Kurzfassung
Ein Dokument ist nicht deshalb sicher, weil es in Microsoft 365 liegt. Entscheidend ist, wer es öffnen darf, wie es weitergegeben wird und was passiert, wenn jemand es versehentlich am falschen Ort teilt. Microsoft Purview bietet dafür unter anderem Vertraulichkeitsbezeichnungen und Data Loss Prevention (DLP). Bezeichnungen machen den Schutzbedarf sichtbar und können Schutzmaßnahmen mit einer Datei oder E-Mail verbinden. DLP-Regeln erkennen bestimmte Inhalte oder Bezeichnungen und können bei riskanten Aktionen warnen oder eingreifen.
Der Nutzen entsteht aber nicht durch möglichst viele Regeln. Er entsteht, wenn Mitarbeitende die Kategorien verstehen, Warnungen ernst nehmen und für berechtigte Ausnahmen einen einfachen Weg kennen. Deshalb beginnt eine tragfähige Einführung mit konkreten Daten und Arbeitsabläufen – nicht mit einer pauschalen Sperre für die gesamte Organisation.
Ein normaler Arbeitstag, ein falscher Empfänger
Ein Vertriebsteam bereitet ein Angebot vor. In der Kalkulation stehen interne Preise, die Namen von Ansprechpartnern und vertrauliche Vertragsdetails. Für die Abstimmung mit dem Kunden soll nur die fertige Angebotsfassung nach außen gehen. Im Arbeitsalltag liegen beide Dateien jedoch im selben Projektordner. Kurz vor einem Termin wird ein Freigabelink erstellt – und ausgerechnet die interne Kalkulation ausgewählt.
Das ist kein exotischer Angriff, sondern ein plausibler Fehler unter Zeitdruck. Ein Schutzkonzept sollte deshalb mehrere Fragen beantworten: Erkennt die Person am Dokument, dass es nicht für den Kunden bestimmt ist? Ist die externe Freigabe technisch eingeschränkt? Erscheint eine verständliche Warnung? Und wer kann helfen, wenn die Weitergabe ausnahmsweise doch erforderlich ist?
An diesem Beispiel wird der Unterschied zwischen Vertraulichkeitsbezeichnung und DLP deutlich. Die Bezeichnung beschreibt den Schutzbedarf des Dokuments. Eine DLP-Regel prüft eine konkrete Situation – etwa eine externe Freigabe – und reagiert darauf. Microsoft ermöglicht es, Vertraulichkeitsbezeichnungen als Bedingung in DLP-Richtlinien zu verwenden. Welche Bedingungen und Aktionen verfügbar sind, hängt vom jeweiligen Microsoft-365-Dienst und Szenario ab.
Bezeichnungen müssen eine Entscheidung erleichtern
Eine Klassifizierung mit zehn ähnlich klingenden Stufen mag auf dem Papier vollständig wirken. Für jemanden, der zwischen zwei Kundenterminen eine Datei erstellt, ist sie oft zu kompliziert. Besser ist ein überschaubares Modell mit Namen, die im Unternehmen etwas bedeuten: beispielsweise „Öffentlich“, „Intern“, „Vertraulich“ und – nur wenn wirklich nötig – eine besonders geschützte Stufe.
Wichtiger als der Name ist die Antwort auf die Frage: Wann verwende ich diese Bezeichnung? Zu jeder Stufe gehören wenige konkrete Beispiele. Ein freigegebenes Produktblatt ist anders zu behandeln als eine interne Preiskalkulation. Ein allgemeines Teamprotokoll hat einen anderen Schutzbedarf als eine Liste mit personenbezogenen Kundendaten.
Microsoft empfiehlt, Bezeichnungen aus der eigenen Klassifizierung abzuleiten, sie mit verständlichen Hinweisen zu versehen und zunächst für eine Pilotgruppe zu veröffentlichen. Je nach Konfiguration kann eine Bezeichnung beispielsweise sichtbare Markierungen oder Verschlüsselung auslösen. Sie ist also mehr als ein farbiges Etikett. Gerade deshalb müssen die Auswirkungen vor dem breiten Einsatz getestet werden. Microsoft beschreibt diese Einführungsschritte und die unterschiedlichen Lizenzanforderungen.
Bei der Festlegung sollten Fachbereiche, IT und die für Datenschutz oder Informationssicherheit verantwortlichen Personen gemeinsam entscheiden. Die IT kann Schutz technisch umsetzen. Ob eine bestimmte Kalkulation an einen Partner gehen darf, ist zuerst eine fachliche Frage.
Dateien und Arbeitsbereiche sind nicht dasselbe
Ein häufiger Denkfehler lautet: „Das Team ist als vertraulich gekennzeichnet, also sind automatisch alle Dateien darin entsprechend geschützt.“ So einfach ist es nicht. Eine Bezeichnung für eine Microsoft-365-Gruppe, ein Team oder eine SharePoint-Site steuert Einstellungen des Arbeitsbereichs. Sie überträgt nicht automatisch ihre Dateischutz-Einstellungen auf jedes enthaltene Dokument. Microsoft trennt diese beiden Anwendungsfälle ausdrücklich.
Für die Praxis bedeutet das: Prüfe sowohl den Raum als auch seine Inhalte. Ein Kundenprojekt kann beispielsweise strengere Regeln für Gäste und externe Freigaben benötigen. Innerhalb des Projekts können einzelne Dateien zusätzlich eine eigene Bezeichnung und gegebenenfalls Verschlüsselung brauchen. Beides ergänzt sich; keines ersetzt das andere.
Ebenso wenig ersetzt eine Vertraulichkeitsbezeichnung die Berechtigungsprüfung. Wenn zu viele Personen Zugriff auf eine Site haben, bleibt dieser Zugriff ein Problem – auch wenn ihre Dokumente korrekt gekennzeichnet sind.
DLP braucht einen präzisen Anlass
DLP wird schnell als Werkzeug verstanden, das „sensible Daten blockiert“. Für eine brauchbare Richtlinie ist das zu ungenau. Zuerst muss klar sein, welche Information geschützt werden soll und welche Handlung ein Risiko darstellt.
Bei einer internen Kalkulation könnte die Regel auf die Bezeichnung „Vertraulich“ reagieren, sobald die Datei extern geteilt werden soll. Bei anderen Daten können erkannte Informationstypen eine bessere Grundlage sein. Auch der Ort zählt: E-Mail, SharePoint, OneDrive, Teams-Nachrichten und verwaltete Geräte unterstützen nicht in jeder Hinsicht dieselben Bedingungen und Aktionen. Eine Regel, die in SharePoint sinnvoll ist, sollte deshalb nicht ungeprüft auf weitere Orte ausgedehnt werden. Die Microsoft-Referenz zu DLP-Richtlinien zeigt diese Unterschiede.
Formuliere jede neue Regel zunächst als einfachen Satz: „Wenn eine als vertraulich gekennzeichnete Datei an Personen außerhalb unserer Organisation freigegeben wird, soll …“ Erst danach folgt die technische Konfiguration. So lässt sich später noch nachvollziehen, welches Risiko die Regel eigentlich vermindern sollte.
Erst beobachten, dann eingreifen
Eine sofort aktivierte Sperre kann auch erwünschte Arbeit treffen: die Zusammenarbeit mit einem Steuerbüro, die Übergabe an einen Dienstleister oder einen abgestimmten Datenraum für ein Kundenprojekt. Deshalb gehört vor die Durchsetzung ein Pilot mit realistischen Beispielen.
Microsoft bietet für DLP-Richtlinien einen Simulationsmodus. Damit lassen sich Treffer und mögliche Auswirkungen auswerten, bevor eine Richtlinie regulär durchgesetzt wird. Für einen möglichst unverfälschten ersten Überblick sollte auch geprüft werden, wie die Option für Richtlinienhinweise eingestellt ist: Der Modus mit eingeblendeten Hinweisen kann sich für Nutzende anders verhalten als eine reine Beobachtung. Die konkrete Kombination aus Modus, Hinweis und Aktion gehört deshalb ausdrücklich in den Testplan.
Sieh dir bei den Treffern nicht nur die Zahl an. Drei Fragen sind hilfreicher:
- Wurde ein tatsächlich schützenswerter Inhalt erkannt?
- Welche normale Arbeit hätte die Regel erschwert?
- Fehlen bestimmte Fälle, obwohl du dort einen Treffer erwartet hättest?
Falsch positive Treffer kosten Vertrauen. Nicht erkannte Fälle vermitteln falsche Sicherheit. Beides lässt sich nur beurteilen, wenn Fachleute aus dem jeweiligen Arbeitsbereich die Ergebnisse mit der IT durchgehen.
Eine gute Warnung hilft beim richtigen Handeln
Nicht jedes Risiko braucht sofort dieselbe Reaktion. In manchen Situationen ist eine Warnung mit einer kurzen Erklärung sinnvoll. In anderen ist eine begründete Ausnahme angemessen. Bei besonders kritischen Vorgängen kann eine Blockierung erforderlich sein. Diese Abstufung sollte aus dem Schutzbedarf folgen, nicht aus dem Wunsch, möglichst streng zu wirken.
Ein Hinweis wie „Diese Aktion verstößt gegen Richtlinie 17“ hilft kaum. Besser ist: „Diese Datei ist als vertraulich gekennzeichnet. Prüfe vor der externen Freigabe, ob der Empfänger und die Dateiversion freigegeben sind.“ Dazu gehört ein klarer Kontaktweg für Fragen. Microsoft beschreibt für DLP Benachrichtigungen, Richtlinienhinweise und mögliche Übersteuerungen; ihre Verfügbarkeit unterscheidet sich je nach Anwendung und Ort.
Schulung bleibt dabei wichtig. Mitarbeitende müssen keine DLP-Konfiguration verstehen. Sie sollten aber wissen, was die Bezeichnungen im eigenen Arbeitsbereich bedeuten, wie sie eine Warnung einordnen und wie sie einen möglichen Fehlalarm melden.
Ausnahmen sind Teil des Schutzkonzepts
Eine pauschale Regel wird nie jeden Geschäftsprozess richtig abbilden. Wenn Ausnahmen nur durch informelle Umwege möglich sind, entstehen Schattenprozesse: Dateien werden umbenannt, über andere Wege versendet oder in unpassende Räume kopiert. Ein guter Ausnahmeprozess ist daher keine Schwächung der Governance, sondern ihre Voraussetzung.
Für eine Ausnahme sollten wenige Angaben genügen: Was soll geteilt werden? Mit wem? Zu welchem Zweck? Wer trägt die fachliche Verantwortung? Wie lange wird der Zugriff benötigt? Danach entscheidet eine zuständige Person, und die technische Umsetzung bleibt nachvollziehbar. Wiederholen sich gleichartige Ausnahmen, ist das ein Signal: Vielleicht passt die Regel nicht zum tatsächlichen Arbeitsablauf.
Auch ein DLP-Treffer benötigt einen Betriebsweg. Wer prüft den Vorfall? Wer spricht mit dem Fachbereich? Wann handelt es sich um einen Bedienfehler, wann um einen Sicherheitsvorfall? Ohne solche Zuständigkeiten produziert selbst eine präzise Regel lediglich Meldungen.
Ein realistischer Start in sechs Schritten
Für den Anfang genügt ein eng begrenztes Szenario. Statt alle Daten gleichzeitig schützen zu wollen, kannst du so vorgehen:
- Wähle einen wichtigen Datenfluss. Beispielsweise interne Angebotskalkulationen, die in SharePoint bearbeitet und gelegentlich mit Kundenprojekten verwechselt werden.
- Beschreibe den erlaubten Weg. Welche Fassung darf nach außen? Wer gibt sie frei? Welche Gäste oder Partner sind beteiligt?
- Lege wenige Bezeichnungen fest. Teste Namen und Beschreibungen mit den Menschen, die sie später verwenden.
- Baue eine gezielte DLP-Regel. Beschränke Ort, Bedingung und Reaktion zunächst auf dieses Szenario.
- Simuliere und korrigiere. Prüfe echte Treffer, Fehlalarme und übersehene Fälle mit dem Fachbereich.
- Schule und erweitere. Erst nach einem verständlichen Pilot werden weitere Datenarten und Abteilungen aufgenommen.
Vor dem Rollout solltest du außerdem prüfen, welche Purview-Funktionen eure Lizenzen tatsächlich abdecken. Manuelle Bezeichnungen, automatische Klassifizierung und DLP-Funktionen haben nicht zwangsläufig dieselben Voraussetzungen. Plane die Einführung anhand der benötigten Funktion – nicht allein anhand eines Produktnamens.
Woran du erkennst, dass es funktioniert
Die Zahl angelegter Bezeichnungen oder Richtlinien ist noch kein Erfolg. Aussagekräftiger ist, ob vertrauliche Informationen im Alltag seltener falsch geteilt werden und berechtigte Zusammenarbeit weiterhin funktioniert.
Beobachte dafür beispielsweise, wie häufig Warnungen berechtigt waren, welche Ausnahmen beantragt wurden, wie lange ihre Bearbeitung dauerte und welche Fragen beim Support wiederkehren. Frage Pilotgruppen auch direkt, ob sie die Bezeichnungen ohne Nachschlagen unterscheiden können. Wenn regelmäßig dieselbe Kategorie missverstanden wird, liegt die Lösung möglicherweise in einem besseren Namen oder Beispiel – nicht in einer weiteren Regel.
Der CloudLights-Blick darauf ist pragmatisch: Datenschutz und Zusammenarbeit stehen nicht automatisch im Widerspruch. Gute Leitplanken zeigen den sicheren Weg, bevor ein Fehler passiert. Sie greifen dort ein, wo ein konkretes Risiko besteht, und lassen nachvollziehbare Ausnahmen zu. So wird aus Purview kein schwer verständlicher Regelkatalog, sondern ein Werkzeug, das Menschen bei ihrer täglichen Arbeit unterstützt.
Du möchtest wissen, wo in deiner Microsoft-365-Umgebung ein sinnvoller Einstieg liegt? CloudLights hilft dir, Datenflüsse und Schutzbedarf zu ordnen, einen überschaubaren Pilot aufzusetzen und die Ergebnisse gemeinsam mit den Fachbereichen auszuwerten. Melde dich bei uns, wenn du Vertraulichkeitsbezeichnungen und DLP praxisnah einführen möchtest.
Mit Unterstützung von KI erzeugt.
