Comment fonctionne Zero Trust Network Access avec ZTXGate
Le ZTNA n'est pas simplement un tunnel chiffré ou une autre manière de se connecter à un réseau privé. Le changement architectural important consiste à autoriser explicitement l'accès autour de l'utilisateur, de l'appareil, de la ressource protégée et des conditions actuelles de politique.
ZTXGate rassemble ces décisions dans une plateforme exploitable par le client ou un MSP, sur site, dans une infrastructure cloud, en environnement hybride ou totalement air-gapped.
La décision ZTNA
Cet utilisateur, sur cet appareil, peut-il atteindre cette ressource dans les conditions actuelles ?
ZTXGate peut utiliser l'identité et le rôle, l'appareil enrôlé, la posture, l'emplacement réseau, l'heure, la ressource protégée, la durée, l'état d'approbation et les exigences d'authentification renforcée. La connectivité réseau seule n'est pas considérée comme une autorisation suffisante.
Architecture ZTXGate en un coup d'œil
Il s'agit d'une architecture logique : les blocs représentent des responsabilités de sécurité, pas nécessairement un processus logiciel par bloc.
Identité : qui demande l'accès ?
OIDC peut fournir authentification et claims d'identité, tandis que SCIM peut synchroniser des informations de cycle de vie depuis les systèmes pris en charge. L'identité devient un signal de politique plutôt qu'une porte unique donnant automatiquement un accès réseau large.
Découvrir Identité & confiance appareil
Appareil : quel terminal demande l'accès ?
ZTXGate enrôle individuellement les appareils utilisateur. Un appareil perdu ou devenu non fiable peut être révoqué sans nécessairement désactiver les autres appareils de l'utilisateur. Dans les environnements connectés, les signaux de Microsoft Intune, Microsoft Defender for Endpoint, SentinelOne Singularity, CrowdStrike et Jamf peuvent également être utilisés.
Politique : que peuvent atteindre cet utilisateur et cet appareil ?
La politique est centrée sur des ressources définies. Un développeur peut accéder au développement sans accéder à la production ; un prestataire peut recevoir une application pour une durée limitée ; un administrateur peut devoir obtenir une approbation et effectuer une vérification supplémentaire avant une ressource sensible.
Accès géré : WireGuard pour le transport sécurisé
Les terminaux gérés utilisent une connectivité basée sur WireGuard pour l'accès réseau autorisé. WireGuard fournit le transport ; ZTXGate ajoute les contextes d'identité, d'appareil, de ressource, de cycle de vie, d'approbation, de posture et d'audit. L'existence d'un tunnel WireGuard n'est donc pas la politique d'accès.
Accès sans client : HTTP/HTTPS via le proxy
Pour les applications HTTP et HTTPS prises en charge, ZTXGate peut fournir un accès sans client via son proxy appliquant les politiques. Il termine la connexion entrante et établit la connexion autorisée vers l'application protégée. Comme il opère au niveau HTTP, il peut appliquer des contrôles tenant compte de l'application lorsque le modèle de politique le permet.
Application continue des politiques
Une décision ne doit pas rester valide uniquement parce qu'une connexion a été autorisée auparavant. Si une fenêtre d'accès se ferme, un rôle change ou une posture ne satisfait plus la politique, ZTXGate peut continuer à évaluer les conditions et révoquer l'accès selon la configuration.
Authentification renforcée
Les ressources sensibles peuvent exiger une vérification supplémentaire. ZTXBAS sous licence est intégré sous forme de bibliothèque et fournit une authentification biométrique résistante au phishing dans les modèles connectés comme air-gapped. Les déploiements connectés peuvent aussi utiliser des services pris en charge tels qu'Okta Verify et Duo. ZTXBAS autonome reste un produit gratuit distinct destiné aux développeurs d'applications.
Audit et visibilité de sécurité
ZTXGate enregistre l'accès, l'authentification et l'activité de politique. Les événements peuvent être transmis aux environnements de supervision avec des formats pris en charge comme syslog, CEF ou JSON. Cette visibilité ne remplace pas un SIEM ; elle lui fournit un contexte d'accès centralisé.
Les intégrations externes sont des signaux, pas des dépendances fondamentales
OIDC, SCIM, Intune, Defender for Endpoint, SentinelOne, CrowdStrike, Jamf, Okta Verify, Duo et les plateformes SIEM enrichissent le contexte lorsqu'ils sont accessibles. Dans un environnement totalement air-gapped, ZTXGate utilise les capacités d'identité, d'authentification, d'appareil et de supervision disponibles localement.
Modèle de déploiement et de plan de contrôle
ZTXGate peut fonctionner de manière autonome sans plan de contrôle cloud CoreZT obligatoire. Il peut être exploité par le client ou un MSP. En mode autonome, il peut rester totalement air-gapped avec licences et mises à jour manuelles. Pour les déploiements connectés, CoreZT propose ZTXHub en option pour centraliser licences et mises à jour.
Découvrir le modèle de plan de contrôle
Sauvegarde et reprise après sinistre
ZTXGate n'utilise pas actuellement de HA en cluster conventionnelle. Des sauvegardes périodiques peuvent être restaurées dans un nouveau déploiement lorsque nécessaire. Il s'agit d'un modèle sauvegarde/restauration et non d'un cluster actif/actif ou actif/passif.
Ce que le ZTNA ne remplace pas
Le ZTNA reste une couche d'une architecture de sécurité plus large. Conception applicative sûre, durcissement des systèmes, segmentation locale, protection endpoint, gestion des certificats et clés, gestion des vulnérabilités, supervision, réponse aux incidents, sauvegardes et reprise après sinistre restent nécessaires.