Empfehlungen zu bewährten Methoden für verwaltete Identitäten

Verwaltete Identitäten in Azure bieten eine sichere und bequeme Möglichkeit zum Verwalten von Anmeldeinformationen für Anwendungen, die auf Azure-Ressourcen ausgeführt werden. In diesem Artikel werden empfehlungen für bewährte Methoden für die Auswahl zwischen vom Benutzer zugewiesenen und vom System zugewiesenen verwalteten Identitäten beschrieben, die Ihnen dabei helfen, die Identitätsverwaltung zu optimieren und den Verwaltungsaufwand zu verringern.

Auswählen von system- oder benutzerseitig zugewiesenen verwalteten Identitäten

Vom Benutzer zugewiesene verwaltete Identitäten sind in einer größeren Bandbreite von Szenarien effizienter als vom System zugewiesene verwaltete Identitäten. In der folgenden Tabelle finden Sie einige Szenarien und Empfehlungen für benutzer- oder systemseitig zugewiesene Szenarien.

Vom Benutzer zugewiesene Identitäten können von mehreren Ressourcen verwendet werden, und ihre Lebenszyklen sind von den Lebenszyklen der Ressourcen, denen sie zugeordnet sind, abgekoppelt. Erfahren Sie, welche Ressourcen verwaltete Identitäten unterstützen.

Dank dieses Lebenszyklus können Sie Ihre Aufgaben bei der Ressourcenerstellung und der Identitätsverwaltung trennen. Vom Benutzer zugewiesene Identitäten und deren Rollenzuweisungen können vor den Ressourcen konfiguriert werden, für die sie erforderlich sind. Benutzer, welche die Ressourcen erstellen, benötigen nur den Zugriff zum Zuweisen einer benutzerseitig zugewiesenen Identität und brauchen keine neuen Identitäten oder Rollenzuweisungen zu erstellen.

Da vom System zugewiesene Identitäten zusammen mit der Ressource erstellt und gelöscht werden, können Rollenzuweisungen nicht im voraus erstellt werden. Diese Abfolge kann beim Bereitstellen der Infrastruktur zu Fehlern führen, wenn der Benutzer, der die Ressource erstellt, nicht auch Zugriff zum Erstellen von Rollenzuweisungen hat.

Wenn es in Ihrer Infrastruktur erforderlich ist, dass mehrere Ressourcen auf die gleichen Ressourcen zugreifen müssen, kann ihnen eine einzelne vom Benutzer zugewiesene Identität zugewiesen werden. Der Verwaltungsaufwand wird reduziert, da weniger unterschiedliche Identitäten und Rollenzuweisungen verwaltet werden müssen.

Wenn jede Ressource über eine eigene Identität verfügen muss, oder wenn für Ressourcen ein eindeutiger Berechtigungssatz erforderlich ist und die Identität beim Löschen der Ressource ebenfalls gelöscht werden soll, sollten Sie eine vom System zugewiesene Identität verwenden.

Szenario	Empfehlung	Notizen
Schnelle Erstellung von Ressourcen (z. B. kurzlebiges Computing) mit verwalteten Identitäten	Vom Benutzer zugewiesene Identität	Wenn Sie versuchen, mehrere verwaltete Identitäten in kurzer Zeit zu erstellen – z. B. die Bereitstellung mehrerer virtueller Computer mit einer eigenen vom System zugewiesenen Identität – können Sie die Rategrenze für Die Erstellung von Microsoft Entra-Objekten überschreiten, und die Anforderung schlägt mit einem HTTP 429-Fehler fehl. Wenn Ressourcen schnell erstellt oder gelöscht werden und Sie vom System zugewiesene Identitäten verwenden, überschreiten Sie möglicherweise auch den Grenzwert für die Anzahl der Ressourcen in Microsoft Entra ID. Während auf eine gelöschte vom System zugewiesene Identität nicht mehr von einer Ressource zugegriffen werden kann, zählt sie zu Ihrem Limit, bis sie nach 30 Tagen vollständig gelöscht wurde. Für die Bereitstellung der Ressourcen, die einer einzelnen vom Benutzer zugewiesenen Identität zugeordnet sind, muss nur ein Dienstprinzipal in Microsoft Entra ID erstellt werden, womit die Rate-Limitierung vermieden wird. Die Verwendung einer einzelnen Identität, die im Voraus erstellt wird, reduziert das Risiko von Replikationsverzögerungen, die auftreten können, wenn mehrere Ressourcen jeweils mit ihrer eigenen Identität erstellt werden. Erfahren Sie mehr über die Grenzwerte für den Azure-Abonnementdienst.
Replizierte Ressourcen/Anwendungen	Vom Benutzer zugewiesene Identität	Für Ressourcen, die dieselbe Aufgabe ausführen (z. B. duplizierte Webserver oder identische Funktionen, die in einem App-Dienst und einer Anwendung auf einem virtuellen Computer ausgeführt werden), sind in der Regel dieselben Berechtigungen erforderlich. Durch die Verwendung derselben benutzerseitig zugewiesenen Identität sind weniger Rollenzuweisungen erforderlich, was den Verwaltungsaufwand senkt. Die Ressourcen müssen nicht vom selben Typ sein.
Compliance	Vom Benutzer zugewiesene Identität	Wenn Ihre Organisation erfordert, dass die gesamte Identitätserstellung einen Genehmigungsprozess durchlaufen muss, erfordert die Verwendung einer einzelnen vom Benutzer zugewiesenen Identität über mehrere Ressourcen hinweg weniger Genehmigungen als vom System zugewiesene Identitäten, die als neue Ressourcen erstellt werden.
Zugriff vor dem Bereitstellen einer Ressource erforderlich	Vom Benutzer zugewiesene Identität	Einige Ressourcen benötigen möglicherweise im Rahmen ihrer Bereitstellung Zugriff auf bestimmte Azure-Ressourcen. In diesem Fall kann eine vom System zugewiesene Identität nicht rechtzeitig erstellt werden, sodass eine bereits vorhandene vom Benutzer zugewiesene Identität verwendet werden sollte.
Überwachungsprotokollierung	Vom System zugewiesene Identität	Wenn Sie protokollieren müssen, welche Ressource (und nicht welche Identität) eine Aktion ausgeführt hat, verwenden Sie eine vom System zugewiesene Identität.
Lebenszyklusverwaltung für Berechtigungen	Vom System zugewiesene Identität	Wenn die Berechtigungen für eine Ressource zusammen mit der Ressource entfernt werden müssen, verwenden Sie eine vom System zugewiesene Identität.

Verwenden von benutzerseitig zugewiesenen Identitäten zur Reduzierung der Verwaltung

Die Diagramme veranschaulichen den Unterschied zwischen system- und benutzerseitig zugewiesenen Identitäten, wenn diese verwendet werden, um mehreren virtuellen Computern den Zugriff auf zwei Speicherkonten zu ermöglichen.

Das Diagramm enthält vier virtuelle Computer mit systemseitig zugewiesenen Identitäten. Jeder virtuelle Computer verfügt über dieselben Rollenzuweisungen, die Zugriff auf zwei Speicherkonten erlauben.

Wenn den vier virtuellen Computern eine vom Benutzer zugewiesene Identität zugeordnet ist, sind nur zwei Rollenzuweisungen erforderlich (im Gegensatz zu acht Rollenzuweisungen bei vom System zugewiesenen Identitäten). Wenn die Identität der virtuellen Computer mehr Rollenzuweisungen erfordert, werden sie allen Ressourcen gewährt, die dieser Identität zugeordnet sind.

Sicherheitsgruppen können ebenfalls verwendet werden, um die Anzahl der erforderlichen Rollenzuweisungen zu reduzieren. Dieses Diagramm zeigt vier virtuelle Computer mit vom System zugewiesenen Identitäten, die einer Sicherheitsgruppe hinzugefügt wurden, wobei die Rollenzuweisungen der Gruppe anstelle der vom System zugewiesenen Identitäten hinzugefügt wurden. Das Ergebnis ist zwar ähnlich, aber diese Konfiguration bietet nicht die gleichen Resource Manager-Vorlagenfunktionen wie vom Benutzer zugewiesene Identitäten.

Mehrere verwaltete Identitäten

Ressourcen, die verwaltete Identitäten unterstützen, können sowohl über eine systemseitig als auch über eine oder mehrere benutzerseitig zugewiesene Identitäten verfügen.

Dieses Modell ist so flexibel, dass Sie sowohl eine gemeinsam verwendete, vom Benutzer zugewiesene Identität nutzen als auch bei Bedarf präzise Berechtigungen anwenden können.

Im folgenden Beispiel kann "Virtual Machine 3" und "Virtual Machine 4" auf Speicherkonten und Schlüsseltresor zugreifen, je nachdem, welche vom Benutzer zugewiesene Identität bei der Authentifizierung verwendet wird.

Im folgenden Beispiel verfügt "Virtuelle Maschine 4" über eine vom Benutzer zugewiesene Identität, sodass dieser Zugriff auf Speicherkonten und Key Vaults erhält, je nachdem, welche Identität bei der Authentifizierung verwendet wird. Die Rollenzuweisungen für die vom System zugewiesene Identität sind speziell diesem virtuellen Computer zugewiesen.

Grenzwerte

Informieren Sie sich über die Grenzwerte für verwaltete Identitäten und über benutzerdefinierte Rollen und Rollenzuweisungen.

Befolgen des Prinzips der geringsten Rechte beim Gewähren von Zugriff

Wenn Sie Identitäten, einschließlich einer verwalteten Identität, Berechtigungen für den Zugriff auf Dienste erteilen, erteilen Sie immer die geringsten Berechtigungen, die zum Ausführen der gewünschten Aktionen erforderlich sind. Wenn beispielsweise eine verwaltete Identität zum Lesen von Daten aus einem Speicherkonto verwendet wird, müssen diese Identitätsberechtigungen nicht auch Daten in das Speicherkonto schreiben. Durch das Erteilen zusätzlicher Berechtigungen werden verwaltete Identitäten beispielsweise zu Mitwirkenden in einem Azure-Abonnement, wenn dies nicht erforderlich ist, was den Sicherheitsradius hinsichtlich der Identität erhöht. Der Sicherheitsradius muss immer minimiert werden, damit eine Kompromittierung dieser Identität nur zu geringen Schäden führt.

Berücksichtigen Sie die Auswirkungen der Zuweisung verwalteter Identitäten zu Azure-Ressourcen und/oder der Erteilung von Berechtigungen für Benutzer*innen.

Es ist wichtig zu beachten, dass, wenn einer Azure-Ressource, z. B. einer Azure-Logik-App oder einem virtuellen Computer, eine verwaltete Identität zugewiesen wird, alle Berechtigungen, die der verwalteten Identität gewährt werden, jetzt für die Azure-Ressource verfügbar sind. Dies ist besonders wichtig, denn wenn ein Benutzer Zugriff zum Installieren oder Ausführen von Code für diese Ressource hat, hat der Benutzer Zugriff auf alle Identitäten, die der Azure-Ressource zugewiesen/zugeordnet sind. Der Zweck der verwalteten Identität besteht darin, Code, der in einer Azure-Ressource ausgeführt wird, Zugriff auf andere Ressourcen zu geben, ohne dass Entwickler Anmeldeinformationen verarbeiten oder direkt im Code speichern müssen, um diesen Zugriff zu erhalten.

Wenn z. B. einer verwalteten Identität (ClientId = 1234) Lese-/Schreibzugriff auf StorageAccount7755 gewährt wird und LogicApp3388 zugewiesen ist, kann Alice, der keinen direkten Zugriff auf das Speicherkonto hat, aber über die Berechtigung zum Ausführen von Code in LogicApp3388 verfügt, auch Daten in/aus StorageAccount7755 lesen/schreiben, indem der Code ausgeführt wird, der die verwaltete Identität verwendet.

Wenn Alice über Berechtigungen verfügt, die verwaltete Identität selbst zuzuweisen, kann sie sie einer anderen Azure-Ressource zuweisen und hat Zugriff auf alle Berechtigungen, die für die verwaltete Identität verfügbar sind.

Wenn Sie einem Benutzer Administratorzugriff auf eine Ressource gewähren, die Code ausführen kann (z. B. eine Logik-App) und über eine verwaltete Identität verfügt, sollten Sie im Allgemeinen überlegen, ob die dem Benutzer zugewiesene Rolle Code für die Ressource installieren oder ausführen kann, und wenn ja, sollten Sie diese Rolle nur zuweisen, wenn der Benutzer sie wirklich benötigt.

Maintenance

Vom System zugewiesene Identitäten werden automatisch gelöscht, wenn die Ressource gelöscht wird, während der Lebenszyklus einer vom Benutzer zugewiesenen Identität von keiner Ressource abhängig ist, der sie zugeordnet ist.

Sie müssen eine vom Benutzer zugewiesene Identität manuell löschen, wenn sie nicht mehr benötigt wird, auch wenn keine Ressourcen damit verknüpft sind.

Rollenzuweisungen werden beim Löschen von system- oder benutzerseitig zugewiesenen verwalteten Identitäten nicht automatisch gelöscht. Diese Rollenzuweisungen sollten manuell gelöscht werden, damit der Grenzwert für Rollenzuweisungen pro Abonnement nicht überschritten wird.

Rollenzuweisungen, die gelöschten verwalteten Identitäten zugeordnet sind, werden beim Anzeigen im Portal mit "Identität nicht gefunden" angezeigt. Weitere Informationen

Rollenzuweisungen, die einem Benutzer- oder Dienstprinzipal nicht mehr zugeordnet sind, werden mit einem ObjectType Wert von Unknownangezeigt. Um sie zu entfernen, können Sie mehrere Azure PowerShell-Befehle aneinander weiterverarbeiten, um zuerst alle Rollenzuweisungen zu erhalten und sie nur auf diejenigen zu filtern, die einen ObjectType-Wert von Unknown aufweisen, und diese Rollenzuweisungen dann aus Azure zu entfernen.

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

Einschränkung der Verwendung verwalteter Identitäten für Autorisierungzwecke

Die Verwendung von Microsoft Entra ID-Gruppen zur Zugriffsbewilligung auf Dienste ist eine hervorragende Möglichkeit, den Autorisierungsprozess zu vereinfachen. Die Idee ist einfach: Sie erteilen einer Gruppe Berechtigungen und fügen der Gruppe Identitäten hinzu, so dass sie dieselben Berechtigungen erben. Dies ist ein bewährtes Muster aus verschiedenen lokalen Systemen und funktioniert gut, wenn die Identitäten Benutzer darstellen. Eine weitere Option zur Steuerung der Autorisierung in Microsoft Entra ID ist die Verwendung von App-Rollen, mit denen Sie Rollen deklarieren können, die spezifisch für eine App sind (anstelle von Gruppen, die ein globales Konzept im Verzeichnis sind). Anschließend können Sie den verwalteten Identitäten App-Rollen zuweisen (sowie Nutzern oder Gruppen).

In beiden Fällen, für nicht menschliche Identitäten wie Microsoft Entra-Anwendungen und verwaltete Identitäten, ist der genaue Mechanismus, wie diese Autorisierungsinformationen zu der Anwendung präsentiert werden, heute nicht ideal. Die heutige Implementierung mit Microsoft Entra ID und Azure rollenbasierter Zugriffssteuerung (Azure RBAC) verwendet Zugriffstoken, die von Microsoft Entra ID für die Authentifizierung der einzelnen Identitäten ausgestellt werden. Wenn die Identität einer Gruppe oder Rolle hinzugefügt wird, wird dies als Ansprüche in dem von Microsoft Entra ID ausgestellten Zugriffstoken ausgedrückt. Azure RBAC verwendet diese Ansprüche, um die Autorisierungsregeln zur Zulassung oder Verweigerung des Zugriffs weiter auszuwerten.

Da es sich bei den Gruppen und Rollen der Identität um Ansprüche im Zugriffstoken handelt, werden alle Autorisierungsänderungen erst wirksam, wenn das Token aktualisiert wird. Für einen menschlichen Benutzer ist das in der Regel kein Problem, da ein Benutzer ein neues Zugriffstoken erwerben kann, indem er sich abmeldet und wieder anmeldet (oder darauf wartet, dass die Lebensdauer des Tokens abläuft, die standardmäßig 1 Stunde beträgt). Verwaltete Identitätstoken hingegen werden von der zugrunde liegenden Azure-Infrastruktur aus Leistungs- und Ausfallsicherheitsgründen zwischengespeichert: Die Back-End-Dienste für verwaltete Identitäten verwalten einen Cache pro Ressourcen-URI für etwa 24 Stunden. Das bedeutet, dass es mehrere Stunden dauern kann, bis Änderungen an der Gruppen- oder Rollenmitgliedschaft einer verwalteten Identität wirksam werden. Derzeit ist es nicht möglich, die Aktualisierung des Tokens einer verwalteten Identität vor seinem Ablauf zu erzwingen. Wenn Sie die Gruppen- oder Rollenmitgliedschaft einer verwalteten Identität ändern, um Berechtigungen hinzuzufügen oder zu entfernen, müssen Sie daher möglicherweise mehrere Stunden warten, bis die Azure-Ressource, die die Identität verwendet, den richtigen Zugriff hat.

Wenn diese Verzögerung für Ihre Anforderungen nicht akzeptabel ist, sollten Sie Alternativen zur Verwendung von Gruppen oder Rollen im Token in Betracht ziehen. Um sicherzustellen, dass Änderungen an Berechtigungen für verwaltete Identitäten schnell wirksam werden, empfiehlt es sich, Azure-Ressourcen mithilfe einer vom Benutzer zugewiesenen verwalteten Identität mit Berechtigungen zu gruppieren, die direkt auf die Identität angewendet werden, anstatt verwaltete Identitäten einer Microsoft Entra-Gruppe mit Berechtigungen hinzufügen oder daraus entfernen zu müssen. Eine vom Benutzer zugewiesene verwaltete Identität kann wie eine Gruppe verwendet werden, da sie einer oder mehrere Azure-Ressource(n) zugewiesen werden kann, um sie zu verwenden. Der Zuweisungsvorgang kann mithilfe der Rolle Mitwirkender für verwaltete Identität und der Operator-Rolle für verwaltete Identität gesteuert werden.