Zero Trust Network Access local
Lleve el acceso Zero Trust a aplicaciones e infraestructura que ya residen dentro de su centro de datos, oficina, sucursal o entorno privado.
ZTXGate se ejecuta dentro de infraestructura que usted opera, de modo que puede aplicar acceso basado en identidad, dispositivo y recurso sin hacer que el acceso principal dependa de un plano de control en la nube alojado por CoreZT.
Qué significa ZTNA local
El ZTNA local mantiene la plataforma de acceso cerca de las aplicaciones y sistemas que protege.
En lugar de enviar cada decisión de acceso a través de un servicio en la nube operado por el proveedor, ZTXGate puede ejecutarse sobre infraestructura Linux operada por el cliente o por un MSP dentro del entorno donde ya existen los recursos protegidos.
Este modelo puede ser útil cuando:
- aplicaciones importantes permanecen dentro de un centro de datos privado
- los sistemas internos deben permanecer bajo control operativo local
- la conectividad a Internet es limitada o está restringida deliberadamente
- la ubicación del despliegue es una consideración arquitectónica o regulatoria
- la organización desea el mismo modelo de políticas para usuarios locales y remotos
Local describe dónde se ejecuta la plataforma de acceso. No exige que el entorno circundante esté desconectado de servicios de identidad, MDM, EDR, SIEM u otros servicios en la nube si la organización decide utilizarlos.
Zero Trust también debe aplicarse dentro de la red
La presencia física en una red corporativa no debería determinar automáticamente a qué puede acceder un usuario.
ZTXGate permite que el acceso siga centrado en el usuario, dispositivo, recurso y política, tanto si el usuario está remoto como si ya se encuentra dentro de una oficina o centro de datos.
Un desarrollador puede estar autorizado para sistemas de desarrollo sin recibir acceso a recursos de producción no relacionados. Un usuario de finanzas puede acceder a aplicaciones aprobadas sin ser considerado de confianza simplemente porque su endpoint está conectado a una red interna.
Por tanto, los mismos conceptos de política pueden aplicarse al acceso local y remoto.
Cómo se ejecuta ZTXGate localmente
Un despliegue típico sitúa ZTXGate sobre infraestructura Linux operada por el cliente.
Los endpoints gestionados utilizan conectividad basada en WireGuard cuando el acceso mediante túnel es apropiado. Las aplicaciones HTTP y HTTPS también pueden publicarse a través del proxy sin cliente de ZTXGate cuando el acceso desde navegador sea más adecuado.
A alto nivel:
La aplicación protegida no necesita hacerse accesible públicamente solo porque los usuarios necesiten acceso remoto a ella.
Mantenga el tráfico local en local
Cuando ZTXGate y los recursos protegidos se despliegan en el mismo entorno, el acceso no necesita desviarse a través de un servicio alojado por CoreZT.
Esto puede simplificar la ruta del tráfico para aplicaciones privadas y ayuda a las organizaciones a conservar el control sobre dónde opera la infraestructura de acceso.
Las integraciones externas siguen siendo decisiones arquitectónicas opcionales. Por ejemplo, una organización puede utilizar un proveedor de identidad alojado en la nube mientras mantiene ZTXGate y el tráfico de aplicaciones localmente.
Utilice sus sistemas existentes de identidad y dispositivo
Un despliegue operado por el cliente o MSP no requiere un silo de identidad separado.
En entornos conectados, ZTXGate puede integrarse con:
- proveedores de identidad OIDC para autenticación
- SCIM para sincronización del ciclo de vida de usuarios
- plataformas MDM y EDR compatibles para postura del dispositivo
- plataformas SIEM para visibilidad de eventos
- métodos compatibles de autenticación adicional
La plataforma de acceso permanece local mientras esas integraciones se utilizan cuando corresponde.
Para entornos donde no estén disponibles servicios externos, ZTXGate puede operar con los servicios y señales de seguridad accesibles dentro de ese entorno.
ZTXBAS en todos los modelos de despliegue
Cuando se licencia con ZTXGate, ZTXBAS está estrechamente integrado como biblioteca y funciona en entornos conectados, locales y completamente aislados sin requerir un despliegue separado del servidor ZTXBAS.
Esto resulta útil cuando una organización desea autenticación biométrica resistente al phishing sin hacer que esa ruta de autenticación dependa de un servicio MFA alojado en Internet.
Las opciones dependientes de la nube, como Okta Verify o Duo, siguen estando disponibles para despliegues conectados donde dichos servicios sean accesibles.
Independiente o gestionado centralmente
ZTXGate puede funcionar como un despliegue independiente.
Los despliegues conectados pueden utilizar opcionalmente ZTXHub, un servicio propiedad de CoreZT y operado por CoreZT. ZTXHub proporciona gestión centralizada de actualizaciones de software y licencias entre despliegues.
El punto importante es que ZTXHub es opcional.
Explorar el modelo de plano de control
Un despliegue que no utiliza ZTXHub puede seguir operando ZTXGate de forma independiente, incluso en entornos aislados. En ese modelo, las licencias y actualizaciones de software se gestionan manualmente.
Esto ofrece a las organizaciones una elección entre:
| 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 |
| Dependencia de nube alojada por CoreZT | No requerida | No requerida para el funcionamiento de acceso de ZTXGate |
| 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 aislado | Compatible | Depende de la arquitectura de hub/red elegida |
Acceso a nivel de recurso
El despliegue local no significa volver a una confianza de red amplia.
Las políticas de ZTXGate pueden considerar:
- identidad del usuario
- rol
- dispositivo registrado
- postura del dispositivo cuando esté disponible
- ubicación de red
- hora
- recurso
- duración del acceso
Esto permite a una organización mantener aplicaciones privadas localmente mientras aplica un modelo de acceso basado en autorización explícita.
Acceso temporal y aprobado
Los sistemas locales sensibles suelen necesitar acceso ocasional de administración o resolución de problemas, en lugar de permisos permanentes.
ZTXGate admite acceso temporal y mediante solicitud y aprobación para que un aprobador autorizado pueda conceder una ventana de acceso definida y permitir que el permiso caduque automáticamente después.
Esto puede utilizarse para sistemas de producción, aplicaciones administrativas, proyectos temporales y trabajo de terceros.
Copias de seguridad y recuperación ante desastres
ZTXGate no proporciona clustering convencional de alta disponibilidad.
En su lugar, el portal de administración puede configurarse para crear copias de seguridad periódicas del despliegue. Si se pierde un despliegue, una copia 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 HA activa/activa ni activa/pasiva.
Las organizaciones deben planificar la frecuencia y protección de las copias, la infraestructura de sustitución y los procedimientos de recuperación conforme a sus propios objetivos de recuperación.
ZTNA local frente a ZTNA suministrado desde la nube
Ningún modelo es automáticamente el correcto para todas las organizaciones.
| Consideración | ZTNA suministrado desde la nube | ZTXGate local |
|---|---|---|
| Infraestructura de control | Principalmente operada por el proveedor | Operada por el cliente o MSP |
| Ubicación del despliegue | Definida por la arquitectura del servicio | Elegida por el cliente o MSP |
| Mantenimiento de infraestructura | Principalmente responsabilidad del proveedor | Responsabilidad del cliente o MSP |
| Tráfico de aplicaciones locales | Depende de la arquitectura | Puede permanecer dentro del entorno de despliegue seleccionado |
| Dependencia de servicio externo | Normalmente inherente al servicio | El acceso básico de ZTXGate no requiere un plano de control alojado por CoreZT |
| Funcionamiento aislado | Depende de la arquitectura | Modelo independiente compatible |
| Modelo de recuperación | Depende del proveedor/servicio | Copia de seguridad y restauración en un despliegue nuevo |
El ZTNA suministrado desde la nube puede reducir el trabajo de gestión de infraestructura. El ZTNA local ofrece mayor control sobre ubicación y operación.
Dónde encaja el ZTNA local
Puede valer la pena evaluar ZTXGate cuando necesite acceso Zero Trust para:
- aplicaciones privadas de centros de datos
- interfaces administrativas internas
- infraestructura de oficinas o sucursales
- entornos híbridos con recursos locales importantes
- redes restringidas
- organizaciones que prefieren operar por sí mismas la infraestructura de seguridad
Para entornos completamente desconectados, consulte ZTNA aislado.
Para el modelo de despliegue más amplio, consulte ZTNA autoalojado.
Preguntas frecuentes
¿Requiere Internet el ZTNA local?
El funcionamiento básico del acceso de ZTXGate no requiere un plano de control en la nube alojado por CoreZT. Las integraciones externas requieren conectividad únicamente cuando decide utilizar esos servicios.
¿Pueden los usuarios locales regirse por las mismas políticas que los remotos?
Sí. La política puede seguir centrada en identidad, dispositivo, recurso y contexto, en lugar de asumir que la presencia en la red local constituye autorización suficiente.
¿Podemos seguir utilizando nuestro proveedor de identidad en la nube?
Sí, cuando el servicio de identidad sea accesible. Mantener ZTXGate localmente no impide utilizar servicios de identidad en la nube.
¿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, mientras que los conectados pueden utilizar ZTXHub para gestión centralizada de licencias y actualizaciones de software.
¿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 el acceso cerca de los sistemas que opera
Lleve políticas Zero Trust a aplicaciones locales sin obligar a que la plataforma de acceso se sitúe en un servicio en la nube alojado por el proveedor.