Empfehlungen zu bewährten Methoden für verwaltete Identitäten
Verwaltete Identitäten für Azure-Ressourcen ist eine Funktion von Microsoft Entra ID. Für alle Azure-Dienste, die verwaltete Identitäten unterstützen, gilt ein eigener Zeitplan. Sehen Sie sich den Verfügbarkeitsstatus der verwalteten Identitäten für Ihre Ressource und die bekannten Probleme an, bevor Sie beginnen.
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 | Anmerkungen |
|---|---|---|
| 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. bei der Bereitstellung mehrerer virtueller Computer mit jeweils eigener systemseitig zugewiesener Identität), überschreiten Sie möglicherweise den Grenzwert für die Erstellung von Microsoft Entra-Objekten, und bei der Anforderung tritt ein HTTP 429-Fehler auf. 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. Auf eine gelöschte, vom System zugewiesene Identität kann von keiner Ressource mehr zugegriffen werden, sie wird jedoch auf den Grenzwert angerechnet, bis sie nach 30 Tagen vollständig gelöscht wird. Beim Bereitstellen von Ressourcen, die einer einzelnen vom Benutzer zugewiesenen Identität zugeordnet sind, muss nur ein Dienstprinzipal in Microsoft Entra ID erstellt werden, wodurch ein Überschreiten des Grenzwerts vermieden wird. Die Verwendung einer einzelnen Identität, die im voraus erstellt wird, reduziert auch das Risiko von Replikationsverzögerungen, die auftreten können, wenn mehrere Ressourcen mit jeweils eigener 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. |
| Kompatibilität | Vom Benutzer zugewiesene Identität | Wenn in Ihrer Organisation die gesamte Identitätserstellung einen Genehmigungsprozess durchlaufen muss, sind bei Verwendung einer einzelnen vom Benutzer zugewiesenen Identität für mehrere Ressourcen weniger Genehmigungen erforderlich als bei vom System zugewiesenen Identitäten, die zusammen mit neuen 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 wird eine vom System zugewiesene Identität möglicherweise nicht rechtzeitig erstellt. Daher sollte eine bereits vorhandene vom Benutzer zugewiesene Identität verwendet werden. |
| Ü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 für die Identität der virtuellen Computer mehr Rollenzuweisungen erforderlich sind, werden diese 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 enthält vier virtuelle Computer mit vom System zugewiesenen Identitäten, die einer Sicherheitsgruppe hinzugefügt wurden, wobei die Rollenzuweisungen der Gruppe und nicht den 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 können „Virtueller Computer 3“ und „Virtueller Computer 4“ auf Speicherkonten und Schlüsseltresore zugreifen, je nachdem, welche benutzerseitig zugewiesene Identität sie bei der Authentifizierung verwenden.
Im folgenden Beispiel verfügt „Virtueller Computer 4“ über eine vom Benutzer zugewiesene Identität, die Zugriff auf Speicherkonten und Schlüsseltresore erlaubt, 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, ist es nicht erforderlich, für diese Identität auch Berechtigungen zum Schreiben von Daten in das Speicherkonto zuzulassen. Durch das Erteilen zusätzlicher Berechtigungen wird die verwaltete Identität beispielsweise zu einem 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.
Beachten Sie Folgendes: Wenn einer Azure-Ressource (z. B. Azure Logic-App, Azure-Funktion, VM) eine verwaltete Identität zugewiesen wird, sind alle Berechtigungen, die der verwalteten Identität erteilt wurden, jetzt auch für die Azure-Ressource verfügbar. 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 beispielsweise einer verwalteten Identität (ClientId = 1234) Lese-/Schreibzugriff für StorageAccount7755 erteilt wurde und sie LogicApp3388 zugewiesen wurde, kann Alice, die keinen direkten Zugriff auf das Speicherkonto, aber die Berechtigung zur Ausführung von Code innerhalb von LogicApp3388 hat, ebenfalls Daten aus bzw. in StorageAccount7755 lesen bzw. schreiben, indem sie den Code ausführt, 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.
Wartung
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, selbst wenn ihr keine Ressourcen zugeordnet 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 im Portal mit der Kennzeichnung „Identität nicht gefunden“ angezeigt. Weitere Informationen.
Rollenzuweisungen, die keinem Benutzer oder Dienstprinzipal mehr zugeordnet sind, werden mit einem ObjectType-Wert von Unknown angezeigt. 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 die Gruppen und Rollen der Identität Ansprüche im Zugriffstoken sind, werden alle Autorisierungsänderungen erst durch das Aktualisieren des Tokens wirksam. 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, ziehen Sie Alternativen zur Verwendung von Gruppen oder Rollen im Token in Betracht. 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.