ZTNA autoalojado frente a ZTNA suministrado desde la nube
“ZTNA en la nube” y “ZTNA autoalojado” parecen dos categorías sencillas. En la práctica, el mercado contiene varios modelos arquitectónicos entre ambos extremos.
La pregunta más útil no es simplemente dónde se ejecuta un producto. Es:
¿Quién opera el plano de control, por dónde circula el tráfico de aplicaciones y qué sigue funcionando cuando los servicios externos no están disponibles?
Esta guía compara los principales modelos operativos sin asumir que uno sea universalmente mejor.
Cuatro modelos operativos habituales
1. ZTNA suministrado desde la nube
El proveedor opera la gestión, las políticas y el servicio de acceso como una plataforma en la nube.
Esto puede reducir el trabajo de infraestructura para el cliente y proporcionar disponibilidad y alcance geográfico gestionados por el proveedor.
2. Plano de control del proveedor + conectores del cliente
El proveedor opera servicios centrales de coordinación y políticas, mientras el cliente despliega conectores, gateways o service edges cerca de las aplicaciones privadas.
El tráfico de aplicaciones puede circular por componentes del cliente, service edges del proveedor, rutas directas entre pares o una combinación, según el producto.
3. ZTNA autoalojado
El cliente o MSP opera la infraestructura de control y aplicación del producto.
Esto proporciona mayor control del despliegue, pero el operador también asume más responsabilidad de mantenimiento, copias de seguridad, disponibilidad y monitorización.
4. ZTNA independiente / desconectado
La plataforma de acceso puede funcionar sin un servicio de control obligatorio alojado por el proveedor.
Este es el modelo relevante para entornos permanentemente aislados, altamente restringidos o completamente air-gapped.
Propiedad del plano de control
El plano de control suele gestionar configuración, identidades, definiciones de recursos, políticas, autorización y flujos administrativos.
En un servicio suministrado desde la nube, el proveedor opera esa capa.
En un sistema autoalojado, la opera el cliente o MSP.
Ninguno es automáticamente más seguro. Crean límites de confianza y responsabilidades operativas diferentes.
Preguntas que conviene formular:
- ¿quién puede administrar el servicio de control?
- ¿dónde se almacena la configuración?
- ¿qué servicios externos son necesarios para tomar decisiones de política?
- ¿pueden los administradores seguir trabajando durante una interrupción de Internet?
- ¿de qué es responsable el proveedor frente al cliente o MSP?
Ruta de datos
La ubicación del plano de control no indica necesariamente por dónde circula el tráfico de aplicaciones.
Un producto ZTNA gestionado desde la nube puede mantener el tráfico de aplicaciones directamente entre componentes controlados por el cliente. Otro puede enrutar el tráfico mediante service edges del proveedor. Una plataforma autoalojada puede hacer proxy o gateway del tráfico a través de infraestructura operada por el cliente.
Al evaluar productos, pregunte por separado:
- ¿Dónde se coordinan las decisiones de política?
- ¿Por dónde circula realmente el tráfico de aplicaciones?
Dependencia de Internet
Un servicio conectado puede ofrecer excelente disponibilidad y seguir dependiendo del acceso a la nube del proveedor para gestión, nuevas autorizaciones, coordinación de autenticación u otras funciones.
Esto puede ser aceptable —o deseable— para despliegues empresariales normales.
Los entornos desconectados necesitan una respuesta diferente.
Pregunte qué ocurre cuando:
- desaparece la conectividad a Internet durante minutos u horas
- el servicio de control del proveedor deja de ser accesible
- el proveedor de identidad externo deja de ser accesible
- el servicio MDM/EDR deja de ser accesible
- la red está deliberadamente aislada de forma indefinida
“Funciona durante una interrupción temporal” no es necesariamente lo mismo que “puede operar permanentemente aislado”.
Identidad y autenticación
El ZTNA suministrado desde la nube suele integrarse con proveedores de identidad en la nube. Los productos autoalojados pueden admitir proveedores externos de identidad, usuarios locales o ambos.
Un diseño aislado debe utilizar métodos de identidad y autenticación disponibles dentro del entorno desconectado.
Esta distinción también se aplica a MFA. Un servicio push en la nube no puede completar una transacción de autenticación si el despliegue no puede acceder a ese servicio.
Actualizaciones y licencias
Los productos suministrados desde la nube suelen convertir la gestión del ciclo de vida del software principalmente en responsabilidad del proveedor.
Los productos autoalojados necesitan un modelo de actualización. Puede incluir repositorios automatizados, servicios gestionados de actualización o paquetes manuales.
Los entornos desconectados necesitan un proceso offline controlado para actualizaciones y licencias si esas funciones dependerían de conectividad externa.
Disponibilidad y recuperación ante desastres
Los servicios en la nube normalmente proporcionan redundancia gestionada por el proveedor como parte del servicio.
El autoalojamiento transfiere más responsabilidad al operador. Los productos pueden admitir clustering, diseños activo/pasivo, componentes distribuidos o recuperación mediante copia de seguridad y restauración.
No son equivalentes.
Un comprador debe preguntar por el modelo exacto en lugar de aceptar “alta disponibilidad” o “resiliencia” como etiquetas genéricas.
Responsabilidad operativa
| Área | Suministrado desde la nube | Autoalojado / operado por cliente o MSP |
|---|---|---|
| Infraestructura del plano de control | Proveedor | Cliente o MSP |
| Parches de plataforma | Principalmente proveedor | Cliente/MSP según proceso del proveedor |
| Escalado | Principalmente proveedor | Cliente/MSP |
| Copias de seguridad | Principalmente responsabilidad del servicio del proveedor | Cliente/MSP |
| Disponibilidad de la plataforma de monitorización | Proveedor + integración del cliente | Cliente/MSP |
| Dependencia de Internet | Depende del producto; normalmente significativa | Depende del producto; puede ser evitable |
| Idoneidad para air gap | Depende del producto | Posible si la arquitectura lo admite |
El modelo autoalojado proporciona más control, pero también más responsabilidad.
Requisitos de cumplimiento y control de datos
Algunas organizaciones prefieren la entrega en la nube porque el proveedor puede operar una plataforma estandarizada y disponible globalmente.
Otras necesitan que la infraestructura permanezca dentro de límites operativos definidos por motivos como:
- redes aisladas
- políticas internas de arquitectura
- entornos regulados
- requisitos contractuales de clientes
- restricciones de ubicación de datos o dependencias
La decisión correcta depende de los requisitos reales, no de una afirmación genérica de que la nube o el autoalojamiento siempre es superior.
Ejemplos de modelos de mercado
El mercado ZTNA actual demuestra la variedad de posibilidades:
- algunos productos utilizan un controlador alojado por el proveedor con conectores del cliente
- algunos ofrecen ediciones en la nube y verdaderamente autoalojadas
- algunos gestionan el plano de control como SaaS mientras liberan como código abierto componentes del lado del cliente
- algunos proporcionan componentes de continuidad local mientras se sincronizan con un servicio en la nube durante el funcionamiento normal
Esa variedad explica por qué importa evaluar la arquitectura.
Dónde encaja ZTXGate
ZTXGate está diseñado para ejecutarse en infraestructura operada por el cliente o por un MSP.
El funcionamiento básico del acceso no requiere un plano de control en la nube obligatorio alojado por CoreZT.
ZTXGate independiente
- operado por el cliente o MSP
- puede permanecer completamente aislado
- la gestión de licencias es manual
- las actualizaciones de software son manuales
- ZTXBAS integrado puede operar dentro del entorno ZTXGate desconectado cuando está licenciado
ZTXGate con ZTXHub opcional
- ZTXGate sigue siendo operado por el cliente o MSP
- ZTXHub es propiedad de CoreZT y operado por CoreZT
- ZTXHub proporciona gestión centralizada de actualizaciones de software
- ZTXHub proporciona gestión centralizada de licencias
- el servicio es opcional y no requerido para el funcionamiento básico del acceso
Modelo de resiliencia
Actualmente ZTXGate no proporciona clustering HA convencional. Los administradores pueden configurar copias de seguridad periódicas y restaurar una copia en un despliegue nuevo cuando se necesite recuperación ante desastres.
Es un modelo DR basado en copia de seguridad y restauración, no en conmutación por error automática.
Explorar ZTNA autoalojado · Sin plano de control en la nube obligatorio
Preguntas que hacer a cualquier proveedor ZTNA
Antes de elegir una arquitectura, pregunte:
- ¿Quién opera el plano de control?
- ¿Por dónde circula el tráfico?
- ¿Qué componentes del lado del cliente son necesarios?
- ¿Qué ocurre cuando la nube del proveedor no está disponible?
- ¿Puede el sistema operar permanentemente desconectado?
- ¿Qué funciones de identidad y postura dependen de servicios externos?
- ¿Cómo se entregan las actualizaciones?
- ¿Cómo se gestionan las licencias en entornos desconectados?
- ¿Cuál es el modelo real de disponibilidad?
- ¿Quién es responsable de las copias de seguridad y recuperación ante desastres?
- ¿Qué funciones requieren software en el endpoint?
- ¿Qué responsabilidades permanecen en el cliente o MSP?
Esas respuestas suelen revelar más sobre el modelo operativo que la etiqueta “ZTNA”.