Microsoft Purview | Ende der DLP-Latenz ⏱ 3 Min.

Microsoft Purview | Ende der DLP-Latenz

Bisherige Data Loss Prevention (DLP) in SharePoint Online leidet unter einem fundamentalen Architekturproblem: der asynchronen Verarbeitung. Lädt ein User eine Datei hoch, reiht das System diesen Inhalt in die Warteschlange des Such-Crawlers ein. Erst nach Abschluss der Indexierung evaluiert die DLP-Engine die Datei gegen aktive Richtlinien. In diesem Zeitfenster – dem Detection Gap – ist der Inhalt auf Cloud-Ebene ungeschützt. Angreifer und böswillige Insider nutzen diese Latenz für „Smash-and-Grab“-Aktionen, indem sie sensible Daten hochladen und sofort externe Freigabelinks generieren, bevor Purview den Zugriff algorithmisch sperren kann.

JIT-Interception in SharePoint

Die Just-in-Time (JIT) Protection (Roadmap ID 139457), die nach aktueller Planung im Oktober 2026 in die Preview geht, schließt diese Lücke. Du musst die kausalen Zusammenhänge zwischen SharePoint-APIs und Endpoint-Defender verstehen, um JIT fehlerfrei zu implementieren und Operations-Ausfälle zu vermeiden.

Die klassische DLP scannt Daten im Ruhezustand. JIT verlagert den Prüfpunkt direkt in den Egress-Pfad. Sobald ein API-Call zum Herunterladen oder Teilen einer unklassifizierten Datei abgesetzt wird, triggert das System einen Request-Hold. SharePoint friert den Datenstrom auf Netzwerkebene für Millisekunden ein. Während dieses Holds lädt die Purview-Engine den Inhalt in den Arbeitsspeicher (On-the-fly Scan) und gleicht ihn synchron mit den konfigurierten DLP-Policies ab. Erst wenn die Engine keinen Richtlinienverstoß meldet, gibt sie den Byte-Stream für den User frei.

Endpoint-Integration: 3-Sekunden-Regel

Auf Endpunkt-Ebene (Windows/macOS) integriert sich die JIT-Logik nativ in den Microsoft Defender. Versucht der User, einen JIT-Kandidaten (z.B. eine unbekannte Datei) auf einen USB-Stick zu kopieren, greift die 3-Sekunden-Regel. Dies ist zwingend notwendig, um I/O-Blockaden des Betriebssystems zu verhindern. Der Defender blockiert den File-System-Zugriff und übergibt den Hash an den lokalen DLP-Agenten.

Schließt der Agent die Evaluierung innerhalb von 3 Sekunden ab, triggert das System einen Auto-Resume. Der Kopiervorgang im Windows Explorer läuft transparent weiter. Dauert die Prüfung länger, verweigert das System den Zugriff auf das Speichermedium hart. Das Betriebssystem wirft eine Toast-Notification („Evaluation in progress“). Erst nach asynchronem Abschluss des Scans muss der User die Aktion manuell wiederholen (Repeat Action).

Fallback: Fail-Open vs. Fail-Closed

Die synchrone Natur von JIT erzwingt die Definition einer Fallback Action. Du konfigurierst zentral, wie sich das System bei unerreichbarer Purview-Cloud oder bei Scan-Timeouts verhält.

Setzt Du den Fallback auf „Block“ (Fail-Closed), verhinderst Du Datenabflüsse kompromisslos. Du provozierst bei temporären Tenant-Latenzen jedoch einen vollständigen Stillstand der Arbeitsprozesse, da SharePoint dann alle unklassifizierten Downloads global sperrt. Du solltest den Fallback initial auf „Allow users to complete actions“ setzen (Fail-Open), um das Systemverhalten über Audit-Logs im Activity Explorer auszuwerten, bevor Du den harten Block aktivierst.

Grenzen: OCR & Drittanbieter-Verschlüsselung

Besonders der Einsatz von Optical Character Recognition (OCR) treibt die Scan-Zeiten in die Höhe. Da Purview für JIT auf Azure OCR-Dienste zugreift, um Text aus Bildern zu extrahieren, reißt die Endpunkt-Prüfung häufiger die 3-Sekunden-Marke.

Bei Drittanbieter-Verschlüsselungen (z. B. PGP) stößt JIT an seine architektonischen Grenzen. Der On-the-fly Scan extrahiert hier nur unlesbare Strings, wodurch die Policy das Dokument standardmäßig als "nicht scannbar" blockiert. Dies zwingt Dich architektonisch dazu, auf natives Microsoft Information Protection (MIP) Labeling umzusteigen, da Purview MIP-Dateien im RAM verarbeiten kann.

Fazit: Die Lücke ist geschlossen

Mit JIT Protection eliminiert Microsoft das historische Detection Gap physisch durch den Request-Hold im Egress-Pfad. Für Deine Architektur bedeutet dies eine massive Konsolidierungschance: Du kannst externe Cloud Access Security Broker (CASB) zurückbauen, da native SharePoint-APIs die Echtzeit-Kontrolle in der Cloud übernehmen. Die Sicherheit verschiebt sich fundamental von der Klassifizierung im Ruhezustand zur Kontrolle bei reiner Datenbewegung.

Kritisch bleibt die User Experience am Endpunkt. Du musst sicherstellen, dass Dein Helpdesk auf die Toast-Notifications der 3-Sekunden-Regel vorbereitet ist und Du die Telemetrie auf JIT-Timeouts überwachst. Wenn Du Drittanbieter-Verschlüsselung nutzt, plane den Wechsel zu MIP, da JIT diese Fremdformate im Fail-Safe-Modus rigoros blockieren wird, wodurch legitime Business-Prozesse unterbrochen werden.

Teilen:
Noch keine Kommentare

Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.

Kommentar hinterlassen

Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.

E-Mail Adresse wird nicht veröffentlicht.