Zero Trust: nunca confíes, siempre verifica

La idea que reorganiza todo lo anterior

Este módulo construyó la maquinaria del acceso: cómo pruebas la identidad (factores, MFA, biometría), cómo un login se esparce entre apps (SSO), y cómo se sostiene y defiende la sesión resultante (gestión de sesiones). Zero Trust es la estrategia que ata todo eso y te dice cuánto confiar en cualquier parte de ello, y cuándo.

Durante décadas la seguridad corrió sobre un modelo de perímetro: construye un muro fuerte (el firewall) y trata como confiable todo lo que esté dentro. Una vez en la red corporativa, eras mayormente libre de moverte. Ese modelo murió al contacto con la realidad — la nube, el trabajo remoto, el SaaS, el móvil y los contratistas borraron el “dentro”, y los atacantes aprendieron que romper el perímetro una vez les daba libre acceso a todo lo de atrás. Zero Trust es la respuesta: deja de confiar en la red, y verifica cada acceso de forma explícita.

Este es el broche del módulo y un artículo estratégico. Va menos sobre un protocolo puntual y más sobre una forma de pensar que recompone factores, SSO y sesiones en una postura coherente. La referencia canónica es NIST SP 800-207, complementada por el CISA Zero Trust Maturity Model.

Los principios (NIST SP 800-207)

Zero Trust se convierte a menudo en eslogan, pero la sustancia son tres principios disciplinados.

Nunca confíes, siempre verifica

Ninguna petición es confiable por de dónde viene. Estar en la LAN corporativa, en la VPN o detrás del firewall no concede nada. Cada acceso — usuario a app, servicio a servicio, incluso dentro del datacenter — se autentica y autoriza de forma explícita, por sus propios méritos, usando identidad, dispositivo y contexto. La confianza nunca se hereda de la red.

Asume la brecha

Diseña como si un atacante ya estuviera dentro. Esto invierte la mentalidad de “mantenlos afuera” a “limita lo que pueden hacer una vez dentro”. Impulsa la segmentación (una brecha en un lugar no se propaga), el mínimo privilegio (una cuenta comprometida alcanza poco), el logging rico (puedes ver al intruso) y el acceso de vida corta y re-verificado (un punto de apoyo se degrada en vez de persistir). Dejas de apostarlo todo a un muro que eventualmente será roto.

Mínimo privilegio

Cada identidad — humana o workload — obtiene el acceso mínimo necesario, por el mínimo tiempo. Sin concesiones amplias permanentes “por si acaso”. Es el mismo principio de mínimo privilegio que gobierna la autorización y el PAM, aplicado como postura por defecto: el acceso es estrecho, acotado y expira. Es lo que hace sobrevivible al “asume la brecha” — si los privilegios son mínimos, un compromiso queda contenido por diseño.

Los siete principios, hechos concretos

NIST SP 800-207 no se queda en eslóganes — enumera siete principios (tenets) que convierten el “nunca confíes, siempre verifica” en requisitos comprobables. Parafraseados, y vale conocerlos porque auditores y arquitectos los referencian por número:

1. Todas las fuentes de datos y servicios de cómputo son recursos. No existe una “zona confiable” privilegiada de cosas que no necesitan protección — cada activo está en alcance.
2. Toda comunicación se asegura sin importar la ubicación de red. Estar en la red interna no cambia nada; el tráfico se autentica y cifra igual dentro que fuera.
3. El acceso se concede por sesión. Una concesión a un recurso se evalúa por sí misma y no se extiende automáticamente al siguiente recurso ni a la siguiente sesión.
4. El acceso lo determina una política dinámica — identidad, aplicación, dispositivo solicitante y atributos de comportamiento/entorno — no una regla estática fijada a un rango de IP.
5. La empresa mide la integridad y postura de todos los activos. La salud del dispositivo es una entrada de primera clase; un dispositivo que no cumple es un dispositivo de menor confianza.
6. Toda autenticación y autorización es dinámica y estrictamente aplicada antes del acceso — evaluada continuamente, no una vez, y aplicada antes de alcanzar el recurso.
7. La empresa recolecta telemetría de activos, infraestructura y comunicaciones, y la usa para mejorar la postura. El monitoreo no es opcional; es el bucle de retroalimentación que hace más inteligente al Trust Algorithm.

Lee los principios 3 y 6 juntos y obtienes la esencia operativa: por sesión, evaluado fresco, cada vez. Lee el principio 5 y ves por qué la postura del dispositivo va junto a la identidad en cada decisión. Estos siete son la checklist detrás de la arquitectura que sigue.

La arquitectura: PDP, PEP y el Trust Algorithm

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

• Policy Enforcement Point (PEP) — la compuerta frente a un recurso. Intercepta cada petición y hace cumplir la decisión: permitir, bloquear o permitir-con-condiciones. No decide; ejecuta. (Un reverse proxy, un gateway identity-aware, un sidecar de service mesh.)
• Policy Decision Point (PDP) — el cerebro. Por cada petición que el PEP reenvía, el PDP evalúa la política y devuelve permitir/denegar. Se divide conceptualmente en el Policy Engine (corre la decisión) y el Policy Administrator (emite/revoca las credenciales o tokens de sesión que dejan al PEP abrir la compuerta).
• Trust Algorithm — la lógica dentro del PDP que pondera todas las señales para llegar a un veredicto: identidad y sus entitlements, postura del dispositivo, contexto de la petición (ubicación, hora), entradas de comportamiento e inteligencia de amenazas. Puede ser binario o, mejor, basado en puntaje y adaptativo — que es exactamente la idea de autenticación adaptativa basada en riesgo del artículo de factores, generalizada a cada decisión de acceso.
• Policy Information Points (PIPs) — las fuentes de señales que el Trust Algorithm lee: el proveedor de identidad, un feed de postura de dispositivo/EDR, inteligencia de amenazas, SIEM/analítica de comportamiento, datos de entitlements.

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 Policy Enforcement Point, que la reenvía a un Policy Decision Point. El Policy Decision Point corre un Trust Algorithm que lee señales de puntos de información que incluyen el proveedor de identidad, la postura del dispositivo, el contexto y la inteligencia de amenazas. El Trust Algorithm devuelve una decisión de permitir, step-up o denegar al punto de aplicación, que concede o bloquea el acceso al recurso. Una flecha de reevaluación continua vuelve de la sesión del recurso al punto de decisión para que la confianza se reevalúe a medida que las señales cambian.
  S[Sujeto: usuario o workload] --> PEP{Policy Enforcement Point}
  PEP -->|consulta| PDP[Policy Decision Point<br/>Trust Algorithm]
  IdP[Identidad + entitlements] --> PDP
  DEV[Postura de dispositivo] --> PDP
  CTX[Contexto: ubicación, hora] --> PDP
  TI[Inteligencia + comportamiento] --> PDP
  PDP -->|permitir / step-up / denegar| PEP
  PEP -->|concedido| R[(Recurso)]
  R -. reevaluación continua .-> PDP

Continuous Adaptive Trust: verificación que nunca se detiene

La debilidad clásica de la autenticación es que ocurre una vez, en la puerta. Todo lo posterior al login monta esa única decisión — que es justo por qué una sesión robada (artículo de SSO) o una cookie secuestrada (artículo de sesiones) es tan poderosa: hereda una decisión de confianza tomada minutos u horas atrás, bajo condiciones que quizá ya no se cumplen.

El Continuous Adaptive Trust (CAT) cierra esa brecha. La confianza se reevalúa a lo largo de la sesión, no se congela en el login. El Trust Algorithm sigue observando, y si el panorama cambia, la decisión cambia:

• La ubicación del usuario salta a un nuevo país a mitad de sesión → step-up o re-autenticar.
• Su comportamiento deja de coincidir con su perfil (la señal de biometría comportamental del artículo de biometría) → sube el riesgo, restringe o desafía.
• Su dispositivo deja de cumplir — falta un parche, EDR deshabilitado — → estrecha o corta el acceso de inmediato.
• La inteligencia de amenazas marca la IP de origen → bloquea la sesión en vuelo.

Aquí converge todo el módulo. La biometría comportamental alimenta el CAT en silencio. El step-up es la respuesta del CAT al riesgo creciente. Las sesiones cortas y la revocación server-side son lo que permite al CAT realmente actuar sobre un veredicto cambiado. El CAT es el “siempre verifica” extendido de un instante único a la vida entera del acceso — el corazón operativo de un programa Zero Trust maduro.

La identidad es el plano de control

Si la ubicación de red ya no concede confianza, algo debe hacerlo — y ese algo es la identidad. En Zero Trust, la pregunta “¿debe permitirse esta petición?” se responde principalmente desde: quién es el sujeto autenticado (usuario o workload), a qué tiene derecho, cuál es la postura de su dispositivo y cuál es su riesgo en tiempo real. La identidad es la única señal presente en cada decisión de acceso.

Eso hace del proveedor de identidad y su policy engine el punto de aplicación primario — el plano de control de la arquitectura. Es por lo que todo este dominio importa tanto: la autenticación fuerte (factores, MFA, passkeys resistentes a phishing), el acceso federado (SSO) endurecido contra el blast radius, y las sesiones bien gestionadas no son temas separados — son el sustrato sobre el que corre Zero Trust. Identidad débil significa Zero Trust débil, por mucho que se gaste en herramientas de red. Este es el significado de la frase de la industria “la identidad es el nuevo perímetro”: el límite que defiendes ya no es el borde de la red, es la identidad que hace cada petición.

ZTNA: lo que reemplaza a la VPN confiable

La expresión a nivel de producto más visible de Zero Trust es ZTNA — Zero Trust Network Access, y contrastarla con la clásica VPN hace concreta toda la estrategia.

Una VPN tradicional es una herramienta de perímetro disfrazada: una vez que te autenticas a ella, quedas en la red y típicamente puedes alcanzar un amplio rango de recursos internos — confianza implícita concedida por un solo login, justo el modelo que Zero Trust rechaza. Si un atacante roba las credenciales de la VPN, hereda ese alcance amplio.

ZTNA lo invierte. En vez de ponerte en la red, intermedia acceso por aplicación a través de un gateway con política (un PEP), concediendo conexión a un recurso solo después de que el PDP evalúa identidad, postura de dispositivo y contexto para esa petición. Diferencias clave:

• A nivel de aplicación, no de red. Alcanzas la app específica para la que estás autorizado, nunca un segmento de red plano.
• Los recursos quedan a oscuras. Las aplicaciones no se exponen en la red; solo son alcanzables por el broker, encogiendo la superficie de ataque que un intruso siquiera puede ver.
• Evaluado continuamente. El acceso puede estrecharse o cortarse a mitad de sesión conforme cambia la postura — la idea del CAT en acción — mientras que un túnel VPN, una vez arriba, es confiable hasta que cae.

ZTNA se entrega a menudo como parte de una plataforma SASE (Secure Access Service Edge), pero recuerda el mito que viene: ZTNA es un componente que aplica Zero Trust al acceso remoto, no Zero Trust en sí.

Por dónde empezar: una ruta de adopción pragmática

Como Zero Trust es un viaje, la pregunta práctica nunca es “¿cómo terminamos?” sino “¿por dónde empezamos, y en qué orden?” Una secuencia defendible, consistente con el modelo de madurez de CISA:

1. Inventario. No puedes proteger lo que no ves — enumera identidades (humanas y no humanas), dispositivos y las aplicaciones/datos que alcanzan. Es el principio 1 en la práctica.
2. Arregla la identidad primero. MFA en todos lados, factores resistentes a phishing para el acceso privilegiado y de administrador, y consolidación en un IdP fuerte. Es el movimiento de mayor apalancamiento porque la identidad es el plano de control.
3. Incorpora la postura de dispositivo. Alimenta la salud/cumplimiento del dispositivo en las decisiones de acceso para que un dispositivo no gestionado o vulnerable se trate como de menor confianza.
4. Aplica el mínimo privilegio. Recorta el acceso permanente, adopta elevación just-in-time y acota los entitlements — encogiendo el blast radius alrededor del cual se diseña el “asume la brecha”.
5. Segmenta e intermedia el acceso. Reemplaza la confianza plana de red con acceso por aplicación (ZTNA) y micro-segmentación para que un punto de apoyo no pueda propagarse.
6. Instrumenta y adapta. Conecta la telemetría al monitoreo e ITDR, y lleva el Trust Algorithm de reglas estáticas hacia evaluación continua basada en riesgo.

El orden importa: los equipos que empiezan en el paso 5 (comprar un appliance de segmentación) saltándose el paso 2 (arreglar la identidad) obtienen la etiqueta de Zero Trust sin la protección — el modo de falla exacto que describen los mitos de abajo.

Mitos comunes

Zero Trust es uno de los términos más mal usados en seguridad. Aclarar los mitos es parte de entenderlo.

• “Zero Trust es un producto que compras.” El mayor mito. Ningún proveedor entrega Zero Trust en una caja. Es una estrategia y arquitectura ensamblada a partir de identidad, postura de dispositivo, política, segmentación y monitoreo. Un producto puede ser un componente; ninguno es el todo.
• “Zero Trust es una tecnología.” No es solo micro-segmentación, ni solo un gateway ZTNA, ni solo MFA. Es una combinación coherente guiada por principios y un modelo de madurez — quita la identidad, o el monitoreo, o el mínimo privilegio, y deja de ser Zero Trust.
• “Zero Trust significa no confiar en nada / cero usabilidad.” Significa eliminar la confianza implícita e inmerecida — no volver inusables los sistemas. Bien hecho suele ser más fluido: cuando el riesgo es bajo, la verificación es invisible (una passkey, un dispositivo que cumple pasan en silencio); la fricción aparece solo cuando el riesgo sube. La confianza se gana por petición, no se abole.
• “Es un proyecto que terminas.” Zero Trust es un viaje medido por madurez, no una casilla que marcar. El CISA Zero Trust Maturity Model lo enmarca en pilares (identidad, dispositivos, redes, aplicaciones, datos) que avanzan de tradicional a óptimo con el tiempo. Lo maduras; no lo completas.
• “Zero Trust reemplaza el firewall / VPN por completo desde el día uno.” Cambia su rol y reduce la dependencia de ellos, pero la adopción es incremental — segmentas, agregas acceso identity-aware y retiras la confianza plana de red gradualmente, no en un solo corte.

Micro-segmentación y el blast radius

El “asume la brecha” necesita un mecanismo, y la micro-segmentación es el principal en la capa de red y workload. El viejo modelo era una red interna plana: rompe una máquina y podías alcanzar miles. La micro-segmentación divide el entorno en zonas pequeñas e individualmente vigiladas — idealmente hasta por-workload — de modo que alcanzar una cosa no concede alcance a la siguiente.

El efecto es encoger el blast radius. Un atacante que compromete un solo servidor descubre que el movimiento lateral — la técnica detrás de casi toda gran brecha — queda bloqueado por política en cada salto, y cada salto debe pasar por sí mismo comprobaciones de identidad y postura. Combinada con el mínimo privilegio en las identidades, la segmentación convierte un punto de apoyo de una plataforma de lanzamiento en un callejón sin salida. Este es el complemento del lado de red a todo lo que hace el plano de control de identidad: la identidad decide quién, la segmentación limita hasta dónde.

Zero Trust para workloads e identidades no humanas

Zero Trust se enseña normalmente con un usuario humano en mente, pero la mayor parte del acceso en un sistema moderno es máquina a máquina — servicios, contenedores, funciones, scripts y cada vez más agentes IA llamándose entre sí. Estas identidades no humanas (NHIs) ahora superan por mucho a los humanos, y los mismos principios aplican sin excepción: cada llamada de servicio se autentica y autoriza de forma explícita, se concede con mínimo privilegio, y nunca se confía solo por originarse “dentro del clúster”.

En la práctica esto significa que los workloads obtienen identidades fuertes y verificables en vez de secretos compartidos en archivos de configuración — estándares como SPIFFE/SPIRE, workload identity de nube (managed identities, IAM roles) y credenciales de vida corta y rotadas automáticamente en vez de API keys de larga vida. El Trust Algorithm evalúa la identidad y postura de un servicio igual que la de un usuario. Este es el puente al dominio de PAM & NHI más adelante en el currículo: a medida que la autenticación humana se endurece, los atacantes pivotan a las identidades de máquina más blandas y numerosas — y Zero Trust tiene que cubrirlas también, o tiene un hueco justo donde está el volumen.

Dónde se sitúa Zero Trust entre los frameworks

Zero Trust no es una isla — se conecta con la guía a la que los equipos de seguridad ya responden, y nombrar esos enlaces ayuda a posicionarlo ante el liderazgo. NIST SP 800-207 es la referencia arquitectónica; el CISA Zero Trust Maturity Model lo convierte en pilares y etapas de madurez para evaluación práctica; y el mandato federal de EE. UU. (OMB M-22-09) empujó a las agencias hacia cronogramas de Zero Trust, que es en gran parte por qué el término se volvió mainstream. La DoD Zero Trust Reference Architecture agrega un desglose de capacidades de grado defensa.

También complementa en vez de reemplazar los frameworks del currículo más amplio. Zero Trust es una estrategia para el acceso; NIST CSF enmarca todo el programa de riesgo alrededor de él; ISO 27001 gobierna el sistema de gestión; el mínimo privilegio y la segmentación aparecen en casi todo catálogo de controles (CIS Controls, PCI-DSS). En la práctica, adoptar Zero Trust te da evidencia para muchos requisitos de control de acceso a la vez — un punto que vale hacerle a un dueño de cumplimiento, porque reencuadra el trabajo de “otro proyecto de seguridad” a “una postura que satisface obligaciones que ya tienes”. El mismo despliegue de MFA, la revisión de mínimo privilegio y el monitoreo continuo que avanzan tu madurez también producen evidencia de auditoría para requisitos de control de acceso, autenticación y logging de varios de esos frameworks simultáneamente — un solo cuerpo de trabajo, muchas casillas marcadas.

Un ejemplo trabajado: asume la brecha un lunes

Haz concreto el “asume la brecha”. Un atacante hace phishing a un empleado, Daniel, y roba una sesión válida. Dos mundos responden distinto.

• En el modelo de perímetro: la sesión de Daniel estaba en la VPN corporativa, así que el atacante está ahora dentro, tratado como confiable. Se mueve lateralmente por una red plana, alcanza sistemas que Daniel nunca usó, y escala — porque estar dentro significaba ser confiable. La única sesión robada se vuelve un compromiso amplio.
• En un modelo Zero Trust: cada recurso que el atacante intenta alcanzar se reevalúa por petición. El dispositivo en el que está no es la laptop gestionada y que cumple de Daniel, así que las comprobaciones de postura fallan o fuerzan step-up. Su comportamiento — nuevas ubicaciones, recursos inusuales, horarios raros — diverge de su perfil, subiendo el puntaje de riesgo y disparando re-autenticación que el atacante no puede satisfacer. El mínimo privilegio significa que incluso el acceso legítimo de Daniel es estrecho, y la micro-segmentación bloquea el movimiento lateral hacia cualquier cosa que él no usara ya. La sesión robada queda contenida cerca de donde empezó, y la telemetría se enciende para el SOC.

Nada aquí asume que la brecha fue prevenida — asume que ocurrió y pregunta hasta dónde llega. Ese es todo el punto de la estrategia: no un muro más alto, sino un edificio donde irrumpir en un cuarto no abre el resto.

Trampas más allá de los mitos

Incluso los equipos que entienden Zero Trust en principio tropiezan con trampas operativas recurrentes. Conocerlas de antemano es la mayor parte de evitarlas:

• Reacción a la fricción. Atornilla verificación en todos lados de golpe y los usuarios se rebelan, luego el liderazgo retrocede y el programa se estanca. El arreglo es la postura adaptativa: haz el acceso de bajo riesgo invisible (dispositivo que cumple + passkey pasa en silencio) para que la fricción aparezca solo cuando el riesgo sube. Zero Trust bien hecho se siente menos, no más.
• Romper el acceso legítimo. Políticas agresivas que malinterpretan la postura o el contexto pueden bloquear a usuarios y workloads reales — un outage autoinfligido. Despliega en modo monitor-primero (registra lo que sería bloqueado) antes de aplicar, y escalona la aplicación gradualmente.
• Ignorar las identidades no humanas. Los equipos endurecen el login humano y dejan las cuentas de servicio, API keys e identidades de máquina en la vieja confianza implícita — el siguiente movimiento del atacante. Las NHIs deben estar en alcance desde el inicio.
• Proliferación de políticas. Las reglas por-recurso, por-contexto se multiplican en una maraña inmanejable que nadie entiende del todo — lo que se vuelve su propio riesgo. Centraliza la política, exprésala como código donde sea posible, y revísala, para que el Trust Algorithm siga siendo comprensible.
• Pensamiento tool-first. Comprar productos antes de definir principios, inventario y cimientos de identidad rinde gasto sin postura — la falla contra la que advirtieron los mitos, vista desde el lado operativo.
• Puntos ciegos de cobertura. Aplicar Zero Trust a las relucientes apps nuevas de nube mientras los sistemas legacy, las conexiones de terceros y el shadow IT conservan su vieja confianza plana. Los atacantes van directo al resto desprotegido, así que el inventario del primer paso debe ser honesto sobre lo que no está cubierto aún.
• Declarar victoria. Tratar un hito como la meta final y dejar que la postura derive. Zero Trust se mantiene continuamente o decae.

El hilo común: Zero Trust falla no en el concepto sino en la disciplina de despliegue — fricción adaptativa, monitorear-antes-de-aplicar, alcance completo de identidad, política manejable y atención sostenida.

Recapitulación

Zero Trust es la estrategia que le da sentido al resto de este módulo:

1. Reemplaza la confianza de perímetro con verificación explícita por petición — principios: nunca confíes siempre verifica, asume la brecha, mínimo privilegio (NIST SP 800-207).
2. Su arquitectura es un PEP (aplica) y un PDP corriendo un Trust Algorithm sobre señales de los PIPs — decisión y aplicación, limpiamente separadas.
3. El Continuous Adaptive Trust reevalúa la confianza en toda la sesión, convirtiendo el “siempre verifica” de un momento de login en una constante — potenciado por señales de comportamiento, step-up, sesiones cortas y revocación.
4. La identidad es el plano de control: neutralizada la red, la identidad decide el acceso, así que la autenticación fuerte, el SSO y la higiene de sesión son el cimiento sobre el que se para Zero Trust.
5. Es una estrategia y un viaje, no un producto — todos los mitos colapsan en esa verdad.

Tres preguntas para autoevaluarte

1. Mapea el módulo completo: para una sola petición de “transferir dinero”, nombra a qué componente Zero Trust (PEP, PDP, Trust Algorithm, un PIP) corresponde cada uno de estos — el resultado de MFA del proveedor de identidad, el reverse proxy frente a la API, el puntaje de riesgo, y el feed de cumplimiento del dispositivo.
2. Un proveedor le presenta a tu CISO una “plataforma Zero Trust” que es esencialmente un appliance de micro-segmentación de red. Da tres preguntas que expongan si adoptarlo solo entregaría realmente Zero Trust.
3. Explica, usando el Continuous Adaptive Trust, cómo un sistema Zero Trust debería reaccionar distinto a una sesión de SSO robada que un modelo de perímetro. ¿Qué controles de más temprano en este módulo hacen posible esa reacción?

Ejercicios prácticos

1. Localiza los componentes en un stack real. Para un sistema que conozcas (incluso una cuenta cloud personal), identifica qué hace de PEP (la compuerta), qué hace de PDP (la decisión de política), y qué señales alimentan la decisión (MFA, dispositivo, ubicación). Bosqueja la ruta de la petición.
2. Puntúa tu madurez de identidad. Usando el pilar de Identidad del CISA Zero Trust Maturity Model, ubica a una organización que conozcas en la escala tradicional → inicial → avanzada → óptima para cobertura de MFA, mínimo privilegio y evaluación continua. Nombra el único siguiente paso de mayor impacto.
3. Reescribe una regla de perímetro como Zero Trust. Toma una regla legacy como “cualquiera en la VPN puede alcanzar la wiki interna”. Reescríbela como una política por petición basada en identidad y dispositivo, y di qué señales de PIP necesitaría tu Trust Algorithm para hacerla cumplir.