Los microservicios suelen desplegarse en subredes privadas dentro de una Amazon Virtual Private Cloud (VPC) para garantizar el aislamiento y protegerlos del acceso directo desde internet. Hay dos enfoques habituales para configurar el acceso externo a los microservicios:
- Private Link: una funcionalidad de red que usa interface endpoints para exponer de forma segura los recursos privados de la VPC a API Gateway, sin abrirlos a la internet pública. De esta manera, el tráfico se mantiene dentro de la red de AWS.
- HTTP Integration (orientada a internet): permite que API Gateway enrute las solicitudes hacia endpoints HTTP de acceso público, como un Application Load Balancer (ALB) orientado a internet, de modo que los servicios queden disponibles a través de un endpoint público.
Nos vamos a enfocar en asegurar el segundo enfoque: un ALB orientado a internet detrás de un API Gateway. En concreto, abordamos el reto de restringir el acceso directo al ALB público y permitir que solo los clientes de confianza interactúen con la aplicación a través del API Gateway.
Planteamiento del problema
Cuando se configura un ALB orientado a internet detrás de un API Gateway mediante una integración HTTP, el ALB queda accesible públicamente. Aunque los clientes de confianza se conectan a la aplicación a través del API Gateway, esta configuración introduce un riesgo de seguridad importante: el endpoint público del ALB puede consultarse de forma directa, saltándose las funciones de seguridad del API Gateway.
Esta falta de restricción abre la puerta a varias vulnerabilidades. Para mantener la seguridad y la integridad de tu aplicación, hay que impedir el acceso directo al ALB. Si te aseguras de que todo el tráfico pase por el API Gateway, podrás aplicar funciones de seguridad críticas como la validación de solicitudes, el throttling, la autenticación y la autorización. Sin estas protecciones, los atacantes pueden explotar vulnerabilidades, saltarse los mecanismos de autenticación y saturar los servicios de backend con carga excesiva, lo que puede derivar en ataques de denegación de servicio (DoS).
Si bien AWS ofrece una solución basada en REST API Gateway y AWS Web Application Firewall (WAF) para bloquear las solicitudes que no traigan un header único, ese enfoque suma complejidad y costos. Vale la pena aclarar que, para casos de uso que requieren medidas de seguridad avanzadas como protección contra inyección SQL, cross-site scripting (XSS) o mitigación de bots, AWS WAF sigue siendo una herramienta muy potente.
En este blog presentamos una alternativa más simple y económica. Combinando headers personalizados y condiciones en las reglas del ALB, se logra el mismo nivel de seguridad sin depender de AWS WAF. Este método funciona sin problemas tanto con REST como con HTTP API Gateways y reduce de manera notable la sobrecarga operativa.
**Solución propuesta**
Este enfoque elimina la necesidad de AWS WAF al aprovechar las capacidades de enrutamiento basado en contenido del ALB. La solución consiste en:
- Agregar un header personalizado y su valor a las solicitudes HTTP en API Gateway.
- Configurar las reglas del ALB para validar ese header. Solo las solicitudes con el header y el valor correctos coincidirán con las reglas deseadas; el resto caerá en la regla por defecto.
- Configurar la regla por defecto del ALB para que devuelva un código de error HTTP, como 403 Forbidden.
Esta es una vista general de la arquitectura:
Flujo de la solicitud HTTP.
**Pasos detallados de implementación**
Paso 1: Definir un header personalizado en API Gateway
Para HTTP API Gateway, usa parameter mappings para modificar las solicitudes que se envían a la integración con el ALB.
- Entra a la consola de API Gateway.
- Ve hasta tu HTTP API.
- En la sección "Integrations", abre "Manage Integrations".
- Crea un parameter mapping para incluir el header personalizado y su valor.
Configuración del parameter mapping.
Si tu API Gateway es de tipo REST, sigue este enlace para agregar un header HTTP personalizado.
Paso 2: Configurar las reglas del ALB
- Abre la configuración del ALB en la consola de EC2.
- Para cada regla del listener (excepto la regla por defecto):
- Agrega una condición AND.
- Selecciona "HTTP header" como tipo de condición.
- Ingresa el nombre del header y el valor esperado.
3. Configura la regla por defecto para que devuelva una respuesta de error HTTP (por ejemplo, 403 Forbidden).
Condiciones y acciones de las reglas del ALB.
Si quieres profundizar en el enrutamiento basado en contenido en el ALB, consulta este artículo del blog de AWS.
Paso 3: Probar la configuración
- Envía una solicitud directamente al ALB sin el header personalizado. Verifica que se active la regla por defecto del ALB y que devuelva la respuesta de error.
- Envía una solicitud a través del API Gateway. Verifica que se enrute hacia la aplicación.
**Conclusión**
Esta solución simplifica la arquitectura al eliminar la dependencia de AWS WAF. Al apoyarse en las capacidades nativas de enrutamiento basado en contenido del ALB, este enfoque ofrece una forma segura y eficiente de restringir el acceso directo a tu Application Load Balancer.
Si quieres saber más o te interesan nuestros servicios, no dudes en escribirnos. Puedes contactarnos aquí.