Purview DLP wandert auf die Netzwerkebene
Inline-Inhaltsprüfung via Entra Internet Access – Architektur, Lizenzpflicht und Praxisfallen|
SECURITY & COMPLIANCE |
|---|
Purview DLP wandert auf die Netzwerkebene
Executive Summary
Microsoft hängt Purview DLP jetzt an Entra Internet Access. Im Klartext: Deine Klassifizierungsregeln – dieselben Sensitive Information Types, dieselben Sensitivity Labels, die du ohnehin schon für Exchange, SharePoint und Endpoint DLP pflegst – greifen ab sofort auch mitten im Netzwerkverkehr. Nicht auf dem Endgerät, nicht im Postfach, sondern in der Leitung. Wenn dein Controller die Debitorenliste in ein KI-Chatfenster kippt, sieht das nicht mehr erst der Wirtschaftsprüfer im nächsten Jahr, sondern der Service Edge in genau dem Moment, in dem das Paket rausgeht.
Der Charme liegt im Wegfall: kein zusätzlicher Agent auf den Endpunkten, keine neue Konsole, kein zweites Regelwerk. Der Preis steht im Kleingedruckten. Du brauchst den Global-Secure-Access-Client, TLS-Inspection auf breiter Front, Pay-as-you-go-Abrechnung in Purview und entweder Microsoft 365 E7 oder die Kombination aus Purview E5 und Entra Internet Access. Und du brauchst Geduld: Die allgemeine Verfügbarkeit rollt erst ab Ende September 2026 an und ist erst Ende Oktober durch. Bis dahin ist das ein Preview-Feature – und Preview-Features haben die charmante Eigenschaft, ihr Verhalten genau dann zu ändern, wenn du gerade den Betriebsrat überzeugt hast.
|
Fakten auf einen Blick Integration: Microsoft Purview Network Data Security mit Entra Global Secure Access (Internet Access). · Abdeckung: über 35.000 Anwendungen aus dem Defender-for-Cloud-Apps-Katalog. · Aktionen: Audit only oder Block, einzeln je Aktivität. · Protokolle: HTTP und HTTPS – QUIC auf UDP wird nicht inspiziert. · Public Preview seit November 2025, GA-Rollout ab Ende September 2026, Abschluss Ende Oktober 2026. |
|---|
Worum geht es im Detail?
Bisher hattest du zwei halbwegs brauchbare Orte, um Datenabfluss zu stoppen: das Endgerät über Endpoint DLP und die Microsoft-eigenen Dienste, also Exchange, SharePoint, OneDrive und Teams. Beides funktioniert gut – solange sich der Anwender an die Spielregeln hält und brav in Edge arbeitet. Tut er aber nicht. Er nutzt Firefox, weil der „schneller ist“. Er installiert sich einen KI-Desktop-Client, weil der „nicht so nervt“. Er schickt Daten über ein Office-Add-in raus, das nie jemand freigegeben hat. Endpoint DLP sieht davon je nach Konstellation wenig bis gar nichts.
Genau in diese Lücke zielt die neue Konstruktion. Der Global-Secure-Access-Client leitet den Internetverkehr des Geräts über den Microsoft Service Edge. Dort wird TLS aufgebrochen – anders geht es nicht, verschlüsselter Inhalt bleibt sonst schlicht verschlüsselter Inhalt. Eine Content Policy in Entra entscheidet, welcher Datenverkehr überhaupt interessant ist: welche Aktivität, welche Content-Typen, welches Ziel. Steht in der Regel die Aktion „Scan with Purview“, wandert der Inhalt zur Klassifizierung an Purview. Purview wertet die passende DLP-Richtlinie vom Typ „Inline web traffic“ aus und gibt das Verdikt zurück. Der Edge setzt es durch. Das alles passiert synchron, während der Anwender auf seinen Fortschrittsbalken starrt und sich wundert.

Der komplette Pfad – acht Stationen, und an jeder einzelnen kann dir die Konfiguration um die Ohren fliegen.
Wichtig ist die Arbeitsteilung, weil sie in Projekten regelmäßig missverstanden wird. Entra kann auch ohne Purview blocken: Die Basic Content Policy erkennt den MIME-Typ und sagt Ja oder Nein. Das ist allgemein verfügbar, braucht keine Purview-Lizenz und ist ungefähr so differenziert wie ein Vorschlaghammer – PDF blockieren, fertig, Feierabend. Erst „Scan with Purview“ macht daraus echte Inhaltsprüfung. Und nur damit bekommst du überhaupt Textprüfung, denn die Basic Content Policy inspiziert keinen einzigen Buchstaben Fließtext. Wenn dein Ziel lautet „Kein Kundendatensatz im Prompt“, führt kein Weg an der Purview-Variante vorbei – und die ist genau die, die noch in Preview steckt.
Auf der Purview-Seite konfigurierst du das erstaunlich vertraut. Neue Richtlinie, Kategorie „Inline web traffic“, dann die Cloud-Apps auswählen, entweder einzeln oder über Adaptive App Scopes wie „All unmanaged AI apps“. Als Enforcement-Ziel schaltest du „Network and non-Microsoft secure browsers“ ein. Diese Option ist ausgegraut, solange Pay-as-you-go nicht eingerichtet ist – das ist der Moment, in dem in jedem zweiten Workshop die Stimmung kippt, weil plötzlich der Einkauf mit am Tisch sitzt und jemand das Wort „Budget“ sagt. Anschließend die übliche Regelmechanik: Content contains, dazu Sensitive Info Types oder Sensitivity Labels, dann die Aktion „Restrict browser and network activities“ mit vier Aktivitäten – Text gesendet, Text empfangen, Datei hochgeladen, Datei heruntergeladen. Jede davon einzeln auf Audit oder Block.
|
Praxistipp aus dem Feld Der Klassiker beim ersten Test: Du trägst als Ziel brav chatgpt.com ein, lädst eine Test-PDF hoch – und nichts passiert. Der Grund ist, dass der Upload gar nicht über die sichtbare Domain läuft, sondern über Backend-Endpunkte wie /backend-api/files und *.oaiusercontent.com. Wer die nicht einträgt, testet erfolgreich gar nichts und meldet das dann als Erfolg. Also: Entwicklertools auf, Netzwerk-Tab mitlaufen lassen, echte Endpunkte notieren. Das gilt sinngemäß für jede Anwendung, die du absichern willst. |
|---|
Auch die Katalogpflege ist so ein Detail, das erst weh tut, wenn es weh tut. Im Cloud-App-Katalog existieren für dieselbe Anwendung gerne mehrere Einträge, etwa „QwenAI“ und „Qwen Chat“. Nimmst du nur einen davon, hast du eine Abdeckungslücke, die in keinem Report auftaucht – denn ein Report zeigt nur, was er sieht. Dazu kommt: Manche KI-Dienste schicken Inhalte zeitweise kodiert an dynamisch erzeugte Endpunkte, was die Durchsetzung unterlaufen kann. Und wenn eine Anwendung dieselbe URL für Consumer- und Enterprise-Variante nutzt, erwischt deine Regel eben beide – inklusive der Enterprise-Instanz, die du eigentlich ausdrücklich erlauben wolltest.

Endpoint DLP und Network DLP sind keine Alternativen, sondern zwei Netze mit unterschiedlicher Maschenweite – und beide haben Löcher.
Was sind Chancen? Was sind Risiken?
Die größte Chance ist banal und trotzdem entscheidend: Du bekommst endlich Zahlen. Nicht mehr „einige Mitarbeiter nutzen vermutlich ChatGPT“, sondern „340 Interaktionen letzte Woche, davon 47 mit Personendaten, davon 12 aus der Personalabteilung“. Der Activity Explorer lässt sich auf die Enforcement Plane „network“ filtern, DSPM for AI baut dir daraus eine Auswertung, und wenn du willst, erzeugt dir die Empfehlung „Extend insights into sensitive data in AI app interactions“ per Klick eine fertige Collection Policy. Erst messen, dann diskutieren – in dieser Reihenfolge gewinnst du Gespräche mit der Geschäftsführung, in der umgekehrten verlierst du sie.
Die zweite Chance ist die Abdeckungsbreite. Weil die Kontrolle im Netzwerk sitzt, ist ihr herzlich egal, welcher Browser, welche App oder welches Add-in da gerade sendet. Alles, was über den GSA-Client rausgeht, läuft durch dieselbe Prüfung. Das ist architektonisch der sauberste Punkt, den du überhaupt haben kannst – vorausgesetzt, du bekommst wirklich allen Verkehr dorthin.
|
Warbox: Der Satz, der jedes Projekt kippt „Wir machen TLS-Inspection einfach für alle, dann sind wir sicher.“ Nein. Du bröselst damit die Betriebsvereinbarung, den Datenschutzbeauftragten und vermutlich zwei Fachanwendungen, deren Hersteller Certificate Pinning macht und dir das nie gesagt hat. Microsoft legt nicht ohne Grund automatisch eine Bypass-Regel für Education, Finance, Government sowie Health und Medicine an. Wer die löscht, weil sie „Löcher“ sind, protokolliert am Ende die Online-Banking-Sitzung des Betriebsratsvorsitzenden mit. Viel Vergnügen bei dem Termin. |
|---|
Damit sind wir bei den Risiken, und die sind erwachsen. Erstens: TLS-Inspection ist ein Eingriff mit Ansage. Du brauchst eine eigene Zertifizierungsstelle, verteilst das Root-Zertifikat per Intune in den Trusted-Root-Store und musst das vorher kommuniziert und mitbestimmungsrechtlich sauber abgeklopft haben. Microsoft schreibt das sogar ausdrücklich in die Dokumentation – das kommt selten vor und passiert noch seltener grundlos.
Zweitens die Betriebsdetails, die harmlos klingen und es nicht sind. QUIC wird nicht unterstützt. Die offizielle Empfehlung lautet, ausgehendes UDP 443 per Firewall-Regel zu blocken, damit Browser auf TCP zurückfallen. Das ist eine einzige PowerShell-Zeile und trotzdem ein Change, den du an jedem Client durchziehen musst. Vergisst du ihn, läuft ein Teil deines Verkehrs fröhlich an der Inspektion vorbei, während dein Dashboard beruhigend grün leuchtet. Weiter geht es: Komprimierte Inhalte werden zwar als ZIP erkannt, aber nicht entpackt. Die Erkennung des echten Dateityps ist nicht hundertprozentig. Wildcards auf Top- und Second-Level-Domains funktionieren nicht. Und B2B-Gastnutzer sind von den Purview-Netzwerkrichtlinien schlicht ausgenommen – ausgerechnet die Gruppe, bei der externe Datenweitergabe strukturell am wahrscheinlichsten ist.
|
Achtung: Dein Reporting kann dich anlügen Ein leeres DLP-Dashboard bedeutet nicht „keine Vorfälle“. Es bedeutet zunächst nur „keine Treffer in dem Ausschnitt, den ich überhaupt sehe“. Fehlende Katalogeinträge, nicht erfasste Upload-Endpunkte, QUIC-Verkehr, Geräte ohne GSA-Client, Gastkonten – jedes dieser Löcher produziert exakt dasselbe beruhigende Bild wie echte Sauberkeit. Bau dir bewusst Testfälle, die einen Treffer erzeugen müssen, und prüfe monatlich, ob sie ihn immer noch erzeugen. |
|---|
Drittens die Kosten. Die Abrechnung läuft über Pay-as-you-go, und die Einheit ist der Request – also jeder Netzwerkaufruf von Gerät oder Browser in Richtung Website oder API. Antworten zählen nicht mit, Anfragen schon. Während der Public Preview fallen für die Durchsetzung über Entra Global Secure Access ausdrücklich keine zusätzlichen Gebühren an. Das ist eine ausgesprochen freundliche Formulierung für „später schon“. Wer jetzt eine Regel auf „alle Apps, alle Aktivitäten, alle Nutzer“ baut, weil es gerade nichts kostet, baut sich damit die Rechnung fürs vierte Quartal.
Und viertens der Punkt, den Vertriebsfolien gern weglassen: Was in Preview ist, ist nicht deshalb in Preview geblieben, weil alles so rund lief. Der GA-Termin ist bereits einmal nach hinten gewandert. Plane entsprechend – und schreibe keine Termine in ein Auditkonzept, die von einem Rollout-Zeitraum abhängen, den ein anderer Konzern kontrolliert.

Zwischen erster Ankündigung und belastbarer Verfügbarkeit liegen fast zwölf Monate – kalkuliere Projekte danach, nicht nach der Blog-Überschrift.
Was müssen wir jetzt schon vorbereiten?
Die gute Nachricht: Das meiste, was du jetzt tust, ist auch dann sinnvoll, wenn du dieses Feature am Ende nie produktiv schaltest. Die schlechte Nachricht: Es ist trotzdem Arbeit, und zwar in drei verschiedenen Teams gleichzeitig.
Lizenzlage klären. Entweder Microsoft 365 E7 pro Nutzer oder Purview E5 zusammen mit Entra Internet Access. Nicht raten, sondern nachzählen – und zwar bevor die Architektur steht.
Pay-as-you-go in Purview einrichten. Ohne das ist die Option „Network and non-Microsoft secure browsers“ gar nicht anwählbar. Das ist kein technischer, sondern ein kaufmännischer Schritt – also Vorlaufzeit einplanen.
Gerätebasis prüfen. Entra-joined oder Hybrid-joined ist Pflicht. Jedes Gerät, das das nicht ist, bleibt ein blinder Fleck.
Global Secure Access ausrollen und das Internet-Access-Forwarding-Profil aktivieren. Danach in den Advanced Diagnostics des Clients prüfen, ob die Regeln tatsächlich ankommen – das kann bis zu 15 Minuten dauern.
TLS-Inspection vorbereiten: Zertifizierungsstelle aufbauen, Root-Zertifikat per Intune verteilen, Bypass-Liste bewusst gestalten, Secure DNS deaktivieren, QUIC blocken.
Mitbestimmung und Datenschutz frühzeitig einbinden. Content Capture zeichnet auf Wunsch die komplette Konversation mit der KI-Anwendung auf. Das ist ein mächtiges Werkzeug und gleichzeitig eine juristische Handgranate.
Rollen klären: Global Secure Access Administrator, Conditional Access Administrator, dazu in Purview DLP Compliance Management oder Information Protection Admin. Drei Teams, ein Feature – das ist der eigentliche Projektaufwand, nicht die Klickstrecke.
Klassifizierung aufräumen. Network DLP nutzt deine vorhandenen Sensitive Info Types. Wenn die heute schon zu viele Falschtreffer produzieren, wird das im Netzwerk nicht besser – es wird nur sichtbarer, lauter und teurer.
|
Der Deployment-Pfad, der tatsächlich funktioniert Erst eine Collection Policy zum reinen Beobachten. Dann die DLP-Richtlinie im Simulationsmodus. Dann Block für eine einzige, klar abgegrenzte Gruppe – typischerweise Finanzwesen oder Personal – mit genau einer Handvoll Sensitive Info Types. Erst danach breiter ausrollen. Wer direkt mit „Block für alle“ startet, hat innerhalb von zwei Stunden das halbe Unternehmen am Service Desk und ist am nächsten Morgen wieder auf Audit only. Nur mit dem Unterschied, dass ihm ab dann niemand mehr zuhört. |
|---|
Ein letzter, unbequemer Gedanke zum Schluss: Diese Technik behandelt ein Symptom. Dass Leute Firmendaten in fremde KI-Dienste kippen, liegt selten an krimineller Energie und fast immer daran, dass das freigegebene Werkzeug schlechter ist als das verbotene. Wenn du Shadow AI blockst, ohne gleichzeitig eine brauchbare Alternative anzubieten, hast du nicht das Risiko beseitigt, sondern nur die Kreativität deiner Anwender herausgefordert. Und die ist beachtlich: privates Handy neben der Tastatur, Abtippen vom Screenshot, Weiterleitung an die private Adresse. Blocken ist die eine Hälfte, ein gutes internes Angebot die andere. Wer nur die erste macht, hat ein Compliance-Projekt. Wer beide macht, hat eine Lösung.
Häufig gestellte Fragen
Brauche ich für Purview Network DLP einen zusätzlichen Agenten auf den Clients?
Einen Purview-Agenten brauchst du nicht, wohl aber den Global-Secure-Access-Client. Der leitet den Internetverkehr des Geräts über den Microsoft Service Edge, und nur dort kann inspiziert werden – ohne diesen Client sieht die Lösung den Verkehr schlicht nicht.
Funktioniert das auch ohne TLS-Inspection?
Für echte Inhaltsprüfung nicht. Ohne Aufbrechen der Verschlüsselung bleibt nur die Basic Content Policy, die lediglich nach MIME-Typ erlaubt oder blockt und überhaupt keinen Text inspiziert.
Was kostet die Sache konkret?
Neben den Lizenzen – Microsoft 365 E7 oder Purview E5 zusammen mit Entra Internet Access – wird Network Data Security über Pay-as-you-go abgerechnet, und zwar pro Request, also pro Netzwerkaufruf in Richtung Website oder API. Während der Public Preview fallen für die Durchsetzung über Entra Global Secure Access keine zusätzlichen Gebühren an.
Ersetzt Network DLP mein bestehendes Endpoint DLP?
Nein, es ergänzt es. Endpoint DLP greift auch offline und bei lokalen Vorgängen wie dem Kopieren auf einen USB-Stick, Network DLP greift dafür browser- und anwendungsunabhängig im Datenverkehr – erst beide zusammen ergeben eine belastbare Abdeckung.
Ab wann kann ich das produktiv einsetzen?
Die Purview-Integration mit Entra Global Secure Access ist derzeit Preview; der GA-Rollout beginnt Ende September 2026 und soll Ende Oktober 2026 abgeschlossen sein. Bis dahin eignet sich das Feature gut für Pilotierung und Messung, aber nicht für Zusagen in einer Betriebsvereinbarung.
