Tema 5
En sistemas distribuidos ya no alcanza con proteger el perímetro. Los servicios internos también deben demostrar quiénes son, qué pueden hacer y bajo qué condiciones actúan. Zero Trust traslada la seguridad desde la confianza implícita hacia la verificación explícita y continua.
Durante mucho tiempo muchas arquitecturas asumieron una idea peligrosa: si algo estaba dentro de la red interna, podía considerarse confiable. Ese supuesto fue debilitándose con la nube, el trabajo remoto, la integración con terceros, los despliegues automatizados y la proliferación de componentes distribuidos.
En microservicios, esa confianza implícita es todavía más riesgosa. Un servicio comprometido puede usar su posición interna para moverse lateralmente, consultar recursos que no necesita o emitir llamadas que parecen legítimas. Por eso el modelo tradicional de "interior confiable y exterior hostil" deja de ser suficiente.
Zero Trust no es un producto ni una única herramienta. Es una postura arquitectónica: asumir que ninguna interacción merece confianza automática y que cada acceso debe verificarse según identidad, contexto y necesidad real.
Zero Trust suele resumirse en la idea de never trust, always verify. En términos prácticos significa que la pertenencia a una red, a un clúster o a un segmento no debería otorgar privilegios por sí sola.
El acceso a un recurso debe evaluarse en función de:
Los microservicios están llenos de interacciones remotas: llamadas API, intercambio de eventos, acceso a secretos, comunicación con bases de datos y uso de infraestructura compartida. Cada una de esas interacciones es un punto donde conviene aplicar verificación explícita.
Además, la arquitectura distribuida incrementa la probabilidad de compromisos parciales. Un contenedor vulnerable, una cuenta técnica expuesta o una configuración errónea pueden convertir a un servicio interno en un atacante plausible. Zero Trust está pensado precisamente para ese escenario.
Aunque las implementaciones concretas varían, Zero Trust suele apoyarse en algunos principios estables.
En arquitecturas tradicionales el control principal estaba en el borde: firewalls, VPNs, DMZ y proxies. En Zero Trust, sin eliminar esos controles, el eje principal pasa a ser la identidad del solicitante y su contexto.
Esto cambia la pregunta. En lugar de pensar solamente "desde dónde viene la llamada", se empieza a preguntar "quién es", "por qué necesita este acceso", "qué recurso específico puede usar" y "cómo se valida esa afirmación".
| Enfoque tradicional | Enfoque Zero Trust | Consecuencia |
|---|---|---|
| Confianza basada en red o segmento | Confianza basada en identidad y política | Menor dependencia de límites perimetrales |
| Acceso amplio dentro del entorno interno | Acceso acotado por recurso y contexto | Menor movimiento lateral |
| Verificación inicial y luego confianza persistente | Evaluación continua y revocable | Mejor respuesta ante compromisos parciales |
En microservicios no solo existen usuarios humanos. También existen workloads: pods, servicios, jobs, funciones, sidecars o procesos que actúan automáticamente. Esas identidades técnicas deben tratarse con el mismo rigor o incluso con más rigor que las identidades de usuario.
Zero Trust no se reduce a autenticar una vez al inicio y luego asumir confianza ilimitada. Las decisiones de acceso pueden depender del tipo de operación, del entorno, de la sensibilidad del recurso, del riesgo del token o del estado del workload.
Esto no significa pedir credenciales en cada segundo, sino evaluar continuamente si las condiciones que justifican el acceso siguen siendo válidas.
El mínimo privilegio es uno de los pilares de Zero Trust, pero no debe quedarse en una declaración abstracta. En sistemas distribuidos implica revisar qué permisos necesita realmente cada servicio, qué datos consume, qué recursos administra y qué acciones nunca debería poder ejecutar.
Zero Trust suele apoyarse en segmentación fina. En lugar de permitir comunicación amplia entre todos los componentes internos, se autorizan solamente los caminos estrictamente necesarios para que una capacidad funcione.
En microservicios esto puede expresarse como:
La microsegmentación reduce la probabilidad de que un compromiso local se propague a todo el sistema.
Autenticar no alcanza. Un servicio o usuario puede ser legítimo y aun así no estar autorizado para una acción concreta. Por eso Zero Trust necesita autorización fina y contextual.
La decisión de autorización puede depender de:
Zero Trust no puede sostenerse sin telemetría. Si el sistema no registra quién accedió, desde dónde, con qué identidad, a qué recurso y con qué resultado, la política existe solo en el papel.
La observabilidad en este enfoque no es solo técnica. También es de seguridad:
Uno de los aspectos más valiosos de Zero Trust es que obliga a asumir que un componente interno podría estar comprometido. Ese supuesto cambia el diseño: ya no alcanza con que el tráfico venga "de adentro", porque ese origen podría ser precisamente el problema.
Diseñar con esta hipótesis ayuda a limitar movimientos laterales, a restringir tokens y a separar mejor las rutas de acceso más sensibles.
Adoptar Zero Trust cambia decisiones cotidianas de arquitectura. Obliga a pensar contratos más explícitos, permisos más finos, secretos menos persistentes, rutas de acceso más acotadas y validaciones más cercanas a cada recurso sensible.
También modifica la conversación entre equipos: ya no alcanza con que algo "funcione". Hay que poder justificar por qué ese servicio tiene ese permiso, qué evidencia demuestra su identidad y qué controles detectan un uso anómalo.
Zero Trust ofrece una forma más realista de pensar la seguridad en sistemas distribuidos. En lugar de asumir que lo interno es confiable, obliga a construir confianza a partir de identidad, autorización, contexto y evidencia. Esa postura es especialmente adecuada para microservicios, donde los bordes de interacción son numerosos y el compromiso parcial es un escenario plausible.
En el próximo tema estudiaremos el diseño seguro de APIs REST, gRPC y mensajería asíncrona para llevar estos principios a los contratos concretos de comunicación entre componentes.