Un VPN étend le réseau privé jusqu’au terminal distant, alors que le ZTNA établit un passage limité vers une application donnée. Leur opposition révèle deux conceptions radicalement différentes de la confiance numérique en entreprise.
Le chiffrement rapproche les deux modèles sans produire les mêmes garanties. La sécurité des ressources dépend de l’étendue accordée après l’authentification plutôt que du tunnel seul. Un accès distant sécurisé réclame un contrôle des connexions fondé sur l’identité, l’état du terminal et la ressource demandée. Le périmètre ne suffit plus.
VPN et ZTNA reposent sur deux modèles d’accès distincts
Le VPN d’accès distant relie votre terminal au système d’information par un point d’entrée central. Il crée un tunnel réseau chiffré jusqu’à une passerelle d’entreprise, puis laisse le routage, les pare-feu et les listes de contrôle définir les destinations joignables. Les échanges restent protégés en transit, mais la session peut exposer plusieurs ressources selon la segmentation retenue et les privilèges associés.
- Le VPN connecte le terminal à un réseau distant.
- Le ZTNA ouvre uniquement le chemin vers un service autorisé.
Pour sa part, le ZTNA adopte une logique différente. Il délivre un accès applicatif ciblé vers un service autorisé, sans ouvrir le réseau qui l’héberge. Cette approche relève d’une architecture Zero Trust plus vaste, laquelle englobe identités, terminaux, données et gouvernance. Les recommandations publiées en mai 2026 par le NCSC britannique rappellent que TLS, IPsec ou même un VPN peuvent transporter ce type d’accès : la différence tient à la portée accordée et à la décision appliquée.
Comment les droits d’accès sont-ils attribués dans chaque architecture ?
Dans un VPN classique, l’authentification ouvre une session dont l’étendue dépend des contrôles placés derrière la passerelle. Les règles réseau autorisent alors un sous-réseau, une plage d’adresses IP ou plusieurs destinations, dessinant un périmètre de connexion plus ou moins large. Des ACL, des pare-feu, la segmentation et l’authentification multifacteur peuvent réduire cette portée ; un VPN ne donne donc pas automatiquement accès à tout le réseau.
Le ZTNA inverse cette logique en évaluant une demande dirigée vers une cible nommée. Ses politiques d’autorisation combinent l’identité, l’état du terminal et d’autres signaux pour accorder un accès par ressource, par exemple à l’application RH, à un service de développement ou à une interface d’administration. Un prestataire utilise ainsi le portail prévu sans obtenir de route vers les serveurs voisins. Si la politique ouvre de vastes plages après une simple authentification, le bénéfice disparaît et le fonctionnement se rapproche d’un VPN classique.
Le ZTNA réduit la connectivité implicite et les mouvements latéraux
Un VPN traditionnel peut exposer à un compte compromis plusieurs ressources joignables par les routes réseau autorisées. L’attaquant dispose alors d’un terrain propice à la reconnaissance des hôtes, au repérage des services vulnérables et au mouvement latéral. Le ZTNA rompt cette connectivité implicite : il établit un chemin vers l’application permise, sans ouvrir l’ensemble du sous-réseau interne visé.
Lors d’une compromission, l’attaquant se heurte ainsi à des frontières d’accès plus étroites. Le rayon d’impact diminue : un salarié habilité pour l’application RH ne peut atteindre ni les serveurs de développement ni les consoles d’administration. Cette protection dépend néanmoins d’une segmentation interne cohérente ; un réseau plat, des politiques trop généreuses ou un VPN résiduel contournant le moteur de décision recréent des passerelles et affaiblissent nettement l’isolation attendue.
À retenir : le ZTNA limite l’accès utile, mais une route VPN large laissée en parallèle peut rétablir la connectivité implicite et agrandir la portée d’une attaque.
Quels signaux alimentent une décision d’accès contextuelle ?
Une demande d’accès est évaluée à partir de plusieurs preuves concordantes, et non du seul mot de passe. Le moteur vérifie l’utilisateur, ses groupes, la solidité de l’authentification multifacteur ainsi que l’identité du terminal. Il examine aussi l’horaire, la localisation habituelle et les écarts de comportement. Selon le résultat, il ouvre uniquement une application précise, réclame une preuve supplémentaire ou refuse immédiatement la session demandée.
L’état de sécurité du poste enrichit l’évaluation pendant toute la durée de connexion. La conformité MDM confirme la présence du chiffrement, du verrouillage et des correctifs requis, tandis que le risque remonté par l’EDR révèle une infection ou une activité suspecte. Si le score se dégrade, l’accès peut être restreint ou révoqué sans attendre une nouvelle connexion. La réévaluation suit une fréquence adaptée à la sensibilité de la ressource et aux capacités de l’architecture déployée.
| Signal analysé | Exemples de vérification | Décision possible |
|---|---|---|
| Utilisateur | Identité, rôle et groupes | Accorder un accès limité |
| Authentification | Méthode employée et robustesse | Demander une vérification supplémentaire |
| Terminal | Appareil reconnu et géré | Autoriser ou bloquer la connexion |
| État de sécurité | Correctifs, chiffrement et alertes EDR | Restreindre ou révoquer l’accès |
| Comportement | Lieu, horaire ou activité inhabituelle | Déclencher une nouvelle évaluation |
La surface d’attaque se déplace vers de nouveaux composants critiques
Un VPN d’accès distant place sa passerelle à la frontière du réseau pour recevoir les connexions des terminaux. Cette passerelle exposée sur Internet constitue une cible directe ; correctifs rapides, durcissement, authentification robuste et cryptographie sûre limitent les possibilités d’intrusion. En juin 2024, la CISA, le FBI et leurs partenaires recommandaient d’étudier Zero Trust, SSE ou SASE pour réduire les faiblesses liées aux VPN traditionnels et à leurs configurations défaillantes encore rencontrées.
Le ZTNA inverse le schéma : ses composants proches des applications initient les communications vers le service d’accès, sans port entrant publiquement accessible. Ces connecteurs sortants réduisent l’exposition directe, mais ne suppriment ni les failles ni les dépendances. La confiance se concentre désormais sur le fournisseur, l’Identity Provider, les agents installés et le moteur de politique qui autorise chaque session. Comptes d’administration, mises à jour et journaux réclament une protection rigoureuse, car une compromission pourrait toucher des applications.
Le ZTNA offre-t-il toujours de meilleures performances que le VPN ?
La performance dépend moins de l’étiquette technologique que du chemin réellement suivi par chaque flux. Un VPN en tunnelisation complète renvoie les accès privés et Internet vers une passerelle centrale, ce qui peut charger le concentrateur et augmenter la latence réseau lorsque l’utilisateur travaille loin du datacenter. À l’inverse, la tunnelisation fractionnée réserve le tunnel aux flux définis ; elle raccourcit certains trajets, au prix d’une visibilité de sécurité différente. Quatre paramètres méritent une mesure :
- la distance entre l’utilisateur et l’infrastructure d’accès ;
- la capacité des passerelles, proxys et liaisons ;
- le nombre d’inspections appliquées au trafic ;
- le chemin vers les applications privées ou SaaS.
Le ZTNA peut rapprocher l’accès des utilisateurs et acheminer seulement les échanges destinés aux applications privées. Le résultat dépend pourtant de la répartition des points de présence, du placement des proxys, de leur capacité et des inspections appliquées. Un nœud éloigné ou saturé peut créer plus de détour qu’un VPN proche et correctement dimensionné. Comparez depuis les lieux d’usage le temps d’établissement, le débit, la stabilité et la réponse applicative par protocole.
L’expérience utilisateur varie selon les applications et les protocoles
Pour l’utilisateur, le passage du VPN au ZTNA peut effacer plusieurs gestes techniques sans modifier ses habitudes de travail. L’authentification unique fédère l’ouverture de session et évite la répétition des identifiants, tandis qu’un agent d’accès permanent reconnaît les flux autorisés en arrière-plan. L’accès paraît alors direct, à condition que le terminal respecte les règles définies et que la vérification d’identité reste discrète.
Les usages sans client se révèlent adaptés aux services web consultés directement depuis un navigateur. Leur publication derrière un proxy applicatif simplifie l’accès sans logiciel local. Les applications métiers empruntant des flux TCP ou UDP privés réclament parfois un agent, un connecteur dédié ou une prise en charge native. L’UDP, dépourvu de session, complique certains contrôles ; le TCP tolère mieux l’inspection, mais les outils sensibles à la latence ou aux ruptures de session peuvent perdre en fluidité.
À retenir : un accès web peut rester transparent, tandis que certains flux TCP ou UDP privés nécessitent un agent installé sur le terminal.
Dans quels cas le ZTNA peut-il remplacer un VPN ?
Le remplacement fonctionne bien lorsque chaque personne doit rejoindre des services précisément identifiés, sans obtenir de visibilité sur le réseau interne. Les applications privées web ou client-serveur compatibles se prêtent à des politiques fondées sur l’identité, le terminal et la ressource demandée. L’accès des sous-traitants gagne ainsi en finesse : chaque prestataire atteint son outil métier, sans tunnel ouvrant des plages d’adresses plus larges.
Le VPN garde sa place dès qu’un usage exige une extension du réseau, au-delà de quelques ressources publiées. Les protocoles réseau anciens, les outils dépendants de la découverte locale ou les équipements incompatibles avec un agent ZTNA peuvent imposer un tunnel classique. Une connexion de site à site repose encore sur IPsec pour relier deux infrastructures. Segmentation et filtrage limitent alors les destinations afin d’éviter tout droit général. Cette coexistence couvre les besoins résiduels sans étendre les autorisations accordées aux utilisateurs distants.
Une migration progressive doit aboutir à des politiques de moindre privilège
La transition gagne en précision lorsqu’elle avance application par application, plutôt que par bascule globale du réseau. Un inventaire des applications, enrichi de leurs flux, dépendances, propriétaires et populations autorisées, révèle les accès réellement nécessaires et les services encore liés au VPN. Chaque règle peut alors associer une identité fiable, vérifiée par MFA, à une ressource définie. Cette démarche transforme progressivement les droits historiques en politiques de moindre privilège, lisibles, limitées et faciles à révoquer.
Le déploiement reste réversible durant les tests, mais sa cible ne doit laisser aucun passage parallèle. Les contrôles de santé des terminaux intègrent la conformité MDM, le chiffrement, la version du système et les alertes EDR avant l’autorisation. Une journalisation centralisée relie l’identité, l’appareil, la ressource, la décision et sa justification. Supprimer les routes directes, règles statiques et VPN étendus ferme les contournements qui préserveraient un accès implicite au réseau interne.