Zero Trust : pourquoi le périmètre réseau ne protège plus rien

Plus de 80 % des attaques contre les entreprises passent par l’utilisation ou le détournement d’identifiants légitimes. Quand un attaquant entre avec un mot de passe valide, le pare-feu ne voit rien. Le VPN ne voit rien. Tout le modèle de sécurité bâti depuis trente ans s’effondre sur ce simple constat. C’est exactement pour ça que le Zero Trust est devenu la nouvelle référence en matière de sécurité réseau, et que les agences fédérales américaines y sont passées par décret en 2021.
Le terme a été forgé en 2010 par John Kindervag, alors analyste chez Forrester Research. Sa formule tient en six mots : « ne jamais faire confiance, toujours vérifier ». Derrière cette phrase, une refonte complète de l’architecture réseau, qui touche l’identité, les appareils, les applications, les données et les flux. Voici comment ça marche, à quoi ça ressemble une fois en place, et ce qu’il faut prévoir pour basculer sans tout casser.
Le château et ses douves : pourquoi le modèle périmétrique a craqué
Pendant longtemps, la sécurité réseau en entreprise s’est construite sur une idée simple. Il y à un dehors hostile et un dedans de confiance. On bâtit un mur (le pare-feu), on creuse des douves (la DMZ), on filtre les ponts-levis (le VPN). Une fois à l’intérieur, l’utilisateur ou la machine peut circuler. Ce modèle, on l’appelle « château et douves » dans la littérature anglo-saxonne, et il a tenu tant que les ressources de l’entreprise vivaient effectivement dans ses murs.
Plusieurs choses l’ont mis à genoux. D’abord le cloud. Quand votre messagerie tourne chez Microsoft, vos fichiers sur Google Drive et votre CRM en SaaS, où est le périmètre ? Il n’y en a plus. Ensuite le télétravail, qui s’est généralisé brutalement en 2020 et n’est jamais reparti. Enfin l’explosion des appareils connectés : ordinateurs personnels, smartphones, capteurs IoT, imprimantes intelligentes… chaque objet ajoute une porte. Le pare-feu, lui, ne voit qu’une partie du décor.
Et puis il y à la statistique qui change tout. Quand un attaquant utilise un identifiant valide (volé, deviné, acheté sur un forum, obtenu par phishing), il franchit le mur sans déclencher la moindre alerte. Une fois à l’intérieur, il se déplace latéralement, recense les ressources, escalade les privilèges, et frappe au moment opportun. L’attaque Sunburst contre SolarWinds a procédé exactement comme ça. Le château était intact. Le problème venait des occupants.
Face à ces risques, les stratégies de protection doivent évoluer vers des modèles comme le Zero Trust.
Zero Trust en clair : ne jamais faire confiance, toujours vérifier
Le modèle Zero Trust part d’une hypothèse opposée. Personne n’est digne de confiance par défaut, ni à l’extérieur ni à l’intérieur du réseau. Chaque demande d’accès est traitée comme si elle venait d’une source potentiellement compromise. L’utilisateur doit prouver qui il est, son appareil doit prouver qu’il est sain, son contexte (heure, lieu, comportement) doit être cohérent. Et tout cela en continu, pas une fois pour toutes au login.
Ça paraît contraignant dit comme ça. Dans la pratique, l’expérience utilisateur peut être meilleure qu’avec un VPN classique, parce que l’authentification se fait au niveau de l’application, pas au niveau du réseau. Vous ouvrez votre poste, votre identité est vérifiée, et vous accédez aux ressources autorisées sans monter de tunnel à chaque fois. Le travail de filtrage est descendu d’un cran : on ne demande plus « est-ce que tu es dans le bon réseau ? », on demande « est-ce que tu es la bonne personne, sur le bon appareil, en train de demander la bonne chose ? ».
La référence technique du modèle est la publication NIST SP 800-207 (août 2020), qui codifie l’architecture Zero Trust et sert de base à la plupart des implémentations sérieuses. Le décret Biden du 12 mai 2021 a imposé cette norme à toutes les agences fédérales américaines, ce qui a accéléré son adoption dans le privé. La CISA a complété l’ensemble avec son Zero Trust Maturity Model en avril 2023, qui décline le cadre en cinq piliers opérationnels.
Trois principes qui structurent toute l’architecture
Quel que soit le fournisseur ou l’éditeur, on retrouve toujours les mêmes briques de raisonnement. Elles tiennent en trois principes.
Vérification continue. Toute demande d’accès est validée à chaque tentative, pas une seule fois en début de session. Les politiques d’accès dynamiques évaluent en temps réel les privilèges de l’utilisateur, l’état de l’appareil, la géolocalisation, le comportement, les renseignements sur les menaces. Si un facteur change (un appareil sort d’une zone autorisée, un comportement devient anormal), l’accès est suspendu et la session relancée.
Moindre privilège. Chaque utilisateur, chaque service, chaque appareil reçoit le strict minimum nécessaire pour faire son travail. Un comptable n’a pas besoin d’accéder aux serveurs de développement, un sous-traitant n’a pas besoin de voir le SI complet, un script de sauvegarde n’a pas besoin des droits d’administrateur. Les autorisations sont accordées pour un temps défini, puis révoquées. Cette discipline limite mécaniquement la casse en cas de compromission.
Hypothèse de violation. Les équipes de sécurité agissent comme si l’attaquant était déjà dans la place. C’est une posture qui découle des chiffres. La segmentation, la surveillance, la journalisation, la détection comportementale deviennent des opérations standard, plus du luxe. Si un poste est compromis, l’objectif change : il s’agit de contenir l’incident à un sous-réseau, un compte, une session, l’intrusion étant déjà ratée.
CrowdStrike formule ces principes un peu différemment, en parlant de « limitation de l’onde de choc » et d’« automatisation de la collecte du contexte ». L’idée reste la même.
Les cinq piliers du Zero Trust selon la CISA
Le modèle de maturité de la CISA structure l’architecture autour de cinq domaines, avec des niveaux d’avancement (traditionnel, initial, avancé, optimal). C’est aujourd’hui la grille de lecture la plus pratique pour faire un état des lieux d’entreprise.
| Pilier | Ce qu’il couvre | Briques techniques typiques |
|---|---|---|
| Identité | Qui se connecte | IAM, SSO, MFA, fournisseur d’identité, SCIM |
| Appareils | Avec quoi on se connecte | MDM, EDR, conformité OS, certificats |
| Réseaux | Par où passent les flux | Micro-segmentation, ZTNA, SASE, chiffrement |
| Applications et workloads | À quoi on accède | API gateway, validation continue, contrôle d’accès dynamique |
| Données | Ce qu’on protège | Classification, DLP, chiffrement au repos et en transit |
Le pilier Identité est généralement le premier chantier, parce que c’est sur lui que reposent tous les autres. Sans une vue claire de qui est qui dans le SI, impossible de calibrer le moindre privilège, ni de détecter un comportement anormal. Les piliers Données et Applications viennent souvent en dernier, parce qu’ils touchent au métier et demandent un travail de cartographie qui peut être long.
IAM, PAM, MFA : la brique identité au cœur du dispositif
Trois acronymes reviennent en boucle dès qu’on parle Zero Trust. Ils ne désignent pas la même chose.
IAM (Identity and Access Management) gère les identités ordinaires. C’est la base annuaire (Entra ID, Okta, Ping, Keycloak), le SSO, le provisionnement automatique des comptes quand un nouvel arrivant rejoint l’entreprise, et la déprovisionnement quand il part. Sans IAM solide, le moindre privilège est impossible à appliquer parce qu’on ne sait même pas qui a accès à quoi.
PAM (Privileged Access Management) s’occupe spécifiquement des comptes à privilèges : administrateurs systèmes, comptes de service, accès root, clés API critiques. Ces comptes sont la cible numéro un des attaquants. Un PAM stocke les mots de passe dans un coffre, les remplace régulièrement, force des sessions enregistrées et n’autorise un accès admin que pour une tâche précise et un temps limité (juste-in-time access). CyberArk, BeyondTrust, Delinea sont les acteurs historiques sur ce créneau.
MFA (authentification multifacteur) ajoute une preuve supplémentaire au mot de passe. Code reçu par SMS, notification push sur smartphone, clé physique FIDO2 (Yubikey, Titan Key), empreinte. Toutes les MFA ne se valent pas. Le SMS reste vulnérable au SIM-swapping, les codes par e-mail peuvent fuiter avec la boîte. Les recommandations actuelles, y compris celles de Cloudflare et de l’ANSSI, privilégient les clés matérielles FIDO2, qui résistent au phishing.
Sans ces trois briques, parler de Zero Trust n’a pas grand sens. C’est de l’identité bien gérée que tout le reste découle.
Micro-segmentation : la fin du mouvement latéral
Dans un réseau classique, une fois qu’un attaquant à un pied sur un poste, il peut souvent atteindre les serveurs internes, les partages de fichiers, parfois le contrôleur de domaine. C’est ce qu’on appelle le mouvement latéral, et c’est la phase la plus destructrice d’une intrusion.
La micro-segmentation découpe le réseau en zones isolées de granularité fine. Plus de gros sous-réseaux où tout se voit. À la place, des micro-périmètrès : les serveurs de paie ne parlent qu’à l’application paie, les caméras IP ne parlent qu’au serveur de vidéosurveillance, les imprimantes ne parlent à rien d’autre que les postes utilisateurs autorisés. Chaque flux nécessite une autorisation explicite, et tout le reste est bloqué par défaut.
Techniquement, ça repose sur des politiques de sécurité applicatives (par exemple via des SDN, du SDP ou des solutions comme Illumio, Guardicore, VMware NSX), pas sur des VLAN traditionnels. Un attaquant qui compromet un poste de la compta se retrouve dans une bulle. Il peut casser ce qu’il y a dans la bulle, pas plus. C’est moins glamour qu’un pare-feu nouvelle génération, mais c’est là que se joue la vraie réduction de risque.
ZTNA et SASE : remplacer le VPN par de l’accès contextuel
Le VPN d’entreprise est un héritage des années 2000. Vous montez un tunnel chiffré entre l’utilisateur distant et le réseau du siège, et l’utilisateur se retrouve « comme s’il était au bureau ». C’est précisément le problème : il accède au réseau entier, pas aux applications dont il a besoin. Et si son poste est compromis, l’attaquant accède aussi au réseau entier.
ZTNA (Zero Trust Network Access) inverse la logique. Au lieu de connecter l’utilisateur au réseau, on le connecte à une application précise, après vérification d’identité, d’appareil et de contexte. L’infrastructure interne reste invisible : l’utilisateur ne sait même pas qu’il y à un serveur derrière. Si l’application change d’adresse, ça ne change rien pour lui. C’est plus sûr, plus rapide (pas de tunnel à monter à chaque connexion) et plus scalable que le VPN.
SASE (Secure Access Service Edge), prononcé « sassy », est le cadre plus large dans lequel ZTNA prend place. Inventé par Gartner en 2019, le SASE combine en un seul service cloud : ZTNA, passerelle web sécurisée (SWG), CASB (sécurité du SaaS), pare-feu nouvelle génération en mode service (FWaaS), et SD-WAN. L’idée : centraliser tous les contrôles de sécurité dans une plateforme cloud unique, plutôt que d’avoir un patchwork d’appliances locales. Cloudflare One, Zscaler Zero Trust Exchange, Cisco Umbrella+, Netskope sont les principales offres SASE du marché.
Pour une entreprise qui à des collaborateurs partout, des applications éclatées entre datacenter et cloud, et un mix VPN/proxy/firewall vieillissant, le SASE est souvent la voie de migration la plus directe vers du Zero Trust opérationnel.
Comment passer au Zero Trust : une feuille de route en trois phases
CrowdStrike propose un découpage qu’on retrouve sous d’autres noms ailleurs (CISA, Microsoft) et qui marche bien sur le terrain. Trois phases, à dérouler dans l’ordre.
Phase 1 : Visualiser. Avant de protéger, il faut savoir quoi protéger. Inventaire des identités (humains, services, comptes techniques), des appareils, des applications, des flux. Cartographie des accès actuels (qui peut faire quoi), repérage des comptes dormants, des privilèges excessifs, des shadow IT. Cette phase peut durer trois à six mois sur un SI moyen, et c’est souvent celle qu’on bâclé. Mauvaise idée. Sans visibilité, le reste se fait à l’aveugle.
Phase 2 : Atténuer. Mise en place des contrôles : MFA généralisée (en priorité sur les comptes admin), durcissement IAM, déploiement d’un PAM, segmentation des flux les plus sensibles, remplacement progressif du VPN par du ZTNA. C’est ici que la majorité des bénéfices se concrétisent. Une entreprise qui en reste à cette phase et fait bien le travail aura déjà coupé 70 à 80 % de sa surface d’attaque.
Phase 3 : Optimiser. Étendre le modèle à tout le SI, intégrer la détection comportementale (UEBA), automatiser la réponse aux incidents, descendre la micro-segmentation au niveau applicatif, classifier les données. C’est un travail qui ne s’arrête jamais vraiment, et c’est normal : le Zero Trust est un état permanent, pas un projet qui se termine.
Comptez en général deux à quatre ans pour qu’une entreprise de taille moyenne arrive à un niveau de maturité « avancé » selon la grille CISA. Les projets qui veulent aller plus vite échouent presque toujours, parce qu’ils sautent la phase de visualisation.
Cas d’usage concrets : où le modèle change vraiment la donne
Télétravail. Le scénario d’école. Au lieu d’un VPN qui ouvre tout le réseau, l’utilisateur accède via ZTNA à exactement les applications dont il a besoin. Si son poste est compromis, le rayon d’action est minuscule. Si son appareil n’est pas conforme (OS pas à jour, EDR désactivé), l’accès est refusé sans intervention humaine.
Multicloud et environnements hybrides. Quand vos charges de travail sont éclatées entre AWS, Azure, GCP et un datacenter on-prem, le périmètre n’a plus de sens. Le Zero Trust applique des politiques cohérentes partout, basées sur l’identité et le contexte, pas sur la localisation réseau. C’est un sujet qui rejoint directement les problématiques d’architecture cloud computing.
Chaîne logistique. Les attaques par la supply chain (un fournisseur compromis qui sert de relais vers l’entreprise) ont explosé ces dernières années. Le Zero Trust limite drastiquement ce risque, parce qu’un compte fournisseur, même compromis, n’a accès qu’à un périmètre défini, pas au SI entier.
Internet des objets. Les caméras, capteurs, automates industriels sont notoirement difficiles à patcher et constituent des points d’entrée privilégiés pour les attaquants. Une architecture Zero Trust les surveille en continu, vérifie leur intégrité et limite leur capacité de communication à ce qui est strictement nécessaire à leur fonction.
Fusions-acquisitions. Intégrer un SI tiers est un cauchemar de sécurité classique. Avec une approche Zero Trust, vous pouvez accorder des accès granulaires aux équipes de l’entité absorbée sans fusionner les annuaires en urgence ni faire confiance à un réseau dont vous ignorez encore la posture de sécurité.
Les pièges et les limites à connaître avant de se lancer
Le Zero Trust n’est ni une solution magique ni un produit qu’on achète sur étagère. Quelques travers reviennent souvent dans les retours d’expérience.
Le premier piège, c’est de croire qu’on fait du Zero Trust en achetant un produit estampillé « Zero Trust ». Aucun éditeur ne peut livrer une architecture clé en main : c’est un modèle qui touche les processus, l’organisation, les contrats fournisseurs, autant que la technique. Méfiez-vous des promesses commerciales un peu rondes.
Deuxième piège : surcharger l’utilisateur final de demandes d’authentification. Si vous obligez les collaborateurs à se réauthentifier toutes les heures par MFA, ils vont chercher des contournements (post-it avec mot de passe, partage de session, désactivation discrète des contrôles). Le Zero Trust bien fait est largement transparent pour l’utilisateur. Mal fait, il devient un cauchemar ergonomique qui fragilise plus qu’il ne sécurise.
Troisième piège : oublier les comptes de service et les identités machines. Dans un SI moderne, les identités non humaines (scripts, conteneurs, services cloud) sont souvent dix à vingt fois plus nombreuses que les humains. Et leurs privilèges sont rarement audités. C’est un angle mort énorme, que des outils comme HashiCorp Vault commencent à adresser sérieusement.
Le coût, enfin. Une architecture Zero Trust mature coûte cher en licences (IAM moderne, PAM, ZTNA/SASE), en intégration et en compétences. Pour une PME, le calcul peut être délicat à équilibrer. Le bon arbitrage consiste souvent à attaquer en priorité les briques à plus fort retour sur investissement (MFA partout, PAM sur les comptes admin, ZTNA pour le télétravail), et à étendre par paliers une fois les premiers gains acquis. Le cadrage budgétaire est un sujet à part entière, qui rejoint les enjeux plus larges de cybersécurité en PME.
Questions fréquentes sur la sécurité réseau Zero Trust
▸Le Zero Trust remplace-t-il complètement les pare-feu ?
▸Quelle est la différence entre ZTNA et VPN ?
▸Faut-il être une grande entreprise pour adopter le Zero Trust ?
▸Le Zero Trust ralentit-il les utilisateurs ?
▸Quels sont les standards de référence à suivre ?
▸Peut-on mesurer le retour sur investissement d’un projet Zero Trust ?
Le Zero Trust n’a rien d’une mode. C’est la conséquence logique d’un environnement IT qui a éclaté son périmètre il y a quinze ans. La vraie question n’est plus « est-ce qu’il faut y aller ? », mais « par où commencer et à quel rythme ? ». Le bon point d’attaque, dans la quasi-totalité des cas, c’est l’identité : MFA partout, PAM sur les comptes sensibles, IAM remis à plat. Le reste vient ensuite, par paliers. Évitez les big-bangs, ils n’aboutissent jamais.
Une chose à garder en tête, quand même : le Zero Trust déplace le risque, il ne le supprime pas. Vous remplacez une grosse vulnérabilité périmétrique par mille petites vulnérabilités d’identité. La discipline opérationnelle (rotation des secrets, audit régulier, revue des accès, formation des utilisateurs) compte autant que les outils. Le meilleur SASE du marché ne fera rien contre un mot de passe administrateur partagé sur trois Post-it. Comme souvent en sécurité, le maillon humain reste le maillon faible, et aucun modèle d’architecture n’y change vraiment quelque chose.







