Les erreurs Zero Trust qui recréent un VPN invisible

Le Zero Trust devait mettre fin à une habitude tenace : considérer comme fiables les utilisateurs et les appareils dès lors qu’ils se trouvent derrière un périmètre réseau. Pourtant, de nombreux déploiements ZTNA reproduisent exactement les réflexes du VPN traditionnel. Le tunnel change de nom, l’interface se modernise, mais l’accès reste large, permanent et difficile à contrôler.

Cette contradiction n’est pas seulement théorique. Elle augmente la surface d’attaque, complique les investigations et donne aux équipes une fausse impression de segmentation. Pour éviter ce « VPN invisible », il faut distinguer une authentification moderne d’une véritable architecture d’accès adaptatif.

1. Confondre ZTNA et nouveau portail VPN

La première erreur consiste à installer une solution ZTNA sans revoir le modèle d’accès. Si l’utilisateur s’authentifie une fois, lance un agent, puis découvre toutes les applications internes autorisées par son profil, le principe « ne jamais faire confiance, toujours vérifier » reste largement théorique.

Un accès Zero Trust devrait être accordé à une ressource précise, pour une action précise et dans un contexte donné. L’identité n’est qu’un signal parmi d’autres : état du terminal, niveau de risque, localisation inhabituelle, heure de connexion, sensibilité de l’application ou comportement observé doivent aussi peser dans la décision.

2. Accorder des droits trop larges

Les groupes hérités de l’annuaire sont pratiques, mais ils deviennent dangereux lorsqu’ils déterminent seuls les politiques d’accès. Un groupe « développeurs » ou « support » ne décrit pas le besoin réel d’une personne à un instant donné. Il peut surtout conserver des privilèges accumulés au fil des changements de poste et des projets.

La microsegmentation doit donc s’appuyer sur les ressources et les flux métier, pas uniquement sur les rôles administratifs. Une politique plus robuste pourrait autoriser une connexion à une base de test, depuis un terminal géré, uniquement pendant une fenêtre de maintenance et via une procédure renforcée.

• Découper les applications plutôt que les seuls sous-réseaux ;
• Limiter les ports, protocoles et méthodes d’administration ;
• Accorder des privilèges temporaires et révocables ;
• Revoir régulièrement les droits réellement utilisés.

3. Oublier le terminal dans l’équation

Vérifier un mot de passe et un second facteur ne suffit pas si l’appareil utilisé est compromis. Un poste personnel non chiffré, un navigateur obsolète ou une session administrateur ouverte constituent des signaux de risque que l’architecture doit savoir exploiter.

Le contrôle de posture ne doit cependant pas devenir une simple case à cocher. Il doit combiner la gestion des correctifs, le chiffrement, la présence d’un agent de protection, la version du système et l’intégrité des mécanismes d’authentification. Une politique adaptative peut réduire les privilèges, imposer une authentification résistante au phishing ou bloquer l’accès lorsqu’un indicateur critique apparaît.

4. Remplacer la confiance réseau par la confiance dans l’identité

Le Zero Trust déplace le centre de gravité vers l’identité, mais cela ne signifie pas que l’identité est infaillible. Un compte légitime volé peut contourner un contrôle purement déclaratif, surtout lorsque les sessions sont longues et les jetons peu surveillés.

La détection doit donc continuer après l’ouverture de session. L’analyse des connexions, des volumes transférés, des commandes exécutées et des changements de contexte permet de repérer une utilisation anormale. Il faut également prévoir une révocation rapide des sessions et des jetons, sans attendre la prochaine reconnexion.

Dans cette perspective, la journalisation n’est pas une fonction secondaire. Les décisions d’accès, leurs motifs, les signaux évalués et les ressources consultées doivent être exportés vers une plateforme de supervision. Sans ces traces, impossible de comprendre pourquoi une politique a autorisé une action ou de démontrer qu’une mesure corrective a été efficace.

5. Négliger les accès machine à machine

Les discussions Zero Trust se concentrent souvent sur les collaborateurs, alors que les identités non humaines se multiplient : comptes de service, pipelines d’intégration continue, API, robots d’automatisation et charges de travail dans le cloud. Leur donner une connectivité permanente revient à maintenir des portes dérobées particulièrement attractives.

Chaque service devrait disposer d’une identité propre, d’un secret à durée de vie courte et d’un périmètre minimal. Les communications entre applications doivent être authentifiées et autorisées indépendamment de leur emplacement réseau. Cette approche est plus exigeante au départ, mais elle évite qu’une compromission latérale transforme un simple jeton technique en accès transversal.

Cette logique de contrôle contextuel dépasse d’ailleurs les seuls systèmes d’entreprise. Lorsqu’on prépare une itinérance numérique, il devient tout aussi important de choisir des services fiables, de protéger ses appareils et de limiter les données exposées, comme le suggère Le Guide de l'Auxois lorsqu’il aborde les usages numériques responsables pendant un déplacement. Le contexte change, mais le principe reste identique : réduire la confiance implicite.

Vers un Zero Trust mesurable

Une architecture crédible ne se juge pas au nombre de fonctionnalités affichées par un produit, mais à ses résultats opérationnels. Les équipes doivent suivre le nombre de ressources réellement segmentées, la durée moyenne des privilèges, les accès refusés, les exceptions actives et le délai de révocation d’une session compromise.

Le déploiement peut progresser par étapes :

• Cartographier les applications, dépendances et identités avant de modifier les routes ;
• Commencer par un périmètre sensible et définir des politiques explicites ;
• Passer d’un accès réseau à un accès applicatif, ressource par ressource ;
• Tester les scénarios de panne, de compromission et de perte de connectivité ;
• Mesurer les résultats puis supprimer progressivement les anciens tunnels.

Le but n’est pas de rendre chaque connexion plus pénible. Il s’agit de rendre les décisions plus précises, plus visibles et plus réversibles. Une authentification forte, une segmentation fine et une surveillance continue doivent fonctionner ensemble ; isolées, elles ne font que déplacer le risque.

Le VPN invisible apparaît lorsque l’organisation conserve une logique de réseau de confiance derrière une façade Zero Trust. Pour l’éviter, il faut penser en ressources, en sessions et en signaux de risque plutôt qu’en zones internes. Retrouvez d’autres analyses sur les mutations de la cybersécurité et du logiciel depuis notre page d’accueil.