Datenrichtlinien

Die Verhinderung von Datenverlust (DLP) ist ein entscheidender Aspekt zur Aufrechterhaltung der Datensicherheit und Compliance im Microsoft Power Platform-Ökosystem.

Sie können Datenrichtlinien erstellen, die als Leitplanken dienen können, um das Risiko zu reduzieren, dass Benutzende unbeabsichtigt Organisationsdaten preisgeben. Eine Hauptkomponente von Power Apps, Power Automate und Microsoft Copilot Studio ist die Verwendung von Connectors zum Aufzählen, Befüllen, Pushen und Pullen von Daten. Mit Datenrichtlinien im Power Platform Admin Center können Administrierenden den Zugriff auf diese Connectors auf verschiedene Weise steuern, um das Risiko für Ihre Organisation einzudämmen.

In dieser Übersicht werden einige allgemeine Konzepte im Zusammenhang mit Connectors beschrieben und einige wichtige Überlegungen erläutert, die beim Einrichten Ihrer Richtlinien oder beim Vornehmen von Richtlinienänderungen berücksichtigt werden müssen.

Konnektoren

Connectors sind ganz grundsätzlich stark typisierte Darstellungen von RESTful-Anwendungsprogrammierschnittstellen, sogenannte APIs. Die Power Platform-API stellt zum Beispiel verschiedene Vorgänge im Zusammenhang mit der Funktionalität im Power Platform Admin Center bereit.

Das Umschließen der Power Platform-API in einen Connector macht es Erstellenden und Citizen Developer leichter, die API in ihren Low-Code-Apps, -Workflows und -Chatbots zu nutzen. Der Power Platform for Admins-V2-Connector ist zum Beispiel die Darstellung der Power Platform-API und wir sehen, dass die Aktion „Empfehlungen abrufen“ einfach per Drag & Drop in den Flow gezogen wird:

In diesem Artikel werden mehrere Connectortypen erwähnt und jeder verfügt über Funktionen innerhalb von Datenrichtlinien.

Zertifizierte Connectors

Zertifizierte Connectors sind Connectors, die strenge Test- und Zertifizierungsprozessen durchlaufen haben, um sicherzustellen, dass sie den Sicherheits-, Zuverlässigkeits- und Konformitätsstandards von Microsoft entsprechen. Diese Connectors bieten Benutzenden eine zuverlässige Möglichkeit zur Integration mit anderen Microsoft-Diensten und externen Diensten, während gleichzeitig die Datenintegrität und -sicherheit gewahrt bleibt.

Weitere Informationen zu zertifizierten Connectors finden Sie unter Richtlinien für die Einreichung zur Zertifizierung.

Benutzerdefinierte Konnektoren

Mithilfe benutzerdefinierter Connectors können Erstellende eigene Connectors erstellen, um diese in externe Systeme oder Dienste zu integrieren, die nicht vom Standardsatz zertifizierter Connectors abgedeckt werden. Benutzerdefinierte Connectors bieten zwar Flexibilität und Möglichkeiten der Anpassung, sollten aber genau bedacht werden, um sicherzustellen, dass sie den Datenrichtlinien entsprechen und die Datensicherheit nicht gefährden.

Weitere Informationen finden Sie unter Benutzerdefinierte Connectors erstellen und verwalten.

Virtuelle Connectors

Virtuelle Connectors sind Connectors, die in Datenrichtlinien zur Steuerung durch Administrierende angezeigt werden. Sie basieren jedoch nicht auf einer RESTful-API. Die Verbreitung virtueller Connectors ist darauf zurückzuführen, dass Datenrichtlinien zu den beliebtesten Governance-Kontrollen in Power Platform zählen. Es wird erwartet, dass weitere „Ein/Aus“-Funktionen dieser Art als Regeln in Umgebungsgruppen eingeführt werden.

Zur Steuerung von Microsoft Copilot Studio stehen mehrere virtuelle Connectors zur Verfügung. Mit diesen Connectors können verschiedene Features von Copiloten und Chatbots deaktiviert werden.

Lernen Sie virtuelle Connectors und ihre Rolle bei der Verhinderung von Datenverlusten in Microsoft Copilot Studio kennen.

Verbindungen

Wenn ein Erstellender eine App oder einen Flow erstellt und eine Verbindung zu Daten herstellen muss, kann er einen der oben genannten Connectortypen verwenden. Wenn einer App erstmals ein Connector hinzugefügt wird, wird mithilfe der von diesem bestimmten Connector unterstützten Authentifizierungsprotokolle eine Verbindung hergestellt. Diese Verbindungen stellen gespeicherte Anmeldeinformationen dar und werden in der Umgebung gespeichert, in der die App oder der Flow gehostet wird. Weitere Informationen zur Authentifizierung bei Connectors finden Sie unter Verbinden mit und Authentifizieren bei Datenquellen.

Entwurfszeit versus Laufzeit

Wenn Administrierende den Zugriff auf einen ganzen Connector oder auf bestimmte Aktionen eines Connectors beschränken, wirkt sich dies sowohl auf die Umgebung der Erstellenden als auch auf die Ausführung zuvor erstellter Apps, Flows und Chatbots aus.

Die Umgebung von Erstellen, oft auch als Entwurfszeitumgebungen bezeichnet, schränken ein, mit welchen Connectors Erstellende interagieren können. Wenn eine Datenrichtlinie die Verwendung des MSN Wetter-Connectors blockiert, können Erstellende ihren Flow oder ihre App, der bzw. die den Connector verwendet, nicht speichern und erhalten stattdessen eine Fehlermeldung, dass der Connector durch die Richtlinie blockiert wurde.

Umgebungen, bei denen eine App ausgeführt oder ein Flow nach einem festgelegten Zeitplan ausgeführt wird, z. B. täglich um 3:00 Uhr, werden oft als Laufzeit-Umgebung bezeichnet. Um beim vorherigen Beispiel zu bleiben: Wenn die Verbindung durch den unten beschriebenen Hintergrundprozess deaktiviert wurde, führt dies dazu, dass die App oder der Flow eine Fehlermeldung ausgibt, dass die MSN Wetter-Verbindung unterbrochen wurde und repariert werden muss. Wenn Erstellende versuchen, die Verbindung zu aktualisieren, um das Problem zu beheben, erhalten sie zur Entwurfszeit die Fehlermeldung, dass der Connector von einer Richtlinie blockiert wird.

Prozess für Richtlinienänderungen

Wenn neue Datenrichtlinien erstellt oder vorhandene Richtlinien aktualisiert werden, wird innerhalb des Power Platform-Ökosystem an Diensten ein bestimmter Prozess ausgelöst, der dabei hilft, diese Richtlinien für alle Ressourcen zu erzwingen, die in einem Mandanten vorhanden sind. Dieser Vorgang umfasst die folgenden Schritte.

1. Die Datenrichtlinienkonfiguration wird auf Kundenmanagementebene gespeichert.
2. Konfigurationen werden auf jede Umgebung im Kundenmandanten herunterkaskadiert.
3. Ressourcen in jeder Umgebung (wie Apps, Flows und Chatbots) suchen regelmäßig nach aktualisierten Richtlinienkonfigurationen.
4. Wenn erkannt wird, dass sich eine Konfiguration geändert hat, wird jede App, jeder Flow und jeder Chatbot überprüft, um festzustellen, ob ein Verstoß gegen die Richtlinie vorliegt.
5. Wenn ein Verstoß vorliegt, wird die App, der Flow oder der Chatbot in den Status Unterbrochen oder Quarantäne versetzt und kann somit nicht ausgeführt werden.
6. Verbindungen werden gescannt. Wenn die Richtlinie den gesamten Connector blockiert, wird die Verbindung in den Status deaktiviert versetzt, sodass sie nicht ausgeführt werden kann.
7. Alle Ressourcen, die ausgeführt werden und versuchen, eine inaktive Verbindung zu verwenden, schlagen zur Laufzeit fehl.

Wichtig

Die Laufzeiterzwingung hängt vom Status der Verbindung ab. Ist diese noch nicht deaktiviert bzw. wurde sie noch nicht gescannt, kann die Verbindung zur Laufzeit trotzdem fehlerfrei ausgeführt werden.

Zu berücksichtigende Latenz

Wie viel Zeit für eine wirksame Implementierung von Datenrichtlinien erforderlich ist, ist von Kundschaft zu Kundschaft unterschiedlich und hängt vom Umfang der Umgebungen und der darin enthaltenen Ressourcen ab. Je mehr Apps, Flows und Chatbots vorhanden sind, desto länger dauert es, bis Richtlinienänderungen vollständig wirksam werden. In den extremsten Fällen beträgt die Latenz bis zur vollständigen Erzwingung 24 Stunden. In den meisten Fällen geschieht dies innerhalb einer Stunde.

Siehe auch

Richtlinien für die Verhinderung von Datenverlust (DLP-Richtlinien)