Zero trust

El modelo tradicional tenía un perímetro. Dentro, los sistemas confiaban entre sí; fuera, no. Ese modelo se rompió por motivos que hoy resultan evidentes: la gente trabaja desde cualquier sitio, las cargas de trabajo corren en centros de datos de proveedores, los proveedores necesitan acceso, y un solo correo de phishing mete a un atacante dentro de la zona de confianza, donde ya no se comprueba nada más.

El zero trust sustituye la ubicación por la evaluación. Cada petición se autentica, se autoriza contra una política y se evalúa con el contexto disponible: qué identidad, en qué dispositivo, en qué estado, hacia qué recurso y para hacer qué. La decisión se toma por petición y no por sesión, de manera que el acceso se pueda retirar cuando el contexto cambia.

Arquitectónicamente se describe como un punto de decisión de política que toma la determinación y un punto de aplicación de política que la impone, situado delante del recurso. El NIST SP 800-207 es el documento de referencia y merece la pena leerlo precisamente porque es neutral respecto a fabricantes y describe las propiedades en lugar de los productos.

Tres principios sostienen casi todo el peso práctico. Verificar de forma explícita, cada vez, en lugar de heredar la confianza de un paso anterior. Conceder mínimo privilegio, incluido el acceso justo a tiempo y en la cantidad justa en lugar de derechos permanentes. Y asumir la brecha: diseñar de forma que comprometer un componente no implique el resto, lo que en la práctica significa segmentación, alcances de credencial pequeños y cifrado entre servicios.

El fallo más frecuente es comprarlo. No existe ningún producto zero trust, y la plataforma zero trust de un fabricante es un componente: un proveedor de identidad, un proxy de acceso, un servicio de conformidad de dispositivo, una herramienta de microsegmentación. Cada uno es útil. Ninguno constituye una arquitectura, y los parques que compraron uno y dieron el programa por terminado han mejorado por lo general el acceso remoto y no han cambiado nada del interior de su centro de datos.

El segundo es quedarse en el usuario. El acceso humano recibe identidad, comprobaciones de dispositivo y política condicional, y el tráfico entre servicios dentro del parque sigue funcionando exactamente igual que antes: confianza implícita por estar en la red, credenciales estáticas, ninguna autenticación entre servicios. Ahí es donde opera un intruso después del primer punto de apoyo, así que un programa que solo cubre a las personas no ha abordado la fase de la intrusión que más importa.

El tercero es la lista de excepciones. Aplicaciones heredadas que no saben autenticarse de forma moderna, appliances que solo hablan protocolos antiguos, la herramienta de un proveedor que necesita una ruta plana. Cada excepción se negocia, se documenta y se vuelve permanente, y el conjunto de excepciones acaba describiendo una pequeña red clásica dentro de la nueva. En los encargos, las excepciones son donde trabajamos.

El cuarto es un motor de políticas sin contexto que merezca la pena. Evaluar cada petición solo vale si la evaluación lleva señal dentro. Cuando la política es «usuario autenticado, cualquier dispositivo, cualquier ubicación», tienes una comprobación por petición que siempre dice que sí, que es más infraestructura y la misma seguridad.

Se comparan como si fueran tres opciones para el mismo trabajo. Una es una arquitectura y dos son mecanismos de acceso.

Lo importante son las dos últimas filas. El ZTNA es una mejora genuina sobre una VPN porque elimina la ruta de red, y es un punto de aplicación dentro de una arquitectura que además tiene que cubrir el tráfico entre servicios, el acceso administrativo y los datos. Sustituir una VPN por ZTNA y dar el programa por terminado es la versión más frecuente de este proyecto, y deja el parque interno exactamente como estaba.

Tratarlo como una compra. Es un principio de diseño aplicado a identidad, dispositivos, red, cargas de trabajo y datos, y el trabajo consiste en su mayor parte en no comprar nada.

Ignorar el tráfico entre máquinas. La mayor parte del tráfico de un parque es entre servicios, y la mayoría de los programas de zero trust no lo tocan nunca.

Construir políticas sin señal. Una política condicional que acepta cualquier dispositivo desde cualquier sitio es una casilla marcada.

Excepciones permanentes. Toda excepción necesita un responsable, un control compensatorio y una fecha. Sin esas tres cosas, la excepción es la arquitectura.

Confundir cifrado con autenticación. Una conexión TLS que no verifica al cliente no demuestra nada sobre quién llama, y por eso existe mTLS.

Empieza por donde empiezan las intrusiones. La identidad primero: un solo proveedor, factores ligados al origen, política condicional con el estado del dispositivo como señal de verdad. Ese único paso retira más riesgo que cualquier cambio de red, porque el perímetro actual es el plano de identidad.

Después retira el acceso permanente. Derechos administrativos concedidos justo a tiempo y que caducan, en lugar de pertenencia permanente a grupos privilegiados, cambian lo que vale una cuenta comprometida. Esto suele ser más difícil políticamente que técnicamente.

Después trabaja hacia dentro. Microsegmentación entre cargas de trabajo, autenticación mutua entre servicios en lugar de listas de permitidos por dirección, y credenciales de carga de trabajo de vida corta en vez de claves estáticas. Empieza por el segmento que más dolería y ve ampliando, porque un programa que intenta abarcar el parque entero de una vez no termina.

Mídelo como alcanzabilidad y no como madurez. La pregunta honesta es: desde un puesto de trabajo comprometido, ¿hasta dónde se llega hoy sin ninguna credencial adicional? Responderla con una prueba, al principio y otra vez un año después, es una métrica mucho mejor que una puntuación de madurez, y es la misma pregunta que responde un encargo interno.

No auditamos el zero trust como una lista de comprobación. Probamos la propiedad que afirma: si un punto de apoyo en un sitio da acceso a otro sin una decisión explícita evaluada por política. El informe describe hasta dónde llegamos y desde dónde, qué decisiones se reevaluaron y cuáles se heredaron.

Las excepciones son la parte más útil del entregable. Enumeramos los caminos donde la confianza sigue siendo implícita: protocolos heredados, segmentos planos, cuentas de servicio con credenciales estáticas, appliances fuera del plano de política. Sobre eso se puede actuar, y es invisible para una evaluación de madurez que lee documentos de política.

La severidad se escribe contra el alcance. Una excepción que permite a una aplicación heredada autenticarse de forma débil es un hallazgo moderado. La misma excepción sobre un segmento que contiene el directorio o la infraestructura de copias es crítica.

Si la arquitectura aguanta cuando alguien ya está dentro es exactamente lo que se propone establecer al probar desde una posición dentro de la red.

¿Se puede comprar zero trust? No. Se pueden comprar componentes que lo apliquen: un proveedor de identidad, un proxy de acceso, conformidad de dispositivo, herramientas de segmentación. La arquitectura es cómo se combinan y qué decisiones se reevalúan, y esa parte es tuya.

¿Zero trust es lo mismo que sustituir nuestra VPN? No, aunque es por donde empiezan casi todos los programas. Retirar la ruta de red a favor de un acceso por aplicación es una mejora real y cubre un camino. Siguen quedando el tráfico entre servicios, el acceso administrativo y el acceso a los datos.

¿Por dónde deberíamos empezar? Por la identidad, con factores ligados al origen y una política condicional que use el estado del dispositivo. Aborda la vía que toman la mayoría de las intrusiones, y todos los pasos posteriores dependen de tener un plano de identidad único y autorizado.

¿Cómo sabemos que está funcionando? Probándolo. Desde un puesto de trabajo comprometido, establece hasta dónde se llega sin una decisión explícita adicional. Ese número, medido ahora y otra vez más adelante, es evidencia. Una puntuación de madurez es una opinión.