DLP-Richtlinien für Einsteiger

Sobald mehrere Kolleginnen und Kollegen in Power Automate eigene Flows bauen, entsteht ein blinder Fleck. Niemand weiß mehr, wer welche Daten mit welchem Dienst verbindet. Landen dabei Kundendaten aus SharePoint in einem privaten Postfach, merkt es zunächst niemand.

Genau dafür gibt es Data Loss Prevention, kurz DLP. Eine DLP-Richtlinie legt fest, welche Connectors in einer Umgebung erlaubt sind. Sie bestimmt außerdem, welche Connectors sich innerhalb eines Flows kombinieren lassen. Laut Microsoft wirken Datenrichtlinien als Schutzschienen gegen den unbeabsichtigten Abfluss von Unternehmensdaten.

Dieser Beitrag erklärt die Grundbegriffe, zeigt den Weg zur ersten Richtlinie im Power Platform Admin Center und beschreibt, was bei einem Verstoß tatsächlich passiert.

Was eine DLP-Richtlinie eigentlich regelt

Eine DLP-Richtlinie ordnet jeden Connector genau einer von drei Gruppen zu und verbietet den Datenfluss zwischen den Gruppen. Connectors sind stark typisierte Darstellungen von APIs. Über sie lesen und schreiben Flows Daten.

Die Gruppennamen tragen keine technische Bedeutung. Wichtig ist allein, welche Connectors zusammen in einer Gruppe stehen.

Gruppe im Admin Center | Wert in PowerShell und API | Wirkung

Gruppe im Admin Center: Geschäftlich (Business) · Wert in PowerShell und API: Confidential · Wirkung: Kombination nur mit anderen Connectors derselben Gruppe

Gruppe im Admin Center: Nicht geschäftlich (Non-business) · Wert in PowerShell und API: General · Wirkung: Standardgruppe, Kombination nur innerhalb der Gruppe

Gruppe im Admin Center: Blockiert (Blocked) · Wert in PowerShell und API: Blocked · Wirkung: Connector ist im Geltungsbereich gar nicht nutzbar

Gruppe im Admin Center: Nur für Custom-Connector-Regeln · Wert in PowerShell und API: Ignore · Wirkung: Das URL-Muster wird nicht bewertet

Ein Beispiel aus der Microsoft-Dokumentation macht den Effekt greifbar. Stehen SharePoint und Salesforce in der Gruppe Geschäftlich, dürfen beide Daten austauschen. Nutzt derselbe Flow zusätzlich Outlook.com aus der Gruppe Nicht geschäftlich, wird er blockiert.

Nicht jeder Connector lässt sich sperren. Microsoft-eigene Standard-Connectors wie SharePoint und die Dataverse-Connectors sind nicht blockierbar. Klassifizieren können Sie sie trotzdem.

Wo eine Richtlinie greift: Entwurfszeit und Laufzeit

Eine Richtlinie greift an zwei Stellen, beim Speichern eines Flows und danach durch einen Hintergrundauftrag. Beide Wege haben unterschiedliche Laufzeiten.

Zur Entwurfszeit prüft Power Automate den Flow beim Erstellen und Ändern. Bei Flows ohne untergeordnete Flows läuft die Prüfung synchron in Echtzeit. Enthält ein Flow untergeordnete Flows, erfolgt die Auswertung asynchron innerhalb von 24 Stunden.

Ändern Sie eine Richtlinie, durchsucht ein Hintergrundauftrag alle aktiven Flows der Umgebung. Auch das geschieht asynchron innerhalb von 24 Stunden. Zusätzlich läuft wöchentlich eine Konsistenzprüfung über alle aktiven Flows.

Die Rückkehr funktioniert ebenfalls automatisch. Cloud-Flows, die in den vergangenen sieben Tagen gesperrt wurden, werden wieder aktiviert, sobald sie keine Richtlinie mehr verletzen.

Woran Sie eine DLP-Sperre eindeutig erkennen

Ein wegen DLP gesperrter Flow trägt den Status Suspended und den Grund CompanyDlpViolation. Diese Felder liefern die API, PowerShell und die Aktion „List Flows as Admin" des Power-Automate-Management-Connectors.

So sieht der relevante Ausschnitt der Antwort aus:

1{
2  "name": "6df8ec2d-3a2b-49ef-8e91-942b8be3202f",
3  "properties": {
4    "displayName": "Rechnungen nach SharePoint ablegen",
5    "state": "Suspended",
6    "flowSuspensionReason": "CompanyDlpViolation",
7    "flowSuspensionTime": "2026-08-14T09:12:47.113Z"
8  }
9}
Copy

Sie müssen also nicht raten, warum ein Flow plötzlich steht. Ohne diese Felder liegt die Ursache woanders, etwa bei einer abgelaufenen Verbindung.

Wer Richtlinien anlegen darf: Mandant oder Umgebung

Richtlinien entstehen auf Mandanten- oder Umgebungsebene, und die Mandantenebene gewinnt immer. Umgebungsrichtlinien können eine Mandantenrichtlinie ergänzen, aber nicht aushebeln.

Kriterium | Mandantenebene | Umgebungsebene

Kriterium: Erforderliche Rolle · Mandantenebene: Power Platform-Administrator · Umgebungsebene: Umgebungsadministrator, mit Dataverse Systemadministrator

Kriterium: Geltungsbereich · Mandantenebene: Gesamter Mandant, Umgebungen ein- oder ausschließbar · Umgebungsebene: Genau eine Umgebung

Kriterium: Änderbar durch Umgebungsadmin · Mandantenebene: Nein · Umgebungsebene: Ja

Kriterium: Verhältnis bei mehreren Richtlinien · Mandantenebene: Die strengste Regel für die Connector-Kombination gilt · Umgebungsebene: Die strengste Regel gilt

Klären Sie früh, wer die Mandantenrolle trägt. Davon hängt ab, wer später überhaupt Änderungen vornehmen darf.

Schritt für Schritt zur ersten Richtlinie

Der Weg zu einer funktionierenden Richtlinie besteht aus sieben Schritten im Admin Center.

1. Im Power Platform Admin Center unter Sicherheit den Bereich Daten und Datenschutz öffnen, dann Datenrichtlinie und Neue Richtlinie.
2. Einen sprechenden Namen vergeben, zum Beispiel „Produktivumgebungen Standard".
3. Connectors den Gruppen Geschäftlich, Nicht geschäftlich oder Blockiert zuordnen.
4. Die Standardgruppe für künftige Connectors festlegen. Microsoft empfiehlt hier Nicht geschäftlich.
5. Bei Bedarf Regeln für benutzerdefinierte Connectors über URL-Muster ergänzen.
6. Den Geltungsbereich setzen, also Umgebungen einschließen oder ausschließen.
7. Die Übersicht prüfen und die Richtlinie erstellen.

Richtlinien per PowerShell prüfen und pflegen

Für wiederkehrende Prüfungen ist PowerShell schneller als die Oberfläche, weil sich Richtlinien so versioniert dokumentieren lassen. Das Administratormodul benötigt Windows PowerShell 5.x.

1Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
2Add-PowerAppsAccount
3
4# Alle Datenrichtlinien des Mandanten auflisten
5Get-DlpPolicy | Select-Object PolicyName, DisplayName
6
7# Einen Connector in die Gruppe Geschaeftlich verschieben
8$business = @([pscustomobject]@{
9    id   = "/providers/Microsoft.PowerApps/apis/shared_sharepointonline"
10    name = "SharePoint"
11    type = "providers/Microsoft.PowerApps/apis"
12})
13
14Add-ConnectorsToPolicy `
15    -PolicyName "7b914a18-ad8b-4f15-8da5-3155c77aa70a" `
16    -Connectors $business `
17    -Classification Confidential
Copy

PolicyName ist die GUID aus Get-DlpPolicy, nicht der Anzeigename. Steht ein Connector bereits in einer anderen Gruppe, verschiebt ihn der Befehl.

Ergänzen Sie außerdem eine Kontaktadresse für Fehlermeldungen. Über New-PowerAppDlpErrorSettings erscheinen eine Governance-URL und eine E-Mail-Adresse direkt in der Fehlermeldung der Erstellenden.

Typische Fehler und Ursachen

Die meisten Störungen rund um DLP haben fünf wiederkehrende Ursachen, und alle sind ohne Ticket lösbar.

Meldung „Looks like this workflow is disabled by your organization"

Ursache: Der Flow verletzt eine Datenrichtlinie und wurde gesperrt. Lösung: Die Flow-Prüfung im Designer nennt die betroffene Aktion. Entfernen Sie die Kombination oder lassen Sie die Richtlinie anpassen. Quelle: Troubleshoot Power Automate trigger problems.

Desktop-Flow-Module werden trotz Standardgruppe nicht blockiert

Ursache: Bei Desktop-Flows gilt die Standardgruppe nicht. Nur explizit zugeordnete Module und Aktionen werden ausgewertet. Lösung: Verschieben Sie jedes relevante Modul bewusst in eine Gruppe. Quelle: DLP policy creation.

Richtlinie gespeichert, der Flow läuft trotzdem weiter

Ursache: Der Hintergrundauftrag arbeitet asynchron und braucht bis zu 24 Stunden. Lösung: Auswertung abwarten oder den Flow speichern, damit die Prüfung sofort greift. Quelle: DLP policy creation.

Connectors fehlen in der PowerShell-Ausgabe

Ursache: Bekannte Einschränkung. Get-DlpPolicy gibt Connectors der Standardgruppe nicht zurück, solange sie nie verschoben wurden. Lösung: Connector einmal in eine andere Gruppe und wieder zurück verschieben. Quelle: PowerShell support for Power Apps.

Umgebungsadministrator kann eine Sperre nicht aufheben

Ursache: Die Richtlinie stammt von der Mandantenebene. Lösung: Ausnahme über New-PowerAppDlpPolicyExemptResources setzen oder den Geltungsbereich der Mandantenrichtlinie ändern. Quelle: Data resource exemption cmdlets.

Empfehlungen für den Einstieg im Mittelstand

Beginnen Sie mit einer einzigen, moderat restriktiven Richtlinie für Ihre Produktivumgebungen. Test- und Sandbox-Umgebungen nehmen Sie zunächst bewusst aus.

Teilen Sie die Liste der klassifizierten Connectors intern. Erstellende wissen dann vor dem Bau eines Flows, welche Kombinationen erlaubt sind.

Belassen Sie die Standardgruppe auf Nicht geschäftlich. Neue Connectors werden so weder versehentlich freigegeben noch pauschal blockiert.

Verstehen Sie Verstöße als Signal. Ein angehaltener Flow zeigt zuverlässig, wo ein Prozess Daten über Gruppengrenzen hinweg bewegen wollte.

Als Ausblick lohnt ein Blick auf die Advanced Connector Policies. Sie ersetzen das Dreiergruppenmodell durch eine strikte Positivliste, gelten aber vorerst nur für zertifizierte Connectors.

Häufige Fragen

Blockiert eine DLP-Richtlinie sofort alle bestehenden Flows, die dagegen verstoßen?

Nicht in Sekunden, aber zuverlässig. Ein Hintergrundauftrag prüft alle aktiven Flows der Umgebung und arbeitet asynchron innerhalb von 24 Stunden. Zusätzlich läuft wöchentlich eine Konsistenzprüfung.

Kann ich einzelne Testumgebungen von einer strengen Richtlinie ausnehmen?

Ja. Bei Richtlinien auf Mandantenebene legen Sie den Geltungsbereich fest. Sie schließen entweder bestimmte Umgebungen aus oder wählen gezielt mehrere Umgebungen aus.

Was passiert mit einem neuen Connector, den ich noch nicht klassifiziert habe?

Er landet in der Standardgruppe der Richtlinie. Microsoft empfiehlt dafür Nicht geschäftlich, damit neue Connectors weder ungeprüft blockiert noch ungeprüft freigegeben werden.

Gilt eine DLP-Richtlinie auch für Desktop-Flows?

Ja. Sie stufen Desktop-Flow-Module und einzelne Aktionen als geschäftlich, nicht geschäftlich oder blockiert ein. Dafür muss die Mandanteneinstellung „Show desktop flow actions in DLP policies" aktiv sein. Diese Einstellung lässt sich danach nicht mehr zurücknehmen.

Wer kann eine von der IT erstellte Mandantenrichtlinie wieder ändern?

Nur Personen mit der Rolle Power Platform-Administrator. Umgebungsadministratoren legen eigene Richtlinien für ihre Umgebung an, bearbeiten oder löschen aber keine mandantenweiten Richtlinien.

Was gilt, wenn mehrere Richtlinien auf eine Umgebung wirken?

Für die jeweilige Connector-Kombination greift die strengste Regel. Eine Umgebungsrichtlinie kann eine Mandantenrichtlinie nie lockern.

Weiterführende Informationen liefert die offizielle Microsoft-Dokumentation zu Datenrichtlinien in Power Platform. Den Weg im Admin Center beschreibt die Seite zur Verwaltung von Datenrichtlinien. Die Besonderheiten für Cloud- und Desktop-Flows stehen unter DLP-Richtlinien für Power Automate.