Warum Power Platform-DLP-Richtlinien keine klassischen Sicherheitskontrollen sind

Von Mirko Peters · 2026-08-12

Erfahren Sie, wie sich Power Platform-DLP-Richtlinien von klassischer Sicherheit unterscheiden, wie Sie sie mit Umgebungen kombinieren und welche Best Practices für Low-Code-Governance gelten.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Power Platform-Richtlinien zur Verhinderung von Datenverlust (Data Loss Prevention, DLP) funktionieren grundlegend anders als die Standard-Sicherheitsfunktionen von Microsoft 365. Statt den breiten Benutzerzugriff einzuschränken oder Dateien zu verschlüsseln, steuern Power Platform-DLP-Richtlinien gezielt, wie einzelne Low-Code-Connectors innerhalb von Umgebungen kombiniert werden dürfen, um Datenabfluss zu verhindern.

Das Wichtigste in Kürze

• Power Platform-DLP-Richtlinien steuern in erster Linie die Interaktion zwischen Connectors und nicht die klassischen Benutzerberechtigungen oder die Verschlüsselung auf Dateiebene.
• Connectors werden in Gruppen für Geschäftsdaten und Nicht-Geschäftsdaten eingeteilt. Dadurch wird geregelt, welche Dienste innerhalb derselben App oder desselben Flows Daten austauschen dürfen.
• Die Umgebungsarchitektur muss zusammen mit den DLP-Richtlinien entworfen werden, damit die Governance unternehmensweit wirksam ist.
• Eine einzige mandantenweite DLP-Richtlinie reicht für vollständige Sicherheit nicht aus. Granulare, umgebungsspezifische Strategien sind erforderlich.
• Die Standardeinstellungen im Power Platform Admin Center sollten stets überprüft werden, um eine ungewollte Offenlegung von Unternehmensdaten zu verhindern.

Grundlagen von Power Platform-DLP verstehen

Wenn IT-Administratoren sich erstmals mit den Sicherheitsfunktionen von Microsoft 365 befassen, gehen sie oft davon aus, dass DLP-Werkzeuge in allen Workloads gleich funktionieren. Ob Exchange, SharePoint oder OneDrive: Klassisches DLP soll sensible Informationen wie Kreditkartennummern oder personenbezogene Daten (PII) erkennen und deren Übertragung oder Freigabe blockieren.

Power Platform-DLP folgt jedoch einem völlig anderen Funktionsprinzip. Wie in unserer ausführlichen Analyse beschrieben, durchsuchen diese Richtlinien die Inhalte von Low-Code-Apps oder Cloud-Flows nicht in Echtzeit nach sensiblen Datenmustern. Stattdessen wirken sie als architektonische Leitplanken, die festlegen, welche Dienste miteinander kommunizieren dürfen. Indem Administratoren Connectors in bestimmte Gruppen einteilen – traditionell als Gruppe für Geschäftsdaten, Gruppe für Nicht-Geschäftsdaten und eine blockierte Kategorie –, steuern sie die Kommunikationswege, die Citizen Developern zur Verfügung stehen.

Wie Connectors innerhalb von Lösungen interagieren

Das zentrale Risiko bei der Citizen Entwicklung besteht nicht darin, dass jemand eine einzelne Power App oder einen einzelnen Power Automate-Flow erstellt, sondern darin, dass ein Workflow ein sicheres Unternehmenssystem mit einem ungeprüften öffentlichen Dienst verbindet. Beispielsweise könnte ein Maker unbeabsichtigt einen Flow entwerfen, der Finanzdaten aus einer internen SQL-Datenbank extrahiert und in einen Cloud-Speicher für Verbraucher oder einen öffentlichen Social-Media-Kanal exportiert.

Power Platform-DLP-Richtlinien unterbinden dies, indem sie Grenzen zwischen Connector-Typen durchsetzen. Ist ein Connector der Gruppe für Geschäftsdaten zugewiesen, darf er innerhalb derselben Anwendung oder desselben Flows keine Daten mit einem Connector der Gruppe für Nicht-Geschäftsdaten austauschen. Diese strukturelle Einschränkung verhindert eine unautorisierte Vermischung von Daten, ohne dass IT-Fachleute jede Zeile der Low-Code-Logik manuell prüfen müssen.

Kombination von DLP-Richtlinien und Umgebungsarchitektur

Ein häufiger Fehler bei neuen Plattformadministratoren ist, sich allein auf eine einzige, mandantenweite DLP-Richtlinie zu verlassen. Organisationen umfassen unterschiedlichste Betriebseinheiten, von experimentellen Sandbox-Zonen bis hin zu geschäftskritischen Produktionsumgebungen. Ein Einheitsansatz scheitert deshalb zwangsläufig.

Wirksame Governance erfordert, DLP-Richtlinien direkt an Ihrer Umgebungsstrategie auszurichten. Zum Beispiel:

• Standardumgebungen: Hier sollten strenge, stark restriktive DLP-Richtlinien gelten, weil jeder Benutzer im Mandanten standardmäßig Maker-Zugriff auf diese Umgebungen hat.
• Sandbox-Umgebungen: Sie sind für Experimente und Lernzwecke gedacht und können einen breiteren Konnektorzugriff erlauben, während risikoreiche externe Integrationen weiterhin blockiert werden.
• Produktionsumgebungen: Sie werden mit granularen, geschäftsspezifischen Konnektorgruppen abgesichert, um Unternehmensdatenbanken und zentrale Betriebssysteme wie SAP oder Dynamics 365 zu schützen.

Ohne eine bewusst gestaltete Umgebungsarchitektur werden mandantenweite Richtlinien entweder zu restriktiv und blockieren alltägliche Produktivitätsprojekte, oder sie sind zu freizügig und setzen kritische Unternehmensdaten Shadow IT aus.

Häufige Missverständnisse zur Sicherheit von Power Platform

Viele Organisationen glauben, dass das bloße Aktivieren von Managed Environments oder das Umschalten einer Standard-DLP-Richtlinie bereits eine vollständig umgesetzte Sicherheitslage darstellt. Tatsächlich ist Sicherheit ein fortlaufendes Betriebsmodell, das kontinuierliche Bestandsaufnahmen und klare Grenzen für Maker erfordert.

Außerdem übersehen Organisationen, die Dynamics 365 nutzen, häufig die zugrunde liegende Power-Platform-Basis. Da Dynamics direkt auf Dataverse und der Power-Platform-Infrastruktur aufsetzt, wirken sich Berechtigungen und Konnektorfunktionen, die auf Plattformebene festgelegt werden, automatisch auf das gesamte Ökosystem der Geschäftsanwendungen aus. Wer diese darunterliegende Architektur nicht berücksichtigt, schafft verborgene Schwachstellen, die klassische Audits von Software-as-a-Service oft nicht erkennen.

Fazit

Um Power Platform wirksam zu steuern, muss man die Vorstellung hinter sich lassen, Low-Code-Werkzeuge seien einfache Hobbyanwendungen, die kaum Aufsicht benötigen. Wenn Sie Power Platform als unternehmenstaugliche Anwendungsplattform behandeln und DLP-Richtlinien so gestalten, dass sie Hand in Hand mit Ihrer Umgebungsstrategie arbeiten, können IT-Verantwortliche Unternehmensdaten schützen, ohne die Innovation aus den Fachbereichen zu ersticken.

Um diese Governance-Frameworks, Umgebungsarchitekturen und Citizen-Development-Strategien ausführlicher kennenzulernen, hören Sie die vollständige Episode an und entdecken Sie Expertenwissen, mit dem Sie ein nachhaltiges Microsoft-365-Betriebsmodell aufbauen können.

Häufige Fragen

Worin unterscheiden sich Power-Platform-DLP-Richtlinien von der DLP für Microsoft 365 Information Protection?

Die klassische M365-DLP prüft Inhalte auf sensible Datentypen wie Kreditkartennummern oder personenbezogene Daten (PII) und schränkt die Dateifreigabe ein. Power-Platform-DLP legt dagegen fest, welche Konnektoren innerhalb einer App oder eines Flows gemeinsam verwendet werden dürfen, und verhindert so, dass Daten zwischen Unternehmenssystemen und Consumer-Diensten vermischt werden.

Kann ich unterschiedliche DLP-Richtlinien auf verschiedene Umgebungen anwenden?

Ja. Power-Platform-DLP-Richtlinien können für den gesamten Mandanten, für bestimmte Umgebungen oder mit Ausnahme einzelner Umgebungen gelten. Diese Granularität ist entscheidend, um großzügige Entwicklerbereiche von streng kontrollierten Produktionsbereichen zu trennen.

Was passiert, wenn eine DLP-Richtlinie einen Konnektor in einem bestehenden Flow blockiert?

Untersagt eine DLP-Richtlinie, dass zwei verbundene Dienste in derselben Lösung zusammenarbeiten, schlagen aktive Apps oder Flows, die diese unzulässige Kombination verwenden, bei der Validierung oder zur Laufzeit fehl. Administratoren oder Maker müssen dann ihre Architektur anpassen.

Reicht eine einzige mandantenweite DLP-Richtlinie aus, um meine Organisation zu schützen?

Nein. Eine einzelne mandantenweite Richtlinie reicht selten aus, weil Abteilungen und Projekte sehr unterschiedliche Risikoprofile haben. Für eine ausgereifte Unternehmens-Governance sind mandantenweite Basisrichtlinien in Kombination mit umgebungsspezifischen Richtlinien erforderlich.