Franchir la porte numérique d’une entreprise ne devrait jamais donner libre accès à tout son système d’information. Le ZTNA instaure un accès réseau sécurisé, précis et réversible.
Au lieu de reconnaître un utilisateur parce qu’il se trouve sur le bon réseau, cette architecture Zero Trust réévalue sa demande selon son identité, son terminal et les signaux de risque. Chaque application reste invisible jusqu’à l’autorisation, puis un contrôle d’accès contextuel limite la connexion au strict nécessaire. Au moindre doute, l’accès tombe sans délai.
ZTNA, c’est quoi au juste ?
Le ZTNA contrôle la connexion entre un utilisateur, son terminal et une application privée. Désigné par l’acronyme Zero Trust Network Access, ce dispositif soumet chaque demande à une politique précise plutôt qu’à la seule position sur le réseau. Le ZTNA renforce ainsi la sécurité des accès en vérifiant plusieurs signaux avant d’établir une liaison limitée et réversible. Avant toute ouverture, le service examine trois points.
- l’identité de la personne ;
- l’état de son terminal ;
- la ressource demandée.
Son périmètre reste ciblé : il gouverne l’accès aux ressources privées sans couvrir à lui seul toute l’architecture Zero Trust. Cette dernière englobe les identités, les terminaux, les données, la segmentation et la journalisation. Le ZTNA écarte donc la confiance implicite associée à une adresse IP, à un bureau ou à un appareil géré ; il complète les autres contrôles de défense au lieu de les remplacer.
De la confiance réseau à l’accès explicite aux ressources
Le modèle classique accorde une connectivité étendue après l’entrée dans le réseau interne, par exemple via un VPN. Le ZTNA change cette logique : chaque demande exige une autorisation explicite pour une application déterminée, sans exposer le sous-réseau qui l’héberge. Cet accès applicatif ne donne donc aucun droit automatique sur les services voisins, même lorsque le terminal appartient à l’entreprise.
Prenons une responsable RH qui ouvre l’outil de paie depuis son ordinateur professionnel. Après vérification de son identité, de l’état du terminal et des règles en vigueur, elle atteint cette seule application, mais ni les serveurs techniques ni les outils financiers. Le principe du moindre privilège transforme ainsi une entrée générale dans le réseau en droit ciblé, révocable et parfois limité dans le temps. La ressource peut rester invisible depuis Internet, car un connecteur établit la liaison uniquement après validation.
Une demande d’accès soumise à plusieurs contrôles
Lorsqu’un utilisateur sollicite une application, le dispositif ZTNA ne lui ouvre pas le réseau. La demande de connexion déclenche la vérification de l’identité auprès du fournisseur et la collecte des attributs sur le compte et l’appareil. Le moteur de politique compare ces signaux aux règles attachées à la ressource visée, sans extrapoler l’autorisation à d’autres services. La validation des accès établit un canal limité vers l’application visée, par proxy ou connecteur.
À retenir : le ZTNA réévalue une autorisation et peut interrompre la session dès que le risque augmente.
Une autorisation favorable conduit à l’émission d’un jeton temporaire et à l’établissement de la session. Durant l’échange, la surveillance continue réévalue le risque à partir des nouveaux signaux reçus. Un terminal déclaré non conforme, une alerte de sécurité ou un comportement inhabituel peut imposer une authentification renforcée. Si le doute persiste, la politique ordonne une restriction immédiate ou la révocation de session, sans conserver la confiance acquise.
Identité, terminal et contexte orientent chaque décision
Une adresse IP interne ne suffit pas à déterminer les droits d’un utilisateur sur une application. Le moteur examine son rôle, ses groupes, la sensibilité de la ressource et le niveau de preuve associé à son identité. Selon le risque, une authentification multifacteur résistante à l’hameçonnage peut être exigée avant l’ouverture d’une console d’administration ou l’accès aux données de paie. Les privilèges restent ciblés.
L’état réel de l’appareil complète cette lecture avant et pendant chaque session. Le chiffrement, les correctifs, l’inscription dans un outil MDM ou UEM et les alertes de l’EDR déterminent la posture du terminal. Les règles croisent ces données avec l’heure, la localisation approximative et les écarts par rapport aux habitudes observées. Ainsi, un salarié consulte la paie depuis un poste géré, puis perd cet accès si l’EDR détecte une compromission ou si son comportement devient anormal.
Trois fonctions pilotent et appliquent les politiques
La gouvernance d’un accès ZTNA repose sur des rôles séparés, qui coopèrent sans confondre analyse et exécution. Le moteur de politique confronte la demande aux règles, à l’identité, à l’état du terminal et au risque observé. Il produit une décision d’autorisation, de refus ou de révocation, sans ouvrir lui-même la session. L’enchaînement peut se résumer ainsi :
- Analyser les signaux et rendre un verdict.
- Traduire ce verdict en commandes techniques.
- Autoriser, limiter ou interrompre le flux.
Le verdict doit encore être converti en commandes exécutables. L’administrateur de politique traduit l’ordre en actions techniques : émission d’un jeton, configuration du chemin ou interruption de la session. Le point d’application, placé devant l’application protégée, applique alors cette instruction. Il laisse passer, limite ou bloque le flux. Si le niveau de risque change pendant l’usage, une nouvelle évaluation peut retirer l’accès. Cette séparation réduit les privilèges implicites et facilite l’audit, car chaque fonction laisse une trace distincte.
ZTNA, VPN, SSE et SASE ne couvrent pas le même périmètre
Ces quatre approches se distinguent par leur objet, même si elles peuvent cohabiter dans une architecture unique. Le tunnel VPN chiffre les échanges et étend la connectivité réseau vers un environnement distant ; il donne généralement accès à un segment plutôt qu’à une seule application. Le ZTNA accorde un passage explicite vers une ressource précise selon plusieurs signaux. Le tableau situe le SSE et le SASE :
| Approche | Fonction | Portée | Modèle d’accès |
|---|---|---|---|
| VPN | Chiffrement et transport du trafic | Réseau ou sous-réseau distant | Accès au segment après authentification |
| ZTNA | Protection des applications | Ressources définies | Autorisation explicite et granulaire |
| SSE | Regroupement des contrôles de sécurité | Services fournis depuis le cloud | Politiques fondées sur l’identité et le risque |
| SASE | Association des fonctions réseau et du SSE | Réseau étendu, applications et services | Contrôle unifié des flux et des accès |
Le VPN n’est donc pas incompatible avec le Zero Trust. Il peut transporter le trafic tandis qu’une politique ZTNA limite les droits, application par application. Le SSE réunit des services de sécurité cloud comme le ZTNA, le SWG ou le CASB ; le SASE y associe des fonctions WAN, notamment le SD-WAN. Changer d’offre ne suffit donc pas : la granularité des autorisations et leur réévaluation déterminent le modèle d’accès.
La surface d’attaque et les déplacements latéraux se réduisent
Le ZTNA soustrait les ressources internes aux scans venus d’Internet. Placées derrière un proxy ou un connecteur, les applications privées ne répondent qu’après validation de la demande, au lieu d’afficher une porte d’entrée publique. Cette invisibilité produit une réduction de la surface d’attaque concrète : l’assaillant trouve moins de services à sonder, tandis que chaque personne accède uniquement aux outils nécessaires à sa mission, selon le principe du moindre privilège.
Une compromission n’ouvre donc pas automatiquement le reste du système d’information. Les politiques limitent le périmètre de session et bloquent les mouvements latéraux vers des serveurs étrangers au rôle attribué. Une segmentation du réseau cohérente prolonge ce cloisonnement entre zones, avec des pare-feux et des règles locales. Le ZTNA borne ainsi le chemin autorisé vers une ressource précise ; il ne remplace ni l’isolation des systèmes sensibles ni leurs protections propres contre les intrusions.
Un socle fiable d’identités, de terminaux et de journaux
Les décisions d’accès valent seulement par la fiabilité des signaux qui les alimentent. Un fournisseur d’identité faisant autorité relie le SSO à un MFA ajusté au risque, tandis que le cycle de vie des comptes couvre création, changement de poste et suppression au départ. La gestion des terminaux atteste pour sa part l’identité de l’appareil, son chiffrement, ses correctifs et l’état de son EDR avant toute ouverture de session.
Des signaux dispersés ou tardifs rendent les politiques aveugles face aux anomalies. Une journalisation centralisée rapproche demandes, décisions, sessions et changements de posture afin d’accélérer la détection, puis de reconstituer précisément un incident. La résilience se vérifie par des tests de panne visant le service d’identité, le moteur de politique et les points d’application. Un accès de secours peut subsister, limité, surveillé et audité, sans devenir un passage contournant les contrôles ordinaires.
À retenir : des identités fiables, des appareils vérifiés et des journaux exploitables conditionnent la pertinence de chaque décision d’accès.
Quand le ZTNA recrée malgré lui un périmètre de confiance
Le modèle s’affaiblit dès que l’autorisation ouvre une zone interne entière. Au lieu de relier une identité à une application précise, la configuration accorde un accès réseau étendu à des sous-réseaux, serveurs ou interfaces. Un compte compromis retrouve alors les possibilités d’exploration et de déplacement latéral propres aux VPN permissifs, derrière une façade Zero Trust moderne, seulement en apparence.
Le signal réseau devient trompeur lorsqu’il tient lieu de preuve. Une adresse IP interne, un bureau ou une plage VPN ne garantit ni l’identité présentée ni l’intégrité du terminal ; cette logique facilite le contournement des contrôles. Le danger augmente encore si une application privée, une API ou une console d’administration reste directement exposée à Internet, puisqu’une faille peut alors être sollicitée sans passer par le moteur d’autorisation ZTNA au préalable.
La migration passe par la suppression des accès de contournement
Une bascule réussie ne consiste pas à superposer un nouveau service aux anciens chemins. La migration vers le ZTNA débute par une cartographie des usages, des dépendances applicatives et des flux autorisés, puis repère les routes d’accès historiques : tunnels VPN permissifs, routage direct, exceptions de pare-feu et comptes techniques. Chaque voie est retirée progressivement après validation ; sinon, elle demeure un contournement hors du moteur de politique central.
Le chantier s’achève quand les exceptions cessent de court-circuiter la décision. Les politiques de sécurité peuvent relier chaque ressource à l’identité, à l’état du terminal, au niveau d’authentification et au risque, avec des journaux exploitables. L’objectif reste un accès minimal, explicite et réévalué, complété par un dispositif de secours limité, surveillé et audité. Sinon, les règles statiques recréent pourtant silencieusement la confiance générale que le projet devait supprimer.