Teilen über

Standardumgebung absichern

  • Artikel

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.

Schränken Sie das Teilen mit anderen ein

Hersteller können ihre Apps mit anderen Einzelbenutzern und Sicherheitsgruppen Teilenieren . Standardmäßig ist die Freigabe für Ihre gesamte Organisation oder für Alle deaktiviert. Erwägen Sie die Verwendung eines Gated-Prozesses für häufig verwendete Apps, um Richtlinien und Anforderungen wie diese durchzusetzen:

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

Die Funktion Teilen mit „Jeder“ ist in Power Platform standardmäßig deaktiviert. Wir empfehlen, diese Einstellung deaktiviert zu lassen, um die übermäßige Aussetzung von Canvas-Apps gegenüber unbeabsichtigten Benutzern zu begrenzen. Die Gruppe Jeder für Ihre Organisation enthält alle Benutzer, die sich jemals bei Ihrem Mandanten angemeldet haben, einschließlich Gäste und interne Mitglieder. Es betrifft nicht nur alle internen Mitarbeiter innerhalb Ihres Mandanten. Darüber hinaus kann die Mitgliedschaft der Gruppe Jeder weder bearbeitet noch angezeigt werden. Weitere Informationen zur Gruppe Jeder finden Sie unter /windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyone.

Wenn Sie Teilen mit allen internen Mitarbeitern oder einer großen Gruppe von Personen teilen möchten, ziehen Sie die Freigabe für eine vorhandene Sicherheitsgruppe dieser Mitglieder in Betracht oder erstellen Sie eine Sicherheitsgruppe und teilen Sie Ihre App mit dieser Sicherheitsgruppe.

Wenn Teilen mit „Jeder“ deaktiviert ist, kann nur eine kleine Gruppe von Administratoren eine Anwendung mit jedem im Umgebung Teilen. Wenn Sie ein Administrator sind, können Sie den folgenden PowerShell-Befehl ausführen, wenn Sie die Freigabe für Jeder aktivieren müssen.

  1. Öffnen Sie zunächst PowerShell als Administrator und melden Sie sich bei Ihrem Power Apps Konto an, indem Sie diesen Befehl ausführen.

    Add-PowerAppsAccount

  2. 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:

    Screenshot von drei Kennzeichen im $settings.powerPlatform.PowerApps-Objekt.

  3. Führen Sie die folgenden PowerShell-Befehle aus, um das Einstellungsobjekt abzurufen und die Variable „disableShareWithEveryone“ auf „$false“ festzulegen.

    $settings=Get-TenantSettings 
$settings.powerPlatform.powerApps.disableShareWithEveryone=$false

  4. Führen Sie das Set-TenantSettings Cmdlet mit dem Einstellungsobjekt aus, um es Herstellern zu ermöglichen, ihre Apps mit allen im Mandanten zu Teilenieren.

      Set-TenantSettings $settings

    Um die Freigabe für Jeder zu deaktivieren, führen Sie folgen dieselben Schritte aus, legen Sie jedoch $settings.powerPlatform.powerApps.disableShareWithEveryone = $true fest.

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 Konnektoren in die Gruppe „Nicht geschäftlich“ Ihrer DLP-Richtlinie eingefügt. 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.

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

  2. Verschieben Sie alle Konnektoren, die blockiert werden können, in die Gruppe blockierter Daten.

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 Konnektoren.

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.

Weitere Informationen zum Einrichten der entsprechenden Exfiltrationsregeln für Power Platform bezogenen E-Mail-Verkehr finden Sie unter E-Mail-Exfiltrationskontrollen für Konnektoren.

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

Mandantenübergreifenden eingehenden und ausgehenden Zugriff einschränken (Vorschauversion)

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