Microsoft Purview^™ DLP : comment valider vos stratégies avec des preuves

Dans les consoles Purview, une scène revient souvent : des stratégies DLP restées en mode simulation depuis des mois, des règles endpoint réglées en audit seul, et une équipe persuadée que tout bloque. Personne n’a menti. Votre console affiche correspondances, alertes et graphiques, sans vous dire ce qui serait sorti.

Valider une stratégie Microsoft Purview DLP dans Microsoft 365, c’est vérifier, scénario par scénario, qu’elle détecte et bloque une sortie de données sur chaque emplacement où elle est déployée : Exchange, SharePoint, OneDrive, Teams et postes de travail. Le mode simulation indique ce qu’une règle aurait déclenché, sans démontrer qu’elle arrête une exfiltration. Pour cela, il faut un test actif, rejoué avec des données synthétiques, dont vous tracez le résultat.

Ce que le mode simulation de Purview vous dit, et ce qu’il tait

Purview vous laisse lancer une stratégie en simulation avant de l’activer. Bonne pratique : vous mesurez le volume de correspondances, vous repérez les règles trop bavardes, vous évitez de bloquer la paie un lundi matin. La portée reste quand même limitée.

• La simulation travaille sur l’activité qui existe. Si personne n’a envoyé de fichier sensible vers l’extérieur pendant la période, la stratégie n’a rien eu à juger. 0 correspondance ne veut pas dire 0 fuite possible.
• Elle valide la détection. L’action, elle, reste à prouver. Une fois activée, une règle peut se comporter autrement : exception utilisateur, blocage contournable sur simple justification, conflit de priorité.
• Elle ignore les chemins absents de votre stratégie. Un navigateur non géré ou un poste non intégré n’apparaîtra jamais dans vos résultats.

La simulation répond donc à « ma règle est-elle bien calibrée sur le trafic courant ? ». Elle ne répond pas à « un utilisateur ou un attaquant peut-il sortir ce fichier ? ». C’est le piège décrit dans notre article sur les faux négatifs DLP : une règle silencieuse ressemble à une règle efficace. Pour la seconde question, il vous faut un test d’exfiltration de données, calé sur la tactique TA0010 de MITRE ATT&CK.

Les angles morts spécifiques à M365

Endpoint DLP : la couverture dépend de l’intégration des postes

La DLP endpoint de Purview ne protège que les appareils intégrés (Windows 10, Windows 11 et les 3 dernières versions majeures de macOS) qui remontent correctement leur état. Sur un parc hétérogène, les trous arrivent vite : postes réinstallés, machines hors domaine, systèmes non pris en charge, agents en échec. Vérifiez 3 choses avant de parler d’efficacité :

1. La liste des appareils intégrés colle à votre inventaire réel, au-delà de celui d’Intune.
2. Les activités surveillées (copie sur clé USB, impression, téléversement vers un service cloud, presse-papiers, partage réseau, application Bluetooth non autorisée) sont réglées en blocage là où vous le pensez, et non en audit seul.
3. Les navigateurs restreints sont listés de façon cohérente. La DLP s’applique nativement dans Edge, alors que Chrome et Firefox ont besoin de l’extension Microsoft Purview.

Teams : messages, fichiers et invités

Dans Teams, votre DLP agit sur les messages de conversation et de canal, alors que les fichiers partagés vivent dans SharePoint (canaux) et OneDrive (conversations). Votre stratégie peut donc bloquer un numéro de carte collé dans un message et laisser passer le même contenu dans un document joint. Testez à part vos conversations avec des invités ou des utilisateurs fédérés : c’est là que la donnée quitte l’organisation.

Types d’informations sensibles et classifieurs

Les types d’informations sensibles de Microsoft 365 reposent sur des motifs, des mots clés de proximité et 3 niveaux de confiance (65 pour faible, 75 pour moyen, 85 pour élevé). Un IBAN, un numéro de sécurité sociale français (INSEE) ou une référence interne ne seront détectés que si le type colle à votre format et si le seuil est adapté. Une étiquette « Confidentiel » qui n’est pas une condition de la règle ne protège rien non plus. Ici, la qualité de votre DLP dépend directement de la classification des données.

Une matrice de validation par emplacement

Plutôt qu’un test global, construisez une matrice : 5 lignes pour les emplacements, 4 colonnes pour les questions auxquelles vous devez répondre, preuve à l’appui. Si vous comparez des outils pour l’automatiser, nos critères pour choisir un outil de test DLP vous aideront.

Faites défiler le tableau →

Scénario concret : le fichier RH qui ne devait pas sortir

Un scénario type, dans un cabinet de conseil qui a activé en avril une stratégie « Données RH ». En octobre, le tableau de bord affiche quelques dizaines de correspondances par mois, toutes sur Exchange Online. L’équipe en conclut que la règle fonctionne.

L’équipe rejoue alors 4 tentatives avec un fichier synthétique qui imite un export de paie : envoi par Outlook, partage OneDrive, message Teams, copie sur clé USB. Le courriel est bloqué. Le partage OneDrive passe, parce que la règle cible un site SharePoint précis et pas les espaces personnels. Le message Teams est bloqué. La copie USB passe sur une partie des postes, ceux qui n’ont jamais été intégrés. Bilan : 2 tentatives sur 4 passent. C’est ce que la simulation ne pouvait pas montrer. Dans ATT&CK, ces 2 fuites relèvent de T1567.002 (stockage cloud) et de T1052.001 (support USB).

Le verdict n’est pas « la DLP ne marche pas ». Il tient en 2 corrections, l’une de périmètre, l’autre d’intégration des postes. Ce niveau de précision vous permet ensuite de hiérarchiser la remédiation.

Constituer des preuves exploitables

Votre auditeur ISO 27001, votre DPO face à l’article 32 du RGPD ou votre comité de direction ne se contentera pas d’une capture d’écran. Votre preuve exploitable réunit :

• la stratégie et la règle concernées, avec leur version et leur mode (simulation ou activée) à la date du test ;
• le scénario rejoué, décrit côté défenseur : emplacement, type de donnée synthétique, action tentée ;
• le résultat observé (bloqué, audité, passé) et l’événement correspondant dans Purview, exporté, car l’explorateur d’activités ne couvre que 30 jours de données ;
• le délai de remontée de l’alerte vers le portail Microsoft Defender, le SOC ou le SIEM ;
• la date du prochain rejeu.

Checklist avant de déclarer une stratégie validée

• Chaque emplacement de votre stratégie a été testé au moins une fois en mode activé.
• Les exceptions et les substitutions ont été testées comme des chemins à part.
• Les échanges Teams avec des invités ont été testés.
• Vos tests utilisent exclusivement des données synthétiques, jamais de données réelles.
• Vos écarts sont consignés avec une action corrective et un responsable.
• Un rejeu est planifié après chaque changement de configuration.

FAQ