Zero Trust explicado: ZTNA en lugar de VPN clásico

Zero Trust no significa que ya no se confíe en nadie. Significa que el acceso ya no se concede de forma general solo porque un usuario esté en la red interna, en la VPN o en una ubicación conocida. Cada intento de acceso se comprueba de forma consciente: ¿quién accede? ¿Desde qué dispositivo? ¿A qué aplicación? ¿Bajo qué condiciones?

Zero Trust Network Access, o ZTNA, es una implementación concreta de esta idea para remote access y aplicaciones privadas. En lugar de abrir toda una red mediante VPN, un usuario recibe acceso solo a las aplicaciones o recursos previstos para su rol.

Este artículo explica los fundamentos de forma deliberadamente neutral respecto al fabricante. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access y otras soluciones aplican principios similares de forma diferente. Por eso, la primera decisión no es el producto, sino el modelo de acceso.

Clasificar Zero Trust y ZTNA

Zero Trust es una arquitectura de seguridad. ZTNA es una ruta técnica de acceso dentro de esa arquitectura.

Zero Trust es un principio

Las redes clásicas suelen trabajar con una suposición implícita: dentro es más confiable que fuera. Hoy esa suposición es peligrosa. Los usuarios trabajan de forma móvil, las aplicaciones están en SaaS, centros de datos y cloud, los dispositivos cambian constantemente de ubicación y las credenciales comprometidas son un escenario realista.

Zero Trust desplaza el foco de los límites de red hacia identidad, dispositivo, aplicación, datos y contexto. NIST describe Zero Trust como una arquitectura que reduce la confianza implícita y evalúa el acceso por solicitud. En la práctica, un inicio de sesión correcto ya no basta.

ZTNA es acceso a recursos concretos

ZTNA sustituye accesos amplios a la red por acceso basado en recursos. Un usuario no ve automáticamente una subred completa, sino solo las aplicaciones para las que encaja una política.

Recursos ZTNA típicos son:

• aplicaciones web internas,
• portales de administración,
• accesos RDP o SSH por rutas controladas,
• aplicaciones TCP individuales,
• accesos de desarrollo, soporte o partners,
• aplicaciones SaaS con control de acceso adicional.

Así el remote access se controla con más granularidad. Una cuenta comprometida no debería poder alcanzar inmediatamente toda la red interna.

Por qué ZTNA es diferente de VPN

VPN no es automáticamente malo. Muchos entornos siguen necesitando site-to-site VPN, admin VPN, protocolos especiales o accesos de emergencia. La diferencia está en el modelo de confianza.

VPN suele abrir una red

Un remote access VPN clásico conecta un dispositivo con una red interna. Después, routing, reglas de firewall, DNS y segmentación deciden qué es accesible. Si el entorno está construido limpiamente, puede funcionar. En la práctica, las redes VPN suelen ser demasiado amplias, históricas o difíciles de revisar.

Riesgos típicos:

• Los usuarios reciben acceso a más sistemas de los necesarios.
• Grupos VPN antiguos permanecen activos.
• Split tunnel, DNS y rutas no están claros.
• Malware en un cliente VPN puede alcanzar objetivos internos.
• Accesos admin usan el mismo túnel que accesos de usuario.

ZTNA comprueba más cerca de la aplicación

ZTNA decide por aplicación o recurso. Una política puede considerar grupo de usuarios, MFA, dispositivo, ubicación, riesgo, estado del cliente y otras condiciones. Solo cuando las condiciones coinciden se permite el acceso exactamente a ese recurso.

Esto reduce la superficie de ataque, pero no sustituye una aplicación segura. Una aplicación insegura sigue siendo insegura aunque esté detrás de ZTNA. ZTNA controla el acceso, no automáticamente la aplicación.

Componentes de un buen entorno Zero Trust

Zero Trust es débil si se introduce solo como una nueva herramienta de acceso. El valor aparece cuando varios componentes encajan.

Identidad y MFA

La identidad es el punto de entrada más importante. Usuarios, grupos, roles y cuentas externas deben mantenerse limpios. MFA debería ser obligatorio para accesos críticos. En entornos Microsoft, Microsoft Entra ID suele ser la fuente central de identidad; en otros entornos, otros Identity Providers pueden asumir el mismo papel.

El offboarding también es importante. Cuando un usuario abandona la empresa, el acceso debe desaparecer no solo en una aplicación, sino en la identidad central y en todas las políticas relevantes.

Dispositivo y contexto

ZTNA se vuelve más fuerte cuando no solo se evalúa el usuario, sino también el dispositivo. Según la solución, sistema operativo, estado del dispositivo, certificado, estado EDR, estado de gestión, ubicación o riesgo pueden influir en la decisión.

Esto es especialmente relevante para:

• dispositivos privados,
• proveedores externos,
• accesos admin privilegiados,
• acceso a sistemas financieros, HR o producción,
• dispositivos sin estado de protección actual.

Gateway, connector o servicio cloud

ZTNA necesita una ruta de datos entre usuario y aplicación. Según el proveedor, hay gateways, connectors, túneles o cloud PoPs. Esta parte decide dónde entra el tráfico, quién opera la ruta de datos y qué reglas DNS, certificados y firewall son necesarias.

Cloudflare suele trabajar con Cloudflare Tunnel y Access Policies. Sophos ZTNA usa Sophos Central, ZTNA Gateways y políticas de recursos. La arquitectura es diferente, pero la pregunta básica sigue igual: ¿cómo llega un usuario de forma controlada a la aplicación sin abrir toda la red?

Políticas, logging y operación

Una política ZTNA debe seguir siendo comprensible más adelante. Por eso conviene documentar nombres, grupos, condiciones y excepciones. El logging es obligatorio, porque si no, no se reconoce si una política es demasiado amplia, si se bloquea a usuarios o si un acceso se usa de forma inesperadamente frecuente.

Cuándo tiene sentido ZTNA

ZTNA encaja especialmente bien cuando aplicaciones individuales deben ser accesibles de forma controlada. No es un fin en sí mismo ni un sustituto automático de toda conexión.

Buenos casos de uso

ZTNA suele tener sentido para:

• aplicaciones web internas para empleados,
• accesos de partners o proveedores,
• portales admin que no deben estar expuestos públicamente,
• RDP o SSH por rutas de acceso controladas,
• aplicaciones con grupos de usuarios claros,
• entornos donde el acceso VPN se ha vuelto demasiado amplio,
• sustitución gradual de modelos antiguos de remote access.

Especialmente para proveedores externos, ZTNA suele ser más cómodo que VPN. No hay que liberar toda una red, sino publicar una aplicación concreta con una política clara.

Dónde VPN sigue encajando

VPN sigue siendo útil cuando hay que conectar redes completas, cuando protocolos especiales no funcionan limpiamente con ZTNA o cuando se necesita un acceso de emergencia independiente de servicios cloud. Enlaces site-to-site, algunos entornos OT, aplicaciones legacy y escenarios admin complejos pueden seguir necesitando VPN.

La pregunta correcta no es: “¿VPN o ZTNA?” Mejor: “¿Qué recurso necesita qué ruta de acceso?”

Evaluar proveedores de forma neutral

Las soluciones ZTNA difieren mucho. Algunas son muy buenas para aplicaciones basadas en navegador, otras para accesos con cliente y otras como parte de una plataforma SSE o SASE más amplia.

Criterios importantes de selección

Antes de elegir producto, conviene aclarar:

• ¿Qué aplicaciones deben ser accesibles?
• ¿Se necesita acceso por navegador, por cliente o ambos?
• ¿Qué Identity Provider ya está definido?
• ¿Deben comprobarse dispositivos por posture?
• ¿Dónde está la ruta de datos: sitio propio, cloud del proveedor o ambos?
• ¿Cómo funcionan logs, exportación SIEM y auditoría?
• ¿Hay procesos claros de emergencia y break-glass?
• ¿Cómo encaja la solución con firewalls, EDR, MDM y DNS existentes?

Cloudflare suele ser fuerte cuando Access, Tunnel, DNS, web security e infraestructura edge global deben trabajar juntos. Sophos ZTNA suele encajar bien en entornos que ya usan intensamente Sophos Central, Sophos Endpoint o Sophos Firewall. No es una cuestión de fe, sino de arquitectura.

No todo Zero Trust es automáticamente mejor

Un ZTNA mal mantenido es solo un riesgo más moderno. Si los grupos son demasiado amplios, quedan excepciones antiguas, nadie lee logs o la verificación de dispositivos solo existe en papel, no se crea un entorno Zero Trust fuerte.

Introducción en orden sensato

Una buena introducción no empieza con el clic del producto, sino con una aplicación pequeña y bien entendida.

1. Inventariar aplicaciones y ordenarlas por riesgo.
2. Limpiar grupos de usuarios y roles externos.
3. Estabilizar Identity Provider y MFA.
4. Elegir una aplicación piloto importante pero controlable.
5. Planificar ruta de datos, DNS, certificado y logging.
6. Probar la política con un grupo pequeño de usuarios.
7. Revisar logs, recoger casos de soporte y mejorar la experiencia.
8. Migrar más aplicaciones paso a paso.
9. Reducir accesos VPN solo cuando ZTNA funciona en operación.

Para entornos específicos de Sophos, el siguiente paso es Configurar Sophos ZTNA: visión general y secuencia. Si el tema concreto es el gateway, ayuda Planificar y crear Sophos ZTNA Gateway.

Errores típicos

Tratar ZTNA como puro sustituto de VPN

Si solo se sustituye el túnel, pero grupos, aplicaciones, dispositivos y logs permanecen igual, hay poca mejora de seguridad. ZTNA debe planificarse por recurso.

Migrar demasiadas aplicaciones a la vez

Un rollout big-bang grande es arriesgado. Es mejor un piloto con una aplicación real, criterios de éxito claros y un camino de retorno limpio.

Olvidar el acceso de emergencia

Identity Provider, DNS, servicio cloud o gateway pueden fallar. Para admins se necesita un acceso break-glass documentado, fuertemente protegido, raramente usado y revisado periódicamente.

No operar los logs

ZTNA sin logging es difícil de soportar. Debe verse qué usuario accede a qué recurso, qué política aplica, por qué se bloqueó un acceso y si aparecen patrones inusuales.

Checklist operativo

• Documentar aplicaciones y owners.
• Mantener grupos de usuarios pequeños y comprensibles.
• Exigir MFA para accesos críticos.
• Usar activamente verificación de dispositivos si la solución la soporta limpiamente.
• Revisar políticas regularmente frente al uso real.
• Enviar logs a SIEM o logging central si el acceso es crítico.
• Documentar y probar acceso break-glass.
• Eliminar permisos VPN antiguos tras una migración exitosa.
• Dar a accesos de proveedores fecha de caducidad o revisión.

FAQ