Zero Trust Network Access pour les environnements air-gapped
L'isolation réduit l'exposition, mais elle ne supprime pas la nécessité de contrôler qui peut atteindre les systèmes sensibles au sein de l'environnement isolé.
ZTXGate peut fonctionner dans des réseaux totalement air-gapped sans dépendre d'un plan de contrôle cloud hébergé par CoreZT. Les contrôles d'identité, d'appareil, de ressource, de politique, d'authentification et d'audit peuvent rester dans l'environnement.
Ce que signifie le ZTNA air-gapped
Le ZTNA air-gapped n'est pas un moyen de rendre un système isolé accessible à distance depuis l'Internet public.
Il permet d'appliquer des contrôles d'accès Zero Trust à l'intérieur d'un environnement isolé ou déconnecté.
Les utilisateurs, administrateurs et appareils qui disposent déjà d'un chemin approuvé vers cet environnement peuvent toujours être soumis à une politique explicite avant d'atteindre les applications et infrastructures protégées.
C'est important, car l'isolation réseau seule ne répond pas à des questions telles que :
- Quel utilisateur doit pouvoir atteindre cette ressource ?
- Quel appareil enrôlé peut être utilisé ?
- L'autorisation doit-elle être permanente ou limitée dans le temps ?
- L'accès sensible doit-il exiger une authentification supplémentaire ?
- Les administrateurs peuvent-ils déterminer qui a accédé à une ressource et quand ?
ZTXGate répond à ces questions de contrôle d'accès sans exiger que son fonctionnement principal contacte un service cloud CoreZT.
Garder la plateforme d'accès à l'intérieur de la frontière
Un déploiement ZTXGate autonome peut fonctionner entièrement dans l'environnement protégé.
Le parcours d'accès principal reste dans la frontière réseau.
Fonctionnement autonome
Les clients n'ont pas besoin de ZTXHub pour exploiter ZTXGate et le fonctionnement principal n'exige pas de plan de contrôle hébergé par CoreZT.
Dans un déploiement autonome air-gapped :
- la politique d'accès est gérée localement
- les licences sont gérées manuellement
- les mises à jour logicielles sont gérées manuellement
- les sauvegardes sont gérées localement
- les données d'audit restent disponibles dans le déploiement
Ce modèle d'exploitation est volontairement adapté aux réseaux où la connectivité de gestion externe n'est pas autorisée.
ZTXHub optionnel pour les déploiements connectés
CoreZT fournit également ZTXHub, un service optionnel détenu et exploité par CoreZT.
Les déploiements ZTXGate connectés peuvent utiliser ZTXHub pour centraliser la gestion des mises à jour logicielles et des licences.
Il n'est pas requis pour une installation totalement air-gapped. Les clients ayant besoin d'une isolation stricte peuvent l'omettre et conserver le modèle d'exploitation manuel.
La gestion centralisée reste ainsi un choix de déploiement plutôt qu'un prérequis au fonctionnement de ZTXGate.
Découvrir le modèle de plan de contrôle
ZTXBAS fonctionne dans les environnements air-gapped
L'authentification renforcée devient souvent difficile dans les environnements déconnectés, car de nombreux produits MFA dépendent d'un service hébergé sur Internet.
Lorsqu'il est sous licence avec ZTXGate, ZTXBAS est étroitement intégré sous forme de bibliothèque et fonctionne dans tous les modèles de déploiement ZTXGate, y compris les réseaux totalement air-gapped, sans nécessiter un serveur ZTXBAS distinct.
Cela maintient une authentification biométrique résistante au phishing dans le même environnement isolé au lieu d'exiger l'accès à un service externe d'authentification push.
Les déploiements connectés peuvent toujours utiliser des alternatives prises en charge telles qu'Okta Verify ou Duo lorsque ces services sont accessibles.
L'identité dans un environnement isolé
Un déploiement air-gapped ne peut utiliser que les systèmes d'identité accessibles depuis cet environnement.
Si une organisation exploite un fournisseur d'identité interne compatible ou une intégration d'annuaire, ZTXGate peut utiliser les services disponibles dans la frontière réseau.
Un fournisseur d'identité hébergé sur Internet ne peut pas participer à l'authentification sauf si l'environnement lui fournit volontairement une connectivité.
Le même principe s'applique à chaque intégration externe : ZTXGate ne prétend pas qu'un réseau déconnecté peut atteindre un service cloud physiquement indisponible.
Identité de l'appareil et politique
ZTXGate enrôle les appareils individuellement et peut utiliser leur identité dans la politique d'accès.
Les politiques peuvent combiner des facteurs tels que :
- l'identité de l'utilisateur
- le rôle
- l'appareil enrôlé
- les informations de posture disponibles localement
- l'emplacement réseau
- l'heure
- la ressource protégée
- la durée d'accès
Lorsqu'un service MDM ou EDR est hébergé hors de l'environnement isolé, ses données de posture ne sont pas disponibles sans connectivité. La politique doit donc être conçue autour des signaux disponibles dans l'environnement.
Accès avec et sans client
Les environnements air-gapped peuvent contenir à la fois des services réseau et des applications accessibles par navigateur.
Les terminaux gérés peuvent utiliser l'accès basé sur WireGuard via ZTXGate pour les ressources autorisées.
Les applications HTTP et HTTPS peuvent aussi utiliser le proxy sans client de ZTXGate lorsque l'accès via navigateur convient, ce qui permet d'appliquer les politiques et contrôles d'audit sans logiciel de tunnel sur ce terminal.
Audit et visibilité locaux
Les environnements déconnectés ont toujours besoin d'investigation et de traçabilité.
ZTXGate conserve localement les enregistrements d'accès, d'authentification et de politique. Lorsqu'une plateforme SIEM ou de logs interne existe dans le réseau isolé, ZTXGate peut transmettre les événements avec les formats et transports pris en charge.
Les services SIEM hébergés dans le cloud nécessitent une connectivité et ne font donc pas partie d'une architecture strictement air-gapped.
Mises à jour logicielles et licences
Un déploiement autonome totalement air-gapped utilise des workflows manuels pour les licences et les mises à jour logicielles.
Cela diffère d'un déploiement connecté utilisant ZTXHub en option, où la gestion des licences et des mises à jour peut être centralisée.
Le modèle manuel permet au client ou au MSP exploitant le déploiement de contrôler quand les logiciels ou éléments de licence entrent dans l'environnement isolé selon ses procédures opérationnelles.
Sauvegarde et reprise après sinistre
ZTXGate n'utilise pas de clustering HA conventionnel.
Le portail d'administration prend en charge 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 l'environnement configuré.
Pour un déploiement air-gapped, le client ou le MSP doit conserver des copies de sauvegarde protégées et maintenir un processus documenté de mise en place d'une infrastructure de remplacement dans l'environnement isolé.
Il s'agit d'un modèle de reprise après sinistre fondé sur sauvegarde et restauration, et non sur un basculement continu.
Capacités connectées et air-gapped
| Capacité | Déploiement connecté | Déploiement autonome totalement air-gapped |
|---|---|---|
| Accès principal ZTXGate | Oui | Oui |
| Plan de contrôle cloud hébergé par CoreZT requis | Non | Non |
| ZTXBAS | Oui | Oui |
| Okta Verify / Duo | Lorsque le service est accessible | Non, sauf si la connectivité est volontairement fournie |
| Fournisseur d'identité cloud | Lorsque le service est accessible | Non, sauf si la connectivité est volontairement fournie |
| Posture MDM / EDR cloud | Lorsque le service est accessible | Non, sauf si la connectivité est volontairement fournie |
| SIEM cloud | Lorsque le service est accessible | Non, sauf si la connectivité est volontairement fournie |
| Gestion des licences | Manuelle ou ZTXHub optionnel exploité par CoreZT | Manuelle |
| Mises à jour logicielles | Manuelles ou ZTXHub optionnel exploité par CoreZT | Manuelles |
| DR par sauvegarde/restauration | Oui | Oui |
Où le ZTNA air-gapped s'applique
Ce modèle peut être pertinent pour des environnements tels que :
- réseaux isolés de recherche et développement
- environnements opérationnels restreints
- infrastructures internes sensibles
- réseaux dont la connectivité Internet est volontairement limitée
- organisations dont l'architecture exige des services de sécurité locaux
L'adéquation d'un déploiement donné dépend toujours des exigences de sécurité de l'organisation et des contrôles environnants.
Questions fréquentes
Le ZTNA air-gapped donne-t-il un accès Internet distant à un réseau isolé ?
Non. L'objectif est d'appliquer l'accès Zero Trust dans l'environnement isolé, pas de contourner l'air gap.
ZTXGate a-t-il besoin de ZTXHub dans un déploiement air-gapped ?
Non. ZTXHub est optionnel, détenu et exploité par CoreZT. Un déploiement ZTXGate totalement air-gapped n'utilise pas ZTXHub et peut recourir à des workflows manuels pour les licences et mises à jour.
La MFA biométrique peut-elle fonctionner sans accès Internet ?
Oui. Lorsqu'il est sous licence avec ZTXGate, ZTXBAS intégré fournit une authentification biométrique résistante au phishing dans les déploiements totalement air-gapped sans serveur ZTXBAS distinct.
Que deviennent les intégrations cloud ?
Elles ne sont disponibles que si les services correspondants sont accessibles. Un environnement strictement air-gapped doit utiliser les services d'identité, d'authentification, de posture, de journalisation et de gestion disponibles à l'intérieur de sa frontière.
ZTXGate fournit-il de la HA pour les environnements isolés ?
Pas au sens d'un clustering conventionnel. Le modèle de résilience pris en charge repose sur des sauvegardes périodiques et une restauration dans un nouveau déploiement après sinistre.
Appliquez Zero Trust sans rompre l'air gap
Gardez la plateforme d'accès, l'option d'authentification, les politiques et le parcours d'audit dans l'environnement isolé exploité par le client ou le MSP.
Comparer les modèles d'exploitation air-gapped
Pour des comparaisons d'architecture actuelles, consultez ZTXGate vs Cloudflare Access, ZTXGate vs Zscaler Private Access et ZTXGate vs Tailscale.