Tema 23
Cuando una API se divide en microservicios, la superficie de ataque deja de concentrarse en un solo punto. Aparecen nuevas relaciones de confianza, tráfico interno, identidades de máquina, propagación de contexto y dependencias cruzadas. En este escenario, asegurar solo el borde ya no alcanza: también hay que proteger cómo los servicios se autentican, se autorizan y se observan entre sí.
Las arquitecturas de microservicios prometen escalabilidad, despliegues independientes y separación funcional. Pero también multiplican puntos de entrada, rutas de comunicación, secretos, políticas y decisiones de confianza. Cada servicio que llama a otro servicio abre una nueva frontera de seguridad.
En sistemas monolíticos, muchas decisiones ocurren dentro del mismo proceso. En microservicios, esas decisiones viajan por red. Eso implica que autenticación, autorización, cifrado, observabilidad y manejo de secretos deben repensarse para un entorno donde lo “interno” ya no es un único espacio homogéneo.
Este tema aborda cómo asegurar esa comunicación interna y cómo evitar que la arquitectura distribuida degrade el modelo de seguridad general.
En una API monolítica, una vez que la solicitud entra al backend, gran parte del flujo transcurre dentro de una frontera de proceso relativamente controlada. En microservicios, en cambio, la solicitud puede atravesar múltiples servicios, colas, caches, gateways internos y bases distribuidas.
Eso cambia varias cosas:
Uno de los errores más comunes es asumir que el tráfico entre microservicios es confiable solo por ocurrir dentro de la red interna. Esa suposición puede ser razonable en entornos muy acotados, pero en arquitecturas modernas suele ser débil: hay múltiples equipos, entornos compartidos, nubes, service meshes, componentes tercerizados y superficies de movimiento lateral.
Cuando un servicio llama a otro, el receptor debería saber quién es el llamador técnico, no solo qué request llegó. Esa identidad de servicio permite aplicar políticas, limitar privilegios y trazar responsabilidades.
Sin identidad explícita, el servicio receptor solo ve tráfico genérico de la red y pierde capacidad de:
La autenticación service-to-service puede implementarse con distintos mecanismos: mTLS, tokens firmados, identidades emitidas por plataforma o combinaciones de varios. La elección depende de la arquitectura y del nivel de madurez operativo.
Lo importante es que el servicio receptor no dependa solo del origen de red o de un header fácilmente inyectable. Debe poder verificar de forma confiable la identidad del emisor.
Mutual TLS es especialmente útil en microservicios porque autentica ambas partes del canal y cifra el tráfico interno. Esto ayuda a asegurar que un servicio se comunica realmente con otro servicio autorizado y no con un actor lateral que logró posicionarse en la red.
Sus beneficios incluyen:
En muchas arquitecturas, además de la identidad del servicio, se propaga parte del contexto del usuario original: tenant, scopes, correlation ID, claims relevantes o identidad delegada. Esto permite que servicios internos tomen decisiones coherentes con la solicitud original.
Sin embargo, propagar contexto también crea riesgos:
Es importante distinguir ambas cosas. Un microservicio puede actuar “en nombre” de un usuario, pero sigue siendo un actor técnico distinto. Si esta diferencia no se modela bien, aparecen decisiones de autorización ambiguas y registros poco auditables.
| Identidad | Qué representa | Para qué sirve |
|---|---|---|
| Usuario | El actor funcional original | Autorización de negocio |
| Servicio | El componente técnico que ejecuta la llamada | Control técnico, auditoría y aislamiento |
Así como un usuario no debería tener más acceso del necesario, tampoco un microservicio debería poder llamar libremente a todos los demás. La autorización entre servicios debe responder:
Si todos los servicios pueden llamar a todo, la arquitectura distribuida amplifica el impacto de un solo compromiso.
El principio de mínimo privilegio también debe aplicarse a servicios internos. Un servicio de notificaciones no debería tener acceso pleno a funciones financieras; un servicio de reporting no debería poder modificar entidades transaccionales si no lo necesita.
Esto implica limitar:
La filosofía Zero Trust resulta especialmente útil aquí: no asumir confianza automática por ubicación de red, sino verificar identidad, contexto y política en cada salto relevante. Esto no significa aplicar fricción absurda entre componentes, sino modelar la confianza de forma explícita y verificable.
En la práctica, esto se traduce en:
En algunas arquitecturas, la comunicación segura entre servicios se apoya en service meshes o proxies sidecar que gestionan mTLS, identidad, políticas y telemetría de forma más centralizada. Esto puede mejorar consistencia y reducir esfuerzo por servicio.
Sin embargo, también introduce complejidad adicional. Si el equipo no entiende bien el modelo de confianza o las políticas efectivas, puede asumir protección donde en realidad hay huecos o configuraciones incompletas.
En sistemas dinámicos, los servicios suelen descubrirse entre sí mediante mecanismos de service discovery o resolución interna. Si esa capa no está bien protegida, un atacante o servicio comprometido podría registrar destinos falsos, redirigir tráfico o aprovechar el conocimiento de topología para expandirse.
La seguridad aquí requiere controlar quién puede registrarse, anunciarse y resolver servicios sensibles.
Cada relación service-to-service suele requerir algún tipo de secreto o identidad. Si esos materiales se distribuyen mal, se comparten entre demasiados servicios o no se rotan, la arquitectura distribuida se vuelve frágil.
Buenas prácticas:
Cuando una solicitud atraviesa varios microservicios, la trazabilidad se vuelve esencial. Sin correlación adecuada, es difícil saber qué componente falló, cuál tomó una decisión insegura o dónde comenzó una cadena de abuso.
La observabilidad distribuida debería permitir:
Uno de los mayores riesgos en microservicios es que el compromiso de un solo componente permita moverse lateralmente hacia otros. Esto puede suceder si los servicios confían ciegamente entre sí, comparten secretos, aceptan cualquier tráfico interno o no limitan qué rutas y acciones puede invocar cada actor técnico.
La contención depende de que cada salto tenga barreras reales, no solo supuestos de red.
La seguridad en microservicios exige trasladar las preguntas clásicas de seguridad a cada relación interna del sistema: quién llama, con qué identidad, con qué contexto, a qué recursos y bajo qué reglas. Una arquitectura distribuida bien diseñada puede ser robusta y escalable; una mal gobernada puede convertirse en una red de confianza implícita difícil de proteger. La clave está en tratar cada comunicación entre servicios como una frontera de seguridad real.
En el próximo tema estudiaremos respuesta a incidentes, auditoría y mejora continua en APIs REST, para cerrar el curso con la dimensión operativa y evolutiva de la seguridad.