Introduction : vers un contrôle granulaire du partage externe dans Microsoft 365
La gestion du partage externe dans Microsoft 365 a longtemps reposé sur des contrôles globaux au niveau du tenant ou du site SharePoint. Avec la montée en puissance des besoins de collaboration ciblée, cette approche monolithique atteint ses limites. Microsoft répond à cette problématique en introduisant deux nouvelles actions au sein des politiques Data Loss Prevention (DLP) de Microsoft Purview, référencées sous le message center MC1338823 et le Roadmap item #557191, sous l'intitulé Block external domain or user access for SharePoint and OneDrive.
Ces nouvelles actions, actuellement en preview, permettent d'agir au niveau de l'élément (fichier), offrant ainsi un contrôle bien plus fin que les paramètres de partage existants.
Disponibilité
Cette fonctionnalité est actuellement en preview et en cours de déploiement progressif. Elle est référencée sous le Roadmap item #557191 et le message center MC1338823. La disponibilité générale (GA) est attendue dans les prochaines semaines.
Périmètre d'application : politiques DLP SPO/ODFB uniquement
Avant d'aller plus loin, il est essentiel de comprendre le périmètre dans lequel ces nouvelles actions opèrent. L'action parente Restrict access or encrypt the content in Microsoft 365 locations n'expose les nouveaux contrôles que lorsque la politique DLP est scopée exclusivement sur SharePoint Online (SPO) et/ou OneDrive for Business (ODFB).
Cela signifie concrètement que :
- Les politiques DLP multi-services (Exchange + SPO, par exemple) n'afficheront pas ces nouvelles options.
- Vous devrez soit créer une nouvelle politique DLP dédiée à SPO/ODFB, soit modifier une politique existante limitée à ces workloads.
- Les utilisateurs internes ne peuvent pas être bloqués par ces actions — seuls les accès externes sont concernés.
Les deux nouvelles actions disponibles
Une fois la politique correctement scopée, deux nouvelles actions apparaissent lors de la configuration des règles :

Action 1 : Block access to external domains and users
Cette première action permet de restreindre le partage d'un fichier en ciblant des domaines externes spécifiques et/ou des adresses SMTP individuelles. Elle offre deux modes de fonctionnement :
- Mode liste de blocage (IS) : les domaines et utilisateurs listés se voient refuser l'accès.
- Mode liste d'autorisation (IS NOT) : tous les partages externes sont bloqués, à l'exception des domaines et utilisateurs listés.
Astuce de saisie
L'interface graphique n'indique pas clairement qu'il est possible de saisir plusieurs valeurs. Séparez simplement les entrées par des virgules : domain1.com, domain2.com, user@domain3.com. Notez cependant que le même opérateur (IS ou IS NOT) s'applique à l'ensemble de la liste, qu'il s'agisse de domaines ou d'adresses SMTP.

Action 2 : Block everyone and move file to the quarantine location
Cette seconde action adopte une approche plus radicale : elle révoque tous les accès au fichier concerné et le déplace vers un emplacement de quarantaine défini préalablement. Ce comportement est analogue à la fonctionnalité Admin Quarantine de Microsoft Defender for Cloud Apps.
La configuration de l'emplacement de quarantaine se fait depuis :
- Microsoft Purview portal > Settings > Data Loss Prevention settings > File quarantine
- Ou directement via le lien disponible dans la configuration de l'action.
Attention à l'accès au site de quarantaine
L'emplacement de quarantaine doit obligatoirement être un site SharePoint Online. Les sites OneDrive for Business ne sont pas acceptés. Restreignez rigoureusement les permissions de ce site aux seuls administrateurs et responsables qualifiés pour traiter les éléments en quarantaine.
Configuration pas à pas d'une politique DLP avec les nouvelles actions
Accéder au portail Microsoft Purview
Rendez-vous sur https://purview.microsoft.com et naviguez vers Solutions > Data Loss Prevention > Policies.
Créer ou modifier une politique scopée SPO/ODFB
Créez une nouvelle politique ou sélectionnez une politique existante. Dans la section Locations, assurez-vous de sélectionner uniquement SharePoint sites et/ou OneDrive accounts. Toute sélection d'un autre service masquera les nouvelles actions.
Configurer l'emplacement de quarantaine (si nécessaire)
Si vous comptez utiliser l'action de quarantaine, configurez préalablement l'emplacement via Settings > Data Loss Prevention settings > File quarantine. Sélectionnez un site SPO dédié et définissez le texte de remplacement du fichier mis en quarantaine.
Configurer les règles et sélectionner les nouvelles actions
Dans la configuration de vos règles, sous l'action Restrict access or encrypt the content in Microsoft 365 locations, sélectionnez l'une des deux nouvelles options :
- Block access to external domains and users : renseignez la liste des domaines/utilisateurs et choisissez l'opérateur IS ou IS NOT.
- Block everyone and move file to the quarantine location : l'emplacement de quarantaine préconfiguré sera automatiquement sélectionné.
Valider et déployer la politique
Finalisez la configuration (notifications, mode simulation ou enforcement) et publiez la politique. Prévoyez un délai de synchronisation pouvant aller jusqu'à plusieurs heures, voire quelques jours, avant que les règles ne soient pleinement opérationnelles sur l'ensemble des contenus.
Inspection des règles via PowerShell
Bien que la création de règles avec ces nouvelles actions ne soit pas encore disponible via PowerShell (les paramètres correspondants ne sont pas exposés par New-DlpComplianceRule), il est possible d'inspecter les propriétés d'une règle existante avec la commande suivante :
1Get-DlpComplianceRule -Policy "SPO" | Select-Object Quarantine, BlockDomainsOrUsers, BlockDomains, BlockDomainsExcept, BlockUsers, BlockUsersExcept, RestrictAccess, SPMoveToQuarantineLocation, AdvancedRuleExemple de résultat :
1Quarantine : False2BlockDomainsOrUsers : True3BlockDomains : {}4BlockDomainsExcept : {contoso.com}5BlockUsers : {}6BlockUsersExcept : {john.doe@contoso.com}7RestrictAccess :8SPMoveToQuarantineLocation : False9AdvancedRule : {10 "Version": "1.0",11 "Condition": {12 "Operator": "And",13 "SubConditions": [14 {15 "ConditionName": "ContentExtensionMatchesWords",16 "Value": [17 "docx",18 "xlsx",19 "pptx",20 "pdf"21 ]22 }23 ]24 }25 }Dans cet exemple, la règle se déclenche lorsqu'un fichier .docx, .xlsx, .pptx ou .pdf est partagé avec n'importe quel domaine ou utilisateur externe, à l'exception de contoso.com et de l'utilisateur john.doe@contoso.com.
Bon à savoir
À date, le cmdlet New-DlpComplianceRule ne prend pas encore en charge les paramètres BlockDomainsOrUsers, BlockDomains, BlockUsers ou SPMoveToQuarantineLocation. La création de règles utilisant ces actions doit donc s'effectuer exclusivement via l'interface graphique du portail Purview. Cette limitation devrait être levée lors de la disponibilité générale de la fonctionnalité.
Comportement côté utilisateur final
Action de blocage par domaine/utilisateur
Lorsqu'un utilisateur tente de partager un fichier avec un destinataire correspondant à la condition de blocage, les entrées concernées sont simplement supprimées de la liste de partage sans notification claire. Si le destinataire fait partie des entités autorisées, le partage s'effectue normalement.
Action de quarantaine
Lorsque la règle de quarantaine se déclenche :
- Tous les accès au fichier sont révoqués.
- Le fichier est copié vers l'emplacement de quarantaine, dans une arborescence reflétant le chemin d'origine (ex :
user_domaine_com > Documents). - Le fichier original est remplacé par un fichier
.txtdont le contenu correspond au message configuré dans les paramètres de quarantaine.


Comportement en preview
Durant la phase de preview, certains comportements peuvent ne pas être entièrement cohérents. Des tests ont montré que le fichier original pouvait rester en place (avec ses permissions de partage intactes) malgré la création correcte de la copie en quarantaine. Ce comportement devrait être normalisé à la GA.
Absence de policy tips et d'overrides
Il n'est actuellement pas possible de configurer des policy tips (notifications dans l'interface utilisateur) ni des overrides (possibilité pour l'utilisateur de justifier et contourner la règle) pour ces deux nouvelles actions. Cette limitation peut générer de la confusion côté utilisateurs, en particulier avec l'action de quarantaine qui peut donner l'impression que des fichiers ont «disparu».
Gestion des alertes et rapports d'incidents
La surveillance des déclenchements de politique s'appuie sur les mêmes mécanismes que les politiques DLP existantes : alertes dans le portail Purview et rapports d'incidents par email. L'expérience administrateur reste donc cohérente avec les workflows existants.


Comparaison avec les contrôles de partage existants
| Mécanisme | Portée | Granularité | Quarantaine | Notifications utilisateur |
|---|---|---|---|---|
| Contrôles de partage tenant/site SPO | Tenant ou site entier | Faible (global) | Non | Non |
| Sensitivity Labels avec chiffrement | Par document | Élevée (par utilisateur/domaine) | Non | Partielle |
| DLP - Block access (nouveau) | Par fichier correspondant à la règle | Élevée (domaine/utilisateur) | Non | Non (pas de policy tips) |
| DLP - Quarantine (nouveau) | Par fichier correspondant à la règle | Élevée | Oui | Non (pas de policy tips) |
Points d'attention et bonnes pratiques
Interaction avec les sensitivity labels
Les fichiers protégés par des sensitivity labels avec chiffrement conservent leur propre logique de permissions. Même si une règle DLP autorise un domaine via la condition IS NOT, les permissions de la label doivent explicitement inclure le domaine ou l'adresse du destinataire pour que le contenu soit accessible.
Indépendance des contrôles
Les nouvelles actions DLP fonctionnent indépendamment des paramètres de partage externe au niveau du tenant et des sites SPO. Elles constituent une couche de contrôle supplémentaire, permettant de sécuriser des fichiers spécifiques tout en maintenant une collaboration ouverte avec certains partenaires.
Recommandations opérationnelles
- Sensibilisez vos utilisateurs avant tout déploiement en mode enforcement, particulièrement pour les règles de quarantaine.
- Testez en mode simulation (Audit only) avant d'activer les actions de blocage ou de quarantaine.
- Restreignez l'accès au site de quarantaine à un groupe restreint d'administrateurs et de responsables de la conformité.
- Documentez le processus de récupération pour les utilisateurs dont les fichiers seraient mis en quarantaine.
- Patientez après la création ou modification d'une politique avant de valider son comportement — la synchronisation peut nécessiter plusieurs heures.
Important : fonctionnalité en preview
Cette fonctionnalité est encore en preview. Des comportements inattendus peuvent se produire, notamment la non-substitution du fichier original par le .txt dans certains tenants. Il est fortement déconseillé de l'utiliser en production sans une phase de test approfondie et une communication préalable auprès des utilisateurs finaux.
Références officielles
- Documentation Microsoft Purview DLP
- Configurer les politiques DLP pour SharePoint et OneDrive
- Admin quarantine dans Microsoft Defender for Cloud Apps
- Cmdlet Get-DlpComplianceRule
- Contrôles de partage externe SharePoint Online
- Roadmap Microsoft 365 #557191
Conclusion
L'introduction de ces deux nouvelles actions DLP pour SharePoint Online et OneDrive for Business représente une avancée significative dans la gestion granulaire du partage externe au sein de Microsoft 365. La possibilité de bloquer ou mettre en quarantaine des fichiers spécifiques sur la base de critères de domaine ou d'utilisateur comble un manque réel par rapport aux contrôles globaux existants.
Néanmoins, l'absence de support pour les policy tips et les overrides, combinée aux quelques incohérences observées en preview, invite à une adoption progressive et maîtrisée. Surveillez les annonces de disponibilité générale et les évolutions de la documentation officielle pour intégrer ces contrôles dans votre stratégie de protection de l'information.



