Verschlüsselung per Sensitivity Label: Nutzungsrechte und die Ausnahmen, die keiner bedenkt

Der Anruf kam an einem Dienstagmorgen, und er kam nicht von der IT. Er kam vom Wirtschaftsprüfer, der seit einer Stunde vor grauen Kacheln saß: Die Jahresabschlussunterlagen, die ihm die Buchhaltung in den Datenraum gelegt hatte, ließen sich nicht öffnen. „Sie sind nicht berechtigt", stand da – für einen Mann, der von Berufs wegen berechtigt sein muss. Was passiert war: Drei Wochen vorher hatte das Unternehmen das Label „Vertraulich" mit Verschlüsselung für alle Mitarbeiter scharf geschaltet. Alle Mitarbeiter. Der Prüfer war keiner.

Verschlüsselung per Sensitivity Label ist das schärfste Werkzeug in Microsoft Purview: Sie hängt den Schutz an das Dokument selbst, nicht an den Ordner, in dem es liegt, und sie sorgt dafür, dass ein Dokument auf dem USB-Stick, in der Fremd-Cloud oder in einer versehentlich weitergeleiteten Mail genauso geschützt ist wie in SharePoint. Sie ist die einzige technische Grenze, die Copilot wirklich respektieren muss, und sie ist die Antwort auf die Frage, was „Kryptografie" in NIS2 und Art. 32 DSGVO praktisch bedeuten soll. Aber sie ist auch das Werkzeug, mit dem du dir am schnellsten die Zusammenarbeit kaputt machst – weil alles, was ein verschlüsseltes Dokument lesen soll, eine Identität braucht, und die haben Scanner, Archive und Prüfer nicht von selbst.

Dieser Artikel erklärt, wie die Verschlüsselung funktioniert, was Nutzungsrechte wirklich steuern, welche drei Wege es gibt, Berechtigungen zu vergeben, wie das Super-User-Konzept aussieht und – vor allem – welche Ausnahmen du geregelt haben musst, bevor das erste Dokument verschlüsselt wird. Wo Verschlüsselung im Gesamtbild von Purview steht, zeigt der Überblick zum Kompetenzbereich Microsoft Purview.

Faktenkasten: Was Verschlüsselung per Sensitivity Label ist Ein Sensitivity Label (Vertraulichkeitsbezeichnung) kann neben Markierungen auch eine Verschlüsselung auslösen. Technisch nutzt Microsoft Purview dafür Azure Rights Management (Azure RMS), die Technik aus Azure Information Protection: Der Inhalt wird mit einem Dateischlüssel chiffriert, in die Datei wird eine Richtlinie eingebettet, die festlegt, welche Benutzer oder Gruppen welche Nutzungsrechte haben – etwa Anzeigen, Bearbeiten, Kopieren, Drucken oder Weiterleiten – und wie lange. Beim Öffnen holt sich der Client vom Dienst eine Nutzungslizenz; ohne passende Identität bleibt die Datei zu, egal wo sie liegt. Konfiguriert wird die Verschlüsselung am Label im Purview-Portal (purview.microsoft.com, Information Protection, Vertraulichkeitsbezeichnungen). Der Tenant-Schlüssel liegt standardmäßig bei Microsoft; Bring-Your-Own-Key und Double Key Encryption sind Sonderfälle. Verschlüsselnde Labels sind ab Microsoft 365 E3 verfügbar; für Automatisierung braucht es E5 (Stand 2026).

 

Wie die Verschlüsselung funktioniert – und warum sie am Dokument hängt

Der entscheidende Unterschied zu allem, was du aus der klassischen Berechtigungswelt kennst: NTFS-Rechte, SharePoint-Berechtigungen und Freigabelinks schützen den Ort. Wer das Dokument aus dem Ort herausbekommt – per Download, per Mail, per Kopie auf den Stick –, hat den Schutz hinter sich gelassen. Verschlüsselung per Label schützt das Objekt. Der Inhalt ist chiffriert, und in der Datei steckt eine Richtlinie, die sagt, wer was darf. Kopieren kannst du sie so oft du willst; ohne passende Identität bleibt es Rauschen. In Projekten nenne ich das gern die Umkehrung der Beweislast: Nicht der Ort muss beweisen, dass er sicher ist, sondern der Leser muss beweisen, dass er berechtigt ist.

Der Weg beim Öffnen: Datei, Client, Azure RMS, Nutzungslizenz

Was beim Öffnen passiert, ist unspektakulär, aber wichtig für alles, was danach kommt. Der Office-Client liest die Richtlinie aus der Datei und fragt Azure Rights Management: Hier ist ein angemeldeter Benutzer, hier ist die Richtlinie – was darf er? Der Dienst prüft die Entra-Identität und ihre Gruppenmitgliedschaften gegen die Richtlinie und stellt eine Nutzungslizenz aus, die den Dateischlüssel und die konkreten Rechte enthält, zeitlich befristet. Diese Lizenz gilt eine Weile auch offline – wie lange, legst du am Label fest, typisch sind einige Tage bis 30 Tage –, danach muss der Client wieder nachfragen. Aus diesem Ablauf folgen zwei Dinge, die viele erst im Betrieb merken: Verschlüsselte Dateien lassen sich nur mit einer Identität öffnen, die Azure RMS kennt. Und Rechteänderungen am Label wirken auf bereits verschlüsselte Dokumente, sobald der Client das nächste Mal eine Lizenz holt.

Skizze 1: Was beim Öffnen passiert – der Schutz steckt in der Datei, die Rechte kommen bei jedem Öffnen frisch von Azure Rights Management.

Das Nutzungsrechte-Modell: mehr als „darf lesen"

Die Rechte, die Azure RMS vergibt, sind feiner als alles, was du aus Dateisystemen kennst. Es gibt VIEW (anzeigen), EDIT (bearbeiten), EXTRACT (Inhalte kopieren, im Portal als „Inhalt kopieren und extrahieren"), PRINT, EXPORT (in anderes Format speichern), FORWARD, REPLY und REPLY ALL für E-Mails, OWNER (Vollzugriff, darf die Rechte selbst ändern) und einige weitere. Damit niemand jedes Recht einzeln ankreuzen muss, bündelt Microsoft sie in vier Standardsätzen: Viewer darf nur anzeigen und antworten, Reviewer darf zusätzlich bearbeiten und weiterleiten, Co-Author darf außerdem kopieren, drucken und exportieren, Co-Owner darf alles inklusive Rechte ändern. Diese Bündel decken neunzig Prozent aller Fälle ab, und ich rate dringend dazu, mit ihnen zu arbeiten statt mit handverlesenen Einzelrechten. Ein Modell, das der Anwender im Dialog wiedererkennt, wird benutzt; eines mit vierzehn Häkchen wird weggeklickt.

Ein Recht verdient besondere Aufmerksamkeit: EXTRACT. Es steuert, ob Inhalte aus dem Dokument herausgezogen werden dürfen – per Kopieren, per Suchindex und, seit es Copilot gibt, per KI. Ein Dokument, bei dem dem Benutzer das EXTRACT-Recht fehlt, wird von Microsoft 365 Copilot nicht als Quelle verwendet. Damit ist ein Viewer- oder Reviewer-Bündel für „Streng vertraulich" nicht nur ein Schutz gegen Weitergabe, sondern die einzige harte Grenze, die Copilot kennt. Was das für Antworten, Zitate und die Label-Vererbung bedeutet, behandelt der Spoke Was Copilot sieht – und was nicht.

Skizze 2: Wer darf was – die vier Rechtebündel und die Einzelrechte dahinter; EXTRACT ist die Copilot-Grenze.

Die folgende Tabelle ordnet die vier Rechtebündel den Stufen zu, wie ich sie in Projekten typischerweise verwende. Die Zuordnung ist ein Vorschlag, kein Gesetz – aber wer davon abweicht, sollte einen Grund haben, den er dem Betriebsrat erklären kann.

Bündel	Enthaltene Rechte	Typische Verwendung	Copilot-Wirkung
Co-Owner	Alle Rechte inkl. OWNER (Rechte ändern, Ablauf setzen)	Autor des Dokuments; Rolle „Informationseigentümer" je Fachbereich	Quelle für Copilot
Co-Author	VIEW, EDIT, EXTRACT, PRINT, EXPORT, REPLY, FORWARD	„Vertraulich" für alle Mitarbeiter – interne Zusammenarbeit ohne Reibung	Quelle für Copilot
Reviewer	VIEW, EDIT, REPLY, FORWARD – kein Kopieren, Drucken, Exportieren	Externe Mitwirkung an Entwürfen; Gremien, die kommentieren, aber nichts mitnehmen sollen	Keine Quelle (kein EXTRACT)
Viewer	VIEW, REPLY – sonst nichts	„Streng vertraulich" für benannte Empfänger; Datenraum für Prüfer und Kanzleien	Keine Quelle (kein EXTRACT)

 

Drei Wege, Berechtigungen zu vergeben

Ein verschlüsselndes Label muss wissen, wer die Rechte bekommt. Dafür gibt es drei Wege, und die Wahl zwischen ihnen entscheidet darüber, ob deine Verschlüsselung skaliert oder ob sie am dritten Tag im Helpdesk landet. Der erste Weg ist der Regelfall, der zweite die Ausnahme für Fälle, die der Administrator nicht kennen kann, der dritte betrifft alle beide.

Vom Administrator festgelegt: das Label kennt die Empfänger

Bei administratorseitig festgelegten Berechtigungen hinterlegst du am Label, wer was darf – etwa „Alle Mitarbeiter: Co-Author" für „Vertraulich" oder „Gruppe Geschäftsführung: Co-Owner, Gruppe Aufsichtsrat: Viewer" für „Streng vertraulich – Gremien". Der Anwender wählt das Label und ist fertig; er muss keinen Empfänger benennen, keine Rechte verstehen, nichts entscheiden. Das ist der Weg, der skaliert, der sich automatisieren lässt und der mit SharePoint, Suche und Co-Authoring am reibungslosesten zusammenspielt. Zwei Handwerksregeln dazu: Nutze Gruppen, nie Einzelpersonen – wer beim Ausscheiden eines Kollegen die Rechte an fünfhundert Dokumenten anpassen muss, hat verloren. Und trag am Label immer mindestens eine Gruppe mit Co-Owner ein, die nicht der einzelne Autor ist, damit es beim Wechsel des Autors einen zweiten Weg ins Dokument gibt.

Vom Benutzer festgelegt: der Anwender entscheidet im Moment des Labelns

Bei benutzerdefinierten Berechtigungen legt der Anwender im Moment des Labelns fest, wer das Dokument öffnen darf – per Dialog mit Empfängerliste und Rechtebündel. In Outlook stehen dafür zusätzlich die Klassiker „Nicht weiterleiten" (Empfänger dürfen lesen und antworten, aber nicht weiterleiten, drucken oder kopieren) und „Nur verschlüsseln" (Empfänger dürfen alles außer die Verschlüsselung entfernen) zur Verfügung. Das ist der richtige Weg für den einzelnen Vertrag, der an genau eine Kanzlei geht, für das Angebot an einen Kunden, für den Fall, den der Administrator vorher nicht kennen kann. Aber es ist ein Weg mit Nebenwirkungen: Dokumente mit benutzerdefinierten Rechten unterstützen kein Co-Authoring in SharePoint, lassen sich nicht dienstseitig automatisch labeln, und wenn der Anwender die falsche Person einträgt, gibt es niemanden außer ihm und dem Super-User, der das korrigieren kann. Deshalb: benutzerdefinierte Rechte für ein Label, das der Anwender bewusst wählt, nicht als Standard.

Ablauf und Offline-Zugriff: die zwei Häkchen für den Datenraum

Beide Wege kennen zwei zusätzliche Stellschrauben. Ein Ablaufdatum – absolut oder als Anzahl Tage nach dem Labeln – sorgt dafür, dass ein Dokument nach dem Prüfungszeitraum oder dem Projektende von selbst unlesbar wird; für Datenräume mit externen Beteiligten ist das Gold wert. Und der Offline-Zugriff legt fest, wie lange ein Client mit der einmal geholten Lizenz weiterarbeiten darf, ohne Azure RMS zu erreichen. Für den Außendienst im Zug ist ein großzügiger Wert richtig; für „Streng vertraulich" wählen manche Kunden „nie", damit ein Rechteentzug sofort wirkt. Beides sind Fragen, die der Fachbereich beantworten sollte, nicht die IT.

Faktenkasten: Schlüssel, Sonderfälle und Zahlen Standardmäßig erzeugt und verwahrt Microsoft den Tenant-Schlüssel für Azure Rights Management. Wer die Schlüsselhoheit selbst halten will, hat zwei Sonderwege: Bring Your Own Key (BYOK) über Azure Key Vault und Double Key Encryption (DKE), bei der ein zweiter Schlüssel im eigenen Rechenzentrum liegt und Microsoft den Inhalt technisch nicht entschlüsseln kann. DKE ist für wenige, extrem sensible Datenklassen gedacht – Suche, Co-Authoring, DLP, eDiscovery und Copilot funktionieren für DKE-Inhalte nicht. Die Offline-Nutzungsdauer wird je Label festgelegt (typisch einige Tage bis 30 Tage, „immer" oder „nie" möglich). Rechteänderungen am Label wirken auf bereits verschlüsselte Inhalte, sobald der Client die nächste Lizenz anfordert; das Löschen eines Labels hebt die Verschlüsselung dagegen nicht auf – die Dokumente bleiben verschlüsselt und werden schwer zugänglich. Labels deshalb nie löschen, sondern aus der Richtlinie nehmen. Verschlüsselnde Labels ab Microsoft 365 E3 (Stand 2026).

 

Der Super-User und die Ausnahmen, die keiner bedenkt

Jetzt zum eigentlichen Grund, warum dieser Artikel existiert. Verschlüsselung funktioniert technisch tadellos; sie scheitert an Systemen und Menschen, die niemand auf der Liste hatte. Die Frage, die du dir vor dem ersten verschlüsselten Dokument stellen musst, lautet nicht „Wer soll das lesen dürfen?", sondern „Wer und was liest das heute alles, ohne dass ich es weiß?" Die Antwort ist in jedem Unternehmen länger, als der Projektleiter denkt.

Das Super-User-Konzept: der Generalschlüssel, den es geben muss

Azure Rights Management kennt eine Super-User-Funktion: Konten in dieser Rolle können jedes verschlüsselte Dokument des Tenants entschlüsseln, unabhängig von der eingebetteten Richtlinie. Sie ist standardmäßig ausgeschaltet und wird per PowerShell aktiviert und befüllt. Ohne sie hast du keinen Weg an ein Dokument, dessen einziger Owner ausgeschieden ist, dessen Berechtigungsgruppe versehentlich gelöscht wurde oder das ein Anwender mit benutzerdefinierten Rechten an die falsche Person adressiert hat. Mit ihr hast du einen Generalschlüssel, der in falschen Händen alles öffnet. Beides ist ein Risiko; das erste ist größer.

Mein Konzept in Projekten: Die Funktion wird bewusst aktiviert und dokumentiert. Super-User sind keine Personen, sondern zwei Arten von Konten – ein Break-Glass-Konto für den Notfall, das nur über Privileged Identity Management zeitlich befristet aktiviert werden kann und dessen Nutzung im Audit-Log auffällt, sowie Dienstkonten für Systeme, die verschlüsselte Inhalte lesen müssen (dazu gleich mehr). Wer welches Konto wann benutzt hat, ist Teil der Purview-Betriebsvereinbarung und wird vierteljährlich geprüft. Und ganz wichtig: Der Global Admin ist nicht automatisch Super-User. Wer die Rolle nicht eingerichtet hat, hat sie nicht – Rollenfragen im Detail behandelt der Spoke zu Rollen und RBAC im Purview-Portal.

Die Ausnahmenliste: DMS, Archiv, Prüfer, Fachanwendungen, Suche

Hier ist die Liste, die ich in jedem Projekt in der ersten Woche durchgehe, und in jedem Projekt kommt mindestens ein Eintrag hinzu, an den vorher niemand gedacht hat. Ein Dokumentenmanagementsystem, das SharePoint-Bibliotheken indexiert oder Dateien per Workflow weiterreicht, sieht bei verschlüsselten Dateien nur Rauschen; Volltextsuche und Metadatenextraktion laufen ins Leere. Ein Archivsystem oder Backup sichert das Chiffrat brav weg – und wenn in acht Jahren der Betriebsprüfer kommt, ist der Schlüssel eine offene Frage. Ein Scanner-Workflow, der PDFs erzeugt und ablegt, ist meist unkritisch; ein PDF-Konverter oder Signaturdienst, der verschlüsselte Word-Dateien verarbeiten soll, ist es nicht. Fachanwendungen mit Dokumentanhängen – ERP, CRM, Vertragsverwaltung – lesen die Datei entweder gar nicht oder brauchen eine Anbindung über das Microsoft Information Protection SDK. Und Menschen: Wirtschaftsprüfer, Steuerberater, Betriebsprüfer, externe Kanzleien, Kunden mit Zugriff auf einen Datenraum, Gäste in Teams.

Die gute Nachricht: Microsofts eigene Dienste sind vorbereitet. SharePoint Online und OneDrive können verschlüsselte Office-Dateien indexieren, im Browser öffnen, per Co-Authoring bearbeiten und mit DLP-Richtlinien prüfen; Exchange Online kann verschlüsselte Mails für Transportregeln, DLP und Journaling verarbeiten; eDiscovery und Legal Hold greifen auf verschlüsselte Inhalte zu, ohne dass jemand die Verschlüsselung entfernen muss (wie sich das mit Aufbewahrung und Sicherung verträgt, steht im Spoke zu Legal Hold in Microsoft 365). Die Ausnahmen davon: Dateien mit benutzerdefinierten Rechten und DKE-Inhalte. Alles außerhalb des Microsoft-Kosmos braucht einen bewusst gebauten Weg.

Skizze 3: Die Ausnahmen-Landkarte – wer alles an ein verschlüsseltes Dokument will und welchen Weg jeder Akteur braucht.

Als Umsetzungshilfe hier die Ausnahmenliste als Prüftabelle: Symptom, Ursache, Lösungsweg. In Projekten arbeite ich sie mit IT, Fachbereichen und Datenschutzbeauftragtem gemeinsam ab, bevor das erste verschlüsselnde Label in einer Richtlinie landet.

Akteur	Symptom ohne Konzept	Lösungsweg
DMS, Indexer, Scanner-Workflow	Volltextindex leer, Workflows brechen ab, Metadaten fehlen	Super-User-Dienstkonto mit MIP-SDK-Anbindung; oder Ablage-Label ohne Verschlüsselung für DMS-Bibliotheken
Archiv, Backup, Langzeitablage	Chiffrat wird gesichert, Lesbarkeit nach Jahren offen	Super-User dokumentiert und getestet; Verfahrensdokumentation (GoBD) beschreibt den Entschlüsselungsweg
Wirtschaftsprüfer, Betriebsprüfer, Kanzlei	„Sie sind nicht berechtigt" vor Buchhaltungsunterlagen	Gastkonto in Entra mit Viewer-Recht in einer Prüfergruppe; oder Owner exportiert unverschlüsselt in Datenraum mit Ablaufdatum
ERP, CRM, Vertragssystem	Anhänge nicht lesbar, Vorschau leer	Prüfen, ob die Anwendung MIP unterstützt; sonst Dienstidentität mit Super-User oder Ausnahme-Label
PDF-Konverter, Signaturdienst	Konvertierung schlägt fehl	Vor Konvertierung Label ändern (Owner) oder unterstützten Dienst wählen
Externe Partner ohne Entra-Konto	Kein Zugriff, Einmalcode-Dialog	B2B-Gast oder benutzerdefinierte Rechte durch den Autor mit Ablaufdatum
Ausgeschiedener Autor als einziger Owner	Niemand kann Rechte ändern	Zweite Owner-Gruppe am Label; Break-Glass-Super-User über PIM
Microsoft 365 Copilot	Antwort „keine Quelle gefunden"	Gewollt: ohne EXTRACT keine Quelle. Für Zusammenarbeit Co-Author-Bündel wählen

 

Warnkasten: Verschlüsselung ohne Ausnahmekonzept Ich sage es so deutlich wie möglich: Wer ein verschlüsselndes Label ausrollt, ohne vorher die Liste der Systeme und Menschen durchzugehen, die heute an diese Dokumente wollen, führt keine Verschlüsselung ein, sondern eine Verfügbarkeitsstörung mit Vorlaufzeit. Sie tritt nicht sofort auf. Sie tritt auf, wenn der Prüfer kommt, wenn das DMS die Quartalsberichte indexieren soll, wenn der einzige Owner in Rente geht. Wer dir erzählt, dass man das „im Betrieb nachziehen" kann, verkauft dir Hoffnung. Im Betrieb nachziehen heißt: mit dem Super-User Tausende Dokumente einzeln anfassen. Das Konzept vorher kostet zwei Workshops. Die Reparatur hinterher kostet Wochen.

 

Praxiskasten: Das Archiv, das zehn Jahre schwieg Bei einem Kunden aus der Industrie hatte die IT vor Jahren ein verschlüsselndes Label für die Konstruktionsabteilung eingeführt – sauber, mit fester Gruppe, ohne Beschwerden. Als das Unternehmen sein Archivsystem wechselte, sollten die alten Zeichnungsdokumente migriert werden. Das Migrationswerkzeug meldete zwanzigtausend Dateien als „beschädigt". Sie waren nicht beschädigt, sie waren verschlüsselt, und niemand hatte je einen Super-User eingerichtet, weil es keinen Anlass gab. Die Lösung war am Ende einfach – Super-User-Feature aktivieren, Dienstkonto anlegen, per PowerShell entschlüsselt migrieren –, aber sie kostete drei Wochen Verzögerung und ein sehr ungemütliches Gespräch mit dem Migrationsdienstleister. Seitdem steht in jedem meiner Verschlüsselungskonzepte auf Seite eins: „Super-User: aktiviert, dokumentiert, getestet."

 

Verschlüsselung im Betrieb: Rechte ändern, Zugriff entziehen, Copilot einordnen

Ist die Verschlüsselung erst im Feld, verschiebt sich die Arbeit vom Konzept in den Betrieb. Drei Fragen kommen dabei regelmäßig: Wie ändere ich Rechte an Dokumenten, die schon draußen sind? Wie entziehe ich einem einzelnen Dokument den Zugriff? Und was mache ich, wenn Copilot plötzlich weniger findet als vorher?

Die erste Frage ist die angenehmste. Weil die Rechte bei jedem Öffnen frisch vom Dienst kommen, wirken Änderungen an administratorseitig festgelegten Berechtigungen auf alle bereits verschlüsselten Dokumente – ergänze eine Gruppe am Label, und die neuen Mitglieder können ab der nächsten Lizenzanforderung lesen. Das gilt nicht für benutzerdefinierte Rechte, die im Dokument stehen und nur vom Owner oder Super-User änderbar sind. Die zweite Frage beantwortet die Funktion „Zugriff verfolgen und widerrufen": Ein Autor kann für ein einzelnes verschlüsseltes Office-Dokument nachsehen, wer versucht hat, es zu öffnen, und den Zugriff komplett widerrufen; Administratoren können das per PowerShell tun. Das ist kein Alltagswerkzeug, aber im Fall des versehentlich verschickten Vertrags unbezahlbar. Die dritte Frage ist eine Einordnung, keine Störung – dazu der Kasten.

KI-Kasten: Wenn Copilot nach der Verschlüsselung weniger weiß Nach der Einführung verschlüsselnder Labels bekomme ich verlässlich die Rückmeldung, Copilot sei „schlechter geworden": Es fasst den Vorstandsbericht nicht mehr zusammen, es findet die Gehaltstabelle nicht mehr. Genau das ist der Zweck. Microsoft 365 Copilot verwendet Inhalte nur als Quelle, wenn der fragende Benutzer das EXTRACT-Recht hat; ein Viewer- oder Reviewer-Bündel schließt das Dokument aus, ein Co-Author-Bündel lässt es zu. Für „Vertraulich" mit Co-Author für alle Mitarbeiter ändert sich für Copilot also nichts – für „Streng vertraulich" mit Viewer-Rechten sehr wohl. Die Entscheidung, welche Stufe Copilot als Quelle nutzen darf, ist deshalb keine Frage der KI-Konfiguration, sondern des Rechtebündels am Label. Wer sie bewusst trifft, hat die einzige harte Copilot-Grenze in der Hand, die es gibt. Details zu Vererbung, Zitaten und Sofortmaßnahmen: Was Copilot sieht – und was nicht.

 

Tippkasten: Ein „Ablage"-Label ohne Verschlüsselung Für Bibliotheken, die von DMS, Archiv oder Fachanwendungen bedient werden, hat sich in Projekten ein pragmatischer Kniff bewährt: ein Label „Vertraulich – Ablage" mit denselben Markierungen wie „Vertraulich", aber ohne Verschlüsselung, das per Standard-Label auf genau diese Bibliotheken wirkt und dessen Schutz stattdessen über die Container-Berechtigungen und DLP läuft. Das ist kein Ersatz für Verschlüsselung, aber ein sauberer Kompromiss für Systeme, die du nicht anbinden kannst – und ehrlicher als ein Label, das jeder heimlich entfernt. Was Container-Labels dabei leisten und was nicht, steht im Spoke zu Container-Labels für Teams und SharePoint.

 

Der Deutschland-Winkel: Art. 32 DSGVO, GoBD-Datenzugriff und der Betriebsrat

Verschlüsselung ist eine der wenigen technischen Maßnahmen, die Art. 32 DSGVO ausdrücklich beim Namen nennt, und die Aufsichtsbehörden sehen sie gern – vorausgesetzt, sie ist nachvollziehbar konfiguriert und dokumentiert. Der Datenschutzbeauftragte sollte deshalb wissen, welche Labels verschlüsseln, mit welchen Rechtebündeln, wo der Schlüssel liegt (Standard: bei Microsoft; wer das nicht will, landet bei BYOK oder DKE) und wer Super-User ist. Genau diese vier Punkte gehören in das Verzeichnis der Verarbeitungstätigkeiten und in die TOM-Dokumentation. Für NIS2-pflichtige Unternehmen ist ein verschlüsselndes Label-Modell außerdem ein greifbarer Nachweis für die Kryptografie- und Zugriffskontrollanforderungen des Maßnahmenkatalogs.

Weniger bekannt, aber in Betriebsprüfungen schmerzhaft: Die GoBD verlangen, dass steuerrelevante Unterlagen für den Prüfer lesbar und maschinell auswertbar bleiben – über die gesamte Aufbewahrungsfrist. Ein verschlüsseltes Dokument, das nur eine 2019 gelöschte Gruppe öffnen kann, erfüllt das nicht. Deshalb gehört der Entschlüsselungsweg (Super-User, Prüfergruppe, Exportprozess) in die Verfahrensdokumentation, und deshalb sollten steuerrelevante Bestände eher über Aufbewahrung und Container-Schutz als über harte Verschlüsselung geschützt werden. Und der Betriebsrat: „Zugriff verfolgen und widerrufen" zeigt dem Autor, wer wann versucht hat, ein Dokument zu öffnen – das ist eine Auswertung über Kollegen und damit ein Fall für § 87 Abs. 1 Nr. 6 BetrVG. In der Betriebsvereinbarung sollte stehen, dass die Nachverfolgung nur bei konkretem Anlass genutzt wird und nicht zur Kontrolle des Leseverhaltens. Wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Steuerberater und Betriebsrat gehören an den Tisch.

Stolperfallen aus der Praxis

Verschlüsselung für „Intern". Der Wunsch nach Vollschutz führt dazu, dass achtzig Prozent aller Dokumente verschlüsselt werden – und damit jedes System, das nicht Microsoft heißt, blind ist. „Intern" bleibt unverschlüsselt und wird über DLP und Container geschützt; Verschlüsselung beginnt bei „Vertraulich". Warum das Stufenmodell so aussieht, steht im Spoke zur Einführung von Sensitivity Labels.

Einzelpersonen im Label statt Gruppen. Der Geschäftsführer wird namentlich als Co-Owner eingetragen. Er wechselt, und plötzlich hat niemand mehr Owner-Rechte an fünf Jahren Vorstandsunterlagen. Immer Gruppen, immer mindestens zwei Rollen mit Owner-Recht.

Der Super-User wird „später" eingerichtet. Später ist der Tag, an dem das Archiv migriert wird oder der Prüfer vor der Tür steht. Aktivieren, dokumentieren, testen – vor dem ersten verschlüsselten Dokument.

Benutzerdefinierte Rechte als Standard. Jedes Dokument fragt nach Empfängern, die Anwender tragen sich selbst und den Chef ein, Co-Authoring in SharePoint funktioniert nicht mehr, und die Hälfte der Dokumente ist für den Rest des Teams unsichtbar. Benutzerdefinierte Rechte für ein bewusst gewähltes Label, nicht für die Regelstufe.

Label gelöscht statt zurückgezogen. Das alte Label „Geheim" soll weg, jemand löscht es im Portal – und tausend Dokumente sind verschlüsselt mit einer Richtlinie, zu der es kein Label mehr gibt. Labels werden aus der Richtlinie genommen, nie gelöscht.

Verschlüsselung für steuerrelevante Bestände. Buchungsbelege und Jahresabschlüsse werden „Streng vertraulich" mit Viewer-Rechten für die Finanzleitung – und in acht Jahren fehlt der Prüfer auf der Liste. Für GoBD-Bestände zählt Lesbarkeit über die Frist mehr als der harte Riegel.

Fazit: Der Schutz am Objekt ist stark – und genau deshalb will er vorbereitet sein

Verschlüsselung per Sensitivity Label ist der stärkste Riegel, den Purview kennt, und der einzige, den Copilot wirklich respektieren muss. Sie funktioniert, weil sie am Dokument hängt statt am Ort – und sie tut weh, weil deshalb jedes System und jeder Mensch, der lesen soll, eine Identität braucht. Vier Rechtebündel, Gruppen statt Personen, Verschlüsselung erst ab „Vertraulich", ein aktivierter und dokumentierter Super-User und eine Ausnahmenliste, die vor dem ersten Dokument abgearbeitet wird: Das ist das ganze Konzept. Wo es im Gesamtbild aus Labels, DLP und Aufbewahrung steht, zeigt der Purview-Überblick.

Wenn du wissen willst, welche Systeme in deinem Haus heute an sensible Dokumente wollen und wie ein Verschlüsselungskonzept dafür aussähe: Die Purview-Standortbestimmung klärt genau das – kompakt, zum Festpreis, mit Ausnahmenliste und Aktionsplan.

FAQ: Häufige Fragen zur Verschlüsselung per Sensitivity Label

Was ist der Unterschied zwischen Verschlüsselung per Sensitivity Label und SharePoint-Berechtigungen?

SharePoint-Berechtigungen schützen den Speicherort: Wer eine Datei herunterlädt oder per Mail weiterleitet, verlässt den Schutz. Verschlüsselung per Sensitivity Label schützt das Dokument selbst – der Inhalt ist chiffriert, und nur Benutzer mit passenden Nutzungsrechten können ihn öffnen, egal ob die Datei in SharePoint, auf einem USB-Stick oder in einer fremden Cloud liegt. Beides ergänzt sich; ersetzen tut das eine das andere nicht.

Brauche ich für verschlüsselnde Sensitivity Labels Microsoft 365 E5?

Nein. Verschlüsselnde Labels mit administratorseitig oder benutzerdefiniert festgelegten Nutzungsrechten sind ab Microsoft 365 E3 enthalten, ebenso die Super-User-Funktion. E5 oder ein Add-on wie E5 Compliance brauchst du für automatisches Labeln und den vollen Umfang von Content und Activity Explorer. Double Key Encryption setzt ebenfalls E5 voraus (Stand 2026).

Was ist ein Super-User in Azure Rights Management?

Ein Super-User ist ein Konto, das jedes per Sensitivity Label verschlüsselte Dokument des Tenants entschlüsseln kann, unabhängig von den eingebetteten Nutzungsrechten. Die Funktion ist standardmäßig deaktiviert und wird per PowerShell eingeschaltet. Sie ist nötig für Notfälle (ausgeschiedener Owner, gelöschte Gruppe) und für Dienstkonten von Systemen wie DMS oder Archiv, die verschlüsselte Inhalte lesen müssen. Empfehlung: aktivieren, dokumentieren, über PIM zeitlich begrenzen, Nutzung im Audit-Log prüfen.

Kann Copilot verschlüsselte Dokumente lesen?

Nur, wenn der fragende Benutzer für das Dokument das EXTRACT-Recht (Inhalte kopieren) hat – das ist im Co-Author- und Co-Owner-Bündel enthalten, im Viewer- und Reviewer-Bündel nicht. Fehlt das Recht, verwendet Microsoft 365 Copilot das Dokument nicht als Quelle. Damit ist das Rechtebündel am Label die einzige harte Copilot-Grenze in Microsoft 365.

Was passiert mit verschlüsselten Dokumenten, wenn ich das Label lösche?

Sie bleiben verschlüsselt. Die Richtlinie steckt im Dokument, nicht im Label; wird das Label gelöscht, verlieren die Dokumente aber die Verbindung zur Verwaltung und werden schwer zugänglich. Labels sollten deshalb nie gelöscht, sondern aus der Label-Richtlinie entfernt werden. Änderungen an den Nutzungsrechten eines bestehenden Labels wirken dagegen auf alle bereits verschlüsselten Dokumente, sobald der Client die nächste Nutzungslizenz holt.

Können externe Partner oder Wirtschaftsprüfer verschlüsselte Dokumente öffnen?

Ja, wenn sie eine Identität haben, die Azure Rights Management kennt: ein Entra-Gastkonto (B2B) oder – bei benutzerdefinierten Rechten – eine per Einmalcode verifizierte E-Mail-Adresse. In der Praxis legst du für Prüfer und Kanzleien eine Gruppe mit Viewer-Recht am Label an oder lässt den Owner das Dokument mit Ablaufdatum in einen Datenraum exportieren. Ohne Vorbereitung sieht der Prüfer nur „Sie sind nicht berechtigt".

Wo fange ich mit Verschlüsselung per Sensitivity Label an?

Mit der Ausnahmenliste, nicht mit dem Label: Welche Systeme (DMS, Archiv, Fachanwendungen, Konverter) und welche Menschen (Prüfer, Kanzleien, Kunden) lesen heute Dokumente, die künftig verschlüsselt werden sollen? Danach das Super-User-Feature aktivieren und dokumentieren, ein Label „Vertraulich" mit Co-Author für alle Mitarbeiter und einer zweiten Owner-Gruppe anlegen, mit einer Pilotgruppe testen – und erst dann für die Kronjuwelen ein „Streng vertraulich" mit Viewer-Rechten für benannte Gruppen.