Zero Trust Network Access sur site
Apportez le Zero Trust aux applications et infrastructures déjà présentes dans votre centre de données, bureau, site distant ou environnement privé.
ZTXGate s’exécute dans l’infrastructure que vous exploitez, afin d’appliquer un accès tenant compte de l’identité, de l’appareil et de la ressource sans rendre le fonctionnement central dépendant d’un plan de contrôle cloud CoreZT.
Ce que signifie ZTNA sur site
Le ZTNA sur site maintient la plateforme d’accès proche des applications et systèmes qu’elle protège.
Au lieu d’envoyer chaque décision d’accès vers un service cloud opéré par le fournisseur, ZTXGate peut fonctionner sur une infrastructure Linux exploitée par le client ou un MSP, dans l’environnement où les ressources protégées existent déjà.
Ce modèle peut être utile lorsque :
- des applications importantes restent dans un centre de données privé
- les systèmes internes doivent rester sous contrôle opérationnel local
- la connectivité Internet est limitée ou volontairement restreinte
- l’emplacement du déploiement est une considération architecturale ou réglementaire
- l’organisation souhaite le même modèle de politique pour les utilisateurs locaux et distants
Sur site décrit où s’exécute la plateforme d’accès. Cela n’exige pas que l’environnement soit déconnecté des services cloud d’identité, MDM, EDR, SIEM ou autres si l’organisation choisit de les utiliser.
Le Zero Trust doit aussi s’appliquer à l’intérieur du réseau
La présence physique sur un réseau d’entreprise ne devrait pas déterminer automatiquement ce qu’un utilisateur est autorisé à atteindre.
ZTXGate maintient l’accès centré sur l’utilisateur, l’appareil, la ressource et la politique, que l’utilisateur soit distant ou déjà présent dans un bureau ou centre de données.
Un développeur peut être autorisé à accéder aux systèmes de développement sans recevoir l’accès à des ressources de production sans rapport. Un utilisateur Finance peut atteindre les applications approuvées sans être considéré comme fiable simplement parce que son terminal est connecté au réseau interne.
Les mêmes concepts de politique peuvent donc s’appliquer aux accès locaux et distants.
Comment ZTXGate fonctionne sur site
Un déploiement typique place ZTXGate sur une infrastructure Linux exploitée par le client.
Les terminaux gérés utilisent une connectivité basée sur WireGuard lorsque l’accès par tunnel est approprié. Les applications HTTP et HTTPS peuvent aussi être publiées via le proxy sans client de ZTXGate lorsque l’accès navigateur est plus adapté.
À haut niveau :
L’application protégée n’a pas besoin de devenir publiquement accessible simplement parce que les utilisateurs ont besoin d’un accès distant.
Garder le trafic local en local
Lorsque ZTXGate et les ressources protégées sont déployés dans le même environnement, l’accès n’a pas besoin d’être renvoyé via un service hébergé par CoreZT.
Cela peut simplifier le chemin du trafic pour les applications privées et aider les organisations à conserver le contrôle de l’endroit où fonctionne l’infrastructure d’accès.
Les intégrations externes restent des choix architecturaux optionnels. Par exemple, une organisation peut utiliser un fournisseur d’identité cloud tout en gardant ZTXGate et le trafic applicatif sur site.
Utiliser les systèmes d’identité et d’appareils existants
Un déploiement exploité par le client ou un MSP ne nécessite pas un silo d’identité séparé.
Dans les environnements connectés, ZTXGate peut s’intégrer avec :
- des fournisseurs d’identité OIDC pour l’authentification
- SCIM pour la synchronisation du cycle de vie utilisateur
- des plateformes MDM et EDR prises en charge pour la posture appareil
- des plateformes SIEM pour la visibilité des événements
- des méthodes d’authentification renforcée prises en charge
La plateforme d’accès reste sur site tandis que ces intégrations sont utilisées là où elles sont appropriées.
Dans les environnements où les services externes ne sont pas disponibles, ZTXGate peut fonctionner avec les services et signaux de sécurité accessibles à l’intérieur de cet environnement.
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 fonctionne dans les environnements connectés, sur site et totalement air-gapped, sans serveur ZTXBAS séparé.
C’est utile lorsqu’une organisation souhaite une authentification biométrique résistante au phishing sans rendre ce parcours dépendant d’un service MFA hébergé sur Internet.
Les options dépendantes du cloud telles qu’Okta Verify ou Duo restent disponibles dans les déploiements connectés où ces services sont accessibles.
Autonome ou géré centralement
ZTXGate peut fonctionner comme déploiement autonome.
Les déploiements connectés peuvent utiliser en option ZTXHub, un service détenu et exploité par CoreZT. ZTXHub fournit une gestion centralisée des mises à jour logicielles et des licences entre déploiements.
Le point essentiel : ZTXHub est optionnel.
Découvrir le modèle de plan de contrôle
Un déploiement sans ZTXHub peut continuer à exploiter ZTXGate indépendamment, y compris dans des environnements isolés. Dans ce modèle, les licences et mises à jour logicielles sont gérées manuellement.
| Modèle d’exploitation | ZTXGate autonome | ZTXGate avec ZTXHub optionnel |
|---|---|---|
| Fonctionnement d’accès central | Exploité par le client ou MSP | Exploité par le client ou MSP |
| Dépendance cloud CoreZT | Non requise | Non requise pour le fonctionnement d’accès ZTXGate |
| Gestion des licences | Manuelle | Centralisée via ZTXHub opéré par CoreZT |
| Gestion des mises à jour | Manuelle | Centralisée via ZTXHub opéré par CoreZT |
| Déploiement air-gapped | Pris en charge | Dépend de l’architecture réseau/hub choisie |
Accès au niveau de la ressource
Un déploiement sur site ne signifie pas revenir à une confiance réseau étendue.
Les politiques ZTXGate peuvent prendre en compte :
- l’identité utilisateur
- le rôle
- l’appareil enregistré
- la posture appareil lorsqu’elle est disponible
- l’emplacement réseau
- l’heure
- la ressource
- la durée d’accès
Cela permet de conserver les applications privées sur site tout en appliquant un modèle d’autorisation explicite.
Accès temporaire et approuvé
Les systèmes sensibles sur site ont souvent besoin d’accès ponctuels d’administration ou de dépannage plutôt que de permissions permanentes.
ZTXGate prend en charge l’accès temporaire et les workflows de demande et approbation afin qu’un approbateur autorisé puisse accorder une fenêtre définie puis laisser l’autorisation expirer automatiquement.
Cela peut s’appliquer aux systèmes de production, applications d’administration, projets temporaires et interventions de tiers.
Sauvegarde et reprise après sinistre
ZTXGate ne fournit pas de clustering haute disponibilité conventionnel.
Le portail d’administration peut toutefois créer des sauvegardes périodiques. Si un déploiement est perdu, une sauvegarde peut être restaurée dans une nouvelle installation ZTXGate pour récupérer rapidement l’environnement configuré.
Il s’agit d’un modèle de reprise par sauvegarde et restauration, pas d’une HA active/active ou active/passive.
Les organisations doivent planifier fréquence et protection des sauvegardes, infrastructure de remplacement et procédures de reprise selon leurs propres objectifs.
ZTNA sur site vs ZTNA fourni depuis le cloud
Aucun modèle n’est automatiquement adapté à toutes les organisations.
| Critère | ZTNA fourni depuis le cloud | ZTXGate sur site |
|---|---|---|
| Infrastructure de contrôle | Principalement opérée par le fournisseur | Exploitée par le client ou MSP |
| Emplacement de déploiement | Défini par l’architecture du service | Choisi par le client ou MSP |
| Maintenance de l’infrastructure | Principalement fournisseur | Client ou MSP |
| Trafic applicatif local | Dépend de l’architecture | Peut rester dans l’environnement choisi |
| Dépendance à un service externe | Généralement inhérente au service | Le cœur ZTXGate n’exige pas de plan de contrôle CoreZT |
| Fonctionnement air-gapped | Dépend de l’architecture | Modèle autonome pris en charge |
| Modèle de reprise | Dépend du fournisseur/service | Sauvegarde et restauration vers un nouveau déploiement |
Le ZTNA cloud peut réduire le travail de gestion d’infrastructure. Le ZTNA sur site offre davantage de contrôle sur le placement et l’exploitation.
Où le ZTNA sur site s’intègre
ZTXGate mérite d’être évalué pour :
- des applications de centre de données privé
- des interfaces d’administration internes
- des infrastructures de bureau ou de site distant
- des environnements hybrides comportant des ressources sur site importantes
- des réseaux restreints
- des organisations qui préfèrent exploiter elles-mêmes leur infrastructure de sécurité
Pour des environnements totalement déconnectés, consultez ZTNA air-gapped.
Pour le modèle de déploiement plus large, consultez ZTNA auto-hébergé.
Questions fréquentes
Le ZTNA sur site nécessite-t-il un accès Internet ?
Le fonctionnement central de ZTXGate n’exige pas de plan de contrôle cloud CoreZT. Les intégrations externes nécessitent une connectivité uniquement lorsque vous choisissez de les utiliser.
Les utilisateurs locaux peuvent-ils être régis par les mêmes politiques que les utilisateurs distants ?
Oui. La politique peut rester centrée sur l’identité, l’appareil, la ressource et le contexte plutôt que de considérer la présence sur le réseau local comme une autorisation suffisante.
Pouvons-nous continuer à utiliser notre fournisseur d’identité cloud ?
Oui, si le service d’identité est accessible. Conserver ZTXGate sur site n’empêche pas l’utilisation de services d’identité cloud.
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 ; 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 l’accès proche des systèmes que vous exploitez
Appliquez des politiques Zero Trust aux applications sur site sans forcer la plateforme d’accès à passer par un service cloud hébergé par un fournisseur.