Microsoft Purview | SharePoint Standard-Labels sichern alte Daten

Du richtest eine Dokumentenbibliothek für die Geschäftsführung in SharePoint Online ein. Ein Standard-Vertraulichkeitskennzeichen (Default Sensitivity Label) wird definiert, um menschliche Fehler auszuschließen und "Secure by Default" zu erzwingen.

Die technische Realität sah bisher jedoch anders aus: Die SharePoint-Engine wendete dieses Label ausschließlich auf Dateien an, die nach der Aktivierung der Richtlinie neu hochgeladen oder modifiziert wurden. Der gesamte Altbestand, oft Tausende von Dokumenten, blieb komplett ungeschützt und unverschlüsselt.

Die Ursache hierfür lag tief in der Architektur der Information Protection Engine. Die Verschlüsselung griff bisher nur synchron in dem Moment, wenn sich der File Stream durch eine Nutzeraktion öffnete. Ein asynchroner Batch-Job, der Gigabytes an ruhenden Alt-Daten (Data at rest) nachträglich öffnet, verschlüsselt und speichert, hätte die Azure Storage-Nodes massiv überlastet.

Um diese Lücke zu schließen, warst du in der Vergangenheit gezwungen, teure E5-Auto-Labeling-Richtlinien zu lizenzieren oder komplexe PowerShell-Skripte über die Graph API abzufeuern. Diese Skripte kollidierten regelmäßig mit Throttling-Limits oder zerschossen das Änderungsdatum (Modified Date) der Dateien, wodurch forensische Timestamps für Compliance-Audits unbrauchbar wurden.

Mit dem aktuellen Update (Roadmap ID 559105, Rollout im Mai 2026) verlagert Microsoft diese Compute-Last nun endlich in die eigene Fabric. Wenn du heute das Default-Label auf einer Bibliothek konfigurierst, triggert das Backend einen nativen Timer-Job. Dieser durchläuft den Container systematisch und appliziert die Klassifizierung rückwirkend auf alle ruhenden Dateien.

Der entscheidende Vorteil dieses System-Jobs ist die Erhaltung der Metadaten-Integrität. Die Versionshistorie sowie die "Geändert am"- und "Geändert von"-Felder bleiben unangetastet. Retention Policies und eDiscovery-Hold-Prozesse laufen somit fehlerfrei weiter.

Gleichzeitig verändert sich durch das rückwirkende Labeling die Zugriffsarchitektur auf die Legacy-Daten fundamental. Beinhaltet das angewendete Standard-Label eine Azure Rights Management (RMS) Verschlüsselung, reicht ein simples SharePoint-Leserecht für den Dateizugriff nicht mehr aus. Der Nutzer muss ab sofort ein Entra ID Token präsentieren, das die exakten Kriterien des RMS-Templates erfüllt, um den kryptografischen Content-Key zum Entschlüsseln der Datei zu erhalten.

Ein massenhaftes Update von Dateimetadaten zwingt den SharePoint-Suchindex zwingend zu einer Neuindizierung. Um die allgemeine Tenant-Performance zu schützen, schiebt Microsoft diese Crawls für das automatische Labeling in eine Low-Priority-Queue. Dadurch greifen Data Loss Prevention (DLP) Policies für die Alt-Daten erst zeitverzögert, nämlich exakt dann, wenn der Crawler das neue Label auf der Datei verarbeitet hat. Diesen Zeitversatz musst du in deiner Risikoanalyse dokumentieren.

Zudem implementiert Microsoft ein opportunistisches File Locking, um die Datenintegrität zu wahren. Ist ein fünf Jahre altes Dokument in dem Moment, in dem der Timer-Job es labeln will, durch eine aktive Office Online-Session gesperrt, reiht das System die Datei in eine Retry-Queue ein. Schreibkonflikte beim Co-Authoring werden so technisch auf Backend-Ebene blockiert.

Die Einführung des rückwirkenden Standard-Labels für ruhende Daten eliminiert eine der größten konzeptionellen Schwachstellen im Microsoft Purview-Ökosystem. Aus der Architekturperspektive schließt du damit eine kritische Lücke in deiner Zero-Trust-Strategie, da alte Dateien nicht länger als unverschlüsselter Beifang in ansonsten hochsicheren Bibliotheken verweilen. Dass Microsoft die enorme Rechenlast für Metadaten-Tagging und Neuverschlüsselung nun auf die eigenen Server auslagert, schont deine administrativen Kapazitäten drastisch und verhindert gefährliche Skripting-Fehler.

Dennoch erfordert dieses Feature ein präzises technisches Monitoring. Da die RMS-Verschlüsselung nun asynchron und unsichtbar über den Altbestand rollt, riskierst du bei unsauber konfigurierten Berechtigungen im Label-Template ein hartes Aussperren von Nutzern. Du musst den Fortschritt des Background-Dienstes zwingend auditieren.

Im Activity Explorer überwachst du, wie das Systemkonto die Labels schrittweise anwendet. Kalkuliere bei großen Bibliotheken Laufzeiten von mehreren Tagen ein, bis der Schutz vollständig etabliert ist. Auch die Lizenzierungsfrage erfordert Aufmerksamkeit: Das automatisierte Scannen und Labeln von "Data at rest" fällt konzeptionell tief in den Auto-Labeling-Bereich. Daher dürften in Produktionsumgebungen entsprechende E5- oder E5 Compliance-Lizenzen zwingend erforderlich sein, um die Microsoft-Infrastruktur für diesen Dienst zu nutzen. Wenn du diese Parameter architektonisch berücksichtigst, überführst du deine Legacy-Datensilos endlich in ein revisionssicheres und lückenloses Information-Protection-Konzept.