ZTNA vs VPN: ¿qué es realmente diferente?
Zero Trust Network Access y las VPN de acceso remoto pueden proporcionar conectividad segura a recursos privados, pero parten de supuestos arquitectónicos diferentes.
Una VPN tradicional de acceso remoto normalmente establece conectividad hacia una red privada y después depende de rutas, reglas de firewall, segmentación, sistemas de identidad y otros controles para determinar qué puede alcanzar el endpoint conectado.
ZTNA acerca la decisión de autorización al recurso: ¿debe permitirse que este usuario, desde este dispositivo, acceda a este recurso bajo las condiciones actuales?
Esa es la distinción importante. ZTNA no es simplemente un protocolo VPN más nuevo.
La versión corta
| Pregunta | VPN tradicional de acceso remoto | ZTNA |
|---|---|---|
| ¿Qué se concede primero? | Conectividad de red | Autorización a recursos definidos |
| ¿Para qué se utiliza la identidad? | Habitualmente para autenticarse en el servicio VPN | Autenticación más contexto de política |
| ¿Cómo se utiliza el contexto del dispositivo? | Depende de la VPN y del stack de endpoint | Suele formar parte de la política de acceso |
| ¿El acceso siempre requiere cliente? | Normalmente | No; existen modelos con cliente y sin cliente |
| ¿Puede el acceso ser temporal o basado en aprobación? | Posible con sistemas circundantes | Patrón habitual de política ZTNA |
| ¿Se reevalúa la política después de la conexión? | Depende del producto | Objetivo central de diseño ZTNA |
| ¿Sustituye ZTNA la segmentación/firewalls? | No | No |
Ambas arquitecturas pueden desplegarse de forma segura. La diferencia está en dónde comienza la autorización y con qué precisión se expresa el acceso.
Cómo funcionan las VPN tradicionales de acceso remoto
Una VPN de acceso remoto crea una conexión cifrada entre un endpoint y un gateway VPN. Una vez establecida, el endpoint recibe rutas u otra accesibilidad de red según el despliegue.
Las organizaciones pueden —y suelen— añadir controles fuertes alrededor de esa conexión:
- MFA
- reglas de firewall
- ACL
- segmentación de red
- postura del endpoint
- gateways conscientes de identidad
- flujos de acceso privilegiado
Un despliegue VPN bien diseñado no es inherentemente inseguro.
El reto operativo aparece cuando la autorización de recursos está distribuida entre varios sistemas. Un usuario puede autenticarse en la VPN, recibir conectividad de red y después encontrarse con controles adicionales en otras partes del entorno.
Cómo funciona ZTNA
ZTNA considera que la ubicación de red o la pertenencia a un túnel no son autorización suficiente por sí mismas.
Una política ZTNA puede considerar señales como:
- identidad del usuario
- rol o grupo
- dispositivo registrado
- postura del dispositivo
- recurso solicitado
- hora y ubicación
- estado de aprobación
- duración del acceso
- requisitos de autenticación adicional
El National Cyber Security Centre describe una arquitectura ZTNA bien diseñada como aquella que autoriza explícitamente el acceso, limita la exposición de aplicaciones y el movimiento lateral, verifica continuamente el acceso y mantiene la autorización estrechamente delimitada.
Lea nuestra guía sobre cómo funciona ZTNA
Acceso a red frente a acceso a recursos
La diferencia arquitectónica más clara es el alcance del acceso.
Con una VPN tradicional de acceso remoto, los administradores suelen pensar en términos de accesibilidad de red: ¿a qué subredes, rutas, puertos o zonas de seguridad debe poder acceder el endpoint conectado?
ZTNA comienza con el recurso protegido.
Por ejemplo:
- un desarrollador puede acceder a sistemas de desarrollo sin recibir acceso amplio a redes de producción
- un usuario de finanzas puede acceder a una aplicación de contabilidad sin obtener accesibilidad general a la subred circundante
- un contratista puede recibir una aplicación durante un período fijo
- un administrador puede tener que solicitar aprobación antes de acceder a un recurso sensible
El objetivo es hacer explícito el recurso permitido.
La identidad es más que iniciar sesión
Tanto los productos VPN como ZTNA pueden integrarse con proveedores modernos de identidad.
La diferencia está en cómo se utiliza la identidad después de la autenticación.
En ZTNA, la identidad suele ser una de varias entradas de una decisión de acceso a recursos. El rol del usuario, la pertenencia actual a grupos, el dispositivo, la postura, el recurso y otro contexto pueden contribuir a la política.
Esto convierte la identidad en parte de la autorización y no únicamente en el mecanismo utilizado para establecer una sesión.
Confianza del dispositivo
Un nombre de usuario no indica qué endpoint solicita acceso.
Los productos ZTNA suelen representar el dispositivo por separado del usuario y pueden incorporar señales de postura como estado del sistema operativo, cumplimiento MDM, riesgo EDR, certificados u otros indicadores de confianza.
Los productos VPN también pueden utilizar postura del dispositivo, especialmente cuando forman parte de un stack más amplio de acceso seguro o endpoint. Por tanto, la confianza del dispositivo no es exclusiva de ZTNA.
La pregunta arquitectónica es si el contexto del dispositivo es una entrada directa y de primera clase para la autorización de recursos.
Aplicación continua
Una decisión de acceso puede quedar obsoleta.
Un rol puede cambiar. Una ventana de acceso temporal puede caducar. Un dispositivo puede dejar de cumplir las políticas. Un equipo de seguridad puede revocar el acceso de un usuario.
Las arquitecturas ZTNA están diseñadas alrededor de la aplicación continua de políticas, en lugar de tratar una conexión exitosa como permanentemente autoritativa durante toda la sesión.
La rapidez exacta con la que un producto detecta y actúa ante un cambio varía según la implementación.
Acceso con cliente y sin cliente
ZTNA no implica una única arquitectura de endpoint.
Acceso con cliente
Un cliente o agente puede establecer conectividad segura y admitir acceso a protocolos más allá del navegador. ZTXGate utiliza transporte basado en WireGuard para su ruta de acceso gestionado.
Acceso sin cliente
Para aplicaciones web, algunas plataformas ZTNA pueden actuar como proxy HTTP/HTTPS consciente de identidad, de modo que el endpoint no necesite software de túnel de red.
ZTXGate ofrece acceso HTTP/HTTPS sin cliente como capacidad licenciada.
Importan el plano de control y el plano de datos
Dos productos pueden llamarse ZTNA y tener modelos operativos muy distintos.
Preguntas que conviene hacer:
- ¿quién opera el plano de control?
- ¿depende la política de un servicio en la nube alojado por el proveedor?
- ¿por dónde circula el tráfico de aplicaciones?
- ¿qué ocurre si se pierde la conectividad a Internet?
- ¿puede el sistema operar permanentemente desconectado?
- ¿quién es responsable de actualizaciones, copias de seguridad y disponibilidad?
Estas suelen ser preguntas de evaluación más útiles que la presencia de un acrónimo concreto en una lista de funciones.
Compare ZTNA autoalojado y suministrado desde la nube
Cuándo sigue siendo apropiada una VPN
ZTNA no es un sustituto universal para todos los casos de uso VPN.
Una VPN puede seguir siendo una buena opción cuando realmente se necesita conectividad amplia de red entre entornos o endpoints de confianza, por ejemplo:
- conectividad sitio a sitio
- redes de infraestructura
- escenarios administrativos que intencionadamente requieren amplio acceso a protocolos o subredes
- entornos sencillos donde la segmentación y los controles existentes ya satisfacen los requisitos
WireGuard por sí mismo es un excelente protocolo de transporte seguro. La distinción es que transporte seguro y autorización Zero Trust resuelven problemas diferentes.
Descubra cómo encaja WireGuard en ZTNA
La migración no tiene que ser todo o nada
Las organizaciones pueden introducir ZTNA gradualmente.
Una secuencia práctica es:
- seleccionar un pequeño grupo de usuarios
- identificar algunos recursos privados
- definir requisitos de identidad y dispositivo
- introducir ZTNA junto a la VPN existente
- validar el acceso y los flujos operativos
- migrar recursos adicionales cuando corresponda
Esto permite mantener la VPN existente para casos de uso que todavía la necesiten.
Dónde encaja ZTXGate
ZTXGate está diseñado alrededor de la autorización a nivel de recurso con opciones de despliegue operadas por el cliente o un MSP.
Combina:
- identidad de usuario y dispositivo
- integraciones de postura de dispositivos
- políticas de recursos
- acceso temporal y mediante solicitud y aprobación
- aplicación continua de políticas
- conectividad gestionada basada en WireGuard
- acceso HTTP/HTTPS sin cliente licenciado
- integración de auditoría y SIEM
- funcionamiento independiente y aislado sin un plano de control en la nube obligatorio alojado por CoreZT
Para despliegues conectados que deseen gestión centralizada de licencias y actualizaciones, el servicio opcional ZTXHub es propiedad de CoreZT y operado por CoreZT.
Explorar ZTXGate · Sustitución de VPN · Iniciar prueba gratuita