Freigeben über

Autorisieren von Anwendungen, Ressourcen und Workloads mit Microsoft Entra ID

  • Artikel

In diesem Artikel besprechen wir die Autorisierung, wenn ein Benutzer mit einer Anwendung interagiert und sie steuert und wenn Application Programming Interfaces (APIs) für einen Benutzer agieren. Wir decken auch Szenarien ab, in denen Anwendungen oder Dienste unabhängig arbeiten. Dies ist der vierte Artikel in einer Reihe dazu, wie unabhängige Softwareentwickler (ISVs) ihre Anwendungen für Microsoft Entra ID erstellen und optimieren können. In dieser Reihe finden Sie weitere Informationen zu diesen Themen:

Autorisierung in Anwendungen

In diesem Abschnitt behandeln wir Szenarien, in denen ein Benutzer mit einer Anwendung interagiert und sie steuert. Im Abschnitt Autorisierung in Ressourcen (APIs) wird beschrieben, wie APIs die Autorisierung ausführen, wenn der Benutzer eine Autorisierung für den Zugriff auf eine Ressource benötigt, Microsoft Entra ID jedoch nicht die endgültige Autorisierung ausführt. Der Abschnitt Autorisierung in Workloads behandelt Szenarien, in denen Anwendungen oder Dienste unabhängig arbeiten.

Anwendungen benötigen die folgenden Autorisierungen, wenn sie auf Ressourcen für einen Benutzer zugreifen müssen.

  • Die Anwendung muss über eine Autorisierung verfügen, um auf bestimmte Vorgänge innerhalb bestimmter Ressourcen für den aktuellen Benutzer zuzugreifen.
  • Der Benutzer muss über eine Autorisierung verfügen, um unter den aktuellen Bedingungen auf eine Ressource zuzugreifen.
  • Der Benutzer muss über eine Autorisierung verfügen, um auf eine Ressource zuzugreifen.

Der Autorisierungsprozess beginnt mit einer Anwendung, die mit OAuth 2.0 ein Zugriffstoken von Microsoft Entra ID anfordert, um auf bestimmte Vorgänge innerhalb einer bestimmten Ressource für den Benutzer zuzugreifen. Beim delegierten Zugriff fungiert eine App als Stellvertretung für den Benutzer.

Für Entwickler kann eine Ressource eine API wie Microsoft Graph, Azure Storage oder eine eigene API sein. Die meisten APIs verfügen jedoch über verschiedene Vorgänge wie Lesen und Schreiben. Wenn eine Anwendung nur aus einer API liest, sollte die App nur über die Autorisierung für Lesevorgänge verfügen. Dieser Ansatz schützt eine Anwendung vor Kompromittierung und davor, dass sie für mehr Zugriff als vom Entwickler beabsichtigt verwendet wird. Der Entwickler folgt dem Prinzip der geringsten Berechtigung, wenn seine Anwendung nur für die erforderlichen Vorgänge autorisiert ist.

Um festzulegen, welche spezifischen Vorgänge in einer bestimmten API eine Anwendung erfordert, verwenden Entwickler den Bereichsparameter einer OAuth 2.0-Anforderung. Der API-Designer veröffentlicht die Bereiche, die eine Anwendung anfordern kann, als Teil der App-Registrierung. Beispielsweise umfassen Microsoft Power BI-Dienstbereiche Folgendes.

Power BI-Dienstbereich Vorgänge
https://analysis.windows.net/powerbi/api/Capacity.Read.All Die App kann alle Power BI Premium- und Power BI Embedded-Kapazitäten anzeigen, auf die der angemeldete Benutzer Zugriff hat.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All Die App kann alle Power BI Premium- und Power BI Embedded-Kapazitäten anzeigen und bearbeiten, auf die der angemeldete Benutzer Zugriff hat.

Wenn eine Anwendung Kapazitäten nur liest, fordert die App den https://analysis.windows.net/powerbi/api/Capacity.Read.All-Bereich an. Wenn eine Anwendung Kapazitäten bearbeitet, fordert die App den https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All-Bereich an.

Der Bereich enthält die Identität der API und die Identität des Vorgangs. Im https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All-Bereich ist die API https://analysis.windows.net/powerbi/api. Der Vorgang ist Capacity.ReadWrite.All. Aufgrund der hohen Reichweite und Beliebtheit der Microsoft Graph-API können Entwickler Bereiche für Microsoft Graph ohne die API-Komponente des Bereichs anfordern. Beispielsweise definiert Microsoft Graph einen Bereich von https://graph.microsoft.com/Files.Read, den Anwendungen mit Files.Read anfordern können, anstatt den vollständigen Bereichsnamen zu verwenden.

Um die erste Autorisierung abzuschließen, muss eine Anwendung über eine Autorisierung verfügen, um auf bestimmte Vorgänge innerhalb bestimmter Ressourcen für den aktuellen Benutzer zuzugreifen. Microsoft Entra ID muss zuerst den aktuellen Benutzer authentifizieren. Einmaliges Anmelden (Single Sign-On, SSO) kann diese Authentifizierungsanforderung erfüllen, oder es kann möglicherweise eine neue Benutzerinteraktion erforderlich sein.

Nachdem Microsoft Entra ID den Benutzer ermittelt hat, überprüft der Dienst, ob der Benutzer die Anwendung für den angeforderten Bereich autorisiert hat. Dieser Vorgang wird als Erteilen der Einwilligung bezeichnet. Wenn der Benutzer seine Einwilligung erteilt hat, kann der Autorisierungsprozess fortgesetzt werden. Die Administratoreinwilligung ermöglicht es Administratoren, die Einwilligung für sich selbst und für die gesamte Organisation zu erteilen. Microsoft Entra ID überprüft, ob die Anwendung über die Administratoreinwilligung für einen Bereich verfügt. Wenn dies der Fall ist, wird der Autorisierungsprozess fortgesetzt.

Während des Bereichsdesigns kann ein API-Designer Bereiche festlegen, für die nur ein Administrator die Einwilligung erteilen kann. Bereiche, für die eine Administratoreinwilligung erforderlich ist, stellen Vorgänge dar, die der API-Designer für so sensibel, leistungsstark oder wichtig hält, dass Benutzer ohne Administratorberechtigung nicht autorisiert sein sollten, die Einwilligung für die Anwendung zu erteilen.

API-Designer können zwar festlegen, für welche ihrer Bereiche eine Administratoreinwilligung erforderlich ist, aber sie haben nicht das letzte Wort. Wenn ein API-Designer angibt, dass ein Bereich eine Administratoreinwilligung erfordert, ist für den Bereich immer die Administratoreinwilligung erforderlich. Für Bereiche, für die der API-Designer keine Administratoreinwilligung erfordert, kann der Mandantenadministrator die Administratoreinwilligung anfordern, oder die risikobasierten Step-up-Einwilligung bestimmt möglicherweise die Anforderung der Administratoreinwilligung. Entwickler können nicht vorhersagen, ob eine Tokenanforderung eine Administratoreinwilligung erfordert. Diese Einschränkung wirkt sich jedoch nicht auf den benötigten Code aus. Eine Verweigerung der Einwilligung ist nur einer von vielen Gründen für die Ablehnung der Tokenanforderung. Anwendungen müssen immer ordnungsgemäß behandeln, dass kein Token empfangen wird.

Wenn der Benutzer oder der Administrator keine Einwilligung erteilt hat, sieht der Benutzer eine Einwilligungsaufforderung wie im folgenden Beispiel gezeigt.

Screenshot der Benutzereinwilligungsaufforderung.

Aufforderungen zur Einwilligung durch Administratorbenutzer können die Auswahl von Zustimmung im Namen Ihrer Organisation zulassen, um die Einwilligung für alle Benutzer im Mandanten zu erteilen, wie im folgenden Beispiel gezeigt.

Screenshot der Administratoreinwilligungsaufforderung.

Anwendungen steuern das Timing von Aufforderungen zur Benutzereinwilligung. Microsoft Entra ID unterstützt die statische Einwilligung: Wenn eine Anwendung den .default-Bereich verwendet, fordert die App alle Berechtigungen an, die in der Registrierung der App deklariert sind. Mit der statischen Einwilligung fordert Ihre App im Voraus alle Berechtigungen an, die sie möglicherweise jemals benötigt.

Dies kann Benutzer und Administratoren davon abhalten, die Zugriffsanforderung Ihrer App zu genehmigen. Die bewährte Methode für den Einwilligungsanforderungsprozess besteht darin, die erforderliche Berechtigungen für die Basisfunktionalität in Ihrer Anwendung beim Start der Anwendung dynamisch anzufordern und bei Bedarf weitere Bereiche anzufordern. Fordern Sie inkrementell mehr Bereiche an, wenn die Anwendung Vorgänge ausführt, die diese Bereiche benötigen. Dieser Ansatz bietet dem Benutzer ein besseres Verständnis weiterer Berechtigungen, die mit dem Timing der Funktionalität korrelieren. Für jedes API-Zugriffstoken schließt Microsoft Entra ID alle Bereiche ein, die zuvor einer Anwendung gewährt wurden, und nicht nur die Bereiche in der Anforderung.

Eine Anwendung kann z. B. https://graph.microsoft.com/user.read anfordern, um den Benutzer anzumelden und auf das Profil des Benutzers zuzugreifen, wenn die Anwendung gestartet wird. Später wählt ein Benutzer In OneDrive speichern aus, und die Anwendung fordert https://graph.microsoft.com/files.readwrite an, um eine Datei in das OneDrive des Benutzers zu schreiben. Da der Benutzer sieht, warum eine App die Schreibberechtigung für OneDrive anfordert, erteilt der Benutzer die Berechtigung, und die App speichert eine Datei im OneDrive des Benutzers. Der Benutzer schließt dann die App. Wenn die App das nächste Mal gestartet wird, fordert sie https://graph.microsoft.com/user.read an. Microsoft Entra ID gibt ein Zugriffstoken mit den Bereichen https://graph.microsoft.com/user.read und https://graph.microsoft.com/files.readwrite zurück. Eine Tokenanforderung für den https://graph.microsoft.com/files.readwrite-Bereich erfordert keine Einwilligung, da der Benutzer sie erteilt hat. Das Zwischenspeichern von Token in Microsoft-Authentifizierungsbibliotheken (MSAL) verarbeitet automatisch das Zwischenspeichern von Token basierend auf den erteilten Berechtigungen. Nach dem Neustart der App geben Aufrufe an MSAL zum Erhalt eines Tokens mit dem https://graph.microsoft.com/files.readwrite-Bereich in diesem Beispiel das aus der anfänglichen Anforderung der App für den https://graph.microsoft.com/user.read-Bereich zwischengespeicherte Token zurück. Ein weiterer Aufruf von Microsoft Entra ID ist nicht erforderlich.

Dynamische und inkrementelle Einwilligung erfordern keine deklarierten Berechtigungen während der Anwendungsregistrierung. Es wird jedoch dringend empfohlen, dass Anwendungen alle Berechtigungen, die benötigt werden könnten, in einer App-Registrierung deklarieren, um die statische Einwilligung zu unterstützen. Administratoren können die Administratoreinwilligung im Microsoft Entra Admin Center erteilen, indem sie Microsoft Graph PowerShell oder die Microsoft Graph-API verwenden.

Zum Erteilen der Administratoreinwilligung für eine Anwendung verwendet das Microsoft Entra Admin Center die statische Einwilligung, indem die Einwilligung mit dem .default-Bereich für eine App angefordert wird. Administratoren können im Microsoft Entra Admin Center keine Administratoreinwilligung für Apps erteilen, die eine Berechtigung erfordern, wenn Entwickler sie nicht in der App-Registrierung deklarieren.

Microsoft Entra ID-Kunden können Richtlinien für bedingten Zugriff verwenden, um Ressourcen (APIs) und browserbasierte Anwendungen zu schützen. Administratoren können standardmäßig keine Richtlinien für bedingten Zugriff auf native App-Authentifizierungen anwenden. Mandantenadministratorteams können als Ziel Alle Ressourcen (ehemals „Alle Cloud-Apps“) abzielen oder Benutzerdefinierte Sicherheitsattribute verwenden, um auf native Apps mit Richtlinien für bedingten Zugriff abzuzielen. Auch wenn anders abgezielt wird, schließt die Richtlinienerzwingung enthält einige Apps nicht ein, die auf Microsoft Graph oder Azure AD Graph zugreifen.

Anwendungen erfordern in der Regel keinen speziellen Code für bedingten Zugriff, außer in den folgenden Szenarien.

  • Apps für den „Im Auftrag von“-Ablauf
  • Apps, die auf mehrere Dienste oder Ressourcen zugreifen
  • Single-Page-Apps, die MSAL.js verwenden
  • Web-Apps, die eine Ressource aufrufen

Wenn Ihre App eines dieser Szenarien implementiert, lesen Sie den Entwicklerleitfaden für den bedingten Zugriff in Microsoft Entra.

Kostenlose Microsoft Entra ID-Mandanten können bedingten Zugriff nicht nutzen (siehe Lizenzierungsanforderungen. Möglicherweise verfügt der Produktionsmandant Ihres Unternehmens über die erforderliche Lizenzierung. Werten Sie diese Bedingungen aus, bevor Sie Ihren Produktionsmandanten zum Testen verwenden. Es gibt Anleitungen zum Erstellen eines Testmandanten.

Standardmäßig gelten Richtlinien für bedingten Zugriff für Anwendungen und die Ressourcen, auf die eine App auf App-Ebene zugreift. IT-Administratoren können Richtlinien auf App-Ebene auf jede App anwenden, ohne dass Entwickler beteiligt werden müssen. Einige Anwendungen und Szenarien erfordern eine höhere Granularität. Beispielsweise kann eine Finanz-App eine Multi-Faktor-Authentifizierung für die typische Verwendung erfordern. Eine Transaktion über einem bestimmten Betrag kann jedoch ein verwaltetes Gerät erfordern. Entwickler können IT-Administratoren das Zuweisen von Step-up-Richtlinien für bedingten Zugriff zu verschiedenen Bereichen einer Anwendung ermöglichen, indem sie den Authentifizierungskontext für bedingten Zugriff implementieren. Der Entwicklerleitfaden für den Authentifizierungskontext für bedingten Zugriff ist eine hilfreiche Referenz für diese Features.

Standardmäßig gibt Microsoft Entra ID Zugriffstoken aus, die für eine festgelegte Zeit gültig sind. Anwendungen dürfen die Länge der Lebensdauer niemals annehmen. Sie müssen den expires_in-Parameter verwenden, den Microsoft Entra ID mit dem Zugriffstoken zurückgibt. MSAL behandelt dieses Szenario automatisch. Für die Lebensdauer des Zugriffstokens verfügt der Benutzer über die Autorisierung für den Zugriff auf die Ressource unter den Bedingungen zum Zeitpunkt der Autorisierung.

Die Verzögerung zwischen dem Ändern der Bedingungen und dem Erzwingen von Richtlinienänderungen kann Auswirkungen für Administratoren und Benutzer haben. Wenn ein Benutzer beispielsweise ein Gerät verliert, kann der IT-Administrator die Sitzungen des Benutzers widerrufen. Eine App auf dem verlorenen Gerät kann jedoch weiterhin für den Benutzer auf Microsoft Graph zugreifen, bis das Token abläuft. Die fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE) von Microsoft kann den Zugriff nach der Sperrung von Benutzersitzungen für Anwendungen verhindern, die CAE verwenden. Wenn Ihre Anwendung Microsoft Graph mindestens einmal pro Stunde aufruft, können Sie CAE verwenden. Informationen zur Implementierung finden Sie unter Verwenden von APIs mit aktivierter fortlaufender Zugriffsevaluierung in Ihren Anwendungen.

Wenn Sie nicht auf MSAL aufbauen können, muss Ihre App OAuth 2.0 verwenden, um Zugriffstoken von Microsoft Entra ID anzufordern. Unter Microsoft Identity Platform und der OAuth 2.0-Autorisierungscodeflow finden Sie Implementierungsdetails für die von Microsoft Entra ID unterstützten Flows.

Wenn Sie Apps für mobile Geräte erstellen, finden Sie weitere Informationen im Artikel zum Unterstützen von SSO und App-Schutzrichtlinien in mobilen Apps. Erfahren Sie, wie Sie die Tokenbeschaffung, Verwaltung mobiler Anwendungen in Intune (Mobile Application Management, MAM) und App-Schutzrichtlinien unterstützen.

Autorisierung in Ressourcen (APIs)

Im Abschnitt Autorisierung in Anwendungen wurden drei erforderliche Autorisierungen eingeführt, wenn Anwendungen auf Ressourcen für einen Benutzer zugreifen müssen, es wurden aber nur die ersten beiden behandelt. Der Benutzer muss über die Autorisierung für den Zugriff auf eine Ressource verfügen, aber Microsoft Entra ID führt nicht die endgültige Autorisierung aus. Die Ressource (API) führt die Autorisierung aus.

APIs müssen beim Handeln für einen Benutzer zwei Autorisierungen erzwingen:

  • APIs müssen eine App zum Aufrufen der API autorisieren. Überprüfen Sie, ob der scp-Anspruch (Bereich) des Zugriffstokens den erforderlichen Bereich enthält.
  • APIs müssen den Benutzer für den Zugriff auf die spezifische Ressource autorisieren. Die Ansprüche oid (Objekt-ID) und sub (Betreff) im Token stellen die Benutzeridentität dar.

Wir empfehlen die Ansprüche oid und sub für die Autorisierung.

Microsoft Entra ID implementiert einen paarweise sub-Anspruch, daher ist der sub-Anspruch ein eindeutiger Benutzerbezeichner für die anfordernde App. Derselbe Benutzer, der eine andere App verwendet, hat einen anderen sub-Anspruch. Der oid-Anspruch ist für den Benutzer für alle Apps konstant.

Anwendungen stellen das erforderliche Zugriffstoken für APIs, die von Microsoft Entra ID geschützt werden, im Autorisierungsheader der http-Anforderung als Bearertoken bereit. APIs müssen das empfangene Token vollständig überprüfen, da das Token nicht direkt von Microsoft Entra ID stammt. Betrachten Sie die aufrufende App bis zur Tokenüberprüfung als nicht vertrauenswürdig. Die Referenzartikel zu Zugriffstoken und Anspruchsüberprüfung enthalten Details zur Überprüfung von Zugriffstoken von Microsoft Entra ID.

Microsoft Entra ID veröffentlicht die öffentlichen Schlüssel, die APIs verwenden, um die Signatur des Tokens zu überprüfen. Diese Schlüssel werden in regelmäßigen Abständen ausgetauscht, und bei Bedarf erfolgt ein Rollover für öffentliche Schlüssel. Ihre Anwendung darf niemals einen festgelegten Zeitplan für den Rollover von öffentlichen Schlüsseln annehmen. Unter Rollover von Signaturschlüsseln in Microsoft Identity Platform wird erläutert, wie das Rollover für öffentliche Schlüssel ordnungsgemäß behandelt wird.

Es wird empfohlen, eine gut gepflegte Bibliothek zum Durchführen der Tokenüberprüfung zu verwenden. Wenn Sie eine Web-App oder API in ASP.NET oder ASP.NET Core erstellen, verwenden Sie Microsoft.Identity.Web zum Behandeln der Tokenüberprüfung. In der Anleitung zur geschützten Web-API wird erläutert, wie sie Microsoft.Identity.Web zum Schutz einer API verwenden.

APIs müssen manchmal andere APIs aufrufen. Wenn eine App für den Benutzer agiert, empfängt die API ein delegiertes Zugriffstoken, das die Identität des aktuellen Benutzers enthält. Es ist wichtig, dass die API nur einem validierten Token von Microsoft Entra ID vertraut, um die Identität des aktuellen Benutzers zu ermitteln. Dieser Ansatz verhindert Anwendungskompromittierungen, z. B. dass Benutzer die Identität wechseln und auf Ressourcen für einen anderen Benutzer zugreifen. Um denselben Schutz zu erreichen, wenn eine API eine andere API aufruft, verwenden Sie den Im Auftrag von-OAuth-Fluss, um ein Zugriffstoken abzurufen und eine API für den Benutzer aufzurufen, für den die API aufgerufen wurde. Erstellen einer Web-API, die Web-APIs aufruft beschreibt die Schritte, mit denen eine API andere APIs für den aktuellen App-Benutzer aufrufen kann.

Zusätzlich zum delegierten Zugriff müssen APIs möglicherweise Anwendungen unterstützen und unabhängig ohne aktuelle Benutzer agieren. Microsoft Entra ID verweist auf diese Anwendungen als Workloads. Um die Workloadautorisierung zu erzwingen, verwenden APIs nicht den Anspruch scp (Bereich). Stattdessen verwenden APIs den roles-Anspruch, um zu überprüfen, ob die Workload über die erforderliche Einwilligung verfügt. APIs sind dafür verantwortlich zu erzwingen, dass die Workload über die Autorisierung für den Zugriff auf die Ressource verfügt.

Autorisierung in Workloads

Workloads sind Anwendungen, die unabhängig funktionieren und keinen aktuellen Benutzer haben. Wie der delegierte Zugriff, der im Abschnitt Autorisierung in Anwendungen erläutert wird, erfordert der Nur-App-Zugriff mehrere Autorisierungen:

  • Die Anwendung muss über eine Autorisierung verfügen, um auf bestimmte Vorgänge innerhalb bestimmter Ressourcen zuzugreifen.
  • Die Anwendung muss über eine Autorisierung verfügen, um unter den aktuellen Bedingungen auf die Ressource zuzugreifen.
  • Die Anwendung muss über die Autorisierung für den Zugriff auf die Ressource verfügen.

Der Prozess beginnt mit einer Workload, die ein Zugriffstoken mit dem .default-Bereich anfordert (z. B. https://graph.microsoft.com/.default). Im Gegensatz zum delegierten Zugriff (Anwendungen können Bereiche dynamisch und inkrementell anfordern) müssen Workloads immer die statische Einwilligung und den .default-Bereich verwenden.

API-Designer erstellen App-Berechtigungen für ihre API, indem sie der App Registrierung der API Rollen hinzufügen. Diese Rollen verfügen über einen zulässigen Mitgliedstyp von Anwendungen, der die Rollenzuweisung zu Workloads ermöglicht. Weisen Sie Workloads Rollen zu, indem Sie das Microsoft Entra Admin Center oder Microsoft Graph verwenden. Im Microsoft Entra Admin Center ist die Administratoreinwilligung für die zugewiesenen Rollen erforderlich, damit die Workload ausgeführt werden kann.

Standardmäßig autorisiert eine App-Berechtigung die Workloads für den Zugriff auf alle Instanzen einer Ressource. Beispielsweise autorisiert https://graph.microsoft.com/user.read.all eine Workload für den Zugriff auf das vollständige Benutzerprofil jedes Benutzers im Mandanten. IT-Administratoren zögern häufig, diese allgemeinen Berechtigungen zu erteilen.

Verwenden Sie für Workloads, die auf Microsoft Graph zugreifen, die folgenden Methoden, um die Anwendungsberechtigung einzuschränken:

Im Gegensatz zu Anwendungen mit Benutzern authentifizieren sich Workloads selbst bei Microsoft Entra ID.

Bei Workloads, die in Microsoft Azure ausgeführt werden, sind die beste Methode, damit sich eine Workload selbst authentifizieren kann, verwaltete Identitäten für Azure-Ressourcen. Das Feature für verwaltete Identitäten eliminiert die Notwendigkeit, Anmeldeinformationen für die Workload zu verwalten. Es sind keine Anmeldeinformationen vorhanden, auf die zugegriffen werden kann. Microsoft Entra ID verwaltet die Anmeldeinformationen vollständig. Ohne zu verwaltende Anmeldeinformationen sind keine Anmeldeinformationen gefährdet.

Durch die erhöhte Sicherheit erhöhen verwaltete Identitäten auch die Resilienz. Verwaltete Identitäten verwenden langlebige Zugriffstoken und Informationen aus Microsoft Entra ID, um neue Token abzurufen, bevor Token ablaufen. Verwaltete Identitäten verwenden regionale Endpunkte, mit denen Out-of-Region-Fehler verhindert werden, indem Dienstabhängigkeiten konsolidiert werden. Regionale Endpunkte tragen dazu bei, den Datenverkehr in einem geografischen Gebiet zu halten. Wenn sich Ihre Azure-Ressource beispielsweise in WestUS2 befindet, bleibt der Datenverkehr auch in WestUS2.

Wenn die Workload nicht in Microsoft Azure ausgeführt wird, muss sie sich mit dem OAuth 2.0-Flow für Clientanmeldeinformationen authentifizieren.

Microsoft Entra ID unterstützt diese Typen von Clientanmeldeinformationen:

  • Zertifikat. Workloads belegen, dass sie über einen privaten Schlüssel verfügen, indem sie eine Assertion mit dem privaten Schlüssel signieren. Der private Schlüssel wird nicht an Microsoft Entra ID übertragen. Nur die Assertion wird gesendet. Wir empfehlen Zertifikate anstelle geheimer Clientschlüssel, da sie sicherer sind und häufig besser verwaltet werden.
  • Verbundanmeldeinformationen. Der Workload-Identitätsverbund ermöglicht Workloads, die nicht in Microsoft Azure ausgeführt werden, eine Identität von einem anderen Identitätsanbieter, GitHub Actions oder Kubernetes-Cluster zu verwenden. Workloads fordern Token für Verbundanmeldeinformationen genauso wie für Zertifikatanmeldeinformationen an. Der Unterschied besteht darin, dass die Assertion, ein signiertes JSON-Webtoken, vom Verbundidentitätsanbieter stammt.
  • Geheimer Clientschlüssel. Geheime Clientschlüssel werden manchmal auch als Anwendungskennwörter bezeichnet und entsprechen einem Zeichenfolgenwert, den die Workload verwenden kann, um sich selbst zu identifizieren. Der Textwert des geheimen Schlüssels wird von der Workload an Microsoft Entra ID in einer POST-Anforderung für ein Token gesendet. Geheime Clientschlüssel sind weniger sicher als Zertifikate oder der Workload-Identitätsverbund. Wenn Ihre Workload geheime Schlüssel verwendet, befolgen Sie diese bewährten Methoden zum Verwalten von geheimen Schlüsseln.

Zusätzlich zu Microsoft Entra ID umfasst die Microsoft Entra-Produktfamilie Microsoft Entra Workload ID. Microsoft Entra Workload ID verfügt über die folgenden Premiumfunktionen, um die Workloadsicherheit zu verbessern.

  • Bedingter Zugriff: Unterstützt risikobasierte Richtlinien für Workloadidentitäten.
  • Identitätsschutz: Stellt Berichte über kompromittierte Anmeldeinformationen, anomale Anmeldungen und verdächtige Änderungen an Konten bereit.
  • Zugriffsüberprüfungen: Ermöglicht die Delegierung von Überprüfungen an die richtigen Personen, wobei der Schwerpunkt auf den wichtigsten privilegierten Rollen liegt.
  • Empfehlungen zur App-Integrität schlagen Möglichkeiten vor, Identitätssicherheitslücken in Ihrem Anwendungsportfolio zu beheben und die Mandantensicherheit und den Resilienzstatus zu verbessern.

Workloads können fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE) unterstützen, wenn sie Microsoft Graph mindestens einmal pro Stunde aufrufen. Um CAE zu unterstützen, muss es sich bei der Workload um eine einzelne Mandantenanwendung handeln, und die App muss in dem Mandanten registriert sein, in dem sie auf Microsoft Graph zugreift. Wenn Ihre Workload diese Anforderungen erfüllt, finden Sie die Implementierungsschritte in diesem Beispiel.

Nächste Schritte