Consumiendo APIs privadas de Amazon API Gateway usando mutual TLS

En una anterior entrada de blog, se analizó el uso de Amazon API Gateway para crear APIs REST privadas que pueden ser consumidas a través de distintas cuentas de AWS dentro de una nube privada virtual (VPC). Las APIs privadas multicuenta son útiles para los proveedores de software (ISV) y empresas SaaS que proporcionan una conectividad segura a los clientes, y para las organizaciones que crean APIs internas y microservicios de backend.

Mutual TLS (mTLS) es un protocolo de seguridad avanzado que proporciona autenticación bidireccional mediante certificados entre un cliente y un servidor. El protocolo mTLS exige que el cliente envíe un certificado X.509 para demostrar su identidad al realizar una solicitud, junto con el proceso de verificación del certificado de servidor predeterminado. Esto garantiza que ambas partes sean quienes dicen ser.

El proceso de conexión basado en mTLS ilustrado en el diagrama anterior:

1. El cliente se conecta al servidor.
2. El servidor presenta su certificado, que es verificado por el cliente.
3. El cliente presenta su certificado, que es verificado por el servidor.
4. Se ha establecido una conexión TLS cifrada.

Los clientes utilizan mTLS porque ofrece una mayor seguridad y verificación de identidad que las conexiones TLS estándar. mTLS ayuda a prevenir ataques de hombre en el medio (man-in-the-middle) y protege contra amenazas como los intentos de suplantación de identidad, la interceptación de datos y la manipulación. A medida que las amenazas se vuelven más avanzadas, mTLS proporciona una capa de defensa adicional para validar las conexiones.

La implementación de mTLS aumenta la sobrecarga de administración de certificados, pero en el caso de las aplicaciones que transmiten datos valiosos o confidenciales, es importante contar con una mayor seguridad. Si la seguridad es una prioridad para sus sistemas y usuarios, debería considerar la posibilidad de implementar mTLS.

Los endpoints regionales de API Gateway son compatibles de forma nativa con mTLS, pero los endpoints privados de API Gateway no admiten mTLS, por lo que debe terminar el procesamiento de mTLS antes de que la solicitud alcance al API de API Gateway. Una entrada anterior del blog muestra cómo crear API mTLS privadas mediante un proceso de verificación autogestionado dentro de un contenedor que ejecuta un proxy NGINX. Ahora, Application Load Balancer (ALB) admite mTLS de forma nativa, lo que simplifica la arquitectura.

Esta publicación explora la creación de APIs privadas implementando mTLS a través de esta nueva función.

Configuración de mTLS del balanceador de carga de aplicación

Puede habilitar autenticación mutua (mTLS) en un balanceador de carga de aplicación nuevo o uno existente. Al habilitar mTLS en el listener del balanceador de cargas, los clientes deben presentar certificados de confianza para conectarse. El balanceador de cargas valida los certificados antes de permitir que las solicitudes lleguen al backend.

Hay dos opciones disponibles para configurar mTLS en el balanceador de carga de aplicación: el modo Passthrough y el modo Verify with trust store.

En el modo Passthrough, la cadena de certificados del cliente se pasa como un encabezado HTTP X-Amzn-Mtls-Clientcert para que la aplicación inspeccione la autorización. En este escenario, todavía hay un proceso de verificación en el backend. La ventaja de agregar el ALB a la arquitectura es que puede realizar enrutamiento de aplicaciones (capa 7), tal como enrutamiento basado en rutas, lo que permite configuraciones de enrutamiento de aplicaciones más complejas.

En el modo Verify with trust store, el balanceador de cargas valida el certificado del cliente y solo permite que se conecten los clientes que proporcionan certificados confiables. Esto simplifica la administración y reduce la carga de las aplicaciones de backend.

Este ejemplo utiliza una autoridad privada de certificación de AWS, pero los pasos son similares para las autoridades de certificación (CA) de terceros.

Para configurar el almacén de confianza (Trust Store) de certificados para el ALB:

1. Cree una autoridad privada de certificación de AWS. Especifique el Common Name (CN) incluendo el dominio que utilizará para alojar la aplicación (por ejemplo, api.example.com).
2. Exporte la CA mediante la CLI o la consola de AWS y cargue el certificate.pem resultante a un bucket de Amazon S3.
3. Cree un almacén de confianza y apúntelo al certificado cargado en el paso anterior.
4. Actualice el listener de su balanceador de carga de aplicación para usar este almacén de confianza y seleccione el comportamiento de verificación de mTLS requerido.
5. Genere certificados para la aplicación cliente contra la autoridad de certificación privada, por ejemplo, mediante los siguientes comandos:

openssl req -new -newkey rsa:2048 -days 365 -keyout my_client.key -out my_client.csr

aws acm-pca issue-certificate –certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/certificate_authority_id–csr fileb://my_client.csr –signing-algorithm “SHA256WITHRSA” –validity Value=365,Type=”DAYS” –template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1

aws acm-pca get-certificate -certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/certificate_authority_id–certificate-arn arn:aws:acm-pca:us-east-1:account_id:certificate-authority/certificate_authority_id/certificate/certificate_id–output text

Para obtener más información sobre esta parte del proceso, consulte Use ACM Private CA for Amazon API Gateway Mutual TLS.

Verificación mTLS de APIs privadas de API Gateway mediante un ALB

Puede habilitar el uso de mTLS en APIs privada de API Gateway utilizando el modo ALB Verify with trust store, sin la carga operativa que supone un servicio de proxy autogestionado.

Puede usar este patrón para acceder a API Gateway desde la misma cuenta de AWS o desde otras cuentas.

El patrón de misma cuenta permite que los clientes dentro de la VPC consuman el endpoint privado de API Gateway llamando a la URL del balanceador de carga de aplicación. El ALB está configurado para verificar el certificado de cliente proporcionado con el almacén de confianza (Trust Store) antes de pasar la solicitud a la endpoint del API.

Si el certificado no es válido, la API nunca recibe la solicitud. Una política de recursos en el endpoint del API garantiza que las solicitudes solo se permitan a través del VPC Endpoint, y un grupo de seguridad en el VPC endpoint garantiza que solo pueda recibir solicitudes del ALB. Esto evita que el cliente pase por alto la verificación mTLS al llamar directamente el endpoint del API o los endpoints de la VPC.

El patrón multi-cuenta utiliza AWS PrivateLink, que permite conectarse al endpoint del ALB de forma segura entre cuentas y VPCs. Evita la necesidad de conectar las VPC entre sí mediante VPC Peering o AWS Transit Gateway y permite a los proveedores de software ofrecer servicios SaaS para que los consuman sus clientes finales. Este patrón está disponible como código de muestra en el repositorio de GitHub para ser desplegado.

El flujo de una petición de cliente a través de la arquitectura multi-cuenta es el siguiente:

1. Un cliente en la aplicación consumidora envía una solicitud al endpoint de la API del productor.
2. La solicitud se envía a través de AWS PrivateLink a un balanceador de carga de red en la cuenta del consumidor. El balanceador de carga de red es un requisito de los servicios de AWS PrivateLink.
3. El balanceador de carga de red utiliza un target group tipo balanceador de carga de aplicación.
4. El listener del balanceador de carga de aplicación está configurado para mTLs en el modo de verify with trust store mode.
5. Se decide la autorización comparando el certificado del cliente con la cadena del trust store de certificados.
6. Si el certificado del cliente es válido, la solicitud se enruta al endpoint del API a través del VPC endpoint execute-api. Se utiliza una política de recursos de API Gateway para permitir las conexiones únicamente a través del VPC Endpoint.
7. Se lleva a cabo cualquier autenticación y autorización adicional de API Gateway, como el uso de un Lambda Authorizer para validar un JSON Web Token (JWT), por ejemplo.

Si utilizamos el ejemplo implementado en el repositorio de GitHub, esta es la respuesta que se espera de una solicitud correcta con un certificado válido:

curl –key my_client.key –cert my_client.pem https://api.example.com/widgets 

{“id”:”1”,”value”:”4.99”}

When passing an invalid certificate, the following response is received:

curl: (35) Recv failure: Connection reset by peer

Nombres de dominio personalizados

Una ventaja adicional de implementar la solución mTLS con un balanceador de carga de aplicación es la compatibilidad con nombres de dominio privados personalizados. Los endpoints privados de API Gateway no admiten nombres de dominio personalizados en la actualidad. Sin embargo, en este caso, los clientes se conectan primero a un endpoint de ALB, que sí admite un dominio personalizado. El código de ejemplo implementa dominios personalizados privados mediante un certificado público de AWS Certificate Manager (ACM) en el ALB interno y una zona de DNS alojada en Amazon Route 53. Esto le permite proporcionar una URL estática a los consumidores para que, si se reemplaza el API de API Gateway, el consumidor no necesite actualizar su código.

Lista de revocación de certificados

Opcionalmente, como otro nivel de seguridad, también puede configurar una lista de revocación de certificados para un almacén de confianza en el ALB. Las listas de revocación le permiten revocar e invalidar los certificados emitidos antes de su fecha de caducidad. Puede utilizar esta función para excluir a los clientes o denegar credenciales comprometidas, por ejemplo.

Puede añadir la lista de revocaciones de certificados a un almacén de confianza nuevo o existente. La lista se proporciona mediante una URI de Amazon S3 a un archivo con formato PEM.

Conclusión

Esta publicación explora las formas de proporcionar una autenticación TLS mutua para los endpoints privados de API Gateway. En una publicación anterior se muestra cómo lograrlo mediante un proxy NGINX autogestionado. Esta publicación simplifica la arquitectura al utilizar el soporte mTLS nativo que ahora está disponible para los balanceadores de carga de aplicación.

Este nuevo patrón centraliza la autenticación en el borde, agiliza la implementación y minimiza la carga operativa en comparación con la verificación autogestionada. La autoridad de certificación privada de AWS y las listas de revocación de certificados se integran con las credenciales administradas y las políticas de seguridad. Esto facilita la exposición segura de las APIs privadas en todas las cuentas y VPC.

La autenticación mutua y los controles de seguridad progresivos están adquiriendo cada vez más importancia a la hora de diseñar cargas de trabajo seguras basadas en la nube. Para empezar, visite el repositorio de GitHub.

Para obtener más recursos de aprendizaje serverless, visita ServerlessLand.