Zero Trust : principes, mise en œuvre et conformité

Le Zero Trust n’est ni un produit, ni une technologie : c’est un modèle d’architecture de sécurité qui part d’un postulat simple — aucun utilisateur, aucun terminal, aucun flux ne doit être considéré comme digne de confiance par défaut, même à l’intérieur du périmètre de l’entreprise. Dans un contexte où 80 % des intrusions exploitent des identifiants valides et où le télétravail a dissous le périmètre réseau traditionnel, le Zero Trust est devenu la réponse opérationnelle à la convergence des obligations posées par NIS2, le RGPD et les recommandations de l’ANSSI. Cet article détaille les principes fondateurs du modèle, son cadre juridique implicite et une feuille de route de déploiement éprouvée.

I. Origine et définition du modèle Zero Trust

A. De BeyondCorp à NIST SP 800-207

Le concept de Zero Trust a été théorisé en 2010 par John Kindervag (Forrester Research) en réaction aux limites du modèle périmétrique classique (château-et-douves), dans lequel tout ce qui est à l’intérieur du réseau de l’entreprise est implicitement considéré comme fiable. L’implémentation industrielle du modèle a été popularisée par Google avec l’architecture BeyondCorp (2014), déployée à la suite de l’attaque Aurora (2009) qui avait exploité la confiance accordée aux postes internes.

La référence normative aujourd’hui est la publication NIST SP 800-207 “Zero Trust Architecture” (2020), qui définit le Zero Trust comme un ensemble de principes conçus pour minimiser l’incertitude dans la prise de décisions d’accès dans les systèmes et services d’information. L’ANSSI a publié en 2023 une note sur le modèle Zero Trust qui reprend les fondamentaux du NIST tout en soulignant les difficultés pratiques de mise en œuvre dans les environnements français.

B. Ce que Zero Trust n’est pas

Le marketing des éditeurs de sécurité a largement dilué le sens du terme. Pour clarifier, Zero Trust n’est pas un VPN nouvelle génération, un produit d’authentification, une solution d’endpoint, ni une simple segmentation réseau. Aucun éditeur ne peut vendre “le Zero Trust” sous forme d’une licence unique : c’est une stratégie d’architecture qui combine plusieurs briques techniques (identité, réseau, données, terminaux) autour d’une politique d’accès commune et contextuelle.

À l’inverse, Zero Trust est un cadre de décision : chaque requête d’accès (un utilisateur qui ouvre une application, un service qui en appelle un autre, un administrateur qui se connecte à un serveur) est évaluée dynamiquement à partir de multiples signaux (identité vérifiée, posture du terminal, sensibilité de la ressource, contexte de la connexion) avant d’être autorisée, refusée ou soumise à des contrôles supplémentaires.

II. Les principes directeurs du Zero Trust

A. Never trust, always verify

Le premier principe — “ne jamais faire confiance, toujours vérifier” — signifie que chaque requête d’accès doit être authentifiée, autorisée et chiffrée, quelle que soit son origine. Un utilisateur qui se connecte depuis le siège social avec un poste géré par la DSI n’est pas traité différemment, sur le plan du contrôle d’accès, d’un utilisateur qui se connecte depuis un aéroport avec un ordinateur personnel. La confiance n’est plus dérivée de la localisation réseau mais de signaux vérifiables en temps réel.

Ce principe impose un couplage fort avec l’authentification forte (MFA) : sans MFA robuste, impossible de faire du Zero Trust crédible. Dans mon expérience d’accompagnement, j’ai vu des projets Zero Trust capoter dès la première étape parce que l’entreprise n’avait pas d’annuaire centralisé ou que la MFA n’était déployée que sur une fraction des utilisateurs. L’identité est le point de départ, pas une option.

B. Least privilege access (moindre privilège)

Chaque identité (humaine ou machine) ne doit recevoir que les droits strictement nécessaires à l’accomplissement de sa mission, et uniquement pour la durée nécessaire. Concrètement, cela implique :

• La suppression des comptes “admin de tout” au profit de comptes d’administration délégués par périmètre (Just-Enough-Administration) ;
• La généralisation des accès just-in-time (l’administrateur obtient ses droits pour une durée limitée après approbation ou en contexte d’intervention) ;
• La révocation automatique des droits à la fin des projets, des contrats ou des mobilités internes ;
• L’application du principe du moindre privilège aux applications et aux services eux-mêmes (un service web ne doit pas tourner sous un compte de service disposant des droits d’administration sur la base de données).

Ce principe rejoint directement les exigences de l’article 32 du RGPD sur la minimisation des accès et l’obligation de garantir la confidentialité des traitements.

C. Assume breach (présumer la compromission)

Le troisième principe suppose que l’attaquant est déjà présent dans le système d’information. Cette posture change complètement la conception de la sécurité : il ne s’agit plus uniquement d’empêcher l’intrusion, mais de contenir la compromission, de limiter les déplacements latéraux et de détecter les comportements anormaux le plus tôt possible.

Opérationnellement, “assume breach” se traduit par la micro-segmentation du réseau (chaque zone est isolée et communique uniquement via des règles explicites), la journalisation exhaustive des accès et des événements, la surveillance comportementale (UEBA, détection d’anomalies) et la préparation des plans de réaction (exercice de crise, PCA, PRA). L’attaquant qui entre sur un poste compromis ne doit pas pouvoir se déplacer librement vers les serveurs de données.

III. L’architecture technique : les composants clés

A. Le moteur de politique (Policy Engine)

Au cœur d’une architecture Zero Trust se trouve un moteur de décision qui évalue chaque requête d’accès en combinant plusieurs sources de signaux : identité de l’utilisateur (annuaire, IDP), posture du terminal (gestion de flotte, conformité), sensibilité de la ressource (classification des données), contexte de la connexion (localisation, horaire, réseau), historique comportemental (UEBA).

La décision du moteur n’est pas binaire : elle peut être autoriser, refuser, autoriser avec contrôle supplémentaire (défi MFA, limitation de la session) ou autoriser en lecture seule. C’est ce que les solutions de type Conditional Access (Microsoft Entra, Okta, Cisco Duo) implémentent.

B. Le proxy d’accès (Policy Enforcement Point)

Le PEP est le composant qui intercepte concrètement les requêtes et applique la décision du moteur de politique. Dans les architectures modernes, il prend la forme d’une passerelle d’accès aux applications (ZTNA — Zero Trust Network Access), qui remplace progressivement le VPN classique. Le ZTNA expose uniquement les applications autorisées à chaque utilisateur, au lieu d’ouvrir un tunnel vers l’intégralité du réseau.

Les solutions ZTNA disponibles sur le marché (Zscaler, Netskope, Cloudflare Access, Cisco Secure Access, Palo Alto Prisma) répondent toutes à cette logique, avec des différences sur la couverture des protocoles, l’intégration avec les annuaires et la localisation des points de présence.

C. La micro-segmentation et la vérification continue

La micro-segmentation consiste à cloisonner le réseau en zones de confiance les plus petites possibles — idéalement, la granularité de l’application ou du service. Les communications entre zones sont soumises à des règles explicites, journalisées et chiffrées. Cette approche limite drastiquement les déplacements latéraux en cas d’intrusion, ce qui est précisément la phase que les groupes de rançongiciels exploitent pour maximiser leurs impacts.

La vérification doit être continue, pas seulement au moment de la connexion initiale. Si la posture du terminal change en cours de session (un antivirus désactivé, une connexion à un réseau Wi-Fi non approuvé), l’accès doit être réévalué et, le cas échéant, restreint ou interrompu.

IV. Zero Trust et conformité réglementaire

A. NIS2 : une convergence implicite

La directive NIS2 ne mentionne pas explicitement le Zero Trust, mais l’article 21, paragraphe 2, énumère des mesures de gestion des risques qui s’articulent naturellement avec ce modèle : politiques de contrôle d’accès et de gestion des actifs (point i), utilisation de l’authentification multifacteur (point j), sécurité des ressources humaines incluant l’accès aux actifs (point i), sécurité de la chaîne d’approvisionnement (point d). Les entités essentielles et importantes soumises à NIS2 trouvent dans Zero Trust une réponse architecturale cohérente à la majorité de ces exigences.

Lors d’un contrôle NIS2, un superviseur n’interrogera pas l’entreprise sur son “adoption du Zero Trust” mais sur la présence de mesures concrètes : segmentation, MFA généralisée, journalisation, revue des droits, détection des anomalies. Une architecture Zero Trust bien conçue permet de documenter ces mesures avec une cohérence que les approches en silos ne permettent pas.

B. RGPD : la sécurité de l’article 32

L’article 32 du RGPD impose des mesures de sécurité “appropriées” au risque, en prenant en compte l’état de l’art. Les principes Zero Trust répondent directement aux obligations de confidentialité (contrôle des accès), d’intégrité (micro-segmentation, moindre privilège) et de disponibilité (détection précoce, confinement). La CNIL, dans ses guides techniques, recommande depuis plusieurs années des mesures qui préfigurent le Zero Trust : chiffrement systématique, authentification forte pour les accès à distance et aux données sensibles, journalisation des accès, séparation des environnements.

Dans les décisions de sanction récentes, la CNIL a explicitement pointé l’absence de segmentation interne ou de contrôle d’accès granulaire comme constitutive d’un manquement à l’article 32. Un dispositif Zero Trust crédible est un argument défensif puissant en cas d’audit RGPD ou de contrôle de l’autorité.

C. ANSSI, SecNumCloud et les référentiels sectoriels

L’ANSSI, sans imposer le Zero Trust, oriente son référentiel d’hygiène informatique et ses guides dans cette direction : durcissement des comptes d’administration, authentification forte, cloisonnement réseau, surveillance. Le référentiel SecNumCloud exige des mesures techniques qui sont de facto des briques Zero Trust (isolation stricte, contrôle des accès privilégiés, traçabilité exhaustive). Les secteurs régulés (santé via HDS, finance via DORA, défense) convergent vers ces exigences.

V. Mise en œuvre : feuille de route en cinq étapes

Étape 1 — Cartographier l’existant

Un projet Zero Trust démarre toujours par un inventaire : applications (internes, SaaS, héritées), flux entre applications, populations d’utilisateurs (interne, externe, partenaires), terminaux (gérés, BYOD), données (classification, localisation, traitements). Sans cet inventaire, on ne sait pas quoi protéger ni quelles politiques écrire. L’analyse de risques EBIOS RM fournit un cadre méthodologique solide pour prioriser les actifs.

Étape 2 — Sécuriser l’identité

L’identité est la fondation. Cela implique un annuaire centralisé unique (ou une fédération maîtrisée), la suppression des comptes locaux non justifiés, le déploiement de la MFA à 100 % (pas seulement sur les accès sensibles), la mise en place d’un gouvernance des identités (joiner/mover/leaver automatisés) et la gestion des comptes à privilèges via un PAM (Privileged Access Management).

Étape 3 — Mettre en place les politiques d’accès conditionnel

À partir de signaux d’identité, de posture et de contexte, on définit les règles : qui peut accéder à quoi, depuis quels terminaux, à quelles conditions. Ces politiques sont testées sur des populations pilotes avant généralisation. La politique de sécurité documente ces règles et leur gouvernance.

Étape 4 — Segmenter le réseau et les applications

On remplace progressivement le VPN par une solution ZTNA qui expose uniquement les applications autorisées. On segmente le réseau interne pour isoler les environnements sensibles (serveurs de production, données de santé, environnement de paie). Cette étape est la plus longue et la plus coûteuse, mais c’est elle qui produit les gains les plus importants en matière de confinement d’intrusion.

Étape 5 — Superviser, auditer, améliorer

Une architecture Zero Trust produit un volume considérable de journaux qu’il faut collecter (SIEM), corréler (EDR, UEBA) et exploiter (SOC interne ou externalisé). Les tests d’intrusion permettent de vérifier régulièrement l’efficacité réelle des politiques. L’audit de sécurité informatique annuel doit inclure une revue spécifique des politiques d’accès conditionnel et du taux de couverture Zero Trust.

VI. Pièges et erreurs à éviter

Le piège du produit miracle. Aucun éditeur ne vend “le Zero Trust”. Méfiez-vous des commerciaux qui vous proposent une licence unique résolvant l’ensemble du problème. Zero Trust est un programme pluriannuel qui combine plusieurs technologies et, surtout, un changement d’approche.

Le piège de la big bang. Vouloir déployer l’ensemble des briques en même temps échoue dans 90 % des cas. Une approche itérative, par population ou par périmètre applicatif, est la seule qui fonctionne à grande échelle.

Le piège des applications héritées. Les applications anciennes qui n’intègrent pas les standards modernes (SAML, OIDC, SCIM) sont un problème récurrent. Une analyse préalable permet d’identifier celles qui devront être encapsulées derrière une passerelle, migrées ou retirées.

Le piège du “VPN suffit”. Le VPN n’est pas Zero Trust. Un VPN classique donne accès à un réseau entier après authentification initiale. Le ZTNA donne accès à une application spécifique, après vérification continue du contexte. La différence est fondamentale en cas de compromission d’un poste.

Le piège de la sous-estimation de la conduite du changement. Les utilisateurs perçoivent initialement le Zero Trust comme une contrainte (plus d’authentifications, plus de restrictions). Sans accompagnement, le taux de contournement explose. La communication, la formation et la sensibilisation à la sécurité sont essentielles. La conformité du dispositif est également un point vérifié dans les checklists NIS2.

Ce qu’il faut retenir

• Zero Trust est un modèle d’architecture, pas un produit : il repose sur trois principes — never trust always verify, moindre privilège et assume breach.
• NIS2 et le RGPD n’imposent pas explicitement Zero Trust, mais les mesures exigées (MFA, contrôle d’accès, segmentation, journalisation) convergent naturellement vers ce modèle.
• L’identité est la fondation : sans MFA généralisée et sans annuaire centralisé, un projet Zero Trust n’a pas de base solide.
• La mise en œuvre doit être itérative, priorisée par une analyse de risques EBIOS RM et étalée sur 18 à 36 mois selon la maturité initiale.
• Les deux gains majeurs sont la résistance aux mouvements latéraux en cas d’intrusion et la capacité documentée à répondre aux contrôles NIS2, RGPD et ANSSI.

FAQ

Zero Trust est-il obligatoire sous NIS2 ?

Non, la directive NIS2 ne mentionne pas explicitement Zero Trust. En revanche, l’article 21 impose des mesures (authentification multifacteur, contrôle d’accès, gestion des actifs, sécurité de la chaîne d’approvisionnement) qui s’articulent naturellement avec ce modèle. Une architecture Zero Trust crédible facilite la démonstration de conformité lors d’un contrôle de l’autorité de supervision, sans qu’elle soit juridiquement imposée sous ce nom.

Quelle différence entre VPN et ZTNA ?

Un VPN classique crée un tunnel chiffré entre le poste de l’utilisateur et le réseau de l’entreprise. Une fois authentifié, l’utilisateur accède à un segment réseau entier. Le ZTNA (Zero Trust Network Access) n’ouvre jamais de tunnel réseau : il expose uniquement les applications autorisées pour l’utilisateur, après vérification continue de son identité, de la posture de son terminal et du contexte de la connexion. En cas de compromission d’un poste, un VPN donne potentiellement accès à tout le réseau, tandis qu’un ZTNA limite la compromission aux applications effectivement autorisées.

Combien de temps dure un projet Zero Trust ?

Selon la taille et la maturité initiale de l’organisation, un programme Zero Trust se déploie typiquement sur 18 à 36 mois. Les 6 premiers mois servent généralement à la cartographie et à la consolidation de l’identité (annuaire, MFA, gestion des identités). Les 12 mois suivants sont consacrés aux politiques d’accès conditionnel et au remplacement du VPN par une solution ZTNA. La micro-segmentation réseau et la modernisation des applications héritées s’étalent ensuite sur 12 à 24 mois supplémentaires.

Zero Trust est-il adapté à une PME ?

Oui, dans une version proportionnée. Une PME n’a pas besoin d’une architecture Zero Trust de niveau Google ou banque centrale. Les briques essentielles — annuaire centralisé Microsoft 365 ou Google Workspace, MFA généralisée, politiques d’accès conditionnel, remplacement du VPN par une solution ZTNA native de l’écosystème cloud — sont accessibles à coût raisonnable. L’erreur serait de vouloir reproduire un projet grand compte : la PME doit viser une mise en œuvre pragmatique, adaptée à son inventaire d’applications et à sa population, tout en démontrant sa conformité aux obligations applicables (RGPD, NIS2 si concernée).