¿Qué es Zero Trust Network Access (ZTNA)?

Dar acceso remoto a una aplicación no debería implicar abrir camino a todo lo que la rodea. Zero Trust Network Access, o ZTNA, permite autorizar conexiones a recursos concretos según identidad y políticas de acceso. El objetivo es reducir el acceso concedido a lo necesario, en vez de confiar en una persona o un dispositivo únicamente porque están dentro de una red.

Eso requiere más trabajo que cambiar el nombre de una VPN. Hay que saber quién solicita acceso, a qué recurso y bajo qué condiciones. ZTNA aporta mecanismos para aplicar esa decisión, pero su resultado depende del diseño de las políticas, de las señales disponibles y de la protección del propio servicio.

La ubicación no concede confianza automática

Zero Trust es un enfoque de seguridad que evita conceder confianza implícita por ubicación de red o propiedad de un dispositivo. NIST lo describe como una arquitectura orientada a proteger recursos, no únicamente segmentos. ZTNA aplica parte de ese enfoque al acceso, y no equivale por sí solo a desplegar toda una arquitectura Zero Trust.

Imaginemos una colaboradora externa que necesita consultar una aplicación de facturación. Su trabajo no requiere descubrir otros servidores ni alcanzar todas las subredes internas. La autorización puede limitarse a esa aplicación y a su identidad, con condiciones adicionales cuando la solución y el entorno permitan evaluarlas. Es un ejemplo de alcance mínimo, no una garantía automática de cualquier producto.

-InfraCrew dice: Para consultar una factura no debería hacer falta una visita guiada por todas las subredes.-

La identidad suele comprobarse mediante un IdP, el proveedor que autentica a las personas y aporta información sobre ellas. A esa señal pueden añadirse datos del dispositivo, del contexto o del riesgo. Autenticarse y estar autorizado son decisiones distintas: acreditar quién eres no implica tener permiso para cualquier recurso.

De la política a una conexión concreta

Una implementación necesita un mecanismo que decida si se concede el acceso y otro que lo haga cumplir. NIST distingue funciones de decisión y aplicación de políticas. El punto de control debe mediar el acceso al recurso protegido, en vez de limitarse a mostrar una pantalla de inicio de sesión mientras queda una ruta alternativa abierta.

El modo de conexión varía: hay soluciones con agentes en el dispositivo, acceso a aplicaciones web mediante navegador y conectores próximos a los servicios. Compatibilidad y cobertura dependen del producto y del protocolo. Una aplicación web sencilla, una sesión administrativa y un sistema antiguo con dependencias poco documentadas no plantean el mismo trabajo.

También importa cuándo se revisan las condiciones. Una solución puede reevaluar acceso según cambios de identidad, sesión o estado del dispositivo. «Verificación continua» necesita una frecuencia y unas acciones concretas, no solo una frase en la presentación. Hay que saber qué ocurre si se revoca un permiso durante una sesión ya abierta.

La comparación con VPN necesita matices

Una VPN proporciona conectividad mediante un túnel; el alcance real depende de rutas, segmentación, autenticación y reglas. No todas las VPN dan acceso libre a toda la red. La diferencia útil al evaluar ZTNA es si permite expresar y aplicar acceso por aplicación e identidad con la granularidad que necesita la organización.

En nuestro ejemplo de facturación, conviene comprobar tanto que la colaboradora entra en el servicio autorizado como que no accede a otros recursos. La prueba negativa forma parte del resultado, igual que retirar el permiso y verificar qué pasa con las sesiones. Conceder acceso es solo la mitad fácil de una política.

-InfraCrew dice: El botón «permitir» suele estar muy bien probado. El de «ya no» también merece una demostración.-

Puede haber coexistencia entre ZTNA y VPN durante una transición o por necesidades distintas. El catálogo de aplicaciones determina el alcance de la migración, especialmente cuando hay protocolos especiales, servicios compartidos o tareas de administración. Cambiar de herramienta sin inventariar dependencias puede trasladar los problemas de acceso al nuevo sistema.

Lo que sigue siendo responsabilidad del equipo

ZTNA no corrige una aplicación vulnerable ni decide por nosotros sus permisos internos. Una persona autorizada a entrar todavía puede tener privilegios excesivos dentro del servicio. El acceso a la aplicación y la autorización dentro de ella deben encajar, junto con actualizaciones, protección del dispositivo y registro de actividad.

La disponibilidad también cambia de dependencias. Si el IdP, los conectores o el servicio de aplicación de políticas fallan, el acceso puede verse afectado. Hay que definir el comportamiento ante fallos y una recuperación controlada, sin convertir una excepción permanente en la vía habitual de entrada. Esto debe probarse antes de depender de ella en una incidencia.

Un despliegue razonable empieza con un recurso y usuarios representativos, documenta condiciones y revisa los eventos de acceso. Después amplía cobertura con evidencia. La medida del éxito es conceder el acceso necesario y retirar el que sobra de forma comprobable, no contar cuántas veces aparece «Zero Trust» en el diagrama del proveedor.

-InfraCrew dice: La confianza cero funciona mejor cuando el inventario de aplicaciones supera el cero.-

Diccionario de la Crew

Zero Trust — Enfoque que no concede confianza implícita por estar dentro de una red y evalúa el acceso a recursos según políticas y contexto.

IdP — Proveedor de identidad que autentica usuarios y aporta información utilizada para decidir su acceso.