Die Taxonomie der Workload-Identitäten in Entra ID: Service-Principals, Unternehmensanwendungen und andere Formen organisierter Verwirrung

An dieser Stelle wird unser Leitfaden etwas technischer, daher sollten wir die einzelnen Schritte sorgfältig durchgehen.

Das Wichtigste zuerst: Einfach ausgedrückt ist der Begriff „Workload-Identität“ ein Oberbegriff, den Microsoft verwendet, um verschiedene Arten von nicht-menschlichen Identitäten zu beschreiben, die innerhalb von Entra ID zum Einsatz kommen. Diese Identitäten ermöglichen es Anwendungen, Diensten, Cloud-Ressourcen, Automatisierungs-Workloads – und nun auch Agenten –,sich zu authentifizieren und mit anderen Systemen zu interagieren, wobei nur wenig oder gar kein menschliches Eingreifen erforderlich ist.

Hier kommt der wichtige Punkt: Alle Workload-Identitäten, einschließlich der neu eingeführten Agent-Identitätstypen, lassen sich letztendlich auf einen zugrunde liegenden Objekttyp zurückführen: den Service Principal.

Und ehrlich gesagt, das leuchtet ein.

Wie man sich Service-Principals vorstellt

Die servicePrincipal Das „Entity“-Objekt ist wahrscheinlich das flexibelste Identitätsobjekt in Entra ID. Wenn Sie sich dessen Schema über den Microsoft Graph OData-Endpunkt „$metadata“ ansehen, verrät Ihnen allein schon die Anzahl der Eigenschaften, Navigationseigenschaften und gebundenen Aktionen, die dieses Objekt bereitstellt, bereits viel über seine Rolle auf der Plattform.

Diese Service-Principal-Foundation leistet hier im Hintergrund umfangreiche Arbeit. Sie ist mit vielen der Schnittstellen und Subsysteme verbunden, die von Entra ID betrieben werden, um Funktionen wie die Verwaltung von Anmeldedaten, die Erteilung von OAuth-Berechtigungen, die Zuweisung von App-Rollen, Gruppenmitgliedschaften, Eigentumsverhältnisse, die Bewertung des bedingten Zugriffs, RBAC-Mechanismen, die Überwachung sowie die Protokollierung von Anmeldungen zu unterstützen.

Als Microsoft also Agentenidentitäten entwickelte, entschied man sich nicht dafür, eine völlig neue Identitätsprimitive von Grund auf neu zu entwickeln, sondern eine bereits vorhandene zu erweitern.

Wie in der Dokumentation angegeben, gelten für beide agentIdentity¹ und agentIdentityBlueprintPrincipal² Objekte (auf die wir in einem späteren Kapitel näher eingehen werden) sind spezielle Typen von Dienstprinzipalen, die Instanzen der Agentenidentität innerhalb des Microsoft Entra ID-Ökosystems darstellen. In der Praxis bedeutet dies, dass sie die bestehende Architektur der Dienstprinzipale übernehmen, einschließlich der Vorteile, der Kompatibilität mit bestehenden APIs und natürlich auch eines Teils der Komplexität.

An dieser Stelle wird Architektur zu einem sicherheitsrelevanten Faktor.

Ein gutes Beispiel hierfür ist die vor kurzem vom Team von Silverfort veröffentlichte^Erkenntnis³.

Als Microsoft die Rolle „Agent-ID-Administrator“ zur Verwaltung der neuen Steuerungsebene für Agentenidentitäten einführte, wurde dokumentiert, dass deren Geltungsbereich streng auf agentenbezogene Objekte beschränkt sei. In der Praxis hielt diese Abgrenzung jedoch nicht stand. Identitäten, denen ausschließlich diese Rolle zugewiesen war, konnten beliebige Dienstprinzipale übernehmen – einschließlich solcher, die nichts mit Agentenidentitäten zu tun hatten –, indem sie sich selbst als Eigentümer hinzufügten, Anmeldeinformationen zum Dienstprinzipal hinzufügten und sich anschließend als dieses Prinzipal authentifizierten.

Das ist eine vollständige Übernahme durch den Auftraggeber.

Die wahrscheinliche Grundursache lässt sich direkt auf das oben beschriebene Modell zurückführen.

Falls agentIdentity und agentIdentityBlueprintPrincipal Objekte werden auf der Grundlage der servicePrincipal Grundlage muss die Autorisierungsschicht zuverlässig zwischen agentengestützten Dienstprinzipalen und „normalen“ Dienstprinzipalen unterscheiden. Diese Unterscheidung muss explizit durchgesetzt werden.

Dies ist einer der Gründe, warum Microsoft parallel zum neuen Agentenident itätsmodell neue Verzeichnisrollen (Agent-ID-Administrator, Agent-ID-Entwickler und Agent-Registrierungsadministrator) sowie objektspezifische Verwaltungsrollen (Eigentümer, Sponsor und Manager) eingeführt hat.

Konzeptionell sollen diese Rollen die neue, agentenspezifische Oberfläche verwalten:

• Identitäten von Agenten
• Grundsätze für die Identitätsvorlage von Agenten
• Entwürfe für die Identitätsdefinition von Agenten
• Agent-Benutzer

Ihre Berechtigungen sollten auf das Agentenmodell beschränkt sein, nicht auf jeden Dienstprinzipal im Mandanten.

Als interessante und nicht ganz kurze Randbemerkung sei angemerkt, dass das sichtbare RBAC-Modell nicht immer die gesamte Agentenoberfläche klar darstellt. Derzeit verweist die Dokumentation von Microsoft zum „Agent ID Administrator“ auf die übergeordneten agentenbezogenen Aktionen; dabei handelt es sich um Berechtigungseinträge, die festlegen, welche Vorgänge eine Verzeichnisrolle für bestimmte Ressourcentypen ausführen darf.

Auf der Grundlage der offiziellen Dokumentation vermutete Silverfort (zu Recht!), dass Maßnahmen wie microsoft.directory/agentIdentities/owners/update und microsoft.directory/agentIdentityBlueprintPrincipals/owners/update wurde von der integrierten Rolle auf die allgemeine Service-Principal-Steuerungsebene übertragen.

Bei der Abfrage der Live-Rolldefinition über Microsoft Graph sind jedoch die sichtbaren allowedResourceActions scheinen sich ausschließlich auf agentUsers/*.

Und die Aufzählung der deklarierten microsoft.directory Auch bei den Ressourcenaktionen zeigt sich dieselbe Lücke: 18 agentenbezogene Einträge, alle unter agentUsers/*. Keine für die Untertypen der Service-Principal-Ebene (agentIdentities/*, agentIdentityBlueprintPrincipals/*, und agentIdentityBlueprints/*). Das bedeutet im Grunde genommen, dass keine Rolle über solche verfügt.

Eine ähnliche Feststellung gilt auch für die Rolle des KI-Administrators.

Im Gegensatz zum „Agent ID Administrator“, der den Eindruck einer sehr spezifischen Rolle für die Verwaltung der Agent-ID-Steuerungsebene vermittelt, wird die Rolle des „AI Administrator“ mit größerer Wahrscheinlichkeit breit gefächert delegiert. Die dokumentierten Aufgaben konzentrieren sich auf Microsoft 365 Copilot, KI-Dienste, Copilot-Agenten, Nutzungserkenntnisse, den Zustand der Dienste sowie Support-Aktivitäten.

Mit anderen Worten: Es klingt eher nach einer Rolle im Bereich des KI-Betriebs als nach einer vollständigen Kontrolle über die zugrunde liegende Identitätsebene der Agent-ID.

In der Praxis scheint die Rolle jedoch nahezu identische Funktionen in der Steuerungsebene für die Agent-ID zu besitzen wie der Agent-ID-Administrator. Bei allen 17 von uns getesteten Vorgängen ergaben sich für beide Rollen identische Ergebnisse. Das bedeutet, dass jeder, der die Rolle des AI-Administrators innehat, die Eigentumsrechte an jeder Agentenidentität im Mandanten übernehmen, Anmeldedaten in jeden Blueprint einfügen und alle Anwendungsberechtigungen erben kann, die Administratoren diesen Blueprints gewährt haben.

Obwohl die beiden Rollen leicht unterschiedliche allowedResourceActions, und obwohl beide von der Basisklasse „Directory Readers“ erben, von der fast jede privilegierte Rolle erbt (was 55 schreibgeschützte Aktionen beiträgt), beschränkt sich der tatsächliche Unterschied auf die folgenden Aktionen:

Diese Details sind zwar nicht in der Silverfort-Analyse selbst enthalten, sind jedoch im Kontext hilfreich. Sie zeigen, dass ein Teil der Kontrollebene für die Agentenidentität nicht als klares, vollständig sichtbares RBAC-Vokabular dargestellt wird. Ein Teil der Zugriffsrechte für agentenbezogene Objekte scheint tiefer in der API-Ebene durchgesetzt zu werden (z. B. Endpunkt-spezifische Sicherheitsmaßnahmen, an Template-IDs gebundene Überschreibungen, dynamische Laufzeitprüfungen). Dies erklärt auch, warum Anwendungsobjekte nicht betroffen waren, da die Lücke nicht im Bereich der Eigentumsverwaltung lag.

Und damit sind wir wieder beim Thema Sicherheit angelangt.

Die Vererbung verleiht Identitätssystemen ihre Flexibilität, Konsistenz und Wiederverwendbarkeit. Ohne präzise Abgrenzungen des Geltungsbereichs kann sie jedoch auch die Angriffsfläche auf alle beteiligten Objekte ausweiten.
Die Vererbungshierarchie ist jedoch nur eine Variante des Service-Principal-Modells. Service-Principals basieren nicht nur auf derselben zugrunde liegenden Objektarchitektur, sondern werden auch logisch in verschiedene Identitätstypen eingeteilt.

Typen logischer Dienstprinzipale – und wo sie versagen

Im vergangenen Jahr hatte ich die Gelegenheit, auf Reisen EntraGoat vorzustellen – ein Open-Source-Labor, das wir bei Semperis bewusst anfällig gestaltet haben, um reale Angriffspfade auf Identitätsdaten in Microsoft Entra ID zu veranschaulichen und zu üben.

Das Feedback war großartig, doch am meisten sind mir die anschließenden Gespräche in Erinnerung geblieben. Ein Thema tauchte immer wieder auf: Anwendungen und Service-Principals sind weitaus komplexer, als sie auf den ersten Blick erscheinen.

An dieser Stelle möchten wir diese Komplexität näher beleuchten und etwas Licht auf die Angriffe werfen, denen diese Identitäten ausgesetzt sind.

Der Typ eines Dienstprinzipals lässt sich anhand des servicePrincipalType Eigenschaft enum, die Entra ID intern vergeben hat, um die logische Kategorie der Identität anzugeben.

Laut Microsoft Dokumentation für die servicePrincipal Ressourcentyp, dieses Feld kann fünf Hauptwerte enthalten:

• Anwendung
• ManagedIdentity
• Vermächtnis
• SocialIdp
• ServiceIdentity

Meiner Erfahrung nach gehören diese Identitäten zu den einflussreichsten Objekten in Entra ID und stehen häufig im Mittelpunkt kritischer Zugriffspfade.

Um zu verstehen, wie Entra ID unter der Haube tatsächlich funktioniert, ist es unerlässlich zu wissen, wie sich diese Arten von Dienstprinzipalen verhalten, woher sie stammen, wie sie sich authentifizieren und worin sie sich voneinander unterscheiden.

Die 5 wichtigsten Werte von Service Principal in Entra ID verstehen

Lassen Sie uns damit beginnen, die Typen der logischen Dienstprinzipale in der Identitätslandschaft der Workloads zu erfassen.

Ein großes Dankeschön an Eric Woodruff, Chief Identity Architect bei Semperis, der diese Taxonomie ursprünglich entdeckt und uns vorgestellt hat.

Anwendungen

Wie im obigen Diagramm zu den Workload-Identitäten dargestellt, stammt die erste Gruppe, die Service-Principals in einem Entra ID-Mandanten initiiert, aus den Anwendungen, die wir alle nutzen und kennen, wie beispielsweise Microsoft Teams, Salesforce oder intern entwickelte Systeme wie ein HR-Portal.

Ein „Application“-Objekt stellt die globale Definition einer Anwendung dar. Es wird in dem Mandanten erstellt, in dem die Anwendung ursprünglich angelegt wurde (einsehbar in der Benutzeroberfläche für App-Registrierungen ), und dient als Blaupause oder Vorlage, die die Identitätskonfiguration der Anwendung definiert, einschließlich Umleitungs-URIs, erforderlicher API-Berechtigungen, Anmeldeinformationen und weiterer Einstellungen. Das bedeutet, dass das Objekt beschreibt, wie der Identitätsanbieter (IdP) Token ausstellen kann, die es Clients ermöglichen, auf die Anwendung zuzugreifen, welche Ressourcen die Anwendung möglicherweise benötigt und welche Aktionen oder Berechtigungen die App innerhalb eines Mandanten ausführen kann.

Um all dies zu ermöglichen und zu integrieren – und wie Sie am API-Endpunkt „$metadata“ sehen können –, ist das Anwendungsobjekt ebenfalls ein komplexes Objekt (das für die Identitäten der Agenten von großer Bedeutung ist!) mit vielen verschiedenen Eigenschaften und Methoden.

A Service-Principal-Objekt mit servicePrincipalType : application stellt die Instanz dieser Anwendung innerhalb eines bestimmten Mandanten dar und kann in der Unternehmensanwendungen UI. Dies ist das Sicherheitsprinzip, das Entra ID tatsächlich bei Authentifizierungs- und Autorisierungsabläufen anwendet.

Der Dienstprinzipal ermöglicht es der Anwendung, sich anzumelden oder auf Ressourcen innerhalb dieses Verzeichnisses zuzugreifen, und speichert mandantenspezifische Daten wie erteilte Berechtigungen, die Zustimmung des Administrators und die Zuweisung von App-Rollen. Das bedeutet, dass der Dienstprinzipal das Objekt ist, das Tokens erhält, über Berechtigungen verfügt, in den Anmeldeprotokollen erscheint –und das Ziel von Angriffen ist.

Was ist der Unterschied zwischen Anwendungen und Dienstprinzipalen?

Unserer Erfahrung nach gehört die Unterscheidung zwischen Anwendungsobjekten und Dienstprinzipalobjekten zu den Konzepten, die in Entra ID am häufigsten missverstanden werden.

Um den Unterschied zu verdeutlichen, haben wir die folgenden Beispiele aufgeführt, die zeigen, inwiefern sie miteinander zusammenhängen, obwohl sie sich doch deutlich voneinander unterscheiden. Wenn Sie mit dem Thema bereits vertraut sind, können Sie die Aufzählungspunkte gerne überfliegen.

• Ein Anwendungsobjekt existiert ausschließlich in seinem Heimat-Tenant.
• Eine Single-Tenant-Anwendung verfügt über genau einen Dienstprinzipal, der ausschließlich im selben (Heimat-)Mandanten existiert.
• Wenn in einem fremden Mandanten die Zustimmung für eine mandantenübergreifende Anwendung erteilt wird, wird dort lediglich ein Dienstprinzipal angelegt, jedoch kein Anwendungsobjekt.
• Die appId Die Eigenschaft (Anwendungs-ID / Client-ID) identifiziert die Definition des Anwendungsobjekts und ist weltweit eindeutig über alle Entra-ID-Mandanten hinweg. Er wird bei der Erstellung zugewiesen und ändert sich nie.
• Die appId Die Eigenschaft eines Dienstprinzipals stimmt stets mit der appId des zugehörigen Anwendungsobjekts. Aus diesem Grund nutzt dieselbe First-Party-App (wie beispielsweise Microsoft Graph) dieselbe appId für alle Mieter weltweit.
• Jedes Dienstprinzipal verfügt über ein eigenes id (Objekt-ID), die innerhalb des Mandanten, in dem sie vorhanden ist, eindeutig ist.
• App-Rollenzuweisungen und OAuth2-Berechtigungserteilungen werden dem Dienstprinzipal zugewiesen, nicht dem Anwendungsobjekt; daher können zwei Mandanten derselben App mit völlig unterschiedlichen Berechtigungsumfängen zustimmen.
• Anmeldedaten, die direkt einem Dienstprinzipal hinzugefügt werden, gelten ausschließlich für diesen bestimmten Mandanten und können außerhalb dieses Mandanten nicht verwendet werden.
• An das Anwendungsobjekt angefügte Anmeldeinformationen werden von allen Dienstprinzipalen in allen Mandanten übernommen, in denen die App zugelassen ist, was einen mandantenübergreifenden Angriffsvektor ermöglicht.
• Das Löschen eines Service-Principal-Objekts in einem Mandanten hat keine Auswirkungen auf das Anwendungsobjekt (und auch nicht auf die Service-Principals in anderen Mandanten), da der Lebenszyklus jedes Service-Principals unabhängig ist.
• Durch das Löschen des Anwendungsobjekts im Heim-Tenant wird die Dienstinstanz des Heim-Tenants automatisch entfernt; Dienstinstanzen in anderen Tenants werden jedoch nicht entfernt (diese bleiben bestehen, bis sie ausdrücklich gelöscht werden).
• Bis zum 1. April 2026 sowie in bestimmten Sonderfällen konnten Sie eine Anwendung nutzen, ohne eine Dienstinstanz anzulegen; diese „Authentifizierung ohne Dienstinstanz“ sollte jedoch nicht mehr unterstützt werden.

Arten von Anwendungsobjekten

Alle anwendungsgestützten Dienstprinzipale stammen in der Regel aus einer von drei logischen Anwendungskategorien.

Anwendungstypen identifizieren

Microsoft-First-Party-Anwendungen sind Anwendungen, die Microsoft gehören und von Microsoft betrieben werden und Azure- sowie M365-Dienste wie Exchange Online, SharePoint, Microsoft Graph und Hunderte weitere bereitstellen. Sie werden in Ihrem Mandanten angezeigt, wenn ein Benutzer ihnen zustimmt, ein Administrator ihnen Zugriff gewährt oder Microsoft sie automatisch bereitstellt, sobald ein Dienst oder eine Lizenz aktiviert wird (z. B. E5, Defender oder Intune).

Um diese Arten von Workload-Identitäten zu ermitteln, können Sie einfach die appOwnerOrganizationId GUID-Eigenschaft eines Service-Principal-Objekts. Bei Microsoft-eigenen Apps ist diese Eigenschaft in der Regel auf die Mandanten-ID von Microsoft gesetzt (f8cdef31-a31e-4b4a-93e4-5f571e91255a), wobei einige jedoch andere, Microsoft gehörende Mandanten-IDs verwenden.

Es ist wichtig zu wissen, dass die meisten First-Party-Dienstprinzipale zwar in den Anmeldeprotokollen erscheinen mögen, standardmäßig jedoch in der Benutzeroberfläche „Enterprise Applications“ im Azure-Portal ausgeblendet sind, aber dennoch über die Graph-API abgefragt werden können.

Dies liegt daran, dass der UI-Blade nach dem WindowsAzureActiveDirectoryIntegratedApp Tag, das in der Regel Apps kennzeichnet, die in Entra ID integriert sind; die eigenen Service-Principals von Microsoft verfügen jedoch (absichtlich) nicht darüber.

Darüber hinaus nutzen Microsoft-eigene Apps interne Autorisierungsmechanismen, die über die Standard-OAuth-Bereiche hinausgehen. Das bedeutet, dass ihre tatsächlichen Berechtigungen möglicherweise über das hinausgehen, was über die erteilten Berechtigungen ersichtlich ist, und dass sie nicht vollständig über Standardabfragen der Graph-API überprüft werden können.

Die nächste logische Kategorie von Anwendungsobjekten sind Ihre eigenen Anwendungen, auch bekannt als Registrierungsanwendungen.

Hierbei handelt es sich um Anwendungen, die direkt von Administratoren oder Entwicklern über die Funktion „App-Registrierungen“ registriert wurden. In diesem Fall ist die Organisation Eigentümerin des Anwendungsobjekts und kann dessen Konfiguration, Anmeldeinformationen und Berechtigungen vollständig steuern. Bei der Registrierung wird automatisch ein entsprechender Dienstprinzipal im Home-Tenant erstellt.

Um Dienstprinzipale zu erfassen, die aus von unserer Organisation registrierten Anwendungen erstellt wurden – ähnlich wie wir Microsoft-Eigenanwendungen filtern –, können wir alle Dienstprinzipale auflisten, deren appOwnerOrganizationId ist auf unsere Mandanten-ID gesetzt.

Der letzte logische anwendungsgestützte Typ ist „Anwendungen von Drittanbietern/Galerie-Anwendungen“.

Hierbei handelt es sich um SaaS-Anwendungen, die über die Microsoft Entra App Gallery integriert werden, wie beispielsweise Salesforce, ServiceNow oder Zoom. Wie bereits weiter oben in diesem Kapitel erläutert, wird bei der Einbindung einer dieser Anwendungen in einen Mandanten lokal ein Dienstprinzipal (der auf das Multi-Tenant-Anwendungsobjekt des Anbieters verweist) erstellt.

Um Dienstprinzipale zu identifizieren, die von Anwendungen von Drittanbietern erstellt wurden – also von Anwendungen, die nicht in unserem Mandanten registriert sind und nicht zu Microsoft gehören –, können wir auf der Client-Seite einfach sowohl unsere Mandanten-ID als auch die Mandanten-ID von Microsoft aus der Gesamtheit der Dienstprinzipale ausschließen (da Microsoft Graph dies nicht unterstützt ne Filter aktiviert appOwnerOrganizationId).

Sicherheitslücke in einer Anwendung

Wie wir bereits (mittlerweile wahrscheinlich schon zu oft) erwähnt haben, instanziiert jeder dieser drei Anwendungstypen ein lokales Service-Principal-Objekt in Ihrem Mandanten. Das Service-Principal ist die Laufzeitidentität: Es enthält die Berechtigungszuweisungen, die SSO-Konfiguration sowie die protokollspezifischen Einstellungen, die Entra ID zum Zeitpunkt der Authentifizierung durchsetzt.

Durch die Untersuchung der preferredSingleSignOnMode Anhand der Eigenschaft des Service-Principal-Objekts ermittelt Entra ID, welches SSO-Protokoll die Anwendung verwendet. Die möglichen Werte sind:

• saml: Die Anwendung nutzt SAML 2.0, wobei Entra ID als Identitätsanbieter fungiert und signierte SAML-Assertions ausstellt.
• oidc: Die Anwendung nutzt OpenID Connect / OAuth 2.0, das moderne tokenbasierte Protokoll.
• Passwort: Passwortbasiertes SSO, bei dem Entra ID die Anmeldedaten im Namen des Benutzers in das Anmeldeformular der Anwendung einfügt.
• notSupported: Über Entra ID ist kein SSO konfiguriert.
• null: Bezeichnet ältere SAML-Anwendungen oder OIDC-Anwendungen, bei denen der Wert nicht automatisch festgelegt wurde; wird auch für andere logische Typen von Dienstprinzipalen verwendet (wie wir gleich sehen werden).

Aus Sicherheitssicht hat der SSO-Modus direkte Auswirkungen. SAML-Anwendungen stützen sich auf ein Zertifikat zur Token-Signierung, das auf dem Service-Principal selbst konfiguriert ist. Erlangt ein Angreifer Zugriff auf den privaten Schlüssel dieses Zertifikats, kann er SAML-Assertions fälschen und sich als beliebiger Benutzer authentifizieren, dem die Anwendung vertraut.

Forscher von Semperis haben genau dieses Szenario im Forschungsblog „Meet Silver SAML: Golden SAML in the Cloud“ veranschaulicht und dabei aufgezeigt, dass der Import eines extern generierten Signaturzertifikats in eine Dienstinstanz (anstelle der Verwendung des in Entra ID integrierten selbstsignierten Zertifikats) einen ausnutzbaren Angriffsvektor schafft, der keinerlei Interaktion mit Entra ID erfordert.

Probieren Sie es selbst in EntraGoat aus

Da nichts so anschaulich verdeutlicht, wie Service-Principals die heutige Landschaft der Identitätsbedrohungen prägen, wie die Beobachtung dieses Vorgangs im Labor, basieren einige der wirkungsvollsten Wege zur Privilegieneskalation in EntraGoat – dem bewusst anfällig gestalteten Entra ID-Labor, das wir hier bei Semperis aufgebaut haben – vollständig auf diesen Prinzipalen.

Die Szenarien unterscheiden sich zwar hinsichtlich ihres Ausgangspunkts und ihrer Vorgehensweise, doch das Muster ist bewusst einheitlich: Findet man einen Weg zu einem anwendungsbasierten Dienstprinzipal, ist der Weg zu einer mandantenweiten Kompromittierung in der Regel kürzer, als man erwartet.

Wenn Sie sehen möchten, wie das von Anfang bis Ende aussieht, ist EntraGoat ein guter Ausgangspunkt. Lesen Sie mehr dazu und folgen Sie den Anleitungen in unserer Blog-Reihe.

Verwaltete Identitäten

„Managed Identities“ sind gewissermaßen der Versuch von Microsoft, ein Problem zu lösen, das wir selbst geschaffen haben: die Verwaltung von Anmeldedaten.

Jede Identität – und insbesondere jede nicht-menschliche Identität –, die sich über Client-Geheimnisse (Passwörter, Zugriffsschlüssel oder Zertifikate) authentifiziert, bringt Herausforderungen hinsichtlich des Lebenszyklus dieses Geheimnisses mit sich (Rotation, Speicherung, Ablauf und Verlust). Bei der Implementierung von verwalteten Identitäten wurde versucht, diesen Aufwand zu beseitigen, indem die Verwaltung der Anmeldedaten vollständig in die Azure-Steuerungsebene verlagert wurde. Die Identität existiert; sie authentifiziert sich, aber kein Mensch kommt jemals mit den damit verbundenen Anmeldedaten in Berührung (oder geht unsachgemäß damit um).

Arten von verwalteten Identitäten

Jede Ressource, die die Entra-ID-Authentifizierung unterstützt (wie beispielsweise eine virtuelle Maschine, ein App Service, eine Logic App, ein Kubernetes-Cluster sowie viele weitere Azure-Dienste und Ressourcentypen), kann verwaltete Identitäten nutzen, um Token zu erhalten und auf andere Ressourcen zuzugreifen.

Es gibt zwei Arten:

• Vom System zugewiesene verwaltete Identitäten werden als Teil und im Kontext der Azure-Ressource selbst erstellt. Das Verhältnis ist streng 1:1. Eine Ressource, eine Identität, ein Lebenszyklus. Die Identität kann nicht eigenständig existieren, nicht gemeinsam genutzt werden und wird automatisch gelöscht, wenn die Ressource gelöscht wird. Diese enge Kopplung ist zugleich ihr wesentlicher Sicherheitsvorteil.
• Benutzerzugewiesene verwaltete Identitäten sind hingegen eigenständige Azure-Ressourcen. Sie können einer oder mehreren Ressourcen zugeordnet werden, und ihr Lebenszyklus ist unabhängig von den Ressourcen, die sie nutzen. Diese Entkopplung der benutzerzugewiesenen verwalteten Identität stellt den betrieblichen Vorteil dar – und natürlich auch den Kompromiss in puncto Sicherheit.

Identifizierung von verwalteten Identitäten

Das Identifizieren von Service-Principals, die verwaltete Identitäten in Entra ID repräsentieren, ist recht unkompliziert. Wir können einfach das Verzeichnis nach den servicePrincipalType Eigenschaft festgelegt auf ManagedIdentity.

Im Hintergrund erfolgt die Authentifizierung bei beiden Identitätsarten über von Azure verwaltete Endpunkte – wie beispielsweise den Instance Metadata Service (IMDS) bei 169.254.169.254—oder über Identitäts-Endpunkte, die von Diensten wie App Service und Functions bereitgestellt werden. Der Ablauf der Token-Bezugs ist vollständig lokal in Azure abgewickelt, und es werden keine Geheimnisse über das Netzwerk übertragen; es werden keine Anmeldedaten in Key Vault gespeichert (oder schlimmer noch, in appsettings.json), oder gar den Entwicklern zugänglich gemacht.

Im Gegensatz zu anwendungsgestützten Dienstprinzipalen sind verwaltete Identitäten nicht mit einem Anwendungsobjekt im Verzeichnis verknüpft, sodass es keine App-Registrierung, kein Manifest und keine Umleitungs-URIs gibt. Sie sind zudem nicht benutzersichtbar und nehmen an keinen SSO-Protokollen teil.

Erinnern Sie sich an das preferredSingleSignOnMode die Eigenschaft, über die wir zuvor gesprochen haben? Wir hoffen, dass Sie nun verstehen, warum diese und andere authentifizierungsspezifische Eigenschaften bei verwalteten Identitäten in der Regel den Wert „null“ annehmen. Die Authentifizierung erfolgt bei diesen Identitäten nicht über SAML, OIDC oder passwortbasierte Abläufe. Stattdessen stellt Azure für jede verwaltete Identität Zertifikate mit einer Gültigkeitsdauer von 90 Tagen aus, verwaltet diese und erneuert sie alle 45 Tage.

Diese Zertifikate werden ausgestellt von Microsoft.ManagedIdentity und die Objekt-ID des Managed-Identity-Service-Prinzipals in den Zertifikatsbetreff aufzunehmen. Azure nutzt diese, um eine zertifikatsbasierte Authentifizierung durchzuführen und Token direkt über seine Steuerungsebene auszustellen, ohne Anmeldedaten gegenüber dem Mandanten (oder dessen Administratoren) offenzulegen.

Ein Teil dieses Mechanismus lässt sich anhand der keyCredentials Eigenschaft des Service-Principal-Objekts der verwalteten Identität.

Im Gegensatz zu anwendungsgestützten Dienstprinzipalen, bei denen keyCredentials Enthält in der Regel Zertifikate, die von einem Administrator oder Entwickler hochgeladen wurden; bei verwalteten Identitäten werden die Schlüsseldaten vollständig von Azure bereitgestellt und regelmäßig aktualisiert.

Und bei der Abfrage der Eigenschaft wird tatsächlich ein AsymmetricX509Cert Eintrag, bei dem die Option „Verwendung“ auf „Überprüfen“ gesetzt ist und die ID des Dienstprinzipalobjekts als Zertifikatsbetreffender angegeben ist.

Dieses Design ist elegant – solange man es nicht aus der Perspektive eines Angreifers betrachtet.

Angriffe auf verwaltete Identitäten

Es gibt zwei unterschiedliche Missbrauchsmuster, deren Verständnis lohnenswert ist, da sie verdeutlichen, wie das Modell an seine Grenzen stößt, sobald die Theorie auf die Anforderungen der Realität trifft.

Der erste Fall ist der Diebstahl von Token über die angehängte Ressource.

Da verwaltete Identitäten über lokale Endpunkte (IMDS oder den Identitätsendpunkt der Plattform) authentifiziert werden, kann jeder Prinzipal mit Zugriffsrechten (d. h. mit der Möglichkeit, Code auf der zugrunde liegenden Ressource auszuführen) im Namen der verwalteten Identität ein Token anfordern.

Dies ist der klassische, gut dokumentierte Angriffsvektor:

1. Kompromittieren Sie einen Benutzer mit Zugriff auf eine VM, ein Container-Registry, Arc, AKS, Automatisierungskonten, App Services, Logic Apps, Bereitstellungsskripte oder Data Factory
2. Rufen Sie den Token-Endpunkt auf irgendeine Weise ab (Invoke-WebRequest 169.254.169.254/metadata/identity/oauth2/token)

Sollte diese Abfrage ein Ergebnis liefern, verfügen Sie nun über ein gültiges OAuth-Token, dessen Geltungsbereich sich auf die Berechtigungen erstreckt, über die diese Identität für die Nutzung der Azure-APIs verfügt.

Diese Technik gilt zwar sowohl für vom System zugewiesene als auch für vom Benutzer zugewiesene verwaltete Identitäten, doch die Angriffsfläche skaliert direkt mit dem Kontext der Identität.

Bei benutzerzugewiesenen verwalteten Identitäten, die von mehreren Ressourcen gemeinsam genutzt werden, kann eine einzige kompromittierte Identität dazu verwendet werden, Token für jede Ressource anzufordern, für die sie über Berechtigungen verfügt. Ein klassischer Fall von lateraler Bewegung.

Oder wie es auf Microsoft Learn kurz erläutert wird:

Die Sicherheitsgrenze von verwalteten Identitäten für Azure-Ressourcen ist die Ressource, in der die Identität verwendet wird. Jeder Code und jedes Skript, das auf einer virtuellen Maschine ausgeführt wird, kann Token für alle darauf verfügbaren verwalteten Identitäten anfordern und abrufen.

Das zweite Missbrauchsmuster ist der Missbrauch von föderierten Anmeldedaten, der das Vertrauensmodell hinter verwalteten Identitäten untergräbt.

Wie wir soeben gesehen haben, unterstützen benutzerzugewiesene verwaltete Identitäten keine Konfiguration herkömmlicher Anmeldedaten; es ist ausdrücklich untersagt, diese Eigenschaften an der Dienstinstanz, die die verwaltete Identität in Entra ID repräsentiert, zu ändern. Sie unterstützen jedoch Anmeldedaten für Verbundidentitäten. Diese ermöglichen es externen Identitätsanbietern (wie GitHub Actions oder jedem OIDC-konformen Aussteller, einschließlich selbst gehosteter Anbieter), sich ohne Austausch von Geheimnissen als die verwaltete Identität zu authentifizieren.

Wir werden hier nicht allzu sehr auf die Implementierungsdetails eingehen, da dieses Kapitel bereits weit genug abgeschweift ist, aber auf einer allgemeinen Ebene lässt sich dies durch die Erstellung eines federatedIdentityCredential Objekt auf dem Dienstprinzipal der verwalteten Identität über die ARM-API, wobei eine OIDC-Aussteller-URL und eine Subjektkennung anzugeben sind.

Bei der Authentifizierung überprüft Entra ID dann das externe Token anhand des konfigurierten Ausstellers und gleicht es mit dem Subject-Claim ab. Die Eigentumsbeziehung zwischen dem Aussteller und dem Mandanten oder der Ressource der verwalteten Identität wird dabei jedoch nicht überprüft.

Das bedeutet, dass jeder Auftraggeber mit dem Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write Ein Benutzer mit der Berechtigung „action“ im Azure-RBAC-Berechtigungsmodell (das mehrere integrierte Rollen wie „Contributor“, „Owner“ und „Managed Identity Contributor“ umfasst) kann eine neue föderierte Anmeldeinformation hinzufügen, die auf ein externes Repository oder eine Umgebung verweist, die er verwaltet.

Sobald diese Anmeldeinformationen konfiguriert sind, authentifiziert sich der Angreifer über seinen eigenen GitHub-Workflow (oder eine beliebige OIDC-konforme Umgebung), erhält ein gültiges Token für die verwaltete Identität und kann mit deren vollständigen Berechtigungen arbeiten (und zwar vollständig außerhalb der Azure-Ressourcengrenze).

In beiden Fällen ist das Kernproblem dasselbe: Verwaltete Identitäten wurden entwickelt, um das Risiko durch Anmeldedaten innerhalb einer Ressourcengrenze zu beseitigen, doch das Azure-eigene Berechtigungsmodell ermöglicht es, diese Grenze durch jeden, der über ausreichende RBAC-Zugriffsrechte verfügt, zu erweitern (oder gänzlich zu umgehen).

Die Identität ist dafür vorgesehen, innerhalb eines bestimmten Laufzeitkontexts zu existieren, doch der Zugriff darauf bleibt nicht immer auf diesen Kontext beschränkt. Im ersten Fall kann der Zugriff erlangt werden, indem man die Codeausführung auf einer Ressource erlangt, an die die verwaltete Identität gebunden ist. Im zweiten Fall kann der Zugriff über eine föderierte Vertrauensbeziehung erfolgen, die keinerlei tatsächliche Verbindung zur ursprünglichen Azure-Ressource erfordert.

Legacy- und SocialIdp-Identitäten

Die nächsten beiden Arten von Service-Principal-Identitäten sind „Legacy“ und „SocialIdP“. Da beide für den Hauptzweck dieses Leitfadens weniger relevant sind, werden wir nur kurz darauf eingehen.

Der Typ „Legacy“ bezieht sich auf ältere Anwendungen, die vor Einführung des modernen App-Registrierungsmodells oder über veraltete Benutzeroberflächen erstellt wurden. Die appId Die Eigenschaft ist vorhanden, verweist jedoch nicht auf eine App-Registrierung. Ein Legacy-Dienstprinzipal kann weiterhin Anmeldeinformationen und Antwort-URLs enthalten, die von Administratoren direkt verwaltet werden können, und er kann nur in dem Mandanten verwendet werden, in dem er erstellt wurde.

Der Typ „SocialIdp“ wird von Microsoft als „für den internen Gebrauch“ dokumentiert, sodass nur wenige öffentliche Informationen dazu verfügbar sind. Ausgehend von seinem Namen und seinem Verwendungskontext steht er wahrscheinlich für Social-Identity-Provider (wie Google oder Facebook), die für B2C-Benutzerabläufe konfiguriert sind. In der Praxis ermöglicht dieser Typ die Verbundbildung zwischen B2C und externen Social-Identity-Providern; in der Regel werden Sie jedoch nicht direkt mit ihm interagieren, es sei denn, Sie arbeiten mit benutzerdefinierten B2C-Richtlinien.

ServiceIdentity: Der Dienstprinzipal-Typ für Agenten

Damit kommen wir zur neuesten Kategorie in diesem Ökosystem: ServiceIdentity, das Identitätsmodell, das zur Unterstützung agentenbasierter digitaler Abläufe eingeführt wurde.

Agentenidentitäten basieren auf zwei zentralen Entra-ID-Konstrukten: dem Anwendungsobjekt und dem Dienstprinzipalobjekt. Um zu verstehen, wie Agentenidentitäten funktionieren und welches „Potenzial“ sie bergen, mussten wir daher zunächst die verschiedenen Modelle verstehen, von denen sie abgeleitet sind.

Auf einer übergeordneten Ebene ist die agentIdentityBlueprint, bei dem es sich um einen Untertyp der Anwendung handelt, definiert die Agentenvorlage und enthält die Anmeldedaten. Die agentIdentity, ein Subtyp von servicePrincipal mit der Eigenschaft servicePrincipalType eingestellt auf ServiceIdentity, ist das pro Agent vorhandene Laufzeitobjekt, das Berechtigungen abruft und mit Ressourcen interagiert.

Diese Unterscheidung ist von Bedeutung, da Agentenidentitäten keine eigenen Zugangsdaten besitzen.

Stattdessen nutzen sie den Blueprint, um über ein Identitätsnachahmungsmodell in ihrem Namen Token zu erwerben. Der Blueprint authentifiziert sich mit seinen eigenen Anmeldedaten und führt einen Tokenaustausch durch, bei dem das resultierende Token die Identität des Agenten als die des Kunden ausweist, obwohl der Blueprint die eigentliche Authentifizierung durchgeführt hat.

Wie Sie in der Abbildung sehen können, gibt es außerdem ein drittes Objekt (Achtung, Spoiler: Es gibt auch noch einen vierten Teil) im Modell: das agentIdentityBlueprintPrincipal, das von servicePrincipal und dient als mandantenbezogene Laufzeitdarstellung des Blueprints. Es wird erstellt, wenn ein Blueprint in einem Mandanten instanziiert wird, und ermöglicht es dem Blueprint, anwendungsspezifische Token zu beziehen, um Agent-Identitäten zu erstellen und zu verwalten.

Ein weiteres wichtiges architektonisches Unterscheidungsmerkmal ist das Beziehungsmodell. Herkömmliche Anwendungen folgen in der Regel einer Eins-zu-Eins-Beziehung zwischen dem Anwendungsobjekt und dem Dienstprinzipal im Heimatmandanten, während mandantenfähige Anwendungen pro Mandant, in dem die Anwendung genutzt wird, einen Dienstprinzipal erstellen. Das Agentenmodell fügt eine weitere Ebene hinzu: Aus einer einzigen Blaupause können mehrere Dienstprinzipale mit Agentenidentität innerhalb eines Mandanten sowie mandantenübergreifend generiert werden.

Das Verständnis dieser Trennung ist entscheidend für das Verständnis sowohl der Architektur als auch der Angriffsfläche, da Agentenidentitäten nicht einfach nur „ein weiterer Typ von Dienstprinzipal“ sind.

In einem späteren Kapitel werden wir etwas tiefer in diese Architektur eintauchen, untersuchen, welche Erkenntnisse der Microsoft Graph OData-Metadaten-Endpunkt über diese Objektbeziehungen liefert, welche Autorisierungsebenen wahrscheinlich vorhanden sind, und fundierte Vermutungen darüber anstellen, wo künftig Schwachstellen auftreten könnten.

Zunächst wollen wir uns jedoch das Rahmenwerk ansehen, das Microsoft für die Authentifizierung, Autorisierung, Steuerung und den Schutz dieser nicht-menschlichen Identitäten entwickelt hat.

Seien Sie gespannt auf das nächste Kapitel: „Microsoft Agent ID und die Agent Identity Platform verstehen“.

Entdecken Sie den Leitfaden

Springen Sie zum nächsten veröffentlichten Kapitel der Reihe – oder wählen Sie Ihr eigenes Abenteuer.

• Einleitung: Entra ID Agent-Identitätsangriffe verstehen und verhindern: Ein umfassender Leitfaden
• Lernen Sie die Identitäten der Entra-ID-Agenten kennen (übrigens: Es handelt sich dabei nicht um Menschen)

Endnoten

• 1 https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/resources/agentidentity.md
• 2 https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/resources/agentidentityblueprintprincipal.md
• 3 https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/