Tema 7
En arquitecturas de microservicios el borde de entrada sigue siendo importante, pero ya no como única línea de defensa. El API Gateway ayuda a centralizar controles, limitar abuso, estandarizar políticas y reducir exposición innecesaria hacia los servicios internos.
En microservicios no conviene exponer directamente cada servicio al exterior. Esa práctica multiplica la superficie de ataque, complica observabilidad, fragmenta políticas de seguridad y hace más difícil controlar el consumo. El sistema necesita un punto de entrada más gobernado.
El API Gateway suele cumplir ese rol. Actúa como capa de acceso centralizada para clientes externos o incluso para ciertos consumidores internos. Allí pueden concentrarse controles como autenticación, validación básica, rate limiting, routing, terminación TLS, observabilidad y algunas políticas transversales.
Sin embargo, es importante entender su alcance real. Un gateway mejora seguridad, pero no reemplaza los controles internos de cada servicio. Si se lo usa como excusa para dejar de validar, autenticar o autorizar dentro del sistema, la arquitectura queda expuesta a fallos internos y movimiento lateral.
Un API Gateway es un componente que recibe solicitudes de clientes, aplica políticas comunes y las enruta hacia servicios internos. Puede simplificar la interacción con el sistema al ocultar topología interna, consolidar endpoints y aplicar reglas transversales de acceso.
Desde el punto de vista de seguridad, su valor principal está en que permite establecer un borde más controlado y consistente para las capacidades que sí deben exponerse.
| Función | Qué aporta | Límite de esa función |
|---|---|---|
| Routing | Oculta topología interna y dirige tráfico | No reemplaza autorización interna |
| Autenticación | Valida credenciales o tokens al ingreso | No alcanza para decisiones finas por recurso |
| Rate limiting | Reduce abuso, picos y scraping | No resuelve toda forma de denegación de servicio |
| Validación básica | Filtra formatos o requests inválidos temprano | No reemplaza validación de negocio |
| Observabilidad | Centraliza logs, métricas y trazas de entrada | No ofrece visibilidad completa del flujo interno |
Un gateway bien diseñado puede mejorar significativamente la postura de seguridad del sistema.
Como ocurre con casi toda herramienta poderosa, un gateway mal usado puede introducir nuevos riesgos.
Una de las funciones más valiosas del gateway es validar la identidad del cliente antes de enrutar la solicitud. Esto puede incluir verificación de tokens, integración con proveedores de identidad, validación de certificados o políticas específicas según tipo de consumidor.
Sin embargo, una autenticación exitosa en el gateway no debería otorgar confianza ciega aguas abajo. Los servicios internos todavía deben validar el contexto que realmente necesitan y, cuando corresponde, volver a autorizar sobre recursos concretos.
El rate limiting ayuda a evitar abuso intencional o involuntario. Permite limitar la cantidad de requests por identidad, IP, cliente, endpoint o ventana temporal. Es útil tanto para seguridad como para estabilidad operativa.
Diseñar mal estos límites también puede ser problemático: cuotas demasiado agresivas afectan usuarios legítimos y cuotas demasiado laxas pierden efectividad.
El gateway puede actuar como primer filtro de requests claramente inválidas. Por ejemplo, puede rechazar payloads demasiado grandes, formatos no permitidos, headers obligatorios ausentes o rutas inexistentes. Esa validación temprana ahorra recursos internos y disminuye exposición.
Pero esta capa tiene un alcance acotado. La validación profunda de negocio sigue perteneciendo a los servicios que entienden el dominio y el contexto real de la operación.
La protección perimetral no desaparece con Zero Trust. Lo que cambia es su rol. Deja de ser la única defensa y pasa a ser una capa más dentro de una estrategia más profunda.
En el borde pueden convivir controles como:
No todo servicio debe ser visible desde el gateway. En una arquitectura madura, solo se exponen las capacidades que realmente necesitan ser consumidas desde fuera del dominio o desde clientes externos.
Esto obliga a preguntarse:
El gateway puede ayudar con autorizaciones gruesas, por ejemplo validar scopes, roles generales o pertenencia a cierto cliente. Pero la autorización fina suele depender del dominio y del recurso concreto, por lo que debe seguir viva en los servicios.
Una buena regla práctica es esta: el gateway puede negar temprano cuando está claro que la solicitud no corresponde, pero los servicios siguen siendo dueños de las decisiones de negocio y de recurso específico.
Como punto de entrada, el gateway ofrece una perspectiva privilegiada del tráfico que entra al sistema. Esto lo vuelve muy útil para seguridad y operación.
Las reglas del gateway no deberían vivir como cambios manuales opacos. Conviene tratarlas como configuración gobernada, versionada y revisable, especialmente cuando afectan autenticación, límites de tráfico o exposición de rutas.
Cuando esto no ocurre, es común terminar con políticas inconsistentes, rutas heredadas, bypass accidentales y poca capacidad para auditar por qué una regla existe.
El API Gateway es una pieza importante para ordenar la exposición de capacidades y aplicar controles consistentes en el borde. Su mayor valor aparece cuando se combina con contratos bien diseñados, identidades claras, autorización contextual y observabilidad sólida. En ese escenario, ayuda a filtrar temprano y a reducir presión sobre el resto de la plataforma.
En el próximo tema estudiaremos identidad, autenticación federada y autorización entre servicios para profundizar cómo se construye confianza verificable dentro y fuera del sistema.