Freigeben über

Empfehlungen für die Identitäts- und Zugriffsverwaltung

  • Artikel

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

SE:05 Implementieren Sie ein striktes, bedingtes und überprüfbares Identitäts- und Zugriffsmanagement (IAM) für alle Workload-Benutzer, Teammitglieder und Systemkomponenten. Beschränken Sie den Zugriff ausschließlich auf nach Bedarf. Verwenden Sie moderne Industriestandards für alle Authentifizierungs- und Autorisierungsimplementierungen. Beschränken Sie den Zugriff, der nicht auf der Identität basiert, und prüfen Sie ihn streng.

In dieser Anleitung werden die Empfehlungen zur Authentifizierung und Autorisierung von Identitäten beschrieben, die möglicherweise versuchen, auf Ihre Workload-Ressourcen zuzugreifen.

Aus kontrolltechnischer Sicht ist Identität immer der primäre Perimeter. Dieser Umfang umfasst nicht nur die Grenzen Ihrer Workload. Er umfasst auch einzelne Komponenten, die in Ihrer Workload enthalten sind.

Typische Identitäten sind u. a.:

  • Menschen. Anwendungsbenutzer, Administratoren, Betreiber, Prüfer und schädliche Akteure.
  • Systeme. Workloadidentitäten, verwaltete Identitäten, API-Schlüssel, Dienstprinzipale und Azure-Ressourcen.
  • Anonym. Entitäten, die keinen Nachweis ihrer Identität erbracht haben.

Definitionen

Terms Definition
Authentifizierung (AuthN) Ein Prozess, der überprüft, ob eine Identität die Person ist, die 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 Ein Regelsatz, der Aktionen auf der Grundlage festgelegter Kriterien zulässt.
IdP Ein Identitätsanbieter wie Microsoft Entra ID.
Rolle Eine Stellenfunktion oder ein Titel, der eine Reihe von Verantwortlichkeiten und Aktionen mit sich bringt.
Vorab freigegebener Schlüssel Eine Art Geheimnis, das von einem Anbieter und einem Verbraucher gemeinsam genutzt und über einen sicheren und vereinbarten Mechanismus verwendet wird.
Ressourcenidentität Eine für Cloud-Ressourcen definierte Identität, die von der Plattform verwaltet wird.
Role Eine Reihe von Berechtigungen, die definieren, was ein Benutzer oder eine Gruppe tun kann.
Geltungsbereich Verschiedene Ebenen der Organisationshierarchie, auf denen eine Rolle ausgeführt werden darf. Auch eine Gruppe von Funktionen in einem System.
Sicherheitsprinzipal Eine Identität, die Berechtigungen erteilt. Es kann sich um einen Benutzer, eine Gruppe oder einen Dienstprinzipal handeln. Alle Gruppenmitglieder erhalten die gleiche Zugriffsebene.
Benutzeridentität Eine Identität für eine Person, beispielsweise einen Mitarbeiter oder einen externen Benutzer.
Workloadidentität Eine Systemidentität für eine Anwendung, einen Dienst, ein Skript, einen Container oder eine andere Komponente einer Workload, die zur Authentifizierung gegenüber anderen Diensten und Ressourcen verwendet wird.

Anmerkung

Eine Identität kann mit anderen, ähnlichen Identitäten unter einem übergeordneten Element, einem sogenannten Sicherheitsprinzipal gruppiert werden. Eine Sicherheitsgruppe ist ein Beispiel für einen Sicherheitsprinzipal. Diese hierarchische Beziehung vereinfacht die Wartung und verbessert die Konsistenz. Da Identitätsattribute nicht auf individueller Ebene behandelt werden, verringert sich auch die Fehlerwahrscheinlichkeit. In diesem Artikel umfassen Sicherheitsprinzipale den Begriff Identität.

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

Alle Power Platform-Produkte verwenden Microsoft Entra ID (zuvor 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

Authentifizierung ist ein Prozess zur Überprüfung von Identitäten. Die anfordernde Identität ist erforderlich, um eine Form der überprüfbaren Identifizierung bereitzustellen. Zum Beispiel:

  • Ein Benutzername und ein Kennwort.
  • Ein vorab freigegebenes Geheimnis, beispielsweise ein API-Schlüssel, der Zugriff gewährt.
  • Ein Token für Shared Access Signature (SAS).
  • Ein Zertifikat, das bei der gegenseitigen Authentifizierung von Transport Layer Security (TLS) verwendet wird.

Die Power Platform Authentifizierung umfasst eine Folge von Anforderungen, Antworten und Umleitungen zwischen dem Browser des Benutzers und Power Platform- oder Azure-Diensten. Die Reihenfolge folgt dem Microsoft Entra ID-Flow der Berechtigungscodegewährung.

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 die Microsoft Entra ID Microsoft Identity Platform zur Autorisierung aller API-Aufrufe mit dem branchenüblichen 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 gibt es wahrscheinlich eine eigene Reihe von Kontrollen, die Sie unter Berücksichtigung der Annahme eines Verstoßes entwickeln müssen. Identifizieren Sie die bedingten Auswahlmöglichkeiten basierend auf den Identitätsanforderungen des Anwendungsfalls oder der Personas. Vermeiden Sie die Verwendung einer Lösung für alle Anwendungsfälle. Umgekehrt sollten die Kontrollen nicht so detailliert sein, dass sie unnötigen Verwaltungsaufwand verursachen.

Sie müssen den Identitätszugriffspfad protokollieren. Auf diese Weise können Sie die Kontrollen leichter überprüfen und die Protokolle für Compliance-Audits verwenden.

Alle Identitäten zur Authentifizierung ermitteln

Zugriff von außen. Die Power Platform Authentifizierung umfasst eine Folge von Anforderungen, Antworten und Umleitungen zwischen dem Browser des Benutzers und Power Platform- oder Azure-Diensten. Die Reihenfolge folgt dem Microsoft Entra ID-Flow der Berechtigungscodegewährung. Power Platform authentifiziert automatisch alle Benutzer, die aus verschiedenen Gründen auf die Arbeitslast zugreifen.

Zugriff von innen. Ihre Workload muss auf andere Ressourcen zugreifen. Beispiele hierfür sind das Lesen von oder Schreiben auf der Datenplattform, das Abrufen von Geheimnissen aus dem Geheimnisspeicher und das Protokollieren von Telemetriedaten bei Überwachungsdiensten. Möglicherweise ist sogar der Zugriff auf Dienste von Drittanbietern erforderlich. Dies sind alles Anforderungen an Workloadidentitäten. Sie müssen jedoch auch die Anforderungen an die Ressourcenidentität berücksichtigen, beispielsweise wie Bereitstellungspipelines ausgeführt und authentifiziert werden.

Aktionen für die Autorisierung festlegen

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 nach der Art des erforderlichen Zugriffs unterteilt werden:

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

  • Zugriff auf Steuerungsebene. 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 typischerweise auf Operationen auf Datenebene ab, während Operationen oft sowohl auf Steuer- als auch auf Datenebene zugreifen.

Rollenbasierte Autorisierung bereitstellen

Autorisieren Sie basierend auf der Verantwortung jeder Identität Aktionen, die zulässig sein sollen. Einer Identität darf nicht mehr erlaubt werden, als nötig. Bevor Sie Autorisierungsregeln festlegen, müssen Sie sich darüber im Klaren sein, wer oder was Anforderungen stellt, was diese Rolle tun darf und in welchem Umfang. Diese Faktoren führen zu Entscheidungen, die Identität, Rolle und Umfang kombinieren.

Beachten Sie 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?
  • Gibt es für intelligente Anwendungs-Workloads wie z. B. Agenten, Anforderungen für einmaliges Anmelden (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, die der Identität ausschließlich das Abschließen von Aufgaben erlauben. Wenn die Berechtigungen eines Benutzers auf seine beruflichen Anforderungen beschränkt sind, lässt sich verdächtiges oder nicht autorisiertes Verhalten im System leichter erkennen.

Stellen Sie Fragen wie die folgenden:

  • Reicht ein Nur-Lese-Zugriff aus?
  • 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 Geschäftseinheit, 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, verringert sich das Risiko eines erfolgreichen Angriffs oder eines unbefugten Zugriffs erheblich. 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.

Nachteil: Ein granularer Zugangssteuerungs-Ansatz macht eine bessere Überprüfung und Überwachung der Benutzeraktivitäten möglich.

Weisen Sie Rollen zu, die mit den geringsten Berechtigungen beginnen, und fügen Sie basierend auf Ihren Betriebs- oder Datenzugriffsanforderungen weitere hinzu. Ihre technischen Teams müssen über klare Richtlinien zur Implementierung von Berechtigungen verfügen.

Auswahl für bedingten Zugriff treffen

Weisen Sie nicht allen Identitäten dieselbe Zugriffsebene zu. Treffen Sie Ihre Entscheidungen auf der Grundlage von zwei Hauptfaktoren:

  • Uhrzeit. Wie lange die Identität auf Ihre Umgebung zugreifen kann
  • Berechtigung Die Berechtigungsebene

Diese Faktoren schließen sich nicht gegenseitig aus. Eine kompromittierte Identität mit mehr Berechtigungen und zeitlich unbegrenztem Zugriff kann eine größere Kontrolle über das System und die Daten erlangen oder diesen Zugriff nutzen, um die Umgebung weiter zu verändern. Beschränken Sie diese Zugangsfaktoren sowohl als vorbeugende Maßnahme als auch zur Kontrolle des Explosionsradius.

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

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

Obwohl Zeit und Privilegien die Hauptfaktoren sind, gelten auch andere Bedingungen. Sie können zum Festlegen von Richtlinien beispielsweise auch das Gerät, das Netzwerk und den Standort verwenden, von dem der Zugriff erfolgt ist.

Verwenden Sie starke Kontrollen, die unbefugten Zugriff filtern, erkennen und blockieren, einschließlich Parameter wie Benutzeridentität und -standort, Gerätezustand, Workloadkontext, Datenklassifizierung und Anomalien.

Beispielsweise muss auf Ihre Workload möglicherweise von Drittidentitäten wie Lieferanten, Partnern und Kunden zugegriffen werden. Sie benötigen die entsprechende Zugriffsebene und nicht die Standardberechtigungen, die Sie Vollzeitmitarbeitern erteilen. Durch eine klare Unterscheidung externer Konten können Angriffe, die über diese Vektoren erfolgen, leichter verhindert und erkannt werden.

Konten mit kritischen Auswirkungen

Administrative Identitäten stellen einige der größten Sicherheitsrisiken dar, da die von ihnen ausgeführten Aufgaben privilegierten Zugriff auf eine breite Palette dieser Systeme und Anwendungen erfordern. Kompromittierungen oder Missbrauch können sich nachteilig auf Ihr Unternehmen und seine Informationssysteme auswirken. Die Verwaltungssicherheit ist einer der kritischsten Sicherheitsbereiche.

Um privilegierte Zugriffe vor entschlossenen Angreifern zu schützen, müssen Sie einen umfassenden und durchdachten Ansatz verfolgen, um diese Systeme vor Risiken zu isolieren. Hier finden Sie einige Strategien:

  • Minimieren Sie die Anzahl der Konten mit kritischen Auswirkungen.

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

  • Vermeiden Sie dauerhaften oder ständigen Zugriff, indem Sie die JIT-Funktionen Ihres IdP nutzen. Befolgen Sie bei Situationen mit Notfallzugängen das Notfallzugangsverfahren.

  • Verwenden Sie moderne Zugriffsprotokolle, z. B. kennwortlose Authentifizierung oder Multifaktor-Authentifizierung. Übertragen Sie diese Mechanismen auf Ihren IdP.

  • Erzwingen Sie wichtige Sicherheitsattribute durch die Verwendung von Richtlinien für bedingten Zugriff.

  • Deaktivieren Sie Administratorkonten, die nicht verwendet werden.

Prozesse zur Verwaltung des Identitätslebenszyklus einrichten

Der Zugriff auf Identitäten darf nicht länger bestehen 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 sich die Teamstruktur oder die Softwarekomponenten ändern.

Diese Anleitung gilt für Quellcodeverwaltung, Daten, Steuerungsebenen, Workloadbenutzer, Infrastruktur, Werkzeuge, die Überwachung von Daten, Protokollen, Metriken und anderen Entitäten.

Richten Sie einen Identitätsverwaltungsprozess ein, um den Lebenszyklus digitaler Identitäten, hochprivilegierter Benutzer, externer/Gastbenutzer und Workloadbenutzer zu verwalten. Implementieren Sie Zugriffsüberprüfungen, um sicherzustellen, dass Identitäten, die die Organisation oder das Team verlassen, ihre Workloadberechtigungen entzogen werden.

Nicht-identitätsbasierte Geheimnisse schützen

Anwendungsgeheimnisse wie vorab freigegebene Schlüssel sollten als Schwachstellen im System betrachtet werden. Bei der wechselseitigen Kommunikation können erhebliche Sicherheitsrisiken entstehen, wenn die Identität des Anbieters oder Verbrauchers kompromittiert wird. Diese Schlüssel können auch eine Belastung darstellen, da sie Betriebsprozesse einführen.

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

Stellen Sie sicher, dass Sie die Möglichkeit haben, Geheimnisse zu widerrufen.

Wenden Sie Betriebspraktiken an, die Aufgaben wie Schlüsselrotation und -ablauf behandeln.

Informationen zu Rotationsrichtlinien finden Sie unter Die Rotation eines Geheimnisses für Ressourcen automatisieren, die über zwei Sätze von Authentifizierungsinformationen verfügen und unter Tutorial: Aktualisieren der Häufigkeit der automatischen Zertifikatrotation in Key Vault.

Sicherheit für Entwicklungsumgebungen

Der Schreibzugriff auf Entwicklerumgebungen 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.

Überwachungspfad verwalten

Ein Aspekt des Identitätsmanagements besteht darin, sicherzustellen, dass das System überprüfbar ist. Durch Überwachungen wird überprüft, ob Strategien zur Vermeidung von Datendiebstählen wirksam sind. Die Verwaltung eines Überwachungspfads hilft Ihnen bei Folgendem:

  • Überprüfen Sie, ob die Identität mit einer starken Authentifizierung authentifiziert wurde. Jede Aktion muss nachvollziehbar sein, um Zurückweisungsangriffe zu verhindern.

  • Erkennen Sie schwache oder fehlende Authentifizierungsprotokolle und erhalten Sie Einblick in und Erkenntnisse zu Benutzer- und Anwendungsanmeldungen.

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

  • Verfolgen Sie den Fortschritt oder die Abweichung von den Compliance-Anforderungen.

Die meisten Ressourcen haben Zugriff auf Datenebene. Sie müssen wissen, welche Identitäten auf Ressourcen zugreifen und welche Aktionen sie durchführen. Sie können diese Informationen zur Sicherheitsdiagnose verwenden.

Power Platform: schnellere Durchführung

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 (zuvor 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.

Diagramm eines Cloud Computing-Systems.

Lizenzzuwesiung

Zugriff auf Power Apps und Power Automate beginnt mit einer 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.

Richtlinien für bedingten Zugriff

Bedingter 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 bedingten Zugriff in Microsoft Entra, indem Sie eine Zugriffsrichtlinie einrichten, die auf Ihren betrieblichen Anforderungen basiert.

Weitere Informationen finden Sie unter

Fortlaufender Zugriff

Der fortlaufende Zugriff wird beschleunigt, wenn bestimmte Ereignisse ausgewertet werden, um zu bestimmen, ob der Zugriff widerrufen werden soll. Traditionell tritt bei OAuth der 2.0-Authentifizierung der Ablauf des Zugriffstokens ein, wenn während der Tokenerneuerung eine Überprüfung durchgeführt wird. 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.

Bei 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 Fortlaufende Zugriffsevaluierung

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. Die Verwendung von Entra ID durch Power Platform 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 Berechtigungen an bestimmte Benutzer zu vergeben, weisen Sie Gruppen den Zugriff in Microsoft Entra ID zu. Wenn keine Gruppe vorhanden ist, arbeiten Sie mit Ihrem Identitätsteam zusammen, um eine zu erstellen. Sie können dann Gruppenmitglieder außerhalb von Azure hinzufügen und entfernen und sicherstellen, dass die Berechtigungen aktuell sind. Sie können die Gruppe auch für andere Zwecke wie Mailinglisten verwenden.

Weitere Informationen finden Sie unter Sichere Zugriffssteuerung durch Gruppen in Microsoft Entra ID.

Bedrohungserkennung

Microsoft Entra ID-Schutz kann Ihnen dabei helfen, identitätsbasierte Risiken zu erkennen, zu untersuchen und zu beheben. Weitere Informationen finden Sie unter Was ist Identitätsschutz?.

Die Bedrohungserkennung kann in Form einer Reaktion auf eine Warnung vor verdächtigen Aktivitäten oder einer proaktiven Suche nach anomalen Ereignissen in Aktivitätsprotokollen erfolgen. Mithilfe der User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel können Sie verdächtige Aktivitäten ganz einfach erkennen. Weitere Informationen finden Sie unter Erweiterte Bedrohungen mit UEBA in Microsoft Sentinel erkennen.

Identitätsprotokollierung

Power Apps, Power Automate, Copilot Studio, Konnektoren und die Aktivitätsprotokollierung zur Verhinderung von Datenverlust werden über das Microsoft Purview-Compliance-Portal verfolgt und angezeigt. Weitere Informationen dazu, finden Sie unter Weitere Informationen über Microsoft Purview.

Es werden Änderungen protokolliert, die an Kundendatensätzen in einer Umgebungs 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), um hochprivilegierte Administratorrollen im Power Platform Admin Center zu verwalten.

Sichern von Dataverse-Daten

Eines der Hauptmerkmale von Dataverse ist das umfassende Sicherheitsmodell, das an viele verschiedene Geschäftsszenarien angepasst werden kann. 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. Zur Bündelung von Berechtigungen in einer Sammlung basiert die Sicherheit in Dataverse auf Rollen. Diese Sicherheitsrollen können direkt den Benutzern zugeordnet sein, oder sie können Dataverse-Teams und -Unternehmenseinheiten zugeordnet werden. Weitere Informationen finden Sie unter Sicherheitskonzepte 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 einer Microsoft Entra ID oder mit 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 Standorte einschränken, die Sie steuern, indem Sie den gesicherten Zugriff mit Direct Line-Geheimnissen oder -Token aktivieren.

Copilot Studio unterstützt Single Sign-On (SSO), was bedeutet, dass Agenten den Benutzer anmelden können. SSO muss auf Ihren Webseiten und mobilen Anwendungen implementiert werden. Denn Microsoft Teams SSO ist 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 Sicherer Zugriff auf Kundendaten mit Customer Lockbox in Power Platform and Dynamics 365.

Sicherheitscheckliste

Lesen Sie die vollständigen Empfehlungen.

Sicherheitscheckliste