Systemseitig vs. benutzerseitig zugewiesene Azure-verwaltete Identitäten: Welche sollten Sie wählen?

Von Mirko Peters · 2026-10-26

Vergleichen Sie systemseitig und benutzerseitig zugewiesene Azure-verwaltete Identitäten. Erfahren Sie, welchen Identitätstyp Sie wählen sollten, um den Verwaltungsaufwand zu reduzieren und sicher zu skalieren.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Die Wahl zwischen systemseitig und benutzerseitig zugewiesenen verwalteten Identitäten in Azure gehört zu den wichtigsten Architekturentscheidungen für Cloud-Sicherheit und Verwaltungsaufwand. Systemseitig zugewiesene Identitäten sind direkt an den Lebenszyklus einer einzelnen Azure-Ressource gebunden. Benutzerseitig zugewiesene Identitäten dagegen sind eigenständige Objekte, die sich über mehrere Ressourcen hinweg nutzen lassen. Das reduziert redundante Rollenzuweisungen deutlich und verhindert in automatisierten Umgebungen Engpässe bei Tokenlimits.

Das Wichtigste in Kürze

• Systemseitig zugewiesene Identitäten werden automatisch zusammen mit ihrer übergeordneten Azure-Ressource erstellt, verwaltet und gelöscht.
• Benutzerseitig zugewiesene Identitäten existieren unabhängig als eigenständige Azure-Ressourcen und lassen sich daher über mehrere VMs, Apps und Funktionen hinweg gemeinsam nutzen.
• Microsoft empfiehlt benutzerseitig zugewiesene Identitäten für die meisten Szenarien mit mehreren Ressourcen, um Verwaltungsaufwand und komplexe Rollenzuweisungen zu minimieren.
• Der Einsatz systemseitig zugewiesener Identitäten in schnell skalierenden oder kurzlebigen Testumgebungen kann dazu führen, dass sich Identitäten ansammeln und Azure-Ratenlimits auslösen.
• Eine einzelne Azure-Ressource kann gleichzeitig eine systemseitig zugewiesene Identität für isolierte Protokollierung und eine oder mehrere benutzerseitig zugewiesene Identitäten für gemeinsam genutzte Workloads verwenden.

Die wesentlichen Unterschiede verstehen

Wenn Sie sichere Cloud-Anwendungen ohne fest codierte Geheimnisse oder Verbindungszeichenfolgen entwerfen, müssen Sie festlegen, wie sich Ihre Workloads bei Microsoft Entra ID authentifizieren. Azure bietet zwei Varianten verwalteter Identitäten: systemseitig und benutzerseitig zugewiesen. Wenn Sie verstehen, wie diese im Hintergrund funktionieren, sparen Sie Ihrem Engineering-Team viele Stunden an Fehlersuche und Wartung.

So funktionieren systemseitig zugewiesene Identitäten

Eine systemseitig zugewiesene verwaltete Identität aktivieren Sie direkt in einer bestimmten Azure-Ressource, etwa einer Azure Virtual Machine, einer App Service-App oder einer Function App. Man kann sich das so vorstellen: Die Identität entsteht mit der Ressource und endet mit ihr. Wenn Sie eine systemseitig zugewiesene Identität auf einer virtuellen Maschine aktivieren, erstellt Azure in Microsoft Entra ID eine Identität, die exakt den Namen dieser Ressource trägt.

Der größte Vorteil dieses Ansatzes liegt in der Einfachheit und der Kopplung des Lebenszyklus. Da die Identität an die Ressource gebunden ist, müssen Sie sich nie um verwaiste Identitäten im Verzeichnis sorgen, nachdem eine virtuelle Maschine außer Betrieb genommen wurde. Löschen Sie die Ressource, entfernt Azure die Identität automatisch. Diese enge Kopplung führt jedoch zu architektonischen Einschränkungen, wenn mehrere Ressourcen dieselben Berechtigungen benötigen.

So funktionieren benutzerseitig zugewiesene Identitäten

Eine benutzerseitig zugewiesene verwaltete Identität wird dagegen zuerst als eigenständige Azure-Ressource angelegt. Sie vergeben einen eigenen Namen, verwalten sie unabhängig innerhalb Ihrer Ressourcengruppen und weisen sie ausdrücklich einem oder mehreren Azure-Diensten zu, die Zugriff benötigen. Da sie nicht an den Lebenszyklus einer einzelnen virtuellen Maschine oder App Service-App gebunden ist, bleibt sie auch dann bestehen, wenn alle zugewiesenen Ressourcen gelöscht werden.

Diese eigenständige Natur verändert, wie Cloud-Architekten die Zugriffsverwaltung im großen Maßstab angehen. Statt Authentifizierung als Eins-zu-eins-Beziehung zwischen einem einzelnen Server und einer Datenbank zu behandeln, ermöglichen benutzerseitig zugewiesene Identitäten Modelle mit vielen Ressourcen pro Identität. Cluster von Microservices teilen sich dann einen einzigen, gut verwalteten Sicherheitskontext.

Administrativer Aufwand und Rollenzuweisungen

Die praktischen Unterschiede zwischen diesen beiden Identitätstypen werden deutlich, wenn man die rollenbasierte Zugriffssteuerung (RBAC) in großen Umgebungen betrachtet. Jedes Mal, wenn Sie einer Identität Zugriff auf ein Speicherkonto, einen Key Vault oder eine Datenbank gewähren, müssen Sie eine Azure-Rollenzuweisung erstellen.

Stellen Sie sich ein typisches Unternehmensszenario vor: Vier virtuelle Maschinen müssen Daten aus zwei separaten Azure-Speicherkonten lesen. Wenn Sie ausschließlich auf systemseitig zugewiesene verwaltete Identitäten setzen, benötigt jede einzelne virtuelle Maschine ihre eigene Identität. Um den Zugriff zu gewähren, müssen Sie acht separate Rollenzuweisungen konfigurieren – eine für jede Maschine auf jedem Speicherkonto. Wenn Sie auf zwanzig virtuelle Maschinen skalieren, wächst die Zahl der Rollenzuweisungen exponentiell und wird zu einem administrativen Albtraum.

Teilen sich dieselben vier virtuellen Maschinen dagegen eine einzige benutzerseitig zugewiesene verwaltete Identität, benötigen Sie insgesamt nur zwei Rollenzuweisungen. Sie erhalten dieselbe präzise Zugriffssteuerung mit einem Bruchteil des Verwaltungsaufwands. Wenn Teammitglieder das Unternehmen verlassen oder die Infrastruktur neu aufgebaut wird, lässt sich ein sauberes Verzeichnis deutlich einfacher pflegen.

Architekturfallen und Sonderfälle

Benutzerseitig zugewiesene Identitäten sind in der Regel effizienter, doch die falsche Wahl des Typs kann versteckte betriebliche Reibungsverluste verursachen. Eine große Gefahr betrifft kurzlebige Compute-Ressourcen oder Umgebungen mit automatischer Skalierung.

Wenn Sie Entwicklungs-, Test- oder containerisierte Umgebungen im Laufe des Tages schnell bereitstellen und wieder entfernen und dabei systemseitig zugewiesene Identitäten verwenden, sammeln sich diese Identitäten in Microsoft Entra ID an, bevor die Bereinigungsroutinen ausgeführt werden. Irgendwann können Organisationen die Ratenbegrenzungen des Azure-Verzeichnisses erreichen, sodass die Plattform neue Ressourcenanforderungen vollständig ablehnt. Wenn Sie eine benutzerseitig zugewiesene Identität für diese kurzlebigen Workloads gemeinsam nutzen, umgehen Sie diese Falle vollständig.

Umgekehrt spielen systemseitig zugewiesene Identitäten in zwei bestimmten Szenarien ihre Stärken aus:

• Nachvollziehbarkeit und Nichtabstreitbarkeit: Wenn Ihre Sicherheitsprotokolle eindeutig belegen müssen, welche genaue virtuelle Maschine eine bestimmte Aktion ausgeführt hat, liefern systemseitig zugewiesene Identitäten diese Zuordnung auf Ebene einzelner Ressourcen, weil jede Ressource ihr eigenes, eindeutiges Verzeichnisobjekt besitzt.
• Strikte Bereinigung im Lebenszyklus: Wenn Compliance-Vorgaben verlangen, dass sämtliche Zugriffsberechtigungen genau in dem Moment entfallen, in dem eine Ressource beendet wird, übernehmen systemseitig zugewiesene Identitäten dies automatisch und ohne manuelles Eingreifen.

Denken Sie daran, dass Sie sich nicht zwingend für eine reine Entweder-oder-Lösung entscheiden müssen. Eine einzelne Azure-Ressource kann sowohl eine systemseitig zugewiesene Identität für private, sensible Vorgänge als auch eine oder mehrere benutzerseitig zugewiesene Identitäten für gemeinsame Unternehmensabläufe besitzen.

Fazit

Die Identitätsverwaltung in der Microsoft-Cloud erfordert einen Ausgleich zwischen betrieblicher Effizienz und strikten Sicherheitsgrenzen. Wenn Sie die betrieblichen Unterschiede zwischen systemseitig und benutzerseitig zugewiesenen Identitäten verstehen, können Sie robuste, skalierbare Architekturen entwerfen, die fest codierte Geheimnisse vermeiden, ohne unnötigen administrativen Ballast zu erzeugen.

Wenn Sie tiefer einsteigen möchten, wie Token ausgestellt werden, wie Azure Key Vault ohne Kennwörter integriert wird und welche typischen Sicherheitsfallen Sie vermeiden sollten, hören Sie sich die vollständige Episode des Podcasts an. Dort erhalten Sie Expertenwissen und praxisnahe Strategien.

Häufige Fragen

Kann eine einzelne Azure-Ressource sowohl systemseitig als auch benutzerseitig zugewiesene verwaltete Identitäten verwenden?

Ja. Eine Azure-Ressource wie eine virtuelle Maschine oder ein App Service kann gleichzeitig eine systemseitig zugewiesene Identität und eine oder mehrere benutzerseitig zugewiesene Identitäten aktiviert haben. So lassen sich dedizierte und gemeinsam genutzte Authentifizierungsstrategien kombinieren.

Was passiert mit einer benutzerseitig zugewiesenen Identität, wenn die Azure-Ressource, an die sie angehängt ist, gelöscht wird?

Anders als systemseitig zugewiesene Identitäten, die automatisch gelöscht werden, sobald ihre übergeordnete Ressource entfernt wird, bleiben benutzerseitig zugewiesene Identitäten als eigenständige Objekte in Azure bestehen, bis ein Administrator sie ausdrücklich löscht.

Warum empfiehlt Microsoft für die meisten Szenarien mit mehreren Ressourcen benutzerseitig zugewiesene Identitäten?

Microsoft empfiehlt benutzerseitig zugewiesene Identitäten vor allem, um den administrativen Aufwand und den Wildwuchs an Rollenzuweisungen zu reduzieren. Wenn Sie eine Identität über mehrere Compute-Ressourcen hinweg teilen, sinkt die Zahl der RBAC-Zuweisungen, die Sie erstellen und pflegen müssen, deutlich.

Verursachen verwaltete Identitäten in Azure Betriebskosten?

Nein, sowohl systemseitig zugewiesene als auch benutzerseitig zugewiesene verwaltete Identitäten sind kostenlose Funktionen von Microsoft Entra ID für Azure-Ressourcen. Für die zugrunde liegenden Rechen- oder Speicherdienste, auf die Sie zugreifen, können jedoch die üblichen Kosten anfallen.