Consulting Briefing

03.08.2026 · boddenberg.de

Purview DLP wird ab September GA mit Entra Internet Access

Microsoft zieht die Datenklassifizierung in den Netzwerkpfad. Ab Ende September 2026 wird ernst, was seit November 2025 in der Preview vor sich hin brodelt – und zwar genau in dem Moment, in dem deine Leute ihre halbe Vertragsakte in fremde KI-Chatfenster kippen. Was du dafür bezahlst, aufbaust und juristisch absichern musst, steht hier.

Executive Summary

Kurz und schmerzhaft: Microsoft Purview kann ab Ende September 2026 in der allgemeinen Verfügbarkeit sensible Inhalte direkt im Netzwerkverkehr klassifizieren und blocken. Der Mechanismus dahinter ist Microsoft Entra Internet Access, also der Internet-Zweig von Global Secure Access. Der bricht TLS auf, reicht Datei- und Textinhalte zur Bewertung an Purview weiter, bekommt ein Verdikt zurück und setzt es durch. Das Message Center nennt als Rollout-Fenster Ende September bis Ende Oktober 2026. Wer aufmerksam mitliest, merkt: Das ist bereits die zweite Terminansage. Ursprünglich sollte die Funktion Mitte Juni 2026 generell verfügbar sein.

Die Zielrichtung ist unmissverständlich. Es geht um Schatten-KI und um unverwaltete Cloud-Dienste. Purview greift auf den Cloud-App-Katalog von Defender for Cloud Apps mit über 35.000 Anwendungen zu, dazu kommen adaptive App-Bereiche wie „All unmanaged AI apps“. Damit erwischst du ChatGPT, Gemini, Claude, Gmail, Dropbox, Box, Google Drive, Google Forms, Facebook und X – und zwar nicht nur aus dem Browser, sondern aus allem, was durch den GSA-Tunnel geht. Genau das ist der Unterschied zum klassischen Endpoint-DLP, das an der nativen Desktop-Anwendung und am API-Aufruf gerne mal vorbeischaut.

Bezahlt wird doppelt: einmal über die Lizenz, einmal über den Verbrauch. Du brauchst entweder Microsoft 365 E7 – den seit Mai 2026 verfügbaren Bundle-Bolzen mit vollständiger Entra Suite – oder die Kombination aus Purview E5 und einer Entra-Internet-Access-Lizenz. Zusätzlich musst du im Tenant zwingend das Pay-as-you-go-Abrechnungsmodell aktivieren, bevor du überhaupt eine Netzwerkrichtlinie anlegen darfst. Abgerechnet wird pro Request, aktuell mit 0,50 US-Dollar je 10.000 Netzwerkaufrufe. Während der Public Preview stellt Microsoft die über Global Secure Access durchgesetzten Richtlinien noch nicht in Rechnung. Ab GA ist die Gnadenfrist vorbei.

Der Datenpfad: Endpunkt, Edge, Purview, Ziel – und die drei Konsolen, in denen der Vorfall danach landet.

Worum geht es im Detail?

Fangen wir mit dem Problem an, das die Sache überhaupt erst nötig macht. Endpoint-DLP ist gut, aber es sieht die Welt durch ein Schlüsselloch. Es kennt den verwalteten Endpunkt, es kennt Edge und mit Erweiterung auch Chrome. Was es nicht zuverlässig kennt, ist der Mitarbeiter, der den nativen Desktop-Client eines KI-Anbieters installiert hat, dort einen Vertragsentwurf einwirft und sich freut, wie gut die Zusammenfassung geworden ist. Der Verkehr geht über HTTPS an eine API, nicht durch ein Upload-Feld im Browser. Auf dem Endpunkt ist das ein ganz normaler Prozess, der ins Internet spricht.

Netzwerk-Layer-DLP dreht die Perspektive um. Statt am Prozess zu hängen, hängst du am Datenpfad. Alles, was über das Internet-Access-Traffic-Profil läuft, kommt an einem Service-Edge vorbei, der aufbricht, hineinschaut und entscheidet. Das ist konzeptionell nichts Neues – jedes Secure Web Gateway macht das seit fünfzehn Jahren. Neu ist, dass die Entscheidung nicht mehr von einer eigenen, separat gepflegten Regex-Sammlung im Proxy getroffen wird, sondern von genau denselben Sensitive Information Types, Sensitivity Labels und trainierbaren Klassifizierern, die auch in Exchange, SharePoint und auf dem Endpunkt greifen. Ein Regelwerk statt fünf. Das ist der eigentliche Wert.

Technisch besteht die Sache aus zwei Hälften, die getrennt konfiguriert werden und beide korrekt sein müssen, sonst passiert exakt gar nichts.

Auf der Entra-Seite: Internet-Access-Traffic-Profil aktivieren, Global Secure Access Client auf Entra-joined oder Hybrid-joined Geräten ausrollen, TLS-Inspection-Richtlinie mit eigener Zertifizierungsstelle einrichten, Content Policy mit der Aktion „Scan with Purview“ anlegen, an ein Security Profile hängen und dieses über eine Conditional-Access-Richtlinie als Session Control scharf schalten.

Auf der Purview-Seite: Pay-as-you-go aktivieren, eine DLP-Richtlinie vom Typ „Inline web traffic“ anlegen, Cloud-Apps oder adaptive App-Bereiche auswählen, die Durchsetzung auf „Network and non-Microsoft secure browsers“ stellen und eine Regel mit der Aktion „Restrict browser and network activities“ bauen.

Innerhalb dieser Aktion stehen dir vier Aktivitäten zur Verfügung, jeweils einzeln auf Audit oder Block schaltbar: Text an eine Cloud- oder KI-App senden, Text von einer Cloud- oder KI-App empfangen, Datei hochladen, Datei herunterladen. Bemerkenswert ist, was fehlt: eine Warnung mit Override wie beim Endpoint-DLP gibt es hier nicht. Entweder du protokollierst still mit, oder du machst die Tür zu. Ein Dazwischen, in dem der Nutzer begründet und trotzdem weitermacht, existiert an dieser Stelle nicht.

Neben den blockierenden DLP-Richtlinien gibt es noch die Collection Policies. Der Unterschied ist betrieblich relevant: DLP-Richtlinien kommunizieren in Echtzeit mit der Netzwerklösung, weil ja jemand auf ein Verdikt wartet. Collection Policies arbeiten asynchron und dienen reinem Monitoring. Wer nur wissen will, was da eigentlich passiert, fährt mit einer Collection Policy schneller und ohne Latenz im Nutzerpfad. In DSPM for AI gibt es dafür sogar eine Ein-Klick-Empfehlung, die eine fertige Richtlinie anlegt. Wenn du zusätzlich Content Capture aktivierst, landet die komplette Konversation zwischen Nutzer und KI-App in Purview. Das ist forensisch großartig und arbeitsrechtlich hochexplosiv – dazu gleich mehr.

Der zweite Baustein, der in den Ankündigungen prominent auftaucht, ist die Verzahnung mit Insider Risk Management. Netzwerk-DLP-Signale speisen die Risikoindikatoren. Ein einzelner Fehlversuch beim Upload ist Rauschen. Derselbe Nutzer, der über zwei Wochen wiederholt klassifizierte Inhalte an wechselnde KI-Dienste schiebt, während im Hintergrund eine Kündigung läuft, ist ein Muster. Genau diese Korrelation ist der Grund, warum Purview und Defender in der Kommunikation als Investigation- und Incident-Management-Ebene positioniert werden und nicht als weiteres Log-Ziel.

Rollout und Vorbereitungsfenster: der Papierkram ist der längere Weg, nicht die Technik.

Was sind Chancen? Was sind Risiken?

Die Chancen liegen auf dem Tisch und sind ehrlich groß. Du bekommst zum ersten Mal einen belastbaren Blick darauf, welche KI-Dienste in deinem Unternehmen tatsächlich genutzt werden und was dort hineinwandert. Nicht geschätzt, nicht aus einer Umfrage, sondern aus dem Datenpfad. Für jeden, der gerade eine KI-Richtlinie schreibt, ist das die einzige belastbare Faktenbasis. Dazu kommt: Du erschlägst Kanäle, die im Endpoint-DLP notorisch durchrutschen – private Webmail, Formulardienste, native Clients, API-Aufrufe. Und du machst es mit deiner bestehenden Klassifizierung, ohne ein zweites Regelwerk zu pflegen.

Der zweite strategische Punkt: Das Ganze ist identitätszentrisch. Die Durchsetzung hängt an einer Conditional-Access-Richtlinie, und die Content Policy kann das Nutzerrisiko als Bedingung auswerten. Damit kannst du abgestuft arbeiten, statt für alle dieselbe Mauer zu bauen. Der Standardnutzer darf, der als riskant eingestufte Nutzer nicht. Das ist genau die Art von Differenzierung, die einen Sicherheitsmechanismus im Betrieb überleben lässt.

Die Risiken sind vielschichtiger, als der Marketingtext vermuten lässt. Der größte ist kein technischer: TLS-Inspektion ist ein Politikum. Du entschlüsselst den Internetverkehr deiner Mitarbeiter an einem Cloud-Edge. Microsoft schreibt in der eigenen Dokumentation ausdrücklich, dass du deine TLS-Richtlinie vorher etablieren und den Endnutzern kommunizieren sollst, um Transparenz zu wahren und Datenschutz- sowie Einwilligungsanforderungen zu erfüllen. Und es kommt noch deutlicher: Beim Anlegen einer TLS-Inspection-Richtlinie wird automatisch eine empfohlene Bypass-Regel erzeugt, die die Kategorien Education, Finance, Government sowie Health & Medicine ausnimmt. Das ist kein Zufall. Das ist Microsofts Art zu sagen: Onlinebanking und Arztportale willst du nicht mitlesen.

Technisch gibt es eine Reihe von Kanten, die du kennen musst, bevor sie dich schneiden. QUIC wird nicht unterstützt; du musst ausgehenden UDP-Verkehr auf Port 443 per Firewall-Regel blocken, sonst läuft der Verkehr am Edge vorbei. Secure DNS beziehungsweise DNS over HTTPS musst du auf dem Client abschalten. Zertifikat-Pinning bricht bei Break & Inspect zuverlässig, also brauchst du eine gepflegte Ausnahmeliste und ein Verfahren, wie eine neue Ausnahme beantragt wird. Komprimierte Inhalte werden im ZIP-Format zwar erkannt, aber nicht entpackt. Die Erkennung des echten Dateityps ist laut Dokumentation nicht zu hundert Prozent zuverlässig. Platzhalter auf Top- und Second-Level-Domains sind bei der FQDN-Konfiguration nicht erlaubt. Und B2B-Gastkonten sind von Purview Network Data Security grundsätzlich ausgenommen – was in Projektorganisationen mit vielen Externen ein sehr großes Loch sein kann.

Dazu kommen Katalogfallen. Wenn eine App unter mehreren Namen im Katalog steht, musst du alle Einträge aufnehmen, sonst hast du unbeabsichtigte Lücken. Einzelne KI-Dienste verschicken Inhalte zeitweise codiert an dynamisch erzeugte Endpunkte, was die Durchsetzung unterlaufen kann. Und wenn Consumer- und Enterprise-Variante eines Dienstes dieselbe URL nutzen, fängt deine Richtlinie beide – der geschäftlich freigegebene Tenant also gleich mit.

Abdeckung ohne Schönfärberei: links der echte Gewinn, rechts das Restrisiko, das im Konzept stehen muss.

Und dann ist da noch die Betriebsrealität. Purview hängt jetzt synchron im Datenpfad. Wenn die Klassifizierung langsam ist, merkt das der Nutzer beim Upload. Nach der Einrichtung musst du bis zu 24 Stunden einplanen, bis Richtlinien an die Netzwerklösung verteilt sind, und bis zu 30 Minuten, bis eine Aktivität im Audit-Log und im Activity Explorer auftaucht. Für eine Live-Analyse während eines Vorfalls ist das eine halbe Ewigkeit. Plane deine Testschleifen entsprechend, sonst suchst du stundenlang den Fehler in einer Richtlinie, die noch gar nicht angekommen ist.

Was müssen wir jetzt schon vorbereiten?

Wenn die GA Ende September beginnt und Ende Oktober durch ist, bleiben dir realistisch zwei Monate. Das reicht, wenn du jetzt anfängst, und es reicht nicht, wenn du im September anfängst. Die Reihenfolge ist dabei wichtiger als die Geschwindigkeit.

Klassifizierung härten. Netzwerk-DLP ist nur so gut wie deine Sensitive Information Types und Labels. Miss die Fehlalarmquote deiner wichtigsten Klassifizierer, bevor du sie auf den Netzwerkpfad loslasst. Ein Klassifizierer, der im SharePoint gelegentlich danebengreift, erzeugt dort einen Hinweis. Im Netzwerkpfad erzeugt er einen blockierten Geschäftsprozess.

Entra Internet Access pilotieren. Traffic-Forwarding-Profil aktivieren, Client auf einer Testgruppe ausrollen, in den Advanced Diagnostics prüfen, ob die Internet-Access-Regeln wirklich ankommen. Rechne mit bis zu 15 Minuten, bis das Profil beim Client landet.

Zertifikatsverteilung sauber aufsetzen. Eigene Zertifizierungsstelle für die TLS-Inspektion, Stammzertifikat über Intune in den Speicher der vertrauenswürdigen Stammzertifizierungsstellen der verwalteten Geräte. Dazu ein dokumentierter Rollback – du willst wissen, wie du das an einem Freitagabend wieder abschaltest.

QUIC und Secure DNS per Richtlinie abschalten. Die Firewall-Regel gegen ausgehendes UDP 443 gehört in dieselbe Baseline wie der Client selbst, sonst hast du eine löchrige Abdeckung und weißt nicht warum.

Bypass-Katalog aufbauen. Banking, Gesundheit, Behörden, Betriebsratssysteme, Anwendungen mit Zertifikat-Pinning. Wer entscheidet über Ausnahmen, wie werden sie dokumentiert, wann werden sie überprüft.

Rechtliches parallel starten. Datenschutz-Folgenabschätzung, Betriebsvereinbarung, Nutzerinformation. Das ist der längste Pfad im Projekt und der einzige, den du nicht durch mehr Techniker beschleunigen kannst.

Pay-as-you-go aktivieren und ein Kostenmodell rechnen. Ohne aktiviertes Abrechnungsmodell kannst du die Netzwerkdurchsetzung im Richtlinienassistenten gar nicht auswählen. Setze von Anfang an Budgetalarme auf die Azure-Subscription.

Audit-Mode zuerst, und zwar länger als dir lieb ist. Simulationsmodus, mindestens sechs Wochen, mit wöchentlicher Auswertung im Activity Explorer, gefiltert auf Enforcement Plane gleich Network. Erst danach gestaffelt auf Block, beginnend mit der Nutzergruppe, die den geringsten Geschäftsschaden verursacht, wenn es schiefgeht.

Betriebsmodell klären. Purview-Alerts, Defender-Incidents und GSA-Traffic-Logs sind drei Oberflächen für einen Vorfall. Wer schaut wo hinein, wer eskaliert an wen, und wie sieht der Prozess aus, wenn ein Block eine Fehlentscheidung war.

Lizenzentscheidung treffen. Microsoft 365 E7 mit vollständiger Entra Suite gegen die Kombination Purview E5 plus Entra Internet Access. Das ist eine Rechnung, die du einmal sauber machst und dann drei Jahre nicht mehr anfassen musst.

Häufig gestellte Fragen

Brauche ich zwingend TLS-Inspektion, damit Purview den Netzwerkverkehr prüfen kann?

Ja, für die Inhaltsprüfung führt kein Weg daran vorbei. Ohne Aufbrechen der TLS-Verbindung am Service-Edge sieht die Lösung nur Metadaten, und die Aktion „Scan with Purview“ kann weder Dateien noch Texte klassifizieren. Eine einfache Content Policy, die nur nach MIME-Typ erlaubt oder blockt, funktioniert auch ohne Purview-Lizenz, ist aber eben nur ein grober Dateitypfilter.

Was kostet Netzwerk-DLP tatsächlich, und ist es in Microsoft 365 E5 enthalten?

Nein, E5 allein genügt nicht. Du brauchst entweder Microsoft 365 E7 oder Purview E5 zusammen mit einer Entra-Internet-Access-Lizenz, und zusätzlich muss im Tenant Pay-as-you-go aktiviert sein. Die verbrauchsabhängige Komponente liegt bei 0,50 US-Dollar je 10.000 Requests, wobei jeder Netzwerkaufruf an eine Website oder API zählt – kalkuliere also über das Verkehrsvolumen und nicht über Nutzerzahlen.

Ersetzt Netzwerk-DLP mein bestehendes Endpoint-DLP?

Nein, die beiden ergänzen sich. Endpoint-DLP kontrolliert lokale Vorgänge wie das Kopieren auf USB-Medien, Drucken oder die Zwischenablage, während Netzwerk-DLP den Weg ins Internet abdeckt, inklusive nativer Anwendungen und API-Aufrufe, die auf dem Endpunkt schwer zu greifen sind. Die Richtlinien werden getrennt gepflegt, weil sich der Typ für Inline-Web-Traffic nicht mit anderen Speicherorten kombinieren lässt.

Funktioniert das auch auf privaten Geräten, iOS oder Android?

In der aktuellen Ausbaustufe nicht. Der Global Secure Access Client setzt für dieses Szenario Windows oder macOS voraus, und das Gerät muss Entra-joined oder Hybrid-joined sein. Für nicht verwaltete Geräte bleibt der klassische Weg über Conditional Access, Gerätekonformität und App-Schutzrichtlinien.

Was passiert mit Anwendungen, die Certificate Pinning verwenden?

Die brechen beim Aufbrechen der TLS-Verbindung, weil sie das Zertifikat des Service-Edge nicht akzeptieren. Solche Ziele gehören in eine Bypass-Regel der TLS-Inspektionsrichtlinie, was gleichzeitig bedeutet, dass sie für die Inhaltsprüfung ein blinder Fleck bleiben. Diese Ausnahmen solltest du dokumentieren und regelmäßig überprüfen, sonst wächst die Liste unbemerkt zu einer echten Lücke an.