Standardumgebung absichern

Alle Mitarbeiter 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.

Vergeben Sie Administratorrollen mit Bedacht

Überlegen Sie, ob Ihre Administratoren über die Rolle der Power Platform-Administrator verfügen müssen. Wäre die Rolle des Umgebungsadministrators oder des Systemadministrators angemessener? Beschränken Sie die mit mehr Macht verbundene Rolle des Power Platform-Administrators auf einige wenige Benutzer. Erfahren Sie mehr über die Verwaltung von Power Platform-Umgebungen.

Vermeiden Sie permanenten oder ständigen Zugriff, indem Sie die Just-in-Time-Funktionen (JIT) Ihres Identitätsanbieters nutzen. Befolgen Sie bei Situationen mit Notfallzugängen das Notfallzugangsverfahren. Verwenden Sie Privileged Identity Management (PIM), eine Funktion von Microsoft Entra ID, um die Verwendung dieser Rollen mit hohen Berechtigungen zu verwalten, zu steuern und zu überwachen.

Weitere Empfehlungen finden Sie unter Identitäts- und Zugriffsverwaltung konfigurieren.

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 genutzt werden soll. Hier sind einige Empfehlungen.

Die Standardumgebung umbenennen

Die Standardumgebung hat bei der Erstellung den Namen TenantName (default). Um die Absicht der Umgebung deutlich zu machen, ändern Sie den Namen auf etwas aussagekräftigeres wie Persönliche Produktivitätsumgebung.

Willkommensinhalte für Erstellende konfigurieren

Konfigurieren Sie eine benutzerdefinierte Willkommensnachricht, um Erstellern bei den ersten Schritten mit Power Apps und Copilot Studio zu helfen. Die Willkommensnachricht ersetzt die standardmäßige Power Apps-Hilfe beim ersten Zugriff für Ersteller. Nutzen Sie die Gelegenheit, die Absicht der Standardumgebung mit allen Erstellern zu teilen, sobald sie in der Standardumgebung landen.

Verwenden Sie den Power Platform Hub

Der 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
• Informationen zu folgenden Themen:
  • 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.

Verwaltete Umgebungen aktivieren

Sorgen Sie für robuste Sicherheit und Governance, indem Sie die Funktionen der verwalteten Umgebung in der Standardumgebung nutzen. Die Funktionen der verwalteten Umgebung bieten erweiterte Funktionen wie Überwachung, Compliance und Sicherheitskontrollen, die für den Schutz Ihrer Daten wichtig sind. Durch aktivieren dieses Feature können Sie Freigabebeschränkungen konfigurieren, mehr Nutzungseinblicke gewinnen, den Benutzerzugriff auf Microsoft Dataverse von nur zulässigen IP-Speicherorten einschränken und die Aktionsseite verwenden, um personalisierte Empfehlungen zur Optimierung der Umgebung zu erhalten. Bewerten Sie die aktuellen Funktionen für verwaltete Umgebungen, und halten Sie sich mit der Produkt-Roadmap auf dem Laufenden, um eine sichere, konforme und gut verwaltete Standardumgebung zu erhalten.

Übermäßige Freigabe verhindern

Power Platform ist als Low-Code-Plattform konzipiert, mit der Benutzer Apps und Flows schnell erstellen können. Diese Benutzerfreundlichkeit kann jedoch zu einer übermäßigen Freigabe von Apps und Flows führen, was Sicherheitsrisiken darstellen kann.

Freigabelimits konfigurieren

Um die Sicherheit zu erhöhen und eine übermäßige Freigabe in der Power Platform-Standardumgebung zu verhindern, schränken Sie ein, wie weit Benutzer Canvas-Apps, Flows und Agenten freigeben können. Überlegen Sie, Freigabegrenzwerte zu konfigurieren, um den Zugriff genauer zu kontrollieren. Solche Grenzwerte verringern das Risiko einer nicht autorisierten Nutzung, übermäßigen Freigabe und übermäßigen Nutzung ohne die erforderlichen Governance-Kontrollen. Die Implementierung von Freigabegrenzwerten trägt zum Schutz kritischer Informationen bei und fördert gleichzeitig einen sichereren und verwaltbareren Freigaberahmen innerhalb der Power Platform.

Schränken Sie das Teilen mit anderen ein

Ersteller können ihre Apps mit anderen einzelnen Benutzern und Sicherheitsgruppen teilen. Standardmäßig ist die Freigabe für die gesamte Organisation oder alle deaktiviert. Erwägen Sie die Verwendung eines kontrollierten Prozesses für weit verbreitete Apps, um Richtlinien und Anforderungen durchzusetzen. Zum Beispiel:

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

Die Funktion Für alle freigeben ist i Power Platform standardmäßig deaktiviert. Wir empfehlen, diese Einstellung deaktiviert zu lassen, um die übermäßige Exposition von Canvas-Apps mit 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 interner Mitglieder. Sie umfasst nicht nur interne Mitarbeitende in Ihrem Mandanten. Darüber hinaus kann die Mitgliedschaft der Gruppe Jeder weder bearbeitet noch angezeigt werden. Erfahren Sie mehr über spezielle Identitätsgruppen.

Wenn Sie die App für alle internen Mitarbeiter oder eine große Gruppe von Personen freigeben möchten, sollten Sie eine vorhandene Sicherheitsgruppe verwenden oder eine Sicherheitsgruppe erstellen, um Ihre App freizugeben.

Wenn Mit allen teilen deaktiviert ist, können nur Dynamics 365-Administratoren, Power Platform-Administratoren und globale Administratoren eine Anwendung für alle in der Umgebung freigeben. Wenn Sie Administrationsfachkraft sind, können Sie den folgenden PowerShell-Befehl ausführen, um die Freigabe für Jeden zu ermöglichen:

1. Öffnen Sie zunächst PowerShell als Administrationsfachkraft 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:

   

3. Führen Sie die folgenden PowerShell-Befehle aus, um das Einstellungsobjekt abzurufen, und legen Sie die Variable disableShareWithEveryone auf $false fest:

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

4. Verwenden Sie das Set-TenantSettings cmdlet mit dem Einstellungsobjekt, um Entwickler zu befähigen, ihre Apps für alle im Mandanten freizugeben.

     Set-TenantSettings $settings
   

   Um die Freigabe für jeden zu deaktivieren, führen Sie die gleichen Schritte aus, aber legen Sie $settings.powerPlatform.powerApps.disableShareWithEveryone = $true fest.

Einrichten einer Datenrichtlinie

Eine weitere Möglichkeit zum Sichern der Standardumgebung besteht darin, eine Datenrichtlinie dafür zu erstellen. Die Bereitstellung einer Datenrichtlinie ist besonders wichtig für die Standardumgebung, da alle Mitarbeiter in Ihrer Organisation Zugriff darauf haben. Hier sind einige Empfehlungen, die Ihnen die Durchsetzung der Richtlinie erleichtern sollen.

Anpassen der Datenrichtlinien-Governance-Nachricht

Passen Sie die Fehlermeldung an, die angezeigt wird, wenn ein Hersteller eine App erstellt, die gegen die Datenrichtlinie 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 Datenrichtlinie im Laufe der Zeit optimiert, können Sie einige Apps versehentlich unterbrechen. Stellen Sie sicher, dass die Datenrichtlinienverletzungsnachricht Kontaktdetails oder einen Link zu weiteren Informationen enthält, um den Entscheidungsträgern eine Möglichkeit zu bieten.

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

Neue Konnektoren in der Standardumgebung blockieren

Standardmäßig werden alle neuen Connectors in der Nicht-Geschäftskategorie Ihrer Datenrichtlinie eingeordnet. Sie können die Standardgruppe jederzeit in „Geschäftlich“ oder „Blockiert“ ändern. Für eine Datenrichtlinie, die auf die Standardumgebung angewendet wird, empfehlen wir, die Gruppe "Blockiert" als Standard zu konfigurieren, um sicherzustellen, dass neue Connectors nicht mehr verwendet werden können, bis sie von einem Ihrer Administratoren überprüft wurden.

Beschränken Sie Ersteller auf vorgefertigte Connectors

Beschränken Sie Entwickler auf einfache, nicht blockierbare Konnektoren, um den Zugriff auf andere Konnektoren zu blockieren.

• Verschieben Sie alle Konnektoren, die nicht blockiert werden können, in die Geschäftsdatengruppe.
• Verschieben Sie alle Konnektoren, die blockiert werden können, in die 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 Konnektoren 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. Weitere Informationen zu Datenrichtlinien für benutzerdefinierte Connectors.

Sichern Sie die Integration mit Exchange ab

Der Office 365 Outlook-Connector ist einer der Standardkonnektoren, 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 ungefähr 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

x-ms-mail-application

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

x-ms-mail-operation-type

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

x-ms-mail-environment-id

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

Erfahren Sie mehr darüber, wie Sie die entsprechenden Exfiltrationsregeln für mit Power Platform zusammenhängenden E-Mail-Datenverkehr einrichten.

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. Wir empfehlen Ihnen, die Mandanten, mit denen sich Ihre Mitarbeitenden verbinden können, explizit zu 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 Microsoft Entra ID-weiten Mandantenbeschränkungen. Der Microsoft Entra ID-basierte Zugriff außerhalb von Power Platform ist nicht betroffen. Sie gilt nur für Connectors, welche die Microsoft Entra ID-basierte Authentifizierung verwenden, wie Office 365 Outlook- und SharePoint-Connectors.

Erfahren Sie mehr:

• Beschränkungen für den ein- und ausgehenden mandantenübergreifenden Zugriff
• Get-PowerAppTenantIsolationPolicy (Microsoft.PowerApps.Administration.PowerShell)

Nächste Schritte,

Lesen Sie die ausführlichen Artikel dieser Serie, um Ihre Sicherheitslage weiter zu verbessern:

• Bedrohungen für Ihre Organisation erkennen
• Kontrolle für Datenschutz und Privatsphäre einrichten
• Implementieren einer Datenrichtlinienstrategie
• Identitäts- und Zugriffsverwaltung konfigurieren
• Erfüllen Sie Compliance-Anforderungen

Lesen Sie nach der Lektüre der Artikel die Sicherheitscheckliste durch, um sicherzustellen, dass die Power Platform-Bereitstellungen robust und resilient sind und den Best Practices entsprechen.