Une politique DLP utile commence par un risque précis
Microsoft Purview Data Loss Prevention détecte des informations sensibles et peut surveiller, avertir ou restreindre leur partage dans les emplacements couverts. Une politique « protéger toutes les données partout » produit généralement trop de bruit. Commencez plutôt par une intention mesurable : empêcher l’envoi externe de dossiers clients à partir d’Exchange, SharePoint et OneDrive, par exemple.
DLP n’est ni une sauvegarde ni une politique de conservation. Les étiquettes décrivent et protègent le contenu, la rétention contrôle son cycle de vie, et la sauvegarde sert à restaurer après une perte. DLP intervient surtout au moment où des données correspondent à des conditions et sont utilisées ou partagées d’une façon définie.
Définir le scénario avant d’ouvrir l’assistant
Rédigez une phrase d’intention qui nomme les données, l’action risquée, les utilisateurs, les emplacements et le résultat souhaité. Pour un exemple fictif : « avertir les membres du groupe DLP-Pilot-Users lorsqu’ils partagent à l’externe au moins deux identifiants clients à confiance élevée; bloquer sans justification après validation du pilote ».
Les types d’informations sensibles utilisent des motifs, des éléments de corroboration, la proximité et un niveau de confiance. Un numéro qui ressemble à une carte de paiement dans un document de formation n’est pas nécessairement une fuite. Testez donc la combinaison du type, du nombre d’occurrences, de la confiance, du contexte et de la destination plutôt qu’un mot-clé isolé.
- Nommer un propriétaire métier capable de distinguer un vrai risque d’un processus légitime.
- Définir les emplacements visés et les exclusions avant la création de la règle.
- Écrire des critères de sortie : taux de correspondances valides, exceptions expliquées et aucun processus critique bloqué.
Portée, prérequis et licences : ne pas supposer une couverture universelle
Purview DLP peut couvrir notamment Exchange Online, SharePoint Online, OneDrive, les messages Teams et les appareils, mais les actions disponibles diffèrent selon l’emplacement. Une règle de courrier ne se comporte pas comme une restriction de copie USB. Endpoint DLP exige des appareils pris en charge et intégrés à Purview; les navigateurs, applications et formats de fichiers ont aussi leurs propres limites.
Les droits dépendent du produit, de l’emplacement et de la fonction utilisée. Les protections de base dans Microsoft 365 ne donnent pas automatiquement droit à Endpoint DLP, aux fonctions avancées ou à toutes les analyses. Consultez la description de service et l’outil de comparaison Microsoft pour les abonnements réellement attribués aux utilisateurs couverts; validez aussi les exigences d’intégration des appareils.
Utilisez le moindre privilège. Microsoft documente les groupes Compliance Administrator, Compliance Data Administrator, Information Protection et Security Administrator, ainsi que des rôles DLP plus granulaires. Séparez idéalement la création, l’approbation et l’enquête.
Inventorier l’existant en lecture seule
Avant d’ajouter une politique, recensez les règles, leur mode, leur priorité et leurs emplacements. Le script suivant lit la configuration dans Security & Compliance PowerShell; il ne modifie rien. Exécutez-le avec un rôle autorisé, dans une session administrative approuvée, puis retirez les identifiants et chemins sensibles avant de partager la sortie.
Complétez l’inventaire par les politiques de transport Exchange, les étiquettes de sensibilité, les contrôles de partage SharePoint et les exceptions existantes. Deux contrôles peuvent agir sur le même geste utilisateur; un test doit identifier lequel a produit le conseil ou le blocage.
# Read-only inventory. ExchangeOnlineManagement is required.
Connect-IPPSSession
Get-DlpCompliancePolicy |
Select-Object Name,Mode,Priority,Enabled,ExchangeLocation,
SharePointLocation,OneDriveLocation,TeamsLocation |
Sort-Object Priority
Get-DlpComplianceRule |
Select-Object Name,Policy,Disabled,Priority,BlockAccess,
NotifyUser,GenerateIncidentReportCréer une première politique en simulation
Dans le portail Microsoft Purview, ouvrez Solutions > Data Loss Prevention > Policies, puis créez une politique personnalisée ou partez d’un modèle pertinent. Limitez la portée à un petit groupe et à quelques sites de test. Ajoutez une règle pour le partage externe de données clients fictives, avec une condition à confiance élevée et un seuil réaliste.
Choisissez Run the policy in simulation mode. Ce mode exécute l’évaluation sans appliquer les restrictions et place les correspondances dans une expérience séparée. L’option d’afficher les conseils en simulation permet de tester le message utilisateur, mais elle change l’expérience : activez-la seulement après une première période silencieuse et une communication au pilote.
- Étape 1 — simulation silencieuse : mesurer les correspondances et les faux positifs.
- Étape 2 — simulation avec conseils : valider le texte, l’aide et la compréhension des utilisateurs.
- Étape 3 — petit anneau appliqué : permettre une justification lorsque le risque et le processus l’exigent.
- Étape 4 — élargissement : bloquer seulement les scénarios à haute confiance dont le retour arrière est testé.
Un exemple concret sans vraies données personnelles
L’entreprise fictive Contoso Nord veut réduire l’envoi externe de fiches clients. Elle commence avec Exchange, SharePoint et OneDrive, dix utilisateurs volontaires et deux sites de test. Les données de test sont synthétiques; aucune personne réelle ni donnée de production n’est utilisée.
La règle à faible confiance ne bloque rien et sert au réglage. La règle à haute confiance génère d’abord un conseil et une alerte. Après le pilote, elle peut empêcher le partage externe tout en autorisant une justification documentée pour un flux approuvé. Un scénario très risqué peut être bloqué sans possibilité de contournement, mais seulement après validation métier.
Test case: External sharing of fictional customer data
Policy: CA-DLP-Customer-Data-Pilot
Pilot: DLP-Pilot-Users and DLP-Pilot-Sites
Data: synthetic values only; never copy production records
Expected results
1. Internal sharing, no sensitive data -> no match
2. External sharing, one low-confidence hit -> record for tuning
3. External sharing, multiple high-confidence hits -> policy tip/alert
4. Approved business workflow -> justified override in pilot
5. Unauthorized external recipient -> block after enforcement approvalLire les résultats avant de toucher au bouton d’application
Dans Simulation results, Activity explorer et le tableau de bord des alertes DLP, examinez le fichier ou le message, le type détecté, la confiance, l’utilisateur, l’emplacement, la destination et l’action simulée. Une alerte n’est pas une preuve d’intention malveillante. Confirmez le contexte avec le propriétaire métier et limitez l’accès au contenu aux enquêteurs qui en ont besoin.
Mesurez la précision par scénario et par processus, pas seulement le nombre total d’événements. Suivez les correspondances valides, les faux positifs, les conseils ignorés, les justifications, les utilisateurs uniques et les flux critiques touchés. Une chute des alertes peut indiquer un meilleur réglage, mais aussi une politique devenue trop étroite.
| Signal | Question de validation | Réglage possible |
|---|---|---|
| Beaucoup de faux positifs | Le type, la confiance et la proximité correspondent-ils au document? | Augmenter la confiance, le nombre ou ajouter du contexte |
| Même flux légitime répété | La destination et le propriétaire sont-ils approuvés? | Exception minimale avec propriétaire et échéance |
| Aucune correspondance | La portée, le format et l’emplacement sont-ils réellement couverts? | Corriger le test avant de conclure que le risque est absent |
| Nombreuses justifications | Le conseil est-il clair ou la règle trop large? | Revoir l’intention et interroger le pilote |
Gérer les exceptions comme des dettes contrôlées
Une exception ne devrait jamais être « tout le service des finances pour toujours ». Donnez-lui une justification, un propriétaire, une portée technique minimale, une mesure compensatoire et une date de révision. Préférez une destination précise, un site ou un groupe restreint à une exclusion globale d’utilisateur.
Les conseils et contournements avec justification sont utiles quand l’utilisateur possède le contexte que la politique ne voit pas. Ils ne conviennent pas à tous les risques. Analysez les justifications répétées; elles peuvent révéler un flux à redessiner, un besoin de formation ou une règle mal calibrée.
Appliquer progressivement et préparer le retour arrière
Passer une politique de simulation à l’application est un changement de production. Exportez ou documentez la portée, le mode et les règles avant le changement. Activez un anneau à la fois, prévoyez un canal de soutien et tenez compte du délai de propagation. Testez de nouvelles actions plutôt que de vous fier à un événement déjà évalué.
En cas d’impact, remettez la politique ou la règle concernée en simulation, ou désactivez uniquement la nouvelle règle selon le plan approuvé. Ne supprimez pas toute la politique : conserver sa configuration et ses événements facilite l’analyse. Vérifiez ensuite que le flux est rétabli et que les autres politiques continuent de protéger les données.
- Critères d’arrêt : processus critique bloqué, hausse inexpliquée, conseil trompeur ou équipe incapable de traiter les alertes.
- Critères d’élargissement : tests représentatifs réussis, précision acceptable par scénario, exceptions approuvées et soutien prêt.
- Revue périodique : propriétaires, licences, emplacements, types sensibles, exceptions et changements d’applications.
Faire de DLP un contrôle exploitable, pas une collection de règles
Une DLP efficace relie classification, partage, identité, appareils, alertes et procédures d’enquête. Gardez un registre des intentions, propriétaires, résultats de simulation, exceptions et décisions d’application. Formez le centre de services à distinguer un conseil, un contournement et un blocage réel.
Commencez avec un petit nombre de risques à forte valeur, puis améliorez-les avec les preuves du pilote. Un audit Microsoft 365 peut cartographier les données, licences, chemins de partage et responsabilités avant un déploiement plus large; le guide ne remplace pas cette analyse de l’environnement.
À propos de l’auteur
Marc-Antoine Lambert
Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.
Discuter de votre environnement →