Comment fonctionne Zero Trust Network Access
Zero Trust Network Access (ZTNA) est une approche architecturale qui contrôle la manière dont utilisateurs et appareils accèdent aux applications et autres ressources protégées.
L'idée centrale est simple :
L'accès doit être explicitement autorisé pour la ressource demandée, plutôt que déduit de l'emplacement réseau ou du simple fait qu'un utilisateur est déjà connecté à un réseau privé.
Le ZTNA n'est donc ni un protocole unique, ni une architecture produit unique, ni un modèle de déploiement unique. Les fournisseurs l'implémentent différemment.
Le flux de décision ZTNA
1. Identifier le demandeur
Avant d'autoriser l'accès, le système doit savoir qui — ou quoi — le demande. Pour un utilisateur humain, l'identité peut venir d'un fournisseur OIDC, d'un annuaire d'entreprise, d'enregistrements locaux ou d'autres systèmes d'authentification.
L'identité n'est pas l'autorisation. Prouver l'identité d'un utilisateur ne devrait pas lui donner automatiquement accès à toutes les ressources privées.
2. Identifier l'appareil
Un utilisateur peut posséder plusieurs terminaux avec des états de sécurité différents. Un système ZTNA peut suivre l'appareil séparément via enrôlement, certificats ou clés, signaux MDM/EDR ou contrôles de posture. Il peut alors distinguer, par exemple, un ordinateur d'entreprise enrôlé d'un terminal inconnu du même utilisateur.
3. Collecter le contexte
Le contexte peut inclure ressource demandée, rôle ou groupe, posture, emplacement, heure, durée, approbation préalable et authentification renforcée requise. Un produit n'a pas besoin de tous les signaux possibles ; l'essentiel est que l'accès soit explicite et piloté par politique plutôt qu'accordé parce que le terminal est « à l'intérieur ».
4. Prendre une décision de politique
Le moteur répond à une question comme :
Cet utilisateur, sur cet appareil, est-il autorisé à accéder à cette ressource dans les conditions actuelles ?
Exemples : développeurs → serveurs de développement, finance → application comptable, fournisseur → un portail de maintenance jusqu'à vendredi, administrateur → console de production uniquement après approbation.
5. Appliquer la décision
Le ZTNA exige un point d'application entre le demandeur et la ressource.
Client et passerelle / connecteur
Un client terminal établit une connectivité sécurisée via une passerelle, un connecteur ou un composant similaire. Ce modèle convient aux protocoles nécessitant une connectivité réseau.
Proxy sans client
Pour les applications via navigateur, un proxy HTTP/HTTPS peut authentifier et autoriser l'utilisateur sans installer de tunnel sur le terminal.
Réseau orienté pair à pair
Certains produits coordonnent des communications peer-to-peer et distribuent centralement les permissions nécessaires.
Ces architectures peuvent toutes être valides si l'accès aux ressources reste explicitement autorisé.
6. Limiter la portée de l'accès
Le ZTNA ne se réduit pas au chiffrement. Le transport sécurisé protège les données en transit ; le ZTNA doit aussi déterminer ce que le demandeur authentifié est autorisé à atteindre. Une politique étroite par ressource peut réduire l'exposition inutile et les mouvements latéraux. La segmentation réseau et les contrôles hôte restent utiles en défense en profondeur.
7. Réévaluer l'accès
Les conditions changent : une fenêtre temporaire expire, un compte est désactivé, la posture d'un appareil se dégrade ou un rôle change. Une architecture ZTNA doit pouvoir réagir aux changements pertinents au lieu de considérer qu'une connexion initialement autorisée reste valide indéfiniment.
8. Enregistrer ce qui s'est passé
Les enregistrements utiles peuvent inclure identité, appareil, ressource demandée, événement d'authentification, résultat de politique, heure d'accès, révocation ou refus. Ils aident les investigations, revues d'accès, diagnostics et workflows SIEM.
Le ZTNA n'est pas simplement de la MFA
La MFA renforce l'authentification mais ne définit pas l'autorisation à une ressource. Un utilisateur peut réussir la MFA et rester non autorisé pour une application donnée.
Le ZTNA n'est pas simplement un protocole VPN
WireGuard, IPsec et TLS peuvent assurer un transport sécurisé. Un tunnel ne connaît pas automatiquement le rôle métier, la conformité d'un appareil, une approbation temporaire ou la ressource autorisée. Ces questions relèvent du système d'accès environnant.
Voir comment WireGuard s'intègre au ZTNA
Plan de contrôle et plan de données
Le plan de contrôle gère généralement configuration, identités et groupes, ressources, politiques, coordination des clés ou autorisations et workflows administratifs. Le plan de données transporte ou proxifie le trafic applicatif réel.
Certains fournisseurs exploitent les deux dans le cloud, d'autres hébergent le plan de contrôle tandis que le client déploie des connecteurs, et certains permettent l'auto-hébergement ou un fonctionnement sans cloud fournisseur obligatoire.
Comparer ZTNA auto-hébergé et cloud
Modèles de déploiement ZTNA courants
- Cloud-delivered : le fournisseur exploite le service de contrôle et souvent une infrastructure d'application distribuée.
- Plan de contrôle fournisseur + connecteurs client : coordination centrale chez le fournisseur, connecteurs près des applications privées.
- Auto-hébergé : le client ou un MSP exploite gestion et application.
- Autonome / déconnecté : le système d'accès peut fonctionner sans service de contrôle obligatoire du fournisseur et peut rester durablement isolé.
Chaque modèle présente des compromis différents en exploitation, disponibilité, contrôle des données et dépendance Internet.
Où se situe ZTXGate
ZTXGate utilise une plateforme d'accès exploitée par le client ou un MSP. Son accès géré utilise le transport WireGuard ; l'accès sans client sous licence peut proxifier les applications HTTP/HTTPS prises en charge. Identité, appareil, ressource, posture, heure, approbation et authentification supplémentaire peuvent alimenter les politiques.
ZTXGate peut fonctionner de manière autonome sans plan de contrôle cloud CoreZT obligatoire, y compris en environnement air-gapped. Les déploiements connectés peuvent utiliser ZTXHub en option pour centraliser licences et mises à jour logicielles.
Découvrir l'architecture ZTXGate · Découvrir ZTXGate