Le paradigme Zero Trust de la confiance implicite à la vérification continue
Executive summary
Le Zero Trust n’est pas un slogan marketing ni une simple évolution des outils de sécurité. C’est une rupture architecturale profonde avec le modèle périmétrique historique, fondé sur une confiance implicite accordée à tout ce qui se trouve « à l’intérieur » du système d’information.
Face à la dispersion des actifs numériques (cloud, SaaS, API), à la généralisation du travail hybride et à la professionnalisation des attaques, ce modèle a atteint ses limites. L’ANSSI comme le NIST convergent aujourd’hui vers un même constat : la sécurité moderne repose sur une vérification continue, contextuelle et systématique de chaque accès, qu’il soit humain ou machine.
Dans cet article, nous revenons sur les fondements conceptuels et réglementaires du Zero Trust, avant de proposer une méthodologie pragmatique d’évaluation et de déploiement, alignée avec les exigences NIS2 et DORA. L’objectif : donner aux DSI et RSSI une grille de lecture claire, opérationnelle et durable.
L’obsolescence du modèle périmétrique
Pendant des décennies, la cybersécurité s’est construite autour du modèle dit du « château et des douves » ou de la «forteresse » : un périmètre fortement défendu, à l’intérieur duquel la confiance était largement implicite. Une fois l’authentification initiale passée, les mouvements internes étaient peu ou mal contrôlés.
Cette hypothèse ne résiste plus à la réalité opérationnelle.
Des frontières dissoutes
Parallèlement, le travail hybride est devenu la norme. L’ANSSI souligne dans son guide sur le nomadisme numérique (v2.0, novembre 2023) que les contextes d’accès non maîtrisés représentent désormais la majorité des accès aux systèmes d’information.
Une réalité confirmée par les incidents
Les statistiques d’attaque confirment cette bascule. Les mouvements latéraux, qui exploitent précisément la confiance interne, constituent aujourd’hui le vecteur privilégié des ransomwares. L’ENISA estime dans son Threat Landscape 2025 un temps moyen de résidence de 21 jours avant détection.
C’est dans ce contexte que l’ANSSI a publié un premier avis sur le Zero Trust dès 2021, consolidé en 2025 par les « Fondamentaux du modèle Zero Trust », actant l’impossibilité de maintenir une frontière hermétique et durable.
Les trois piliers du NIST SP 800-207
Le NIST a formalisé en 2020 le référentiel SP 800-207, Zero Trust Architecture, qui repose sur trois principes structurants.
1. Vérifier explicitement (Verify Explicitly)
Chaque demande d’accès doit être authentifiée et autorisée dynamiquement, à partir de l’ensemble des signaux disponibles :
- identité de l’utilisateur ou du service,
- posture de sécurité du terminal,
- localisation et contexte réseau,
- sensibilité de la ressource,
- niveau de risque en temps réel.
La vérification ne s’effectue plus une seule fois à la connexion, mais en continu, tout au long de la session. Ce principe a été rendu obligatoire pour les agences fédérales américaines par l’Executive Order 14028 et le mémorandum OMB M-22-09.
2. Appliquer le moindre privilège (Use Least Privilege Access)
Le Zero Trust impose une réduction drastique de la surface d’exposition : chaque entité ne dispose que des droits strictement nécessaires, pour une durée limitée et un périmètre précis.
L’ANSSI recommande la suppression des privilèges permanents au profit d’approches Just-in-Time (JIT) et Just-Enough-Access (JEA), applicables aux utilisateurs, aux administrateurs, aux comptes de service et aux processus applicatifs.
3. Supposer la compromission (Assume Breach)
C’est sans doute le changement culturel le plus exigeant. L’architecture doit être pensée comme si un attaquant était déjà présent dans le système.
Cela implique :
- une micro-segmentation fine des ressources,
- une surveillance comportementale continue,
- une réduction maximale du blast radius en cas d’incident.
La CISA positionne d’ailleurs la micro-segmentation comme l’un des piliers clés de son cadre Journey to Zero Trust.
Le modèle décisionnel de l’ANSSI
Les sujets
Toute entité demandant un accès : utilisateur, administrateur, compte de service, processus automatisé. Leur identité doit être vérifiée via des mécanismes MFA robustes, idéalement résistants au phishing (FIDO2).
Les ressources
Applications, données, API, infrastructures. Chaque ressource est qualifiée selon sa criticité DIC (Disponibilité, Intégrité, Confidentialité), qui conditionne le niveau d’exigence.
Le contexte
Il agrège l’ensemble des signaux dynamiques : posture du terminal, localisation, horaire, réseau d’origine, comportement récent, niveau de menace détecté.
La décision d’accès
Elle est prise par un Policy Engine, qui évalue ces paramètres en temps réel à l’aide de règles et, idéalement, d’un algorithme de confiance dynamique. Cette décision est ensuite appliquée par des Policy Enforcement Points (PEP) : ZTNA, reverse proxy, pare-feu applicatif, etc.
La centralisation de la télémétrie dans un SIEM est indispensable pour corréler les signaux faibles et détecter les compromissions précoces.
Zero Trust et exigences réglementaires : NIS2 et DORA
NIS2 : une exigence structurelle
La directive NIS2 impose depuis octobre 2024 dix mesures minimales de cybersécurité. Plusieurs sont directement alignées avec le Zero Trust :
- Gestion des risques par identité et contexte,
- Détection rapide des incidents,
- Sécurisation de la chaîne d’approvisionnement.
L’ENISA recommande explicitement le déploiement de SIEM, EDR/XDR et l’adoption du ZTNA pour les accès distants.
DORA : la résilience opérationnelle au cœur
Le règlement DORA, applicable depuis janvier 2025, renforce ces exigences pour le secteur financier. Les Threat-Led Penetration Tests (TLPT), alignés sur TIBER-EU, valident concrètement l’efficacité des dispositifs Zero Trust.
DORA impose également une segmentation fine et une supervision continue des prestataires ICT, rendant le Zero Trust quasiment incontournable.
Méthodologie de déploiement standard, à adapter en fonction des contextes et des moyens:
PDCA: Plan-Do-Act-Check (principe issu de ISO27001)
Le Zero Trust ne se décrète pas : il se construit progressivement.
Phase 1 : identifier les ressources
Cartographier applications, données, flux et environnements. Prioriser selon la criticité métier et les contraintes réglementaires.
Phase 2 : cartographier les dépendances
Analyser les flux réseau et applicatifs pour révéler les dépendances réelles, souvent bien plus larges que prévu.
Phase 3 : définir les politiques
Traduire les besoins métiers en règles d’accès granulaires, gouvernées, documentées et auditables.
Phase 4 : déployer et valider
Piloter sur un périmètre restreint, mesurer, ajuster, puis généraliser. La formation et l’adhésion des équipes sont déterminantes.
Livrables clés : schéma cible et anti-patterns
Un programme Zero Trust mature produit au minimum :
- Un schéma cible d’architecture,
- Une check-list d’anti-patterns pour éviter les écueils classiques : approche purement réseau, solutions monolithiques, sous-estimation de la gouvernance, absence de métriques, manque de sponsoring exécutif.
| Dimension | Modèle Périmétrique Traditionnel | Zero Trust Architecture |
|---|---|---|
| Hypothèse de confiance | Interne = confiance, Externe = menace | Aucune confiance implicite, vérification continue |
| Point de décision | Authentification initiale (VPN, pare-feu) | Chaque requête, chaque session |
| Granularité | Segmentation macro (VLAN, zones DMZ) | Micro-segmentation (application, workload, API) |
| Critères d'accès | Localisation réseau (IP interne/externe) | Identité + appareil + contexte + risque |
| Surveillance | Périodique, focalisée sur le périmètre | Continue, télémétrie complète (logs, flux, comportements) |
| Gestion des identités | Centralisée mais statique (LDAP / AD) | Dynamique, fédérée, avec scoring de confiance |
| Conformité | Audits ponctuels, preuves documentaires | Traçabilité temps réel, reporting automatisé |
Le Zero Trust n’est ni une mode ni un produit : c’est une réponse architecturale structurante aux limites du modèle périmétrique. Les convergences entre l’ANSSI, le NIST et les régulateurs européens rendent cette transformation inévitable.
La mise en place d’architectures Zero Trust est souvent complexe et difficile quand elle part d’un existant à faire évoluer : la dette technologique existante ralentit ou décourage toute initiative de rupture. En partant de zéro, les démarches « Secure by design » et/ou « Secure by default » permettent souvent une meilleure gestion des contraintes et des priorités liées au Zero Trust.
La clé du succès, par conséquent, réside dans une démarche progressive, une gouvernance claire et une implication transverse des équipes IT, sécurité et métiers. Les prochains articles de cette série approfondiront les briques opérationnelles : identité, ZTNA-SASE, accès privilégiés, segmentation, API, cryptographie post-quantique et supervision intelligente.
