Ersetzen von Dienstprinzipalprofilen durch Dienstprinzipale

Wenn Ihre Lösung Dienstprinzipalprofile (Service Principal Profiles, SPP) verwendet und deren Identitäts-, Governance-, API- oder betriebliche Einschränkungen Ihre Anforderungen einschränken, können Sie in diesem Leitfaden basierend auf dedizierten Microsoft Entra-Dienstprinzipalen einen Ersatz auswerten und implementieren. Wenn Ihre vorhandene profilbasierte Lösung Ihre Anforderungen erfüllt, können Sie sie weiterhin verwenden.

Für Kunden, die sich für die Migration entscheiden, empfiehlt dieses Handbuch verwaltete Identitäten und föderierte Anmeldeinformationen, sofern die Hosting- und Vertrauensanforderungen erfüllt sind. Die direkte Authentifizierung mit einem Dienstprinzipal bleibt eine Alternative. Beide Pfade stellen dedizierte Kundenidentitäten für Verzeichnisgovernance, unabhängige Anmeldeüberwachung und Zugriff auf unterstützte Dienste auch außerhalb profilbezogener Schnittstellen bereit.

Warum von Profilen migrieren

Erwägen Sie das Ersetzen von Profilen, wenn die folgenden Einschränkungen Ihre Lösung einschränken:

  • Profile entsprechen nicht den bewährten Methoden von Microsoft Entra ID für geregelte Workloadidentitäten. Ein Profil hat keine Repräsentation in Microsoft Entra ID. Es erzeugt keine unabhängigen Anmeldeprotokolle, kann nicht mit einer eigenen Richtlinie für bedingten Zugriff versehen werden und kann nicht durch die Tools gesteuert werden, die für den Rest der Identitätsstruktur verwendet werden.

Beispielsweise können Sie ein Profil nicht als Identität einer Direct Lake-Verbindung von einem semantischen Modell zu einem Lakehouse oder Warehouse konfigurieren. Sie können ihr auch keinen Zugriff als unabhängige Microsoft Entra-Identität auf andere nachgeschaltete Dienste gewähren, die die Anwendung oder ihre Workloads erreichen müssen. Ein dedizierter Dienstprinzipal kann diese Berechtigungen empfangen, sofern der Dienst dies unterstützt.

Sie können Profile nicht mit den Fabric REST-APIs verwenden. Profile werden nur von der profilfähigen REST-API, dem .NET SDK und unterstützten XMLA/TOM-Schnittstellen unterstützt. Die Fabric REST-APIs unterstützen keine Profile, und die Unterstützung ist nicht geplant. Verwenden Sie eine unterstützte Identität für diese API-Aufrufe anstelle eines Profils. Das Erstellen eines dedizierten Dienstprinzipals erfüllt die Identitätsanforderung, aber jede API und jeder Vorgang muss diese Identität weiterhin unterstützen und ihm die erforderlichen Berechtigungen erteilen.

  • Die Authentifizierung bleibt an die übergeordnete Identität gebunden. Wenn die übergeordnete Entität ein Geheimnis oder ein Zertifikat verwendet, schützen und rotieren Sie diese Anmeldeinformationen. Das empfohlene Ersatzverfahren vermeidet gespeicherte Anmeldeinformationen der Kundenanwendung. Profile können auch ein übergeordnetes verwaltetes Identitäts-Element verwenden, sodass die geheimnislose Authentifizierung allein nicht erfordert, dass Profile ersetzt werden. Eine übergeordnete verwaltete Identität bietet den Profilen keine unabhängigen Verzeichnisidentitäten oder eine breitere API-Unterstützung.

Profile lösen ein Skalierungsproblem, kein Problem getrennter Identitäten. Ein übergeordneter Dienstprinzipal kann bis zu 100.000 Profile erstellen, und jedes Profil kann auf bis zu 1.000 Arbeitsbereiche zugreifen oder bis zu 1.000 Arbeitsbereiche erstellen. Ein Dienstprinzipal selbst kann zu höchstens 1.000 Arbeitsbereichen in diesem Modell gehören. Dedizierte Kundenidentitäten belegen stattdessen Microsoft Entra Verzeichnisobjekte. Überprüfen Sie die geltenden Grenzwerte für die Kundenanzahl, bevor Sie die Migration durchführen.

Note

Sicherheitsgrenze: Ein Profil ist keine kryptografische Mandantengrenze: Sein übergeordneter Dienstprinzipal kann über jedes seiner Profile handeln. Das empfohlene Muster ermöglicht es ebenfalls, dass sich die verwaltete Laufzeitidentität als jede Kundenanwendung authentifizieren kann, die ihr vertraut. Arbeitsbereichs- und Ressourcenberechtigungen bleiben die erzwungene Autorisierungsgrenze. Schützen Sie die Laufzeit- und die Kunden-zu-Identitätszuordnung in jedem der beiden Modelle.

Weitere zu berücksichtigende Profilbeschränkungen

Einschränkung Auswirkungen der Migration
Keine unabhängige Prüfungs- oder Richtlinienidentität Ein Profil verfügt über keinen unabhängigen Microsoft Entra-Anmeldedatensatz oder ein Ziel für bedingten Zugriff für Workloadidentitäten. Dedizierte Dienstprinzipale bieten diese Funktionen, sofern die Richtlinien- und Lizenzvoraussetzungen erfüllt sind.
Dauerhafte Kopplung von Profil zu übergeordnetem Element Profile können nicht an einen anderen übergeordneten Service Principal übertragen werden. Das Ersetzen des übergeordneten Elements erfordert neue Profile, neue Arbeitsbereichsberechtigungen und aktualisierte Kundenzuordnungen.
Kein Identitätsverwaltungsportal Profile sind nur API und werden nicht in Microsoft Entra Verwaltungstools dargestellt. Dedizierte Anwendungen und Dienstprinzipale verfügen über Sichtbarkeits- und Verwaltungsoberflächen für Verzeichnisse.

Das Muster für verwaltete Identitäten und Verbundidentitäts-Anmeldeinformationen

Verwenden Sie dieses Muster, wenn Sie Profile ersetzen und Ihre Laufzeit die Anforderungen für das Hosting verwalteter Identitäten erfüllt.

Das Muster

Weisen Sie jedem Kunden einen echten Microsoft Entra Dienstprinzipal zu und verwenden Sie die verwaltete Identität der Anwendung als Assertionsquelle. Bei diesem Ansatz werden sowohl die freigegebenen Anwendungsanmeldeinformationen als auch die Profilabstraktion ersetzt. Sie können jede Kundenidentität für den Bedingten Zugriff für Workloadidentitäten protokollieren, steuern und auswerten, und sie kann unterstützte Fabric-REST-APIs aufrufen.

Dieser Ansatz ist der empfohlene Migrationspfad bei Lösungen, für die deren Azure-Hosting- und Vertrauensanforderungen geeignet sind. Es entfernt gespeicherte Anmeldeinformationen der Kundenanwendung und deren Rotationsprozesse, ohne zu ändern, wo Workspace- und Ressourcenautorisierung erzwungen wird.

Die Architektur zeigt die Laufzeitvorgänge der Anwendung, drei Kundenanwendungsidentitäten und Vertrauensstellungen sowie die 1:1-Kundenarbeitsbereichsbeziehungen. Sie stellt die Standardanordnung der gemeinsam genutzten Laufzeitumgebung dar, nicht eine neue Isolationsgrenze.

Diagramm, das eine ISV-Anwendung zeigt, die ein verwaltetes Identitätstoken erwirbt, es gegen ein ausgewähltes Kundenanwendungstoken austauscht und Ziel-APIs aufruft. Separate Kunden-A-, B- und C-Dienstkonten verfügen über Verbundvertrauensstellung in der verwalteten Identität der Anwendung und greifen nur auf ihre entsprechenden Kundenarbeitsbereiche zu.

Abbildung 1: Eine von der Anwendung verwaltete Identität authentifiziert sich als dedizierte Dienstprinzipale.

Funktionsweise

  1. Verwaltete Identität Weisen Sie der ISV-Anwendung, die auf unterstützten Azure Compute ausgeführt wird, eine vom Benutzer zugewiesene verwaltete Identität zu, z. B. App Service, Container-Apps, eine entsprechend konfigurierte AKS-Workload oder eine virtuelle Maschine. Verwenden Sie eine verwaltete Identität für die Anwendung, nicht eine pro Kunde. Es verfügt über keine eigenen Kundenarbeitsbereichs- oder Zieldienstberechtigungen; seine Rolle ist hier nur die Bereitstellung einer Assertion.

  2. Kunden-, Benutzer- oder Gruppen-Dienstprinzipale. Erstellen Sie für jede vorhandene Kunden- oder Autorisierungsgrenze eine Microsoft Entra Anwendungsregistrierung und einen Dienstprinzipal im Verzeichnismandanten des ISV. Ein logischer Kunde bedeutet nicht unbedingt einen separaten Microsoft Entra-Mandanten, und eine Identität pro Endbenutzer ist nicht erforderlich, es sei denn, wenn das vorhandene Zugriffsdesign dies vorsieht.

  3. Verbundidentitätsnachweis. Konfigurieren Sie eine Anmeldeinformation für föderierte Identitäten für jede Registrierung der Kundenanwendung, um der verwalteten Identität der Anwendung zu vertrauen. Die Laufzeit kann dann das verwaltete Identitätstoken als Assertion verwenden, um ein Zugriffstoken für diese Kundenanwendung ohne einen geheimen Clientschlüssel oder Zertifikat abzurufen.

  4. Laufzeittokenaustausch. Wenn Der Benutzer A oder ein kundenspezifischer Job die Anwendung aufruft, ermitteln Sie Kunde A anhand einer vertrauenswürdigen serverseitigen Zuordnung. Rufen Sie das verwaltete Identitätstoken mit Zielgruppe api://AzureADTokenExchangeab; tauschen Sie es für ein Zugriffstoken als SP-A aus. Rufen Sie dann die Ziel-APIs mithilfe des SP-A-Tokens auf, um Arbeitsbereiche zu verwalten, Ressourcenvorgänge auszuführen oder anwendungsspezifische Token anzufordern, sofern erforderlich.

    Für den Austausch im vorherigen Schritt akzeptiert die .NET Azure Identity ClientAssertionCredential das verwaltete Identitätstoken als Client assertion. Dies ist ein Anmeldeinformationstyp von Azure Identity, keine MSAL-Klasse. Das Zugriffstoken muss auf die Zielgruppe der Ressourcen-API abzielen, nicht auf die Tokenaustausch-Zielgruppe.

  5. Arbeitsbereichszugriff. Gewähren Sie jedem Dienstprinzipal nur Zugriff auf die ihm zugewiesenen Arbeitsbereiche, und zwar nur mit Mitglieds- oder Administratorrechten, wenn diese Rollen erforderlich sind, oder andernfalls mit der unterstützten Rolle mit den geringsten Berechtigungen für die erforderlichen Vorgänge. Diese Berechtigung beschränkt den Ressourcenzugriff. Da die verwaltete Identität der Anwendung sich gegenüber jeder Kundenanwendung authentifizieren kann, die ihr vertraut, behandeln Sie sie und ihre Computehosts als hochwertige Identitäten und Infrastruktur.

  • Weniger langlebige Anmeldeinformationen. Sie müssen kein Anwendungsgeheimnis des Kunden oder den privaten Schlüssel eines Zertifikats in der Laufzeitumgebung speichern, abrufen oder verteilen.

  • Weniger Rotationsarbeit. Azure verwaltet die Anmeldeinformationen für verwaltete Identitäten und gibt kurzlebige Token aus. Sie benötigen keinen separaten Geheimnis- oder Zertifikatverlängerungsprozess für jede Kundenanwendung, die diese Vertrauensstellung verwendet.

  • Einheitliches Onboarding. Stellen Sie eine Kundenanwendung und einen Dienstprinzipal bereit, definieren Sie die explizite Vertrauensstellung, und gewähren Sie Kundenressourcenzugriff. Neue Kunden benötigen keine neuen langlebigen Zugangsdaten.

Diese Vorteile machen die Notwendigkeit einer Verwaltung von Vertrauensstellungen, Kundenautorisierung, Auditüberwachung oder Verzeichniskapazitätsplanung nicht überflüssig.

Alternative: Direkte Authentifizierung mit einem Dienstprinzipal

Wenn Sie keine verwalteten Identitäts- und Verbundidentitätsanmeldeinformationen verwenden möchten, erstellen Sie dieselben dedizierten Kundenanwendungsregistrierungen und Dienstprinzipale, authentifizieren Sie sie jedoch direkt mit Zertifikaten oder anderen unterstützten Anwendungsanmeldeinformationen. Bevorzugen Sie Zertifikate vor Clientgeheimnissen, sofern unterstützt. Schützen Sie private Schlüssel und Geheimnisse, beschränken Sie den Zugriff darauf und automatisieren Sie die Rotation.

Die direkte Authentifizierung behält die Verzeichnissichtbarkeit, die Anmeldeprotokolle pro Sicherheitsprinzipal und den Zugriff auf unterstützte APIs bei. Das Hosting oder die Vertrauensstellung für die verwaltete Identität ist nicht erforderlich, aber gespeicherte Kundenanmeldeinformationen werden dadurch jedoch nicht eliminiert.

Schlüsselkonzepte

Unterscheiden Sie die Anmeldeinformationen, die Vertrauen herstellen, von den zur Laufzeit verwendeten Token.

Verbundidentitätszugangsdaten

Konfigurieren Sie eine Verbundidentitätsanmeldeinformation (FIC) für die Microsoft Entra Anwendungsregistrierung, die dem Dienstprinzipal des Kunden zugrunde liegt. Sie definiert eine Vertrauensstellung mit einem Tokenherausgeber und gibt an, welche Assertion die Anwendung anstelle eines geheimen Clientschlüssels oder Zertifikats akzeptiert.

In dieser Architektur ist die Zielidentität die Kundenanwendung und der Dienstprinzipal; die verwaltete Identität der Anwendung ist die Assertion Source. Aus diesem Grund konfigurieren Sie die Kundenanmeldeinformation für die Anwendungsregistrierung und nicht für das Dienstprinzipal-Objekt oder die quellverwaltete Identität.

Note

Konfigurationsunterschied: Verbundidentitätsanmeldeinformationen werden auch für benutzerseitig zugewiesene verwaltete Identitäten in anderen Verbundszenarien unterstützt. Dadurch wird das Muster hier nicht geändert: Konfigurieren Sie die Vertrauensstellung für jede Kundenanwendungsregistrierung. Nur eine vom Benutzer zugewiesene verwaltete Identität wird als Assertionsquelle für verwaltete Identitäten im in diesem Handbuch beschriebenen App-Vertrauensmuster unterstützt.

Vertrauensstellung Wert in der globalen Cloud
Issuer https://login.microsoftonline.com/{directory-tenant-id}/v2.0
Betreff Die Objekt-ID des Dienstprinzipals der vom Benutzer zugewiesenen verwalteten Identität. Verwenden Sie seine Client-ID nicht.
Publikum api://AzureADTokenExchange

Wenn die Anwendung das verwaltete Identitätstoken vorlegt und ein Zugriffstoken für die Kundenanwendung anfordert, validiert Microsoft Entra ID die Assertion anhand der Verbundanmeldeinformationen. Der Herausgeber, der Betreff und die Zielgruppe müssen übereinstimmen. Wenn die Überprüfung erfolgreich ist, gibt es ein Zugriffstoken aus, das den Zieldienstprinzipal für die angeforderte Ressource darstellt.

Die Registrierung der verwalteten Identität und der vertrauenden Anwendung muss sich im selben Microsoft Entra Mandanten befinden. Die Ressourcenzielgruppe ist eine separate Wahl von der Assertionszielgruppe. Für Azure Identity ist api://AzureADTokenExchange/.default der Bereich für den globalen Cloudtokenaustausch; der Ziel-API-Bereich ist normalerweise der Ressourcenbezeichner, gefolgt von /.default.

Tokenaustauschablauf: Client-Anmeldeinformationen mit einer Verbund-Assertion

Dieser Ablauf umfasst drei Teilnehmer und sechs Schritte. SP-A ist der Anwendungs- und Service Principal des Kunden A. Das Assertionstoken für die verwaltete Identität und das zurückgegebene SP-A-Ressourcenzugriffstoken dienen verschiedenen Zwecken.

Sequenzdiagramm mit einer Azure-Anwendung, die ein verwaltetes Identitätstoken anfordert und empfängt, eine Clientanmeldeinformationenanforderung mit der Client-ID von SP-A und dem verwalteten Identitätstoken als Assertion sendet, Microsoft Entra ID die Verbundvertrauensstellung überprüft, das Zugriffstoken von SP-A zurückgibt und die Anwendung die Ziel-API als SP-A aufruft.

Abbildung 2: Client credentials-Tokenaustausch, der durch eine Assertion einer verwalteten Identität gestützt wird.

  1. Fordern Sie das Token der Managed Identity an. Die App auf Azure fordert ein verwaltetes Identitätstoken mit Zielgruppe api://AzureADTokenExchangean.

  2. Assertionstoken zurückgeben. Microsoft Entra ID gibt das verwaltete Identitätstoken aus, das die App über den verwalteten Identitätsmechanismus der Azure Hostumgebung empfängt.

  3. Übermitteln Sie die Kundentokenanforderung. Senden Sie eine Anfrage an den Endpunkt des Verzeichnismandanten /oauth2/v2.0/token mit grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token> und scope=<target-resource>/.default. Die vollständige OAuth-Anforderung übermittelt außerdem client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer; eine Identitätsbibliothek behandelt diesen Parameter.

  4. Überprüfen Sie die Zusicherung. Microsoft Entra ID überprüft das verwaltete Identitätstoken anhand der Verbundanmeldeinformation bei der Anwendungsregistrierung von SP-A.

  5. Das Kundenzugriffstoken zurückgeben. Microsoft Entra ID gibt ein Zugriffstoken für SP-A mit der Zielressource als Zielgruppe zurück.

  6. Rufen Sie die ZIEL-REST-APIs auf. Die App sendet das Zugriffstoken von SP-A an die Ziel-API. Es verwendet das Assertionstoken nicht als Ressourcen bearertoken und wählt kein Profil aus.

Architekturvergleich

Die Ersetzungsspalte deckt im Allgemeinen dedizierte Dienstkonten ab. Verwaltete Identität und Föderation sind die empfohlene Authentifizierungsmethode, aber auch die direkte Zertifikatsauthentifizierung oder eine andere unterstützte Anmeldeinformationsauthentifizierung ist möglich.

Aspect Dienstprinzipalprofile Eigene Dienstprinzipale
Kennung pro Kunde Logisches Profil, kein Microsoft Entra-Objekt. Anwendungsregistrierung und Service Principal, der die Kundenautorisierungsgrenze darstellt.
Erzwungene Begrenzung Arbeitsbereichs- und Ressourcenberechtigungen. Arbeitsbereichs- und Ressourcenberechtigungen.
Reichweite der Stammidentität Der übergeordnete Dienstprinzipal kann als jedes seiner Profile agieren. Eine Laufzeit kann alle Identitäten erreichen, für die sie über Anmeldeinformationen oder vertrauenswürdige Assertions verfügt; ein MI kann sich als jede App authentifizieren, die ihm vertraut.
Geheimnisrotation Erforderlich, wenn das übergeordnete Element ein Geheimnis oder ein Zertifikat verwendet. Für Anmeldeinformationen für verwaltete Identitäten nicht erforderlich; erforderlich für gespeicherte Zertifikate oder Clientgeheimnisse im direkten Pfad.
Skalenobergrenze Bis zu 100.000 Profile pro übergeordnetem SP; jedes Profil bis zu 1.000 Arbeitsbereiche. Die eigene Zugehörigkeit des übergeordneten SP ist auf 1.000 Arbeitsbereiche beschränkt. Eine Anwendungsregistrierung und ein Dienstprinzipal pro Kunde, vorbehaltlich der Verzeichnisobjektkontingente und der Ressourcengrenzwerte jedes Zieldiensts.
Überwachungspfad Profil-IDs werden möglicherweise in Ressourcenprotokollen angezeigt, Profile weisen jedoch keinen unabhängigen Microsoft Entra-Anmeldedatensatz auf. Microsoft Entra Anmeldedatensätze pro Serviceprinzipal, korreliert mit Anwendungs- und Ressourcenüberwachungsprotokollen.
Bedingter Zugriff Keine Workload-Identity-Richtlinie pro Profil. Verfügbar für berechtigte Dienstprinzipale mit Microsoft Entra Workload ID Premium; die Richtlinie muss direkt auf jeden Prinzipal ausgerichtet sein.
Portalsichtbarkeit Nicht in Microsoft Entra ID vorhanden. Anwendungsregistrierung in App-Registrierungen; Dienstprinzipalobjekt in Unternehmensanwendungen.
Fabric REST-API-Unterstützung Nicht unterstützt; Support ist nicht geplant. Unterstützt, wo die spezifische API und der Vorgang Service Principals akzeptieren, mit erforderlichen Berechtigungen.
Übertragung von Anmeldeinformationen und Kopplung mit dem übergeordneten Element Ein Profil kann nicht zwischen übergeordneten Dienstprinzipalen übertragen werden. Die Verbundvertrauen kann neu konfiguriert werden; direkte Anmeldeinformationen können ersetzt werden, ohne eine Profilabstraktion neu zu erstellen.

Lesen Sie diese Tabelle: Keine der Konfigurationen bietet eine kryptografische Isolation von Mandanten. Ressourcenberechtigungen erzwingen den Zugriff, und die Laufzeit hat möglicherweise indirekten Zugriff über Kundengrenzen hinweg. Profile bieten eine leichtgewichtige Identität. Dedizierte Dienstprinzipale verbessern die Verzeichnisgovernance, anmeldebezogene Sichtbarkeit und API-Kompatibilität. Der empfohlene Pfad für verwaltete Identität und Verbund entfernt auch gespeicherte Anwendungsanmeldeinformationen des Kunden.

Migrationspfad

Der folgende Pfad ersetzt Profile durch dedizierte Dienstprinzipale für den Kundendienst. Behalten Sie Migrations- und Rollbackentscheidungen für jeden Kunden getrennt.

Von Profilen bis hin zu verwalteter Identität und föderierten Anmeldeinformationen

Verwenden Sie die folgenden Migrationsphasen mit einem kleinen Pilotkohort und einem Rollout-Switch pro Kunde. Halten Sie die Profilroute zur Verfügung, bis die Validierung und der vereinbarte Rollback-Zeitraum abgeschlossen sind.

Phase 0: Erstellen Sie die verwaltete Identität der Anwendung

  • Erstellen Sie die vom Benutzer zugewiesene verwaltete Identität für die Anwendung, und weisen Sie sie der Compute-Ressource zu. Das Implementierungshandbuch zeigt die Erstellungs- und Zuweisungsbefehle.

  • Notieren Sie die Objekt-ID des Prinzipals. Der Verbundidentitätsnachweis jeder Kundenanwendung verwendet diesen Wert als Subjekt. Notieren Sie außerdem die Client-ID, verzeichnismandanten-ID und Azure Ressourcen-ID.

Verwenden Sie eine verwaltete Identität für die Anwendung, nicht eine pro Kunde. Ein separates MI für jeden Kunden ist in diesem Muster unnötig: Die Kundenidentität ist der Dienstprinzipal, und die MI liefert die Assertion. Bei größeren Bereitstellungen oder kleinerem Kompromittierungsbereich partitionieren Sie Kunden über eine kleine Anzahl von Laufzeitidentitäten, denen jeweils nur ihre zugewiesene Teilmenge von Kundenanwendungen vertraut.

Phase 1: Inventar

Alle vorhandenen Profile über die profile-management API auflisten:

GET {profile-api-base}/v1.0/myorg/profiles

Für jedes Profil notieren Sie:

  • Profil-ID und Anzeigename, übergeordneter Dienstprinzipal und Kundenzuordnung.

  • Zugeordnete Arbeitsbereiche und Rollenzuweisungen.

  • Zugeordnete semantische Modelle oder Datasets, Berichte und andere Ressourcen.

  • Verbindungen, Datenquellenanmeldeinformationen, Abhängigkeiten hinsichtlich Besitzverhältnissen, Hintergrundaufträge und API-Vorgänge, die vom Profil abhängen.

Notieren Sie vor dem Ändern der Konfiguration eines Kunden die vorhandenen Arbeitsbereichsrollen, den Besitz des semantischen Modells, Verbindungsidentitäten, die Konfiguration von Anmeldeinformationen und die für das Rollback erforderliche Kunden-zu-Profil-Zuordnung. Notieren Sie sichere Verweise auf Anmeldedaten, keine geheimen Werte.

Notieren Sie die Gesamtanzahl der Kunden, und vergleichen Sie die erforderlichen Anwendungs- und Dienstprinzipalobjekte mit Ihrem Microsoft Entra Verzeichnisobjektkontingent, bevor Sie fortfahren. Überprüfen Sie auch den Grenzwert von 1.000 Arbeitsbereichen für Mitgliedschaften sowie alle ressourcenspezifischen Grenzwerte. Wenn die Population das Kontingent eines einzelnen Verzeichnisses überschreitet, planen Sie eine unterstützte Kontingenterhöhung oder ein bewusst verwaltetes Design mit mehreren Verzeichnissen; es wird von diesem Muster nicht automatisch gelöst.

Note

Endpunktnotation:{profile-api-base} gibt die vorhandene profilfähige REST-API-Basis-URL an, die bereits von Ihrer Lösung verwendet wird. Behalten Sie diese URL in Ihrer Bereitstellungskonfiguration bei. In diesen Beispielen werden die Vorgangspfade beibehalten; Ersetzen Sie jeden Platzhalter, bevor Sie sie ausführen. Der Begriff profilbewusst beschreibt die API-Unterstützung, nicht den Status „Veraltet“.

Phase 2: Neue Identitäten bereitstellen

Für jedes Profil oder jede Gruppe von Profilen, die zur gleichen Autorisierungsgrenze des Kunden gehören:

  1. Erstellen Sie eine Anwendungsregistrierung und einen Dienstprinzipal. Notieren Sie die Anwendungsclient-ID, die Anwendungsobjekt-ID und die Dienstprinzipalobjekt-ID separat.

  2. Konfigurieren Sie eine Verbundidentitäts-Anmeldeinformation für die Anwendungsregistrierung des Kunden, die der in Phase 0 erstellten Anwendungs-MI vertraut.

  3. Gewähren Sie dem neuen Dienstprinzipalobjekt Zugriff auf dieselben Kundenarbeitsbereiche und -ressourcen. Verwenden Sie „Member“, wenn die inventarisierten Vorgänge dies erfordern, oder die Rolle mit den geringsten Rechten. Adminrechte nur bei Bedarf gewähren.

Behalten Sie vorhandene Arbeitsbereichs- und Ressourcen-IDs bei, wo immer unterstützt. Eine Arbeitsbereichsberechtigung überträgt nicht automatisch Ressourcenbesitz, Verbindungsidentitäten oder Datenquellenanmeldeinformationen. Schließen Sie diese dienstspezifischen Updates vor der Umschaltung ab.

Phase 3: Aktualisieren des Anwendungscodes

  • Ersetzen Sie den Profilauswahlheader und die SDK-Profilkonfiguration durch verwalteten Identitäts-gesicherten Tokenaustausch für die ausgewählte Kundenanwendung.

  • Aktualisieren Sie die Kunden-zu-Identitätszuordnung in Ihrer Anwendungsdatenbank.

Vorher Nach
customerId -> profileId mit einer freigegebenen SP-Anmeldeinformation und einem Profilheader. customerId -> spClientId mit der SP-Authentifizierung pro Kunde über verwalteten Identitätstokenaustausch. Behalten Sie außerdem die Verzeichnismandanten-ID, die Authentifizierungskonfiguration und die zulässigen Ressourcen-IDs bei.

Kunden-IDs sind logische IDs von ISV-Kunden, nicht unbedingt Microsoft Entra Mandanten-IDs. Überprüfen Sie die Kundenmitgliedschaft des authentifizierten Benutzers, bevor Sie eine Identität auswählen. Schlüsseltokencaches nach Verzeichnismandanten, Client-ID und Ressource oder Gültigkeitsbereich.

  • Aktualisieren Sie die anwendungsspezifische Tokengenerierung, um das Zugriffstoken für den Dienstprinzipal des Kunden zu verwenden. Wenn Ihre Lösung Berichte oder andere Inhalte einbettet, aktualisieren Sie diese Tokengenerierung ebenfalls; Das Einbetten ist eine bestehende Workload, die migriert werden soll, nicht die Voraussetzung für diesen Leitfaden.

  • Aktualisieren Sie die Arbeitsbereichsverwaltung, nachgeschaltete Verbindungen, Bereitstellung, geplante Aufträge und jeden anderen Zugriffspunkt mithilfe der alten Profilkonfiguration.

Phase 4: Überprüfen

Überprüfen Sie für jeden Kunden Folgendes:

  • Der Zugriff auf Arbeitsbereich und Ressourcen erfolgt erfolgreich über den neuen Dienstprinzipal.

  • Der Erwerb von Token für verwaltete Identitäten und der föderierte Tokenaustausch gelingen für die beabsichtigte Kundenanwendung.

  • Anwendungsspezifische Token werden erfolgreich generiert, wo sie verwendet werden, und vorhandene Berichte oder andere eingebettete Inhalte werden ggf. ordnungsgemäß gerendert.

  • Neue Anmeldungen von Dienstprinzipalen werden in Microsoft Entra ID angezeigt und können mit Anwendungs- und Ressourcenüberwachungsprotokollen korreliert werden.

  • Der kundenübergreifende Zugriff wird verweigert: Ein Anrufer kann die Anwendungsidentität oder Ressourcen-IDs eines anderen Kunden nicht auswählen.

Dokumentieren Und testen Sie vor der Produktionsumstellung das Rollbackverfahren für einen Pilotkunden. Berücksichtigen Sie die Wiederherstellung des Besitzers eines semantischen Modells, von Verbindungsidentitäten, Datenquellenanmeldeinformationen und Berechtigungen, die während der Migration geändert wurden. Stellen Sie sicher, dass das vorherige Profil seine erforderlichen Vorgänge nach dem Rollback ausführen kann, einschließlich Konfigurationsaktualisierungen und Parameterupdates.

Wechseln Sie die Application Route des Kunden erst, nachdem die Akzeptanzkriterien bestanden wurden. Überwachen Sie Fehler, Leistung und Berechtigungen, bevor Sie die Bereitstellung erweitern.

Wenn die Überprüfung fehlschlägt, halten Sie betroffene Hintergrundaufträge an und stellen Sie die vorherige Konfiguration mithilfe der unterstützten Verfahren für jeden Dienst wieder her. Das Zurückwechseln der Anwendungsroute nur zum Profil stellt möglicherweise keine Vorgänge wieder her, die von Besitz oder Anmeldeinformationen abhängen. Wechseln Sie nach dem Wiederherstellen der erforderlichen Konfiguration zurück zur profilbasierten Route, und überprüfen Sie den Ressourcenzugriff und abhängige Vorgänge, bevor Sie Aufträge fortsetzen. Behalten Sie die ursprünglichen Profile und die erforderlichen Berechtigungen während des Rollbackzeitraums bei.

Phase 5: Profile außer Betrieb nehmen

  • Entfernen Sie nach dem Rollbackzeitraum veraltete Berechtigungen für den ursprünglichen übergeordneten Arbeitsbereich und den Profilarbeitsbereich, nachdem Sie bestätigt haben, dass die dedizierten Kundendienstprinzipale über den erforderlichen Zugriff verfügen.

Löschen Sie jedes migrierte Profil über die Profilverwaltungs-API:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}
  • Löschen Sie optional die ursprüngliche Registrierung und den Dienstprinzipal der freigegebenen Anwendung, wenn sie von keinen Kunden, Aufträgen/Jobs oder nicht zugehörigen Arbeitsauslastungen mehr verwendet werden. Veraltete Zugangsdaten stilllegen und Migrationszuordnungen und Überwachungsdatensätze entsprechend Ihren Aufbewahrungsanforderungen beibehalten.

Note

Alternative Migration ohne MI oder Verbund: Verwaltete Identitäts- und Verbundanmeldeinformationen werden empfohlen, nicht obligatorisch. Wenn Sie sie nicht verwenden möchten, lassen Sie Phase 0 aus. Konfigurieren Sie in Phase 2 ein Zertifikat oder eine andere unterstützte Anmeldeinformation für jede Kundenanwendung anstelle einer Verbundanmeldeinformation. In Phase 3 und 4 können Sie Zugriffstoken direkt als diese Anwendung abrufen und überprüfen. Behalten Sie denselben Bestand, Ressourcenzuweisungen, Kundenautorisierungsschritte, Rollout- und Außerbetriebnahmeschritte bei, und betreiben Sie die sichere Speicherung und Rotation von Anmeldeinformationen.

Implementierungsanleitung

Dieses Handbuch implementiert den empfohlenen Pfad für verwaltete Identitäten und Verbundidentitätsanmeldeinformationen. Die Alternative zur direkten Authentifizierung folgt der gleichen Identitäts- und Berechtigungseinrichtung und wird nach den Hauptschritten beschrieben. Azure CLI Beispiele verwenden Bash-Syntax. Ersetzen Sie Platzhalter, und melden Sie sich vor dem Ausführen beim vorgesehenen Mandanten und Abonnement an.

Voraussetzungen

  • Ein Azure Abonnement und Berechtigungen zum Erstellen und Zuweisen verwalteter Identitäten für den empfohlenen Pfad.

  • Berechtigungen in Microsoft Entra ID zum Erstellen von Anwendungsregistrierungen und Dienstprinzipalen sowie zum Aktualisieren von Anwendungsanmeldeinformationen. Azure Ressourcenberechtigungen und Verzeichnisberechtigungen sind getrennt.

  • Eine anwendung, die auf unterstützten Azure Compute gehostet wird, z. B. App Service, Container-Apps, eine entsprechend konfigurierte AKS-Workload oder eine virtuelle Maschine. Die MI-gesicherte Assertion-Quelle in diesem Muster hängt von der Azure-Hostingkonfiguration ab.

  • Administrative Berechtigungen zum Gewähren von Zugriff auf den Kundenarbeitsbereich und auf Ressourcen, Konfigurieren der erforderlichen Diensteinstellungen und Erteilen von API-Berechtigungen oder Zustimmung, für die der Zieldienst sie benötigt.

  • Azure CLI ist installiert und beim richtigen Mandanten des Verzeichnisses angemeldet. Bestätigen Sie den Abonnementkontext, bevor Sie Azure Ressourcen erstellen.

Einstellungen für Entwickler-Mandanten

Überprüfen Sie die relevanten Einstellungen in der Verwaltungsschnittstelle Ihres Diensts unter Mandanteneinstellungen und Entwicklereinstellungen. Beschränken Sie den Zugriff des Dienstprinzipals auf eine zulässige Sicherheitsgruppe, die die Kundendienstprinzipale enthält. Die genauen Bezeichnungen und das aktuelle Verhalten finden Sie unter Einstellungen des Entwicklermandanten.

Fügen Sie für jede von Ihrer Lösung erforderliche Gruppeneinstellung jeden Ersatz-Dienstprinzipal zu einer zulässigen Sicherheitsgruppe hinzu, bevor Sie testen oder die Umstellung durchführen. Der Zugriff, der dem ursprünglichen übergeordneten Dienstprinzipal gewährt wird, autorisiert nicht automatisch die ersetzenden Prinzipale. Die Einstellung für den Zugriff auf die öffentliche API gilt sowohl für die vorhandenen profilfähigen REST-APIs als auch für die Fabric REST-APIs. Die Migration nur der Identität entfernt diese Voraussetzung nicht.

Die folgende Einstellung für public-API verwendet ein produktneutrales Etikett; die Verwaltungsschnittstelle kann den Namen des Diensts enthalten.

Setting Veröffentlichte Standardeinstellung Erforderlich, wenn
Dienstprinzipale können öffentliche APIs aufrufen Für neue Kunden aktiviert. Die Kundendienstprinzipale rufen entweder die vorhandenen profilfähigen REST-APIs oder die Fabric-REST-APIs auf. Schließen Sie jedes Ersatzkonto in die zulässige Sicherheitsgruppe ein, wenn die Einstellung auf Gruppenebene festgelegt ist.
Dienstprinzipale können Arbeitsbereiche, Verbindungen und Bereitstellungspipelines erstellen. Deaktiviert für neue Kunden. Die Anwendung stellt diese Ressourcen bereit.
Inhalt in Apps einbetten In vorhandenen Konfigurationen aktiviert; verifizieren Sie Ihre Mandanteninstanz. Ihre vorhandene Anwendung bettet Inhalte über die entsprechenden REST-APIs ein.
Zulassen, dass Dienstprinzipale Profile erstellen und verwenden Gehen Sie nicht von einer Standardeinstellung aus. Nur wenn Kunden die Profilroute noch verwenden; für migrierte Kunden nicht erforderlich.

Überprüfen Sie die tatsächlichen Werte, anstatt die Standardwerte anzunehmen. Neue und vorhandene Mandanten können unterschiedlich sein, und Administratoren können Einstellungen ändern. Behalten Sie die Profileinstellung bei, bis alle abhängigen Kunden und Jobs migriert werden. Aktivieren Sie die Einbettungseinstellungen nicht für einen Workload ohne Einbettung.

Schritt 1: Erstellen und Zuweisen der vom Benutzer zugewiesenen verwalteten Identität

Diese verwaltete Identität stellt die ISV-Anwendung dar, nicht einen einzelnen Kunden. Verwenden Sie eine vorhandene Ressourcengruppe:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Notieren Sie ihre Client-ID, Prinzipal-ID (Objekt), Verzeichnismandanten-ID und Azure Ressourcen-ID. Weisen Sie diese der Compute-Ressource zu. Für eine vorhandene App Service-Anwendung:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Verwenden Sie das entsprechende Identitätszuweisungsverfahren für andere Rechendienste. Wählen Sie diese vom Benutzer zugewiesene Identität explizit in der Runtime aus. Da die Identität unabhängig von der Hostressource ist, muss die erneute Bereitstellung eines Hosts nicht jede Vertrauensstellung des Kunden ersetzen.

Schritt 2: Erstellen eines Service Principals für jeden Kunden

Erstellen Sie für jede Kunden-, Benutzer- oder Gruppenabgrenzung, die die vorhandenen Profile darstellen, eine Anwendungsregistrierung und den Service Principal. In diesem Beispiel wird eine Einzelmandantenanwendung im Verzeichnis des ISV erstellt:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)
Kennung Verwenden
Anwendungsclient-ID Identifizieren Sie die Kundenanwendung beim Anfordern eines Zugriffstokens.
Anwendungsobjekt-ID Konfigurieren Sie die föderierten Anmeldeinformationen für die Anwendungsregistrierung.
Objekt-ID für Dienstprinzipal Erteilen Sie Arbeitsbereichs- oder Ressourcenrollen, wenn die API die Objekt-ID des Prinzipals erfordert.

Note

Anmeldeinformationen für den empfohlenen Pfad: Erstellen Sie keinen geheimen Clientschlüssel oder ein Zertifikat für diese Authentifizierungsroute. Das Verbundvertrauen der Kundenanwendung liefert den Authentifizierungsmechanismus.

Schritt 3: Konfigurieren von Verbundidentitätsanmeldeinformationen

Rufen Sie die Prinzipal-ID für die verwaltete Identität und deren Verzeichnismandanten-ID ab. Verwenden Sie den Mandanten der Identität, anstatt anzunehmen, dass ein anderes aktuelles Abonnement denselben Mandanten hat:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Fügen Sie jeder Kundenanwendungsregistrierung eine Verbundidentitäts-Anmeldeinformation hinzu. Der folgende Global-Cloud-Befehl verwendet die Anwendungsobjekt-ID aus Schritt 2 und die soeben abgerufenen MI-Werte:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

Alternativ können Sie denselben JSON-Code mit ersetzten Werten in einer lokalen credential.json Datei speichern und übergeben --parameters credential.json. Wiederholen Sie die Vertrauenseinstellung für jede Kundenanwendung. Warten Sie die Weitergabe der Konfiguration ab, bevor Sie den Tokenaustausch überprüfen.

Schritt 4: Gewähren Sie jedem Dienstprinzipal Zugriff auf den Arbeitsbereich

Fügen Sie den Dienstprinzipal für den Kundendienst als Mitglied oder Administrator nur zu den festgelegten Arbeitsbereichen hinzu, in denen diese Rolle erforderlich ist. Bevorzugen Sie eine niedrigere unterstützte Rolle, wenn sie die Anforderungen des Vorgangs erfüllt. Diese Berechtigung legt den Ressourcenzugriff des Kunden fest.

Verwenden Sie die Arbeitsbereichsverwaltungsschnittstelle oder den REST-Vorgang für die Rollenzuweisung des Arbeitsbereichs. Im folgenden Beispiel werden konfigurierbare API- und Ressourcenbezeichner verwendet. Es erfordert eine autorisierte Bereitstellungsidentität; dem Laufzeit-MI selbst werden keine Kundenressourcenberechtigungen für den Tokenaustausch gewährt.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Verwenden Sie den Endpunkt und das Anforderungsformat, die für den Dienst dokumentiert sind, der den vorhandenen Arbeitsbereich besitzt. Der angezeigte Vorgang gilt für die profilbewusste Workspace-API; andere APIs verwenden möglicherweise unterschiedliche Rollenzuweisungsschemata. Ersetzen Sie keine Client-ID, wenn der Vorgang eine Objekt-ID eines Dienstprinzipals erwartet. Vermeiden Sie die Protokollierung von Bearer-Token, und lassen Sie die Weitergabe von Berechtigungen zu.

Schritt 5: Authentifizierung und Aufruf von APIs zur Laufzeit

  1. Ermitteln Sie die Anwendungsclient-ID des authentifizierten Kunden und die zulässigen Ressourcen aus der vertrauenswürdigen serverseitigen Konfiguration.

  2. Abrufen eines Assertionstokens mithilfe der ausgewählten vom Benutzer zugewiesenen verwalteten Identität und des api://AzureADTokenExchange/.default Bereichs in der globalen Cloud.

  3. Verwenden Sie das MI-Token als Client assertion für die Kundenanwendung. Fordern Sie ein Zugriffstoken mit dem Anwendungsumfang der Ressourcen-API an, nicht der Assertion-Zielgruppe.

  4. Rufen Sie die Ziel-API mithilfe dieses Zugriffstokens der Kundenanwendung und ohne Profilauswahlkonfiguration auf. Verwalten Sie Arbeitsbereiche, fordern Sie alle erforderlichen anwendungsspezifischen Token an, und führen Sie andere inventarisierten Vorgänge über die Kundenidentität aus.

Verwenden Sie für .NET Azure Identity ClientAssertionCredential mit dem verwalteten Identitätstoken als Assertionsrückruf. Der sechsstufige Ablauf und die offiziellen Konfigurationsbeispiele zeigen den Austausch, ohne dass ein einbettungsspezifisches Anwendungscodebeispiel erforderlich ist.

Onboarding und Offboarding automatisieren

Umschließen Sie die vier Onboardingvorgänge in Ihrer Bereitstellungspipeline: Erstellen Sie die Anwendungsregistrierung, erstellen Sie den Dienstprinzipal, konfigurieren Sie die Verbundvertrauensstellung und weisen Sie die Arbeitsbereichsrolle zu. Erstellen Sie gleichzeitig den entsprechenden Offboardingpfad: Ressourcenerteilungen entfernen, veraltete Vertrauens- oder Anmeldeinformationen widerrufen und Anwendungsidentitäten nur nach der Überprüfung von Abhängigkeiten löschen.

Alternative Implementierung: Dienstprinzipale direkt authentifizieren

Wenn Sie MI und Föderation nicht verwenden möchten, überspringen Sie die Schritte 1 und 3. Führen Sie Schritt 2 für jeden Kunden aus, und konfigurieren Sie eine unterstützte Anmeldeinformation anstelle der Verbundvertrauensstellung.

Verwenden Sie ein Zertifikat, das unterstützt wird, und befolgen Sie die Einrichtungsanleitungen für Anwendungsanmeldeinformationen. Laden Sie das öffentliche Zertifikat hoch, schützen Sie den privaten Schlüssel in einem geeigneten Anmeldeinformationsspeicher, und automatisieren Sie die Verlängerung. Wenn ein Client-Secret erforderlich ist, schützen Sie es und erneuern Sie es vor Ablauf.

Führen Sie Schritt 4 mit denselben minimalen Kundenberechtigungen aus. Verwenden Sie in Schritt 5 die Client-ID des Kunden und die zugehörige Anmeldeinformation, um direkt ein Zugriffstoken für Clientanmeldeinformationen anzufordern. Behalten Sie dasselbe Kundenrouting, die Tokencachetrennung, die Überprüfung und die Migrationsbereinigungssteuerelemente bei.

Sicherheit, Einschränkungen und Überlegungen

Wenden Sie die folgenden Sicherheitsmaßnahmen auf den von Ihnen ausgewählten Authentifizierungspfad an, und planen Sie dessen Betriebsgrenzwerte.

Sicherheitsempfehlungen

  • Verwenden Sie eine stabile, vom Benutzer zugewiesene verwaltete Identität. Dies verhindert, dass das Vertrauen der Kunden nur deshalb verloren geht, weil eine Computeressource ersetzt wird. Verwenden Sie keine vom System zugewiesene Identität als Assertionsquelle für dieses App-Vertrauensmuster.

  • Behandeln Sie die Anwendungs-MI als hoch privilegierte Identität. Sie kann sich als jede Kundenanwendung authentifizieren, die ihr vertraut. Einschränken von Computebereitstellungsrechten, der Zuweisung verwalteter Identitäten, Anwendungsbesitzern und der Anmeldeinformationsverwaltung. Unterteilen Sie Laufzeitidentitäten, wenn erforderlich, um den Kompromittierungsbereich zu reduzieren.

  • Erteilen Sie dem MI keine eigenen Kundendienstberechtigungen. Es handelt sich um eine Anspruchsquelle; Dienstprinzipale erhalten Arbeitsbereichs- und nachgeschaltete Dienstberechtigungen.

  • Mandanteneinstellungen auf eine Sicherheitsgruppe beschränken Schließen Sie jeden relevanten Kundenservice-Dienstprinzipal in die zulässige Gruppe ein, anstatt den Zugriff für Dienstprinzipale für die gesamte Organisation zu aktivieren.

  • Überwachen Sie die Anmeldungen jedes Dienstprinzipals und richten Sie Warnungen dafür ein. Korrelieren Sie mit Anwendungs- und Ressourcenprotokollen. Das Sammeln von Protokollen ohne kundenspezifische Untersuchung und Alarmierung bietet keinen betrieblichen Nutzen.

  • Automatisieren Sie das Onboarding und Offboarding zusammen. Das Entfernen von Arbeitsbereichsrollen, das Aufheben von Anmeldeinformationen oder Vertrauensstellungen und das Löschen veralteter Dienstprinzipale muss so kontrolliert und wiederholbar sein wie ihre Bereitstellung.

Bewahren Sie serverseitige Kundenzuordnungen auf, überprüfen Sie die Mitgliedschaft, bevor Sie eine Identität auswählen, und lehnen Sie beliebige vom Client bereitgestellte Identitäts- oder Ressourcen-IDs ab. Die Wiederverwendung von Token bedeutet, dass ein Anmeldedatensatz keine Aufzeichnung aller API-Aufrufe ist. Protokollieren Sie keine Geheimnisse, Assertionen, Zugriffstoken oder private Zertifikatschlüssel.

Einschränkungen und betriebliche Anforderungen

Consideration Was Sie einplanen sollten
Skalenobergrenze im Vergleich zu Profilen Profile erlauben 100.000 pro übergeordnetem Serviceprinzipal, mit bis zu 1.000 Arbeitsbereichen pro Profil. Dedizierte Anwendungsregistrierungen und Dienstprinzipale belegen Verzeichnisobjekte. Überprüfen Sie Verzeichniskontingente, Arbeitsbereichslimits für Dienstprinzipale und den Bereitstellungsdurchsatz, bevor Sie commiten.
Limit für Verbundanmeldedaten Eine Anwendungsregistrierung unterstützt höchstens 20 Verbundidentitätsanmeldeinformationen. In der Regel benötigt diese Architektur eine pro vertrauenswürdiger, verwalteter Laufzeitidentität in jeder Kundenanwendung, nicht eine pro Kunde in einer freigegebenen Anwendung.
Anforderung: gleicher Mandant Die verwaltete Identität und jede vertrauenswürdige Anwendungsregistrierung müssen demselben Microsoft Entra Mandanten angehören. Der Zugriff auf Ressourcen in einem anderen Mandanten erfordert zusätzlich eine unterstützte Anwendungskonfiguration, Zustimmung und Ressourcenberechtigungen.
Kein cloudübergreifender Tokenaustausch Tauschen Sie keine Token zwischen verschiedenen Azure Clouds aus, z. B. der globalen Cloud und der US Government-Cloud. Verwenden Sie die richtigen Zielgruppen- und Autorisierungsendpunkte in der Zielcloud.
Azure Compute-Anforderung Der mit verwalteter Identität gesicherte Assertionsablauf erfordert den Mechanismus der verwalteten Identität einer unterstützten Azure-Hostingumgebung. Wenn die App an anderer Stelle ausgeführt wird oder Sie dieses Muster nicht verwenden möchten, verwenden Sie die Alternative zur direkten Authentifizierung oder eine andere unterstützte Verbundarchitektur.
Bedingter Zugriff Microsoft Entra Workload ID Premium ist zum Erstellen oder Ändern der Workloadidentitätsrichtlinien für den bedingten Zugriff erforderlich. Richtlinien gelten für berechtigte, organisationsinterne Dienstprinzipale mit Einzelmandantenfähigkeit und müssen direkt auf sie ausgerichtet sein. Sie decken keine verwalteten Identitäten ab oder wirken sich allein aufgrund der Gruppenmitgliedschaft aus.
Einstellungen für Entwickler-Mandanten Jeder Dienstprinzipal, der eine gruppenbezogene Einstellung verwendet, muss sich in der zulässigen Sicherheitsgruppe befinden. Überprüfen Sie die vier Einstellungen in den Implementierungsvoraussetzungen; nehmen Sie keine Standardwerte an.
Automation Die manuelle Verwaltung von Hunderten oder Tausenden von Kundenidentitäten ist unpraktisch. Automatisieren Sie die Bereitstellung, Berechtigungsänderungen, die Überwachung, die Rotation oder Vertrauensaktualisierungen sowie das Offboarding. Behandeln Sie die Drosselung mit begrenzten Wiederholungsversuchen und Backoff.
Ausschließlich delegierte Erfahrungen bleiben außerhalb des Umfangs Durch das Ersetzen von Profilen wird die Nur-App-Authentifizierung nicht aktiviert, wenn eine Workload delegierte Benutzertoken erfordert. Im Real-Time Dashboard-Einbettungsvorschau werden nur dieser Elementtyp und die delegierte Benutzerauthentifizierung unterstützt; Nur-App- und App-owns-data-Token werden nicht unterstützt. Beim Einbetten vorhandener Berichte wird der jeweils anwendbare dienstspezifische Mechanismus verwendet.

Lesen Sie die Microsoft Entra-Dienstgrenzwerte und informieren Sie sich über die API-Identitätsunterstützung des Zieldiensts, bevor Sie Kapazität und Berechtigungen festlegen.

Aktuelle Vertrauensbeschränkungen und Weitergabeverhalten finden Sie unter Überlegungen zu Verbundidentitätsanmeldeinformationen.

Aktuelle Richtlinienberechtigung und -lizenzierung finden Sie unter Bedingter Zugriff für Workloadidentitäten.

Verwenden Sie je nach Bedarf die Audience für den globalen Cloud-Tokenaustausch api://AzureADTokenExchange, die Audience der US-Regierung api://AzureADTokenExchangeUSGov oder die China-Audience api://AzureADTokenExchangeChina. Ordnen Sie den Authority-Endpunkt der Cloud zu. Die Beispiele in diesem Artikel verwenden die globale Cloud.

Verwenden Sie unterstützte Identitätsbibliotheken zum Zwischenspeichern und Aktualisieren von Token. Berücksichtigen Sie die Vertrauens- und Berechtigungsweitergabe, wiederholen Sie vorübergehende Fehler mit begrenztem Backoff und untersuchen Sie anhaltende Abweichungen bei Aussteller, Subjekt oder Zielgruppe. Rotieren Sie für die direkte Authentifizierung Zertifikate und Geheimnisse mit einer Überlappungsphase, und überwachen Sie das Ablaufdatum.

Gehen Sie nicht davon aus, dass das Löschen eines Profils, das Entfernen einer Anmeldeinformation oder das Ändern einer Vertrauensstellung zuvor ausgestellte Token nicht sofort ungültig macht. Berücksichtigen Sie die Tokenlebensdauer und das Autorisierungs- und Sperrverhalten jedes Ressourcendiensts beim Planen der Umstellung und des Offboardings.

Verwandte Inhalte

Verwenden Sie diese Verweise für API-spezifische Berechtigungen, aktuelle Identitätseinschränkungen und vorhandene Workloadkonfigurationen.

Profile, Dienstprinzipale und vorhandene Workloads

Verbundidentität für Workloads und verwaltete Identität

SDKs, APIs und Dienstlimits

  • Zuletzt aktualisiert um