ZTNA contre VPN en termes simples

A VPN crée un tunnel chiffré entre un appareil utilisateur et votre réseau (généralement via une passerelle VPN), donnant ainsi l'impression que l'appareil distant est « sur le réseau » à des fins d'accès.^[9] C’est utile, mais cela peut aussi élargir le rayon de l’explosion lorsqu’un appareil est compromis, car l’utilisateur est effectivement connecté à l’environnement interne.

ZTNA L'accès réseau Zero Trust (Zero Trust Network Access) fait partie d'une architecture Zero Trust plus large qui ne présuppose aucune confiance implicite fondée sur la localisation réseau. Au contraire, les décisions d'accès sont appliquées en continu en fonction de l'identité, du statut de l'appareil et des politiques, et sont limitées à l'application ou à la ressource spécifique demandée.^[1] Le Centre canadien pour la cybersécurité présente le modèle Zero Trust comme un modèle moderne pour sécuriser les télétravailleurs et les environnements cloud hybrides dans le contexte actuel des menaces.^[2]

Pourquoi les équipes informatiques reconsidèrent le VPN comme solution par défaut

Les VPN ne sont pas intrinsèquement « mauvais », mais ils constituent des cibles de grande valeur. La CISA et la NSA ont souligné à plusieurs reprises que les serveurs VPN d'accès à distance sont des points d'entrée dans les réseaux protégés, ce qui les rend attrayants pour les adversaires.^[4] Le Centre canadien pour la cybersécurité propose également des guides de déploiement pour les technologies VPN et des liens vers des recommandations de renforcement de la sécurité pour les VPN d'accès à distance.^[3]

Points faibles courants des VPN qui apparaissent dans les audits et les incidents

• Large accès dès la conception: de nombreuses configurations VPN offrent une connectivité au niveau du réseau qui dépasse les besoins professionnels réels de l'utilisateur.
• Incertitude liée à l'appareil: les terminaux non gérés, les clients obsolètes et les environnements BYOD mixtes compliquent l'application des règles.
• Risque concentréLe concentrateur VPN constitue un point de blocage critique pour la disponibilité et une cible prioritaire pour les attaques.
• Lacunes de visibilitéLes journaux existent, mais le contexte au niveau de l'application et la visibilité du parcours utilisateur peuvent être plus difficiles à corréler sans télémétrie mature.

En pratique, il est important de noter que le VPN est souvent une solution de transport, tandis que ZTNA est un modèle de politique et d'application. Si votre programme de sécurité s'oriente vers « vérification explicite, application du moindre privilège, présumer une violation », ZTNA s'intègre plus naturellement à ce modèle opérationnel.^[6]

Comment fonctionne réellement ZTNA

Dans la plupart des implémentations ZTNA, l'utilisateur ne bénéficie pas d'un tunnel réseau global. Un moteur de règles évalue chaque requête et n'autorise l'accès qu'à la destination spécifique permise par la règle. Ce modèle est conforme à l'objectif plus large du Zero Trust, qui vise à minimiser l'incertitude liée aux décisions d'accès pour chaque requête au sein d'un réseau considéré comme compromis.^[7]

Un flux d'accès typique

1. L'utilisateur demande une application (application web, RDP, SSH, service de fichiers ou SaaS privé).
2. L'identité est vérifiée. (SSO, MFA, signaux de risque, conditions d'accès conditionnel).
3. La posture de l'appareil est vérifiée. (appareil géré, conformité, chiffrement, présence EDR, niveau de correctif du système d'exploitation, certificat).
4. La décision politique se produit (rôle, emplacement, score de risque, heure, sensibilité de l'application, classification des données).
5. La connexion est négociée à cette application uniquement, avec une réévaluation continue en cas de changement de signal.

Comparaison : ZTNA vs VPN en termes d'opérations, de sécurité et d'expérience utilisateur

Vous n'êtes pas obligé de tout migrer en une seule fois. De nombreuses organisations utilisent une migration. hybride modèle pour une période donnée, utilisant ZTNA pour la plupart des accès et un VPN renforcé uniquement pour les exceptions héritées.

Une stratégie de migration progressive VPN vers ZTNA

La réussite d'une migration repose moins sur le choix d'un produit unique que sur son enchaînement. L'objectif est de minimiser les risques tout en assurant la continuité de l'activité. Utilisez les phases ci-dessous comme guide, puis adaptez-les en fonction de la topologie de votre réseau, de votre niveau de maturité en matière d'identité et de votre pile applicative.

Phase 1 : Découverte et évaluation initiale (semaines 0 à 2)

• Utilisateurs de l'inventaire et types d'accès: employés, sous-traitants, fournisseurs, comptes de service, accès d'urgence.
• Applications d'inventaire derrière un VPN: RDP, partages de fichiers, applications web internes, outils d'administration, bases de données, environnements OT (le cas échéant).
• Capture des flux de trafic: ce qui est utilisé quotidiennement par rapport à ce qui est rarement utilisé, ce qui est essentiel à l'activité et ce qui présente un risque élevé.
• Hygiène de l'identité de baseCouverture MFA, rôles privilégiés, comptes obsolètes, lacunes d'accès conditionnel.

Phase 2 : Définir les résultats politiques (semaines 2 à 4)

• Commencez par « qui, quoi, quand, d'où ».: rôle, application, heure, lieu, signaux de risque.
• Écrire les règles d'accès par application (non par sous-réseau) : le principe du moindre privilège est plus facile à appliquer lorsqu'on conçoit en fonction des flux de travail métier.
• Choisissez les signaux de contrôle: appareil géré, appareil conforme, authentification par certificat, EDR requis, restrictions géographiques.

Phase 3 : ZTNA pilote pour les applications à faible risque et à volume élevé (semaines 4 à 8)

• Choisissez 2 à 4 applications qui sont fréquemment utilisées mais ne sont pas les plus complexes (applications web internes, RDP vers un serveur de rebond, outils d'administration de billetterie).
• Mettre en place un groupe pilote contrôlé (En priorité aux équipes informatiques et aux utilisateurs avancés) et mesurer les frictions : temps de connexion, taux d’échec, tickets d’assistance.
• Gardez le VPN comme solution de repli pendant la phase pilote, mais à utiliser comme solution d'exception, et non par défaut.

Phase 4 : Étendre la couverture et supprimer les chemins VPN (semaines 8 à 16)

• Déplacez l'accès des entrepreneurs et des fournisseurs au plus tôtCela permet souvent une réduction immédiate des risques car l'accès est limité à l'application.
• Imposer des conditions plus strictes au fur et à mesure de la stabilisation : conformité des appareils, points de terminaison gérés et politiques d’accès conditionnel.
• Réduire les droits VPN Progressivement : moins de groupes, moins de routes, moins de sous-réseaux accessibles, durée de vie des sessions plus courte.

Phase 5 : Déclassement et renforcement des installations restantes (en cours)

• Supprimer les comptes et itinéraires VPN inutilisés.
• Renforcez le VPN résiduel pour les véritables exceptions, en appliquant les meilleures pratiques actuelles et une discipline de mise à jour continue.^[4]
• Documenter le nouveau modèle de contrôle pour les audits, les assurances et le contrôle des changements.

Modèles d'architecture qui fonctionnent (et comment les choisir)

Le modèle d'acquisition moderne le plus courant consiste à acheter ZTNA dans le cadre d'une solution de sécurité cloud plus large. La définition SASE de Gartner, par exemple, inclut ZTNA comme une fonctionnalité essentielle au même titre que d'autres services réseau et de sécurité.^[8] Sur le marché, vous trouverez des offres positionnées comme ZTNA, SSE ou SASE.

Modèle A : ZTNA centré sur l’identité pour les applications privées

Si votre plateforme d'identité est mature, une approche ZTNA centrée sur l'identité peut constituer une alternative efficace aux VPN traditionnels pour les applications privées. Microsoft décrit le ZTNA centré sur l'identité comme une solution permettant de remplacer les VPN classiques en accordant un accès granulaire aux ressources privées sans exposer l'intégralité du réseau.^[5]

Modèle B : ZTNA faisant partie de SSE ou SASE

Si votre organisation a également besoin d'une passerelle web sécurisée, de contrôles d'applications cloud et d'une protection centralisée contre les menaces, une approche SSE ou SASE peut consolider les outils. L'essentiel est d'associer les fonctionnalités aux résultats attendus : accès aux applications, protection des données, visibilité et flux de réponse.

Modèle C : ZTNA en amont d’un réseau segmenté

ZTNA est particulièrement performant lorsqu'il est associé à une segmentation interne efficace et à des contrôles d'identité robustes. Imaginez ZTNA comme la « porte d'entrée » et la segmentation comme les « couloirs internes ». Lorsque les deux sont alignés, les déplacements latéraux sont plus difficiles et la détection plus aisée.

Si vous souhaitez obtenir de l'aide pour choisir l'architecture adaptée à votre environnement, commencez par consulter les services de MSP Corp. Services de cybersécurité hub, ou associer le projet à Services réseau et Infrastructure gérée pour une visibilité de bout en bout.

Plan directeur des politiques : que définir avant de passer à l’action ?

Le succès de ZTNA repose sur la qualité des politiques. Pour maîtriser le périmètre, il est essentiel de définir les politiques par couches : identité, appareil, application et sensibilité des données. Cette approche est similaire à la façon dont de nombreux modèles de maturité Zero Trust décomposent les capacités selon différents piliers.^[7]

Politiques d'identité (de base)

• Mettez en place l'authentification multifacteur pour tous les accès distants, puis améliorez-la grâce à un accès conditionnel basé sur le risque et le contexte.
• Distinguer les identités d'administrateur des identités d'utilisateur ; protéger les rôles privilégiés par des contrôles plus stricts.
• Exigez une authentification moderne et bloquez les méthodes d'authentification héritées lorsque cela est possible.

Si votre feuille de route inclut les contrôles d'identité Microsoft, ces ressources de MSP Corp pourraient vous être utiles : L'authentification multifacteur ne suffit pas : comment ajouter correctement l'accès conditionnel et la Liste de contrôle d'administration de Microsoft 365.

Politiques relatives aux appareils (de base)

• Exiger un appareil géré et conforme pour les applications à haut risque (finance, RH, outils administratifs).
• Effectuez des contrôles de posture : chiffrement du disque, présence d’EDR, système d’exploitation actuel, démarrage sécurisé le cas échéant.
• Définir une procédure d'exception pour les situations critiques et documenter ses approbations.

Politiques d'application (de base)

• Regrouper les applications par sensibilité et flux de travail : « quotidienne », « admin », « finance », « réservée aux fournisseurs », « rare ».
• Privilégiez l'accès à un serveur de rebond sécurisé pour les protocoles d'administration plutôt qu'un accès direct à de nombreux serveurs.
• Adaptez la durée des sessions au risque (plus courte pour l'accès administrateur et fournisseur).

Politiques de données et de réponse (situation de référence)

• Définir les éléments déclencheurs d'un incident : impossibilité de déplacement, refus répétés, position risquée de l'appareil.
• Assurez-vous que votre plan d'intervention est à jour et a été testé (voir le Modèle de plan de réponse aux incidents (pour les PME)).
• Confirmer la couverture pour la surveillance et l'escalade, en particulier en dehors des heures ouvrables (voir Ce qui est inclus (et ce qui ne l'est pas) dans l'assistance informatique 24h/24 et 7j/7).

Gestion du changement : assurer un déploiement sans heurts

Si les utilisateurs perçoivent ZTNA comme un durcissement de la sécurité et une lenteur accrue, son adoption sera freinée. Le déploiement doit être perçu comme un gain de productivité : moins de problèmes de connexion, moins de ralentissements du tunnel complet et un accès plus rapide aux applications réellement utilisées.

Tactiques de déploiement permettant de réduire les tickets

• Commencez par un petit pilote et publier les indicateurs de succès (temps de connexion, moins de déconnexions VPN, meilleures performances).
• Expliquez le pourquoi: le principe du moindre privilège et la vérification explicite protègent l'entreprise et les utilisateurs.^[6]
• Prévoir une solution de repli définie pendant la phase pilote, puis retirez-le intentionnellement à mesure que la confiance grandit.
• Alignement sur la gouvernance pour les approbations et les exceptions (voir Gouvernance de l'IA pour les équipes informatiques : matrice RACI, approbations et gestion des changements).

Si la performance de vos fournisseurs ou un historique de transition chaotique font partie de vos facteurs déterminants, ce guide de MSP Corp peut vous aider : Quand changer de fournisseur de services gérés : 12 signaux d’alerte et une liste de vérification pour la transition.

Pièges courants (et comment les éviter)

Piège n° 1 : Considérer ZTNA comme un simple changement de VPN

Un changement d'outil sans définition de politique adéquate reproduit souvent le problème du VPN dans une nouvelle interface. Si votre modèle d'accès reste trop permissif, vous ne bénéficierez pas pleinement des avantages en matière de sécurité.

Piège n° 2 : Des fondements identitaires fragiles

ZTNA est axé sur l'identité. Si la couverture MFA est incohérente ou si les rôles privilégiés ne sont pas rigoureusement contrôlés, votre système repose sur des bases fragiles. Commencez par un contrôle d'accès conditionnel et une gestion saine des rôles, puis migrez les applications.

Piège n° 3 : Points de terminaison non gérés dans les flux de travail à haut risque

Si l'appareil est inconnu, la session ne peut être sécurisée. Définissez des règles claires pour le BYOD (ou supprimez-le pour les applications sensibles) et incitez progressivement les utilisateurs à utiliser des terminaux gérés.

Piège n° 4 : Ne pas mettre à jour les opérations et la réponse aux incidents

ZTNA modifie l'emplacement des signaux et la manière dont les sessions sont établies. Assurez-vous que votre flux de travail SOC, vos alertes et votre procédure d'astreinte sont à jour. Si vous étendez les fonctionnalités de sécurité Microsoft, cette liste de contrôle vous aidera à harmoniser les données, la sécurité et les licences : Liste de vérification de préparation à Microsoft 365 Copilot (Données, Sécurité, Licences).

Que faire si vous devez conserver un VPN (pour le moment)

Dans de nombreux environnements, certains besoins d'accès hérités subsistent. Si le maintien d'un VPN est indispensable, considérez-le comme une couche d'exception renforcée et minimisez les risques. Les recommandations de la CISA et de la NSA concernant la sélection et le renforcement des solutions VPN d'accès distant constituent une base solide pour une configuration rigoureuse et une maintenance continue.^[4]

QFP

Références

1. NISTSP 800-207, Architecture de confiance zéro. https://csrc.nist.gov/pubs/sp/800/207/final
2. Centre canadien pour la cybersécurité, Modèle de sécurité Zero Trust (ITSAP.10.008). https://www.cyber.gc.ca/en/guidance/zero-trust-security-model-itsap10008
3. Centre canadien pour la cybersécurité, réseaux privés virtuels (ITSAP.80.101). https://www.cyber.gc.ca/en/guidance/virtual-private-networks-itsap80101
4. CISA et NSA, Sélection et sécurisation des solutions VPN d'accès à distance (alerte et conseils). https://www.cisa.gov/news-events/alerts/2021/09/28/cisa-and-nsa-release-guidance-selecting-and-hardening-vpns
5. Microsoft, Remplacez votre VPN traditionnel par un ZTNA centré sur l'identité.. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/replace-your-legacy-vpn-with-an-identity-centric-ztna/4395973
6. Microsoft Apprendre, Principes du Zero Trust : vérifier explicitement, appliquer le moindre privilège, présumer une violation.. https://learn.microsoft.com/en-us/entra/identity-platform/zero-trust-for-developers
7. CISA, Modèle de maturité Zero Trust. https://www.cisa.gov/zero-trust-maturity-model
8. Gartner, Définition de Secure Access Service Edge (SASE). https://www.gartner.com/en/information-technology/glossary/secure-access-service-edge-sase
9. NIST SP 800-77 Rév. 1, Guide des VPN IPsec. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf