Leitfaden für Cloud-Flow-Freigabe und -Berechtigungen

Diese Anleitung dient als Unterstützung, um geeignete Szenarien für die Flow-Freigabe zu identifizieren und Berechtigungen einzurichten, um den Benutzerzugriff zu verwalten und die Sicherheit zu gewährleisten.

Verwalten von Benutzern, Berechtigungen und Rollen in Power Automate Umgebungen

Die Verwaltung, wer Flows erstellen, bearbeiten oder einfach nur ausführen kann, ist entscheidend für die Aufrechterhaltung einer sicheren und geordneten Power Automate Umgebung. Das Sicherheitsmodell von Power Automate arbeitet auf mehreren Berechtigungsebenen:

• Rollen auf Umgebungsebenen (z. B. Umgebungsadministrator und Umgebungsersteller): Steuern die Fähigkeit eines Benutzers, Ressourcen in einer bestimmten Umgebung zu verwalten oder zu erstellen.
• Dataverse Sicherheitsrollen (wenn die Umgebung über eine Dataverse Datenbank verfügt): Wie Basic Benutzer, Systemanpasser und andere, die den Zugriff auf Daten und Entitäten steuern. Beispielsweise benötigen Benutzer in der Regel mindestens die Rolle Basic-Benutzer, um Apps oder Flows auszuführen, die Dataverse Daten verwenden.
• Berechtigungen auf Flowebene: Geben Sie Einstellungen für einzelne Flows frei, die andere Benutzer entweder zu Mitbesitzern (mit Bearbeitungsrechten) oder zu Benutzern mit Nur-Ausführen-Rechten machen.

Umgebungsrollen und Sicherheit

In jeder Umgebung können nur Benutzer mit den entsprechenden Rollen Ressourcen erstellen oder verwalten.

• Umgebungsadministrator: Hat die vollständige administrative Kontrolle über die Umgebung. Ein Umgebungsadministrator kann alle Ressourcen verwalten, einschließlich der Anzeige aller Flows, des Hinzufügens und Entfernens von Benutzern und des Festlegens von Richtlinien. In Umgebungen ohne Dataverse kann nur diese Rolle Administratoraufgaben ausführen. In Dataverse aktivierten Umgebungen dient eine Systemadministratorrolle in Dataverse einem ähnlichen Zweck für Datenvorgänge.

• Umgebungsersteller: Diese Rolle ermöglicht es Benutzern, neue Ressourcen wie Flows, Apps und Verbindungen in der Umgebung zu erstellen. Die Rolle Umgebungsersteller gewährt keinen Zugriff auf vorhandene Daten in Dataverse, sondern nur die Möglichkeit, Artefakte zu erstellen und freizugeben. Microsoft folgt einem Modell der geringsten Rechte für vordefinierte Rollen: Der Umgebungsersteller verfügt über den Mindestzugriff, der zum Erstellen von Apps/Flows erforderlich ist, ohne Daten preiszugeben, die sie nicht anzeigen dürfen. Ersteller können die von ihnen erstellten Apps/Flows nach Bedarf für andere in der Organisation freigeben, aber sie können ihre eigenen Berechtigungen zum Lesen von Daten nicht erhöhen, es sei denn, sie erhalten zusätzliche Dataverse Rollen.

• Umgebungsbenutzer (Basic-Benutzer): In Dataverse unterstützten Umgebungen muss regulären Endbenutzern die Sicherheitsrolle Basic-Benutzer (manchmal auch Benutzer genannt Common Data Service) zugewiesen werden, um Apps auszuführen oder Flows zu nutzen, die mit Dataverse Daten interagieren. Standardmäßig kann das Hinzufügen eines Benutzers zu einer Umgebung, insbesondere wenn die Umgebung über eine Dataverse Datenbank verfügt, die explizite Zuweisung einer solchen Rolle erfordern. Dadurch wird sichergestellt, dass sie die Lösungen ausführen können, jedoch nur mit grundlegenden Berechtigungen für Daten. In Umgebungen ohne Dataverse, wenn einem Benutzer ein Flow nur zum Ausführen freigegeben wird, wird er möglicherweise nicht in der Umgebungsbenutzerliste angezeigt, es sei denn, er wird manuell hinzugefügt. Ihre Berechtigungen werden ausschließlich über die Flowfreigabe erteilt.

Freigabeberechtigungen auf Flow-Ebene

Auf der Ebene der einzelnen Flows können Besitzer einen Cloud-Flow auf zwei Arten freigeben: Mitbesitzer hinzufügen oder Nur-Ausführen-Benutzer zuweisen. Es ist wichtig, den Unterschied zu verstehen.

• Besitzer/Mitbesitzer: Ein Mitbesitzer hat im Wesentlichen die gleichen Rechte wie der ursprüngliche Ersteller des Flows. Mitbesitzer können den Ausführungsverlauf anzeigen, das Design des Flows bearbeiten, seine Einstellungen ändern, den Flow starten und beenden, Verbindungen verwalten sowie weitere Besitzer hinzufügen oder entfernen. Mit anderen Worten: Jeder Mitbesitzer hat die volle Kontrolle, mit der Ausnahme, dass er den ursprünglichen Ersteller nicht entfernen kann. Mitbesitzer zeigen den Flow auch in ihrer Teamflowliste an und können ihn wie jeden anderen Flow verwalten, den sie selbst erstellt haben. Aufgrund des Umfangs dieser Berechtigungen sollten nur vertrauenswürdige Personen oder Gruppen als Mitbesitzer hinzugefügt werden.

  Beispiel: Wenn Alice Mitbesitzerin von Bobs Flow ist, kann Alice diesen Flow ändern oder löschen. Daher sollte Bobs Team Alice nur hinzufügen, wenn ein solcher Zugriff beabsichtigt ist.

• Nur-Ausführen-Benutzer: Ein Nur-Ausführen-Benutzer ist auf die Ausführung des Flows beschränkt, in der Regel über einen manuellen Trigger wie einen Schaltflächen- oder SharePoint Element-Trigger. Sie können den Flow nicht im Bearbeitungsmodus öffnen, seine interne Logik nicht anzeigen oder den bisherigen Ausführungsverlauf anzeigen. Dies ist ideal für Szenarien, in denen man möchte, dass Kollegen von der Automatisierung profitieren. Führen Sie z. B. einen Schaltflächenflow oder eine sofortige Datenverarbeitungsaufgabe aus, ohne ihnen Entwurfsberechtigungen zu erteilen. Nur-Ausführen-Benutzer zeigen den Namen des Flows an und können ihn ausführen, aber wenn sie versuchen, Details zu überprüfen, haben sie nur eingeschränkte Sichtbarkeit. Sie können auch keine weiteren hinzufügen oder den Flow in irgendeiner Weise ändern.

  Beispiel: Ein Helpdesk verfügt über einen Power Automate Schaltflächenflow zum Erstellen eines Tickets und zum Senden einer Bestätigung. Alle Frontline-Mitarbeiter werden als Nur-Ausführen-Benutzer hinzugefügt, sodass sie den Flow von ihren Geräten aus auslösen können, aber nicht ändern können, was der Flow tut.

Ressourcenspezifische Sicherheit im Vergleich zu Umgebungsrollen

Umgebungsrollen und Flowfreigabeberechtigungen arbeiten Hand in Hand. Wenn Benutzer Umgebungsadministrator sind oder über bestimmte Dataverse Berechtigungen verfügen, können sie aufgrund ihres breiten Zugriffs Flows unabhängig von der expliziten Freigabe anzeigen oder ändern.

• Ein Power Platform Administrator oder Umgebungsadministrator kann von Natur aus alle Flows in der Umgebung anzeigen und verwalten, auch wenn sie nicht einzeln für sie freigegeben wurden. Beispielsweise kann ein globaler Administrator bei Bedarf sich selbst als Besitzer jedem Flow hinzufügen.
• Umgekehrt kann einem Benutzer ohne Umgebungsrolle durch Freigabe Zugriff auf einen bestimmten Flow gewährt werden. In diesem Fall wird dieser Benutzer zu einem Sonderfallteilnehmer für diesen einen Flow, hat aber möglicherweise keinen Zugriff auf andere Ressourcen in der Umgebung.

Um Berechtigungen effektiv zu verwalten, sollten Organisationen formalisieren, welche Benutzer Flow-Ersteller (Ersteller) und welche Flow-Konsumenten* (Ausführer) sind, und dann die Rollen entsprechend anwenden. In den folgenden Abschnitten werden bewährte Methoden für die Implementierung dieser Unterscheidungen und die Minimierung von Risiken erläutert.

Berechtigungsebenen in Power Automate – Besitzer im Vergleich zu Benutzer mit Nur-Ausführen-Berechtigung

Ein wichtiger Aspekt beim Verwalten der Flowsicherheit ist das Verständnis der Funktionen verschiedener Freigabeberechtigungsstufen. In der folgenden Tabelle sind die Unterschiede zwischen Mitbesitzern und Nur-Ausführen-Benutzern für einen Cloud-Flow zusammengefasst. Er vergleicht Berechtigungen und Funktionen von Flow-Mitbesitzer mit jenen von Nur-Ausführen-Benutzern in Power Automate.

In der Praxis bedeuten diese Unterscheidungen, dass Mitbesitzer auf Benutzer beschränkt sein sollten, die wirklich am Entwurf oder der Wartung eines Flows zusammenarbeiten müssen, während die Nur-Ausführen-Freigabe für eine breite Verteilung der Funktionalität eines Flows bevorzugt wird. Der Leitfaden von Microsoft unterstreicht dies: Fügen Sie Mitbesitzer für die Flow-Zusammenarbeit nur nach Bedarf hinzu. Wenn ein Flow freigegeben werden muss, geben Sie ihn in den meisten Fällen mit Nur-Ausführen-Berechtigungen frei. Dadurch wird sichergestellt, dass Benutzer von der Automatisierung profitieren können, ohne unbefugte Änderungen oder die Offenlegung von Flow-Interna zu riskieren.

Mildern der Risiken bei der gemeinsamen Nutzung von Flows außerhalb ihrer Umgebung

Wenn Sie Benutzern, die keine Umgebungsmitglieder sind, den Zugriff auf Flows erlauben, kann dies einige Risiken mit sich bringen:

• Governance-Blind-Spots Administratoren wissen möglicherweise nicht, wer Zugriff hat.
• Potenzielle Gefährdung von Daten: Wenn Flows vertrauliche Daten verarbeiten
• Nur-Ausführen-Zugriff: Kann ein Problem darstellen, wenn Trigger die Sichtbarkeit der Parametereingabe oder -ausgabe zulassen und die Kontrolle über Änderungen verloren geht. Dies ist der Fall, wenn Mitbesitzer außerhalb des Teams unbeabsichtigte Änderungen vornehmen.

Um diese Risiken zu mindern, sollten Unternehmen eine Kombination aus Richtlinien, technischen Kontrollen und Überwachung einführen.

• Erzwingen von Umgebungszugriffssteuerungen: Eine grundlegende bewährte Methode besteht darin, die Mitgliedschaft in der Umgebung mithilfe von (Microsoft Entra Azure AD) Sicherheitsgruppen einzuschränken. Durch Zuordnen einer Sicherheitsgruppe zu einer Umgebung können nur Benutzer in dieser Gruppe zu den Rollen der Umgebung hinzugefügt werden. Das heißt, selbst wenn ein Ersteller versucht, einen Flow für eine Person außerhalb der Gruppe freizugeben, wird diese Person nicht automatisch der Umgebung hinzugefügt. In Umgebungen mit einer zugeordneten Sicherheitsgruppe ist jeder Benutzer, der nicht zur Gruppe gehört, im Wesentlichen ein Außenstehender und verfügt über eingeschränkte Möglichkeiten, bis ein Administrator Zugriff gewährt. Diese Einrichtung verhindert, dass Außenstehende auf Umgebungsressourcen zugreifen, es sei denn, ein Administrator fügt sie explizit hinzu, indem er sie gemäß der Richtlinie zur Sicherheitsgruppe hinzufügt.

  Wenn beispielsweise die HR Apps Umgebung von Contoso an die HR-Team Sicherheitsgruppe gebunden ist, kann ein Benutzer aus Finance nur dann zum Mitbesitzer eines Flows in HR Apps gemacht werden, wenn er der Gruppe zuvor von einem Administrator hinzugefügt wurdeHR-Team. Diese Verwendung von Sicherheitsgruppen hilft Organisationen, eine klare Abgrenzung der Personen einzuhalten, die zur Verwendung der einzelnen Umgebungen berechtigt sind.

• Mitbesitz überprüfen und einschränken: Die Freigabe von Flows für Mitbesitzer sollte zurückhaltend erfolgen. Jeder Mitbesitzer wird effektiv zu einem vollwertigen Besitzer des Flows. Beschränken Sie also die Anzahl der Mitbesitzer auf die notwendigen Besitzer. Wenn ein Flow für eine externe Person freigegeben wurde, z. B. für einen Entwickler oder Berater aus einem anderen Team zur Problembehandlung, stellen Sie sicher, dass Sie deren Mitbesitzer entfernen, nachdem das Problem behoben wurde. Tun Sie dies, es sei denn, es besteht ein anhaltender Bedarf. Organisationen können Governanceprozesse implementieren, bei denen das Hinzufügen eines Mitbesitzers außerhalb der Umgebung eine Warnung auslöst oder eine Genehmigung erfordert. Dies kann durch den Einsatz von Power Automate Governance-Tools erreicht werden (z. B. ein Administrator-Flow, der die Power Platform Verwaltungskonnektoren verwendet, um zu erkennen, wenn ein neuer Besitzer zu einem Flow hinzugefügt wird). Anschließend benachrichtigen sie die IT-Abteilung oder ein Power Platform Center of Excellence-Team.

• Nur-Ausführen-Freigabe für externe Benutzer bevorzugen: Wenn die Freigabe für Benutzer, die keine Mitglieder der Umgebung sind, unvermeidlich oder gerechtfertigt ist, verwenden Sie nach Möglichkeit Nur-Ausführen-Berechtigungen anstelle von vollständigen Bearbeitungsrechten. Der Nur-Ausführungszugriff reduziert das Risiko erheblich: Der Benutzer kann die Flowlogik nicht anzeigen oder ändern, und er erhält Zugriff auf Ausführungsdaten, die möglicherweise vertrauliche Nutzlasten enthalten.

  Wenn ein Flow beispielsweise Kundendaten per E-Mail sendet, kann ein Nur-Ausführen-Benutzer diesen E-Mail-Versand auslösen, den Flow jedoch nicht öffnen, um die Kundendetails abzurufen, die gestern verarbeitet wurden. Dieses Prinzip entspricht dem Prinzip der minimalen Rechte, d. h. gewähren Sie den Mindestzugriff, der für die Rolle des Benutzers erforderlich ist. Durch die reine Freigabe kann häufig die geschäftliche Anforderung erfüllt werden, dass jemand einen Flow auslösen oder verwenden kann, ohne die Kontrolle abzugeben.

• Sicherheitsrollen zur Aufgabensegmentierung verwenden: Stellen Sie sicher, dass Benutzer, die Flows nur ausführen, aber nicht erstellen sollen, nicht über die Rolle Umgebungsersteller verfügen. Indem Sie diese Benutzer als Benutzer der einfachen Umgebung oder vollständig außerhalb der Umgebung mit Zugriff nur auf ausführbare Flows belassen, verringern Sie die Wahrscheinlichkeit, dass sie unautorisierte Flows erstellen oder importieren können. Nur designierte Ersteller sollten über Erstellerberechtigungen verfügen, während andere möglicherweise nur die Ausgaben von Flows nutzen.

  Weitere Informationen finden Sie unter Verwenden von Sicherheitsrollen und -gruppen: Entwickler gegenüber Benutzern, die nur ausführen dürfen, verwalten.

• Datenverlustverhütungsrichtlinien (DLP) implementieren: Obwohl es bei DLP-Richtlinien eher um die Steuerung der Konnektornutzung geht, tragen sie indirekt zur Risikominderung bei, indem sie verhindern, dass freigegebene Flows gesperrte Konnektoren verwenden. Wenn beispielsweise ein Außenstehender Nur-Ausführen-Zugriff auf einen Flow erhält, stellt eine strenge DLP-Richtlinie sicher, dass der Flow nicht plötzlich damit beginnen kann, Daten an einen nicht autorisierten Dienst zu übertragen. DLP stoppt die Freigabe selbst nicht, begrenzt aber den potenziellen Schaden, wenn ein Flow versehentlich oder absichtlich missbraucht wird. Als bewährte Methode klassifizieren Sie Konnektoren in geschäftliche und nicht-geschäftliche Kategorien, und blockieren Sie alle gefährlichen Kombinationen. Auf diese Weise werden Flows, selbst wenn sie allgemein freigegeben werden, keine Daten an nicht genehmigte Endpunkte weitergeben.

• Regelmäßige Prüfung und Überwachung: Etablieren Sie eine Routine (z. B. monatlich oder vierteljährlich) zur Überprüfung von Flowberechtigungen. Identifizieren Sie im Rahmen dieser Überprüfung alle Flows mit ungewöhnlicher Freigabe, insbesondere solche mit externen Besitzern oder großen Nur-Ausführen-Benutzerlisten. Überprüfen Sie sie, wenn sie noch benötigt werden. Die Microsoft-Dokumentation empfiehlt regelmäßige Überprüfungen von Berechtigungen, um sicherzustellen, dass sie mit den aktuellen Geschäftsanforderungen übereinstimmen, und um den Zugriff für Benutzer zu entfernen, die ihn nicht mehr benötigen.

  Die Überwachung kann automatisiert werden. Beispielsweise könnte ein Administrator einen Power Automate Flow mithilfe des Administrator-Konnektors einrichten, der einen Bericht aller Flows mit ihren Besitzern und dem Datum der letzten Änderung sendet. Der Flow hebt die Flows hervor, deren Besitzer außerhalb einer angegebenen Liste genehmigter Personen liegen. Erwägen Sie außerdem die Nutzung der Power Platform Admin Analytics-Dashboards. Er kann die Gesamtnutzung anzeigen und möglicherweise gefiltert werden, um zu erfahren, wie viele Benutzer jeden Flow ausführen.

• Aufklärung von Entwicklern und Durchsetzung von Richtlinien: Manchmal wird das Risiko durch mangelndes Bewusstsein verursacht. Dokumentieren und kommunizieren Sie eine klare Richtlinie für die Freigabe, z. B., Fügen Sie keine Benutzer von außerhalb von Umgebung X ohne Genehmigung als Mitbesitzer hinzu. Verwenden Sie bei Bedarf den Nur-Ausführen-Zugriff für Benutzer außerhalb des Teams. Indem Sie Power Automate Entwickler gemäß diesen Richtlinien schulen, reduzieren Sie die versehentliche Exposition. Wenn Ihre Organisation über eine interne Power Platform Community oder ein Champion-Netzwerk verfügt, teilen Sie Erinnerungen an die Auswirkungen der breiten Freigabe von Flows. Letztendlich sollten sich die Benutzer darüber im Klaren sein, dass die Freigabe mit Power Automate zwar einfach ist, es jedoch Compliance- und Sicherheitsschritte gibt, die für jede umgebungsübergreifende Zusammenarbeit befolgt werden müssen.

• Verwenden Sie separate Umgebungen für die breite Freigabe: In einigen Fällen kann es ratsam sein, eine dedizierte Umgebung für Flows zu haben, die von einem breiten Publikum verwendet werden müssen. Beispielsweise könnte eine Organisation eine Umgebung für gemeinsame Dienste erstellen, die für viele Benutzer mit einer entsprechenden Sicherheitsgruppe offen ist. Flows, die für eine breite Nutzung vorgesehen sind, können dort entwickelt und gehostet werden, anstatt sie in einer eingeschränkteren Umgebung freizugeben. Auf diese Weise werden Umgebungsgrenzen beibehalten. Ihre streng kontrollierten Umgebungen bleiben strikt, und die offene Umgebung ist für die funktionsübergreifende Freigabe mit angemessener Aufsicht vorgesehen. Wenn Sie diese Strategie anwenden, stellen Sie sicher, dass die offene Umgebung weiterhin über starke DLP-Richtlinien und -Überwachung verfügt, da sie entwurfsbedingt über eine größere Benutzerbasis verfügt.

• Erwägen Sie das Kopieren von Flows anstelle der direkten Freigabe: Wenn Benutzer in einer anderen Umgebung die Funktionalität eines Flows benötigen, besteht ein anderer Ansatz darin, den Flow als Paket zu exportieren und das Paket freizugeben, anstatt den Live-Flow freizugeben. Microsoft empfiehlt diesen Ansatz in Szenarien, in denen der Benutzer kein Mitglied Ihrer Power Automate Umgebung ist – Sie können ihm eine Kopie des Flows senden, die er in seine eigene Umgebung importiert. Der Empfänger richtet dann seine eigenen Verbindungen ein und führt den Flow unabhängig aus. Dadurch wird das Risiko gemindert, da jeglicher direkter Zugriff auf den Flow der ursprünglichen Umgebung vermieden wird. Es gibt ihnen im Wesentlichen die Lösung, ohne ihnen einen Zugriff in Ihrer Umgebung zu geben. Der Nachteil ist, dass Aktualisierungen des Flows nicht automatisch synchronisiert werden, da es sich um eine separate Kopie handelt. Für einmalige Anforderungen oder die gemeinsame Nutzung mit externen Teams sorgt diese Methode jedoch für eine saubere Trennung.

Zusammenfassend lässt sich sagen, dass die Minderung der Risiken, die mit der gemeinsamen Nutzung von Flows verbunden sind, auf eine strenge Kontrolle des Umgebungszugriffs, eine umsichtige Nutzung von Freigabeoptionen und eine wachsame Aufsicht hinausläuft. Durch die Kombination technischer Sicherheitsvorkehrungen (z. B. von Sicherheitsgruppen kontrollierte Umgebungen und DLP-Richtlinien) mit Prozesssicherheitsvorkehrungen (z. B. Genehmigungen für das Hinzufügen von Besitzern und regelmäßige Audits) können Unternehmen die Vorteile der Power Automate Zusammenarbeit nutzen und gleichzeitig Sicherheits- und Compliance-Probleme minimieren.

Der folgende Abschnitt konzentriert sich auf einen bestimmten Aspekt der Governance: die Verwendung von Rollen und Gruppen, um zu definieren, wer ein Ersteller und wer nur ein Flow-Runner ist.

Sicherheitsrollen und Gruppen verwenden: Entwickler versus Nur-Ausführungsbenutzer

Eine kritische Governance-Entscheidung besteht darin, festzulegen, welche Benutzer Macher sein sollen, die Flows erstellen und besitzen können, und welche auf die Ausführung von Flows beschränkt sein sollten, die möglicherweise die Ergebnisse nutzen können. Power Automate und die Power Platform bieten mehrere Mechanismen, um diese Unterscheidung durchzusetzen, vor allem durch Sicherheitsrollen und Sicherheitsgruppen.

Macher von Nicht-Machern unterscheiden

In einem Unternehmensszenario sollte nicht jeder Benutzer mit einer Power Automate Lizenz notwendigerweise Flows in jeder Umgebung erstellen. Standardmäßig kann ein Umgebungsersteller Flows und andere Ressourcen in dieser Umgebung erstellen. Bei dedizierten Umgebungen sollten Sie die Rolle des Umgebungserstellers absichtlich nur den Benutzern oder Gruppen zuweisen, die für die Erstellung von Lösungen verantwortlich sind. Sie können beispielsweise festlegen, dass in der Finance Automation-Umgebung nur das Finanz-IT-Team und einige Power-User über Umgebungsersteller-Berechtigungen verfügen.

Sie können dies durchsetzen, indem Sie wie folgt vorgehen:

• Weisen Sie die Sicherheitsrolle Umgebungsersteller in den Umgebungseinstellungen direkt bestimmten Benutzern zu.
• Verwenden Sie eine Azure Active Directory (AD)-Sicherheitsgruppe. Fügen Sie alle beabsichtigten Ersteller einer Gruppe hinzu (z. B. Finanzentwicklergruppe), und weisen Sie dieser gesamten Gruppe die Rolle Umgebungsersteller zu, wenn die Umgebung keine Dataverse hat. In Dataverse aktivierten Umgebungen müssen Sie möglicherweise Gruppenmitglieder einzeln hinzufügen oder Gruppenteams mit Sicherheitsrollen einsetzen.
• Ordnen Sie für eine umfassende Kontrolle die Umgebung einer Sicherheitsgruppe zu, damit sich nur Mitglieder in der Umgebung befinden können. Weisen Sie dann innerhalb dieser Menge der entsprechenden Teilmenge Entwicklerrollen zu. Dieser zweistufige Ansatz bedeutet, dass Außenstehende nicht unentdeckt als Entwickler hinzugezogen werden können, und unter den Insidern haben nur einige die Rolle des Entwicklers. In seriösen Anleitungen wird empfohlen, die Funktion Umgebungssicherheitsgruppe auf alle Produktionsumgebungen und vertraulichen Umgebungen anzuwenden, um die Anwesenheit unerwünschter Benutzer zu verhindern.

Verwenden Sie Sicherheitsgruppen für Nur-Ausführen-Zugriff

Es gibt zwar keine Nur-Ausführen-Rolle für die Umgebung, aber Sie können Nur-Ausführen-Berechtigungen in großem Umfang mithilfe von Gruppen verwalten. Beim Freigeben eines Flows können Besitzer einen Gruppennamen anstelle einzelner Benutzer eingeben, um entweder Mitbesitzer- oder Nur-Ausführen-Zugriff zu erhalten. Dies bedeutet, dass Sie eine Sicherheitsgruppe wie Vertriebsberichte-Flow-Benutzer erstellen und diese Gruppe als Nur-Ausführen-Benutzer für relevante Flows zuweisen können. Alle Mitglieder der Gruppe erben dann die Ausführungsberechtigung für diese Flows. Die Verwaltung wird einfacher. Um einem bestimmten Benutzer den Zugriff zu entziehen, entfernen Sie ihn aus der Gruppe. Sie verlieren den Ausführungszugriff auf alle Flows, denen diese Gruppe zugewiesen wurde. Wenn Sie einer neuen Person Ausführungszugriff auf mehrere Flows gewähren möchten, fügen Sie sie der Gruppe hinzu. Sicherheitsgruppen tragen somit dazu bei, die Berechtigungsverwaltung zu vereinfachen, indem sie sie externalisieren.

Power Automate Flows müssen nicht 50 Benutzer als Nur Ausführen auflisten. Sie listen eine Gruppe auf, und Ihr Azure AD oder Microsoft 365 Admin verarbeitet die Mitgliedschaft.

Rollenzuweisung für Entwickler im Vergleich zu Ausführern

In Dataverse Umgebungen können Sicherheitsrollen überlagert werden, um genau abzustimmen, was Entwickler und Benutzer mit Nur-Ausführen-Rechten tun können.

• Ersteller: Sie benötigen mindestens die Rolle Umgebungsersteller, um Flows zu erstellen. Wenn ihre Flows mit Dataverse Tabellen interagieren, benötigen sie möglicherweise auch zusätzliche Dataverse Rollen wie Systemanpasser oder Berechtigungen für bestimmte Tabellen, um diese ordnungsgemäß zu entwerfen und zu testen. Durch die Kombination aus Umgebungsersteller und einer Rolle, die Datenzugriff gewährt (falls erforderlich), können vollständige Lösungen erstellt werden. Es hat sich bewährt, Entwicklern nur die Berechtigungen zu gewähren, die sie benötigen. Wenn ein Entwickler beispielsweise nur SharePoint und E-Mails automatisiert, benötigt er möglicherweise überhaupt keine Dataverse Rolle, abgesehen davon, dass er in der Umgebung anwesend ist. Wenn ein Entwickler jedoch einen Flow erstellt, um einen Dataverse Datensatz zu aktualisieren, benötigt er die Berechtigung für diese Tabelle. Planen Sie Ihre Sicherheitsrollen so, dass Entwickler bei Bedarf eine separate Entwickler-Datenrolle erhalten, anstatt ihnen übermäßig breite Rollen zuzuweisen.
• Nur-Ausführen-Benutzer: Diese Benutzer benötigen Umgebungsersteller nicht. Wenn die Umgebung über eine Dataverse Datenbank verfügt und der Flow Dataverse-Daten berührt, ist möglicherweise die Basic-Benutzerrolle (oder eine andere Rolle) erforderlich, um Lese-/Schreibzugriff auf die zugrunde liegenden Daten zu haben, wenn der Flow in ihrem Kontext ausgeführt wird. Ein manueller Trigger-Flow kann beispielsweise einen Dataverse Datensatz im Namen des Ausführers erstellen. Wenn dies der Fall ist, benötigt der Runner die Berechtigung, diesen Datensatz zu erstellen. Wenn Sie die Option Nur Ausführen Benutzer stellt Verbindung bereit verwenden, wird der Flow im Kontext der Anmeldeinformationen des Ausführungsbenutzers ausgeführt. In solchen Fällen müssen Sie sicherstellen, dass diese Benutzer über die minimalen Rechte verfügen, die durch Dataverse-Rollen oder relevante Systemberechtigungen erforderlich sind, um die vom Flow ausgeführten Aktionen auszuführen. Wenn der Flow immer die Verbindung des Besitzers verwendet, benötigt der Ausführungsbenutzer möglicherweise keine besondere Rolle in Dataverse—er drückt eine Schaltfläche und der Flow verwendet die Berechtigung des Besitzers. Diese Nuance sollte sorgfältig abgewogen werden. Ein sicherer Ansatz besteht darin, Nur-Ausführen-Benutzern Lesezugriff auf Daten zu gewähren, die sie anzeigen können, und nicht mehr. Viele Unternehmen erstellen eine benutzerdefinierte Dataverse-Rolle oder verwenden Basic-Benutzer mit minimalen Leserechten und weisen sie allen Endbenutzern zu, um diese Anforderung der Ausführung von Apps und Flows zu erfüllen.

Rollenmanagement unter Berücksichtigung der Governance

Behalten Sie den Überblick, wer welche Rolle hat. Ein Power Platform-Administrator kann alle Benutzer in einer Umgebung und ihre zugewiesenen Sicherheitsrollen über das Admin Center oder über PowerShell auflisten. Dies kann mit der erwarteten Liste der Entwickler abgeglichen werden. Es ist eine bewährte Governance-Methode, ein Inventar zu führen, z. B. Umgebungs-X-Entwickler: Alice, Bob, Carol; Umgebung X Nur-Ausführen/Verbraucher: Alle Benutzer in der Marketingabteilung. Wenn Sie sich darüber im Klaren sind, können Sie bei einer Anfrage zum Hinzufügen eines neuen Entwicklers überprüfen, ob dieser von der Gruppe genehmigt wurde, oder die erforderlichen Genehmigungen erhalten, um den Kreis zu erweitern.

Szenarien und Beispiele

In der folgenden Liste werden einige Szenarien und Beispiele für Lösungen dafür erläutert.

• Szenario: Eine Abteilungsumgebung, in der nur ein kleines Team Flows erstellen sollte, aber von vielen in der Abteilung genutzt werden.
• Lösung: Der IT-Leiter der Abteilung erhält die Bezeichnung Umgebungsadministrator. Eine Azure AD Gruppe Abt. Entwickler enthält die fünf Personen, die Apps und Flows erstellen. Diese Gruppe wird der Rolle Umgebungsersteller hinzugefügt. Dies geschieht entweder direkt, oder die Einzelpersonen werden zugewiesen, wenn keine Gruppenzuweisung verfügbar ist. Alle Mitarbeiter der Abteilung befinden sich in der Gruppe Abteilungsbenutzer, die der Umgebung zugeordnet ist, sodass sie alle Zugriff als Benutzer haben. In der Umgebung erstellte Flows, die von der gesamten Abteilung ausgeführt werden müssen, werden als Nur Ausführen für die Gruppe Abteilungsbenutzer freigegeben. Auf diese Weise können Entwickler erstellen und teilen. Ein Abteilungsmitglied kann ausführen, aber Personen, die nicht zur Abteilung gehören, haben keinen Zugriff, da sie nicht in der Umgebungsgruppe sind.
• Szenario: Eine Produktionsumgebung mit sensiblen Flows, die von niemandem außer zwei Lösungsbesitzern bearbeitet werden sollten.
• Lösung: Nur diese beiden Personen sind Umgebungsersteller. Niemand sonst hat die Entwickler-Rolle. Wenn andere Benutzer Flows auslösen müssen, erhalten sie Nur-Ausführungszugriff. Möglicherweise ist ein dediziertes Dienstkonto oder ein Dienstprinzipal tatsächlich der Besitzer von Flows für die Stabilität, wobei die beiden Besitzer als Mitbesitzer für die Wartung fungieren. Die Verwendung eines Dienstprinzipals als primärer Besitzer verbessert die Governance für kritische Flows. Alle regulären Mitarbeiter befinden sich entweder nicht in dieser Umgebung oder haben nur die Benutzerrolle. Die Umgebung könnte an eine Sicherheitsgruppe gebunden werden, die nur die erforderlichen Konten enthält, um die Exklusivität weiter zu gewährleisten.
• Szenario: Eine Center-of-Excellence-Umgebung, in der Governance-Teams Überwachungsflows für alle Umgebungen erstellen.
• Lösung: Nur das Center of Excellence-Team hat Zugriff. Sie sind Umgebungsersteller nach Rolle. Es ist keine reine Ausführungsfreigabe erforderlich, da diese Flows eher intern sind. Hier haben die Mitglieder des wesentlichen Center of Excellence vielleicht die Power Platform Administratorrolle auf Mandantenebene, was ihnen implizit Rechte für alle Umgebungen gibt.

Vorteile der Rollentrennung

Durch die klare Abgrenzung von Maker und Runner erreichen Sie Folgendes:

• Prinzip der minimalen Rechte: Benutzer erhalten nur die Berechtigungen, die sie benötigen. Ein Nur-Ausführen-Benutzer kann nicht plötzlich damit beginnen, Flows zu erstellen, die die IT-Aufsicht umgehen, weil ihm diese Rolle fehlt. Die Entwickler haben die Freiheit, zu erstellen, aber da diese Gruppe kleiner und bekannter ist, kann man sie leichter trainieren und überwachen.
• Vereinfachtes Lebenszyklusmanagement: Wenn ein Mitarbeiter das Unternehmen verlässt oder die Rolle wechselt, ist es einfacher, den Zugriff zu aktualisieren. Wenn Joe z. B. ein Entwickler war und das Team verlässt, entfernen Sie ihn aus der Sicherheitsgruppe Entwickler. Er verliert sofort die Fähigkeit, in dieser Umgebung zu erstellen und zu bearbeiten, während er den Ausführungszugriff beibehält, wenn er in der Benutzergruppe bleibt. Sie können dann seinen Ersatz zur Gruppe Entwickler hinzufügen. Diese gruppenbasierte Wartung ist sauberer als das manuelle Hinzufügen und Entfernen von Dutzenden von Flow-Berechtigungen.
• Compliance-Ausrichtung: Viele Vorschriften verlangen einen kontrollierten Zugriff. Wenn Sie einem Prüfer zeigen können, dass nur diese spezifischen Personen die Automatisierung in dieser Umgebung ändern können und alle anderen lediglich genehmigte Flows auslösen können, können Sie starke interne Kontrollen nachweisen. Auditoren können auch den Export von Umgebungsrollenzuweisungen als Nachweis für die Durchsetzung erhalten.
• Verwirrung vermeiden: Wenn jeder über Entwicklerrechte besäße, könnten weniger technische Benutzer versehentlich Flows erstellen oder ändern oder durch die Power Automate Benutzeroberfläche verwirrt werden. Durch die Einschränkung der Entwicklerrolle stellen Sie sicher, dass nur geschultes Personal Flows entwirft, wodurch Fehler reduziert werden können.

Diese Maßnahmen sollten regelmäßig überprüft werden. Wenn sich die Geschäftsanforderungen ändern, muss jemand, der ein Verbraucher ist, möglicherweise ein Entwickler werden (z. B. ein Power-User tritt in einem neuen Team auf), oder ein Entwickler muss ein Verbraucher werden. Das Governance-Modell sollte flexibel genug sein, um dies mit ordnungsgemäßen Genehmigungen zu ermöglichen. Dokumentieren Sie die Kriterien für die Erteilung von Umgebungsersteller-Berechtigungen und den Prozess zur Beantragung, damit Transparenz und Konsistenz gewährleistet sind. Definieren Sie auf ähnliche Weise, welche Bedingungen den Entzug des Entwicklerzugriffs auslösen können, z. B. der Wechsel in eine andere Abteilung.

Durch die gemeinsame Verwendung von Sicherheitsrollen und -gruppen können Organisationen eine klare und verwaltbare Trennung zwischen denjenigen erreichen, die die Automatisierung erstellen, und denen, die die Automatisierung nutzen. Dies erhöht sowohl die Sicherheit als auch die Produktivität in Power Automate Umgebungen.

Verwandte Informationen

• Freigegebene Flows mit Benutzern außerhalb einer Umgebung verwalten
• Einen Cloud-Flow freigeben