Zero Trust Network Access autoalojado
Ejecute su plataforma de acceso en infraestructura operada por su organización o MSP.
ZTXGate proporciona Zero Trust Network Access sin requerir un plano de control en la nube obligatorio alojado por CoreZT para el funcionamiento básico del acceso. Despliéguelo localmente, en una VM en la nube, en infraestructura híbrida o dentro de un entorno aislado.
Qué significa ZTNA autoalojado
Para ZTXGate, autoalojado significa que el software se ejecuta dentro de infraestructura operada por el cliente o por un MSP que actúa en nombre del cliente.
El operador del despliegue determina dónde se ejecuta ZTXGate, cómo se protege el host, a qué redes se conecta, qué integraciones de identidad y seguridad se utilizan, qué recursos se protegen y cómo se definen las políticas de acceso.
ZTXGate es software con soporte comercial desplegado fuera de un plano de control de acceso obligatorio alojado por CoreZT. Autoalojado no significa que el producto sea de código abierto.
Mantenga la plataforma de acceso cerca de sus recursos
Local
Ejecute ZTXGate dentro de un centro de datos, oficina u otro entorno operado por el cliente o MSP.
Nube
Despliegue ZTXGate en una VM Linux junto a infraestructura alojada en la nube.
Híbrido
Utilice el mismo modelo de acceso con recursos distribuidos entre entornos locales y en la nube.
Aislado
Despliegue ZTXGate dentro de entornos aislados donde la plataforma central de acceso no pueda depender de un servicio externo en la nube.
Sin plano de control en la nube obligatorio del proveedor
Algunas arquitecturas ZTNA dependen de un servicio en la nube operado por el proveedor para control, políticas, intermediación de identidad, manejo del tráfico u otras funciones.
ZTXGate puede ser operado por el cliente o por un MSP. La política central y la aplicación del acceso se ejecutan dentro de ese entorno de despliegue de ZTXGate.
Esto puede ser importante cuando una organización desea infraestructura bajo su propio control operativo, tiene requisitos internos o regulatorios de despliegue, opera aplicaciones que deben permanecer independientes de un plano de control SaaS externo o restringe deliberadamente la conectividad a Internet.
Esto no significa que todas las integraciones opcionales funcionen sin conectividad externa. Si ZTXGate está configurado para utilizar un proveedor de identidad externo, una plataforma MDM, una plataforma EDR, un servicio SIEM o un servicio de autenticación de terceros, esa integración depende naturalmente de que el servicio correspondiente sea accesible.
Explorar el modelo de plano de control
Arquitectura bajo su control
Los endpoints gestionados utilizan conectividad basada en WireGuard para el acceso autorizado a través de ZTXGate. La plataforma también puede admitir acceso HTTP/HTTPS sin cliente cuando ese modelo sea adecuado.
El punto importante es que la autorización ocurre a través del entorno de despliegue ZTXGate seleccionado, en lugar de requerir un plano de acceso alojado por CoreZT.
Autoalojado no significa aislado de los sistemas existentes
En entornos conectados, ZTXGate puede integrarse con sistemas que la organización ya utiliza:
- Identidad: autenticación OIDC y aprovisionamiento SCIM
- Seguridad del dispositivo: entradas de postura de MDM y EDR compatibles
- Autenticación: ZTXBAS en todos los modelos de despliegue, además de Okta Verify Push y Duo Push cuando esos servicios en la nube sean accesibles
- SIEM: exportación mediante syslog, CEF y JSON
Estas integraciones son componentes opcionales alrededor de la plataforma de acceso operada por el cliente o MSP.
Independiente o gestionado centralmente con ZTXHub
ZTXGate no necesita un servicio central de CoreZT para funcionar. Un despliegue independiente puede gestionar el acceso localmente, incluso en un entorno completamente aislado.
Para despliegues conectados que deseen gestión centralizada de actualizaciones de software y licencias, ZTXHub es un servicio opcional propiedad de CoreZT y operado por CoreZT.
Si no se utiliza ZTXHub, ZTXGate permanece independiente. Las licencias y actualizaciones de software se gestionan manualmente.
| Modelo operativo | ZTXGate independiente | ZTXGate con ZTXHub opcional |
|---|---|---|
| Funcionamiento básico del acceso | Operado por el cliente o MSP | Operado por el cliente o MSP |
| Plano de control alojado por CoreZT requerido | No | No |
| Gestión de licencias | Manual | Centralizada mediante ZTXHub operado por CoreZT |
| Gestión de actualizaciones de software | Manual | Centralizada mediante ZTXHub operado por CoreZT |
| Despliegue completamente aislado | Compatible | Utilice el modo independiente para permanecer completamente aislado |
ZTXBAS en todos los modelos de despliegue
Cuando se licencia con ZTXGate, ZTXBAS está estrechamente integrado como biblioteca y no requiere un despliegue separado del servidor ZTXBAS. Funciona en entornos ZTXGate conectados, locales, híbridos y completamente aislados.
Esto proporciona a los despliegues una opción de autenticación biométrica resistente al phishing que puede permanecer dentro del mismo límite de despliegue. Los servicios MFA dependientes de la nube, como Okta Verify y Duo, siguen estando disponibles donde sus respectivos servicios sean accesibles.
ZTNA autoalojado frente a ZTNA suministrado desde la nube
Ningún modelo de despliegue es automáticamente el correcto para todas las organizaciones.
| Consideración | ZTNA suministrado desde la nube | ZTXGate autoalojado |
|---|---|---|
| Infraestructura de control | Operada por el proveedor | Operada por el cliente o MSP |
| Mantenimiento de infraestructura | Principalmente responsabilidad del proveedor | Responsabilidad del cliente o MSP |
| Ubicación del despliegue | Definida por la arquitectura del proveedor | Elegida por el cliente o MSP |
| Dependencia de servicio externo | Normalmente inherente al servicio | El funcionamiento básico no requiere un plano de control alojado por CoreZT |
| Funcionamiento aislado | Depende de la arquitectura | Modelo de despliegue compatible |
| Control operativo | Compartido con el servicio del proveedor | Controlado por el cliente o MSP |
| Escalado y disponibilidad | Modelo de servicio gestionado por el proveedor | El cliente planifica capacidad y resiliencia del despliegue |
El ZTNA suministrado desde la nube puede reducir la carga de gestión de infraestructura. El ZTNA autoalojado ofrece mayor control sobre dónde opera la plataforma de acceso.
Autoalojado también implica más responsabilidad
Un mayor control de la infraestructura conlleva responsabilidad operativa.
La organización que opera ZTXGate también es responsable de las prácticas adecuadas en torno a seguridad del host, mantenimiento del sistema operativo, configuración de red, copias de seguridad, recuperación, planificación de disponibilidad, acceso administrativo, monitorización y actualizaciones del producto.
Es una compensación deliberada.
Identidad sin renunciar al control del despliegue
Una plataforma de acceso operada por el cliente o MSP puede seguir utilizando servicios modernos de identidad. En entornos conectados, ZTXGate puede autenticar usuarios mediante un proveedor de identidad OIDC y utilizar SCIM para sincronizar el ciclo de vida de identidad.
Dónde se ejecuta la plataforma de acceso y qué sistema de identidad utiliza la organización son decisiones arquitectónicas independientes.
Confianza del dispositivo
ZTXGate registra dispositivos de usuario individualmente y puede hacer que la identidad del dispositivo forme parte de la política. Cuando haya disponibles servicios externos de postura compatibles, la información de cumplimiento o riesgo también puede contribuir a las decisiones de acceso.
En entornos aislados, la política utiliza naturalmente las señales de identidad, dispositivo y seguridad disponibles dentro del entorno.
Entornos aislados y desconectados
La plataforma central de acceso de ZTXGate puede desplegarse sin depender de un plano de control en la nube alojado por CoreZT.
Sin embargo, una arquitectura aislada debe considerarse en su conjunto. Los servicios de identidad, MDM, EDR, SIEM o autenticación push alojados en Internet requieren conectividad si forman parte del despliegue.
ZTXGate no hace que una dependencia externa esté disponible dentro de un aislamiento; permite que la propia plataforma central de acceso permanezca dentro del entorno aislado.
Copias de seguridad y recuperación ante desastres
ZTXGate no proporciona clustering HA convencional. En su lugar, el portal de administración puede crear copias de seguridad periódicas del despliegue.
Si se pierde un despliegue, una copia de seguridad puede restaurarse en una instalación nueva de ZTXGate para recuperar rápidamente el entorno configurado. Se trata de un modelo de recuperación ante desastres basado en copia de seguridad y restauración, no de conmutación por error activa/activa o activa/pasiva.
Las organizaciones deben proteger las copias de seguridad y planificar la infraestructura de sustitución y los procedimientos de recuperación conforme a sus propios objetivos de recuperación.
¿Quién debería considerar ZTNA autoalojado?
ZTXGate puede ser adecuado cuando:
- su organización ya opera infraestructura Linux
- las aplicaciones privadas residen principalmente localmente o en infraestructura en la nube operada por el cliente o MSP
- no desea que el acceso principal dependa de un plano de control alojado por el proveedor
- opera infraestructura híbrida
- necesita compatibilidad con entornos aislados
- la ubicación del despliegue es una consideración arquitectónica o regulatoria
- su equipo prefiere poseer y operar la infraestructura frente a un modelo SaaS completamente operado por el proveedor
Un servicio suministrado desde la nube puede ser preferible cuando la propiedad y el mantenimiento de infraestructura son precisamente responsabilidades que su organización desea externalizar.
Preguntas frecuentes
¿Es ZTXGate de código abierto?
No. ZTXGate es software con licencia comercial y soporte, desplegado en infraestructura operada por el cliente o por un MSP.
¿Requiere ZTXGate una cuenta en la nube de CoreZT para el acceso básico?
El funcionamiento básico del acceso no requiere un plano de control en la nube obligatorio alojado por CoreZT. Las integraciones conectadas específicas dependen naturalmente de sus respectivos servicios.
¿Puede ZTXGate ejecutarse localmente o en una nube pública?
Sí. Ambos son modelos de despliegue compatibles.
¿Puede ZTXGate funcionar en un entorno aislado?
ZTXGate puede desplegarse en entornos aislados sin requerir un plano de control en la nube alojado por CoreZT. Las capacidades disponibles dependen de qué sistemas de identidad, autenticación, postura, monitorización y soporte sean accesibles dentro de ese entorno.
¿El autoalojamiento elimina el trabajo operativo?
No. El cliente o MSP que opera el despliegue es responsable de proteger y mantener la infraestructura que aloja ZTXGate.
¿Necesitamos ZTXHub?
No. ZTXHub es opcional y es propiedad de CoreZT y operado por CoreZT. Los despliegues independientes utilizan flujos manuales de licencia y actualización de software, mientras que los conectados pueden utilizar ZTXHub para gestión centralizada de licencias y actualizaciones.
¿Proporciona ZTXGate alta disponibilidad?
No en el sentido convencional de clustering. ZTXGate utiliza un modelo de recuperación ante desastres basado en copia de seguridad y restauración, de modo que una configuración guardada puede restaurarse en un despliegue nuevo.
Mantenga Zero Trust donde reside su infraestructura
Si su organización desea acceso Zero Trust a nivel de recurso manteniendo la plataforma de acceso dentro de infraestructura operada por su equipo o MSP, ZTXGate proporciona un modelo de despliegue autoalojado.
Explorar ZTXGate · ZTNA autoalojado vs. ZTNA en la nube · ZTNA local · ZTNA aislado · Explorar Seguridad y confianza