Alternatives zero trust au VPN pour la défense : ZTNA, périmètres définis par logiciel et proxys sensibles à l'identité

Les VPN hérités ont été conçus pour un périmètre réseau qui n'existe plus. Lorsque chaque application résidait dans un centre de données et que chaque utilisateur était installé à un poste de travail géré sur un sous-réseau connu, accorder un large accès par tunnel au réseau de l'organisation était une posture défendable. Les architectures de défense modernes -- avec des charges de travail réparties entre enclaves sur site, cloud classifié, nœuds avancés déployés et postes de commandement mobiles -- rendent ce modèle non seulement inefficace mais activement dangereux. Le concentrateur VPN devient un point unique de risque de déplacement latéral : une seule identification compromise ou un tunnel mal configuré accorde à un adversaire le même accès implicite au niveau réseau que celui dont dispose un initié légitime. L'architecture zero trust pour les réseaux militaires offre un modèle fondamentalement différent, et cet article examine les composants spécifiques qui remplacent le VPN dans la pratique : le Zero Trust Network Access, les périmètres définis par logiciel et les proxys sensibles à l'identité.

Pourquoi les VPN hérités échouent dans les architectures de défense modernes

L'échec architectural des VPN hérités dans les contextes de défense n'est pas principalement une vulnérabilité dans le protocole VPN lui-même -- le tunneling IPsec et TLS reste cryptographiquement solide. L'échec réside dans le modèle d'accès que le VPN impose. Une fois qu'un utilisateur s'authentifie auprès du concentrateur VPN, le tunnel résultant accorde une accessibilité au niveau réseau à un sous-réseau ou un VLAN entier. Le VPN ne sait pas quelle application spécifique l'utilisateur a l'intention d'atteindre, n'évalue pas la santé de l'appareil connecté et n'applique pas de politique par session basée sur la sensibilité de la ressource demandée. Chaque session reçoit la même confiance implicite une fois que la vérification d'identification initiale est passée.

Dans les environnements de défense opérationnels, ce modèle de confiance plat crée un risque concret. Les terminaux compromis -- ordinateurs portables récupérés par des adversaires, identifiants extraits de personnel capturé -- portent les mêmes octrois d'accès VPN que les appareils opérationnels en règle. Les configurations split-tunnel, introduites pour réduire la consommation de bande passante sur les bases opérationnelles avancées, créent des asymétries de routage que les équipes de sécurité ne peuvent pas auditer pleinement. Et lorsque les concentrateurs VPN eux-mêmes portent des vulnérabilités non corrigées, la surface d'attaque exposée est la passerelle vers l'ensemble du segment de réseau protégé, et non vers une seule application. Plusieurs intrusions très médiatisées dans les réseaux de sous-traitants de défense ont suivi exactement ce schéma : accès initial via une vulnérabilité de concentrateur VPN, suivi d'un déplacement latéral à travers des sous-réseaux que le modèle VPN considérait implicitement comme dignes de confiance.

Le tempo opérationnel ajoute une deuxième couche de friction. Le provisionnement d'un accès VPN pour un nouveau sous-traitant, une unité déployée ou un partenaire de coalition nécessite des changements manuels de règles de pare-feu et des affectations de groupes VPN. Révoquer l'accès à la fin d'un engagement nécessite l'inverse. Dans un environnement de menace où l'accès devrait être accordé pour la durée d'une tâche spécifique et révoqué immédiatement à la fin de cette tâche, la granularité grossière de la gestion des accès VPN crée à la fois un accès permanent surprivilégié et une charge administrative chronophage. L'argument opérationnel en faveur du remplacement du VPN porte autant sur l'agilité d'accès que sur la posture de sécurité.

Architecture Zero Trust Network Access (ZTNA) : principes et composants

Le Zero Trust Network Access (ZTNA) est le modèle architectural qui remplace directement le VPN pour la connectivité utilisateur à application. Le principe fondateur est qu'aucune connexion n'est digne de confiance en vertu de son emplacement réseau. Chaque session -- qu'elle provienne d'un poste de travail à l'intérieur du centre de données ou d'une tablette sur une base opérationnelle avancée -- doit présenter une identité vérifiée, une attestation de posture de l'appareil et une justification contextuelle suffisante avant que le moteur de politiques n'autorise l'accès à une application spécifique. Le tunnel VPN est remplacé par une connexion par session, limitée à l'application, médiatisée par une passerelle ZTNA qui impose la décision de politique.

L'architecture ZTNA comporte quatre composants centraux. Le fournisseur d'identité (IdP) émet l'assertion d'identité cryptographique que l'utilisateur transporte dans la session. Dans les déploiements de défense, il s'agit généralement d'un système adossé à une PKI utilisant des cartes à puce, des jetons matériels ou des clés FIDO2 -- et non des identifiants par mot de passe uniquement. Le moteur de politiques évalue la revendication d'identité, les signaux de posture de l'appareil et les attributs de la requête d'accès par rapport à un jeu de règles de politique pour produire une décision d'autorisation ou de refus. La passerelle ZTNA impose cette décision au niveau réseau, ne proxyfiant que les sessions applicatives autorisées et rejetant tout autre trafic. L'agent de posture de l'appareil, s'exécutant sur le terminal, recueille et atteste les signaux de santé que le moteur de politiques exige. Ces quatre composants interagissent selon une séquence qui produit un jeton d'accès à durée limitée et limité à l'application pour chaque session autorisée, plutôt qu'un tunnel réseau persistant.

L'effet pratique est une microsegmentation sans la complexité de la configuration de règles de pare-feu par application à travers chaque segment de réseau. Les applications ne sont directement accessibles depuis aucun réseau ; tout le trafic passe par la passerelle ZTNA, qui connaît l'identité de chaque session qu'elle proxyfie. Cette architecture est décrite en détail dans le contexte de l'architecture zero trust Corvus QUANTUM : conception et composants, qui met en œuvre la pile ZTNA complète pour les déploiements de défense cloud et sur site.

Périmètres définis par logiciel : autorisation par paquet unique et conception du contrôleur

Les périmètres définis par logiciel (SDP) étendent le principe ZTNA à la couche de découverte réseau : l'infrastructure n'est pas simplement soumise à un contrôle d'accès mais rendue entièrement invisible aux parties non authentifiées. Une passerelle SDP ne répond pas aux paquets TCP SYN, n'apparaît pas dans les réponses DNS visibles par les réseaux non fiables, et rejette tout le trafic qui n'a pas été précédé d'un knock d'autorisation par paquet unique (SPA) valide. Du point de vue d'un scanner réseau ou d'un cadriciel d'exploitation automatisé, l'infrastructure n'existe tout simplement pas. Cette propriété de « réseau invisible » est la caractéristique déterminante qui distingue le SDP de la segmentation conventionnelle imposée par pare-feu, où l'infrastructure est visible même si l'accès est refusé.

L'autorisation par paquet unique fonctionne via une poignée de main précisément définie. Le client SDP recueille le jeton d'identité de l'utilisateur, l'identifiant du service demandé, un horodatage et un nonce, signe la charge utile combinée avec une clé privée provenant du module de sécurité matériel ou du TPM de l'appareil, et transmet le knock signé sous forme d'un unique datagramme UDP au contrôleur SDP. Le contrôleur valide la signature cryptographique du knock par rapport à la clé publique enrôlée de l'utilisateur, vérifie l'horodatage pour la protection contre le rejeu (généralement une fenêtre de validité de cinq secondes), évalue la politique d'accès pour le service demandé, et si la politique l'autorise, ordonne à la passerelle SDP d'ouvrir une règle de pare-feu par session pour cette IP cliente spécifique et ce port de destination. Ce n'est qu'alors que le client tente la connexion TCP. Un observateur surveillant le réseau voit le datagramme knock -- qui est chiffré et ne porte aucun identifiant de service en clair -- mais ne peut pas le rejouer, ne peut pas déterminer quel service a été demandé, et ne peut pas se connecter sans une identification d'identité valide.

La conception du contrôleur est la décision architecturale qui affecte le plus la résilience opérationnelle du SDP. Un contrôleur centralisé unique constitue un point de défaillance unique pour l'ensemble du plan de contrôle d'accès. Les déploiements de défense utilisent généralement un cluster de contrôleurs distribué doté d'un mécanisme de consensus (basé sur Raft ou Paxos) qui tolère la perte d'une minorité de nœuds. Pour les unités déployées en avant qui doivent conserver une capacité d'accès pendant une perturbation des communications, une instance de contrôleur SDP local peut être déployée à la périphérie du réseau de l'unité, synchronisée avec le contrôleur central lorsque la connectivité est disponible et fonctionnant de manière autonome sur un instantané de politique mis en cache localement lorsqu'elle ne l'est pas.

Proxys sensibles à l'identité : imposer la politique d'accès au niveau applicatif

Les proxys sensibles à l'identité (IAP) complètent le ZTNA et le SDP en déplaçant le point d'imposition de l'accès de la couche réseau à la couche applicative. Là où une passerelle ZTNA contrôle si une session peut atteindre le point d'extrémité réseau d'une application, un IAP termine la session, inspecte le protocole de niveau applicatif, évalue l'identité et la politique, et réémet la connexion vers le backend uniquement si l'autorisation par requête réussit. L'IAP comprend les verbes HTTP, les chemins d'URL, les noms de service gRPC et les sous-systèmes SSH -- il peut imposer une politique d'accès à la granularité de points d'extrémité d'API individuels ou de classes de commandes, et pas seulement au niveau de l'application dans son ensemble.

Pour les applications de défense, les IAP fournissent une capacité que les contrôles purement au niveau réseau ne peuvent pas offrir : des décisions d'autorisation à grain fin et auditables qui sont journalisées avec une identité d'utilisateur vérifiée, et non une adresse IP source. Un IAP placé devant un service de données classifié peut imposer qu'un analyste logistique puisse interroger les points d'extrémité en lecture mais pas les points d'extrémité en écriture, qu'une identité de partenaire de coalition puisse accéder à des objets de données non classifiés mais soit refusée lorsqu'elle demande des objets classifiés, et que tout accès à une catégorie de données spécifique déclenche une alerte vers l'équipe des opérations de sécurité. Ces contrôles sont indépendants de la topologie réseau -- l'application backend n'a pas besoin d'être modifiée pour les imposer, et ils restent efficaces même si l'adresse réseau du terminal change en raison de l'itinérance ou d'une connectivité sans VPN.

L'IAP résout également le problème de piste d'audit qui afflige les journaux d'accès basés sur l'IP. Comme l'IAP authentifie chaque requête et injecte des en-têtes d'identité vérifiés que l'application backend journalise, la piste d'audit associe chaque accès aux données à une identité d'utilisateur spécifique plutôt qu'à une adresse IP qui peut être partagée, NATtée ou usurpée. Pour les environnements classifiés soumis à des exigences d'audit, ce journal d'accès attribué à l'identité constitue une amélioration opérationnelle significative par rapport aux journaux au niveau session produits par les concentrateurs VPN.

Évaluation de la posture des terminaux : vérifier la santé du terminal avant d'accorder l'accès

L'évaluation de la posture des terminaux est le mécanisme par lequel les systèmes ZTNA vérifient que le terminal connecté est dans un état réputé sain avant d'émettre un jeton d'accès. L'évaluation de posture comble le vecteur d'attaque qu'une vérification fondée uniquement sur les identifiants réseau laisse ouvert : une identification valide sur un appareil compromis. L'agent de posture, installé sur le parc de terminaux gérés, recueille des signaux qui attestent l'état de sécurité de l'appareil et les soumet au moteur de politiques dans le cadre de la requête d'autorisation de session. Les signaux incluent généralement la version et le niveau de correctifs du système d'exploitation, le statut et l'horodatage du dernier scan de l'agent de détection et de réponse aux menaces sur les terminaux (EDR), l'état du chiffrement du disque, la présence et la validité d'un certificat d'enrôlement émis par la PKI de l'organisation, et l'absence de processus connus comme malveillants.

La conception de la politique de posture nécessite d'équilibrer la rigueur de sécurité et la continuité opérationnelle. Une politique qui exige une base de données de signatures EDR à jour refusera l'accès aux terminaux qui ont été hors ligne dans un environnement à communications interdites et qui n'ont pas reçu de mises à jour récentes -- un scénario qui est de routine pour les unités de défense déployées. Les déploiements ZTNA de défense définissent généralement des niveaux de posture échelonnés : un appareil entièrement géré avec des correctifs à jour et un EDR actif reçoit un accès sans restriction à toutes les applications autorisées ; un appareil géré avec des signatures EDR obsolètes reçoit l'accès à un ensemble d'applications réduit excluant les ressources les plus sensibles ; un appareil non géré sans certificat d'enrôlement ne reçoit aucun accès, ou un accès limité à un portail d'information en lecture seule, en attente d'une revue manuelle. Ce modèle échelonné préserve l'accès opérationnel pour le personnel déployé tout en maintenant une imposition de posture significative.

La réévaluation continue de la posture pendant les sessions actives traite le scénario d'un appareil qui passe la vérification de posture initiale puis se dégrade -- parce que l'agent EDR est arrêté, parce qu'un utilisateur installe un logiciel non autorisé, ou parce qu'une nouvelle vulnérabilité de gravité élevée est publiée contre un composant de l'appareil. L'agent de posture signale les variations de santé au moteur de politiques à un intervalle configurable. Lorsque le moteur de politiques reçoit un signal de posture qui fait passer l'appareil sous le niveau minimum requis pour sa session en cours, il révoque le jeton d'accès et force une réauthentification. La terminaison de la session est journalisée avec le signal de posture spécifique qui l'a déclenchée, donnant aux opérations de sécurité un enregistrement précis du moment et de la raison de la révocation de l'accès.

Déployer le ZTNA dans des environnements isolés et classifiés : contraintes et adaptations

Les implémentations ZTNA conçues pour les environnements d'entreprise connectés à Internet supposent que le fournisseur d'identité, le moteur de politiques et les flux de renseignement sur les menaces sur lesquels s'appuie l'évaluation de posture sont accessibles via l'Internet public ou un backbone cloud. Les réseaux isolés et classifiés imposent un ensemble différent de contraintes : aucune connectivité Internet, des exigences strictes de diode de données ou de solution interdomaines (CDS) à toute frontière externe, et des processus d'accréditation qui régissent quels composants logiciels peuvent s'exécuter à l'intérieur de la frontière de classification. Ces contraintes nécessitent des adaptations architecturales qui préservent le modèle d'accès zero trust tout en éliminant toute dépendance à une connectivité externe.

L'adaptation principale consiste à héberger tous les composants du plan de contrôle ZTNA à l'intérieur de la frontière de classification. Le fournisseur d'identité, l'autorité de certification qui émet les certificats d'enrôlement des appareils, le moteur de politiques, le cluster de contrôleurs SDP et le déploiement IAP sont tous exploités comme des charges de travail sur site à l'intérieur de l'enclave. Comme il n'y a aucune connectivité PKI externe, la révocation des certificats doit être gérée par un répondeur OCSP hébergé en interne ou par une liste de révocation de certificats (CRL) régulièrement distribuée et mise à jour via le processus de gestion des changements de l'enclave. Les flux de renseignement sur les menaces qui alimentent la politique de posture -- tels que les CVE nouvellement publiées contre des composants de l'OS -- sont ingérés via un processus de transfert contrôlé à une cadence de mise à jour définie plutôt qu'en temps réel.

Une deuxième contrainte est le processus d'enrôlement des appareils. Dans les déploiements ZTNA d'entreprise, les appareils sont enrôlés par l'utilisateur qui visite un portail d'enrôlement hébergé par l'IdP via Internet. Dans les environnements isolés, l'enrôlement doit se faire via un processus en bande : l'appareil est connecté à un segment de réseau d'enrôlement dédié, l'agent PKI est installé et le certificat d'enrôlement est émis, puis l'appareil est reconnecté au réseau opérationnel. Ce processus doit être documenté et imposé dans le dossier d'accréditation, et le segment de réseau d'enrôlement doit être isolé du trafic opérationnel pour empêcher que l'émission de certificats ne soit utilisée comme vecteur d'attaque. Les schémas de durcissement pour les charges de travail Kubernetes de défense qui hébergent les composants du plan de contrôle ZTNA appliquent le même principe d'isolement et d'exposition minimale aux interfaces de gestion du cluster.

Chemin de migration : passer d'un VPN hérité au ZTNA sans interruption de service

La migration d'un VPN hérité vers le ZTNA est rarement un événement de bascule unique dans les environnements de défense. La diversité des applications, l'hétérogénéité du parc de terminaux et la criticité opérationnelle de l'accès continu font d'une approche progressive et en exploitation parallèle le seul chemin de migration réaliste. La migration se déroule en cinq phases qui déplacent de manière incrémentale les groupes d'applications de l'accès médiatisé par VPN vers l'accès imposé par ZTNA tout en maintenant une disponibilité opérationnelle continue.

La première phase est un inventaire complet de l'utilisation actuelle du VPN : quels utilisateurs accèdent à quelles applications, via quels protocoles, depuis quels types d'appareils, et pendant quelles périodes opérationnelles. Cet inventaire révèle des dépendances qui ne sont pas évidentes à partir des schémas réseau -- applications qui utilisent le tunnel VPN pour l'authentification service à service, systèmes hérités qui lient le contrôle d'accès aux adresses IP source, et processus automatisés qui utilisent des identifiants VPN pour des tâches planifiées. Ces dépendances cachées deviennent les obstacles de migration qui doivent être résolus avant que l'application correspondante puisse être déplacée derrière la passerelle ZTNA. L'exploitation en mode fantôme -- exécution du moteur de politiques ZTNA en mode journalisation seule pendant que le VPN reste actif -- fait émerger ces dépendances sans perturber les opérations, nécessitant généralement deux à quatre semaines d'observation par groupe d'applications avant que la politique soit suffisamment complète pour être digne de confiance.

La bascule incrémentale se déroule de la criticité la plus faible à la plus élevée parmi les groupes d'applications. Chaque groupe est basculé lors d'une fenêtre de maintenance : les routes split-tunnel VPN pour les sous-réseaux de cette application sont supprimées, la passerelle ZTNA devient le seul chemin d'accès, et une période de surveillance renforcée suit pour détecter toute défaillance d'accès que l'observation en mode fantôme aurait manquée. La phase finale -- le déclassement des concentrateurs VPN -- devrait être précédée d'une revue d'accès complète confirmant qu'aucune application ne reste accessible via un accès résiduel par tunnel VPN, et que tous les journaux d'accès aux sessions portent désormais l'identité de l'utilisateur plutôt que l'IP du tunnel comme identifiant d'accès principal. Le résultat opérationnel est un réseau où chaque session applicative est attribuable à une identité vérifiée, où l'état de santé de chaque terminal est attesté en continu, et où les chemins de déplacement latéral que la topologie VPN héritée créait n'existent plus.