Microsoft 365 Purview | Text & Prompts auf Netzwerkebene geschützt ⏱ 10 Min.

Microsoft 365 Purview | Text & Prompts auf Netzwerkebene geschützt

Purview DLP verlässt Office

Die klassischen Grenzen der Data Loss Prevention (DLP) sind deckungsgleich mit den Grenzen der eigenen Cloud-Tenant-Infrastruktur. Richtlinien in Microsoft Purview schützen Daten in Exchange Online, SharePoint Online und Microsoft Teams zuverlässig. Sobald Informationen die geschützte Umgebung verlassen, endet die Kontrollmöglichkeit.

Kopiert ein Mitarbeiter sensible Daten aus einem internen Dokument und fügt diesen Text in das Eingabefeld einer externen künstlichen Intelligenz wie ChatGPT oder Gemini ein, bleibt dieser Vorgang für traditionelle DLP-Systeme unsichtbar. Es findet kein klassischer Datei-Upload statt, der durch Endpoint DLP auf dem Betriebssystem blockiert werden könnte. Der Text fließt als unstrukturierter Payload über eine HTTPS-Verbindung ab. Genau diese Sicherheitslücke schließt Microsoft mit der Erweiterung der Data Loss Prevention auf die Netzwerkebene durch die Integration von Entra Internet Access.

Die Public Preview läuft seit Ende Juni 2026, die Roadmap nennt Juli 2026 als Preview-Phase und September 2026 als Start der General Availability. Seit Mitte November 2025 filtert die GSA-Integration Dateien auf Netzwerkebene (Roadmap-ID 522096, angekündigt in MC1181769), die Datei-Filterung hat laut Message Center seit Mitte Juni 2026 die General Availability erreicht. Der neue Eintrag hebt die entscheidende Einschränkung auf. Bisher blieben getippte Texte, Prompts und API-Payloads unsichtbar für Purview.

Die technologische Architektur: Wie GSA und Purview verschmelzen

Die technische Basis bildet die Global-Secure-Access-Familie (GSA), die als Security Service Edge (SSE) agiert. Auf dem Endgerät des Nutzers ist der Global-Secure-Access-Client installiert. Dieser Client klinkt sich tief in den Netzwerk-Stack des Betriebssystems ein, konkret als Kernel-Mode-Netzwerkfilter. Er fängt den gesamten ausgehenden Web-Traffic ab, der für das öffentliche Internet bestimmt ist.

Anstatt die Daten direkt an die Ziel-URL zu senden, leitet der Client die Pakete durch einen verschlüsselten Tunnel an den nächstgelegenen Microsoft-SSE-Edge-Knoten weiter. An diesem Punkt erfolgt der entscheidende Schritt: die TLS-Inspektion (Transport Layer Security Inspection). Der Edge-Knoten bricht die verschlüsselte HTTPS-Verbindung auf. Er fungiert als transparenter Proxy. Damit das Endgerät diese Verbindung nicht als Man-in-the-Middle-Angriff einstuft und blockiert, muss eine vertrauenswürdige Zwischenzertifizierungsstelle (Sub-CA) im Zertifikatsspeicher des Clients hinterlegt sein.

Sobald der Datenstrom entschlüsselt vorliegt, analysiert die Content-Policy nicht mehr nur die Metadaten oder Dateigrößen. Die Engine extrahiert den HTTP-POST-Body. Hier befinden sich die getippten Texte, API-Payloads und Prompts, die an generative KI-Dienste gesendet werden. Dieser extrahierte Text wird in Echtzeit an die Purview-Klassifizierungs-Engine übergeben. Dort wirken dieselben Mechanismen wie bei der klassischen E-Mail-Überwachung: Sensitive Information Types (SITs) für Kreditkartennummern oder Sozialversicherungsdaten, Sensitivity Labels und antrainierte Klassifizierer (Trainable Classifiers). Erkennt Purview einen Verstoß, blockiert der Edge-Knoten die Übertragung inline. Die Daten erreichen den Zieldienst nie.

Für Dich als Admin bedeutet das: dieselben Sensitive Information Types, Sensitivity Labels und Trainable Classifiers, die Du heute in Exchange- oder Endpoint-Richtlinien nutzt, wirken künftig auf über 35.000 nicht verwaltete Cloud-Apps aus dem Katalog von Defender for Cloud Apps. Die Signale fließen parallel in Insider Risk Management, wodurch riskante Muster wie massenhafter Datenabfluss zu Consumer-KI-Apps als Risikoindikator auswertbar werden. Alerts und Incidents landen zentral in Purview und im Defender-Portal.

Lizenz und Kosten: der Teil, den Microsoft klein druckt

Die Implementierung erfordert eine genaue ökonomische Vorabkalkulation, da die Lizenzkosten abseits der Standard-E5-Pakete liegen. Bevor Du die Anleitung durchklickst, rechne die Voraussetzungen durch, denn hier liegt die eigentliche Hürde.

  • Purview-Funktion: Microsoft 365 E5 oder gleichwertige Lizenz (E5 Compliance) pro Nutzer.
  • Entra Internet Access: separate Lizenz, entweder standalone oder als Teil der Entra Suite. Das in E5 enthaltene GSA-Traffic-Profil deckt ausschließlich M365-Traffic ab und reicht für dieses Szenario nicht.
  • Purview Pay-as-you-go: zwingend. Der Tenant muss mit einer Azure-Subscription verknüpft sein, abgerechnet wird pro Request (aktuell 0,50 US-Dollar pro 10.000 Requests laut Purview-Preisliste). Während der Preview ist die GSA-Integration von der Abrechnung ausgenommen, ab GA fallen die Kosten an.

Der kostentechnisch kritischste Faktor ist die Abrechnung pro einzelnem Request. Als Request zählt jeder Netzwerkaufruf eines Geräts oder Browsers an eine Webseite oder API, die Antworten darauf zählen nicht. Abgerechnet werden dabei nur Requests, die in den Geltungsbereich einer Purview-Richtlinie fallen. Genau deshalb entscheidet der Zuschnitt der Richtlinie über die Azure-Rechnung: Eine moderne Webseite erzeugt durch Skripte, Bilder, Werbebanner und API-Aufrufe dutzende Requests pro Seitenaufruf, ein aktiver Mitarbeiter kommt im regulären Betrieb problemlos auf mehrere tausend Requests pro Tag.

Ohne eine präzise Eingrenzung des Geltungsbereichs drohen unvorhersehbare Kosten bei der monatlichen Azure-Abrechnung. Während der aktuellen Public-Preview-Phase ist diese Funktion von den Nutzungsgebühren ausgenommen, die Abrechnung startet mit der General Availability.

HowTo

Teil 1 Umsetzung in EntraID

Die Einrichtung erfolgt in einer strikten chronologischen Reihenfolge. Ohne eine voll funktionsfähige TLS-Inspektion schlagen nachfolgende DLP-Richtlinien fehl.

Schritt 1: Aktivierung des Internet-Access-Profils

Navigiere im Entra Admin Center zum Bereich Global Secure Access. Aktiviere das Traffic-Forwarding-Profil für den Internet Access. Weise dieses Profil einer dedizierten Pilotgruppe zu, um den regulären Betrieb der restlichen Belegschaft nicht zu gefährden. Der GSA-Client muss auf den Testgeräten installiert sein, damit der Datenverkehr über die Microsoft-Infrastruktur fließt. Die Geräte müssen dafür in Entra ID eingebunden sein (Entra ID Joined), da Microsoft dies als Voraussetzung für die Internet-Access-Szenarien nennt.

Schritt 2: Einrichtung der TLS-Inspektion

Erstelle eine Richtlinie für die TLS-Inspektion. Hierzu generierst Du eine Zwischenzertifizierungsstelle im Entra-Portal oder lädst das Zertifikat Deiner internen Enterprise-PKI hoch. Dieses Zertifikat muss zwingend über Microsoft Intune als vertrauenswürdige Stammzertifizierungsstelle auf alle Client-Geräte verteilt werden. Fehlt dieser Schritt, brechen Browser jede Verbindung mit einer schweren Sicherheitswarnung ab.

Schritt 3: Erstellung der Content-Policy

Konfiguriere eine Inhaltsrichtlinie (Content Policy) im Bereich der Netzwerk-Inhaltsfilterung. Die entscheidende Konfiguration innerhalb der Regel ist die Aktion "Scan with Purview". Diese Aktion bildet die technologische Brücke und weist den Entra-Edge-Knoten an, den entschlüsselten Payload zur Tiefenprüfung an Purview zu übergeben.

Bündle die TLS-Inspektionsrichtlinie und die Content-Policy in einem gemeinsamen Sicherheitsprofil (Security Profile). Verknüpfe dieses Profil anschließend mit einer Richtlinie für den bedingten Zugriff (Conditional Access), die auf Deine Pilotgruppe zielt. Erst durch diese Verknüpfung wird der Datenverkehr der Sessions aktiv kontrolliert.

Teil 2 Konfiguration in Purview

Nachdem die Netzwerkinfrastruktur den Datenverkehr bereitstellt, erfolgt die Konfiguration der Schutzregeln im Purview-Portal.

Schritt 1: Pay-as-you-go aktivieren

Stelle sicher, dass Dein Tenant mit einer gültigen Azure-Subscription verknüpft ist. Ohne diese Verbindung lassen sich die netzwerkbasierten DLP-Funktionen im Portal nicht konfigurieren und verbleiben in einem ausgegrauten Zustand.

Schritt 2: DLP-Richtlinie anlegen

Erstelle eine neue Data-Loss-Prevention-Richtlinie. Wähle als spezifischen Standort die Option "Inline web traffic" aus. Dieser Standort erfasst neben den bereits länger unterstützten Datei-Uploads nun auch reine Texteingaben.

Schritt 3: Geltungsbereich über Adaptive Scopes einschränken

Um die Kosten zu kontrollieren und den Fokus auf das Risiko zu legen, wählst Du bei den App-Bereichen die adaptiven Gruppen (Adaptive App Scopes) aus. Wähle die Gruppe "All unmanaged AI apps". Der Vorteil dieser dynamischen Zuweisung liegt darin, dass Microsoft die Liste bekannter Cloud-KI-Dienste kontinuierlich pflegt. Neue Plattformen fallen automatisch unter die Richtlinie, ohne dass manuelle URL-Listen gepflegt werden müssen.

Schritt 4: Bedingungen und Schutzaktionen definieren

Definiere die Bedingungen für das Anschlagen der Regel. Nutze bewährte Sensitive Information Types wie IBAN-Strukturen, Kreditkartendaten oder Quellcode-Muster. Bei den Aktionen wählst Du den Punkt "Restrict browser and network activities".

Setze die beiden Optionen "Text sent to or shared with cloud or AI apps" sowie "File uploaded to or shared with cloud or AI apps" restriktiv auf Blockieren. Dadurch verhinderst Du den Upload eines vertraulichen PDF-Dokuments und das Kopieren von Textpassagen in den Prompt-Bereich.

Schritt 5: Testlauf im Simulationsmodus

Aktiviere die Richtlinie zwingend zuerst im Simulationsmodus. Die Auswirkungen von Netzwerk-DLP auf den Workflow der Nutzer sind massiv. Eine Testphase von zwei bis vier Wochen liefert die notwendige Datenbasis im Activity Explorer. So lässt sich ermitteln, wie viele Fehlalarme (False Positives) generiert werden, bevor eine harte Blockierung den Helpdesk mit Anfragen überlastet.

Validierung und fortlaufendes Monitoring

Die Überprüfung der Funktionskette erfolgt über den Activity Explorer im Purview-Portal. Um die korrekte Filterung zu verifizieren, filterst Du die Ereignisse nach der Enforcement Plane mit dem Wert "Network". Jedes Protokoll mit diesem Attribut beweist, dass der Datenstrom erfolgreich über die GSA-Integration geprüft wurde.

Führe einen praktischen Test mit einem Testgerät der Pilotgruppe durch. Tippe einen Prompt in eine nicht verwaltete KI-Anwendung, der eine synthetische Kreditkartennummer enthält. Die Blockierung muss unmittelbar inline im Browser erfolgen. Gleichzeitig muss das Ereignis im Activity Explorer dokumentiert werden. Bei konfigurierten Warnungen wird parallel ein Incident im Microsoft Defender-Portal generiert, was dem Security Operations Center (SOC) die Korrelation mit anderen Identitätsrisiken ermöglicht.

Kritische Stolperfallen und regulatorische Hürden

Die Implementierung von TLS-Inspektion ist im DACH-Raum kein rein technisches Projekt. Das Aufbrechen verschlüsselter Verbindungen stellt eine tiefgreifende Überwachung der Mitarbeiter dar. Dies berührt direkt die Mitbestimmungsrechte des Betriebsrates nach Paragraph 87 Absatz 1 Nummer 6 BetrVG, da es sich um eine technische Einrichtung zur Verhaltens- und Leistungsüberwachung handelt. Eine frühzeitige Einbindung des Gremiums und der Abschluss einer klaren Betriebsvereinbarung sind zwingend erforderlich.

Der Datenschutzbeauftragte muss ebenfalls einbezogen werden. Eine Datenschutz-Folgenabschätzung (DSFA) ist in der Regel unvermeidbar. Erschwerend kommt hinzu: Ist die private Nutzung des Internets am Arbeitsplatz erlaubt, darf der Arbeitgeber den privaten Datenverkehr (wie Online-Banking oder digitale Patientenakten) rechtlich nicht einsehen. Administratoren müssen granulare Bypass-Listen in den TLS-Inspektionsrichtlinien konfigurieren, um sensible Kategorien komplett von der Entschlüsselung auszunehmen. Die Pseudonymisierung von Benutzerdaten im Insider Risk Management lindert das Problem, entbindet aber nicht von den rechtlichen Vorgaben.

Aus technischer Sicht gilt: Der Schutz funktioniert ausschließlich auf Geräten, auf denen der GSA-Client aktiv läuft. Bring-Your-Own-Device-Szenarien (BYOD) oder nicht verwaltete Linux-Systeme werden von diesem Netzwerk-Tunnel nicht erfasst. Hier müssen weiterhin alternative Kontrollen wie Microsoft Edge for Business oder Conditional Access App Control greifen. Da sich die Funktionalität in der Preview-Phase befindet, sind kurzfristige Verhaltensänderungen bis zur General Availability im September 2026 einzukalkulieren. Microsoft Learn weist zusätzlich darauf hin, dass die Verteilung neuer Richtlinien an die integrierte Netzwerklösung bis zu 24 Stunden dauern kann, bis die ersten Daten sichtbar werden.

Fazit und Empfehlungen

Mit Roadmap 566528 zieht Microsoft die DLP-Grenze dorthin, wo sie hingehört: an den Netzwerkrand statt an die App-Grenze. Dass Purview jetzt getippten Text und KI-Prompts inline prüft, beendet die unbefriedigende Situation, dass Endpoint DLP zwar den Datei-Upload nach ChatGPT blockt, der kopierte Vertragstext im Prompt-Feld aber ungehindert durchgeht. Für Organisationen mit Schatten-KI-Problem ist das der bisher vollständigste Microsoft-native Ansatz, weil er Egress-Kanäle jenseits des Browsers abdeckt und dieselbe Klassifizierungslogik nutzt, die Du in Purview ohnehin gepflegt hast.

Die Kehrseite dieser Architektur liegt in der Komplexität und den finanziellen Aufwänden. Die Kombination aus E5-Lizenzen, zusätzlichen Entra-Internet-Access-Gebühren und den Pay-as-you-go-Kosten pro Request summiert sich schnell zu erheblichen Beträgen. Unternehmen, die bereits etablierte SASE-Systeme von Drittanbietern wie Zscaler, Netskope oder Palo Alto im Einsatz haben, sollten die parallel verfügbaren Purview-Integrationen prüfen, anstatt einen zusätzlichen Netzwerk-Client auszurollen.

Der richtige Weg für Administratoren: Nutze die kostenfreie Preview-Phase für einen isolierten Piloten im Simulationsmodus. Die gewonnenen Erkenntnisse über den tatsächlichen Datenfluss zu externen KI-Plattformen bieten eine valide Entscheidungsgrundlage für zukünftige Investitionen, selbst wenn das System aufgrund regulatorischer Hürden oder Kostenfaktoren am Ende nicht flächendeckend produktiv geschaltet wird. Die Abstimmung mit dem Betriebsrat sollte parallel zum technischen Setup am ersten Tag starten.

QuelleThemaURL
Microsoft 365 RoadmapRoadmap-ID 566528, Text/Prompts via GSAhttps://www.microsoft.com/microsoft-365/roadmap?searchterms=566528
Message Center Archiv (Merill Fernando)MC1181769, Datei-Filterung via GSA (Vorgänger)https://mc.merill.net/message/MC1181769
Microsoft LearnNetwork Data Security: Konzept, Lizenz, PAYGhttps://learn.microsoft.com/en-us/purview/dlp-network-data-security-learn
Microsoft LearnDLP-Richtlinie gegen unmanaged AI Apps (Anleitung)https://learn.microsoft.com/en-us/purview/dlp-create-policy-ai-network-data-security
Microsoft LearnWhat's new in Microsoft Purview (Preview-Eintrag)https://learn.microsoft.com/en-us/purview/whats-new
Microsoft Entra Blog (Tech Community)Offizielle Preview-Ankündigung Purview + Entrahttps://techcommunity.microsoft.com/blog/microsoft-entra-blog/protect-sensitive-data-in-motion-across-saas-and-ai-apps-with-microsoft-purview-/4529310
Chris BuesPraxis-Setup Network DLP mit GSA, Lizenz- und Kostendetailshttps://chrisbues.com/blog/network_dlp/
Message Center ArchivMC1102773, IRM-Erkennung auf Netzwerkebenehttps://mc.merill.net/message/MC1102773


Teilen:
Noch keine Kommentare

Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.

Kommentar hinterlassen

Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.

E-Mail Adresse wird nicht veröffentlicht.