Heute ergab sich im Kurs SC 200 (Schutz vor Cyberthreats mit der Sicherheitsbetriebsplattform von Microsoft) eine interessante Teilnehmerfrage im Kontext des „Defender for Cloud-Apps“ (MDCA), der sich bekanntlich um den Umgang mit SaaS-Applikationen, verbundenen Apps und das Thema „Schatten-IT“ kümmert. Administratoren können hier verschiedene Arten von Richtlinien erstellen, u. a. „Sitzungsrichtlinien“ im Tab „Bedingter Zugriff“, die eine gewisse Verwandtschaft zu DLP in Purview suggerieren. Hier geht aber tatsächlich um etwas anderes.
Außerdem gibt es beim MDCA noch den Richtlinien-Typ „Information Protection“ mit der Möglichkeit, „Dateirichtlinien“ zu erstellen, wodurch ebenfalls eine gewisse Verwandtschaft zu Purview AIP suggeriert wird, die hier aber „bedingt“ berechtigt ist, insofern dass Purview-Sensitivity-Labels berücksichtigt werden. Ich werde das in diesem kleinen Beitrag aufdröseln.
Das Thema Richtlinien Im MDCA ist für viele Nutzer verwirrend, weil dort mehrere Richtlinienquellen „zusammenlaufen“, darunter :
- MDCA‑eigene Richtlinien
- Vorlagen
- Automatisch aktivierte Erkennungen
- Verknüpfte Regeln aus anderen Produkten (MDE, Purview, Entra)
Die Richtlinien finden sich unter „Cloud-Apps / Richtlinien / Richtlinienverwaltung“ und verteilen sich auf die Bereiche „Bedrohungserkennung“ (Aktivitätsrichtlinie, OAuth-App-Richtlinie), „Information Protection“ (Dateirichtlinie), „Bedingter Zugriff“ (Zugriffsrichtlinie, Sitzungsrichtlinie) und „Schatten-IT“ (App-Ermittlungsrichtlinie“).
Zusätzlich kommen vom Microsoft Defender for Endpoint (MDE) ….
- Device Discovery Signale (Cloud Discovery Daten)
- SaaS-App Risiken aus Endpoint-Verhalten
- Ungewöhnliche Endpunktaktivitäten (korrelierte Alerts)
Allerdings liefert MDE liefert keine Richtlinien direkt in Cloud Apps, sondern liefert nur Daten, die in MDCA‑Regeln verwendet werden. MDCA nutzt diese Regeln nur in verbundenen SaaS‑Apps.
Zudem kommen von Entra ID …
- OAuth App Erkennungen
- Identity Risk Events
- Sign-In Patterns
Diese triggern MDCA‑Threat‑Detection Alerts.
Das Problem für MCDA-Neulinge: Diese sehen native MDCA Policies, automatisch aktive Threat Detection Policies, Templates/Vorlagen sowie verknüpfte Policies aus Purview und/oder Entra, d. h. nicht jede Richtlinie kommt direkt aus MDCA, einige sind nur „Frontends“ für andere Microsoft Security Produkte.
Schließlich der Aufhänger für diesen Beitrag: MDCA integriert sich zum Teil mit Purview über Labels (AIP/MIP); „echte“ Purview‑DLP‑Regeln allerdings bleiben Purview vorbehalten und erscheinen nicht in MDCA. MDCA hat nämlich eigene Dateirichtlinien und eigene Echtzeit‑Kontrollen (Session Control).“
Deshalb erkläre ich jetzt für die beiden oben fett gedruckten Richtlinientypen den im MCDA-Kontext widersprüchlich verwendeten DLP-Begriff.
Was bedeutet DLP bei MDCA konkret?
Eine gewisse Verwirrung kommt daher, dass Microsoft selbst den Begriff DLP an zwei komplett verschiedenen Stellen benutzt, obwohl sie völlig unterschiedliche Technologien meinen:
- Purview DLP (klassische DLP-Engine für M365, Exchange, SharePoint, OneDrive usw.)
- MDCA DLP / Echtzeit-DLP (Session Control); die o. e. Sitzungsrichtlinie
Hier der Unterschied:
Purview DLP (klassische DLP): Diese Regeln werden in Microsoft Purview erstellt und sind NICHT in MDCA sichtbar. Bei Purview DLP handelt es sich um klassische Inhaltsprüfung ( z. B. „Dokument enthält IBAN“). MDCA kann sie auch nicht ausführen oder anzeigen. Sie gelten für:
- Exchange Online
- SharePoint
- OneDrive
- Teams
- Endpoint DLP
- Power BI DLP
- Insider Risk Integration
MDCA Echtzeit‑DLP (Sitzungsrichtlinie). Die Funktion heißt bei Microsoft trotzdem „DLP“, weil sie Datenverlust verhindert. Diese „DLP“ läuft in der Browser-Sitzung mithilfe von …
- Conditional Access App Control
- Reverse Proxy Session
- MDCA Session Policies
und wird in MDCA aktiviert – aber in Entra geroutet.
Sie kann z. B.:
- Upload blockieren
- Download blockieren
- Copy/Paste verhindern
- Screenshots unterbinden
- Datei-Downloads markieren
Beispiel: Sie haben eine App als „Connected App“ in MDCA verbunden, (z. B. Microsoft 365, Dropbox, Google Workspace):
Sie nutzten Entra Conditional Access (P1 oder höher) und haben eine Conditional Access Policy, die den Session‑Proxy aktiviert
Was bedeutet Information Protection bei MDCA konkret?
Der zweite Punkt, der Nutzer bzgl. der „Verwandtschaft“ von MDCA mit Purview mitunter verwirrt sind Richtlinien im Bereich „Information Protection“. Hier können Sie eine „Dateirichtlinie“ (File Policy) erstellen. Diese kann:
- sensible Dateien erkennen
- öffentliche Freigaben finden
- automatische Governance anwenden (Zugriff entfernen, Link löschen, Label setzen)
Auch hierbei handelt es sich um eine reine MDCA-Funktion, d. h. sie nutzt weder Purview AIP oder DLP, also keine Purview-DLP-Regeln und auch keine Purview-AIP-Richtlinien. Eine solche Richtlinie kann z. B.:
- Dateien in SaaS‑Apps scannen
- Dateien mit bestimmten Labels finden
- öffentliche oder externe Freigaben erkennen
- Governance-Aktionen durchführen (Link löschen, Zugriff entfernen, Label anwenden)
Eventuell ist der Name des Tabs „Information Protection“ von Microsoft nicht ganz glücklich gewählt aber durchaus mit Berechtigung, denn die Funktion (und hier besteht tatsächlich eine Querverbindung zu Purview) kann Sensitivity Labels (SITs) aus Purview erkennen und nutzen.
