VPN vs Zero Trust : quelle stratégie d’accès distant pour une entreprise sans périmètre fixe ?

Pour un architecte réseau, la scène est devenue familière : des collaborateurs se connectent depuis leur domicile, un café, ou un espace de coworking, accédant à des applications hébergées sur site, dans un cloud public et en mode SaaS. Le périmètre de l’entreprise n’est plus un mur de château-fort, mais une mosaïque éclatée de points d’accès. La réponse traditionnelle à ce défi a longtemps été de multiplier les tunnels VPN, étendant virtuellement le réseau de l’entreprise jusqu’au PC de chaque utilisateur. Mais cette approche, héritée d’un monde où les frontières étaient claires, a créé une faille béante dans nos infrastructures modernes.

En accordant une confiance implicite à tout appareil authentifié, le VPN offre bien plus qu’un simple accès à une application : il ouvre une porte sur l’ensemble du réseau interne. Cette confiance aveugle est le talon d’Achille de la sécurité périmétrique. La véritable question n’est plus « comment connecter nos utilisateurs au réseau ? », mais plutôt « qui a le droit d’accéder à quoi, et sous quelles conditions strictes ? ». C’est ici que le paradigme Zero Trust Network Access (ZTNA) ne se présente pas comme une simple alternative, mais comme une réponse architecturale fondamentalement différente et bien plus adaptée aux réalités actuelles.

Cet article n’est pas une simple comparaison technique. C’est une déconstruction des scénarios de risque que le modèle VPN engendre au quotidien et une démonstration pragmatique de la manière dont le Zero Trust y répond, point par point. Nous allons passer de la théorie à la pratique, en analysant les vulnérabilités opérationnelles que tout architecte réseau cherche à éliminer.

Pour naviguer à travers cette refonte architecturale, nous aborderons les concepts clés qui opposent ces deux visions, des limites du périmètre traditionnel à l’automatisation de la gestion des identités, le nouveau pilier de la sécurité.

Pourquoi le modèle périmétrique classique ne protège plus vos données dans le Cloud ?

Le modèle de sécurité périmétrique, symbolisé par le pare-feu et le VPN, repose sur une idée simple : tout ce qui est à l’intérieur est fiable, tout ce qui est à l’extérieur est suspect. Cette approche du « château-fort » a fonctionné tant que les actifs de l’entreprise (serveurs, données, utilisateurs) restaient bien sagement derrière les remparts. Aujourd’hui, cette vision est une illusion. Avec l’adoption massive du cloud, les données et applications sont dispersées. Selon une étude, 94% des entreprises utilisent au moins un service cloud, créant un SI hybride et distribué.

Cette dispersion a généré une « dette de complexité » colossale. Tenter de protéger ce patchwork de services avec des murailles classiques revient à vouloir contenir un océan avec des digues percées. Chaque nouveau service SaaS, chaque nouvelle instance cloud est une brèche potentielle dans un périmètre qui n’existe plus vraiment. Pire, cette complexité nourrit une autre forme de dette. En effet, des analyses montrent qu’entre 25 à 30% du budget IT annuel est englouti par la dette technique, un chiffre qui grimpe à 40% dans les organisations multi-systèmes.

Le Zero Trust prend le contre-pied de cette logique. Il part du principe qu’il n’y a plus d’intérieur ou d’extérieur. Le réseau est considéré comme hostile par défaut. La sécurité ne repose plus sur la localisation de l’utilisateur, mais sur la vérification systématique de son identité et du contexte de chaque demande d’accès. Le périmètre n’est plus un mur, mais une bulle de protection dynamique autour de chaque application et de chaque donnée.

Comment configurer votre DMZ pour exposer vos services web sans mettre en danger le réseau interne ?

La Zone Démilitarisée (DMZ) est un autre pilier de l’architecture périmétrique. C’est un sous-réseau isolé qui héberge les serveurs devant être accessibles depuis Internet (serveurs web, mail…). L’idée est de créer une zone tampon : si un serveur en DMZ est compromis, l’attaquant ne peut pas, en théorie, atteindre le réseau interne. Cependant, dans la pratique, la DMZ est une surface d’attaque volontairement exposée. Les services écoutent sur des ports ouverts, attendant des connexions. Pour un attaquant, c’est une vitrine de cibles potentielles.

L’approche Zero Trust renverse complètement ce concept avec ce que l’on pourrait appeler une « DMZ inversée ». Au lieu d’exposer des services, le ZTNA les rend totalement invisibles sur Internet. Les applications n’ont aucun port d’écoute ouvert. Elles établissent uniquement des connexions sortantes vers le broker ZTNA. Un utilisateur autorisé ne se connecte pas directement à l’application, mais au service ZTNA, qui, après une authentification et une vérification rigoureuses, établit le pont vers l’application demandée. C’est le principe du « dark cloud » : ce qui n’est pas explicitement autorisé à être vu reste invisible.

Cette différence architecturale est fondamentale pour la réduction des risques, comme le montre cette comparaison.

Le ZTNA ne se contente pas de déplacer la DMZ ; il en élimine le besoin en traitant chaque application comme une île isolée, accessible uniquement via un pont-levis contrôlé dynamiquement.

L’erreur de donner un accès VPN complet à un fournisseur de maintenance CVC

L’un des cas d’usage les plus dangereux du VPN concerne l’accès des tiers : prestataires, fournisseurs, consultants. La pratique courante consiste à leur fournir un compte VPN pour qu’ils puissent intervenir sur un équipement spécifique. Le problème ? Une fois connecté, ce tiers est « sur le réseau ». Même si ses droits sont limités, il a une visibilité sur le réseau interne, ce qui ouvre la porte au mouvement latéral. L’exemple le plus tristement célèbre est la cyberattaque massive contre l’enseigne Target en 2013, où l’accès initial a été obtenu via le compte VPN d’un sous-traitant en charge de la climatisation (CVC). Le résultat fut le vol de 40 millions de données bancaires et 70 millions de données personnelles.

Ce scénario illustre parfaitement la faille de la confiance implicite du VPN. En donnant les clés du portail, on donne accès à la cour du château. Le Zero Trust, à l’inverse, n’accorde jamais les clés du royaume. Pour ce même prestataire CVC, une approche ZTNA consisterait à créer un accès ultra-restreint et éphémère. L’accès ne serait autorisé qu’à une seule application ou une seule adresse IP/port, depuis une source identifiée, pour une durée limitée, et après une authentification forte. Une fois l’intervention terminée, l’accès est automatiquement détruit. La surface d’attaque est réduite à une seule porte, pour une seule personne, pendant un temps défini.

Comme le montre cette visualisation, l’approche Zero Trust crée une bulle d’accès minimaliste et contrôlée pour chaque intervenant externe, empêchant toute possibilité de reconnaissance ou de mouvement latéral sur le réseau. L’impact financier d’une telle brèche est énorme ; Target a dépensé plus de 61 millions de dollars en réponse à l’incident, sans compter les coûts indirects.

SSL Inspection : comment voir ce qui se cache dans le trafic HTTPS sans tuer la performance ?

Une grande partie du trafic Internet est aujourd’hui chiffrée en HTTPS. C’est une excellente chose pour la confidentialité, mais un casse-tête pour la sécurité. Comment détecter les menaces (malwares, exfiltration de données) si elles se cachent dans un tunnel chiffré ? La méthode traditionnelle est l’inspection SSL/TLS (aussi appelée « Man-in-the-Middle » légitime). Un boîtier de sécurité central (proxy, pare-feu) déchiffre le trafic, l’inspecte, puis le rechiffre avant de l’envoyer à sa destination. Cette méthode est lourde, coûteuse en ressources et crée un goulot d’étranglement qui dégrade les performances.

De plus, elle pose des problèmes de confidentialité et de conformité, notamment avec les flux bancaires ou de santé. Le Zero Trust propose des alternatives plus modernes et distribuées, en phase avec la demande croissante pour ces technologies. Selon les prévisions, on observe une demande accrue de 50% pour les services Zero Trust, qui intègrent des approches plus intelligentes :

• Inspection distribuée : Au lieu d’un point de contrôle central, l’inspection est réalisée au plus près de l’utilisateur, via un agent local sur le poste de travail ou un point de présence cloud (edge). Cela évite les goulots d’étranglement.
• Analyse des métadonnées : Il n’est pas toujours nécessaire de déchiffrer le contenu pour détecter une menace. L’analyse des métadonnées du trafic (comme les empreintes JA3/JA3S qui caractérisent la session TLS) peut révéler des communications avec des serveurs de commande et de contrôle connus, sans violer la confidentialité du flux.
• Intégration CASB/API : Pour les applications SaaS, les plateformes CASB (Cloud Access Security Broker) peuvent analyser les flux de données directement via les API, offrant une visibilité profonde sans inspecter le trafic réseau.

En combinant ces techniques, le ZTNA offre une visibilité granulaire sur les menaces potentielles, tout en préservant la performance et la confidentialité, un équilibre que l’inspection SSL centralisée peine à atteindre.

Quand bloquer une IP : automatiser la réponse aux scans de ports incessants

Tout administrateur réseau connaît le bruit de fond incessant des scans de ports et des tentatives de connexion automatisées. La réponse classique consiste à maintenir des listes noires d’adresses IP malveillantes (threat intelligence feeds) et à bloquer manuellement ou via un script les IP les plus agressives. C’est un jeu du chat et de la souris épuisant et peu efficace. Les attaquants utilisent des botnets avec des milliers d’IP tournantes, rendant le blocage d’une seule adresse presque inutile.

L’approche Zero Trust est, encore une fois, fondamentalement différente. Premièrement, comme les applications sont invisibles par défaut, un scan de ports ne révèle… rien. Il n’y a pas de service à l’écoute. La surface d’attaque est nulle. Deuxièmement, la décision de bloquer ou non un accès ne repose plus sur le seul critère de l’adresse IP. Le ZTNA utilise une analyse comportementale et contextuelle, qui évalue une multitude de signaux de risque en temps réel pour chaque tentative d’accès.

Cette approche dynamique et proactive rend les méthodes de blocage traditionnelles obsolètes.

Au lieu d’un simple « bloquer/autoriser », le ZTNA peut moduler sa réponse. Si le score de risque est moyen (par exemple, un employé se connectant depuis un pays inhabituel), le système peut exiger une authentification multifacteur (MFA) supplémentaire au lieu d’un blocage pur et simple. C’est ce qu’on appelle l’authentification adaptative.

VPN Client-to-Site : comment garantir que le PC du télétravailleur n’infecte pas le réseau principal ?

Le VPN Client-to-Site étend le réseau de l’entreprise jusqu’à l’ordinateur portable du télétravailleur. Si cet ordinateur est compromis par un malware, le VPN devient une autoroute directe pour que l’infection se propage au sein du réseau principal. Le VPN authentifie l’utilisateur, pas la machine. Une fois la connexion établie, il fait une confiance aveugle à l’état du terminal. C’est l’un des risques les plus critiques du télétravail massif.

Le Zero Trust résout ce problème en intégrant le concept de contrôle de posture de l’appareil (device posture check) à chaque demande d’accès. Avant d’autoriser la connexion à une application, le système ZTNA vérifie en temps réel l’état du terminal. Est-ce que l’antivirus est à jour et actif ? Le système d’exploitation a-t-il les derniers patchs de sécurité ? Y a-t-il des processus suspects en cours d’exécution ? Si un seul de ces critères n’est pas rempli, l’accès est refusé ou limité, même si l’utilisateur a fourni les bons identifiants.

Cette vérification n’a pas lieu qu’une seule fois à la connexion. Elle est continue. Comme le démontre une approche comme l’accès Just-In-Time (JIT), si une anomalie est détectée sur le poste de travail en cours de session, l’accès peut être révoqué instantanément. Le ZTNA ne se contente pas de vérifier qui vous êtes, il vérifie en permanence que l’appareil que vous utilisez est digne de confiance. C’est la fin du laissez-passer permanent qu’offre le VPN.

RBAC vs ABAC : quelle méthode de gestion des droits choisir pour une PME en croissance ?

La gestion des droits d’accès est un autre domaine où les approches traditionnelles montrent leurs limites. Le modèle le plus courant est le RBAC (Role-Based Access Control), où les permissions sont associées à des rôles (ex: « Comptable », « Développeur »). C’est un bon début, mais ce modèle est rigide. Que se passe-t-il si un comptable doit exceptionnellement accéder à un outil de développeur ? On crée des exceptions, des rôles temporaires, et la matrice des droits devient vite un cauchemar à maintenir.

Le Zero Trust s’appuie sur une évolution bien plus granulaire et dynamique : l’ABAC (Attribute-Based Access Control). Ici, la décision d’accès n’est pas basée sur un rôle statique, mais sur une combinaison d’attributs en temps réel. Ces attributs peuvent concerner :

• L’utilisateur : son rôle, son département, son niveau hiérarchique.
• La ressource : la sensibilité de la donnée, son emplacement.
• L’environnement : l’heure de la journée, la géolocalisation de l’utilisateur.
• L’appareil : sa posture de sécurité (géré par l’entreprise, patché, etc.).

Une règle ABAC pourrait ressembler à : « Autoriser l’accès à l’application ‘SAP-Finance’ uniquement si l’utilisateur a le rôle ‘Comptable’, se connecte depuis la France, entre 8h et 18h, et depuis un appareil géré par l’entreprise ». Cette granularité est la seule capable de faire appliquer le principe du moindre privilège de manière réaliste dans un environnement complexe. L’adoption du Zero Trust est d’ailleurs en pleine explosion, ce qui confirme l’intérêt pour ces modèles : selon une étude, 61% des entreprises ont déjà mis en œuvre une initiative Zero Trust en 2023, une hausse spectaculaire par rapport aux 24% de 2021.

IAM : comment automatiser l’arrivée et le départ des collaborateurs pour finir avec les comptes fantômes ?

Si l’identité est le nouveau périmètre, alors la gestion des identités et des accès (IAM) devient le cerveau de la stratégie de sécurité. Dans un modèle Zero Trust, chaque décision d’accès est orchestrée par le système IAM. C’est lui qui valide l’identité, qui interroge les attributs pour une décision ABAC, et qui déclenche l’authentification adaptative si nécessaire. Un IAM robuste est donc un prérequis absolu pour le ZTNA.

L’un des plus grands défis de l’IAM est la gestion du cycle de vie des utilisateurs, notamment les arrivées et les départs. Dans de nombreuses entreprises, la création et la révocation des comptes sont des processus manuels. Le résultat ? Des retards dans l’accès pour les nouveaux arrivants et, bien pire, des « comptes fantômes » ou « orphelins » qui restent actifs bien après le départ d’un collaborateur. Ces comptes sont une mine d’or pour les attaquants.

L’automatisation du provisioning et du déprovisioning est la solution. En connectant le système IAM directement au Système d’Information des Ressources Humaines (SIRH), les droits d’accès sont créés, modifiés et révoqués automatiquement en fonction des changements de statut de l’employé (arrivée, changement de poste, départ). Cette automatisation élimine virtuellement le risque de comptes fantômes et garantit que les droits correspondent toujours au poste actuel de la personne. Sans surprise, les entreprises investissent massivement : 80% des organisations ont augmenté leur budget Zero Trust, et pour 20% d’entre elles, cette augmentation a dépassé les 25%.

En définitive, le passage du VPN au Zero Trust n’est pas qu’une question de technologie, mais de philosophie. Pour sécuriser un monde sans frontières, l’étape suivante consiste à auditer vos propres processus d’accès et à identifier où la « confiance implicite » met votre organisation en danger.