Zero Trust & gouvernance des données M365 : guide RSSI

Zero Trust est aujourd'hui le cadre de référence de la cybersécurité d'entreprise. Ses trois principes, vérification explicite, moindre privilège, présomption de compromission — sont bien intégrés par les équipes sécurité pour les identités : MFA, accès conditionnel Entra, gestion des comptes à privilèges. Là où l'exécution reste défaillante, c'est sur la couche données.

Selon Gartner (janvier 2023), seulement 10% des grandes entreprises disposeront d'un programme Zero Trust mature en 2026, et plus de la moitié des cyberattaques cibleront des zones non couvertes par les contrôles Zero Trust. Dans la plupart des tenants M365, des partages SharePoint ouverts, des liens anonymes actifs et des groupes Teams publics coexistent avec une authentification forte et un Entra ID parfaitement configuré. Zero Trust des identités est en place. Zero Trust des données ne l'est pas. Ce guide détaille comment traduire les trois principes Zero Trust en actions concrètes sur la gouvernance des données M365.

Zero Trust des données : un principe distinct du Zero Trust des identités

Selon Microsoft (Learn, 2026), Zero Trust s'appuie sur trois principes fondamentaux pour la protection des données.

La vérification explicite exige d'authentifier et d'autoriser en fonction de tous les points de données disponibles, y compris la classification des données, l'identité de l'utilisateur et les anomalies comportementales. Le moindre privilège impose de limiter l'accès avec des approches just-in-time et just-enough-access, en protégeant à la fois les données et la productivité. La présomption de compromission requiert de réduire le rayon d'exposition, de vérifier le chiffrement de bout en bout et d'utiliser l'analytique pour détecter les menaces.

Ces trois principes s'appliquent distinctement aux identités et aux données. Un tenant peut respecter le principe de vérification explicite pour les connexions (MFA, accès conditionnel) tout en échouant sur la vérification explicite des accès aux données, si personne ne contrôle si un partage SharePoint créé il y a deux ans est encore justifié.

Microsoft identifie cinq composants pour une stratégie Zero Trust sur les données via Purview : classification et étiquetage, protection de l'information, prévention des fuites, gestion des risques internes, et gouvernance du cycle de vie des données sensibles (Microsoft Learn, 2026). Ce dernier point, gouvernance du cycle de vie, est précisément celui qui est le plus souvent absent dans les organisations M365.

Zero Trust des données ne se résume pas à chiffrer les fichiers sensibles : il exige de savoir qui accède à quoi, de réduire ces accès au strict nécessaire, et de vérifier périodiquement que chaque accès reste justifié par une nécessité métier documentée.

Le problème central : la dette de permissions dans M365

Dans un tenant M365 qui n'a pas mis en oeuvre une gouvernance des accès rigoureuse, les permissions s'accumulent mécaniquement au fil du temps. Un partage créé pour un projet se termine rarement par une révocation des accès. Un groupe Teams ouvert "par défaut" reste ouvert des années. Un lien anonyme partagé pour un partenaire externe reste actif après la fin du contrat.

Selon le rapport Microsoft State of Cloud Permissions Risks (2023), moins de 2% des permissions accordées aux super identités cloud sont effectivement utilisées. Les 98% restants constituent une surface d'exposition dormante, et les permissions dormantes sont précisément celles que Copilot et les agents IA amplifient mécaniquement, en accédant à tout ce à quoi l'utilisateur a droit, y compris des accès oubliés depuis des années.

Cette dette n'est pas un problème technique, c'est un problème de gouvernance. Les équipes IT peuvent identifier les partages à risque via SharePoint Advanced Management ou Microsoft Purview DSPM. Elles ne peuvent pas décider seules si un partage est encore nécessaire. Cette décision appartient au propriétaire fonctionnel des données. C'est exactement pourquoi le principe de vérification explicite Zero Trust, appliqué aux données, exige une boucle de décision humaine, pas seulement une politique technique.

Dans un environnement M365 non gouverné, l'écart entre ce que Zero Trust exige sur la couche données et ce qui est réellement en place représente la première surface d'exposition non couverte par les contrôles Zero Trust identité.

Etape 1 : Moindre privilège : cartographier et réduire les accès

L'application du moindre privilège aux données M365 commence par une cartographie complète des permissions actives. Selon Microsoft (Learn, 2026), il est impossible de protéger des données sensibles de manière adéquate sans les avoir d'abord inventoriées et classifiées.

Quatre catégories d'accès concentrent l'essentiel de la surface d'exposition dans un tenant M365.

Les partages anonymes et accès externes actifs sur SharePoint et OneDrive permettent à tout utilisateur externe d'accéder aux fichiers sans authentification, en contradiction directe avec le principe de vérification explicite Zero Trust.

Les groupes Microsoft 365 et Teams ouverts à "Toute l'organisation" donnent à chaque collaborateur un accès en lecture aux contenus publiés, quelle que soit leur sensibilité.

Les accès externes non recertifiés concernent les utilisateurs invités qui conservent des droits après la fin d'une collaboration. Leur maintien ne peut pas être justifié sans vérification fonctionnelle.

Les héritages de droits sur les sous-arborescences SharePoint créent des situations où des utilisateurs conservent des accès sur des espaces sensibles après avoir quitté un projet ou une équipe.

Les outils natifs disponibles pour cette cartographie sont les rapports de gouvernance d'accès aux données SharePoint (SAM) et Purview DSPM (E5) pour l'inventaire des données sensibles. Sur un tenant non audité, ces quatre catégories représentent la majorité des violations du moindre privilège que Zero Trust exige de corriger.

Etape 2 : Vérification explicite : recertifier les accès avec les propriétaires fonctionnels

Zero Trust exige une vérification explicite de chaque accès. Pour les données M365, cette vérification ne peut pas être entièrement automatisée — elle nécessite que la personne responsable fonctionnellement des données valide si un accès est encore justifié.

C'est le principe de la revue des droits d'accès : chaque accès maintenu doit l'être sur décision documentée du propriétaire, pas par défaut d'inaction. Cette approche produit aussi les preuves de conformité que NIS2 et les audits requièrent — un journal de décisions fonctionnelles daté et tracé.

La limite des approches purement IT est précisément là : un administrateur M365 peut identifier un site SharePoint surexposé via SAM ou Purview, mais il ne peut pas décider si le partage avec l'équipe de développement externe d'il y a dix-huit mois est encore nécessaire. Seul le propriétaire fonctionnel peut le faire.

Selon les données IDECSI (2024), constatées sur plus d'un million d'utilisateurs accompagnés, une campagne de recertification impliquant les propriétaires fonctionnels produit en moyenne 7 corrections de permissions par utilisateur en 4 à 6 semaines. La Communauté d'Agglomération de Cergy-Pontoise a supprimé 50% de ses risques dès la première campagne DETOX, 70% à l'issue de la deuxième, sans mobiliser de ressources IT supplémentaires.

Dans une approche Zero Trust des données, la recertification périodique des accès par les propriétaires fonctionnels est l'équivalent de la réévaluation continue du niveau de risque que l'accès conditionnel Entra applique aux identités, c'est la boucle de vérification explicite appliquée à la couche données.

Etape 3 : Présomption de compromission : surveiller les accès aux données sensibles

Le troisième principe Zero Trust, présupposer qu'une compromission peut survenir à tout moment, exige une surveillance continue des accès aux données sensibles, pas uniquement une réponse aux incidents.

Sur M365, trois niveaux de surveillance correspondent à ce principe. L'alerting temps réel sur les accès à des données sensibles ou critiques, répertoires RH, données financières, propriété intellectuelle, permet de détecter des comportements anormaux avant qu'ils ne deviennent des incidents. Defender for Cloud Apps couvre ce périmètre pour les comportements utilisateurs.

La surveillance des interactions Copilot et des agents IA est couverte par Purview DSPM for AI (GA fin mai 2026) : il journalise les prompts et réponses, détecte les accès non justifiés aux données sensibles et alerte sur les comportements agentiques à risque.

La détection des accès obsolètes réactivés, un utilisateur qui accède soudainement à un site SharePoint qu'il n'avait pas consulté depuis deux ans — est un signal de compromission potentielle que seul un historique des accès permet de détecter.

La présomption de compromission appliquée aux données M365 signifie que la surveillance ne s'arrête pas au périmètre des identités authentifiées : elle couvre ce que ces identités font de leurs accès — et cette surveillance doit être continue, pas périodique.

Tableau de synthèse : Principes Zero Trust appliqués aux données M365

Conclusion

Zero Trust des données dans Microsoft 365 n'est pas une extension du Zero Trust des identités, c'est une couche distincte, avec ses propres exigences et ses propres outils. Elle exige trois choses que les politiques techniques seules ne peuvent pas produire : la cartographie des accès existants, la vérification fonctionnelle périodique par les propriétaires des données, et la surveillance continue des comportements d'accès.

Les organisations qui ont déployé MFA et Entra ID ont couvert le Zero Trust des identités. Celles qui n'ont pas encore conduit de campagne de remédiation et de recertification de leurs données M365 ont un écart Zero Trust sur la couche la plus exposée de leur tenant, et c'est précisément la couche que Copilot et les agents IA amplifient.

Pour établir l'état Zero Trust de vos données M365 et identifier les actions prioritaires, un diagnostic DETOX permet de cartographier les permissions actives et de dimensionner le plan de recertification adapté.