Standardumgebung absichern

Artikel
01/10/2024

Alle Mitarbeitenden in Ihrer Organisation haben Zugriff auf die Power Platform-Standardumgebung. Als Power Platform Administrator müssen Sie überlegen, wie Sie diese Umgebung absichern, wobei die Ersteller sie gleichzeitig weiterhin produktiv damit arbeiten können müssen. Dieser Artikel macht dazu einige Vorschläge.

Vergeben Sie Administratorrollen mit Bedacht

Überlegen Sie, ob Ihre Administratorbenutzenden die Administratorrolle für Power Platform haben müssen. Wäre die Rolle des Umgebungsadministrators oder des Systemsadministrators angemessener? Vergeben Sie die mit mehr Rechten ausgestattete Power Platform Administratorrolle auf jeden Fall an nur wenige Benutzende. Erfahren Sie mehr über die Verwaltung von Power Platform Umgebungen.

Stellen Sie die Absicht klar

Eine der größten Herausforderungen des Teams des Power Platform Center of Excellence (CoE) ist, zu kommunizieren, wie die Standardumgebung benutzt werden soll. Hier sind einige Empfehlungen.

Die Standardumgebung umbenennen

Die Standardumgebung hat bei der Erstellung den Namen TenantName (default). Sie können den Umgebungsnamen ändern, sodass er etwas aussagekräftiger ist, z. B. Persönliche Produktivitätsumgebung. Damit stellen Sie auch die Absicht eindeutig klar.

Verwenden Sie die Power Platform Hub

Die Microsoft Power Platform Hub ist eine Vorlage für eine SharePoint Kommunikationsseite. Sie bietet Erstellern einen Ausgangspunkt für eine zentrale Informationsquelle über die Verwendung von Power Platform. Mit Starterinhalten und Seitenvorlagen können Sie Erstellern ganz leicht Informationen anbieten:

Anwendungsfälle für die persönliche Produktivität
Apps und Flows erstellen
Wo werden Apps und Flows erstellt?
Das CoE-Supportteam kontaktieren
Regeln für die Integration mit externen Diensten

Fügen Sie Links zu anderen internen Ressourcen hinzu, die Ihre Ersteller möglicherweise hilfreich finden.

Ersteller können mit anderen einzelnen Benutzenden, Sicherheitsgruppen und standardmäßig allen in der Organisation ihre Apps teilen. Sie sollten erwägen, einen kontrollierten Prozess für weit verbreitete Apps einzusetzen, um z. B. die folgenden Richtlinien und Anforderungen durchzusetzen:

Richtlinie zur Sicherheitsprüfung
Geschäftsbewertungsrichtlinie
Anforderungen an das Application Lifecycle Management (ALM)
Benutzererfahrung und Branding-Anforderungen

Überlegen Sie, ob Sie das Feature Für alle freigeben in Power Platform deaktivieren wollen. Mit dieser Einschränkung darf nur eine kleine Gruppe von Administratoren eine Anwendung mit allen in der Umgebung teilen. Gehen Sie dabei wie folgt vor.

Führen Sie das Get-TenantSettings-Cmdlet aus, um die Liste der Mandanteneinstellungen Ihrer Organisation als Objekt abzurufen.

Das powerPlatform.PowerApps-Objekt enthält drei Kennzeichen:
Führen Sie die folgenden PowerShell-Befehle aus, um das Einstellungsobjekt abzurufen, und legen Sie die Variable zur Freigabe für alle auf „falsch“ fest.
```
$settings=Get-TenantSettings 
$settings.powerPlatform.powerApps.disableShareWithEveryone=$true 
```
Führen Sie das Set-TenantSettings-Cmdlet mit dem Einstellungsobjekt, um Ersteller daran zu hindern, ihre Apps für alle im Mandanten freizugeben.
```
  Set-TenantSettings $settings
```

Erlassen Sie eine Richtlinie zur Verhinderung von Datenverlust

Eine andere Möglichkeit, die Standardumgebung zu sichern, ist, eine Richtlinie zur Verhinderung von Datenverlust (DLP) dafür zu erstellen. Eine DLP-Richtlinie ist für die Standardumgebung ganz besonders wichtig, da alle Mitarbeitenden in Ihrer Organisation darauf zugreifen können. Hier sind einige Empfehlungen, die Ihnen die Durchsetzung der Richtlinie erleichtern sollen.

Passen Sie die DLP-Governance-Meldung an

Passen Sie die Fehlermeldung an, die angezeigt wird, wenn jemand eine App erstellt, die gegen die DLP-Richtlinie Ihrer Organisation verstößt. Verweisen Sie den Ersteller an die Power Platform-Hub Ihrer Organisation und geben Sie die E-Mail-Adresse Ihres CoE-Teams an.

Da das CoE-Team die DLP-Richtlinie im Laufe der Zeit weiter verfeinert, könnten Sie versehentlich einige Apps beschädigen. Stellen Sie sicher, dass die Meldung über einen Verstoß gegen die DLP-Richtlinie Kontaktdaten oder einen Link zu weiteren Informationen enthält, sodass Ersteller wissen, wie sie weiter vorgehen können.

Verwenden Sie die folgenden PowerShell-Cmdlets zum Anpassen der Governance-Richtliniennachricht:

Command	Beschreibung
Set-PowerAppDlpErrorSettings	Governance-Nachricht festlegen
Set-PowerAppDlpErrorSettings	Governance-Nachricht aktualisieren

Neue Konnektoren in der Standardumgebung blockieren

Standardmäßig werden alle neuen Connectors in der Gruppe „Nicht geschäftlich“ Ihrer DLP-Richtlinie eingeordnet. Sie können die Standardgruppe jederzeit in „Geschäftlich“ oder „Blockiert“ ändern. Bei einer DLP-Richtlinie, die auf die Standardumgebung angewendet wird, sollten Sie die Gruppe „Blockiert“ als Standard konfigurieren, damit neue Connectors unbrauchbar bleiben, bis sie von einem Ihrer Administrierenden überprüft wurden.

Beschränken Sie Ersteller auf vorgefertigte Connectors

Beschränken Sie Ersteller auf grundlegende, nicht blockierbare Connectors, um zu verhindern, dass sie auf den Rest zugreifen.

Verschieben Sie alle Konnektoren, die nicht blockiert werden können, in die Geschäftsdatengruppe.
Verschieben Sie alle Connectors, die blockiert werden können, in die blockierte Datengruppe.

Schränken Sie benutzerdefinierte Connectors ein

Benutzerdefinierte Connectors integrieren eine App oder einen Flow mit einem selbst entwickelten Dienst. Diese Dienste sind für technische Anwender wie Entwickler gedacht. Es ist eine gute Idee, den Speicherbedarf von APIs, die Ihre Organisation erstellt hat, zu reduzieren, die von Apps oder Flows in der Standardumgebung aufgerufen werden können. Damit Ersteller in der Standardumgebung keine benutzerdefinierten Connectors für APIs erstellen und verwenden können, erstellen Sie eine Regel zum Blockieren aller URL-Muster.

Um Erstellern den Zugriff auf einige APIs zu ermöglichen (z. B. einen Dienst, der eine Liste von Betriebsferien zurückgibt), konfigurieren Sie mehrere Regeln, die verschiedene URL-Muster in die geschäftlichen und nicht geschäftlichen Datengruppen klassifizieren. Stellen Sie sicher, dass Verbindungen immer das HTTPS-Protokoll verwenden. Erfahren Sie mehr über die DLP-Richtlinie für benutzerdefinierte Connectors.

Sichern Sie die Integration mit Exchange ab

Der Office 365 Outlook-Connectors ist einer der Standardconnectoren, der nicht blockiert werden kann. Dies erlaubt Erstellern, E-Mail-Nachrichten in den Postfächern, auf die sie Zugriff haben, zu senden, zu löschen und zu beantworten. Das Risiko bei diesem Connector ist auch eine seiner leistungsstärksten Funktionen – die Fähigkeit, eine E-Mail zu senden. Beispielsweise könnte ein Ersteller einen Flow erstellen, der eine E-Mail-Kampagne sendet.

Der Exchange-Administrator Ihrer Organisation kann Regeln auf dem Exchange Server einrichten, um zu verhindern, dass E-Mails von Apps gesendet werden. Es ist auch möglich, bestimmte Flows oder Apps von den Regeln auszuschließen, die zum Blockieren ausgehender E-Mails eingerichtet wurden. Sie können diese Regeln mit einer Positivliste von E-Mail-Adressen kombinieren, um sicherzustellen, dass E-Mails von Apps und Flows nur von einer kleinen Gruppe von Postfächern gesendet werden können.

Wenn eine App oder ein Flow eine E-Mail mithilfe des Office 365 Outlook-Connectors sendet, fügt sie bestimmte SMTP-Header in die E-Mail-Nachricht ein. Sie können in den Headern reservierte Phrasen verwenden, um zu identifizieren, ob die E-Mail von einem Flow oder einer App stammt.

Der in eine von einem Flow gesendete E-Mail eingefügte SMTP-Header sieht wie im folgenden Beispiel aus:

 x-ms-mail-application: Microsoft Power Automate; 
 User-Agent: azure-logic-apps/1.0 (workflow 2321aaccfeaf4d7a8fb792e29c056b03;version 08585414259577874539) microsoft-flow/1.0
 x-ms-mail-operation-type: Send
 x-ms-mail-environment-id: 0c5781e0-65ec-ecd7-b964-fd94b2c8e71b

Header-Details

Die folgende Tabelle beschreibt die Werte, die je nach verwendetem Dienst im Header „x-ms-mail-application“ erscheinen können:

Dienstleistung	Wert
Power Automate	Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow <GUID>; version <version number>) microsoft-flow/1.0
Power Apps	Microsoft Power Apps; User-Agent: PowerApps/ (; AppName= <app name>)

Die folgende Tabelle beschreibt die Werte, die je nach der durchgeführten Aktion im Header „x-ms-mail-operation-type“ erscheinen können:

Wert	Beschreibung
Antworten	Für Antwort-E-Mail-Vorgänge
Weiterleiten	Für Weiterleitungs-E-Mail-Vorgänge
Senden	Für E-Mail-Sendevorgänge einschließlich „SendEmailWithOptions“ und „SendApprovalEmail“

Der Header „x-ms-mail-environment-id header“ enthält den Umgebungs-ID-Wert. Das Vorhandensein dieses Headers hängt von dem Produkt ab, das Sie verwenden:

In Power Apps ist er immer vorhanden.
In Power Automate ist er nur in Verbindungen vorhanden, die nach Juli 2020 erstellt wurden.
In Logik-Apps ist er nie vorhanden.

Mögliche Exchange-Regeln für die Standardumgebung

Hier sind einige E-Mail-Aktionen, die Sie möglicherweise mit den Exchange-Regeln blockieren möchten.

Ausgehende E-Mails an externe Empfänger blockieren: Blockieren Sie alle ausgehenden E-Mails, die von Power Automate und Power Apps an externe Empfänger gesendet werden. Diese Regel hindert Ersteller daran, E-Mails von ihren Apps oder Flows an Partner, Kreditoren oder Kundschaft zu senden.
Ausgehende Weiterleitung blockieren: Blockieren Sie alle ausgehenden E-Mails, die über Power Automate und Power Apps an externe Empfänger weitergeleitet werden und deren Absender nicht von der Positivliste von Postfächern stammt. Diese Regel verhindert, dass Ersteller einen Flow erstellen, der eingehende E-Mails automatisch an einen externen Empfänger weiterleitet.

Ausnahmen, die bei E-Mail-Blockierungsregeln zu berücksichtigen sind

Hier sind einige mögliche Ausnahmen von den Exchange-Regeln zum Blockieren von E-Mails, um die Flexibilität zu erhöhen:

Bestimmte Apps und Flows ausnehmen: Fügen Sie den oben vorgeschlagenen Regeln eine Ausnahmeliste hinzu, damit genehmigte Apps oder Flows E-Mails an externe Empfänger senden können.
Positivliste auf Organisationsebene: In diesem Szenario ist es sinnvoll, die Lösung in eine dedizierte Umgebung zu verschieben. Wenn mehrere Flows in der Umgebung ausgehende E-Mails senden müssen, können Sie eine pauschale Ausnahmeregel erstellen, um ausgehende E-Mails aus dieser Umgebung zuzulassen. Die Entwickler- und Administratorberechtigungen für diese Umgebung müssen streng kontrolliert und begrenzt werden.

Nutzen Sie mandantenübergreifende Isolation

Power Platform verfügt über ein auf Microsoft Entra basierendes System aus Konnektoren, das es autorisierten Microsoft Entra-Benutzern ermöglicht, Apps und Flows mit Datenspeichern zu verbinden. Die Mandantenisolierung steuert die Übertragung von Daten von autorisierten Microsoft Entra-Datenquellen zu und von ihrem Mandanten.

Die Mandantenisolierung wird auf Mandantenebene angewendet und betrifft alle Umgebungen im Mandanten, auch die Standardumgebung. Da alle Mitarbeitenden in der Standardumgebung Ersteller sind, ist die Konfiguration einer robusten Richtlinie zur Mandantenisolierung für die Sicherung der Umgebung entscheidend. Sie sollten die Mandanten, mit denen sich Ihre Mitarbeiter verbinden können, explizit konfigurieren. Alle anderen Mandanten sollten durch Standardregeln abgedeckt werden, die sowohl den eingehenden als auch den ausgehenden Datenfluss blockieren.

Die Power Platform-Mandantenisolierung unterscheidet sich von der Microsoft Entra ID-weiten Mandantenbeschränkung. Sie wirkt sich nicht auf Microsoft Entra ID-basierten Zugriff außerhalb von Power Platform aus. Sie funktioniert nur für Konnektoren, die eine Microsoft Entra ID-basierte Authentifizierung verwenden, z. B. die Office 365 Outlook- und SharePoint-Konnektoren.

Siehe auch

Den mandantenübergreifenden Zugriff auf ausgehende und eingehende Verbindungen beschränken (Vorschau)

Get-PowerAppTenantIsolationPolicy (Microsoft.PowerApps.Administration.PowerShell)