Microsoft Purview | Copilot absichern: DLP-Strategie & die Browser-Falle

Sicherheit im Zeitalter generativer KI gleicht oft einem endlosen Hase-und-Igel-Rennen. Kaum sind die Speicherorte abgesichert, finden Daten neue, kreative Wege in die Modelle. Microsoft reagiert nun auf genau dieses Szenario und rollt aktuell (im Preview-Status seit Ende 2025) eine entscheidende Erweiterung für Microsoft Purview Data Loss Prevention (DLP) aus, die den Schutzschirm für den Microsoft Copilot signifikant erweitert.

Bisher hatten wir als Administratoren vor allem ein Werkzeug in der Hand: Den Zugriff auf Dateien steuern. Wir konnten Copilot effektiv verbieten, Dokumente mit bestimmten Sensitivity Labels (z. B. „Streng Vertraulich“) zu verarbeiten. Dieser container-basierte Schutz ist essenziell, lässt aber eine entscheidende Flanke offen: Den Faktor Mensch.

Denn was passiert, wenn ein Mitarbeiter sensible Daten – etwa eine Kreditkartennummer oder Kundendaten – nicht aus einer geschützten Datei referenziert, sondern sie per Copy & Paste oder via Tastatur direkt in den Chat-Prompt eingibt? Bislang war Copilot hier „blind“ für den Inhalt der Eingabe. Genau diese Sicherheitslücke schließt die neue Funktion, indem sie den Fokus von der Datei auf die Eingabeaufforderung (Prompt) verlagert.

Der Prompt als Sicherheitsrisiko

Bislang basierte der DLP-Schutz für Copilot primär auf Sensitivity Labels. Das bedeutet: Wenn ein Word-Dokument als „Streng Vertraulich“ gelabelt war, durfte Copilot die Informationen aus dieser Datei nicht für seine Antworten nutzen. Dieser Container-basierte Schutz funktioniert auch weiterhin hervorragend.

Die neue Policy setzt jedoch einen Schritt früher an: Sie überwacht den Prompt des Users, also die Eingabe im Chat. Ziel ist es, die Eingabeaufforderung selbst abzusichern („safeguard prompts“). Wenn ein Mitarbeiter versucht, Kreditkartennummern, Ausweisdaten oder andere Muster in den Chat einzufügen, greift die DLP-Regel sofort.

Von der Empfehlung zur Richtlinie

Wer sich die manuelle Konfiguration erleichtern möchte, findet in der Lösung „DSPM for AI“ im Bereich „Empfehlungen“ einen mächtigen Assistenten. Dort lassen sich Vorschläge auswählen, um daraus in den jeweiligen Purview-Lösungen vollautomatisch eine Richtlinie erstellen zu lassen.

Typische Empfehlungen, aus denen diese Richtlinien entstehen, lauten:

• „Riskante Interaktionen in KI-Apps erkennen“
• „Schützen Sie vertrauliche Daten in Copilot-Interaktionen“
• „Sichere Interaktionen von KI-Apps für Unternehmen“

Ein konkretes Beispiel aus der Praxis ist die Empfehlung „Erweitern Sie Ihre Erkenntnisse für die Datenermittlung“. Klickst du hier auf „Einrichten“, passiert im Hintergrund viel mehr, als auf den ersten Blick ersichtlich ist. Das System erstellt gleich drei Regelwerke parallel:

1. DLP & Audit: DSPM for AI – Detect sensitive info shared in AI prompts in Edge (Erkennt Prompts im Edge).
2. Insider Risk Management: DSPM for AI – Detect when users visit AI sites (Erkennt Besuche auf KI-Seiten).
3. DLP Cross-Browser: DSPM for AI: Detect sensitive info added to AI sites (Überwacht Chrome und Firefox).

⚠️ Drei kritische Punkte, die du beachten musst:

1. Die Kosten (Pay-as-you-go): Im Kleingedruckten versteckt sich oft der Hinweis: „Das Erkennen … ist eine Funktion mit nutzungsbasierter Bezahlung.“ Diese DSPM-Funktionen sind oft nicht in der Standard-Lizenz inkludiert, sondern werden verbrauchsabhängig abgerechnet. Prüfe dies vor der Aktivierung!

2. Die „Nur Überwachungsmodus“-Falle: Zwar verspricht Microsoft im Dialog oft „Keine Auswirkungen auf Benutzer (nur Überwachungsmodus)“, doch der Nachsatz hat es in sich: „…aber sie müssen die Microsoft Purview-Browsererweiterung installiert haben.“ Fehlt die Erweiterung auf den Clients oder ist das Gerät nicht korrekt in Purview onboarded, greifen die Richtlinien entweder ins Leere (Blindflug) oder führen, je nach globaler Konfiguration, zu einer sofortigen Blockade der Anwendung (z. B. startet Firefox nicht mehr), da der Browser ohne Extension als „unsicherer Kanal“ eingestuft wird.

3. Simulation ist Pflicht: Verlasse dich niemals darauf, dass der Assistent den Modus korrekt auf „Test“ stellt. Gehe nach der Erstellung sofort in die jeweilige Richtlinien-Übersicht und verifiziere, dass der Status auf „Im Simulationsmodus“ steht. Ein versehentliches „Aktiv“ bei einer Richtlinie, die auch Insider Risk Management und Browser-Blockaden steuert, kann massive Auswirkungen auf den produktiven Betrieb haben.

DSPM for AI als reine Sammelstelle

Vielleicht fragst du dich nach der Aktivierung: „Wo finde ich diese Richtlinien eigentlich wieder?“ Der Bereich DSPM for AI (Verwaltung des Datensicherheitsstatus für KI) fungiert als übergeordnetes Dashboard, sozusagen das strategische Cockpit.

Es ist die zentrale Sammelstelle, die den Status aller KI-bezogenen Sicherheitsmaßnahmen zusammenfasst, egal ob sie technisch im Data Loss Prevention, Insider Risk Management oder Audit laufen.

Der wichtige Unterschied: Während du im DSPM-Dashboard einen hervorragenden Überblick über Risiken erhältst und Richtlinien per „One-Click“ erstellen kannst, ist es kein vollwertiger Editor.

• Einsehen (Monitor): Du siehst hier zentral, welche Richtlinien aktiv sind, welche KI-Apps genutzt werden und wo Risiken bestehen.
• Bearbeiten (Werkstatt): Um eine Richtlinie im Detail anzupassen (z. B. spezifische Ausnahmen hinzufügen, User-Gruppen ändern oder Benachrichtigungstexte anpassen), musst du zwingend in die jeweilige Lösung wechseln (z. B. navigierst du zu Data Loss Prevention > Richtlinien).

Betrachte DSPM for AI also als den Monitor, der dir zeigt, wo Handlungsbedarf besteht, während die eigentliche Konfigurationsarbeit weiterhin in den spezialisierten Purview-Lösungen stattfindet.

Dieses Video von Microsoft Mechanics zeigt anschaulich, wie DSPM for AI als zentrales Dashboard funktioniert und wie die dortigen Erkenntnisse in konkrete Sicherheitsrichtlinien überführt werden.

Umsetzung: Der manuelle Weg

Wer statt der automatisierten Empfehlungen lieber die volle Kontrolle behalten (und potenzielle Zusatzkosten der DSPM-Features vermeiden) möchte, wählt die manuelle Konfiguration.

Hier gilt jedoch eine wichtige architektonische Besonderheit: Der Schutz lässt sich nicht einfach per zusätzlichem Haken in deine bestehenden DLP-Richtlinien integrieren. Du musst eine separate Richtlinie erstellen, die exklusiv den Copilot-Standort anspricht und gezielt auf Sensitive Information Types (SITs) prüft.

1. Richtlinie erstellen und Kategorie wählen

Der Einstieg beginnt im Microsoft Purview Compliance Portal.

• Navigiere zu der Lösung Data Loss Prevention (Verhinderung von Datenverlust) > Richtlinien.
• Klicke auf „Richtlinie erstellen“.

Wichtig: Wähle unter Kategorien „Benutzerdefiniert“ und dann „Benutzerdefinierte Richtlinie“. Zwar gibt es Vorlagen für Finanzen oder Datenschutz, der manuelle Weg stellt jedoch sicher, dass wir keine unnötigen Voreinstellungen für Exchange oder SharePoint mitschleppen.

2. Speicherorte (Orte) auswählen

Dies ist der entscheidende Schritt, der diese Policy von allen anderen unterscheidet.

• Im Bereich „Orte“ deaktivierst du standardmäßig oft alle Voreinstellungen.
• Wähle stattdessen explizit und exklusiv den Standort: ☑ Microsoft 365 Copilot und Copilot Chat

Sobald dieser Haken gesetzt ist, werden die anderen Standard-Speicherorte (wie Exchange E-Mail, SharePoint-Websites, OneDrive-Konten) automatisch für diese Richtlinie deaktiviert. Das System erzwingt hier eine technische Trennung zwischen Dokumenten-DLP und Interaktions-DLP.

Tipp für den Rollout: Standardmäßig steht die Auswahl auf „Alle Benutzer & Gruppen“. Für den Anfang empfehlen wir dringend, über den Button „Bearbeiten“ eine Pilot-Gruppe (z. B. IT-Department oder Key-User) auszuwählen. So kannst du den Impact auf die Arbeitsweise testen, bevor du die Richtlinie auf das gesamte Unternehmen ausrollst.

3. Regeln definieren (SITs)

Im nächsten Schritt definierst du das Herzstück der Richtlinie: Wann soll der Schutzmechanismus zuschlagen?

• Bedingung erstellen: Wähle „Inhalt enthält“ und dort den Unterpunkt „Vertrauliche Informationstypen“ (Sensitive Information Types).
• Typen auswählen: Hier fügst du die relevanten Datentypen hinzu. Microsoft stellt über 300 vorgefertigte Muster bereit (z. B. Credit Card Number, IBAN, Germany Identity Card Number).
• Aktion festlegen: Wähle als Konsequenz „Zugriff beschränken oder Inhalte an Microsoft 365-Standorten verschlüsseln“.

Was technisch passiert: Anders als bei einer Datei wird hier nichts verschlüsselt. Stattdessen triggert diese Aktion im Copilot-Backend den Abbruch. Der Bot verweigert die Antwort mit dem Hinweis, dass Unternehmensrichtlinien verletzt wurden, sobald er das Muster im Prompt erkennt.

ℹ️ Was sind Sensitive Information Types (SITs)?

SITs sind Mustererkennungs-Klassifizierer in Microsoft Purview. Sie identifizieren sensible Daten nicht anhand des Dateinamens oder Speicherorts, sondern durch Analyse des Inhalts.

• Sie nutzen reguläre Ausdrücke (Regex), Schlüsselwörter und Prüfsummen (z. B. den Luhn-Algorithmus bei Kreditkarten), um Fehlalarme zu minimieren.
  
  Microsoft stellt über 300 vorgefertigte Typen bereit (z. B. EU Debit Card Number, Germany Identity Card Number, IBAN).
  
  Unternehmen können eigene Muster definieren, um spezifische Daten wie interne Personalnummern oder Projekt-Codes zu schützen.

Sensitivity Labels (Container-Schutz) hingegen sind der „Stempel“ auf einer Datei (z. B. „Streng Vertraulich“). Copilot darf die ganze Datei nicht lesen.

4. Einschränkungen beachten

Ein wichtiges technisches Detail, das oft übersehen wird: Während die meisten Regex-basierten Muster (z. B. „fängt mit DE an und hat 22 Stellen“) funktionieren, gibt es eine Einschränkung bei komplexeren Typen.

Achte darauf, keine benutzerdefinierten Typen zu verwenden, die auf Document Fingerprinting basieren (z. B. der digitale Fingerabdruck eines spezifischen PDF-Formulars). Diese rechenintensive Prüfung wird von der Copilot-Policy im Echtzeit-Chat aktuell nicht unterstützt.

Die Eckdaten auf einen Blick

Damit du die Tragweite der Konfiguration besser einschätzen kannst, hier die wichtigsten Rahmenbedingungen für den Betrieb:

• Parallelbetrieb & Koexistenz: Du musst dich nicht entscheiden. Diese neue SIT-basierte Richtlinie (die den Text im Prompt prüft) und deine bestehenden Label-basierten Richtlinien (die den Zugriff auf geschützte Dateien blockieren) laufen problemlos nebeneinander. Sie ergänzen sich zu einem mehrschichtigen Schutzkonzept: Der eine Riegel schützt den Container (Datei), der andere den Inhalt (Chat).
  
• RBAC & Berechtigungen: Nicht jeder Admin darf in die KI-Sicherheit eingreifen. Um diese Richtlinien zu erstellen oder zu bearbeiten, benötigst du im Microsoft Purview Portal spezifische Rechte. Mindestens erforderlich ist die Mitgliedschaft in der Rollengruppe „Data Security AI Admin“. Alternativ verfügen natürlich auch Administratoren der Gruppe „Organization Management“ (Organisationsverwaltung) über die notwendigen Privilegien.
  
• Lizenzierung & Umfang: Der Schutz ist weit gefasst und beschränkt sich nicht nur auf eine einzelne App. Die Richtlinie greift:
  1. Im zentralen BizChat (Microsoft 365 Chat in Teams/Web).
  2. Direkt in den Copilot-Funktionen der Office Apps (Word, PowerPoint, Excel, etc.). Wichtig: Laut Microsoft ist die technische Durchsetzung lizenzunabhängig und schützt sowohl die kostenpflichtigen als auch die kostenlosen Versionen von Copilot (sofern im Unternehmenskontext mit Commercial Data Protection genutzt).

User Experience: „Ich kann das nicht beantworten“

Wie fühlt sich diese Einschränkung für den Endanwender an? Stellen wir uns ein klassisches Szenario vor: Ein User kopiert eine Sozialversicherungsnummer oder eine Kreditkartennummer in den Chat und fragt: „Wem gehört diese Nummer?“ oder „Prüfe bitte den Status dieser Transaktion.“

Ohne DLP würde Copilot nun loslaufen und via Microsoft Graph in E-Mails, Chats oder SharePoint-Listen nach dieser Nummer suchen.

Mit aktiver DLP-Richtlinie passiert jedoch Folgendes:

1. Das System scannt den Prompt in Echtzeit, noch bevor die KI die Antwort generiert.
   
2. Es erkennt das Muster der Sozialversicherungsnummer (SIT).
   
3. Copilot bricht den Vorgang ab und lehnt die Bearbeitung der Anfrage höflich, aber bestimmt ab.
   
4. Der Nutzer erhält eine Meldung, dass die Nachricht aufgrund von Organisationsrichtlinien blockiert wurde.

Fazit & Roadmap

Diese neue Funktion ist ein hervorragendes Beispiel für „Erziehung durch Technik“ (Nudging). Der User macht nichts „kaputt“ und es wird kein Alarm ausgelöst, der das SOC sofort in Panik versetzt. Aber er lernt direkt im Workflow: „Aha, sensible Rohdaten gehören nicht in den KI-Chat.“

Laut Microsoft Roadmap (Item 515945) befinden wir uns aktuell auf der Zielgeraden der Preview-Phase, die noch bis Ende 2025 läuft (also nur noch wenige Tage). Die General Availability (GA) – also die allgemeine Verfügbarkeit für alle Produktionsumgebungen – ist für Ende März 2026 geplant.

Mein Rat: Warte nicht bis März. Nutze die Zeit jetzt, um die Richtlinien in deiner Testumgebung vorzubereiten und mit einer kleinen Pilotgruppe zu validieren, welche SITs im Chat-Alltag vielleicht zu „False Positives“ führen könnten.

Wissen kompakt: Information Protection

Bevor du Daten schützen kannst, musst du wissen, was sie sind. Ist es der Speiseplan der Kantine oder die Patentanmeldung für 2026? Das Kernstück von Information Protection sind die Sensitivity Labels (Vertraulichkeitsbezeichnungen). Sie fungieren als digitaler Stempel, der am Dokument klebt und Verschlüsselung durchsetzt.

Wir haben dazu zwei detaillierte Guides für dich:

• Grundlagen & Architektur: Wie baust du ein Label-Konzept auf?
• Automatisierung (Auto-Labeling): Wie Purview Inhalte automatisch erkennt und labelt.

Weitere Links

This post is also available in: Deutsch English