Les modèles de sécurité réseau classiques fonctionnaient sur un postulat simple : tout ce qui se trouve à l’intérieur du périmètre de l’entreprise mérite la confiance. Pare-feux, VPN et zones démilitarisées constituaient les remparts. Une fois passé le pont-levis, la circulation était libre.
Le Zero Trust renverse cette logique. Son hypothèse fondatrice, formalisée par le référentiel NIST SP 800-207 publié en août 2020, pose qu’aucun utilisateur, appareil ou flux ne doit être considéré comme fiable par défaut, y compris depuis le réseau interne.
Lire également : Quelle est la durée de validité d'un PC ?
Confiance implicite : la faille que le Zero Trust corrige
Pendant des années, la sécurité informatique reposait sur la notion de périmètre. Un employé connecté au réseau local de l’entreprise bénéficiait d’un accès large aux ressources internes. L’authentification se jouait à l’entrée, rarement après.
Le problème tient dans le mouvement latéral. Un attaquant qui compromet un seul poste, par phishing ou vol d’identifiants, hérite de la confiance accordée à ce poste. Il se déplace d’un serveur à l’autre, élève ses privilèges et accède aux données sensibles sans déclencher d’alerte. L’authentification multi-facteur a renforcé la barrière d’entrée, mais une fois la session ouverte, le contrôle s’arrêtait souvent là.
A découvrir également : Quel est l'OS le plus rapide ?
Le Zero Trust supprime cette confiance résiduelle. Chaque requête, chaque accès à une ressource, chaque flux entre deux applications doit être authentifié, autorisé selon son contexte et réévalué de manière continue. La localisation sur le réseau ne constitue plus un facteur de confiance.
Zero Trust et vérification continue : ce que le NIST SP 800-207 formalise
Le terme Zero Trust existait depuis 2010, quand l’analyste John Kindervag chez Forrester Research l’a proposé en remplacement de la règle « faire confiance, puis vérifier » par « ne jamais faire confiance, toujours vérifier ». Le NIST SP 800-207 a transformé cette idée en architecture de référence.
Un point souvent mal compris : le NIST SP 800-207 n’est pas une certification. C’est un cadre de conception, pas un standard applicable directement aux entreprises. Il décrit des principes directeurs et des composants architecturaux, sans prescrire un produit ou une pile technologique précise.
Les trois piliers opérationnels
De l’hypothèse centrale découlent trois exigences concrètes que toute implémentation Zero Trust doit respecter :
- Vérification explicite de chaque demande d’accès, fondée sur l’identité de l’utilisateur, l’état du terminal, la localisation, le comportement récent et la sensibilité de la ressource demandée.
- Application du principe de moindre privilège : chaque session accorde uniquement les droits nécessaires à la tâche en cours, pour une durée limitée. Pas d’accès permanent, pas de compte à privilèges qui ne expire jamais.
- Présomption de compromission : l’architecture part du principe qu’un attaquant est déjà présent dans l’environnement. Le chiffrement interne, la micro-segmentation et la surveillance continue des flux visent à limiter les dégâts d’une intrusion plutôt qu’à empêcher toute intrusion.
Ce troisième pilier marque la rupture la plus nette avec les modèles antérieurs. Il ne s’agit plus d’empêcher l’ennemi d’entrer, mais de réduire la portée des dommages en supposant qu’il est déjà là.
Maturité Zero Trust : la trajectoire progressive du modèle CISA
Passer d’une architecture périmétrique à un modèle Zero Trust ne se fait pas en basculant un interrupteur. Le modèle de maturité CISA 2.0, publié en avril 2023, propose une grille de progression répartie sur cinq piliers : identité, appareils, réseaux, applications et données.
La plupart des organisations qui commencent leur parcours Zero Trust se situent aux premiers échelons de cette grille. Elles disposent d’une authentification multi-facteur déployée partiellement, d’une segmentation réseau encore grossière et d’une visibilité limitée sur les flux entre applications.
Identités non humaines et workloads cloud-native
Les implémentations récentes déplacent l’attention au-delà des comptes utilisateurs classiques. Le NIST SP 800-207A, consacré aux applications cloud-native, met l’accent sur l’authentification des workloads (conteneurs, microservices, fonctions serverless) et les politiques d’accès fondées sur l’identité plutôt que sur la localisation réseau.
Les comptes de service, les clés API et les identités machine représentent une surface d’attaque souvent négligée. Un compte de service avec des privilèges élevés et sans date d’expiration constitue exactement le type de confiance implicite que le Zero Trust cherche à éliminer.
Limites connues de l’approche Zero Trust en entreprise
Le Zero Trust ne résout pas tout, et certaines zones grises persistent dans les déploiements réels.
La complexité opérationnelle est le premier frein. Chaque micro-segment, chaque politique d’accès contextuelle, chaque règle de vérification continue ajoute une couche de gestion. Les équipes sécurité de taille réduite peuvent se retrouver submergées par le volume de règles à maintenir, surtout quand les environnements mêlent infrastructure sur site et cloud.
La question de la couverture complète reste ouverte. Atteindre le niveau de maturité le plus élevé sur l’ensemble des cinq piliers simultanément demeure exceptionnel. Les systèmes industriels anciens (SCADA, automates), qui ne supportent ni l’authentification moderne ni la micro-segmentation, posent un défi concret d’intégration.
Enfin, le Zero Trust repose sur la qualité des données contextuelles. Si les journaux d’activité sont incomplets, si la classification des données est approximative ou si l’inventaire des actifs présente des angles morts, les décisions d’accès manquent de fiabilité. L’architecture vaut ce que valent les données qui l’alimentent.
Le Zero Trust n’est ni un produit à acheter ni une destination finale. C’est une posture de conception qui remplace la confiance héritée par une vérification permanente. L’hypothèse de départ, celle d’un environnement déjà compromis, oblige à repenser chaque flux, chaque identité et chaque autorisation. La difficulté n’est pas de comprendre le principe, elle est de le tenir dans la durée face à la complexité croissante des systèmes d’information.
