Zero Trust sin marketing:

qué significa de verdad y por dónde se empieza

Arquitectura de seguridad  |  unfantasmaenelsistema.com

Pocos términos de seguridad han sido tan exprimidos por el departamento comercial como «Zero Trust». En la práctica se ha convertido en una etiqueta que se pega a cortafuegos, VPN, proxies de identidad y casi cualquier producto de red, hasta el punto de que muchos responsables de IT lo asocian con «otra cosa que hay que comprar». La idea original, sin embargo, no es un producto ni una tecnología concreta: es un cambio en la pregunta de partida.

La arquitectura de seguridad tradicional confía en la ubicación de red: si estás dentro del perímetro —en la LAN, detrás del cortafuegos, conectado por la VPN corporativa— se te trata como de confianza. Zero Trust parte de lo contrario: la posición en la red no dice nada sobre si una petición es legítima, así que cada acceso se verifica de forma explícita, con la identidad, el estado del dispositivo y el contexto como criterio, no la dirección IP de origen.

1. El problema que Zero Trust intenta resolver

El modelo clásico se suele describir como «castillo y foso»: un perímetro fuerte alrededor de la red corporativa y poco control una vez dentro. Funcionaba razonablemente cuando las aplicaciones vivían en el centro de datos de la empresa, los empleados trabajaban desde oficinas cableadas y los dispositivos eran de la organización.

Ese modelo se ha roto por varios sitios a la vez: las aplicaciones están en SaaS y en varias nubes, la gente trabaja desde casa y desde el móvil, entran proveedores y contratistas, y los dispositivos personales acceden a recursos de trabajo. El «dentro» ya casi no existe como frontera útil. Y cuando un atacante consigue un punto de apoyo —un portátil comprometido, unas credenciales robadas por phishing— la red plana interior le permite moverse de lado con facilidad, porque todo lo de dentro confía en todo lo demás de dentro.

Zero Trust reacciona a esos dos hechos: el perímetro ya no delimita nada claro, y una vez producida la brecha inicial, la confianza implícita interior es justo lo que amplifica el daño.

2. La definición seria: NIST SP 800-207

El documento de referencia es la publicación especial NIST SP 800-207 (2020), que define Zero Trust como un conjunto de principios de diseño, no como una arquitectura única. Sus ideas centrales se pueden resumir así:

• Toda fuente de datos y servicio de computación se considera un recurso que hay que proteger, no solo los servidores «importantes»
• Toda comunicación se asegura con independencia de dónde esté la red: estar en la LAN no otorga confianza
• El acceso a un recurso se concede por sesión, y solo tras evaluar la petición concreta
• La decisión de acceso es dinámica: depende de la identidad, del estado del dispositivo, del comportamiento y de otros atributos de contexto (hora, ubicación, sensibilidad del recurso)
• La organización mide de forma continua la integridad y la postura de seguridad de todos sus activos: ningún dispositivo es de confianza permanente
• La autenticación y la autorización se aplican de forma estricta antes de permitir la conexión, y se reevalúan durante la sesión
• Se recopila toda la telemetría posible sobre el estado de la red y los accesos, y se usa para mejorar las políticas

El modelo lógico de NIST separa dos planos. El plano de control contiene el motor de políticas (Policy Engine) y el administrador de políticas (Policy Administrator), que deciden si una petición se concede. El plano de datos es el punto de aplicación (Policy Enforcement Point) que se sitúa delante del recurso y ejecuta esa decisión. El PEP puede ser un proxy, un gateway, un agente en el endpoint o el propio servicio; lo importante es que ninguna petición llega al recurso sin pasar por él.

3. «Assume breach»: diseñar dando por hecho que ya han entrado

El principio operativo que más cambia el diseño es assume breach: se asume que el atacante ya está dentro de algún punto de la red, o que lo estará. En lugar de concentrar el esfuerzo en impedir la entrada, se diseña para limitar lo que un intruso puede hacer una vez dentro.

En la práctica eso se traduce en tres consecuencias de diseño. Primero, minimizar el radio de explosión: si cae una cuenta o un equipo, que el acceso que eso concede sea lo más pequeño posible. Segundo, verificar de forma explícita y repetida: no basta con autenticar al inicio de la jornada; cada petición sensible se vuelve a evaluar. Tercero, cifrar y autenticar el tráfico interno, porque la red local se trata como hostil igual que internet.

4. Los pilares en la práctica

4.1 Identidad fuerte

La identidad es el nuevo perímetro. Eso implica un proveedor de identidad centralizado (IdP) con inicio de sesión único (SSO), MFA resistente al phishing —idealmente passkeys o llaves FIDO2 en lugar de códigos por SMS— y políticas de acceso condicional que evalúen el contexto de cada inicio de sesión. Las cuentas de servicio y las identidades de máquina entran en el mismo marco: credenciales de vida corta, rotación automática y nada de secretos compartidos eternos.

4.2 Salud del dispositivo

Antes de conceder acceso a un recurso sensible, la política comprueba el estado del dispositivo que lo pide: si está inscrito en la gestión corporativa, si tiene el disco cifrado, el EDR activo, el sistema al día y sin alertas abiertas. Un dispositivo que no cumple obtiene acceso reducido o nulo, no el mismo que uno conforme.

4.3 Mínimo privilegio y acceso just-in-time

Cada identidad tiene solo los permisos que necesita para su función, y los permisos elevados se conceden de forma temporal y con registro (acceso just-in-time), no de forma permanente. Las revisiones de acceso periódicas retiran lo que ya no se usa. Esto reduce directamente lo que un atacante gana al comprometer una cuenta cualquiera.

4.4 Microsegmentación

En lugar de una red interna plana, el tráfico se divide en segmentos pequeños con políticas explícitas sobre quién habla con quién. Puede hacerse a nivel de red (VLAN, cortafuegos internos), a nivel de carga de trabajo (políticas de red en Kubernetes, cortafuegos de host) o mediante un plano de identidad que autoriza cada flujo. El objetivo es que comprometer un servidor no dé visibilidad ni acceso al resto del centro de datos.

4.5 Telemetría y evaluación continua

Todo lo anterior necesita datos: registros de autenticación, de acceso a recursos, de red, de endpoint. Esa telemetría alimenta la detección y también el propio motor de políticas, que puede endurecer o revocar el acceso cuando aparece una señal anómala (un inicio de sesión desde un país imposible, un dispositivo que de repente falla el chequeo de postura).

5. BeyondCorp: el caso real de Google

El ejemplo práctico más citado es BeyondCorp, la iniciativa con la que Google, a partir de 2011 y tras el incidente conocido como Operación Aurora, movió a sus empleados fuera de la VPN. La premisa: una aplicación interna no debe ser más accesible por estar el usuario «en la red de Google» que estándolo desde una cafetería.

En BeyondCorp el acceso a cada aplicación pasa por un proxy de acceso que consulta, en cada petición, un motor que combina la identidad del usuario y la información del dispositivo (extraída de un inventario que registra su estado y su nivel de confianza). Si usuario y dispositivo cumplen la política para ese recurso concreto, el proxy deja pasar la petición; si no, la corta. No hay una red «de confianza»: el mismo camino sirve desde dentro y desde fuera.

6. ZTNA frente a la VPN tradicional

ZTNA (Zero Trust Network Access) es la categoría de producto que aplica estas ideas al acceso remoto, y es donde más se solapa el marketing con el concepto. La diferencia real con una VPN clásica está en el modelo de acceso.

Una VPN tradicional, una vez autenticado, te coloca en la red: recibes una IP interna y, salvo reglas de cortafuegos adicionales, tienes conectividad hacia muchos recursos. ZTNA no te da acceso a la red, sino a aplicaciones concretas, una por una, tras evaluar identidad y dispositivo, y normalmente sin que las aplicaciones queden expuestas ni siquiera a nivel de descubrimiento (modelo de «internet oscuro»: el recurso no responde a quien no está autorizado).

Esto no significa que la VPN esté muerta. Para administrar sistemas, para protocolos que no son web y para laboratorios propios, un túnel bien segmentado sigue siendo razonable —de hecho lo tratamos en el artículo sobre montar tu propia VPN con WireGuard—. El matiz de Zero Trust es no confiar en el acceso solo porque venga por el túnel: también ahí aplican identidad, dispositivo y segmentación.

7. Qué NO es Zero Trust

• No es un producto. Ningún fabricante te «instala Zero Trust». Los productos aportan piezas (IdP, ZTNA, microsegmentación, EDR); la arquitectura es la forma en que las combinas y las políticas que defines
• No es solo la capa de red. Sustituir la VPN por ZTNA y no tocar identidad, privilegios ni telemetría es quedarse a un tercio del camino
• No es MFA y ya está. El MFA es un cimiento necesario, pero Zero Trust es la evaluación continua y contextual del acceso, no un segundo factor en el login
• No es un proyecto con fecha de fin. Es un modelo operativo: las políticas se revisan, la telemetría se afina y el alcance se amplía de forma continua
• No exige tirar todo lo actual. Se construye por encima de lo que ya tienes (directorio, EDR, cortafuegos) de forma incremental

8. Hoja de ruta realista para una pyme

Zero Trust no exige el presupuesto de Google. Para una organización pequeña o mediana, el orden que más reduce riesgo por euro invertido suele ser este:

Las tres primeras fases se pueden abordar con herramientas que muchas pymes ya pagan dentro de su suite de correo y ofimática. Las fases 5 a 7 son más de proceso que de gasto: revisar accesos, definir zonas y mirar los registros con regularidad. Lo importante es el orden: empezar por microsegmentar la red sin haber puesto MFA ni SSO es optimizar la última milla mientras la puerta principal sigue abierta.

Conclusión

Zero Trust no es una compra ni una casilla que se marca: es dejar de conceder confianza por la posición en la red y empezar a concederla, de forma explícita y revisable, según quién pide el acceso, desde qué dispositivo y en qué contexto. El NIST SP 800-207 lo formaliza como principios de diseño, y el caso BeyondCorp demuestra que es viable a gran escala, pero también que lleva tiempo.

Para una organización que empieza, el consejo práctico es resistir la tentación de comprar la caja que promete «Zero Trust llave en mano» y, en su lugar, avanzar por fases: inventario, MFA en todo, identidad centralizada, acceso condicional, mínimo privilegio, segmentación y, cerrando el ciclo, telemetría que alimente la mejora continua. Cada fase reduce riesgo por sí sola, y esa es precisamente la ventaja de entenderlo como arquitectura y no como producto.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)