Le Zero Trust repose sur trois principes que la plupart des articles se contentent d’énumérer sans les confronter aux réalités d’implémentation : vérification explicite, moindre privilège et hypothèse de compromission. Nous proposons ici une lecture orientée architecture, en insistant sur les points que les guides grand public laissent de côté.
Hypothèse de compromission : le principe qui change la conception réseau
Commencer par l’hypothèse de compromission (assume breach) n’est pas un choix rhétorique. C’est le principe qui génère le plus de résistance dans les équipes infrastructure, parce qu’il remet en cause la notion même de zone de confiance interne.
Lire également : Quels sont les inconvénients du Bluetooth ?
Concevoir un réseau en partant du postulat qu’un attaquant est déjà présent oblige à segmenter chaque charge de travail. La microsegmentation ne consiste pas simplement à créer des VLAN supplémentaires. Elle impose des règles de filtrage appliquées au niveau applicatif, entre chaque service, y compris ceux qui communiquent sur le même sous-réseau.
Ce changement a un coût opérationnel direct : chaque flux inter-services doit être inventorié, autorisé explicitement, puis surveillé en continu. Les environnements legacy, où des centaines de flux est-ouest n’ont jamais été documentés, représentent le vrai goulet d’étranglement d’un projet Zero Trust.
Lire également : Quels sont les inconvénients de l'AI ?
Pourquoi la microsegmentation bloque souvent en production
Nous observons que la majorité des projets de microsegmentation ralentissent dès qu’ils atteignent les applications métier critiques. La raison est technique : ces applications utilisent des ports dynamiques ou des protocoles non standard que les outils de filtrage ne modélisent pas nativement.
Avant de déployer des politiques de segmentation, il faut cartographier les flux applicatifs réels sur plusieurs semaines. Sans cette phase d’observation, le risque de couper un flux légitime en production est réel, et c’est précisément ce risque qui pousse les équipes à repousser le déploiement.
Vérification explicite : au-delà de l’authentification multifacteur
La vérification explicite (verify explicitly) est souvent réduite à la mise en place d’une authentification multifactorielle. En réalité, chaque requête d’accès doit être évaluée en temps réel sur la base de signaux multiples : identité de l’utilisateur, posture du terminal, localisation, sensibilité de la ressource demandée et comportement récent.
Le modèle CISA Zero Trust Maturity Model v2.0, publié en avril 2023, structure cette vérification autour de cinq piliers : identité, appareils, réseaux, applications et charges de travail, données. À chaque pilier correspondent trois capacités transversales : visibilité et analytique, automatisation et orchestration, gouvernance.
Les comptes de service, angle mort de la vérification
Les comptes de service (service accounts) constituent un angle mort fréquent. Ces comptes techniques, souvent configurés avec des mots de passe qui n’expirent jamais, contournent de fait le principe de vérification explicite. Un compte de service sans expiration est une brèche permanente dans une architecture Zero Trust.
Nous recommandons de traiter les comptes de service avec la même rigueur que les comptes utilisateurs :
- Rotation automatisée des secrets, avec une fréquence alignée sur la criticité du service concerné
- Surveillance comportementale des appels API effectués par ces comptes, pour détecter toute déviation par rapport au profil d’usage normal
- Attribution d’un propriétaire métier identifié pour chaque compte de service, afin d’éviter les comptes orphelins
Moindre privilège et pilier données : ce que le CISA Maturity Model change
Le principe du moindre privilège (least privilege) est le plus ancien des trois, et aussi le plus mal appliqué. Accorder à un utilisateur uniquement les droits nécessaires à sa tâche semble évident. En pratique, les droits s’accumulent par héritage de rôles successifs sans jamais être révoqués.
Le modèle CISA v2.0 apporte un cadre plus exigeant en associant les décisions d’accès non seulement à l’identité de l’utilisateur, mais aussi à la sensibilité des données demandées. Cette approche dépasse le contrôle d’accès classique basé sur les rôles (RBAC) pour intégrer une classification dynamique des données.
Chiffrement et classification des données aux niveaux avancés
Aux niveaux de maturité avancés du modèle CISA, le chiffrement des données au repos et en transit devient une exigence systématique. La classification ne se fait plus manuellement par un responsable sécurité, mais de manière automatisée, en fonction du contenu et du contexte d’utilisation.
Cette évolution fait du pilier données le véritable centre de gravité du Zero Trust, là où les présentations traditionnelles se concentrent sur le réseau ou l’identité. Un accès peut être techniquement autorisé par le RBAC et pourtant refusé parce que la donnée demandée est classifiée à un niveau supérieur au besoin opérationnel de l’utilisateur.
Zero Trust et conformité réglementaire : NIS 2 comme accélérateur
La directive NIS 2 impose aux entités concernées des mesures de gestion des risques cyber qui recoupent largement les piliers du Zero Trust. La segmentation réseau, la gestion des accès privilégiés et la surveillance continue des flux figurent parmi les exigences techniques attendues.
Nous constatons que NIS 2 accélère l’adoption du Zero Trust dans les organisations qui n’auraient pas priorisé cette approche autrement. La conformité réglementaire fournit le levier budgétaire que les équipes sécurité n’obtenaient pas sur la base du seul argument technique.
- La gestion des identités et des accès (IAM) répond directement aux exigences NIS 2 sur le contrôle d’accès
- La microsegmentation couvre l’obligation de limiter la propagation latérale en cas d’incident
- La surveillance continue et l’analyse comportementale alimentent les capacités de détection et de réponse exigées par la directive
Le Zero Trust n’est plus un cadre théorique réservé aux grandes entreprises technologiques. Le modèle CISA v2.0 et les obligations NIS 2 en font une trajectoire de maturité mesurable, structurée par piliers et par niveaux. Le point de départ le plus productif reste la cartographie des flux existants et l’identification des comptes à privilèges non surveillés, deux chantiers concrets dont les résultats conditionnent tout le reste.
