Zero Trust Network Access auto-hébergé

Exécutez votre plateforme d’accès dans une infrastructure exploitée par votre organisation ou votre MSP.

ZTXGate fournit le Zero Trust Network Access sans exiger de plan de contrôle cloud CoreZT obligatoire pour son fonctionnement d’accès principal. Déployez-le sur site, dans une VM cloud, au sein d’une infrastructure hybride ou dans un environnement isolé.

Ce que signifie ZTNA auto-hébergé​

Pour ZTXGate, auto-hébergé signifie que le logiciel s’exécute dans une infrastructure exploitée par le client ou par un MSP agissant pour son compte.

L’opérateur du déploiement choisit où ZTXGate s’exécute, comment l’hôte est sécurisé, les réseaux auxquels il se connecte, les intégrations d’identité et de sécurité utilisées, les ressources protégées et la manière dont les politiques d’accès sont définies.

ZTXGate est un logiciel commercial pris en charge, déployé hors d’un plan de contrôle d’accès CoreZT obligatoire. Auto-hébergé ne signifie pas que le produit est open source.

Garder la plateforme d’accès proche de vos ressources​

Sur site​

Exécutez ZTXGate dans un centre de données, un bureau ou tout autre environnement exploité par le client ou le MSP.

Cloud​

Déployez ZTXGate sur une VM Linux aux côtés de l’infrastructure hébergée dans le cloud.

Hybride​

Utilisez le même modèle d’accès avec des ressources réparties entre environnements sur site et cloud.

Air-gapped​

Déployez ZTXGate dans des environnements isolés où la plateforme d’accès centrale ne peut pas dépendre d’un service cloud externe.

Aucun plan de contrôle cloud fournisseur obligatoire​

Certaines architectures ZTNA dépendent d’un service cloud opéré par le fournisseur pour le contrôle, les politiques, l’intermédiation d’identité, le traitement du trafic ou d’autres fonctions.

ZTXGate peut être exploité par le client ou un MSP. Les politiques centrales et l’application des accès s’exécutent dans l’environnement de déploiement ZTXGate choisi.

Cela peut compter lorsqu’une organisation veut conserver l’infrastructure sous son propre contrôle opérationnel, possède des exigences internes ou réglementaires, exploite des applications qui doivent rester indépendantes d’un plan de contrôle SaaS externe ou limite volontairement la connectivité Internet.

Cela ne signifie pas que chaque intégration optionnelle fonctionne sans connectivité externe. Si ZTXGate utilise un fournisseur d’identité externe, une plateforme MDM ou EDR, un service SIEM ou un service d’authentification tiers, cette intégration dépend naturellement de l’accessibilité du service concerné.

Découvrir le modèle de plan de contrôle

Une architecture sous votre contrôle​

Les terminaux gérés utilisent une connectivité basée sur WireGuard pour les accès autorisés via ZTXGate. La plateforme peut aussi prendre en charge l’accès HTTP/HTTPS sans client lorsque ce modèle est approprié.

Le point essentiel est que l’autorisation passe par l’environnement ZTXGate choisi plutôt que par un plan d’accès obligatoirement hébergé par CoreZT.

Auto-hébergé ne signifie pas isolé des systèmes existants​

Dans les environnements connectés, ZTXGate peut s’intégrer aux systèmes déjà utilisés par l’organisation :

• Identité : authentification OIDC et provisioning SCIM
• Sécurité des appareils : signaux de posture MDM et EDR pris en charge
• Authentification : ZTXBAS dans tous les modèles de déploiement, plus Okta Verify Push et Duo Push lorsque ces services cloud sont accessibles
• SIEM : export syslog, CEF et JSON

Ces intégrations sont des composants optionnels autour de la plateforme d’accès exploitée par le client ou le MSP.

Autonome ou géré centralement avec ZTXHub​

ZTXGate n’exige aucun service CoreZT central pour fonctionner. Un déploiement autonome peut gérer les accès localement, y compris dans un environnement totalement air-gapped.

Pour les déploiements connectés qui souhaitent centraliser les mises à jour logicielles et les licences, ZTXHub est un service optionnel détenu et exploité par CoreZT.

Sans ZTXHub, ZTXGate reste indépendant. Les licences et mises à jour logicielles sont alors gérées manuellement.

ZTXBAS dans tous les modèles de déploiement​

Lorsqu’il est licencié avec ZTXGate, ZTXBAS est étroitement intégré sous forme de bibliothèque et ne nécessite pas de serveur ZTXBAS séparé. Il fonctionne dans les environnements ZTXGate connectés, sur site, hybrides et totalement air-gapped.

Cela apporte une option d’authentification biométrique résistante au phishing qui peut rester dans la même frontière de déploiement. Les services MFA dépendants du cloud tels qu’Okta Verify et Duo restent disponibles lorsque leurs services sont accessibles.

Découvrir ZTXBAS

ZTNA auto-hébergé vs ZTNA fourni depuis le cloud​

Aucun modèle n’est automatiquement le bon pour toutes les organisations.

Le ZTNA fourni depuis le cloud peut réduire la charge de gestion d’infrastructure. Le ZTNA auto-hébergé donne davantage de contrôle sur l’endroit où fonctionne la plateforme d’accès.

L’auto-hébergement implique aussi davantage de responsabilité​

Un contrôle accru de l’infrastructure s’accompagne de responsabilités opérationnelles.

L’organisation qui exploite ZTXGate est également responsable des bonnes pratiques concernant la sécurité de l’hôte, la maintenance du système d’exploitation, la configuration réseau, les sauvegardes, la restauration, la planification de disponibilité, les accès administrateur, la supervision et les mises à jour du produit.

C’est un compromis intentionnel.

Identité moderne sans abandonner le contrôle du déploiement​

Une plateforme d’accès exploitée par le client ou un MSP peut tout à fait utiliser des services d’identité modernes. Dans les environnements connectés, ZTXGate peut authentifier les utilisateurs via un fournisseur OIDC et utiliser SCIM pour synchroniser le cycle de vie des identités.

L’emplacement de la plateforme d’accès et le système d’identité utilisé sont deux décisions architecturales distinctes.

Confiance des appareils​

ZTXGate enregistre chaque appareil utilisateur et peut intégrer l’identité de l’appareil à la politique. Lorsque des services de posture externes pris en charge sont disponibles, les informations de conformité ou de risque peuvent également contribuer aux décisions d’accès.

Dans les environnements isolés, les politiques utilisent naturellement les signaux d’identité, d’appareil et de sécurité disponibles dans cet environnement.

Environnements air-gapped et déconnectés​

La plateforme d’accès centrale de ZTXGate peut être déployée sans dépendre d’un plan de contrôle cloud CoreZT.

Cependant, une architecture air-gapped doit être considérée dans son ensemble. Les services d’identité, MDM, EDR, SIEM ou d’authentification push hébergés sur Internet nécessitent une connectivité s’ils font partie du déploiement.

ZTXGate ne rend pas une dépendance externe disponible à l’intérieur d’un air gap ; il permet à la plateforme d’accès centrale elle-même de rester dans l’environnement isolé.

Sauvegarde et reprise après sinistre​

ZTXGate ne fournit pas de clustering HA conventionnel. Le portail d’administration peut créer des sauvegardes périodiques du déploiement.

Si un déploiement est perdu, une sauvegarde peut être restaurée dans une nouvelle installation ZTXGate afin de récupérer rapidement l’environnement configuré. Il s’agit d’un modèle de reprise par sauvegarde et restauration, pas d’un basculement active/active ou active/passive.

Les organisations doivent protéger les copies de sauvegarde et planifier l’infrastructure de remplacement et les procédures de reprise selon leurs propres objectifs.

Qui devrait envisager un ZTNA auto-hébergé ?​

ZTXGate peut convenir lorsque :

• votre organisation exploite déjà une infrastructure Linux
• les applications privées résident surtout sur site ou dans une infrastructure cloud exploitée par le client ou MSP
• vous ne souhaitez pas que l’accès central dépende d’un plan de contrôle hébergé par un fournisseur
• vous exploitez une infrastructure hybride
• vous devez prendre en charge des environnements isolés ou air-gapped
• l’emplacement de déploiement est une considération architecturale ou réglementaire
• votre équipe préfère posséder l’infrastructure plutôt que déléguer entièrement à un modèle SaaS fournisseur

Un service cloud peut être préférable si votre organisation souhaite précisément externaliser la possession et la maintenance de l’infrastructure.

Questions fréquentes​

ZTXGate est-il open source ?​

Non. ZTXGate est un logiciel commercial sous licence et pris en charge, déployé dans une infrastructure exploitée par le client ou un MSP.

ZTXGate exige-t-il un compte cloud CoreZT pour l’accès central ?​

Le fonctionnement d’accès central n’exige pas de plan de contrôle cloud CoreZT obligatoire. Les intégrations connectées spécifiques dépendent naturellement de leurs services respectifs.

ZTXGate peut-il fonctionner sur site ou dans un cloud public ?​

Oui. Les deux sont des modèles pris en charge.

ZTXGate peut-il fonctionner dans un environnement air-gapped ?​

ZTXGate peut être déployé dans des environnements isolés sans plan de contrôle cloud CoreZT. Les capacités disponibles dépendent des systèmes d’identité, authentification, posture, supervision et autres systèmes accessibles à l’intérieur de cet environnement.

L’auto-hébergement élimine-t-il le travail opérationnel ?​

Non. Le client ou MSP qui exploite le déploiement reste responsable de la sécurisation et de la maintenance de l’infrastructure hébergeant ZTXGate.

Avons-nous besoin de ZTXHub ?​

Non. ZTXHub est optionnel, détenu et exploité par CoreZT. Les déploiements autonomes utilisent des workflows manuels pour les licences et mises à jour, tandis que les déploiements connectés peuvent utiliser ZTXHub pour les centraliser.

ZTXGate fournit-il de la haute disponibilité ?​

Pas au sens d’un clustering conventionnel. ZTXGate utilise un modèle de reprise par sauvegarde et restauration permettant de rétablir une configuration enregistrée dans un nouveau déploiement.

Gardez le Zero Trust là où se trouve votre infrastructure​

Si votre organisation souhaite un accès Zero Trust par ressource tout en conservant la plateforme d’accès dans l’infrastructure exploitée par votre équipe ou MSP, ZTXGate fournit un modèle auto-hébergé.

Découvrir ZTXGate · ZTNA auto-hébergé vs cloud · ZTNA sur site · ZTNA air-gapped · Découvrir Sécurité et confiance