Data Loss Prevention Policies oder DLP-Richtlinien sind die Eckpfeiler für den Schutz des Heiligtums Ihres Unternehmens: die firmeneigenen Daten. Low-Code-Anwendungstools wie Power Apps und Power Automate arbeiten mit Daten. Sie können sie nicht nur beschaffen oder erstellen, sondern auch manipulieren oder löschen. Und sie können Daten aus einer Vielzahl von Quellen und Diensten abrufen. Wir müssen also klare Regeln schaffen. Diese Regeln finden sich für Power Apps und Power Automate in DLP Policies.
Um auf Datenquellen zuzugreifen, verwenden Entwickler so genannte „Konnektoren“. Und zum aktuellen Zeitpunkt gibt es über 500 von diesen. Sie alle ermöglichen den Zugriff auf eine Vielzahl von Quellen. Neben den Microsoft-eigenen Konnektoren gibt es auch zahlreiche Drittanbieter. Und die Gesamtzahl wächst ständig. Jeder dieser Konnektoren und jeder neu hinzukommende Konnektor erhöht die möglichen Anwendungsfälle und die Leistungsfähigkeit der damit erstellten Anwendungen. Gleichzeitig ermöglicht die wachsende Zahl von Konnektoren aber auch deren missbräuchliche Nutzung. Und das stellt ein erhebliches Risiko für Unternehmen dar.
Stellen Sie sich zum Beispiel ein Szenario vor, in dem ein Benutzer einen Flow in Power Automate erstellt. Dieser ruft Informationen aus Unternehmenssystemen wie SharePoint oder SalesForce ab. Schließlich sendet der Flow die Informationen an Twitter oder einen privaten E-Mail-Posteingang. Und das alles ohne vorherige Überprüfung. Ein Albtraumszenario für jeden Datenschützer. Ein Szenario, das durch den richtigen Einsatz von Power Automate DLP-Richtlinien effektiv verhindert werden kann.
Lesen Sie mehr zu Funktionen von Power Apps, Power Automate und Power BI in unseren Artikeln:
POWER APPS ENTDECKEN: FUNKTIONEN, KONNEKTOREN & BEISPIELE
POWER AUTOMATE FUNKTIONEN: EIN LEITFADEN ZUR PROZESSAUTOMATISIERUNG
POWER BI TEMPLATES UND BEISPIELE
Data Loss Prevention Policies geben Ihnen als Administrator sowohl auf globaler Ebene (Tenant) als auch auf Umgebungsebene die Möglichkeit, Ihre Daten vor Missbrauch zu schützen. Außerdem können Sie mit DLP-Richtlinien Leitplanken für die Entwicklung und Nutzung von Low-Code-Anwendungen setzen. Eine erfolgreich implementierte DLP gibt dem Administrator die Sicherheit, keine unbemerkten Datenlöcher zuzulassen. Gleichzeitig bietet es Entwicklern die Sicherheit, dass sie nicht unwissentlich gegen Richtlinien verstoßen.
Die praktische Umsetzung von Data Loss Prevention Policies für die Power Platform ist jedoch oft ein Balanceakt. Auf der einen Seite muss die Produktivität des Unternehmens durch Freigaben sichergestellt werden. Andererseits muss Datenverlust oder -missbrauch durch Einschränkungen verhindert werden.
DLP-Richtlinien für die Power Platform können entweder auf der Tenant- oder auf der Environment-Ebene definiert werden. Richtlinien auf Tenant-Ebene gelten für alle nicht ausgeschlossenen Environments des betroffenen Tenants. Die Festlegung von DLP-Richtlinien auf Tenant-Ebene ist besonders nützlich, um bestimmte Dienste vollständig zu blockieren. Wenn es also Dienste gibt, die Sie in Ihrem gesamten Unternehmen von der Nutzung ausschließen möchten, können Sie dies durch DLP-Richtlinien auf Tenant-Ebene erreichen.
Auf der Umgebungsebene können Umgebungsadministratoren Richtlinien für einzelne Umgebungen festlegen. Auf diese Weise können die Richtlinien auf bestimmte Nutzungsszenarien zugeschnitten werden, um die Sicherheit und Produktivität zu maximieren.
Um Richtlinien auf den verschiedenen Ebenen durchsetzen und implementieren zu können, benötigen Sie verschiedene Berechtigungen. Diese Berechtigungen bestimmen, ob Sie Richtlinien für den gesamten Tenant oder nur für einzelne Environments festlegen können.
Um Richtlinien auf Tenant-Ebene durchzusetzen, benötigen Sie Microsoft Power Platform-Administrator-, Dynamics 365-Administrator- oder Microsoft 365-Global-Administrator-Berechtigungen. Um jedoch Richtlinien auf Umgebungsebene zu erstellen, benötigen Sie nur Power Platform-Environment-Administratorberechtigungen.
Durch diese Abstufung können Sie die volle Kontrolle über Ihren Tenant behalten und gleichzeitig die Verantwortlichkeiten effizient verteilen.
Wenn alle Voraussetzungen erfüllt sind, können Sie mit den DLP-Richtlinien für die Power Platform beginnen. Dazu finden Sie im Power Platform Administration Center den Bildschirm DLP Policy Settings.
Hier können Sie verschiedene Konnektoren in bestimmte Buckets verschieben. Sie sind unterteilt in Blocked, Business und Non-Business. Jeder Konnektor, der dem Bereich „Blocked“ zugewiesen wurde, kann in Umgebungen, die dieser DLP-Richtlinie unterliegen, nicht verwendet werden. Konnektoren in den Buckets „Business“ und „Non-Business“ können hingegen weiterhin innerhalb der Power Platform verwendet werden. Allerdings nicht zusammen. Nehmen wir zum Beispiel an, Sie haben SharePoint zum Bucket Business und Twitter zum Bucket Non-Business hinzugefügt. In diesem Fall können Sie zwar beide Konnektoren verwenden, aber nicht in einer Anwendung oder einem Workflow, der auf beide Dienste zugreift. Dies ist eine effiziente Methode, um zu verhindern, dass Daten verloren gehen oder dort landen, wo Sie sie nicht haben wollen.
Da immer wieder neue Konnektoren veröffentlicht werden, empfiehlt es sich, einen Standard-Bucket für sie einzurichten. Außerdem wird dringend empfohlen, den Bucket „Blocked“ als Standard zu wählen. Weisen Sie dann Konnektoren von dort zu. Da immer wieder neue Konnektoren veröffentlicht werden, empfiehlt es sich, einen Standardbereich für sie einzurichten. Hierzu empfehlen wir, den Bucket „Blocked“ als Standard zu wählen. Weisen Sie dann Konnektoren von dort aus je nach Bedarf den Buckets Business und Non-Business zu.
Als Tenant- oder Environment-Administrator können Sie mehrere DLP-Richtlinien festlegen. Diese können alle gleichzeitig auf dieselbe Umgebung angewendet werden. Alle DLP-Richtlinien werden bei der Bewertung der Klassifizierungen Blockiert, Geschäftlich und Nicht-Geschäftlich berücksichtigt. Als Vorbemerkung: Wenn ein Connector in einer der relevanten Richtlinien im Blocked Bucket liegt, kann er in dieser Umgebung nicht verwendet werden. In diesem Zusammenhang ist es unerheblich, ob es sich um eine Umgebungs- oder eine Tenant-Richtlinie handelt. Da es sich um die restriktivste Klassifizierung handelt, erhält „blocked“ immer die höchste Priorität.
Allerdings kann es zu Komplikationen oder Undurchsichtigkeit kommen, wenn mehrere DLP-Richtlinien innerhalb einer einzigen Umgebung kombiniert werden. Nehmen wir zum Beispiel an, es gibt drei Richtlinien, die auf eine einzige Umgebung angewendet werden. Daher werden bei der Erstellung und Verwendung von Anwendungen oder Arbeitsabläufen in dieser Umgebung alle drei Richtlinien geprüft. Das bedeutet, dass alle verwendeten Konnektoren daraufhin überprüft werden, ob sie denselben Buckets zugeordnet sind. Und das über alle drei Policies hinweg. Durch die Kombination mehrerer Richtlinien innerhalb einer Umgebung ergeben sich also viele mögliche Kombinationen. Zusammen bestimmen sie, ob eine Anwendung oder ein Workflow verwendet werden darf.
Um DLP-Richtlinien für die Power Platform übersichtlich, verständlich und vor allem effizient zu gestalten, ist es ratsam, die Anzahl der Richtlinien pro Umgebung so gering wie möglich zu halten. Auf diese Weise behalten Sie selbst den Überblick und ermöglichen den Entwicklern ein schnelles und effizientes Arbeiten.
Einmal angewendet, kommt es früher oder später zu Konflikten zwischen Ihren Data Loss Prevention Policies und Anwendungen und Workflows oder deren Erstellern. Dies führt vor allem dann zu Problemen, wenn ein Konnektor für einen wichtigen Workflow oder eine wichtige Anwendung unerlässlich ist. In diesem Fall müssen Sie überlegen, ob Sie Ihre Richtlinien anpassen oder eine neue Umgebung für diese Szenarien erstellen. Wenn keine der beiden Optionen in Frage kommt, weil es sich um eine absolute Ausnahme handelt, können Sie bestimmte Fälle auch von Ihrer DLP-Richtlinie ausschließen.
Um eine Anwendung oder einen Workflow von Ihrer Richtlinie auszuschließen, benötigen Sie Microsofts PowerShell. Damit können Sie mithilfe eines Skripts eine Ausnahmeliste erstellen, die Anwendungen und Arbeitsabläufe von Ihrer DLP-Richtlinie ausschließt.
Sie sollten jedoch darauf achten, dass diese Ausnahmelisten nicht zur Norm werden. Wie kombinierte Richtlinien innerhalb einer Umgebung, erhöhen auch Ausnahmen die Komplexität und damit die Undurchsichtigkeit.
Wie in den vorherigen Abschnitten beschrieben, wirken sich Ihre DLP-Richtlinien auf die Erstellung und Nutzung Ihrer Anwendungen und Workflows innerhalb der Power Platform aus. Wenn also ein Entwickler bei der Erstellung einer Anwendung oder eines Workflows versucht, auf einen gesperrten Connector zuzugreifen, wird ihm eine DLP-Fehlermeldung angezeigt.
Die neuen Richtlinien wirken sich jedoch nicht nur auf neue Anwendungen und Workflows aus, sondern auch auf solche, die bereits erstellt und in Gebrauch sind. Das bedeutet, dass ein Benutzer, der versucht, auf eine kürzlich von Ihrer Richtlinie betroffene Anwendung zuzugreifen, ebenfalls eine Fehlermeldung erhält. Das Gleiche gilt für bereits erstellte Workflows und wird als Runtime-Fehler bezeichnet.
Der eingangs beschriebene Spagat zwischen Berechtigungen und Einschränkungen sollte an dieser Stelle klar sein, Sie aber keinesfalls abschrecken. Vielmehr sind Data Loss Prevention Policies für Microsofts Power Platform Ihr Schutz vor Datenverlusten oder versehentlichen Datenlecks. Gewissenhaft und konsequent angewendet, schaffen Sie für Ihre Entwickler Leitplanken, zwischen denen sie sich mit gutem Gewissen bewegen und entwickeln können.
Sie möchten mehr über die Arbeit mit der Power Platform lernen? In unserem Trainingsangebot finden Sie verschiedene Angebote, die Ihnen und Ihren Mitarbeitern dabei helfen können.
Wenn Sie weitere Fragen oder Bedenken zur Sicherheit und Governance von Power Platform haben, zögern Sie nicht, uns zu kontaktieren.
