Empfehlungen für die Identitäts- und Zugriffsverwaltung

Gilt für diese Power Platform Well-Architected Sicherheitschecklisten-Empfehlungen:

SE:05 Implementieren Sie strenge, bedingte und auditierbare Identitäts- und Zugriffsverwaltung (IAM) für alle Arbeitsauslastungsbenutzer, Teammitglieder und Systemkomponenten. Beschränken Sie den Zugriff ausschließlich auf das Notwendige. Verwenden Sie moderne Branchenstandards für alle Authentifizierungs- und Autorisierungsimplementierungen. Einschränken und strenges Überwachen des Zugriffs, der nicht auf Identität basiert.

In diesem Leitfaden werden die Empfehlungen für die Authentifizierung und Autorisierung von Identitäten beschrieben, die versuchen, auf Ihre Workloadressourcen zuzugreifen.

Aus kontrolltechnischer Sicht ist Identität immer der primäre Perimeter. Dieser Umfang umfasst nicht nur die Ränder Ihrer Arbeitslast. Sie umfasst auch einzelne Komponenten, die sich innerhalb Ihrer Workload befinden.

Typische Identitäten sind:

  • Menschen. Anwendungsbenutzer, Administratoren, Operatoren, Auditoren und schlechte Akteure.
  • Systeme. Workloadidentitäten, verwaltete Identitäten, API-Schlüssel, Dienstprinzipale und Azure-Ressourcen.
  • Anonym. Entitäten, die keine Beweise dafür bereitgestellt haben, wer sie sind.

Definitionen

Bedingungen Definition
Authentifizierung (AuthN) Ein Prozess, der überprüft, ob eine Identität tatsächlich dem entspricht, was sie vorgibt zu sein.
Autorisierung (AuthZ) Ein Prozess, der überprüft, ob eine Identität über die Berechtigung zum Ausführen einer angeforderten Aktion verfügt.
Bedingter Zugriff Eine Reihe von Regeln, die Aktionen basierend auf angegebenen Kriterien zulässt.
IdP (Identitätsanbieter) Ein Identitätsanbieter, z. B. Microsoft Entra ID.
Person Eine Stellenfunktion oder ein Titel, der über eine Reihe von Zuständigkeiten und Aktionen verfügt.
Vorab vereinbarter Schlüssel Eine Art geheimer Schlüssel, der zwischen einem Anbieter und Verbraucher geteilt wird und über einen sicheren und vereinbarten Mechanismus verwendet wird.
Ressourcenidentität Eine Identität, die für Cloudressourcen definiert ist, die von der Plattform verwaltet werden.
Rolle Eine Gruppe von Berechtigungen, die definieren, was ein Benutzer oder eine Gruppe tun kann.
Umfang Unterschiedliche Ebenen der Organisationshierarchie, in denen eine Rolle operieren darf. Außerdem eine Gruppe von Features in einem System.
Sicherheitsprinzipal Eine Identität, die Berechtigungen bereitstellt. Dabei kann es sich um einen Benutzer, eine Gruppe oder einen Dienstprinzipal handeln. Alle Gruppenmitglieder erhalten dieselbe Zugriffsebene.
Benutzeridentität Eine Identität für eine Person, z. B. ein Mitarbeiter oder ein externer Benutzer.
Workload-Identität Eine Systemidentität für eine Anwendung, einen Dienst, ein Skript, einen Container oder eine andere Komponente einer Workload, die verwendet wird, um sich bei anderen Diensten und Ressourcen zu authentifizieren.

Hinweis

Eine Identität kann mit anderen, ähnlichen Identitäten unter einem übergeordneten Element gruppiert werden, das als Sicherheitsprinzipal bezeichnet wird. Eine Sicherheitsgruppe ist ein Beispiel für einen Sicherheitsprinzipal. Diese hierarchische Beziehung vereinfacht die Wartung und verbessert die Konsistenz. Da Identitätsattribute nicht auf der individuellen Ebene behandelt werden, werden die Fehlerchancen ebenfalls reduziert. In diesem Artikel schließt der Begriff "Identität" Sicherheitsprinzipale ein.

Microsoft Entra ID als Identitätsanbieter für Power Platform

Alle Power Platform-Produkte verwenden Microsoft Entra ID (ehemals Azure Active Directory oder Azure AD) für die Identitäts- und Zugriffsverwaltung. Mit Entra ID können Organisationen die Identität für ihre Hybrid- und Multicloud-Umgebungen sichern und verwalten. Entra ID ist auch für die Verwaltung von Unternehmensgästen wichtig, die Zugriff auf Power Platform Ressourcen benötigen. Power Platform verwendet Entra ID auch zur Verwaltung anderer Anwendungen, die mithilfe der Dienstprinzipalfunktionen in Power Platform-APIs integriert werden müssen. Durch die Verwendung von Entra ID kann Power Platform mehr erweiterte Sicherheitsfunktionen von Entra ID wie etwa bedingten Zugriff und fortlaufende Zugriffsevaluierung nutzen.

Authentifizierung

Die Authentifizierung ist ein Prozess, der Identitäten überprüft. Die anfordernde Identität ist erforderlich, um eine Form der nachweisbaren Identifizierung bereitzustellen. Zum Beispiel:

  • Ein Benutzername und ein Kennwort.
  • Ein geheimer Schlüssel vor der Freigabe, z. B. ein API-Schlüssel, der Zugriff gewährt.
  • Ein SAS-Token (Shared Access Signature).
  • Ein Zertifikat, das bei der gegenseitigen Authentifizierung von Transport Layer Security (TLS) verwendet wird.

Die Power Platform-Authentifizierung umfasst eine Abfolge von Anforderungen, Antworten und Umleitungen zwischen dem Browser des Benutzers und power Platform oder Azure Diensten. Die Sequenz folgt dem Microsoft Entra ID Authentifizierungscode-Genehmigungsfluss.

Die Verbindung und Authentifizierung mit einer Datenquelle erfolgt separat von der Authentifizierung für einen Power Platform-Dienst. Weitere Informationen finden Sie unter Verbinden mit und Authentifizieren bei Datenquellen.

Autorisierung

Power Platform verwendet Microsoft Entra ID Microsoft Identity Platform für die Autorisierung aller API-Aufrufe mit dem Branchenstandard-OAuth 2.0-Protokoll.

Wichtige Designstrategien

Um die Identitätsanforderungen für eine Workload zu verstehen, müssen Sie die Benutzer- und Systemflows, Workloadressourcen und Personas sowie die von ihnen ausgeführten Aktionen auflisten.

Für jeden Anwendungsfall wird es wahrscheinlich einen eigenen Satz von Kontrollen geben, die Sie mit einer ‚Assume-Breach‘-Mentalität entwerfen müssen. Identifizieren Sie basierend auf den Identitätsanforderungen des Anwendungsfalls oder der Personas die bedingten Auswahlmöglichkeiten. Vermeiden Sie die Verwendung einer Lösung für alle Anwendungsfälle. Umgekehrt sollten die Steuerelemente nicht so präzise sein, dass sie unnötigen Verwaltungsaufwand verursachen.

Sie müssen den Identitätszugriffspfad protokollieren. Auf diese Weise können Sie die Steuerelemente überprüfen, und Sie können die Protokolle für Complianceüberwachungen verwenden.

Ermitteln aller Identitäten für die Authentifizierung

Extern zugänglicher Zugriff Die Power Platform-Authentifizierung umfasst eine Abfolge von Anforderungen, Antworten und Umleitungen zwischen dem Browser des Benutzers und power Platform oder Azure Diensten. Die Sequenz folgt dem Microsoft Entra ID Authentifizierungscode-Genehmigungsfluss. Power Platform authentifiziert automatisch alle Benutzer, die aus verschiedenen Gründen auf die Arbeitslast zugreifen.

Zugriff von innen nach außen. Ihre Workload muss auf andere Ressourcen zugreifen. Beispielsweise das Lesen von oder Schreiben in die Datenplattform, das Abrufen von geheimen Schlüsseln aus dem geheimen Speicher und die Protokollierung von Telemetriedaten an Überwachungsdienste. Es kann sogar erforderlich sein, auf Dienste von Drittanbietern zuzugreifen. Dies sind alles Anforderungen an Workload-Identitäten. Sie müssen jedoch auch die Anforderungen an die Ressourcenidentität berücksichtigen, beispielsweise wie Bereitstellungspipelines ausgeführt und authentifiziert werden.

Aktionen zur Autorisierung bestimmen

Als Nächstes müssen Sie wissen, was jede authentifizierte Identität zu tun versucht, damit diese Aktionen autorisiert werden können. Die Aktionen können durch den Typ des Zugriffs geteilt werden, den sie benötigen:

  • Datenebenenzugriff. Aktionen, die in der Datenebene stattfinden, führen zu Datenübertragungen. Beispielsweise eine Anwendung, die Daten aus Microsoft Dataverse liest oder schreibt oder Protokolle in Application Insights schreibt.

  • Zugriff auf die Steuerebene. Aktionen, die in der Steuerungsebene stattfinden, führen dazu, dass eine Power Platform-Ressource erstellt, geändert oder gelöscht wird. Beispielsweise das Ändern von Umgebungseigenschaften oder das Erstellen einer Datenrichtlinie.

Anwendungen zielen in der Regel auf Datenebenen ab, während Vorgänge häufig sowohl auf Kontroll- als auch auf Datenebenen zugreifen.

Bereitstellen einer rollenbasierten Autorisierung

Basierend auf der Verantwortung jeder Identität autorisieren Sie Aktionen, die zulässig sein sollten. Eine Identität darf nicht mehr tun, als sie tun muss. Bevor Sie Autorisierungsregeln festlegen, müssen Sie ein klares Verständnis darüber haben, wer oder was Anforderungen stellt, was diese Rolle tun darf und in welchem Umfang dies möglich ist. Diese Faktoren führen zu Auswahlmöglichkeiten, die Identität, Rolle und Bereich kombinieren.

Beachte Folgendes:

  • Muss die Workload sowohl für den Lese- als auch für den Schreibzugriff Zugriff auf die Datenebene von Dataverse haben?
  • Benötigt die Workload auch Zugriff auf Umgebungseigenschaften?
  • Wenn die Identität durch einen bösartigen Akteur kompromittiert wird, welche Auswirkungen hätte dies auf das System im Hinblick auf Vertraulichkeit, Integrität und Verfügbarkeit?
  • Benötigt die Workload permanenten Zugriff oder kann bedingter Zugriff in Betracht gezogen werden?
  • Führt die Workload Aktionen aus, die administrative/erhöhte Berechtigungen erfordern?
  • Wie interagiert die Workload mit Diensten von Drittanbietern?
  • Für Agenten, haben Sie Anforderungen für Single Sign-On (SSO)?
  • Wird der Agent im nicht authentifizierten Modus, im authentifizierten Modus oder in beiden ausgeführt?

Rollenzuweisung

Eine Rolle ist ein Satz von Berechtigungen, der einer Identität zugewiesen ist. Weisen Sie Rollen zu, mit denen die Entität nur die Aufgabe erledigen kann und nichts darüber hinaus. Wenn die Berechtigungen des Benutzers auf ihre Auftragsanforderungen beschränkt sind, ist es einfacher, verdächtiges oder nicht autorisiertes Verhalten im System zu erkennen.

Stellen Sie Fragen wie diese:

  • Ist schreibgeschützter Zugriff ausreichend?
  • Benötigt die Identität Berechtigungen zum Löschen von Ressourcen?
  • Benötigt die Rolle nur Zugriff auf die von ihr erstellten Datensätze?
  • Ist ein hierarchischer Zugriff basierend auf der Unternehmenseinheit, in der sich der Benutzer befindet, erforderlich?
  • Benötigt die Rolle administrative oder erweiterte Berechtigungen?
  • Benötigt die Rolle dauerhaften Zugriff auf diese Berechtigungen?
  • Was passiert, wenn der Benutzer den Arbeitsplatz wechselt?

Durch die Beschränkung der Zugriffsebene von Benutzern, Anwendungen oder Diensten wird die potenzielle Angriffsfläche verringert. Wenn Sie nur die Mindestberechtigungen erteilen, die zum Ausführen bestimmter Aufgaben erforderlich sind, wird das Risiko eines erfolgreichen Angriffs oder eines nicht autorisierten Zugriffs erheblich reduziert. Beispielsweise benötigen Entwickler nur Entwicklerzugriff auf die Entwicklungsumgebung, nicht aber auf die Produktionsumgebung. Sie benötigen nur Zugriff, um Ressourcen zu erstellen, nicht aber, um Umgebungseigenschaften zu ändern. Außerdem benötigen sie möglicherweise nur Zugriff zum Lesen/Schreiben von Daten aus Dataverse, jedoch nicht zum Ändern des Datenmodells oder der Attribute der Dataverse-Tabelle.

Vermeiden Sie Berechtigungen, die auf einzelne Benutzer abzielen. Granulare und benutzerdefinierte Berechtigungen führen zu Komplexität und Verwirrung und können schwer aufrechtzuerhalten sein, wenn Benutzer die Rolle wechseln und innerhalb des Unternehmens umziehen oder wenn neue Benutzer mit ähnlichen Authentifizierungsanforderungen dem Team beitreten. Diese Situation kann zu einer komplexen Legacy-Konfiguration führen, die schwer zu warten ist und sich negativ auf Sicherheit und Zuverlässigkeit auswirkt.

Tradeoff: Ein granularer oder feinkörniger Zugriffssteuerungsansatz ermöglicht eine bessere Protokollierung und Überwachung von Benutzeraktivitäten.

Gewähren Sie Rollen, die mit den geringsten Berechtigungen beginnen, und fügen Sie basierend auf Ihren betrieblichen oder Datenzugriffsanforderungen mehr hinzu. Ihre technischen Teams müssen klare Anleitungen zum Implementieren von Berechtigungen haben.

Auswahlmöglichkeiten für bedingten Zugriff

Geben Sie nicht allen Identitäten dieselbe Zugriffsebene. Stützen Sie Ihre Entscheidungen auf zwei Hauptfaktoren:

  • Zeit. Wie lange die Identität auf Ihre Umgebung zugreifen kann.
  • Berechtigung Die Berechtigungsstufe.

Diese Faktoren schließen sich nicht gegenseitig aus. Eine kompromittierte Identität mit mehr Berechtigungen und unbegrenzter Zugriffsdauer kann mehr Kontrolle über das System und die Daten erlangen oder diesen Zugriff verwenden, um die Umgebung weiterhin zu ändern. Beschränken Sie diese Zugriffsfaktoren sowohl als präventive Maßnahme als auch um den Strahlradius zu steuern.

Just in Time (JIT)- Ansätze bieten nur die erforderlichen Berechtigungen, wenn sie benötigt werden.

Just Enough Access (JEA) bietet nur die erforderlichen Berechtigungen.

Obwohl Zeit und Berechtigungen die hauptfaktoren sind, gibt es andere Bedingungen, die gelten. Sie können z. B. auch das Gerät, das Netzwerk und den Standort verwenden, von dem der Zugriff zum Festlegen von Richtlinien stammt.

Verwenden Sie starke Steuerelemente, die nicht autorisierten Zugriff filtern, erkennen und blockieren, einschließlich Parametern wie Benutzeridentität und Standort, Geräteintegrität, Workloadkontext, Datenklassifizierung und Anomalien.

Drittanbieteridentitäten wie Lieferanten, Partner und Kunden müssen möglicherweise auf Ihre Workload zugreifen. Sie benötigen die entsprechende Zugriffsebene anstelle der Standardberechtigungen, die Sie Vollzeitmitarbeitern zur Verfügung stellen. Eine klare Differenzierung externer Konten erleichtert das Verhindern und Erkennen von Angriffen, die aus diesen Vektoren stammen.

Konten mit kritischen Auswirkungen

Administrative Identitäten führen einige der höchsten Sicherheitsrisiken ein, da die von ihnen ausgeführten Aufgaben privilegierten Zugriff auf eine breite Palette dieser Systeme und Anwendungen erfordern. Kompromittierung oder Missbrauch kann sich negativ auf Ihr Unternehmen und seine Informationssysteme auswirken. Sicherheit der Verwaltung ist einer der kritischsten Sicherheitsbereiche.

Der Schutz des privilegierten Zugriffs vor entschlossenen Widersachern erfordert einen vollständigen und durchdachten Ansatz, um diese Systeme gegen Risiken zu isolieren. Hier sind einige Strategien aufgeführt:

  • Minimieren Sie die Anzahl kritischer Auswirkungskonten.

  • Verwenden Sie separate Rollen , anstatt Berechtigungen für vorhandene Identitäten zu erhöhen.

  • Vermeiden Sie permanenten oder ständigen Zugriff , indem Sie die JIT-Features Ihres IdP verwenden. Für Bruchglassituationen folgen Sie einem Notfallzugriffsprozess.

  • Verwenden Sie moderne Zugriffsprotokolle wie kennwortlose Authentifizierung oder mehrstufige Authentifizierung. Externalisieren Sie diese Mechanismen auf Ihren IdP.

  • Erzwingen Sie wichtige Sicherheitsattribute mithilfe von Richtlinien für bedingten Zugriff.

  • Stilllegen Sie administrative Konten, die nicht verwendet werden.

Einrichten von Prozessen zum Verwalten des Identitätslebenszyklus

Der Zugriff auf Identitäten darf nicht länger dauern als die Ressourcen, auf die die Identitäten zugreifen. Stellen Sie sicher, dass Sie über einen Prozess zum Deaktivieren oder Löschen von Identitäten verfügen, wenn Änderungen an der Teamstruktur oder softwarekomponenten vorliegen.

Dieser Leitfaden gilt für Quellcodeverwaltung, Daten, Steuerungsebenen, Arbeitslastbenutzer, Infrastruktur, Hilfsmittel, Überwachung von Daten, Protokollen, Metriken und anderen Entitäten.

Richten Sie einen Identitätsgovernanceprozess ein, um den Lebenszyklus digitaler Identitäten, privilegierter Benutzer, externer/Gastbenutzer und Workloadbenutzer zu verwalten. Implementieren Sie Zugriffsüberprüfungen, um sicherzustellen, dass die Arbeitsauslastungsberechtigungen entfernt werden, wenn Identitäten die Organisation oder das Team verlassen.

Schützen nicht identitätsbasierte Geheimnisse

Anwendungsgeheimnisse wie vorverschlüsselte Schlüssel sollten als anfällige Punkte im System betrachtet werden. Wenn der Anbieter oder Verbraucher kompromittiert wird, können in der bidirektionale Kommunikation erhebliche Sicherheitsrisiken eingeführt werden. Diese Schlüssel können auch belastend sein, da sie operative Prozesse einführen.

Behandeln Sie diese Geheimnisse als Entitäten, die dynamisch aus einem geheimen Speicherort abgerufen werden können. Sie sollten nicht in Ihren Apps, Flows, Bereitstellungspipelines oder anderen Artefakten hartcodiert sein.

Achten Sie darauf, dass Sie geheime Schlüssel widerrufen können.

Wenden Sie Betriebsmethoden an, die Aufgaben wie Schlüsselrotation und Ablaufdatum behandeln.

Informationen zu Rotationsrichtlinien finden Sie unter Automatisieren Sie die Rotation eines Geheimnisses für Ressourcen, die zwei Sätze von Authentifizierungsnachweisen haben und Tutorial: Aktualisieren der Frequenz der automatischen Zertifikatsrotation im Key Vault.

Schützen von Entwicklungsumgebungen

Der Schreibzugriff auf Entwicklungsumgebungen sollte eingeschränkt werden, und der Lesezugriff auf den Quellcode sollte auf Rollen beschränkt werden, die nur bei Bedarf davon Kenntnis erhalten. Sie sollten über ein Verfahren verfügen, das die Ressourcen regelmäßig scannt und die neuesten Schwachstellen ermittelt.

Verwalten eines Audit-Trails

Ein Aspekt der Identitätsverwaltung ist die Sicherstellung, dass das System überprüfbar ist. Audits überprüfen, ob Strategien gegen Sicherheitsverletzungen wirksam sind. Die Führung eines Audit-Trails hilft Ihnen dabei:

  • Überprüfen Sie, ob die Identität durch starke Authentifizierung verifiziert wird. Jede Aktion muss nachverfolgt werden können , um Abstreitungsangriffe zu verhindern.

  • Erkennen Sie schwache oder fehlende Authentifizierungsprotokolle , und erhalten Sie Einblicke in Benutzer- und Anwendungsanmeldungen.

  • Bewerten Sie den Zugriff von Identitäten auf die Workload basierend auf Sicherheits- und Complianceanforderungen , und berücksichtigen Sie das Benutzerkontorisiko, den Gerätestatus und andere von Ihnen festgelegte Kriterien und Richtlinien.

  • Nachverfolgen des Fortschritts oder der Abweichung von Complianceanforderungen.

Die meisten Ressourcen haben Zugriff auf die Datenebene. Sie müssen die Identitäten kennen, die auf Ressourcen und die aktionen zugreifen, die sie ausführen. Sie können diese Informationen für die Sicherheitsdiagnose verwenden.

Unterstützung der Power Platform

Die Power Platform-Zugriffssteuerung ist ein wichtiger Teil der gesamten Sicherheitsarchitektur. Zugriffssteuerungspunkte können sicherstellen, dass die richtigen Benutzer Zugriff auf die Power Platform-Ressourcen erhalten. In diesem Abschnitt untersuchen wir die verschiedenen Zugriffspunkte, die Sie konfigurieren können, und ihre Rolle in Ihrer allgemeinen Sicherheitsstrategie.

Microsoft Entra ID

Alle Power Platform-Produkte verwenden Microsoft Entra ID (ehemals Azure Active Directory oder Azure AD) für die Identitäts- und Zugriffsverwaltung. Mit Entra ID können Organisationen die Identität für ihre Hybrid- und Multicloud-Umgebungen sichern und verwalten. Entra ID ist auch für die Verwaltung von Unternehmensgästen wichtig, die Zugriff auf Power Platform Ressourcen benötigen. Power Platform verwendet Entra ID auch zur Verwaltung anderer Anwendungen, die mithilfe der Dienstprinzipalfunktionen in Power Platform-APIs integriert werden müssen. Durch die Verwendung von Entra ID kann die Power Platform mehr erweiterte Sicherheitsfunktionen von Entra ID wie etwa bedingten Zugriff und fortlaufende Zugriffsevaluierung nutzen.

Diagramm eines Cloud Computing-Systems.

Lizenzzuweisung

Der Zugriff auf Power Apps und Power Automate beginnt mit der Lizenz. Die Ressourcen und Daten, auf die ein Benutzer zugreifen kann, werden durch den Lizenztyp bestimmt, über den sie jeweils verfügen. Die folgende Tabelle beschreibt die allgemeinen Unterschiede der Ressourcen, die für einen Benutzer auf Basis des Plantyps verfügbar sind. Präzise Lizenzierungsdetails finden Sie in der Lizenzierungsübersicht.

Bedingte Zugriffsrichtlinien

Der bedingte Zugriff beschreibt Ihre Richtlinie für eine Zugriffsentscheidung. Um bedingten Zugriff zu verwenden, müssen Sie die Für den Anwendungsfall erforderlichen Einschränkungen verstehen. Konfigurieren Sie Microsoft Entra bedingten Zugriff, indem Sie eine Zugriffsrichtlinie einrichten, die auf Ihren betrieblichen Anforderungen basiert.

Erfahren Sie mehr:

Fortlaufender Zugriff

Der fortlaufende Zugriff wird beschleunigt, wenn bestimmte Ereignisse ausgewertet werden, um zu bestimmen, ob der Zugriff widerrufen werden soll. Traditionell tritt bei der OAuth 2.0-Authentifizierung das Ablaufdatum von Zugriffstoken ein, wenn während der Tokenerneuerung eine Überprüfung erfolgt. Beim fortlaufenden Zugriff werden kritische Ereignisse und Netzwerkstandortänderungen eines Benutzers kontinuierlich ausgewertet, um zu bestimmen, ob der Benutzer weiterhin Zugriff behalten sollte. Diese Auswertungen können zu einer vorzeitigen Beendigung aktiver Sitzungen führen oder eine erneute Authentifizierung erforderlich machen. Wenn beispielsweise ein Benutzerkonto deaktiviert wird, sollte es den Zugriff auf die App verlieren. Auch der Standort ist wichtig. Beispielsweise kann das Token von einem vertrauenswürdigen Standort aus autorisiert worden sein, der Benutzer hat seine Verbindung jedoch auf ein nicht vertrauenswürdiges Netzwerk umgestellt. Bei fortlaufendem Zugriff würde die Auswertung der Richtlinie für bedingten Zugriff ausgelöst und der Benutzer würde den Zugriff verlieren, da er keine Verbindung mehr von einem genehmigten Standort aus herstellt.

Power Platform unterstützt derzeit nur Dataverse die fortlaufende Zugriffsevaluierung. Microsoft arbeitet daran, Unterstützung für andere Power Platform Services und Clients hinzuzufügen. Weitere Informationen finden Sie unter Continuous access evaluation.

Mit der fortschreitenden Einführung hybrider Arbeitsmodelle und der Nutzung von Cloud-Anwendungen ist Entra ID zu einem entscheidenden primären Sicherheitsbereich für den Schutz von Benutzern und Ressourcen geworden. Durch bedingten Zugriff wird dieser Perimeter über einen Netzwerkperimeter hinaus erweitert, um die Benutzer- und Geräteidentität einzubeziehen. Durch fortlaufenden Zugriff wird sichergestellt, dass der Zugriff neu bewertet wird, wenn sich Ereignisse oder Benutzerstandorte ändern. Power Platform verwendet Entra ID und ermöglicht Ihnen die Implementierung von Sicherheits-Governance auf Organisationsebene, die Sie konsistent auf Ihr gesamtes Anwendungsportfolio anwenden können. Überprüfen Sie diese Best Practices für das Identitätsmanagement, um weitere Anleitungen zum Erstellen Ihres eigenen Plans zur Verwendung von Entra ID mit Power Platform zu erhalten.

Gruppenzugriffsverwaltung

Anstatt bestimmten Benutzern Berechtigungen zu gewähren, weisen Sie gruppen in Microsoft Entra ID Zugriff zu. Wenn keine Gruppe vorhanden ist, arbeiten Sie mit Ihrem Identitätsteam zusammen, um eine gruppe zu erstellen. Anschließend können Sie Gruppenmitglieder außerhalb Azure hinzufügen und entfernen und sicherstellen, dass Berechtigungen aktuell sind. Sie können die Gruppe auch für andere Zwecke wie Mailinglisten verwenden.

Weitere Informationen finden Sie unter Sichere Zugriffssteuerung mithilfe von Gruppen in der Microsoft Entra-ID.

Bedrohungserkennung

Microsoft Entra ID Protection kann Ihnen helfen, identitätsbasierte Risiken zu erkennen, zu untersuchen und zu beheben. Weitere Informationen finden Sie unter "What is Identity Protection".

Die Bedrohungserkennung kann in einer Reaktion auf eine Warnung vor verdächtigen Aktivitäten bestehen oder in der proaktiven Suche nach anomalen Ereignissen in Aktivitätsprotokollen. Die Benutzer- und Entitätsverhaltensanalyse (User and Entity Behavior Analytics, UEBA) in Microsoft Sentinel erleichtert das Erkennen verdächtiger Aktivitäten. Weitere Informationen finden Sie unter Erkennen Sie fortschrittliche Bedrohungen mit UEBA in Microsoft Sentinel.

Identitätsprotokollierung

Power Apps, Power Automate, Copilot Studio, Connectors und die Data Loss Prevention-Aktivitätsprotokollierung werden im Microsoft Purview Compliance-Portal nachverfolgt und angezeigt. Erfahren Sie mehr über Microsoft Purview.

Es werden Änderungen protokolliert, die an Kundendatensätzen in einer Umgebung mit einer Dataverse-Datenbank vorgenommen werden. Die Dataverse-Überwachung protokolliert auch den Benutzerzugriff über eine App oder über das SDK in einer Umgebung. Diese Überwachung wird auf Umgebungsebene aktiviert, und für einzelne Tabellen und Spalten ist eine zusätzliche Konfiguration erforderlich.

Dienstadministratorrollen

Entra ID enthält eine Reihe vordefinierter Rollen, die Administratoren zugewiesen werden können, um ihnen die Berechtigung zum Ausführen administrativer Aufgaben zu erteilen. Eine detaillierte Aufschlüsselung der Berechtigungen jeder Rolle finden Sie in der Berechtigungsmatrix.

Verwenden Sie Microsoft Entra Privileged Identity Management (PIM) zum Verwalten von Administratorrollen mit hohen Rechten im Power Platform Admin Center.

Sichern von Dataverse-Daten

Eines der Hauptmerkmale von Dataverse ist ein umfangreiches Sicherheitsmodell, das Sie an viele Unternehmensanwendungsszenarien anpassen können. Dieses SicherheitsModell ist nur verfügbar, wenn eine Dataverse-Datenbank in der Umgebung vorhanden ist. Als Sicherheitsexperte erstellen Sie wahrscheinlich nicht das gesamte Sicherheitsmodell selbst, sind aber möglicherweise daran beteiligt, sicherzustellen, dass die Verwendung der Sicherheitsfunktionen den Datensicherheitsanforderungen der Organisation entspricht. Dataverse verwendet rollenbasierte Sicherheit,um eine Sammlung von Rechten zu gruppieren. Diese Sicherheitsrollen können direkt Benutzern oder Dataverse-Teams und -Unternehmenseinheiten zugeordnet werden. Weitere Informationen finden Sie unter Security-Konzepte in Microsoft Dataverse.

Konfigurieren der Benutzerauthentifizierung in Copilot Studio

Microsoft Copilot Studio unterstützt mehrere Authentifizierungsoptionen. Wählen Sie diejenige aus, die Ihren Anforderungen entspricht. Die Authentifizierung ermöglicht es Benutzern, sich anzumelden und Ihrem Agent Zugriff auf eine eingeschränkte Ressource oder Informationen zu gewähren. Benutzer können sich mit Microsoft Entra ID oder einem beliebigen OAuth 2.0-Identitätsanbieter wie Google oder Facebook anmelden. Weitere Informationen finden Sie unter Konfigurieren der Benutzerauthentifizierung in Copilot Studio.

Mit Direct Line-basierter Sicherheit können Sie den Zugriff auf von Ihnen kontrollierte Speicherorte einschränken, indem Sie den gesicherten Zugang mit Direct Line-Geheimnissen oder Tokens aktivieren.

Copilot Studio unterstützt einmaliges Anmelden (Single Sign-On, SSO), was bedeutet, dass Agents den Benutzer anmelden können. SSO muss auf Ihren Webseiten und mobilen Anwendungen implementiert werden. Für Microsoft Teams ist SSO nahtlos, wenn Sie die Authentifizierungsoption "Nur in Teams" auswählen. Sie kann auch manuell mit Azure AD v2 konfiguriert werden. In diesem Fall muss die Teams-App jedoch als ZIP-Datei bereitgestellt werden, nicht über die 1-Klick-Teams-Bereitstellung aus Copilot Studio.

Erfahren Sie mehr:

Sicherer Zugriff auf Daten mit Kunden-Lockbox

Für die meisten Vorgänge, den Support und die Problembehandlung, die von Microsoft-Mitarbeitern (einschließlich Unterauftragnehmern) durchgeführt werden, ist kein Zugriff auf Kundendaten erforderlich. Mit der Power Platform Kunden-Lockbox stellen wir eine Schnittstelle zur Verfügung, über die Kunden Datenzugriffsanforderungen in den seltenen Fällen, in denen ein Zugriff auf Kundendaten erforderlich ist, überprüfen und genehmigen (oder ablehnen) können. Es wird beispielsweise verwendet, wenn ein Microsoft-Techniker auf Kundendaten zugreifen muss, sei es wegen eines vom Kunden initiierten Supporttickets oder eines von Microsoft identifizierten Problems. Weitere Informationen finden Sie unter Securely access customer data using Customer Lockbox in Power Platform and Dynamics 365.

Gastbenutzer verwalten

Möglicherweise müssen Sie Gastbenutzern den Zugriff auf Umgebungen und Power Platform-Ressourcen ermöglichen. Wie interne Benutzer können Sie den bedingten Zugriff von Microsoft Entra ID und eine kontinuierliche Zugriffsauswertung verwenden, um sicherzustellen, dass Gastbenutzer eine erhöhte Sicherheitsstufe erfüllen.

Um die Sicherheit weiter zu erhöhen und das Risiko der versehentlichen Bereitstellung von zu vielen Freigaben zu verringern, können Sie bei Bedarf auch den Zugriff von Microsoft Entra-Gästen auf Ihre gesicherten Dataverse-Umgebungen blockieren oder aktivieren.

Sicherheitsprüfliste

Lesen Sie die vollständigen Empfehlungen.

Sicherheitsprüfliste

  • Last updated on