Eine DLP-Policy, die niemand versteht, schützt niemanden.
Jedes Unternehmen, das Microsoft Power Platform produktiv einsetzt, hat irgendwann diesen Moment: Ein Audit steht an, die IT schaut sich die DLP-Konfiguration an – und plötzlich ist niemandem mehr klar, warum die Policy so aussieht wie sie aussieht. Wer hat das konfiguriert? Wann? Warum ist dieser Connector freigegeben?
Data Loss Prevention in der Power Platform ist kein Selbstläufer. Sie ist ein Konfigurationsobjekt, das ohne aktive Pflege zur Kulisse wird: vorhanden auf dem Papier, wirkungslos in der Realität.
Dieser Artikel ist kein Tutorial zur Connector-Konfiguration – das deckt die Microsoft-Dokumentation ausreichend ab. Es geht hier um die Fehler, die passieren, wenn DLP-Richtlinien ohne Strategie aufgesetzt werden. Und um zwei konkrete Werkzeuge: meine persönliche Meinung dazu, welche Konnektoren in einer Default-Umgebung nichts zu suchen haben – und einen Power Automate Flow, den ihr direkt einsetzen könnt, um eure DLP-Policy automatisch transparent zu machen.
Was DLP in der Power Platform tatsächlich leistet – und was nicht
Data Loss Prevention-Richtlinien in der Power Platform klassifizieren Konnektoren in drei Gruppen:
Business (früher: Business Data Only / HBI) – Konnektoren, die für geschäftliche Daten freigegeben sind und miteinander kombiniert werden dürfen.
Non-Business (früher: Non-Business Data / LBI) – Konnektoren für nicht-geschäftliche Nutzung. Sie können nicht mit Konnektoren der Business-Gruppe in einem Flow kombiniert werden.
Blocked – Konnektoren, die in dieser Umgebung gar nicht verwendet werden dürfen.
Das klingt simpel. Die Tücke liegt im Detail: DLP-Richtlinien kontrollieren Verbindungen, nicht Daten. Eine Policy kann verhindern, dass SharePoint-Daten direkt in einen Twitter-Post fließen. Sie kann nicht verhindern, dass ein Nutzer Daten manuell kopiert. DLP ist also eine Kontrollschicht für automatisierte Flows und Canvas Apps – kein vollständiger Datenschutzmechanismus.
Wer DLP als Allheilmittel betrachtet, baut auf Sand.
Die 5 Fehler, die wir immer wieder sehen
Fehler 1: Eine Policy für alle Umgebungen
Der häufigste Fehler überhaupt. Es gibt eine Tenant-weite DLP-Policy, die für jede Umgebung gilt – von der Default-Umgebung bis zur Produktionsumgebung einer kritischen Geschäftsanwendung.
Das Problem: Der Sicherheitsbedarf ist fundamental verschieden. In der Default-Umgebung haben alle M365-Nutzer automatisch Zugriff. Dort gelten andere Anforderungen als in einer dedizierten Produktionsumgebung mit kontrollierten Benutzern und definierten Lösungen. Eine Einheitsregel passt nicht – sie ist entweder zu restriktiv für Produktionsumgebungen oder zu permissiv für die Default-Umgebung.
Die Lösung: Eine Umgebungsstrategie vor der DLP-Strategie. Dev, Test, Prod, Default – jede Umgebung braucht eine eigene Policy, die zu ihrem Risikoprofil passt.
Fehler 2: Die Default-Umgebung wird unterschätzt
Die Default-Umgebung ist die gefährlichste Umgebung eures Tenants – nicht wegen technischer Schwächen, sondern wegen organisatorischer Realität: Jeder Nutzer mit einer M365-Lizenz hat automatisch Zugriff. Keine Genehmigung, keine Kontrolle, kein Onboarding.
Das bedeutet: Jeder Kollege aus dem Vertrieb, jede neue Mitarbeiterin im HR, jeder externe Berater mit einem Gastkonto – alle können in der Default-Umgebung Flows bauen und Apps erstellen. Mit den Konnektoren, die dort erlaubt sind.
Ich sage das direkt: Eine Default-Umgebung ohne restriktive DLP-Policy ist ein offenes Scheunentor.
Fehler 3: Konnektoren werden freigegeben, ohne dass jemand weiß, was sie können
„Der Vertrieb braucht Salesforce" – also wird der Salesforce-Connector in die Business-Gruppe verschoben. Fertig. Was dabei übersehen wird: Dieser Connector kann jetzt von jedem in der entsprechenden Umgebung genutzt werden, um Daten zwischen SharePoint und Salesforce zu bewegen – in beide Richtungen, ohne weitere Kontrolle.
DLP-Entscheidungen sollten dokumentiert sein: Wer hat den Connector freigegeben? Für welchen Use Case? Mit welcher Begründung? Ohne diese Dokumentation ist die Policy in sechs Monaten nicht mehr nachvollziehbar.
Fehler 4: Keine Transparenz für Maker
Citizen Developer bauen Flows und Apps – oft ohne zu wissen, welche Konnektoren erlaubt sind. Sie scheitern beim Testen, erhalten kryptische Fehlermeldungen und wenden sich an die IT. Das kostet Zeit auf beiden Seiten.
DLP-Richtlinien sollten für alle Maker einsehbar sein. Nicht als trockene Dokumentation auf einem internen Wiki, sondern als lebende Liste – automatisch aktuell, leicht zugänglich. Wie das ohne Aufwand funktioniert, zeige ich weiter unten.
Fehler 5: DLP wird einmal konfiguriert und nie wieder angefasst
Microsoft erweitert die Power Platform kontinuierlich. Neue Konnektoren kommen dazu – und landen standardmäßig in der Non-Business-Gruppe (seit einer Richtlinienänderung 2023 nicht mehr automatisch in Business). Wer seine DLP-Policy nicht regelmäßig reviewed, weiß nicht, ob neue Konnektoren korrekt klassifiziert sind.
Halbjährlicher Review mindestens. Besser: ein automatisierter Alert, wenn neue Konnektoren hinzukommen.
Meine Meinung: Was in der Default-Umgebung nichts zu suchen hat
Das ist keine offizielle Microsoft-Empfehlung. Das ist meine Einschätzung nach Jahren Governance-Arbeit in mittelständischen und Enterprise-Umgebungen.
Die Default-Umgebung verdient die restriktivste DLP-Policy eures Tenants – punkt. Wer das anders sieht, möge mir erklären, warum unkontrollierter Zugriff für tausende Nutzer ein akzeptables Risiko ist.
Diese Konnektoren halte ich in der Default-Umgebung für vertretbar (Business-Gruppe):
- Microsoft 365-Kerndienste: SharePoint, Outlook, Teams, OneDrive, Excel Online, Forms, Planner
- Approvals (Power Automate-native, kein externer Datentransfer)
- Microsoft To Do
- Notifications (intern)
Das war es. Wirklich.
⚠️ Wichtiger Hinweis zu Office-Konnektoren: Outlook, OneDrive, Word, Excel und Microsoft To Do existieren jeweils in zwei Varianten: einmal für Business-Konten (Microsoft 365), einmal für private Microsoft-Konten. In der DLP-Policy sieht das harmlos aus – beide Varianten tauchen nebeneinander auf. Der Unterschied ist aber entscheidend: Die private Variante authentifiziert sich gegen Consumer-Infrastruktur. Maker, die versehentlich die falsche Variante in einem Flow verwenden, erhalten beim Verbindungsaufbau einen Anmeldefehler – und rätseln, warum ihre Unternehmensanmeldedaten nicht funktionieren. In der Business-Gruppe haben ausschließlich die (Business)-Varianten dieser Konnektoren etwas verloren. Die privaten Pendants gehören in Blocked.
Blocked in der Default-Umgebung:
Alles, was nicht explizit in Business steht, gehört in Blocked – soweit technisch möglich. Das klingt rigide, ist es auch, und zwar absichtlich. Microsoft erlaubt es nicht, jeden Connector zu blockieren: Einige sind systemseitig als nicht blockierbar markiert. Diese landen als einzige Ausnahme in Non-Business.
In der Praxis bedeutet das: Non-Business ist in der Default-Umgebung keine inhaltliche Kategorie, sondern ein technischer Auffangbehälter für das, was sich nicht blocken lässt.
- Alle Drittanbieter-Konnektoren → Blocked
- HTTP-Konnektoren → Blocked (universelle Datenpumpen, nichts für eine unkontrollierte Umgebung)
- SQL Server, Azure Blob Storage und vergleichbare Datenbankconnectoren → Blocked
- Premium-Konnektoren → Blocked (wer Premium-Lizenzen kontrolliert vergibt, sollte die zugehörigen Konnektoren ebenfalls nur in kontrollierten Umgebungen zulassen)
- Nicht blockierbare Konnektoren → Non-Business (technische Notwendigkeit, keine Designentscheidung)
Default Group der Policy auf Blocked setzen:
In jeder DLP-Policy gibt es eine Default Group – sie legt fest, in welche Gruppe neue Konnektoren automatisch einsortiert werden, wenn Microsoft sie hinzufügt, ohne dass ihr die Policy aktualisiert habt. Diese Default Group gehört für die Default-Umgebung auf Blocked.
Eine berechtigte Frage taucht hier regelmäßig auf: Was macht Microsoft, wenn ein neuer Connector hinzukommt, der technisch nicht blockiert werden darf? Die Antwort ist ernüchternd – Microsoft kann in diesem Fall nicht garantieren, dass der Connector in Blocked bleibt. In der Praxis hat Microsoft einzelne Konnektoren nach ihrer Einführung nachträglich aus der Blocked-Gruppe herausgenommen, weil systemseitige Abhängigkeiten dies erforderten. Das ist selten, kommt aber vor.
Das ändert nichts an der Empfehlung: Default Group auf Blocked, und einen regelmäßigen Review einplanen. Wer zusätzlich den Transparenz-Flow aus dem nächsten Abschnitt einsetzt, sieht solche Änderungen automatisch in seiner SharePoint-Liste – und kann reagieren, bevor sie jemand anderem auffallen.
Wenn ein Maker in der Default-Umgebung einen Connector benötigt, der dort nicht freigegeben ist, ist das kein Problem – es ist ein Signal. Ein Signal, dass der Use Case eine eigene Umgebung mit angemessener Governance verdient.
DLP-Transparenz ohne Aufwand: Ein Flow, der die Arbeit erledigt
Jetzt zum praktischen Teil.
Das größte Transparenzproblem bei DLP ist nicht die fehlende Dokumentation – es ist die veraltete Dokumentation. Wer kennt das nicht: Eine Excel-Tabelle mit den freigegebenen Konnektoren, die seit 14 Monaten nicht mehr aktualisiert wurde.
Die Lösung ist einfacher als gedacht. Ihr lasst einen wöchentlichen Power Automate Flow laufen, der eure DLP-Policy automatisch ausliest und die Ergebnisse in eine SharePoint-Liste schreibt. Diese Liste ist im Intranet standardmäßig einsehbar – für alle Maker, ohne Login-Hürden, immer aktuell.
Voraussetzungen
- Power Platform for Admins Connector (benötigt Power Platform Admin-Rolle oder entsprechende delegierte Berechtigung)
- SharePoint Online Connector
- Eine SharePoint-Liste mit folgenden Spalten:
Title(einzeiliger Text) – Connector-NameId(einzeiliger Text) – Connector-IdCategory(Auswahl) – "Business", "Non-Business", "Blocked"Policy(Auswahl) – "Default", (und evtl weitere Policies)
Flow-Architektur
Der Flow besteht aus zwei Scopes, die nacheinander laufen:
- Scope: Bestehende Einträge löschen – die Liste wird vor jedem Lauf geleert, um Duplikate zu vermeiden
- Scope: DLP Policy auslesen & schreiben – für jede Connector-Gruppe (HBI/Business, LBI/Non-Business) werden die Konnektoren aus der Policy gelesen und als Listeneintrag angelegt
Der Flow als JSON
Der folgende Flow-Code ist vollständig anonymisiert. Alle kundenspezifischen IDs sind durch Variablen ersetzt, die ihr anpassen müsst.
Vor dem Import anpassen:
DEINE_POLICY_ID→ die GUID eurer DLP-Policy (zu finden im Power Platform Admin Center unter Richtlinien → Datenverlustschutz → URL der Policy)DEINE_SPO_SITE_URL→ vollständige URL eurer SharePoint-Site (z.B.https://euerunternehmen.sharepoint.com/sites/intranet)DEINE_SPO_LISTEN_ID→ die GUID eurer SharePoint-Liste (zu finden in den Listeneinstellungen in der URL)
{
"name":"5f2ce714-a2b6-44b6-b914-83e966af624b",
"id":"/providers/Microsoft.Flow/flows/5f2ce714-a2b6-44b6-b914-83e966af624b",
"type":"Microsoft.Flow/flows",
"properties":{
"apiId":"/providers/Microsoft.PowerApps/apis/shared_logicflows",
"displayName":"DLP Policy Monitor Flow",
"description": "Liest wöchentlich eine DLP-Policy aus und schreibt alle Connectoren (HBI/LBI) in eine SharePoint-Liste.",
"definition":{
"metadata":{
"workflowEntityId":null,
"processAdvisorMetadata":null,
"flowChargedByPaygo":null,
"flowclientsuspensionreason":"None",
"flowclientsuspensiontime":null,
"flowclientsuspensionreasondetails":null,
"provisioningMethod":"FromDefinition",
"failureAlertSubscription":true,
"creationSource":"Portal",
"modifiedSources":"Portal"
},
"$schema":"https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json",
"contentVersion":"undefined",
"parameters":{
"$authentication":{
"defaultValue":{
},
"type":"SecureObject"
},
"$connections":{
"defaultValue":{
},
"type":"Object"
}
},
"triggers":{
"Recurrence":{
"recurrence":{
"frequency":"Week",
"interval":"1",
"startTime":"2026-04-11T02:00:00.000Z",
"schedule":{
"weekDays":[
"Sunday"
]
}
},
"evaluatedRecurrence":{
"frequency":"Week",
"interval":"1",
"startTime":"2026-04-11T02:00:00.000Z",
"schedule":{
"weekDays":[
"Sunday"
]
}
},
"type":"Recurrence"
}
},
"actions":{
"Initialize_variable_SPO-Site":{
"runAfter":{
},
"type":"InitializeVariable",
"inputs":{
"variables":[
{
"name":"SPO-Site",
"type":"string",
"value":""
}
]
}
},
"Initialize_variable_SPO-List":{
"runAfter":{
"Initialize_variable_SPO-Site":[
"Succeeded"
]
},
"type":"InitializeVariable",
"inputs":{
"variables":[
{
"name":"SPO-List",
"type":"string",
"value":""
}
]
}
},
"Initialize_variable_Policy":{
"runAfter":{
"Initialize_variable_Policy":[
"Succeeded"
]
},
"type":"InitializeVariable",
"inputs":{
"variables":[
{
"name":"Policy",
"type":"string",
"value":""
}
]
}
},
"Scope_empty_list":{
"actions":{
"Get_current_items":{
"type":"OpenApiConnection",
"inputs":{
"parameters":{
"dataset":"@variables('SPO-Site')",
"table":"@variables('SPO-List')",
"$filter":"Id ge 0"
},
"host":{
"apiId":"/providers/Microsoft.PowerApps/apis/shared_sharepointonline",
"connectionName":"shared_sharepointonline",
"operationId":"GetItems"
},
"authentication":"@parameters('$authentication')"
}
},
"For_each":{
"foreach":"@outputs('Get_current_items')?['body/value']",
"actions":{
"Delete_item":{
"type":"OpenApiConnection",
"inputs":{
"parameters":{
"dataset":"@variables('SPO-Site')",
"table":"@variables('SPO-List')",
"id":"@item()?['ID']"
},
"host":{
"apiId":"/providers/Microsoft.PowerApps/apis/shared_sharepointonline",
"connectionName":"shared_sharepointonline",
"operationId":"DeleteItem"
},
"authentication":"@parameters('$authentication')"
}
}
},
"runAfter":{
"Get_current_items":[
"Succeeded"
]
},
"type":"Foreach"
}
},
"runAfter":{
"Initialize_variable_SPO-List":[
"Succeeded"
]
},
"type":"Scope"
},
"Scope_Default_DLP":{
"actions":{
"Get_Tenant_DLP_Policy":{
"type":"OpenApiConnection",
"inputs":{
"parameters":{
"policy":"@variables('Policy')",
"api-version":"2018-10-01"
},
"host":{
"apiId":"/providers/Microsoft.PowerApps/apis/shared_powerplatformforadmins",
"connectionName":"shared_powerplatformforadmins",
"operationId":"GetTenantPolicy"
},
"authentication":"@parameters('$authentication')"
}
},
"For_each_Business_Connector":{
"foreach":"@outputs('Get_Tenant_DLP_Policy')?['body/properties/definition/apiGroups/hbi/apis']",
"actions":{
"Create_item":{
"type":"OpenApiConnection",
"inputs":{
"parameters":{
"dataset":"@variables('SPO-Site')",
"table":"@variables('SPO-List')",
"item/Title":"@items('For_each_Business_Connector')?['name']",
"item/Category/Value":"Business",
"item/id0":"@items('For_each_Business_Connector')?['id']",
"item/PolicyEnv/Value":"Default"
},
"host":{
"apiId":"/providers/Microsoft.PowerApps/apis/shared_sharepointonline",
"connectionName":"shared_sharepointonline",
"operationId":"PostItem"
},
"authentication":"@parameters('$authentication')"
}
}
},
"runAfter":{
"Get_Tenant_DLP_Policy":[
"Succeeded"
]
},
"type":"Foreach"
},
"For_each_Non-Business_Connector":{
"foreach":"@outputs('Get_Tenant_DLP_Policy')?['body/properties/definition/apiGroups/lbi/apis']",
"actions":{
"Create_item_1":{
"type":"OpenApiConnection",
"inputs":{
"parameters":{
"dataset":"@variables('SPO-Site')",
"table":"@variables('SPO-List')",
"item/Title":"@items('For_each_Non-Business_Connector')?['name']",
"item/Category/Value":"Non-Business",
"item/id0":"@items('For_each_Non-Business_Connector')?['id']",
"item/PolicyEnv/Value":"Default"
},
"host":{
"apiId":"/providers/Microsoft.PowerApps/apis/shared_sharepointonline",
"connectionName":"shared_sharepointonline",
"operationId":"PostItem"
},
"authentication":"@parameters('$authentication')"
}
}
},
"runAfter":{
"For_each_Business_Connector":[
"Succeeded"
]
},
"type":"Foreach"
}
},
"runAfter":{
"Scope_empty_list":[
"Succeeded"
]
},
"type":"Scope"
}
}
},
"connectionReferences":{
"shared_sharepointonline":{
"connectionName":"shared-sharepointonl-1a7603e9-3734-4475-b6b1-6d000c8fc382",
"source":"Embedded",
"id":"/providers/Microsoft.PowerApps/apis/shared_sharepointonline",
"tier":"NotSpecified",
"apiName":"sharepointonline",
"isProcessSimpleApiReferenceConversionAlreadyDone":false
},
"shared_powerplatformforadmins":{
"connectionName":"shared-powerplatform-8e3aa729-7007-40fa-87de-1e515b98c559",
"source":"Embedded",
"id":"/providers/Microsoft.PowerApps/apis/shared_powerplatformforadmins",
"tier":"NotSpecified",
"apiName":"powerplatformforadmins",
"isProcessSimpleApiReferenceConversionAlreadyDone":false
}
},
"flowFailureAlertSubscribed":false,
"isManaged":false
}
}Import-Anleitung
- Ladet den Flow über das Formular weiter unten herunter und speichert die ZIP-Datei in euren Downloads.
- Öffne Power Automate → Meine Flows → Importieren → Flow-Paket importieren.
- Wählt die ZIP-Datei aus.
- Passt nachdem Import die drei Parameter an:
Policy,SPO-Site,SPO-List. - Weist die Verbindungen zu: Power Platform for Admins (Admin-Konto erforderlich) und SharePoint Online.
- Aktiviert den Flow – er läuft ab sofort jeden Montag um 6:00 Uhr.
Hinweis zur Berechtigung: Der Flow benötigt ein Dienstkonto mit Power Platform Admin-Berechtigung oder zumindest delegierter DLP-Leseberechtigung. Legt dafür kein persönliches Konto an – ein dediziertes Dienstkonto (Service Account) für Governance-Automatisierungen ist Best Practice.
Was ihr daraus macht
Die SharePoint-Liste könnt ihr direkt im Intranet verlinken – sichtbar für alle Maker, keine spezielle Berechtigung notwendig. Noch besser: Baut eine einfache Canvas App darüber, mit Filteroptionen nach Gruppe, und verlinkt sie aus eurem Power Platform Maker Onboarding heraus.
Wer fragt, welche Konnektoren erlaubt sind, bekommt eine lebende, immer aktuelle Antwort – ohne dass die IT jedes Mal gefragt werden muss.
Was das alles bedeutet
DLP in der Power Platform ist keine Einmal-Konfiguration. Es ist ein laufender Prozess – und wie jeder laufende Prozess braucht er Struktur, Dokumentation und regelmäßige Überprüfung.
Die fünf Fehler, die ich beschrieben habe, sind nicht Ausdruck von Fahrlässigkeit. Sie sind das natürliche Ergebnis davon, dass Governance nachträglich auf gewachsene Strukturen aufgesetzt wird – statt von Anfang an eingeplant zu sein.
Wenn ihr nicht sicher seid, wie gut eure aktuelle DLP-Konfiguration aufgestellt ist: Macht den Power Platform Governance Quick Check. Zehn Fragen, ehrliche Auswertung, klares Ergebnis.