Purview DLP réseau : bloquer les fuites vers les IA non gérées via Entra Internet Access

Le problème que l'endpoint DLP ne peut pas résoudre

L'endpoint DLP de Microsoft Purview est redoutable sur les appareils gérés, dans les applications managées. Mais il existe un angle mort bien connu de tous les architectes sécurité : l'utilisateur qui ouvre une session de navigateur personnel, navigue vers ChatGPT, Claude ou n'importe quelle application GenAI non répertoriée, colle des données clients ou du code source, puis appuie sur Entrée. Aucune politique endpoint DLP ne voit ce flux. Aucun agent n'est présent pour inspecter le contenu avant qu'il ne parte.

Ce scénario — appelé la « unmanaged browser gap » — est précisément ce que la nouvelle intégration Microsoft Purview + Entra Internet Access (Global Secure Access) cible. La capacité est identifiée dans la roadmap Microsoft 365 sous le numéro 566528, avec un GA prévu en déploiement progressif fin septembre 2026. Vérifiez le statut courant sur Microsoft Learn avant tout déploiement en production.

Ce qui a changé : Purview descend au niveau réseau

Jusqu'ici, Microsoft Purview DLP opérait selon deux plans principaux :

• Endpoint DLP : inspection au niveau de l'appareil géré, dans les applications managées (Office, Edge en mode géré, etc.).
• Inline web DLP : inspection dans Microsoft Edge avec l'extension Purview, limitée aux sessions Edge managées.

Avec l'intégration Purview + Entra Internet Access, un troisième plan entre en jeu : le niveau réseau. Le trafic de l'utilisateur est routé à travers Global Secure Access (le client SSE de Microsoft). Purview évalue le contenu des requêtes HTTP — texte, prompts, payloads — avant qu'ils n'atteignent la destination. L'application de la politique (autoriser / bloquer / alerter) est appliquée inline, indépendamment du navigateur, de l'application ou de l'API utilisée.

Cela signifie que Chrome, Firefox, une application de bureau, un script Python appelant une API GenAI publique — tous passent par le même plan d'inspection si le client Global Secure Access est actif sur l'appareil.

Architecture du flux d'inspection

Voici comment les composants s'articulent en production :

1. Client Global Secure Access déployé sur l'endpoint (géré ou BYOD avec MDM).
2. Le trafic sortant vers les destinations Internet cibles est capturé par le profil de transfert de trafic (Internet Access traffic forwarding profile).
3. Purview DLP évalue le contenu de la requête contre les politiques configurées (types d'informations sensibles, expressions régulières personnalisées, classifieurs entraînables).
4. L'action configurée est appliquée inline : Allow, Block, ou Audit avec génération d'alerte.
5. Les événements à risque alimentent Insider Risk Management et remontent dans les incidents Microsoft Defender.

Ce que les politiques peuvent intercepter

Les types de contenus couverts par l'inspection réseau Purview incluent :

• PII : noms, numéros de sécurité sociale, adresses, dates de naissance.
• Données financières : numéros de cartes de crédit, IBAN, données bancaires.
• Types d'informations sensibles personnalisés (SIT custom) définis dans le portail Purview.
• Prompts GenAI contenant des données structurées ou non structurées classifiées.
• Contenu collé dans des formulaires web, des éditeurs en ligne, des champs de chat.

Les destinations cibles configurables comprennent les applications GenAI non gérées (ChatGPT public, services tiers), le stockage cloud grand public, la messagerie web, les réseaux sociaux et les formulaires en ligne.

Lien avec Insider Risk Management

Chaque événement d'inspection réseau DLP qui correspond à une politique génère un signal exploitable. Ces signaux sont ingérés par Microsoft Purview Insider Risk Management et corrélés avec d'autres indicateurs comportementaux (téléchargements massifs, accès inhabituels, exfiltrations endpoint).

Les incidents consolidés apparaissent dans deux consoles :

• Portail Microsoft Purview → Insider Risk Management → Alertes.
• Microsoft Defender → Incidents (via l'intégration XDR).

Cela permet aux équipes SOC de contextualiser une alerte réseau dans une séquence comportementale plus large, sans avoir à corréler manuellement les logs.

Coexistence avec l'endpoint DLP et les politiques web inline

L'un des défis d'architecture les plus fréquents lors du déploiement de cette nouvelle couche est d'éviter la double application des politiques et la confusion des utilisateurs. Voici le modèle de coexistence recommandé :

La règle d'or : scoper les politiques réseau exclusivement sur les destinations non couvertes par l'endpoint DLP. Ne pas créer de politiques identiques sur les deux plans — vous obtiendriez des doubles alertes et des expériences utilisateur contradictoires.

Configuration : profil de transfert de trafic et portée de la politique DLP

Prérequis techniques

• Licence Microsoft Entra ID P1 minimum pour Global Secure Access ; Microsoft Purview avec DLP activé.
• Client Global Secure Access déployé via Intune ou GPO sur les endpoints cibles.
• Rôle minimum pour la configuration : Global Secure Access Administrator + Compliance Administrator (principe du moindre privilège — ne pas utiliser Global Administrator pour les opérations courantes).
• Module PowerShell requis : Microsoft.Graph (v2.x recommandé) pour les opérations Graph API ; ExchangeOnlineManagement v3.x pour les cmdlets Purview DLP.

Vérification du client Global Secure Access

Avant de configurer les politiques DLP, confirmez que le client est actif et que le profil Internet Access est bien appliqué :

1# Vérification du statut du service Global Secure Access sur l'endpoint
2# Exécuter en tant qu'administrateur local sur le poste client
3Get-Service -Name "GlobalSecureAccess" | Select-Object Name, Status, StartType
4 
5# Vérifier le profil de trafic actif via l'interface de diagnostic GSA
6# Chemin portail : Entra admin center > Global Secure Access > Connect > Traffic forwarding
7# Valeur attendue : Status = Running, StartType = Automatic

Création d'une politique DLP réseau en mode audit (PowerShell)

1# Module requis : ExchangeOnlineManagement v3.x
2# Install-Module ExchangeOnlineManagement -RequiredVersion 3.4.0 -Scope CurrentUser
3 
4Connect-IPPSSession -UserPrincipalName admin@contoso.com
5 
6# Créer une politique DLP ciblant les interactions réseau (mode Audit)
7New-DlpCompliancePolicy `
8  -Name "Network-DLP-GenAI-Unmanaged-Audit" `
9  -Mode AuditAndNotify `
10  -Comment "Politique réseau Purview - inspection inline via Entra Internet Access - AUDIT ONLY" `
11  -Workload "InternetBrowsing"
12 
13# Créer la règle associée : bloquer les numéros de carte de crédit vers les apps GenAI non gérées
14New-DlpComplianceRule `
15  -Name "Block-CreditCard-GenAI-Network" `
16  -Policy "Network-DLP-GenAI-Unmanaged-Audit" `
17  -ContentContainsSensitiveInformation @{
18      Name = "Credit Card Number";
19      minCount = "1";
20      minConfidence = "85"
21  } `
22  -BlockAccess $false `
23  -GenerateAlert $true `
24  -AlertProperties @{AggregationType = "SimpleAggregation"} `
25  -NotifyUser "LastModifier"
26 
27# Vérifier la création de la politique
28Get-DlpCompliancePolicy -Identity "Network-DLP-GenAI-Unmanaged-Audit" | 
29  Select-Object Name, Mode, Workload, IsValid

Valeur de retour attendue : IsValid = True, Mode = AuditAndNotify, Workload = InternetBrowsing. Si IsValid = False, vérifiez que la capacité réseau DLP est bien activée sur votre tenant.

1# Passer en mode enforcement après validation de l'audit
2# ATTENTION : action irréversible sur les sessions utilisateurs en cours
3Set-DlpCompliancePolicy `
4  -Identity "Network-DLP-GenAI-Unmanaged-Audit" `
5  -Mode Enforce
6 
7# Confirmer le changement
8Get-DlpCompliancePolicy -Identity "Network-DLP-GenAI-Unmanaged-Audit" | 
9  Select-Object Name, Mode, LastModifiedTime

Plan de déploiement progressif recommandé

Checklist de déploiement production

Avant de passer en enforcement, validez chaque point :

• Client Global Secure Access déployé et actif sur tous les endpoints dans le scope.
• Profil Internet Access traffic forwarding activé et vérifié dans le portail Entra.
• Types d'informations sensibles (SIT) validés avec des données de test représentatives.
• Politique DLP réseau en mode audit depuis au moins 2 semaines, sans faux positifs critiques.
• Top 10 destinations GenAI non gérées identifiées et priorisées dans les règles.
• Frontières endpoint DLP vs network DLP documentées et non-chevauchantes.
• Intégration Insider Risk Management confirmée (signaux visibles dans les alertes IRM).
• Communication utilisateurs envoyée et validée par l'équipe juridique/RH.

Pièges courants et dépannage

Cinq erreurs à éviter absolument

1. Enforcer sans auditer : sans phase d'audit, vous bloquerez des flux légitimes et générerez une réaction négative des utilisateurs qui contourneront le système.
2. Ignorer le chevauchement endpoint/réseau : des politiques identiques sur les deux plans génèrent des doubles alertes et des expériences utilisateur contradictoires. Mappez clairement les périmètres.
3. Omettre la communication utilisateur : un blocage silencieux sans message explicatif crée de la méfiance et des tickets de support en masse.
4. Considérer ceci comme un remplacement CASB : l'inspection réseau Purview cible le contenu DLP. Elle ne remplace pas Microsoft Defender for Cloud Apps pour la gouvernance des applications SaaS, la détection de Shadow IT ou les politiques de session.
5. Oublier la limite des appareils non gérés : sans client GSA installé, un appareil personnel non onboardé reste hors périmètre. Ce n'est pas un défaut — c'est une contrainte d'architecture à documenter et compenser par d'autres contrôles (Conditional Access, MFA, blocage des appareils non conformes).

Erreurs PowerShell fréquentes

1# Erreur : « The workload 'InternetBrowsing' is not available on this tenant »
2# Cause : La capacité réseau DLP n'est pas encore disponible sur votre tenant (GA progressif).
3# Résolution : Vérifiez le statut sur le portail Microsoft 365 Roadmap (ID 566528).
4# Workaround temporaire : utilisez le portail Purview > DLP > Policies > Create policy
5# pour vérifier si l'option réseau apparaît dans les workloads disponibles.
6 
7# Erreur : « Connect-IPPSSession : AuthenticationError »
8# Cause : MFA requis ou token expiré.
9# Résolution :
10Connect-IPPSSession -UserPrincipalName admin@contoso.com -UseRPSSession $false

Références officielles Microsoft

Pour implémenter et maintenir cette configuration, les ressources suivantes sont indispensables :

• Microsoft Learn — Protéger les données sensibles en transit via Purview et Entra Internet Access
• Microsoft 365 Roadmap — ID 566528
• Microsoft Security Blog — Global Secure Access et DLP
• Documentation Global Secure Access — Traffic forwarding profiles
• Insider Risk Management — Indicateurs de politique