Zero Trust expliqué simplement : ZTNA au lieu du VPN classique
Zero Trust ne signifie pas que l’on ne fait plus confiance à personne. Cela signifie que l’accès n’est plus accordé globalement simplement parce qu’un utilisateur se trouve dans le réseau interne, dans le VPN ou à un emplacement connu. Chaque accès est vérifié consciemment : qui accède ? Depuis quel appareil ? À quelle application ? Dans quelles conditions ?
Zero Trust Network Access, ou ZTNA, est une mise en œuvre concrète de cette idée pour l’accès à distance et les applications privées. Au lieu d’ouvrir tout un réseau via VPN, un utilisateur reçoit uniquement l’accès aux applications ou ressources prévues pour son rôle.
Cet article explique les bases de manière volontairement neutre vis-à-vis des fournisseurs. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access et d’autres solutions appliquent des principes similaires de différentes manières. La première décision n’est donc pas le produit, mais le modèle d’accès.
Situer Zero Trust et ZTNA
Zero Trust est une architecture de sécurité. ZTNA est un chemin d’accès technique dans cette architecture.
Zero Trust est un principe
Les réseaux classiques fonctionnent souvent avec une hypothèse implicite : l’intérieur est plus fiable que l’extérieur. Cette hypothèse est dangereuse aujourd’hui. Les utilisateurs travaillent en mobilité, les applications se trouvent dans SaaS, datacenter et cloud, les appareils changent constamment d’emplacement et les identifiants compromis sont un scénario réaliste.
Zero Trust déplace le focus des frontières réseau vers identité, appareil, application, données et contexte. NIST décrit Zero Trust comme une architecture qui réduit la confiance implicite et évalue l’accès par requête. En pratique, une connexion réussie ne suffit plus.
ZTNA est l’accès à des ressources concrètes
ZTNA remplace les accès réseau larges par un accès basé sur les ressources. Un utilisateur ne voit pas automatiquement tout un sous-réseau, mais seulement les applications pour lesquelles une policy correspond.
Les ressources ZTNA typiques sont :
- applications web internes,
- portails d’administration,
- accès RDP ou SSH via des chemins contrôlés,
- applications TCP individuelles,
- accès développement, support ou partenaires,
- applications SaaS avec contrôle d’accès supplémentaire.
L’accès à distance devient ainsi plus fin. Un compte compromis ne doit pas pouvoir atteindre immédiatement tout le réseau interne.
Pourquoi ZTNA est différent du VPN
VPN n’est pas automatiquement mauvais. De nombreux environnements ont encore besoin de site-to-site VPN, admin VPN, protocoles spéciaux ou accès d’urgence. La différence tient au modèle de confiance.
VPN ouvre souvent un réseau
Un remote access VPN classique connecte un appareil à un réseau interne. Ensuite, routing, règles firewall, DNS et segmentation décident ce qui est joignable. Si l’environnement est bien construit, cela peut fonctionner. En pratique, les réseaux VPN sont souvent trop larges, historiques ou difficiles à contrôler.
Risques typiques :
- Les utilisateurs obtiennent accès à plus de systèmes que nécessaire.
- D’anciens groupes VPN restent en place.
- Split tunnel, DNS et routes ne sont pas clairs.
- Un malware sur un client VPN peut atteindre des cibles internes.
- Les accès admin utilisent le même tunnel que les accès utilisateurs.
ZTNA contrôle plus près de l’application
ZTNA décide par application ou ressource. Une policy peut tenir compte du groupe utilisateur, MFA, appareil, emplacement, risque, état du client et d’autres conditions. Ce n’est que lorsque les conditions correspondent que l’accès à cette ressource précise est autorisé.
Cela réduit la surface d’attaque, mais ne remplace pas une application sécurisée. Une application non sécurisée reste non sécurisée, même derrière ZTNA. ZTNA contrôle l’accès, pas automatiquement l’application elle-même.
Composants d’un bon environnement Zero Trust
Zero Trust est faible s’il est introduit seulement comme nouvel outil d’accès. La valeur apparaît lorsque plusieurs composants fonctionnent ensemble.
Identité et MFA
L’identité est le point d’entrée le plus important. Utilisateurs, groupes, rôles et comptes externes doivent être propres. MFA devrait être obligatoire pour les accès critiques. Dans les environnements Microsoft, Microsoft Entra ID est souvent la source d’identité centrale ; dans d’autres environnements, d’autres Identity Providers peuvent jouer le même rôle.
L’offboarding est tout aussi important. Lorsqu’un utilisateur quitte l’entreprise, l’accès doit disparaître non seulement dans une application, mais aussi dans l’identité centrale et toutes les policies pertinentes.
Appareil et contexte
ZTNA devient plus fort lorsque l’appareil est évalué en plus de l’utilisateur. Selon la solution, système d’exploitation, état de l’appareil, certificat, statut EDR, statut de gestion, emplacement ou risque peuvent influencer la décision.
C’est particulièrement important pour :
- appareils privés,
- prestataires externes,
- accès admin privilégiés,
- accès aux systèmes finance, RH ou production,
- appareils sans statut de protection actuel.
Gateway, connector ou service cloud
ZTNA a besoin d’un chemin de données entre utilisateur et application. Selon le fournisseur, il existe gateways, connectors, tunnels ou cloud PoPs. Cette partie décide où le trafic entre, qui exploite le chemin de données et quelles règles DNS, certificats et firewall sont nécessaires.
Cloudflare fonctionne souvent avec Cloudflare Tunnel et Access Policies. Sophos ZTNA utilise Sophos Central, ZTNA Gateways et policies de ressources. L’architecture diffère, mais la question de base reste la même : comment un utilisateur atteint-il l’application de manière contrôlée sans ouvrir tout le réseau ?
Policies, logging et exploitation
Une policy ZTNA doit rester compréhensible plus tard. Les noms, groupes, conditions et exceptions doivent donc être documentés. Le logging est obligatoire, sinon on ne voit pas si une policy est trop large, si des utilisateurs sont bloqués ou si un accès est utilisé de façon inattendue.
Quand ZTNA est pertinent
ZTNA convient particulièrement lorsque des applications individuelles doivent être accessibles de manière contrôlée. Ce n’est pas une fin en soi ni un remplacement automatique de toute connexion.
Bons cas d’usage
ZTNA est généralement pertinent pour :
- applications web internes pour collaborateurs,
- accès partenaires ou prestataires,
- portails admin qui ne doivent pas être publics,
- RDP ou SSH via chemins d’accès contrôlés,
- applications avec groupes utilisateurs clairs,
- environnements où l’accès VPN est devenu trop large,
- remplacement progressif d’anciens modèles remote access.
Pour les prestataires externes, ZTNA est souvent plus confortable que VPN. Il n’est pas nécessaire d’ouvrir tout un réseau ; une application concrète peut être publiée avec une policy claire.
Où VPN reste adapté
VPN reste utile lorsque des réseaux entiers doivent être reliés, lorsque des protocoles spéciaux ne fonctionnent pas correctement via ZTNA ou lorsqu’un accès d’urgence doit être indépendant des services cloud. Les liaisons site-to-site, certains environnements OT, applications legacy et scénarios admin complexes peuvent encore nécessiter VPN.
La bonne question n’est donc pas : « VPN ou ZTNA ? » Mieux vaut demander : « Quelle ressource a besoin de quel chemin d’accès ? »
Évaluer les fournisseurs de manière neutre
Les solutions ZTNA diffèrent fortement. Certaines sont très bonnes pour les applications basées navigateur, d’autres pour les accès client, d’autres encore comme partie d’une plateforme SSE ou SASE plus large.
Critères de choix importants
Avant le choix produit, clarifier :
- Quelles applications doivent être accessibles ?
- Faut-il un accès navigateur, client ou les deux ?
- Quel Identity Provider est déjà en place ?
- Les appareils doivent-ils être vérifiés selon leur posture ?
- Où passe le chemin de données : site propre, cloud fournisseur ou les deux ?
- Comment fonctionnent logs, export SIEM et audit ?
- Les processus d’urgence et break-glass sont-ils clairs ?
- La solution s’intègre-t-elle bien aux firewalls, EDR, MDM et DNS existants ?
Cloudflare est souvent fort lorsque Access, Tunnel, DNS, web security et infrastructure edge globale doivent fonctionner ensemble. Sophos ZTNA convient souvent aux environnements qui utilisent déjà fortement Sophos Central, Sophos Endpoint ou Sophos Firewall. Ce n’est pas une question de croyance, mais d’architecture.
Tout Zero Trust n’est pas automatiquement meilleur
Un ZTNA mal entretenu n’est qu’un risque plus moderne. Si les groupes sont trop larges, que d’anciennes exceptions restent, que personne ne lit les logs ou que la vérification des appareils n’existe que sur le papier, aucun environnement Zero Trust solide n’est créé.
Introduire dans le bon ordre
Une bonne introduction ne commence pas par un clic produit, mais par une petite application bien comprise.
- Inventorier les applications et les trier par risque.
- Nettoyer les groupes utilisateurs et rôles externes.
- Stabiliser Identity Provider et MFA.
- Choisir une application pilote importante mais maîtrisable.
- Planifier chemin de données, DNS, certificat et logging.
- Tester la policy avec un petit groupe d’utilisateurs.
- Vérifier les logs, collecter les cas support et améliorer l’expérience utilisateur.
- Migrer d’autres applications par étapes.
- Réduire les accès VPN seulement lorsque ZTNA fonctionne en exploitation.
Pour les environnements Sophos, Configurer Sophos ZTNA : vue d’ensemble et ordre est l’étape suivante. Pour le gateway, Planifier et créer Sophos ZTNA Gateway aide.
Erreurs typiques
Traiter ZTNA comme un simple remplacement VPN
Si seul le tunnel est remplacé, mais que groupes, applications, appareils et logs restent inchangés, le gain de sécurité est faible. ZTNA doit être planifié par ressource.
Migrer trop d’applications à la fois
Un grand rollout big-bang est risqué. Un pilote avec une vraie application, des critères de succès clairs et un retour arrière propre est préférable.
Oublier l’accès d’urgence
Identity Provider, DNS, service cloud ou gateway peuvent tomber en panne. Les admins ont besoin d’un accès break-glass documenté, fortement protégé, rarement utilisé et régulièrement vérifié.
Ne pas exploiter les logs
ZTNA sans logging est difficile à supporter. Il faut voir quel utilisateur accède à quelle ressource, quelle policy s’applique, pourquoi un accès a été bloqué et si des schémas inhabituels apparaissent.
Checklist d’exploitation
- Documenter applications et owners.
- Garder les groupes utilisateurs petits et compréhensibles.
- Imposer MFA pour les accès critiques.
- Utiliser activement la vérification des appareils si la solution la supporte proprement.
- Vérifier régulièrement les policies face à l’usage réel.
- Envoyer les logs vers SIEM ou logging central si l’accès est critique.
- Documenter et tester l’accès break-glass.
- Supprimer les anciennes autorisations VPN après migration réussie.
- Donner aux accès prestataires une date d’expiration ou de review.