Zero Trust: nunca confíes, siempre verifica

Un lunes, de dos maneras

Un lunes por la mañana, un atacante le hace phishing a Daniel y se lleva una sesión válida. Lo que pasa después depende de cómo entienda la confianza su empresa.

En la primera versión, la sesión de Daniel estaba en la VPN corporativa, así que el atacante ya está dentro y se le trata como alguien de confianza. Se mueve de lado por una red plana, llega a sistemas que Daniel nunca tocó y escala privilegios, porque estar dentro significaba ser de confianza. Una sesión robada se convierte en un compromiso amplio. En la segunda versión, cada recurso al que intenta llegar el atacante se comprueba de nuevo, petición a petición. El dispositivo que usa no es el portátil gestionado y en regla de Daniel, así que las comprobaciones de estado fallan o exigen autenticación escalonada. Su comportamiento aparente, ubicaciones nuevas, recursos desconocidos, horas raras, se aleja del perfil de Daniel, la puntuación de riesgo sube y el sistema pide una reautenticación que el atacante no puede superar. El mínimo privilegio hace que incluso el acceso legítimo de Daniel fuera estrecho, y la segmentación bloquea el paso hacia cualquier cosa que él no usara ya. La sesión robada queda contenida cerca de donde empezó, y la monitorización se enciende para el equipo de seguridad.

La segunda versión es Zero Trust. Nada en ella da por hecho que la brecha se evitó; da por hecho que ocurrió y se pregunta hasta dónde llega. Este módulo ha ido montando la maquinaria del acceso: demostrar la identidad con factores, MFA y biometría, extender un inicio de sesión a muchas apps con SSO y mantener y defender el resultado con la gestión de sesiones. Zero Trust es la estrategia que lo une todo y decide cuánto fiarse de cada cosa, y cuándo.

Durante décadas, la seguridad funcionó con un modelo de perímetro: levantar un muro fuerte, el cortafuegos, y tratar como de confianza todo lo que quedara dentro. Los servicios en la nube, el teletrabajo, el SaaS, los dispositivos móviles y los contratistas borraron ese “dentro”, y los atacantes aprendieron que saltar el muro una sola vez les daba vía libre por todo lo que había detrás. La respuesta de Zero Trust es dejar de fiarse de la red y verificar de forma explícita cada acceso. Es un artículo estratégico, más sobre una forma de pensar que sobre un protocolo. La referencia es NIST SP 800-207, junto con el modelo de madurez Zero Trust de CISA.

Los principios

Zero Trust se suele convertir en eslogan, pero el fondo son tres principios exigentes.

Nunca confíes, verifica siempre. Ninguna petición es de confianza por el sitio del que viene. Estar en la red corporativa, en la VPN o detrás del cortafuegos no concede nada. Cada acceso, de usuario a app, de servicio a servicio, incluso dentro del centro de datos, se autentica y se autoriza de forma explícita y por sus propios méritos, con la identidad, el dispositivo y el contexto. La confianza nunca se hereda de la red.

Asume que ya te han comprometido. Diseña como si el atacante ya estuviera dentro. Eso cambia la mentalidad de mantenerlo fuera a limitar lo que puede hacer una vez dentro. De ahí salen la segmentación, para que una brecha en un sitio no se extienda; el mínimo privilegio, para que una cuenta comprometida llegue a poco; un buen registro de eventos, para poder ver al intruso; y accesos de vida corta que se vuelven a comprobar, para que un punto de apoyo se degrade en lugar de durar. Dejas de apostarlo todo a un muro que tarde o temprano caerá.

Mínimo privilegio. Cada identidad, humana o carga de trabajo, recibe el acceso mínimo que necesita durante el tiempo mínimo, sin permisos amplios y permanentes “por si acaso”. Es el mismo principio que rige la autorización y la gestión de accesos privilegiados, aplicado como postura por defecto: el acceso es estrecho, acotado y caduca. Es lo que hace sobrevivible el “asume que ya te han comprometido”, porque si los privilegios son mínimos, un compromiso queda contenido por diseño.

La seguridad de perímetro pregunta si estás dentro de la red. Zero Trust pregunta quién eres, qué estás usando y si esta petición concreta es segura ahora mismo, cada vez. Ese paso de la ubicación a la verificación petición a petición es toda la idea.

Los siete principios operativos

NIST SP 800-207 no se queda en los principios. Enumera siete principios operativos (tenets) que convierten el “nunca confíes, verifica siempre” en requisitos comprobables, y auditores y arquitectos suelen citarlos por su número. Dicho con otras palabras: todas las fuentes de datos y servicios de cómputo cuentan como recursos, así que no existe una zona privilegiada que no necesite protección. Todas las comunicaciones se protegen sea cual sea la ubicación en la red, con el tráfico autenticado y cifrado igual dentro que fuera. El acceso se concede por sesión, de modo que un permiso sobre un recurso no se extiende solo al siguiente recurso ni a la siguiente sesión. El acceso lo decide una política dinámica que tiene en cuenta la identidad, la aplicación, el dispositivo que pide y atributos de comportamiento y de entorno, y no una regla estática atada a un rango de IP. La organización mide la integridad y el estado de todos sus activos, así que un dispositivo que no cumple es un dispositivo de menos confianza. La autenticación y la autorización son dinámicas y se aplican con rigor antes del acceso, evaluadas de forma continua y no una sola vez. Y la organización recoge telemetría de activos, infraestructura y comunicaciones y la usa para mejorar su postura, lo que convierte la monitorización en el bucle que mantiene afinadas las decisiones.

Lee juntos el tercero y el sexto y tienes la esencia operativa: por sesión, evaluado de nuevo, cada vez. Lee el quinto y entiendes por qué el estado del dispositivo va al lado de la identidad en cada decisión.

La arquitectura: PEP, PDP y el algoritmo de confianza

NIST SP 800-207 describe Zero Trust con un conjunto pequeño y preciso de componentes, y aprenderlos convierte la filosofía en algo que se puede construir.

El Policy Enforcement Point (PEP), el punto de aplicación de políticas, es la puerta que hay delante de un recurso. Intercepta cada petición y aplica la decisión, permitir, bloquear o permitir con condiciones, sin decidir nada por sí mismo. En la práctica es un proxy inverso, una pasarela consciente de la identidad o un sidecar de una service mesh. El Policy Decision Point (PDP), el punto de decisión, es el cerebro. Para cada petición que le pasa el PEP, evalúa la política y devuelve un veredicto. NIST lo divide en el motor de políticas, que toma la decisión, y el administrador de políticas, que emite o revoca las credenciales o los tokens de sesión que permiten al PEP abrir la puerta. El algoritmo de confianza es la lógica dentro del PDP que pondera todas las señales para llegar a un veredicto: la identidad y sus permisos, el estado del dispositivo, el contexto de la petición como la ubicación y la hora, y las señales de comportamiento y de inteligencia de amenazas. Puede ser un simple sí o no, pero funciona mejor como una puntuación que se adapta, que es la idea de la autenticación adaptativa basada en riesgo generalizada a todas las decisiones de acceso. Y los puntos de información de políticas son las fuentes de esas señales: el proveedor de identidad, un feed del estado de los dispositivos o del EDR, la inteligencia de amenazas, el SIEM y la analítica de comportamiento, los datos de permisos.

flowchart LR
  accTitle: Bucle de decisión y aplicación de políticas de Zero Trust
  accDescr: Un sujeto hace una petición a un recurso. La petición llega a un punto de aplicación de políticas, que la reenvía a un punto de decisión de políticas. El punto de decisión ejecuta un algoritmo de confianza que lee señales de puntos de información como el proveedor de identidad, el estado del dispositivo, el contexto y la inteligencia de amenazas. El algoritmo devuelve permitir, autenticación escalonada o denegar al punto de aplicación, que concede o bloquea el acceso al recurso. Una flecha de reevaluación continua vuelve desde la sesión del recurso al punto de decisión, de modo que la confianza se reevalúa cuando cambian las señales.
  S[Sujeto: usuario o carga de trabajo] --> PEP{Punto de aplicación<br/>PEP}
  PEP -->|pregunta| PDP[Punto de decisión PDP<br/>algoritmo de confianza]
  IdP[Identidad + permisos] --> PDP
  DEV[Estado del dispositivo] --> PDP
  CTX[Contexto: ubicación, hora] --> PDP
  TI[Amenazas + comportamiento] --> PDP
  PDP -->|permitir / step-up / denegar| PEP
  PEP -->|concedido| R[(Recurso)]
  R -. reevaluación continua .-> PDP

Confianza adaptativa continua

La debilidad clásica de la autenticación es que ocurre una vez, en la puerta. Todo lo que viene después del inicio de sesión se apoya en esa única decisión, y por eso una sesión SSO robada o una cookie secuestrada son tan potentes: heredan una decisión de confianza tomada hace minutos u horas, en unas condiciones que quizá ya no se cumplan.

La confianza adaptativa continua cierra ese hueco reevaluando la confianza durante toda la sesión en lugar de congelarla al iniciarla. El algoritmo de confianza sigue mirando, y cuando cambia el panorama, cambia la decisión. Si la ubicación del usuario salta a otro país a mitad de sesión, el sistema pide autenticación escalonada o un nuevo inicio de sesión. Si su comportamiento deja de encajar con su perfil, la señal de la biometría de comportamiento, el riesgo sube y el acceso se restringe o se pone a prueba. Si su dispositivo deja de cumplir porque falta un parche o se paró el agente de EDR, el acceso se estrecha o se corta en el acto. Si la inteligencia de amenazas marca la dirección de origen, la sesión se bloquea en pleno vuelo. Estándares como CAEP y el Shared Signals Framework, que vimos en el artículo de la frontera, permiten al proveedor de identidad enviar esos cambios a todas las aplicaciones en tiempo real.

Aquí confluye todo el módulo. La biometría de comportamiento alimenta en silencio la confianza continua. La autenticación escalonada es su respuesta cuando sube el riesgo. Las sesiones cortas y la revocación en el servidor son lo que le permite actuar cuando cambia el veredicto. Es el “verifica siempre” estirado de un instante a toda la vida del acceso, y es el corazón operativo de un programa Zero Trust maduro.

La identidad es el plano de control

Si la ubicación en la red ya no concede confianza, algo tiene que hacerlo, y ese algo es la identidad. En Zero Trust, la pregunta de si una petición debe permitirse se responde sobre todo con quién es el sujeto autenticado, usuario o carga de trabajo, a qué tiene derecho, en qué estado está su dispositivo y cuál es su riesgo ahora mismo. La identidad es la única señal presente en todas las decisiones de acceso.

Eso convierte al proveedor de identidad y a su motor de políticas en el principal punto de aplicación, el plano de control de la arquitectura, y es la razón de que este dominio importe tanto. La autenticación fuerte con factores resistentes al phishing, el acceso federado blindado frente a su radio de impacto y unas sesiones bien gestionadas no son temas aparte; son el suelo sobre el que se apoya Zero Trust. Identidad débil significa Zero Trust débil, por mucho que se gaste en herramientas de red. Eso es lo que se quiere decir con “la identidad es el nuevo perímetro”: la frontera que defiendes ya no es el borde de la red, sino la identidad que hay detrás de cada petición.

Algunas organizaciones compran microsegmentación de red y la llaman Zero Trust mientras su capa de identidad sigue funcionando con contraseñas y códigos por SMS. Es empezar la casa por el tejado. Como la identidad es el plano de control, la madurez en Zero Trust empieza por hacer bien la identidad: MFA en todas partes, factores resistentes al phishing para el acceso privilegiado, permisos de mínimo privilegio y evaluación continua del riesgo. Los controles de red importan, pero van encima de la identidad, no en su lugar.

ZTNA: lo que sustituye a la VPN de confianza

La forma más visible de Zero Trust a nivel de producto es el ZTNA, Zero Trust Network Access, y compararlo con la VPN clásica concreta mucho la estrategia. Una VPN tradicional es una herramienta de perímetro disfrazada. Cuando te autenticas en ella, te coloca en la red y normalmente puedes llegar a un montón de recursos internos, confianza implícita concedida por un único inicio de sesión, justo el modelo que Zero Trust rechaza. Si te roban las credenciales de la VPN, el atacante hereda ese alcance, como en la primera versión del lunes de Daniel.

El ZTNA le da la vuelta. En lugar de ponerte en la red, intermedia el acceso a aplicaciones concretas a través de una pasarela que comprueba la política, un PEP, y abre una conexión a un recurso solo después de que el PDP haya evaluado la identidad, el estado del dispositivo y el contexto de esa petición. Llegas a la app concreta que tienes permitida, nunca a un segmento de red plano. Las aplicaciones quedan ocultas a la red y solo se alcanzan a través del intermediario, lo que reduce lo que un intruso puede siquiera ver. Y el acceso se puede estrechar o cortar a mitad de sesión cuando cambia el estado, mientras que un túnel VPN, una vez levantado, es de confianza hasta que se cae. El ZTNA se vende a menudo dentro de una plataforma SASE (Secure Access Service Edge), pero es un componente que aplica Zero Trust al acceso remoto, no Zero Trust en sí.

Microsegmentación y radio de impacto

“Asume que ya te han comprometido” necesita un mecanismo, y la microsegmentación es el principal en la capa de red y de cargas de trabajo. El modelo antiguo era una red interna plana: comprometías una máquina y podías llegar a miles. La microsegmentación divide el entorno en zonas pequeñas, cada una con su propia política, idealmente hasta el nivel de cada carga de trabajo, para que llegar a una cosa no te dé la siguiente. Un atacante que compromete un servidor descubre que el movimiento lateral, la técnica detrás de casi todas las grandes brechas, está bloqueado por la política en cada salto, y que cada salto tiene que pasar sus propias comprobaciones de identidad y de estado. Sumada al mínimo privilegio en las identidades, la segmentación convierte un punto de apoyo de trampolín en callejón sin salida. La identidad decide quién; la segmentación limita hasta dónde.

Cargas de trabajo e identidades no humanas

Zero Trust se suele explicar pensando en un usuario humano, pero la mayor parte del acceso en un sistema moderno es de máquina a máquina: servicios, contenedores, funciones, scripts y, cada vez más, agentes de IA que se llaman entre sí. Estas identidades no humanas superan ya con mucho a las personas, y los mismos principios se aplican sin excepción. Cada llamada entre servicios se autentica y se autoriza de forma explícita, recibe el mínimo privilegio y nunca es de confianza solo porque venga “de dentro del clúster”.

En la práctica, las cargas de trabajo reciben identidades fuertes y verificables en lugar de secretos compartidos en ficheros de configuración: estándares como SPIFFE y SPIRE, identidades de carga de trabajo en la nube como las identidades administradas y los roles de IAM, y credenciales de vida corta que rotan solas en lugar de claves de API de larga duración. El algoritmo de confianza evalúa la identidad y el estado de un servicio igual que los de una persona. A medida que la autenticación humana se vuelve más difícil de burlar, los atacantes se pasan a las identidades de máquina, más blandas y mucho más numerosas, y por eso el dominio de accesos privilegiados e identidades no humanas, más adelante en el temario, importa tanto. Zero Trust tiene que cubrirlas, o tendrá un hueco justo donde está el volumen.

Por dónde empezar

Como Zero Trust es un camino, la pregunta práctica nunca es cómo terminarlo, sino por dónde empezar y en qué orden. Una secuencia defendible, coherente con el modelo de madurez de CISA, empieza por un inventario, porque no puedes proteger lo que no ves: las identidades, humanas y no humanas, los dispositivos y las aplicaciones y datos a los que llegan. Después toca arreglar la identidad: MFA en todas partes, factores resistentes al phishing para el acceso privilegiado y de administración, y consolidación en un proveedor de identidad fuerte. Es el movimiento de más palanca, porque la identidad es el plano de control. Luego se incorpora el estado del dispositivo, para que un dispositivo no gestionado o vulnerable se trate como de menos confianza. Luego se aplica el mínimo privilegio, recortando accesos permanentes, adoptando la elevación justo a tiempo y estrechando permisos, lo que reduce el radio de impacto alrededor del cual se diseña el “asume que ya te han comprometido”. Luego se segmenta y se intermedia el acceso, sustituyendo la confianza de la red plana por acceso por aplicación y microsegmentación. Y por último se instrumenta y se adapta, conectando la telemetría a la monitorización y al ITDR y llevando el algoritmo de confianza de reglas estáticas a una evaluación continua basada en riesgo.

El orden importa. Los equipos que empiezan comprando un equipo de segmentación y se saltan el trabajo de identidad se quedan con la etiqueta de Zero Trust sin la protección.

Mitos

Zero Trust es uno de los términos peor usados de la seguridad, y despejar los mitos forma parte de entenderlo. El mayor es que es un producto que se compra. Ningún fabricante vende Zero Trust en una caja. Es una estrategia y una arquitectura construidas con identidad, estado del dispositivo, políticas, segmentación y monitorización, y un producto puede ser una pieza, nunca el todo. Muy relacionado está la idea de que es una sola tecnología: no es solo microsegmentación, ni solo una pasarela ZTNA, ni solo MFA, y si quitas la identidad, la monitorización o el mínimo privilegio, deja de ser Zero Trust.

Otro mito es que significa no fiarse de nada y renunciar a la usabilidad. Significa quitar la confianza implícita y no ganada, no hacer los sistemas inservibles. Bien hecho, a menudo se nota más fluido: cuando el riesgo es bajo, la verificación es invisible, una passkey y un dispositivo en regla pasan sin que nadie se entere, y la fricción solo aparece cuando sube el riesgo. La confianza se gana en cada petición, no se suprime. También se trata como un proyecto que se termina, cuando es un camino que se mide por madurez. El modelo de CISA lo organiza en pilares, identidad, dispositivos, redes, aplicaciones y datos, que avanzan de tradicional a óptimo con el tiempo. Y no sustituye al cortafuegos ni a la VPN el primer día. Cambia su papel y reduce la dependencia de ellos, pero la adopción es gradual.

El error que más daño hace es tratar Zero Trust como una compra: adquirir un producto con la etiqueta, cantar victoria y dejar sin tocar la identidad, el mínimo privilegio y la monitorización continua. Eso trae el coste de Zero Trust sin nada de su protección. Empieza por los principios, ánclate en la identidad, mide con un modelo de madurez y trata cada producto como un medio, nunca como el objetivo.

Dónde encaja entre los marcos

Zero Trust conecta con las guías a las que ya responden los equipos de seguridad, y nombrar esos vínculos ayuda al presentarlo a la dirección. NIST SP 800-207 es la referencia de arquitectura. El modelo de madurez Zero Trust de CISA lo convierte en pilares y etapas para evaluarlo en la práctica. El mandato federal estadounidense, OMB M-22-09, puso a las agencias con plazos de Zero Trust, y eso explica buena parte de por qué el término se popularizó, y la arquitectura de referencia Zero Trust del Departamento de Defensa añade un desglose de capacidades de nivel militar.

Complementa los marcos más amplios en lugar de sustituirlos. Zero Trust es una estrategia de acceso; el NIST Cybersecurity Framework encuadra todo el programa de riesgos a su alrededor; ISO 27001 gobierna el sistema de gestión; y el mínimo privilegio y la segmentación aparecen en casi todos los catálogos de controles, de los CIS Controls a PCI DSS. En la práctica, el mismo despliegue de MFA, la misma revisión de mínimo privilegio y la misma monitorización continua que suben tu madurez generan también evidencias de auditoría para los requisitos de control de acceso, autenticación y registro de varios marcos a la vez, lo que convierte “otro proyecto de seguridad” en una postura que cumple obligaciones que ya tienes.

Tropiezos en el despliegue

Incluso los equipos que entienden Zero Trust en teoría tropiezan con trampas operativas que se repiten. Si añades verificación en todas partes de golpe, los usuarios se rebelan, la dirección da marcha atrás y el programa se atasca; la cura es el enfoque adaptativo, hacer invisible el acceso de bajo riesgo para que la fricción solo aparezca cuando sube el riesgo. Las políticas agresivas que juzgan mal el estado o el contexto dejan fuera a usuarios y cargas de trabajo reales en una caída provocada por uno mismo; despliega primero en modo observación, registrando lo que se habría bloqueado, antes de aplicar, y aplica por fases. Los equipos blindan el inicio de sesión humano y dejan las cuentas de servicio, las claves de API y las identidades de máquina con la vieja confianza implícita, que es justo hacia donde va después el atacante. Las reglas por recurso y por contexto se multiplican hasta formar una maraña que nadie entiende del todo, y eso se convierte en un riesgo en sí mismo; centraliza la política, escríbela como código cuando puedas y revísala. Las apps nuevas en la nube reciben Zero Trust mientras los sistemas heredados, las conexiones con terceros y la TI en la sombra conservan su confianza plana, y los atacantes van directos a lo que queda sin proteger, así que el inventario tiene que ser honesto sobre lo que todavía no está cubierto. Y los equipos cantan victoria en un hito y dejan que la postura se degrade, cuando Zero Trust hay que mantenerlo de forma continua o se deteriora. Zero Trust rara vez falla por el concepto. Falla por la disciplina del despliegue.

Resumen

Zero Trust es la estrategia que da sentido al resto de este módulo. Sustituye la confianza del perímetro por una verificación explícita petición a petición, construida sobre tres principios de NIST SP 800-207: nunca confíes, verifica siempre; asume que ya te han comprometido; mínimo privilegio. Su arquitectura separa la decisión de la aplicación, con un PEP que aplica y un PDP que ejecuta un algoritmo de confianza sobre las señales de los puntos de información. La confianza adaptativa continua reevalúa la confianza durante toda la sesión, alimentada por señales de comportamiento, autenticación escalonada, sesiones cortas y revocación. La identidad es el plano de control, así que la autenticación fuerte, el SSO blindado y la higiene de sesiones son sus cimientos. Y es una estrategia y un camino, no un producto; todos los mitos se reducen a esa idea.

Tres preguntas para ponerte a prueba

1. Une el módulo: para una única petición de “transferir dinero”, di a qué componente de Zero Trust (PEP, PDP, algoritmo de confianza o un punto de información) corresponde cada una de estas cosas: el resultado del MFA del proveedor de identidad, el proxy inverso delante de la API, la puntuación de riesgo y el feed de cumplimiento de los dispositivos.
2. Un fabricante le presenta a tu CISO una “plataforma Zero Trust” que en el fondo es un equipo de microsegmentación de red. Plantea tres preguntas que dejen claro si adoptarla por sí sola daría de verdad Zero Trust.
3. Con la confianza adaptativa continua, explica cómo debería reaccionar un sistema Zero Trust ante una sesión SSO robada de forma distinta a un modelo de perímetro. ¿Qué controles de este módulo hacen posible esa reacción?

Ejercicios prácticos

1. Encuentra los componentes en un entorno real. En un sistema que conozcas, aunque sea una cuenta personal en la nube, identifica qué hace de PEP, qué hace de PDP y qué señales alimentan la decisión (MFA, dispositivo, ubicación). Dibuja el recorrido de una petición.
2. Puntúa la madurez de la identidad. Con el pilar de identidad del modelo de madurez Zero Trust de CISA, sitúa a una organización que conozcas en la escala de tradicional a óptimo en cobertura de MFA, mínimo privilegio y evaluación continua. Nombra el siguiente paso de más valor.
3. Reescribe una regla de perímetro. Toma una regla antigua como “cualquiera conectado a la VPN puede entrar en la wiki interna” y reescríbela como una política por petición basada en la identidad y el dispositivo. Di qué señales necesitaría tu algoritmo de confianza para aplicarla.