Le ZTNA, ou accès réseau Zero Trust, ne consiste pas à installer un nouveau VPN et à changer son interface. Il s’agit de revoir la manière dont une organisation expose ses applications : chaque demande est évaluée, limitée au strict nécessaire et réexaminée dans le temps. Pour un service informatique, la réussite dépend donc moins de l’outil choisi que de la méthode de déploiement.
Voici un parcours opérationnel en plusieurs étapes, conçu pour les équipes qui souhaitent réduire la dépendance aux accès réseau traditionnels sans interrompre la production.
1. Cartographier les accès avant de choisir une solution
La première erreur consiste à commencer par un catalogue de fonctionnalités. Un projet ZTNA doit partir des usages réels : qui accède à quelle ressource, depuis quel terminal, selon quel niveau de sensibilité et pour quelle durée ? L’inventaire doit couvrir les applications hébergées dans le cloud, les services installés dans le datacenter, les interfaces d’administration et les environnements de développement.
Associez à chaque ressource son propriétaire, ses dépendances et son mode d’authentification. Cette cartographie révèle souvent des comptes techniques partagés, des applications anciennes difficilement fédérables ou des flux interservices ignorés par les règles réseau. Ces éléments ne bloquent pas nécessairement le projet, mais ils doivent être traités comme des risques explicites.
2. Définir les identités et les signaux de confiance
ZTNA ne signifie pas « faire confiance à l’utilisateur parce qu’il est connecté ». L’identité devient le point de départ d’une décision enrichie par plusieurs signaux : appartenance à un groupe, posture du terminal, localisation approximative, heure de connexion, niveau de risque détecté et sensibilité de l’application.
Avant le pilote, consolidez l’annuaire et activez l’authentification multifacteur pour les comptes concernés. Les comptes à privilèges doivent disposer de règles plus strictes, avec une durée de session courte et une élévation temporaire. L’objectif est de passer d’une autorisation implicite à une politique lisible : une identité, une ressource, un contexte et une action autorisée.
3. Choisir un premier périmètre pilote
Un bon pilote est suffisamment représentatif pour tester les décisions d’accès, mais assez limité pour permettre un retour arrière. Sélectionnez une application interne à forte valeur, utilisée par plusieurs profils et accessible depuis différents contextes. Évitez de commencer par les systèmes les plus critiques ou par une application dont les dépendances sont encore inconnues.
Définissez des indicateurs avant la bascule :
- taux de réussite des connexions et fréquence des demandes d’assistance ;
- temps nécessaire pour créer ou retirer un accès ;
- nombre de règles trop permissives ou constamment contournées ;
- qualité des journaux et capacité à reconstituer une session.
4. Concevoir des politiques d’accès minimales
La politique doit exprimer un besoin métier, pas une topologie réseau. Au lieu d’autoriser un sous-réseau entier, donnez accès à une application précise, à un port nécessaire ou à une fonction déterminée. Séparez les profils de consultation, d’exploitation et d’administration. Pour les prestataires, ajoutez une date d’expiration et une validation par le responsable de la ressource.
Commencez en mode observation lorsque la plateforme le permet. Les journaux montrent les flux réellement utilisés et aident à éviter les interruptions. Ensuite, activez progressivement les refus, en documentant chaque exception. Une règle temporaire doit toujours avoir un propriétaire et une date de révision.
Cette logique de moindre privilège dépasse les seuls outils de cybersécurité. Dans d’autres domaines techniques, comme la rénovation énergétique, la décision pertinente repose elle aussi sur un diagnostic préalable : un devis d’isolation extérieure doit être comparé selon la configuration réelle du bâtiment, les matériaux et les contrôles prévus, plutôt qu’à partir d’un prix isolé.
5. Intégrer les applications et gérer les cas particuliers
Les applications modernes s’intègrent généralement via des protocoles fédérés tels que SAML ou OpenID Connect. Les systèmes plus anciens peuvent nécessiter un connecteur, un proxy applicatif ou une adaptation de leur méthode d’authentification. Il faut alors vérifier les URL, les redirections, les certificats, les flux sortants et les appels entre services.
Les accès SSH, RDP et aux consoles d’administration méritent une attention particulière. Ils doivent être isolés, fortement authentifiés et enregistrés lorsque la réglementation et la politique interne l’exigent. Pour les environnements de développement, privilégiez des identités individuelles et des accès temporaires plutôt que des clés permanentes déposées dans plusieurs scripts.
6. Tester la bascule et préparer le retour arrière
Un test sérieux ne se limite pas à vérifier qu’un utilisateur peut ouvrir une application. Simulez une connexion depuis un terminal conforme puis non conforme, une perte de réseau, une révocation de compte et une modification de groupe. Vérifiez aussi les scénarios de secours : indisponibilité du fournisseur d’identité, expiration d’un certificat ou panne d’un connecteur.
Conservez le chemin d’accès historique pendant une période contrôlée, sans le laisser devenir une échappatoire permanente. Le plan de retour arrière doit préciser qui peut réactiver un accès, pendant combien de temps et avec quelles traces. Cette discipline évite qu’une urgence ne réintroduise durablement une autorisation excessive.
7. Superviser, mesurer et étendre progressivement
Après la mise en production, les journaux ZTNA doivent rejoindre la supervision de sécurité et les outils de détection existants. Analysez les refus inhabituels, les changements de posture, les connexions à des horaires atypiques et les accès à des ressources rarement utilisées. Corrélez ces événements avec ceux de l’annuaire, des terminaux et des applications.
Organisez une revue régulière des politiques. Une règle qui n’a pas été utilisée depuis plusieurs mois peut être supprimée ; une exception récurrente peut révéler un besoin mal modélisé. À mesure que le périmètre s’étend, conservez des modèles de politiques par rôle et par niveau de sensibilité, plutôt qu’une accumulation de règles individuelles.
Le ZTNA comme trajectoire, pas comme produit
Le déploiement d’un accès ZTNA réussi est un programme de transformation : il rapproche identité, sécurité des terminaux, segmentation applicative et observabilité. Les équipes doivent accepter une phase d’apprentissage, mesurer les frictions et expliquer clairement les nouvelles règles aux utilisateurs.
La disparition progressive des VPN traditionnels ne sera donc pas une simple migration technique. Elle prendra la forme d’un remplacement ciblé des accès réseau larges par des connexions applicatives, contextualisées et réversibles. Pour suivre les autres transformations de l’informatique, découvrez les analyses publiées sur notre page d’accueil.