ZTNA ou VPN pour le personnel à distance et les sous-traitants

On présente souvent l’accès à distance comme un simple changement de produit : retirer la passerelle VPN (réseau privé virtuel) et s’abonner à un service ZTNA (accès réseau « zéro confiance », de l’anglais zero trust network access). Ce changement, c’est la partie facile. Ce qui détermine si vous réduirez réellement la confiance implicite, c’est la politique que vous y apportez.

Le ZTNA est une catégorie de produits, pas une norme

La publication NIST SP 800-207, qui fait référence pour définir l’architecture « zéro confiance », n’emploie jamais le terme ZTNA. Elle décrit le « zéro confiance » comme une façon de réduire l’incertitude dans des décisions d’accès prises requête par requête, selon le moindre privilège, sur un réseau qu’on tient pour compromis. Elle présente aussi des modèles de déploiement — un agent sur l’appareil jumelé à une passerelle, une passerelle devant une enclave, un portail de ressources — qui correspondent directement à ce que vendent les produits ZTNA. Le guide de mise en œuvre publié ensuite par le NIST, SP 1800-35, range le ZTNA parmi les composantes du SASE, à côté de la passerelle web sécurisée et du CASB. Lisez les promesses des fournisseurs en conséquence : le produit est un point d’application. Le « zéro confiance », c’est la politique qu’il applique.

Le modèle de maturité « zéro confiance » de la CISA (version 2.0) mesure le même virage. Les applications accessibles uniquement par des réseaux privés ou par VPN y relèvent du stade Traditionnel ; chaque stade supérieur met davantage d’applications à la portée directe des utilisateurs autorisés.

Ce que le ZTNA change vraiment

• L’accès par application plutôt que l’accès au réseau. Selon le troisième principe de la SP 800-207, s’authentifier et être autorisé pour une ressource ne donne pas automatiquement accès à une autre. Le VPN fait l’inverse, par conception : il fait de vous un hôte du réseau.
• L’identité et l’appareil, évalués à chaque décision. Les critères sont l’utilisateur, la posture de l’appareil (géré, à jour, chiffré) et la sensibilité de l’application, et non le sous-réseau d’origine. Une évaluation détaillée de la posture exige un logiciel sur l’appareil ; le NIST note qu’un portail sans agent ne voit un appareil que pendant qu’il est connecté.
• Aucun port ouvert en entrée, avec un connecteur. Le connecteur installé dans votre réseau établit lui-même la connexion vers le courtier, et la documentation des fournisseurs le décrit comme strictement sortant, sans règle de pare-feu entrante. C’est important, car les passerelles VPN exposées à Internet sont des cibles : en janvier 2024, la directive d’urgence 24-01 de la CISA a répondu à l’exploitation active et généralisée d’une gamme de VPN SSL, puis a ordonné aux organismes fédéraux civils américains de déconnecter ces produits de leurs réseaux. La surface exposée ne disparaît pas pour autant. Elle se déplace vers le service du fournisseur, dont vous dépendez désormais.

Ce qu’il ne règle pas à lui seul

Sans modèle de politique d’accès, aucun progrès. Si votre première règle est « tous les employés → toutes les applications privées », vous avez reconstruit le VPN dans une nouvelle console. À l’inverse, une politique incomplète prive d’accès des gens qui en ont besoin : le NIST prévient qu’une connaissance incomplète des actifs, des utilisateurs et des processus mène le plus souvent à une défaillance des processus d’affaires. La SP 1800-35 ajoute que les règles peuvent se retrouver éparpillées entre les produits d’identité, de protection des postes et de réseau, et recommande de consigner où chaque règle est configurée. Les deux problèmes ont le même remède : écrire le modèle sous forme de code avant de configurer quelque produit que ce soit.

# access-policy.yaml — révisé en PR, appliqué par la CI
- app: payroll
  sensitivity: high
  allow: { groups: [finance], device: managed-compliant }
  enforced_at: ztna-connector
- app: crm-saas
  sensitivity: medium
  allow: { groups: [sales, sales-contractors], device: registered }
  enforced_at: idp-sign-in-policy
- app: legacy-erp
  sensitivity: high
  allow: { groups: [ops], device: managed-compliant }
  enforced_at: enclave-gateway

Applications patrimoniales et protocoles autres que HTTP. L’accès sans agent, par navigateur, est conçu pour les applications web ; les clients lourds, les partages de fichiers et les protocoles de bases de données exigent généralement l’agent. Vérifiez produit par produit le trafic amorcé par le serveur — rappels VoIP, logiciels déployés sur les portables, mises à jour d’annuaire : certains connecteurs strictement sortants ne le transportent pas du tout. Le modèle d’enclave du NIST, une passerelle devant un segment patrimonial, fonctionne, mais il protège le segment en bloc et peut laisser les utilisateurs voir des ressources qu’ils ne peuvent pas ouvrir.

SaaS. Un connecteur d’accès privé ne voit jamais le trafic SaaS, et le NIST précise qu’un utilisateur à distance ne devrait pas avoir à repasser par le réseau de l’entreprise pour joindre des services infonuagiques comme le courriel. Pour le SaaS, le point d’application est la politique de connexion de votre fournisseur d’identité, qui peut exiger, chez les fournisseurs courants, un appareil conforme ou géré. Les suites SASE ajoutent une passerelle web ou un CASB pour ce trafic : une autre politique, que le modèle doit aussi couvrir.

Accès d’urgence (break-glass). Après la bascule, le courtier et votre fournisseur d’identité deviennent la porte d’entrée. Le NIST note qu’une erreur d’exploitation pourrait paralyser toute l’entreprise si le moteur de politiques ou l’administrateur de politiques devenait inaccessible. Prévoyez un chemin d’urgence qui ne dépende pas des composants qu’il sert à contourner, gardez ses identifiants hors ligne, déclenchez une alerte à chaque utilisation et testez-le à intervalles réguliers.

Quand un VPN reste raisonnable

• Les liens site à site. Relier des réseaux est un autre problème que l’accès des utilisateurs, et IPsec le règle encore.
• Le trafic que votre produit ZTNA ne transporte pas encore, comme les connexions bidirectionnelles ou de longue durée.
• Le reliquat de la migration. Le NIST admet que des flux de travail « zéro confiance » et périmétriques peuvent coexister pendant une période indéterminée, et la CISA décrit le parcours comme un processus graduel qui peut prendre des années.

Le critère : le VPN est-il circonscrit et en recul — des personnes nommées, des sous-réseaux nommés — ou reste-t-il la porte d’entrée par défaut ?

Une migration qui ne prive personne d’accès

1. L’inventaire d’abord : les applications, les personnes qui les utilisent (sous-traitants compris) et leurs appareils. Le NIST en fait le préalable de tout déploiement.
2. Écrivez le modèle de politique sous forme de code, révisé comme n’importe quel autre changement.
3. Observez avant d’appliquer. La SP 1800-35 suggère de partir d’un tunnel couvrant tout l’appareil, d’observer le trafic, puis de n’autoriser que ce dont chaque profil d’utilisateur a besoin. La SP 800-207 décrit une phase en mode rapport seulement, pendant laquelle les règles de base, comme le refus d’accès en cas d’échec de l’authentification multifacteur, restent appliquées.
4. Basculez par cohorte, en commençant par le risque le plus faible, et gardez le VPN comme solution de repli pour cette cohorte.
5. Retirez les routes VPN à mesure que chaque application migre, pour que le VPN rétrécisse au lieu de fonctionner en parallèle indéfiniment.
6. Testez l’accès d’urgence avant la première cohorte, pas après la première panne.

Une Construction d’un accès sécurisé, c’est cette séquence, livrée : le modèle de politique d’accès sous forme de code dans votre dépôt, les points d’application en Terraform, et une bascule par phases, réversible, avec un accès d’urgence testé d’abord. Quel que soit le produit ZTNA retenu, la politique vous appartient.