Microsoft Purview Information Protection

Management Summary – Warum Labels + Policies + Automation heute Pflicht sind

Ich erinnere mich noch gut an Zeiten, in denen vertrauliche Dokumente mit einem dicken roten Stempel „GEHEIM“ versehen in der Aktenschublade verschwanden. Heute, im Zeitalter von Microsoft 365 und weltweiter Collaboration, funktioniert dieser analoge Schutz nicht mehr. Informationen fließen digital rund um die Uhr – über E-Mails, Cloudspeicher, Teams-Chats und mobile Endgeräte. Sensitivity Labels (Vertraulichkeitsbezeichnungen) sind zur Pflicht geworden, um den Überblick und die Kontrolle über sensible Daten zu behalten. Warum? Weil jedes Unternehmen unter dem wachsamen Auge von DSGVO, Kundenerwartungen und Cyber-Bedrohungen steht. Ein Datenleck kann heute nicht nur peinlich, sondern richtig teuer werden – man denke nur an Strafzahlungen und Imageverlust nach einer Datenschutzverletzung.

Als erfahrener M365-/Security-Architekt habe ich in zahlreichen Projekten erlebt, dass Labels + Policies + Automation wahre Game-Changer sind. Sensitivity Labels klassifizieren Dokumente und E-Mails nach Vertraulichkeitsstufe, Label Policies sorgen dafür, dass diese Labels auch wirklich bei den richtigen Anwendern ankommen (und vielleicht sogar verpflichtend genutzt werden), und Automation – etwa automatisches Erkennen und Schützen vertraulicher Inhalte – fängt das ab, was dem Menschen durch die Lappen geht. Gemeinsam bilden diese Bausteine einen Schutzschild, der gleichzeitig die Zusammenarbeit nicht ausbremst. Im Gegenteil: Mit gut konfigurierten Labels können Mitarbeiter bedenkenlos und effizient zusammenarbeiten, weil sie wissen, dass z.B. ein als „Vertraulich“ gekennzeichnetes Dokument automatisch nur intern bleibt oder verschlüsselt versendet wird.

Nutzenbild: Das Nutzenprofil von Microsoft Purview Information Protection (früher bekannt als Azure Information Protection, AIP) lässt sich in drei Worten zusammenfassen: Wissen, wer was darf. Dank Sensitivity Labels weiß die Organisation jederzeit, wo ihre kritischen Daten liegen und wie sie genutzt werden. Versehentliche Datenabflüsse – etwa die vertrauliche Preisliste, die aus Versehen an den falschen Empfänger gemailt wird – werden verhindert, weil solche Inhalte proaktiv erkannt und geschützt werden (z.B. durch automatische E-Mail-Verschlüsselung oder Warnhinweise). Quick Wins gibt es obendrein: Schon mit wenigen, klug gewählten Labels (z.B. Öffentlich, Intern, Vertraulich, Streng Vertraulich) und einer Handvoll Regeln können Unternehmen erste Erfolgserlebnisse erzielen. Beispielsweise kann man sofort erreichen, dass alle neuen Teams-Bereiche und SharePoint-Seiten eine Basisklassifizierung erhalten – damit wird direkt die externe Freigabe unterbunden, wo sie nicht gewünscht ist. Oder man startet mit einem Pilot für Auto-Labeling in Exchange Online: E-Mails, die Kreditkartennummern enthalten, werden automatisch als „Vertraulich“ markiert und verschlüsselt. Solche Maßnahmen zeigen schnell Wirkung und schaffen Vertrauen ins Projekt.

Lizenzierungsüberblick: Viele fragen sich anfangs, welche Lizenzen für Purview Information Protection nötig sind. Die gute Nachricht: Grundlegende Funktionen wie manuelles Klassifizieren und Labeln sind bereits in den gängigen Microsoft 365 Plänen (E3, Business Premium etc.) enthalten. Jeder Mitarbeiter mit Office 365/M365 kann also – lizenztechnisch – Dokumente manuell als vertraulich markieren und geschützte Inhalte lesen. Die erweiterte Magie (automatisches Labeling durch Policies, der AIP-Scanner für lokale Daten oder KI-gestützte Klassifikatoren) kommt allerdings mit den höherwertigen Lizenzen. Microsoft 365 E5 (bzw. das Compliance Add-on für E3) schaltet die Premium-Funktionen frei: automatische Beschriftung nach definierten Regeln, trainierbare Klassifikatoren, Double Key Encryption und mehr. Keine Sorge, wir steigen in Kapitel 8 noch tiefer in die Lizenzthemen ein – inklusive einer Übersichtstabelle, welcher Plan welche Features beinhaltet.

Im Folgenden erwarten Sie praxisnahe Einblicke in die Architektur und Funktionsweise von Microsoft Purview Information Protection (PIP), gewürzt mit Erfahrungen aus dem Beratungsalltag und einer Prise Humor. Von der technischen Architektur über Best Practices im Label-Design bis zum 12-Wochen-Rollout-Plan – dieser Artikel ist Ihr Werkzeugkasten, um Informationsschutz mit Microsoft-Technologien erfolgreich einzuführen. Los geht’s!

1. Architektur von PIP: Sensitivity Labels, Label Policies, AIP, Auto-Labeling, Scanner, Endpoint, Power BI, Abgrenzung zu DLP

Überblick: Bausteine der Informationsschutz-Architektur

Microsoft Purview Information Protection (PIP) setzt sich aus mehreren Bausteinen zusammen, die nahtlos ineinandergreifen:

• Sensitivity Labels: Die eigentlichen Vertraulichkeitskennzeichnungen, die an Dateien, E-Mails und andere Inhalte angehängt werden. Ein Label ist mehr als nur ein digitaler Sticker – es trägt Informationen über die Sensitivititätsstufe (z.B. „Öffentlich“, „Intern“, „Vertraulich“, „Streng Vertraulich“) und kann Schutzmaßnahmen auslösen (wie Verschlüsselung oder Wasserzeichen). Labels werden zentral im Purview-Compliance-Portal definiert und mit Einstellungen versehen.
• Label Policies (Bezeichnungsrichtlinien): Diese Richtlinien regeln die Bereitstellung der Labels an die Endanwender. Über Label Policies lege ich als Admin fest, welche Benutzer oder Gruppen welche Labels zur Verfügung gestellt bekommen. Hier kann ich auch Default-Labels definieren (z.B. erhalten alle neuen Dokumente standardmäßig das Label „Intern“) oder erzwingen, dass E-Mails mindestens ein Label haben müssen, bevor sie versendet werden. Die Label Policies sind also das Bindeglied zwischen den abstrakten Labels und der Praxis beim User.
• Azure Information Protection (AIP) & Unified Labeling: Historisch betrachtet stammt die Technik hinter Sensitivity Labels aus Azure Information Protection. Falls Ihnen der Begriff AIP noch geläufig ist: Das war der Vorgänger von Purview Information Protection. Heute spricht man von Unified Labeling, weil Microsoft die ehemals getrennten Labeling-Welten (AIP für Azure, und separate Klassifizierungen in Office 365) unter einem Dach zusammengeführt hat. Praktisch bedeutet das, dass Labels jetzt im Microsoft 365 Compliance Center erstellt und verwaltet werden, und nicht mehr in einem separaten Azure-Portal. Der gute alte AIP-Client (auch bekannt als Unified Labeling Client) ist inzwischen „zur Ruhe gesetzt“ – Office, Outlook & Co. haben die Labeling-Funktion direkt eingebaut. Nur für Spezialfälle wie die AIP-Scanner-Installation oder den Schutz von Dateien außerhalb von Office gibt es den Client noch als Option.
• Auto-Labeling (automatische Beschriftung): Ein Kernstück der modernen PIP-Architektur ist die Möglichkeit, Labels automatisch anzuwenden. Das erfolgt – je nach Szenario – entweder service-seitig (durch Cloud-Dienste) oder client-seitig (direkt in den Office-Anwendungen auf dem Endgerät). Service-seitiges Auto-Labeling bedeutet, dass z.B. Exchange Online oder SharePoint Online im Hintergrund nach sensiblen Inhalten suchen und passende Labels vergeben. Beispielsweise kann Exchange eingehende/ausgehende E-Mails scannen und automatisch ein Label „Externe vertraulich – verschlüsselt“ anwenden, wenn bestimmte Schlüsselwörter oder Datentypen erkannt werden. Client-seitiges Auto-Labeling hingegen passiert direkt, während der Nutzer an einem Dokument arbeitet: Die Office-App (Word, Excel, PowerPoint) erkennt z.B. eine Personalausweisnummer und schlägt dem Nutzer vor, das Label „Streng Vertraulich“ zu setzen. Oder es wird sogar vollautomatisch gesetzt, falls so konfiguriert. Diese Automatisierung ist essentiell, um menschliche Fehler auszubügeln und eine große Datenmenge effizient zu klassifizieren – allerdings sind die fortgeschrittenen Auto-Labeling-Funktionen, wie bereits im Management Summary angedeutet, lizenztechnisch erst ab E5 freigeschaltet.
• AIP Scanner (lokaler Scanner): Daten liegen nicht nur in der Cloud – viele Organisationen haben nach wie vor File Shares, On-Premises-Datenbanken oder Legacy-Dateisysteme voller sensibler Dateien. Hier kommt der Microsoft Purview Information Protection Scanner (oft einfach AIP-Scanner genannt) ins Spiel. Er ist ein auf Windows Server installierter Dienst, der im Auftrag der Purview-Plattform lokale Dateien durchsuchen und klassifizieren kann. Man kann dem Scanner z.B. sagen: „Durchsuche das Fileshare X:\Abteilung\HR nach allen Dateien mit Personaldaten und wende das Label ‚Vertraulich‘ an“. Der Scanner nutzt dieselben Label und Erkennungsregeln, wie im Compliance Center definiert. Wichtig: Der Scanner kann Dateien auch schützen (verschlüsseln), nicht nur markieren. Allerdings sollte man mit Massenverschlüsselung vorsichtig sein – der Scanner ist ein scharfes Schwert, das gut getestet und kalibriert werden will, bevor man es auf tausende Dateien loslässt.
• Endpoint-Integration: Unter Endpunkten verstehen wir hier v.a. Windows-Clients (aber auch Macs und mobile Geräte), auf denen Informationen erzeugt oder verarbeitet werden. Die Integration von PIP in Endpunkte zeigt sich z.B. daran, dass ein Benutzer in Windows Explorer per Rechtsklick ein Label auf eine Datei anwenden kann, oder dass Word auf dem iPhone ein Label „Vertraulich“ anzeigt. Gerade Windows 10/11 mit der integrierten Sensitivity-Label-Unterstützung ermöglicht es, dass auch außerhalb der Office-Apps Labels sichtbar bleiben (etwa als Spalte im Explorer) und geschützte Dateien nur von berechtigten Apps geöffnet werden können. Zudem gibt es eine Schnittstelle zur Endpoint Data Loss Prevention (Endpoint DLP): Diese kann z.B. erkennen, wenn ein Benutzer versucht, eine streng vertrauliche Datei auf einen USB-Stick zu kopieren, und diesen Vorgang blockieren oder protokollieren. Hier verschwimmen die Grenzen zu DLP schon etwas, aber dazu gleich mehr.
• Power BI: Nicht zu vergessen: Auch Power BI als Analyse- und Reporting-Plattform integriert Sensitivity Labels. Berichte, Dashboards und Datensätze können mit Labels versehen werden, damit vertrauliche Daten nicht ungeschützt über Pivot-Table-Exporte oder Screenshots wandern. Exportiert ein Benutzer z.B. einen als „Vertraulich“ gelabelten Bericht nach Excel, so wird die Excel-Datei automatisch mit dem gleichen Label (und Schutz) versehen, das im Power-BI-Bericht gesetzt war. Das verhindert, dass jemand sensible Kennzahlen mal eben als ungeschützte Datei verschickt und damit die Schutzpolitik umgeht.
• Microsoft Information Protection SDK: Im Hintergrund all dieser Funktionen schlägt das Herz der Architektur, das MIP-SDK. Es ermöglicht Drittanbieter-Anwendungen, die Labels und Schutzmechanismen zu verstehen und anzuwenden. So haben z.B. PDF-Programme (Adobe Acrobat ab einer bestimmten Version) das SDK integriert, um PDF-Dokumente öffnen zu können, die mit Sensitivity Labels verschlüsselt wurden. Auch Backup-Lösungen oder Dritthersteller-Apps können über das SDK Labels auslesen und berücksichtigen. Architektonisch sorgt das SDK dafür, dass der Schutz wirklich mit den Daten mitreist, unabhängig von der Anwendung.

Abgrenzung zu DLP (Data Loss Prevention)

Nun zur oft gestellten Frage: Was ist der Unterschied zwischen Sensitivity Labels und DLP? Beide zielen darauf ab, Datenverluste zu verhindern, aber sie tun dies auf unterschiedliche Weise und an unterschiedlichen Stellen.

Sensitivity Labels (PIP) sind objektbezogen: Sie reisen mit dem Dokument oder der Mail. Einmal gekennzeichnet und (optional) verschlüsselt, trägt die Datei diese Eigenschaften permanent bei sich. Man könnte sagen, Labels sind wie ein eingebauter Sicherheitsgurt für die Daten selbst. Sie wirken immer, unabhängig vom Ort: Eine als „Vertraulich“ gelabelte PDF bleibt vertraulich, egal ob sie auf SharePoint liegt, per E-Mail versendet oder auf einen USB-Stick kopiert wird. Ohne Berechtigung sieht niemand den Klartext.

DLP hingegen ist situationsbezogen: DLP-Policies überwachen bestimmte Kanäle und Vorgänge und greifen ein, wenn ein definierter Regelverstoß erkannt wird. Zum Beispiel: „Verhindere, dass jemand eine Kreditkartennummer per Teams an einen externen Chat schickt“. DLP schaut also quasi als Schutzengel über die Schulter der Benutzer und sagt „Stopp, das darfst du nicht tun“, während Labels direkt am Dokument kleben und sagen „Ich lass mich nur von A, B, C lesen“.

Zusammenspiel: Optimal setzt man beide Technologien ein. Ein paar Beispiele verdeutlichen das Zusammenspiel:

• Eine DLP-Regel kann das Vorhandensein bestimmter Labels als Bedingung nutzen. Z.B.: „Wenn ein Dokument das Label ‚Streng Vertraulich‘ hat, darf es nicht auf externe Cloud-Dienste hochgeladen werden“ (Endpoint DLP kann das auf dem Client erkennen und blockieren). Hier liefert das Label also den Kontext für DLP.
• Umgekehrt kann DLP helfen, fehlende Labels aufzuspüren. Eine DLP-Policy kann z.B. sagen: „Wenn ich in einer Datei Personendaten finde und sie hat kein Vertraulichkeits-Label, dann warne den Benutzer oder label die Datei nachträglich automatisch“. So fungiert DLP als Auffangnetz, falls ein sensibles Dokument mal ungelabelt bleiben sollte.
• DLP greift vor allem an Stellen, wo Labels nicht direkt wirken: z.B. beim Kopieren aus Anwendungen, beim Abfluss über Netzwerkkanäle oder bei Schnittstellen (USB-Geräte, Drucker). Labels können zwar Druck oder Kopieren untersagen, aber DLP kann bereits auf Protokollebene ansetzen, um etwa das Hochladen auf eine unbekannte Website zu blockieren – selbst wenn die Datei kein Label hat.

Kurz gesagt: Labels sind proaktive, persistente Schutzmechanismen, während DLP reaktive, kontextuelle Schutzmaßnahmen bietet. Beide gemeinsam ergeben eine runde Lösung für modernen Informationsschutz. In den nächsten Kapiteln konzentrieren wir uns aber hauptsächlich auf die Label-Seite (PIP), behalten DLP jedoch gedanklich als hilfreichen Kollegen im Hinterkopf.

2. Funktionsprinzip: Labeltypen, Schutzvarianten, Durchsetzungspunkte, Benutzererlebnis

Labeltypen und Anwendungsbereiche

Nicht alle Labels sind gleich – je nach Anwendungsbereich unterscheidet man verschiedene Label-Typen (genauer gesagt: Geltungsbereiche, engl. Scopes). In Microsoft Purview PIP kann ein Sensitivity Label für unterschiedliche Objekttypen gelten:

• Dateien & E-Mails: Der klassische Anwendungsfall. Diese Labels können auf Office-Dokumente, PDFs, Bilder, E-Mails etc. angewendet werden. Sie enthalten Einstellungen wie Verschlüsselung, Markierung und erlaubte Aktionen. Beispiel: Ein Label „Öffentlich“ hat vielleicht gar keine Schutzmaßnahmen, während „Streng Vertraulich“ Verschlüsselung + Wasserzeichen beinhaltet. Dies ist der am weitesten verbreitete Labeltyp.
• Gruppen & Sites: Hier sprechen wir von Container-Labels. Diese werden auf ganze SharePoint-Websites, Teams oder Microsoft 365-Gruppen angewendet. Ein solches Label steuert nicht direkt den Inhalt der Dateien darin, sondern die Rahmenbedingungen des Containers. Etwa: Dürfen Gäste eingeladen werden? Ist die Teams-Site von extern durchsuchbar? Welche SharePoint-Linkfreigaben sind erlaubt? Container-Labels helfen, Kollaborationsräume entsprechend ihrer Sensitivität abzuschotten. Beispiel: Ein Team mit Label „Vertraulich – Intern“ lässt keinen Gastzugriff zu und erlaubt nur interne Freigaben – egal, was die Einzeldateien für Labels haben.
• Besprechungen (Meetings): Relativ neu ist die Möglichkeit, Sensitivity Labels auch für Meetings zu nutzen. Damit lassen sich z.B. für ein „Streng Vertraulich“-Meeting bestimmte Teams-Funktionen erzwingen oder sperren: z.B. Lobby-Einstellungen, Aufzeichnungsverbote oder Wasserzeichen im Videostream. Wichtig: Für einige dieser Features ist Teams Premium erforderlich. Die Labels selbst dienen hier quasi als „Meeting-Vorlage“ für Sicherheitsoptionen. Wenn ich als Organisator ein Meeting mit Label X ansetze, können Teilnehmer sehen, dass es vertraulich ist, und Funktionen wie Chat oder Bildschirmfoto sind ggf. eingeschränkt – je nach Policy.
• Azure/Purview Data Map: Der Vollständigkeit halber: Es gibt auch Labels, die auf strukturierte Daten (Datenbankfelder, Datensätze) angewendet werden können – via Purview’s Data Map. Diese Funktion befindet sich Stand November 2025 in der Preview-Phase. Im Grunde kann man damit auch Daten in SQL-Datenbanken, Azure Cosmos DB etc. klassifizieren, um im Data Catalog den Sensitivitätsgrad zu sehen. Das ist eher ein Spezialthema für Data Governance als für Endanwender.
• Retention Labels vs. Sensitivity Labels: An dieser Stelle sei erwähnt, dass es in Microsoft 365 auch sogenannte Aufbewahrungsbezeichnungen gibt (Retention Labels). Diese dienen jedoch einem anderen Zweck (nämlich der Regulierung, wie lange Daten aufgehoben oder gelöscht werden) und sind Teil von Purview Data Lifecycle Management. Nicht verwechseln: Man kann durchaus beide Arten auf dasselbe Dokument anwenden (z.B. „Streng Vertraulich“ und „7 Jahre aufbewahren“). Hier geht es im Folgenden aber rein um die Vertraulichkeits-Labels.

Schutzvarianten und Rechte

Ein Sensitivity Label kann unterschiedliche Schutzmaßnahmen enthalten – oder auch gar keine (dann spricht man manchmal von einem reinen Klassifizierungs-Label). Die wichtigsten Schutzvarianten sind:

• Verschlüsselung (Encryption): Hierbei wird das Dokument oder die E-Mail verschlüsselt und es werden Zugriffsrechte eingebettet. Man legt im Label fest, wer (Benutzer oder Gruppen) die Inhalte lesen oder bearbeiten darf und welche Aktionen erlaubt sind (Drucken, Weiterleiten, Kopieren etc.). Die technische Grundlage dafür liefert Azure Rights Management (Teil von Microsoft Purview). Wichtig zu wissen: Entweder verwaltet Microsoft den Schlüssel (Standardfall), oder der Kunde bringt eigene Schlüssel ein (Bring Your Own Key) bzw. nutzt Double Key Encryption (zwei Schlüssel: einer bei Microsoft, einer beim Kunden; beide werden zum Entschlüsseln benötigt). Verschlüsselung ist der stärkste Schutz, da sie die Daten selbst unlesbar für Unbefugte macht. Nachteil: Man muss genau planen, wer den Schlüssel bekommt, sonst sperrt man sich im Worst Case selbst aus.
• Inhaltsmarkierung (Content Marking): Damit sind visuelle Markierungen wie Header, Footer, Wasserzeichen gemeint. Ein Label kann z.B. vorschreiben, dass jede Seite eines Word-Dokuments den Schriftzug „Über vertrauliche Informationen – nicht weitergeben“ im Kopf oder als diagonal gedrucktes Wasserzeichen enthält. Diese Markierungen schrecken neugierige Leser ab und sensibilisieren alle Nutzer ständig für den Schutzbedarf. Sie haben jedoch keine technische Zugriffsbeschränkung an sich – sie sind eher das Warnschild, während die Verschlüsselung das Schloss ist.
• Nur Klassifizierung (kein Schutz): Man kann Labels auch nutzen, um Informationen nur zu klassifizieren, ohne automatische Schutzaktion. Dann dient das Label rein der Kenntlichmachung und Protokollierung. Das klingt erstmal nutzlos, ist aber in der Praxis manchmal erwünscht, etwa für ein Label „Öffentlich“ oder „Intern“. Diese Inhalte brauchen keine Verschlüsselung, aber man möchte sie dennoch markieren, um z.B. später in Logs oder Berichten zu sehen, wie die Verteilung der Klassifizierungen ist. Und wer weiß – vielleicht entscheidet man sich später doch, auf alle „Intern“-Dokumente eine Verschlüsselung draufzupacken; dann hat man sie über die Labels schon identifiziert.
• Benutzerdefinierte Berechtigungsvergabe: Eine Sonderform der Verschlüsselung ist es, dem Endanwender das Festlegen der Berechtigungen zu überlassen. Microsoft nennt das manchmal „Benutzer definierte Berechtigungen“. Statt dass das Label fixe Gruppen enthält, die z.B. lesen dürfen, kann man konfigurieren, dass beim Anwenden des Labels ein Dialog aufpoppt, wo der Nutzer selbst Empfänger hinzufügen kann. Beispiel: Label „Verschlüsselt für externe Partner“ – der Anwender wählt aus, welche externe Mailadresse Zugriff bekommt. Dieses Feature wird allerdings dosiert eingesetzt, da es zwar Flexibilität gibt, aber auch riskant sein kann (User könnten versehentlich zu viel freigeben). Oft besser: feste Gruppen definieren.
• Beschränkte Funktionsfähigkeit / Device Policies: Ein eher indirekter Schutzaspekt: Man kann über Labels auch gewisse Funktionsbeschränkungen steuern. Beispiel: Ist ein Dokument als „Streng Vertraulich“ klassifiziert, könnte die Policy dafür sorgen, dass dieses Dokument nur auf Firmengeräten geöffnet werden darf (via Conditional Access und Device Management). Oder in einem „Streng Vertraulichen“ Team werden Gäste ausgeschlossen wie oben beschrieben. Diese Varianten sind Kombinationen aus Purview Labels und anderen Diensteinstellungen (Conditional Access, Teams-Einstellungen) und zeigen, dass der Schutz nicht nur im Dokument selbst liegt, sondern auch in der Umgebung.

Durchsetzungspunkte in der Praxis

Wo werden Sensitivity Labels überall durchgesetzt? Quer durch die Microsoft-Umgebung. Ein paar wichtige Stationen:

• Office-Anwendungen: Word, Excel, PowerPoint (sowohl Desktop, Web als auch Mobile Apps) sind label-aware. Das heißt, ich sehe in der Toolbar die Schaltfläche „Vertraulichkeit“ (bzw. „Sensitivity“ in englischer UI) und kann dort Labels anwenden. Wird ein Label mit Verschlüsselung gewählt, verschlüsselt Office das Dokument direkt beim Speichern. Gleichzeitig werden bei entsprechender Konfiguration auch Header/Wasserzeichen ins Dokument eingefügt. Die Office-Programme respektieren auch Label-Vorgaben: Wenn z.B. eine Excel-Datei als „Read Only“ markiert wurde (per Label, das Bearbeitung verbietet), dann greift der Schreibschutz. Für die Nutzer ist das Erlebnis mittlerweile nahtlos, denn wie erwähnt – es ist kein extra Plugin mehr nötig. Erwähnenswert: Auch Outlook als E-Mail-Client unterstützt Labels. Dort kann ich beim Verfassen einer Mail ein Label wählen, was ggf. OME-Verschlüsselung und „Nicht Weiterleiten“ aktiviert.
• Exchange Online (E-Mail-Transport): Abseits vom Outlook-Client spielt auch der Mail-Server eine Rolle. Exchange Online kann – mithilfe von Exchange-Transportregeln oder Purview Auto-Label Policies – E-Mails beim Versand prüfen und nachträglich ein Label aufstempeln. Z.B. definieren wir: „Wenn eine Mail an extern geht und das Wort ‚Vertraulich‘ im Betreff steht, wende automatisch das Label ‚Vertraulich‘ an“. Zudem erkennt Exchange eingehende geschützte Mails und sorgt dafür, dass sie nur den berechtigten Empfängern angezeigt werden (das passiert im Zusammenspiel mit Azure RMS). Aus Anwendersicht merkt man davon wenig – außer, dass Mails manchmal mit einem Info-Hinweis ankommen: „Diese Nachricht ist durch eine Vertraulichkeitsbezeichnung geschützt“.
• SharePoint Online / OneDrive: Beim Speichern von Dateien in SharePoint oder OneDrive bleiben Labels grundsätzlich erhalten. Wichtig: Dank einer Verbesserung der letzten Jahre kann SharePoint inzwischen verschlüsselte Dateien verwalten – das System entschlüsselt sie im Speicher temporär, damit Suchindex, Vorschau, Co-Authoring etc. funktionieren. Dafür musste man früher in SharePoint explizit eine Integration aktivieren (Stichwort „AIP und SPO Integration“); heute ist das in den meisten Tenants Standard oder zumindest einfach einzuschalten. Durchsetzungspunkt heißt hier: Wenn eine Datei mit Label X hochgeladen wird, kann SharePoint über Policies reagieren (z.B. Label-Mismatch-Erkennung: Liegt eine „Streng Vertrauliche“ Datei in einer als „Öffentlich“ markierten Site, gibt es einen Alarm). Außerdem gibt es die Möglichkeit, Standard-Labels für Bibliotheken zu setzen (E5-Funktion) – damit erhalten alle neu hochgeladenen Dateien automatisch ein vordefiniertes Label, sofern der User nicht selbst ein strengeres vergibt.
• Microsoft Teams: Teams greift im Kern auf die genannten Dienste (SharePoint für Dateien, Exchange für Chat/Historie) zurück. Aber es gibt auch eigene Drehschrauben: Zum einen natürlich die Team- bzw. Gruppen-Labels (Container), die wir schon behandelt haben. Zum anderen werden meeting-bezogene Labels in Teams umgesetzt: Hat ein Meeting das Label „Vertraulich“, kann Teams automatisch bestimmte Features ausschalten (Aufnahme deaktivieren, Copy/Paste im Chat verhindern etc.). Diese Durchsetzung erfordert, wie gesagt, teils das Teams-Premium-Add-on. Generell ist Teams das Schaufenster, wo Nutzer die Wirkung der Labels oft zuerst spüren: Plötzlich kann man in einem streng vertraulichen Team keinen externen Teilnehmer hinzufügen, oder eine im Chat geteilte Datei ist für manche schreibgeschützt – all das ist PIP in Aktion.
• Windows/Endpoint: Auf Windows-Desktops zeigt sich die Durchsetzung z.B. darin, dass der Windows Explorer eine Spalte „Bezeichnung“ anzeigen kann. Das Betriebssystem kennt die Label-Metadaten. Wenn jemand versucht, eine geschützte Datei mit einer nicht berechtigten Anwendung zu öffnen, wird das scheitern (z.B. Notepad kann mit einer verschlüsselten DOCX nichts anfangen). Über die Endpoint-DLP-Integration, die wir schon angeschnitten haben, kann Windows sogar Vorgänge mit sensiblen Inhalten erkennen und blockieren (z.B. Upload im Browser). Hierzu muss aber die Purview-DLP-Funktion konfiguriert sein. Rein für PIP gilt: Der Endpunkt respektiert die Label-Rechte, aber er „verhindert“ ohne DLP nicht unbedingt aktiv den Abfluss – er lässt nur verschlüsselte Inhalte unzugänglich für Unbefugte.
• Mobile Apps: Auch auf iOS/Android gelten Labels. Man kann in der Word-App auf dem Handy Labels setzen und sehen. Allerdings sind die mobilen Office-Apps (und Viewer) naturgemäß etwas schlanker. Ein Beispiel aus der Praxis: PDFs, die verschlüsselt wurden, lassen sich nur mit der richtigen App öffnen – auf dem PC über Acrobat (mit MIP-Plugin) oder Edge-Browser, auf Mobilgeräten ggf. über die AIP-Viewer-App (falls noch genutzt) oder gar nicht. Hier merkt man dann: Ja, Schutz ist da, aber Convenience kann leiden, wenn eine Plattform das Labeling nicht voll unterstützt. Zum Glück holt Microsoft hier stetig auf.
• Drittanbieter-Anwendungen: Dank MIP-SDK gibt es immer mehr Dritt-Apps, die Labels unterstützen. Öffnet man z.B. eine geschützte Mail in Gmail, wird man über einen Web-Viewer zum OME-Portal geführt, wo man nach Login lesen kann. Oder ein Dritthersteller-DMS, das das SDK integriert, kann Dokumente direkt mit Label speichern. Dennoch: Außerhalb der Microsoft-Welt gibt es natürlich Grenzen. Ein Hardcore-Beispiel: Ich drucke den geschützten Inhalt aus oder fotografiere den Bildschirm – dagegen hilft dann nur noch Security Awareness oder im Extremfall Informationsschutz auf physischer Ebene.

Benutzererlebnis und Adoption

Das beste Schutzsystem taugt wenig, wenn die Benutzer es umgehen oder frustriert sind. Das Benutzererlebnis stand bei Microsofts Entwicklung von Purview Information Protection daher mit im Fokus. Aus meiner Sicht sind die folgenden Punkte entscheidend:

• Transparenz und Integration: Für den Anwender läuft das meiste automatisch ab. Labels sind heute in Office integriert, erscheinen als Teil der normalen Symbolleiste. Viele Anwender merken kaum, dass im Hintergrund komplizierte Verschlüsselung abläuft, weil es einfach funktioniert – solange sie ihren Unternehmens-Account nutzen, öffnen sich geschützte Dokumente nahtlos. Das Motto ist: Security by default, Convenience by Design. Idealerweise bekommt der Nutzer höchstens mal einen Hinweis wie „Das Dokument wurde als Intern klassifiziert“, ansonsten arbeitet er weiter wie gewohnt.
• Policy Tips und Schulung: Wenn etwas Ungewöhnliches passiert (z.B. ein Auto-Labeling schlägt an und weist auf eine Kreditkartennummer hin), erhält der User einen Policy Tip – ein kleines Pop-up oder Info-Banner, das erklärt, warum jetzt z.B. das Label geändert wurde oder er es noch setzen soll. Gut gemachte Texte wie „Ihre Organisation schützt diesen Inhalt automatisch, weil sensible Daten erkannt wurden“ helfen, das Vertrauen zu erhöhen. Trotzdem: Nichts ersetzt eine Nutzerschulung. In Trainings sollte erklärt werden, was die Labels bedeuten, wie man sie anwendet und warum das wichtig ist. Mit ein paar knackigen Beispielen („Was passiert, wenn du versehentlich eine Gehaltsliste an alle mailst? Mit PIP wäre das nur halb so wild…“) kann man hier punkten.
• Performance und Zuverlässigkeit: Anfangs (vor einigen Jahren) gab es Bedenken, Verschlüsselung könnte Office langsam machen oder Dokumente korrupt. Diese Kinderkrankheiten hat Microsoft weitgehend ausgebügelt. Heute ist das Speichern mit Label praktisch genauso schnell wie ohne, und der gleichzeitige Zugriff mehrerer Benutzer auf ein geschütztes Dokument (Co-Authoring) funktioniert in M365 mittlerweile, sofern richtig konfiguriert. Wichtig ist, dass die „Supportkette“ bereit ist: Helpdesk sollte wissen, was zu tun ist, wenn ein Anwender meldet „Ich kann Datei X nicht öffnen“ (erstmal fragen: hat die Datei ein Label? Ist der User berechtigt?). Solche Support-Fälle sind aber erstaunlich selten, wenn PIP sauber ausgerollt wurde.
• So wenig Friktion wie möglich: Mein Tipp: Die Anzahl der Labels schlank halten und die Default-Einstellungen sinnvoll wählen. Benutzer sollten nicht bei jeder E-Mail 10 Optionen durchklicken müssen. Lieber mit 3-5 Labels starten und schauen, wie die Nutzer klarkommen. Das Labeling sollte höchstens minimalen Mehraufwand bedeuten – z.B. ein Klick beim Erstellen eines Dokuments, mehr nicht. Alles, was automatisch gehen kann, sollte man automatisieren (z.B. Default-Label, Auto-Label-Regeln). So bleibt das Erlebnis positiv: „Das System hilft mir, statt mich zu nerven.“
• Feedback-Kanal: Es lohnt sich, einen einfachen Weg für Nutzer-Feedback einzurichten, gerade in der Einführungsphase. Wenn User verstehen, warum eine bestimmte Mail jetzt nicht weitergeleitet werden konnte oder warum ihr Team kein Gast hinzufügen darf, werden sie es akzeptieren. Wenn nicht, besteht die Gefahr von Workarounds (dann wird halt doch WhatsApp genommen, um die Datei zu teilen…). Daher sollte man offen für Fragen sein und ggf. Policies nachjustieren, wenn sie unrealistisch streng sind.

Insgesamt nehme ich wahr, dass bei gut gemachter Einführung die Akzeptanz hoch ist. Viele Mitarbeiter finden es sogar gut, dass ihre Firma sich um Schutz kümmert – es signalisiert Professionalität. Und wenn mal was schiefgeht (z.B. falsches Label erwischt), ist es wichtig, einfache Möglichkeiten zu bieten, das zu korrigieren (Label wechseln, Admin fragen können etc.). PIP soll ja den Arbeitsfluss schützen, nicht behindern.

3. Identifikation schützenswerter Inhalte: Sensitive Info Types, EDM, Klassifikatoren, RegEx, mehrsprachige Inhalte, Qualitätssicherung

Bevor man Auto-Labeling und Schutz anwenden kann, muss man definieren können, was überhaupt schützenswert ist. Microsoft Purview stellt dafür verschiedene Werkzeuge zur Inhaltsanalyse bereit:

• Sensitive Information Types (SIT): Das sind vordefinierte oder selbst erstellte Muster, die nach bestimmten Datentypen suchen. Microsoft liefert über 300 davon out-of-the-box mit (z.B. Kreditkartennummer, IBAN, Personalnummer, medizinische Diagnoseschlüssel). Ein SIT besteht meist aus Regex-Patterns, Kombinationsregeln und ggf. Referenzlisten. Beispiel: Der SIT „Deutsche Personalausweisnummer“ schaut nach einem 10-stelligen alphanumerischen Pattern und erwartet in der Nähe Wörter wie „Perso“ oder „Personalausweis“. SITs geben einen Confidence-Wert aus (hoch/mittel/niedrig), je nachdem wie eindeutig der Treffer war. Admins können eigene SITs definieren, wenn z.B. ein spezielles Aktenzeichen oder eine Kundennummer erkannt werden soll.
• Exact Data Match (EDM): Manche Daten sollen nur dann als Treffer gelten, wenn sie genau in einer bekannten Liste vorkommen. Hierfür gibt es EDM: Man lädt z.B. eine Tabelle mit echten Kundendaten (z.B. Sozialversicherungsnummern) als geschützten Hash ins M365 hoch. Die Erkennungsregel gleicht dann Inhalte gegen diese Fingerabdrücke ab. Vorteil: Null False Positive, da z.B. eine Nummer nur dann anschlägt, wenn sie exakt mit einem existierenden Datensatz übereinstimmt. EDM eignet sich für strikt definierte Datenbestände wie Personalnummern, Vertragsnummern, Kundendatenbanken. Aufwand: Man muss die Referenzdaten pflegen und updaten, und EDM erfordert eine E5-Lizenz.
• Trainierbare Klassifikatoren: Hier kommt KI ins Spiel. Purview bietet vordefinierte Klassifikatoren (z.B. für „Lebenslauf“ oder „Quellcode“), aber man kann auch eigene trainieren. Dazu füttert man das System mit ca. 50+ Beispieldokumenten für die gesuchte Kategorie und idealerweise auch Gegenbeispielen. Der Klassifikator lernt dann typische Muster (Wörter, Strukturen) und kann auch komplexe Inhalte erkennen, die keine einheitliche Syntax haben. Beispiel: Einen „Vertrag“ erkennt man nicht an einer Zahl, sondern an Formulierungen (Parteien, Vertragsdatum, Unterschriftenblock etc.). Ein trainierter Klassifikator kann später sagen: „Dieses 30-seitige PDF sieht mit hoher Wahrscheinlichkeit wie ein Vertrag aus.“ Das ist sehr mächtig, allerdings benötigt es genug Trainingsmaterial und wiederum E5-Lizenzen.
• Regex- und Schlüsselwortlisten: Die Low-Tech-Variante: Als Admin kann ich eigene Muster definieren, meist in Form von Regular Expressions (Regeln/Ausdrücke) oder Schlüsselwortlisten. Beispiel: Eine Regex für unsere Projektcodes, die immer „PROJ-“ gefolgt von 6 Ziffern sind (PROJ-[0-9]{6}). Oder eine Liste relevanter Begriffe, die auf ein geheimes Projekt hindeuten. Diese Methode ist schnell umgesetzt und braucht keine KI – aber man muss sie gut testen, damit sie nicht bei jedem Zufallstreffer auslöst. Oft kombiniert man sie mit anderen Kriterien (z.B. Regex und bestimmtes Wort im Dokument), um die Präzision zu erhöhen.
• Mehrsprachige Inhalte: Viele Organisationen agieren international, und sensible Daten kennen keine Sprachgrenzen. Zum Glück sind viele vorkonfigurierte SITs bereits für mehrere Sprachen ausgelegt (z.B. erkennt der SIT für Kreditkarten eine Visa-Nummer, egal ob der Text drumherum deutsch oder englisch ist). Bei schlüsselwort-basierten Erkennungen sollte man jedoch mehrsprachig denken – z.B. das Wort „Vertraulich“ mag im deutschen Dokument stehen, während „Confidential“ im englischen verwendet wird. Hier kann man im SIT die Wortlisten erweitern oder mehrere Sprachen parallel prüfen. Trainierbare Klassifikatoren kann man mit mehrsprachigen Samples füttern, damit sie robust erkennen. Wichtig ist, die Lokalisierung im Blick zu haben: Ein Muster für US-Sozialversicherungsnummern hilft wenig bei deutschen Personaldaten – und umgekehrt.
• Qualitätssicherung der Erkennung: Ein großer Stolperstein sind False Positives (irrtümliche Treffer) und False Negatives (nicht erkannte Treffer). Daher gilt: Bevor man eine Auto-Labeling-Policy scharf stellt, testen, testen, testen! Microsoft Purview bietet dafür den „Content Explorer“ und „Activity Explorer“ im Compliance Center. Dort kann ich z.B. sehen, wie viele Dokumente einen bestimmten SIT enthalten oder welches Label wann angewendet wurde. Zudem gibt es einen Simulation Mode für Auto-Labeling-Policies: Man lässt die Regel zur Probe laufen und schaut, welche Dokumente hätte sie gelabelt. So kann man die Regeln feinjustieren (Regex anpassen, Schwellenwerte justieren), bevor echtes Chaos entsteht. Best Practice: Mit einer kleinen Abteilung oder Datenmenge pilotieren, Feedback einholen, dann ausweiten.

Schauen wir uns die verschiedenen Erkennungsmethoden einmal vergleichend an:

Checkliste Auto-Labeling-Reife: Ist Ihr Unternehmen bereit für automatisches Labeling? Hier einige Punkte, die erfüllt sein sollten, bevor man den Schalter umlegt:

• Datenklassifizierung vorhanden: Es existiert eine klar definierte Richtlinie, welche Daten wie eingestuft werden (idealerweise schriftlich fixiert von Datenschutz/CISO).
• Identifizierungsmethoden definiert: Die passenden Sensitive Info Types, Patterns oder Klassifikatoren für unsere kritischen Daten sind eingerichtet und getestet.
• Lizenz und Technik gegeben: Die nötigen Lizenzen (oft E5 oder entsprechende Add-ons) sind vorhanden, und die Clients haben die erforderlichen Versionen (Office-Versionen, die Auto-Labeling können, etc.).
• Pilot abgeschlossen: In einem kleinen Rahmen (z.B. IT-Abteilung oder mit Testdaten) wurde Auto-Labeling ausprobiert, um die Auswirkungen zu sehen.
• Kommunikation an Benutzer: Die Anwender wissen, dass es künftig automatische Kennzeichnung gibt, und kennen die grundlegenden Labels. Niemand mag Überraschungen im Arbeitsablauf.
• Rückfallplan: Es gibt Möglichkeiten, im Notfall Labels zu übersteuern (z.B. kann ein Administrator oder Data Owner ein Label entfernen, wenn es falsch angewendet wurde). Und es ist klar geregelt, wer solche Entscheidungen trifft.
• Monitoring eingeplant: Nach dem Rollout wird aktiv beobachtet (durch Berichte im Compliance Center), ob die Regeln wie gewünscht greifen, und es gibt ein Team oder eine Person, die für Tuning und Fehlersuche verantwortlich ist.

Wenn all das abgehakt ist, steht dem automatischen Schutz fast nichts mehr im Wege – außer vielleicht noch ein Go-Live-Meeting mit den Stakeholdern, um sicherzustellen, dass alle an Bord sind.

4. Geschützte Übertragungswege: E-Mail (OME), Dateifreigaben (SPO/Teams), Power BI, Endpoint-Kanäle, Altformate mit AIP-Scanner

Die vorigen Kapitel haben die Technik umrissen – nun schauen wir gezielt auf ein paar wichtige Datenflüsse und wie sie mit PIP geschützt werden.

• E-Mail (Exchange/Outlook): E-Mails sind der klassische Übertragungsweg nach extern. Sensitivity Labels integrieren hier Office Message Encryption (OME) und Rights Management: Ist eine Mail als „Vertraulich“ oder „Nicht weiterleiten“ gekennzeichnet, wird ihr Inhalt verschlüsselt verschickt. Unautorisierte Empfänger können sie nicht lesen (bzw. müssten sich über das OME-Portal authentifizieren). Für interne Mails sorgt das Labeling dafür, dass z.B. im Outlook-Client klar angezeigt wird, dass die Mail vertraulich ist; je nach Label werden Funktionen wie Weiterleiten oder Kopieren im Mailtext unterbunden. Zudem kann Exchange Online auf Serverseite E-Mails scannen: eingehende Anhänge automatisch labeln, ausgehende Mails überprüfen (DLP-Regeln können z.B. verhindern, dass eine als „Nicht extern“ markierte Mail überhaupt nach draußen geht). Kurz: Im E-Mail-Kanal sind Labels der Garant, dass vertrauliche Inhalte nicht im Klartext durchs Netz gehen und an der Empfängerseite nur Befugte dran kommen.
• Dateifreigaben (SharePoint, OneDrive, Teams): Wird eine Datei über M365 geteilt (sei es via SharePoint-Link oder im Teams-Chat), greift PIP auf zwei Ebenen: Erstens ist die Datei an sich durch ihr Label geschützt (siehe „At Rest“-Schutz). Zweitens kann über Container-Labels gesteuert werden, wer Zugriff bekommt (z.B. Team ohne Gäste). Beispiel: Ich teile eine Word-Datei in Teams mit einem Partner extern. Was passiert? Der externe erhält nur Zugang, wenn entweder das Team für Gäste offen ist oder ich gezielt eine externe Freigabe mache und das Label der Datei externen Zugriff erlaubt. Falls die Datei verschlüsselt ist und der externe nicht als berechtigter User im Label steht, kann er sie trotz Link nicht öffnen. Hier sieht man das Zusammenspiel: Die Cloud-Freigabe an sich regelt SharePoint/Teams, aber das Label zieht eine zweite Schutzlinie ein. Zusätzlich: Ein Label kann beim Download aus SharePoint den Schutz erweitern – d.h., eine bislang unverschlüsselte Datei wird beim Herunterladen für externe automatisch verschlüsselt und mit den SharePoint-Berechtigungen verknüpft. Dieses Feature (E5 erforderlich) stellt sicher, dass eine Datei, die intern unverschlüsselt lag, das Firmennetz nicht im Klartext verlässt.
• Power BI: Datenanalysen enthalten oft sensible Infos (z.B. Umsatz, Personaldaten). Power BI ermöglicht es, Sensitivity Labels auf Datasets, Berichte und Dashboards anzuwenden. Was bringt das? Wenn jemand einen als „Vertraulich“ gelabelten Bericht als PDF exportiert oder die Daten nach Excel extrahiert, erhält die exportierte Datei automatisch das entsprechende Label und den Schutz. So verlässt der Inhalt das BI-System nicht ungeschützt. Innerhalb von Power BI selbst sehen Benutzer ggf. ein Icon oder Hinweis, dass der Bericht vertraulich ist – ähnlich wie in Office. Man kann auch verhindern, dass bestimmte Berichte überhaupt exportiert werden (Admin-Einstellung), aber das ginge eher Richtung DLP. PIP in Power BI dient vor allem dazu, den Absprung der Daten (Export, Teilen als PDF/Excel, per PowerPoint) abzusichern.
• Endpoint-Kanäle (USB, Druck, Screenshots): Am Endgerät laufen die heikelsten Aktionen ab: Jemand könnte einen Screenshot vom vertraulichen Dokument machen oder es auf einen USB-Stick kopieren. Hier sind Labels alleine nur bedingt wirksam: Sie können wie erwähnt gewisse Aktionen im Dokument sperren (Druck, Kopieren), aber sie können z.B. keinen Screenshot vom Bildschirm physisch verhindern. Allerdings lässt sich in gewissen Apps ein Screenshot blockieren (z.B. Teams mit geschütztem Meeting-Inhalt blendet beim Versuch einer Aufnahme ein Wasserzeichen ein oder verhindert es). USB-Exfiltration: Eine verschlüsselte Datei auf USB ist für Dritte zwar unbrauchbar, aber der Datentransfer an sich findet statt. Hier kommen Endpoint DLP und Gerätemanagement ins Spiel (separat von PIP, aber ergänzend). Man kann z.B. eine Policy haben: „Upload von als Streng Vertraulich gelabelten Dateien auf unsichere Websites blockieren“ oder „Kopieren auf Wechselmedien protokollieren“. PIP liefert hier die Klassifizierung (das Label sagt „das ist Streng Vertraulich“), während andere Komponenten die Durchsetzung übernehmen. Wichtig: Auf mobilen Geräten können App-Schutzrichtlinien (Intune) z.B. verhindern, dass Inhalte aus einer geschützten App in eine private App kopiert werden. Diese fügen sich mit den Labels zusammen zu einem Gesamtpaket.
• Altformate und On-Premises-Files (AIP-Scanner): Was ist mit den Millionen Dateien auf dem Netzlaufwerk X:, inklusive alter WordPerfect-Dokumente von 1995? Der AIP-Scanner kann sie finden und labeln. Aber Achtung bei Altformaten: Nicht jedes proprietäre Format lässt sich direkt verschlüsseln. Hier nutzt Microsoft das Konzept der generischen Schutzhülle (.PFILE). Wenn eine Datei nicht direkt schützbar ist (etwa eine exotische CAD-Datei), kann der Scanner sie als .pfile verpacken. Das bedeutet: Zum Öffnen muss der Nutzer erst die Hülle authentifiziert öffnen (meist über den AIP-Client/Viewer), dann kommt der eigentliche Inhalt zum Vorschein. Das ist weniger elegant als bei Office-Dateien, aber im Zweifel besser als gar kein Schutz. Der Scanner kann zudem so eingestellt werden, dass er nur berichtend läuft (Discovery-Modus), um erst einmal zu sehen, wo überall sensible Inhalte liegen, bevor er sie verschlüsselt. Gerade bei Altdaten gilt: Piano, piano – man will nicht das halbe Archiv versehentlich unzugänglich machen.

Wir fassen die Schutzmechanismen nach Kanal nochmals in einer Tabelle zusammen:

5. Label- und Policy-Design: Taxonomie, Benennungsregeln, Zielgruppen-Policies, Containerlabels, Change Management

In diesem Abschnitt gehen wir einen Schritt zurück vom reinen Technik-Fokus und widmen uns der Konzeption: Wie baut man eine sinnvolle Label-Struktur auf, die den Anforderungen des Unternehmens gerecht wird, und wie setzt man Policies und Prozesse auf?

Taxonomie & Benennungsregeln

Die Taxonomie der Labels ist im Grunde die „Klassifikationspyramide“ Ihres Unternehmens. Hier ein paar Leitlinien aus meiner Erfahrung:

• Weniger ist mehr: Starten Sie mit einer überschaubaren Anzahl an Labels. Typischerweise genügen 3 bis 5 Vertraulichkeitsstufen (z.B. „Öffentlich“, „Intern“, „Vertraulich“, „Streng Vertraulich“, plus vielleicht eine Zwischenstufe für personenbezogene Daten). Jeder zusätzliche Label steigert die Komplexität exponentiell – also nur einfügen, wenn wirklich notwendig.
• Sublabels für Sonderfälle: Anstatt dutzende Haupt-Labels zu haben, arbeiten Sie lieber mit Sublabels. Beispiel: Unter dem Hauptlabel „Vertraulich“ könnte es ein Sublabel „Vertraulich – Nur Personalabteilung“ geben, das zusätzlich die Berechtigungen auf HR-Team einschränkt. Im Normalfall sieht ein Mitarbeiter nur das Hauptlabel, aber HR-Mitarbeiter können spezifischer labeln. So bleibt die Grundstruktur sauber, und spezielle Teams haben ihre zusätzlichen Optionen.
• Sprechende Namen: Verwenden Sie klare, selbsterklärende Bezeichnungen. „Intern“ versteht jeder. „Company Confidential“ wäre das englische Äquivalent; ob Deutsch oder Englisch hängt von Ihrer Firmenkultur ab (man kann auch mehrsprachige Labelnamen vergeben, z.B. „Vertraulich (Confidential)“). Vermeiden Sie witzige Namen oder Abkürzungen, die keiner versteht. Auch Nummerierungen im Namen („Stufe 1 – Öffentlich“) sind möglich, falls eine Sortierung in der UI sonst unlogisch wäre.
• Namenskonventionen: Legen Sie fest, wie Labels benannt werden, insbesondere bei Sublabels. Oft sieht man Formate wie „Vertraulich (HR)“ oder Trennstriche. Konsistenz hilft, dass Nutzer sofort erkennen, was Sache ist. Achten Sie auch auf Länge – zu lange Labelnamen können in Menüs abgeschnitten werden.
• Container-Label getrennt halten: Überlegen Sie, ob Sie andere Namen für Team/Site-Labels verwenden wollen, um Verwechslungen zu vermeiden. Einige Organisationen nutzen z.B. vorangestellte Wörter: „Team Vertraulich“ vs. „Dokument Vertraulich“. Oder sie haben vollkommen separierte Labelsets (was technisch bedeutet, dass man für Container separate Labels erstellt, die für Files gar nicht gelten). Vorteil: Ein User in Teams sieht dann z.B. Labels „Öffentlich, Intern, Vertraulich“ für sein Team, während in Word vielleicht noch weitere Optionen existieren. Der Kontext unterscheidet sich ja: Ein Team „Vertraulich“ ist etwas anderes als ein Dokument „Vertraulich“ – aber beides sollte konsistent ins Gesamtbild passen.

Zur Veranschaulichung ein Muster-Labelkatalog einer fiktiven Firma:

Hinweis: Die obigen Labels sind nur Beispiele. Jedes Unternehmen sollte seine eigenen Stufen und Begriffe wählen, die zur Kultur und den Compliance-Vorgaben passen. Wichtig ist, dass die Taxonomie sowohl vollständig (alle relevanten Stufen abdeckend) als auch beherrschbar (für Nutzer leicht verständlich) ist.

Zielgruppen-Policies & Veröffentlichungen

Nachdem die Label-Taxonomie steht, muss sie unter die Leute gebracht werden – aber nicht unbedingt alle Labels für alle. Hier kommen Veröffentlichungsrichtlinien (Label Policies) ins Spiel:

• Zielgruppenspezifische Labels: Über Policies kann ich Labels nur bestimmten Nutzern anzeigen. Beispiel: Das Label „Vertraulich – Personal“ aus obigem Katalog wird nur für Mitglieder der HR-Abteilung in deren Office-Apps sichtbar gemacht. Für alle anderen existiert es quasi nicht. So verhindert man, dass User mit Optionen verwirrt werden, die sie nie brauchen.
• Default- und Pflicht-Labels: In einer Label-Policy lässt sich definieren, ob ein Standardlabel gelten soll (z.B. bekommen alle neuen Dokumente automatisch „Intern“, sofern nicht anders gesetzt) und ob ein Label erforderlich ist. Pflicht-Label bedeutet, dass der Benutzer beim Speichern/Schließen einer unklassifizierten Datei aufgefordert wird, eins auszusuchen. Dieses Nudging ist sinnvoll, wenn man sicherstellen möchte, dass nichts „unmarkiert“ bleibt. Aber Obacht: Zu aggressiv eingestellt, kann es nerven (Stichwort Change Management, siehe unten).
• Scope der Labels beachten: Wenn man Labels mit unterschiedlichen Scopes hat (z.B. einige sind nur für Container), regelt die Policy auch das. Man kann eine Policy z.B. erstellen, die nur für die Verwaltung gilt, und darin die Site-Labels „Team Vertraulich“ und „Team Öffentlich“ veröffentlichen, damit diese beim Erstellen neuer Teams auftauchen. Eine andere Policy liefert den gleichen Personen die File-Labels. Andere Policies könnten z.B. für externe Projektmitarbeiter nur eine reduzierte Labelauswahl bereitstellen (falls man Gäste in M365 hat, die auch mal labeln sollen – was eher selten ist).
• Versionierung und Erweiterung: Label-Policies lassen sich ändern, aber Änderungen sollten gut kommuniziert werden. Wenn morgen plötzlich ein neues Label „Top Secret“ auftaucht, fragen sich die Leute, ob gestern noch alles „Streng Vertraulich“ war. Jede Erweiterung der Taxonomie sollte daher mit Ankündigung und Schulung einhergehen. Ebenso das Zurückziehen eines Labels: Was passiert mit Inhalten, die es bereits tragen? (Antwort: Die bleiben gelabelt, aber das Label wird als „geschützt“ markiert und kann nicht mehr neu vergeben werden, bis man es ggf. reaktiviert.) Solche Entscheidungen sollten im Gremium (z.B. mit Datenschutzbeauftragtem) getroffen werden.

Change Management beim Labeling

Die Einführung einer Klassifizierungslösung ist mehr Organisationsthema als IT-Thema. Einige Tipps, die ich aus Projekten mitgenommen habe:

• Stakeholder ins Boot holen: Von Anfang an sollten Vertreter aus allen relevanten Bereichen dabei sein: IT, Compliance/Datenschutz, Rechtsabteilung, aber auch Fachbereiche (denen die Daten „gehören“). Gemeinsame Workshops zur Definition der Labels bewirken Wunder in der Akzeptanz.
• Kommunikation & Schulung: Kündigen Sie das neue System frühzeitig an. Erklären Sie warum das gemacht wird (Schutz von Unternehmenswissen, Einhaltung DSGVO, moderne Zusammenarbeit) und wie es den Mitarbeitern hilft („Wir müssen keine Angst mehr haben, versehentlich was Falsches rauszugeben – das System passt mit auf“). Bieten Sie kurze Trainings oder Videos an. Manche Firmen machen auch spaßige Flyer oder Quiz rund ums Thema Informationsschutz, um die Leute abzuholen.
• Pilotphasen nutzen: Ein stufenweiser Rollout (siehe Kapitel 7) ist Gold wert. Early Adopter aus verschiedenen Abteilungen können Feedback geben. So können Sie z.B. herausfinden, dass das Label „Streng Vertraulich“ im Tagesgeschäft fast nie gebraucht wird und man die meisten Dinge mit „Vertraulich“ erschlagen kann – dann wird sich auch keiner beschweren, wenn es Pflicht wird, weil es eh klar ist.
• Policies feinjustieren: Anfangs vielleicht nicht gleich den Zwang maximal aufdrehen. Wenn Benutzer ständig gezwungen werden, Labels zu setzen, die sie nicht verstehen, speichern sie Dokumente am Ende woanders oder schalten das Add-In ab (okay, Letzteres geht nicht so einfach, aber kreativer Widerstand ist nicht zu unterschätzen). Lieber mit Empfehlungen und Auto-Labeling starten und nur bei sehr kritischen Dingen Pflichten einsetzen.
• Support bereithalten: Gerade in den ersten Wochen nach Rollout sollte es eine Stelle geben, an die sich Nutzer wenden können: „Ich kann diese Datei nicht öffnen, obwohl ich sie erstellt habe“ – solche Probleme gilt es schnell und freundlich zu lösen, damit kein Frust entsteht. Oft liegt die Lösung nur in einer kleinen Anleitung (z.B. Nutzer ist nicht angemeldet und sieht daher den Inhalt nicht). Ein FAQ (siehe Kapitel 12) hilft hier, die häufigsten Fragen zentral zu beantworten.
• Kontinuierliche Verbesserung: Informationsschutz ist kein Einmal-Projekt, sondern ein Programm. Technologien entwickeln sich weiter, Geschäftsmodelle ändern sich, neue Datentypen kommen hinzu. Etablieren Sie einen Regelprozess, wie Labels & Policies regelmäßig überprüft und angepasst werden (z.B. jährliches Review mit den Stakeholdern). Und feiern Sie Zwischenerfolge: Jede abgefangene Datenpanne, die dank Labels nicht passiert ist, darf ruhig intern kommuniziert werden (ohne konkreten Inhalt natürlich) nach dem Motto: „Gut, dass wir das haben!“.

6. Betrieb & Monitoring: KPIs, Betriebsmodell, Prozesse, Troubleshooting

Der nachhaltige Betrieb von Information Protection ist eine Daueraufgabe. Hier beleuchten wir, wie man die laufende Nutzung überwacht, wer welche Rolle übernimmt und wie man bei Problemen reagiert.

KPIs für Informationsschutz

Für das Management (und für die eigene Erfolgskontrolle) sind einige Kennzahlen hilfreich:

• Abdeckung der Klassifizierung: Wie viel Prozent der Inhalte sind gelabelt? (z.B. „80% aller in den letzten 30 Tagen erstellten Dokumente tragen ein Label.“) Ein steigender Wert zeigt zunehmende Adoption.
• Verteilung der Label: Wie verteilen sich die Inhalte auf die verschiedenen Sensitivitätsstufen? (z.B. 60% Intern, 30% Vertraulich, 10% Streng Vertraulich). Hier sieht man, ob evtl. zu viel oder zu wenig hoch eingestuft wird.
• Automatisierungsquote: Anteil der Labels, die automatisch oder über Empfehlung gesetzt wurden vs. manuell. Zeigt, wie gut die Policies greifen und wo noch Lücken sind.
• Schutzwirkungs-KPIs: Anzahl verhinderter potenzieller Datenabflüsse. Z.B. „In diesem Quartal wurden 25 E-Mails mit vertraulichen Daten automatisch verschlüsselt“ oder „Durch DLP wurden 10 Uploads vertraulicher Dateien blockiert“. Das quantifiziert den Nutzen.
• Support-Aufkommen: Wie viele Helpdesk-Tickets gab es rund um Labels (z.B. „Zugriff auf geschützte Datei verloren“). Dieser Wert sollte nach anfänglichem Peak niedrig sein. Wenn nicht, gibt es vllt. Usability-Probleme.

Viele dieser Zahlen liefert das Microsoft Purview Portal in den Reports (Label-Aktivitäten, DLP-Berichte). Andere muss man ggf. aus Logs ziehen oder manuell tracken (z.B. Schulungsteilnahmen für Awareness).

Rollen & Verantwortlichkeiten (Betriebsmodell)

Wie bei allen Security-Themen braucht es klar definierte Verantwortliche. Eine RACI-Matrix hilft, die Rollen für typische Aufgaben festzulegen:

(R = Responsible/Verantwortlich, A = Accountable/Rechenschaftspflichtig, C = Consulted/Konsultiert, I = Informed/Informiert)

Natürlich kann diese Matrix je nach Unternehmen variieren. In kleineren Firmen tragen oft wenige Personen mehrere Hüte. Wichtig ist, dass jemand die Rolle des Service Owners für Information Protection übernimmt – häufig im Bereich IT-Security/CISO angesiedelt. Dieser behält den Überblick, koordiniert das Zusammenspiel mit anderen Teams (z.B. DLP-Team, falls getrennt) und sorgt für Eskalation, falls es irgendwo hakt.

Prozesse & Troubleshooting

Ein paar Prozesse sollten definiert sein, damit PIP im Alltag reibungslos läuft:

• Label-Change-Prozess: Was tun, wenn jemand ein neues Label braucht oder eine Anpassung wünscht? Dafür sollte es ein formales Verfahren geben (Antrag, Prüfung durch Security/Compliance, Umsetzung durch IT). Damit verhindert man Wildwuchs oder ungenehmigte Änderungen.
• Rechteentzug bei Austritt: Wenn Mitarbeiter das Unternehmen verlassen, bleiben deren Dateien eventuell verschlüsselt. Hier greift die vorausschauende Planung: Entweder nutzt man Serviceverschlüsselung (dann hat das Unternehmen immer Zugriff mittels eines „Superuser“-Kontos oder eDiscovery-Funktionen), oder man muss vorsorgen, dass Inhalte vor Austritt übertragen werden. Zum Glück sind in M365 Standardszenarien die Admins in der Lage, auch geschützte OneDrive-Dateien zu entschlüsseln, wenn die Konfiguration stimmt (Stichwort: eDiscovery-Rolle mit entsprechenden Rechten).
• Key-Rollover/BYOK: Falls eigene Schlüssel eingebracht wurden, braucht es einen Prozess für Schlüsselwechsel (z.B. alle 2 Jahre). Microsoft dokumentiert genau, wie ein Key-Rollover durchzuführen ist, ohne dass Daten unlesbar werden. Verantwortlich dafür ist i.d.R. derjenige, der die Keys verwaltet (manchmal das Azure-AD-Team, manchmal das Security-Team). Ein verpasstes Verlängern eines Zertifikats kann sonst plötzlich alle verschlüsselten Daten ins Aus katapultieren – Horrorszenario!
• Incident Response: Sollte dennoch einmal etwas schiefgehen – z.B. ein vertrauliches Dokument gelangt unverschlüsselt nach außen – muss klar sein, wer den Vorfall untersucht, wer informiert werden muss (Datenschutzbeauftragter, Management) und wie reagiert wird. Hier greifen die übergeordneten Security-Incident-Response-Pläne; PIP liefert aber wertvolle Forensik-Daten (Logs zeigen, wer auf die Datei zugegriffen hat, wann sie gelabelt wurde etc.).
• Backup und Archivierung: Ein oft diskutierter Punkt: Backup-Lösungen müssen mit geschützten Dateien klarkommen. Die meisten Enterprise-Backup-Systeme können zwar M365-Daten sichern, aber die Wiederherstellung geschützter Inhalte erfordert oft, dass die wiederhergestellten Daten im richtigen Kontext geöffnet werden. Einige Backup-Anbieter integrieren inzwischen das MIP-SDK, um Inhalte im Backup lesbar zu halten für Berechtigte. Archivierung (z.B. für Compliance) sollte idealerweise vor der Verschlüsselung ansetzen (M365 bietet hier das Compliance-Archiv für Exchange, wo Mails im Journal unverschlüsselt aufbewahrt werden können, selbst wenn der externe Empfänger sie nur verschlüsselt sah). Klingt kompliziert? Es ist ein Detailpunkt, aber im Betrieb wichtig, diesen bedacht zu haben.
• Troubleshooting typische Fälle: Das Support-Team sollte FAQs und Lösungen für gängige Probleme griffbereit haben. Einige Klassiker:
• „Ich kann die Datei nicht öffnen, obwohl ich Zugriff haben sollte“: Prüfen, ob der Nutzer mit dem richtigen Konto angemeldet ist (gerade bei Externen). Oft ist der Fehler, dass man mit dem privaten Microsoft-Konto angemeldet ist statt mit dem Firmenkonto und daher die Rechte fehlen.
• „Ein Dokument wird als ‚Geschützt‘ angezeigt, obwohl es das gar nicht sein sollte“: Möglicherweise hat jemand versehentlich ein falsches Label gesetzt. Lösung: Falls der Benutzer Berechtigung hat, Label ändern. Falls nicht, als Admin über PowerShell (Remove-AIPLabel-Cmdlet) das Label entfernen.
• „Wir haben ein Projekt mit Partner X, der unsere geschützten Dateien nicht lesen kann“: Hier muss man entscheiden: Entweder dem Partner einen Gast-Account geben (beste Lösung) oder einen gemeinsamen Schutz (z.B. Azure AD B2B Collaboration) einrichten. Kurzfristig hilft manchmal auch, die Dateien temporär ohne Verschlüsselung bereitzustellen – aber das sollte die Ausnahme bleiben und nur mit Erlaubnis.
• Performance-/Sync-Probleme: Selten, aber bei extrem großen Dateien oder vielen gleichzeitigen Zugriffen können geschützte Dateien etwas zäher sein. Hier hilft es zu prüfen, ob die „Integration von Labels“ in SharePoint sauber läuft (Opt-In gemacht? Aktuelle Office-Versionen?). Meist liegt die Ursache aber woanders (Netzwerk, PC des Nutzers etc.).

Insgesamt gilt: Die Betriebsphase erfordert ein aufmerksames Auge, aber mit guter Vorbereitung (Training, Prozesse, klare Verantwortlichkeiten) hält sich der Aufwand in Grenzen. Viele Unternehmen betreiben PIP quasi im „Autopilot“, mit nur gelegentlichem Nachsteuern, sobald das System einmal sauber etabliert ist.

7. Rollout-Fahrplan (12 Wochen)

Ein bewährtes Vorgehen für die Einführung von Purview Information Protection ist ein 12-Wochen-Plan. Je nach Firmengröße und Komplexität kann es auch schneller oder langsamer gehen, aber für ein mittleres Umfeld (einige tausend Nutzer, moderate Datenmengen) sind 3 Monate ein realistischer Ansatz.

Nach diesem Fahrplan hat man am Ende nicht nur das Tool eingeführt, sondern auch die Organisation mitgenommen. Wichtig ist, dass am Ende eine Abnahme erfolgt: Sind alle Anforderungen erfüllt? Funktionieren die Labels wie geplant? Hier eine kurze Checkliste zur Abnahme:

• Alle definierten Labels sind in der Produktivumgebung verfügbar und korrekt konfiguriert (Namen, Beschreibungen, Schutzsettings stimmen).
• Label-Policies sind so eingerichtet, dass die richtigen Personengruppen die richtigen Labels sehen (Pilot-Scopes ggf. aufgehoben und nun allgemein verfügbar).
• Auto-Labeling-Regeln wurden in der Breite aktiviert und getestet (z.B. mit Testdokumenten). Keine kritischen False Positives mehr.
• Nutzerkommunikation abgeschlossen: Alle Mitarbeiter wurden über die Änderung informiert, Schulungsmaterial ist zugänglich.
• Helpdesk bereit: Support-Teams haben Wissensartikel/FAQs erhalten und können gängige Fragen beantworten.
• Erfolgsmetriken definiert: Es ist klar, wie der Erfolg gemessen wird (siehe KPIs aus Kapitel 6) und erste Baseline-Messungen wurden durchgeführt.
• Management-Abnahme: Die Projektverantwortlichen (z.B. CISO und CIO) haben grünes Licht gegeben und sind über eventuelle Restrisiken informiert.

Wenn diese Punkte abgehakt sind, heißt es: Glückwunsch, Microsoft Purview Information Protection ist offiziell eingeführt! Jetzt geht es in den stetigen Verbesserungsprozess über.

8. Lizenzierung: M365 E3/E5, Purview Add-ons, AIP P1/P2

Bei all den Fähigkeiten stellt sich immer die Frage: Welche Lizenz braucht man dafür? Microsofts Lizenzlandschaft ist berüchtigt komplex, aber für Purview Information Protection lassen sich ein paar klare Punkte festhalten:

• Grundfunktionen (AIP Plan 1): In Microsoft 365 E3 ist Azure Information Protection Plan 1 enthalten (ebenso in Office 365 E3, Business Premium und einigen anderen Plänen). Damit bekommen Sie die Basisfunktionen: Manuelles Labeln in Office, Schutz von Dateien/E-Mails mit vorgegebenen Rechten, Viewer für geschützte Inhalte, AIP-Scanner (Discovery-Modus) etc. Kurz: Alles, was keinen Automatismus erfordert.
• Premiumfunktionen (AIP Plan 2): Microsoft 365 E5 enthält AIP Plan 2 (das „volle Programm“). Plan 2 umfasst automatische und empfohlene Label-Zuweisung (sowohl client- als auch service-seitig), die Nutzung von trainierbaren Klassifikatoren, den AIP-Scanner im Durchsetzungsmodus (automatisch labeln/verschlüsseln on-prem), Double Key Encryption und noch manches mehr. Falls man kein komplettes E5-Abo möchte, gibt es zwei Möglichkeiten: das Microsoft 365 E5 Compliance-Add-on zu E3 buchen (enthält alle Compliance-Features inkl. Info Protection), oder gezielt das Information Protection & Governance-Add-on buchen (für Office 365 E3 Kunden relevant). Beide liefern im Kern die AIP Plan 2 Features nach.
• Teams Premium: Eine Sonderrolle spielt Teams Premium für Meetings. Sensitivity Labels für Teams-Besprechungen lassen sich nur mit Teams Premium in vollem Umfang nutzen (z.B. Wasserzeichen im Meeting, Aufnahmesperre). Die Label an sich kann man zwar auch ohne Teams Premium vergeben, aber die speziellen Meeting-Schutzfeatures sind an dieses Add-on gebunden. Sprich: Wer „Streng vertrauliche“ Meetings mit all den coolen Sperren will, braucht pro Organisator eine Teams-Premium-Lizenz.
• Viewer-Zugriff für Externe: Wichtig zu wissen: Empfänger, die selbst keine AIP-Lizenz haben (z.B. Externe oder F-Pläne), können gelabelte Inhalte lesen, wenn sie dazu berechtigt wurden. Man braucht keine Lizenz, um geschützte Dateien zu konsumieren, sondern nur zum Erstellen. Microsoft hat 2023 zudem klargestellt, dass für interne Nutzer, die manuell labeln, mindestens ein E3/F3 etc. vorhanden sein muss – was in den meisten Umgebungen ohnehin der Fall ist.

Hier eine Übersichtstabelle der wichtigsten Features und ihrer Lizenz-Zuordnung:

(Stand Lizenzinformationen: Q4 2025. Microsoft passt Features gelegentlich an oder ändert Bundles – daher im Zweifel aktuelle Doku prüfen.)

In Summe lässt sich sagen: Mit E3 kommt man schon sehr weit und kann den Grundschutz implementieren. E5 wird dann interessant, wenn man Automatisierung und Hochpräzisions-Erkennung möchte, oder generell eine umfassende Compliance-Lösung einsetzt. Die Add-On-Option ermöglicht es, gezielt nur die Compliance-Features aufzurüsten, ohne gleich alle E5-Funktionen (wie Telefonie oder Power BI Pro etc.) kaufen zu müssen.

9. Sicherheits- & Rechtsaspekte: DSGVO, E-Mail-Verschlüsselung, Auditfähigkeit

Zuletzt werfen wir einen Blick auf regulatorische Aspekte. Information Protection ist nicht nur nice-to-have, sondern oft auch aus rechtlicher Sicht geboten.

• DSGVO & Co.: Die EU-Datenschutzgrundverordnung fordert „geeignete technische und organisatorische Maßnahmen“ zum Schutz personenbezogener Daten. Klassifizierung und Verschlüsselung gelten explizit als empfohlene Maßnahmen (Stichwort „Stand der Technik“ in Art. 32 DSGVO). Mit Microsoft Purview Information Protection kann ein Unternehmen nachweisen, dass es vertrauliche personenbezogene Daten kennzeichnet und vor unbefugtem Zugriff schützt. Im Falle eines Data Breach (Datenlecks) spielt es für die Aufsichtsbehörde eine Rolle, ob die Daten verschlüsselt waren. Eine Pflicht zur Verschlüsselung steht so zwar nicht in der DSGVO, aber es fließt in die Bewertung ein, ob angemessen geschützt wurde. PIP hilft also, Compliance nachzuweisen und das Risiko von Bußgeldern bei Vorfällen zu senken.
• E-Mail-Verschlüsselung im Berufsalltag: In manchen Branchen (z.B. Gesundheit, Finanzwesen) gibt es konkrete Vorgaben, E-Mails mit sensiblen Inhalten nur verschlüsselt zu versenden. Hier macht es PIP extrem einfach: Durch Sensitivity Labels lässt sich firmenseitig erzwingen, dass z.B. alle Mails mit personenbezogenen Daten automatisch über Office Message Encryption laufen. Das erspart Insellösungen oder manuelles Verschlüsseln. Zudem ist OME für den Empfänger leichter handhabbar als z.B. klassische S/MIME-Zertifikate, da nur eine einmalige Authentifizierung nötig ist. Kurzum: PIP kann helfen, interne Policies zur E-Mail-Verschlüsselung konsequent und nutzerfreundlich umzusetzen.
• Auditfähigkeit & eDiscovery: Ein potenzieller Stolperstein bei Verschlüsselung ist die Frage: Kommt das Unternehmen im Bedarfsfall noch an die Daten? Hier ist auf zwei Dinge zu achten:
• Administrative Zugriffsrechte: Microsofts Rights-Management-System erlaubt es, sog. Superuser zu definieren, die unabhängig von Labels alle Inhalte entschlüsseln können (z.B. für eDiscovery im Rechtsfall). In M365 E5 ist dies über die eDiscovery-Tools integriert (Suchergebnisse werden Admins im Klartext gezeigt, auch wenn verschlüsselt gespeichert). Bei E3 muss man ggf. den AIP-Service entsprechend konfigurieren. Wichtig: Diese Möglichkeit sollte eingerichtet und getestet sein, damit man im Ernstfall nicht blind ist. Natürlich muss der Zugriff dieser Superuser selbst streng kontrolliert werden (Vier-Augen-Prinzip etc.).
• Protokollierung: PIP protokolliert Label-Aktivitäten und Zugriffe. Jeder Aufruf einer geschützten Datei lässt sich (für berechtigte Admins) nachverfolgen: Wer hat wann geöffnet, wurde der Zugriff gewährt oder verweigert? Diese Logs sind Gold wert, um z.B. im Nachhinein zu untersuchen, ob jemand Unbefugtes versucht hat, an Daten zu gelangen. Für Audit-Zwecke kann man auch regelmäßige Berichte erstellen („Alle neu als Streng Vertraulich eingestuften Dokumente der letzten Woche“), um Auffälligkeiten zu sehen. Wichtig aus rechtlicher Sicht: Mitarbeiter müssen über solche Überwachungsmaßnahmen informiert sein (Betriebsrat involvieren!). Aber da es hier um den Schutz der Daten geht und nicht um Leistungskontrolle, ist es in der Regel unkritisch, solange man transparent damit umgeht.
• Schlüsselverwaltung & Geheimschutz: Unternehmen mit höchsten Geheimhaltungsanforderungen (man denke an Rüstung, Regierung) stellen sich manchmal die Frage: „Kann Microsoft meine Daten lesen?“. Bei Standard-Encryption verwaltet Microsoft die Schlüssel, was die Nutzung erleichtert (Services wie Suche funktionieren dann normal). Theoretisch könnte Microsoft auf behördliche Anordnung hin Daten entschlüsseln – praktisch ist das sehr strengen Prozessen unterworfen und bisher kaum vorgekommen, zumal Microsoft Kunden in solchen Fällen benachrichtigt (außer gesetzlich verboten). Wer dieses Restrisiko eliminieren will, kann auf Double Key Encryption (DKE) setzen: Hier hat Microsoft nur einen Teil des Schlüssels; ohne den zweiten (beim Kunden) geht nichts. Dadurch werden jedoch Cloud-Funktionalitäten eingeschränkt (keine Suche in DKE-Dokumenten z.B.). Es ist ein Abwägen zwischen maximaler Souveränität und Komfort. In den meisten kommerziellen Szenarien reicht die Standard-Verschlüsselung vollkommen aus und erfüllt auch alle gängigen Compliance-Zertifizierungen (ISO 27001 etc.).

Fazit: Aus Sicherheits- und Rechtssicht schafft ein implementiertes PIP-System Vertrauen bei Kunden, Behörden und Partnern. Es demonstriert, dass das Unternehmen seine Kronjuwelen kennt und schützt. Zugleich muss man gewissenhaft die „Keys to the Kingdom“ verwalten und interne Richtlinien definieren, wer wann wie auf geschützte Daten zugreifen darf (und das regelmäßig überprüfen). Aber unterm Strich gilt: Lieber haben und richtig managen, als nicht haben. In der heutigen Zeit kann sich kaum jemand mehr leisten, auf soliden Informationsschutz zu verzichten.

10. Szenarien & Rezepte: Praktische Use-Cases

Jede Organisation hat ihre eigenen Anwendungsfälle. Hier beleuchten wir beispielhaft einige typische Szenarien und wie man sie mit Microsoft PIP umsetzt.

Use-Case 1: Vertragsdokumente mit Kunden

Use-Case 2: Personalakten und Gehaltsdaten (HR)

Use-Case 3: Finanzberichte & Planungszahlen

Use-Case 4: Zusammenarbeit in Projekten mit externen Partnern

11. Fehler & Anti-Muster: Typische Stolpersteine

Auch bei besten Absichten kann man in Fallen tappen. Hier ein paar Anti-Muster, die ich (natürlich immer nur bei anderen!) erlebt habe:

• Der „Wir labeln ALLES“-Wahn: Voller Eifer wird jedes Dokument mit „Streng Vertraulich“ gestempelt, selbst die Kantinen-Speisekarte. Folge: Niemand nimmt die Labels mehr ernst. Lesson Learned: Klassifizieren Sie sensibel, nicht sinnlos. Ein Dokument ohne sensible Inhalte muss nicht „vertraulich“ sein. Sonst ist irgendwann alles „wichtig“ – und damit nichts mehr.
• Zu viele Köche, zu viele Labels: 20 verschiedene Labels, für jede Abteilung eins und für jede Sensitivitätsstufe nochmal unterteilt? Klingt vielleicht strukturiert, ist für Anwender aber die Hölle. Wenn Nutzer zu viel Auswahl haben, klicken sie entweder irgendwas an oder gar nichts. Besser: Klein starten (3-5 Labels) und nur erweitern, wenn echter Bedarf da ist.
• Keine Sau weiß Bescheid: Die IT rollt das System aus, vergisst aber, es den Mitarbeitern zu erklären. Plötzlich poppen in Word mysteriöse „Vertraulichkeit“-Buttons auf und keiner weiß, was zu tun ist. Ergebnis: Verwirrung, Frust, und im schlimmsten Fall Umgehung („Schick mir das doch privat, dieser blöde Anhang geht nicht auf“). Gegenmittel: Kommunikation und Schulung nicht vergessen! Und den Helpdesk briefen.
• Lizenzroulette: Man baut fleißig automatische Policies, nur um festzustellen, dass die Hälfte der User gar keine E5-Lizenz hat und daher nichts passiert. Oder es geht erst im Test und wird dann deaktiviert, weil eine Compliance-Prüfung ansteht. Tipp: Vorher prüfen, wer welche Lizenz braucht, und Budget für evtl. Upgrades einplanen. Nichts ist peinlicher, als dem Management nach Projektabschluss zu sagen: „Übrigens, wir müssen jetzt doch noch Lizenzen kaufen, damit das tolle Feature läuft…“.
• Technik ohne Prozess: Die Labels sind da, aber es gibt keine klaren Prozesse im Umgang. Beispiel: Ein Dokument ist versehentlich zu hoch eingestuft und der Kollege kommt nicht dran – wer „darf“ das Label entfernen? Ohne Regel fühlt sich keiner zuständig, oder der erste Admin macht es einfach und verstößt evtl. gegen Compliance-Vorgaben. Daher: Prozesse (wie in Kapitel 6 beschrieben) sauber definieren, sonst herrscht Wildwuchs.
• Paranoia Overkill: Auf einmal ist alles verboten: Kein Copy/Paste mehr, Bildschirmsperre nach 5 Minuten, Dokumente verschwinden nach 1 Tag… Die Security-Abteilung spielt James Bond, während die Mitarbeiter im Hamsterrad durchdrehen. Balance finden: Schutzmaßnahmen mit Augenmaß einführen. Sicherheit ja, aber die Arbeit muss noch machbar bleiben. Sonst finden die Leute Schlupflöcher (und sei es, Screens abzufotografieren mit dem Handy).
• Das Ignorieren menschlicher Faktoren: Zu glauben, dass Technologie alles löst, ist ein Fehler. Wenn Mitarbeiter den Sinn nicht verstehen, werden sie Wege suchen, das System zu umgehen. Labels können auch falsch angewendet werden (absichtlich oder versehentlich). Ein klassischer Fall: Jemand labelt bewusst alles als „Unkritisch“, um keine Umstände zu haben. Deshalb: Monitoring und Stichproben einbauen, Feedback einholen und Menschen motivieren, mitzumachen statt dagegen.

Somit: Aus Fehlern lernt man – aber es müssen ja nicht immer die eigenen sein. 😉

12. FAQ: Häufige Fragen

1. Können Externe unsere geschützten Dateien überhaupt lesen? – Ja, sofern sie vom Label berechtigt sind. Externe ohne Microsoft-Account können z.B. über das OME-Webportal nach einmaliger Codeeingabe Mails lesen. Besser ist aber, wichtige Partner via Azure B2B einzubinden, dann funktioniert es für sie wie für interne Nutzer.
2. Was, wenn ein Mitarbeiter austritt – kommen wir noch an seine verschlüsselten Dateien? – Mit den richtigen Vorkehrungen: Ja. Admins sollten für eDiscovery als „Superuser“ berechtigt sein. Dann können sie im Notfall alle Inhalte entschlüsseln. Ohne diese Einrichtung müsste man sonst den Mitarbeiter-Account aktiv halten, was nicht ideal ist.
3. Brauchen wir für alle Features zwingend E5? – Nicht für alle, aber für automatische Klassifizierung und die KI-basierten Funktionen schon. Manuelles Labeln und Grundschutz gehen mit E3/Business Premium. E5 (oder das Compliance-AddOn) wird erforderlich, wenn Sie z.B. Auto-Labeling oder trainierbare Klassifikatoren nutzen wollen.
4. Was ist der Unterschied zwischen Sensitivity Labels und Retention Labels? – Sensitivity Labels schützen die Vertraulichkeit von Inhalten (Geheimhaltung), während Retention Labels die Aufbewahrung regeln (wie lange etwas gespeichert/gelöscht wird). Sie können zusammen existieren: Ein Dokument kann z.B. „Vertraulich“ und „Aufbewahrung 7 Jahre“ tragen.
5. Wir haben schon DLP im Einsatz – brauche ich dann überhaupt Labels? – Idealerweise nutzt man beides. DLP verhindert, dass Daten unkontrolliert wegfließen (durch Regel-Blocking), aber es verschlüsselt nicht. Labels sorgen für Verschlüsselung und persistente Kennzeichnung. DLP kann Labels sogar als Bedingung nutzen. Zusammen ist der Schutz am effektivsten.
6. Macht die Verschlüsselung meine Office-Dokumente langsamer oder kompliziert? – In der Regel nicht. Die Integration ist heute sehr ausgereift. Ein minimaler Overhead beim Speichern/Öffnen ist da, fällt aber kaum auf. Co-Authoring funktioniert seit einiger Zeit auch mit geschützten Dokumenten (vorausgesetzt, die entsprechenden Einstellungen sind aktiviert).
7. Wie gehen wir mit Backups und Archivierung um, wenn alles verschlüsselt ist? – Backup-Systeme sichern meist auf Dateisystem-Ebene, was kein Problem ist – die verschlüsselten Dateien werden eben so gesichert. Beim Restore müssen berechtigte User öffnen, sonst bleiben sie verschlüsselt. Für Compliance-Archivierung (z.B. E-Mail-Journal) kann man Mails parallel unverschlüsselt archivieren lassen (Microsofts Compliance-Archiv löst das). Wichtig ist, dass die Backup-Admins im Ernstfall Zugriff haben (siehe Superuser).
8. Können wir Labels auch auf bestehende Dateien anwenden, oder nur auf neue? – Auch bestehende. Es gibt mehrere Möglichkeiten: Über Auto-Labeling-Policies können Sie z.B. alle vorhandenen SharePoint-/OneDrive-Dateien scannen und labeln lassen (E5-Feature). Oder den AIP-Scanner für on-prem Dateien einsetzen. Manuell können User natürlich jederzeit ein altes Dokument öffnen und ein Label vergeben.
9. Kann ich erzwingen, dass jede E-Mail ein Label hat? – Ja, mit Label-Policies kann man „Required Label“ einstellen. Dann müssen Benutzer beim Verfassen einer Mail (oder Speichern eines Dokuments) ein Label wählen, falls noch nicht gesetzt. Alternativ kann man auch ein Standard-Label für alle neuen Mails vergeben (z.B. „Intern“), sodass nur Ausnahmen aktiv umgelabelt werden müssen.
10. Können Benutzer Labels entfernen oder umgehen? – Nutzer mit Bearbeitungsrechten auf den Inhalt können in der Regel das Label ändern oder entfernen, wenn sie bewusst dagegen handeln wollen. Allerdings wird das protokolliert. Durch Policies kann man Removal teilweise einschränken (z.B. in Outlook kann man verbieten, ein bestimmtes Label zu entfernen). Aber 100% erzwingen ist schwer – hier hilft Awareness: Warum sollte jemand absichtlich den Schutz abdrehen? Wenn doch, sollte es Konsequenzen geben (und DLP könnte das Entfernen auch bemerken).
11. Was, wenn jemand falsch labelt (aus Versehen oder Absicht)? – Aus Versehen: Der Helpdesk oder ein Admin mit entsprechenden Rechten kann das Label ändern. Absicht (z.B. absichtlich zu niedrig eingestuft): Hier kommen Monitoring und DLP ins Spiel. Man kann z.B. DLP-Regeln bauen: „Falls Dokument enthält Kreditkartendaten, aber Label ist ‚Public‘, dann Alarm“. Letztlich ist das ein Schulungsthema und ggf. Compliance-Thema – absichtliches Mislabeling sollte wie ein Policy-Verstoß behandelt werden.
12. Braucht man für Mobile oder Mac etwas Besonderes? – Die aktuellen Office-Apps auf iOS/Android und Mac unterstützen Sensitivity Labels nativ. Auf Mobilgeräten kann man Labels in Word/Excel/PowerPoint anzeigen und ändern. Was nicht geht: Mails in der nativen iOS-Mail-App lesen, wenn sie verschlüsselt sind – da muss man die Outlook-App nutzen oder über den OME-Webviewer gehen. PDF auf dem Mobilgerät öffnen geht z.B. mit Adobe Reader (wenn MIP-SDK integriert) oder mit der OneDrive-App als Vorschau.
13. Schützen Labels auch vor Screenshots oder Fotos? – Nicht wirklich. Wenn etwas am Bildschirm sichtbar ist, kann es abfotografiert werden. Labels können höchstens mit Wasserzeichen abschrecken, aber verhindern lässt es sich nicht.
14. Wir haben doch schon BitLocker und SharePoint-Rechte, reicht das nicht? – Diese schützen nur in ihrem Kontext: BitLocker schützt vor Diebstahl des ganzen Laptops, aber nicht, wenn jemand eine Datei kopiert und mailt. SharePoint-Zugriffsrechte helfen nur, solange die Datei auf SharePoint ist. Sobald sie heruntergeladen oder weitergeschickt wird, sind die Rechte weg. Genau da setzen Sensitivity Labels an – der Schutz reist mit der Datei.
15. Wie fangen wir am besten mit Information Protection an? – Indem Sie die wichtigsten Daten identifizieren („Crown Jewels“) und damit einen Piloten starten. Holen Sie sich Unterstützung von oben (Management-Sponsoring) und beteiligen Sie die Fachbereiche. Kapitel 7 in diesem Artikel gibt einen guten Fahrplan: Start mit grundlegenden Labels, Pilotgruppe, Feedback-Schleife, dann schrittweise ausrollen. Nicht überperfektionieren am Anfang – besser agil lernen und nachsteuern.

13. Beratungsangebot von Ulrich Boddenberg

Zum Abschluss erlaube ich mir einen kleinen Werbeblock in eigener Sache: Wenn Ihnen das alles unter den Nägeln brennt und Sie Unterstützung suchen, stehe ich als erfahrener M365/Security-Architekt zur Verfügung. Ich biete drei Pakete an, um Ihr Information-Protection-Projekt zum Erfolg zu führen (Tagessatz: 1.500 € zzgl. MwSt., persönliche Durchführung durch mich – keine Übergabe an Junioren oder Outsourcing):

• Starter-Paket (ca. 5 PT): Ein kompaktes Workshop- & Konzeptions-Paket. Wir erarbeiten in 2–3 Tagen Workshops Ihre Anforderungen, entwickeln eine auf Sie zugeschnittene Label-Taxonomie und einen groben Umsetzungsplan. In den restlichen Tagen erstelle ich eine schriftliche Strategieempfehlung und Roadmap für Ihr Unternehmen. Ideal, um das Thema zu kickstarten oder Management-Buy-in zu holen.
• Professional-Paket (ca. 10–15 PT): Pilot & Basisimplementierung. Enthält alles aus dem Starter-Paket plus die technische Umsetzung eines Piloten in Ihrer Umgebung. Ich setze mit Ihnen gemeinsam die ersten Labels und Policies auf, schule Ihr Kernteam und begleite einen Testlauf (Pilotgruppe). Am Ende haben Sie eine funktionsfähige Grundschutz-Lösung und klare Empfehlungen für den Rollout.
• Enterprise-Paket (20+ PT, nach Aufwand): Komplette Implementierung & Rollout-Begleitung. Von A bis Z: Analyse, Konzept, Umsetzung aller Labels/Policies, Integration mit DLP, umfassende Schulungen für Admins und Endanwender, Monitoring-Konzept und Begleitung des Rollouts bis zur Abnahme. Quasi ein Rundum-sorglos-Paket für Unternehmen, die das Thema professionell und zügig etablieren wollen. Dauer und Aufwand je nach Firmengröße – gern erstelle ich ein individuelles Angebot.

Hinweis: Alle Beratungsleistungen sind projektbasiert – keine langfristigen Managed Services. Mein Ansatz: Hilfe zur Selbsthilfe. Ich mache Ihr Team fit, sodass Sie Information Protection selbstbewusst selbst betreiben können. Bei Bedarf stehe ich später für Audits, Refresh-Workshops oder neue Anforderungen jederzeit erneut zur Verfügung.

Weitere Beiträge zum Thema Security und Compliance