Agentenidentitäten: Ein tiefer Einblick in das Design

Anmerkung der Redaktion: Willkommen zu Kapitel 4 von „Entra ID-Agenten-Identitätsangriffe verstehen und verhindern: Ein umfassender Leitfaden“. Diese mehrteilige technische Anleitung hilft Ihnen dabei, den Ansatz von Microsoft in Bezug auf Agentenidentitäten zu verstehen und zu erfahren, wie Sie diese vor Angreifern schützen können. Um die vorherigen Kapitel noch einmal durchzugehen und die Übungen zu absolvieren, beginnen Sie bitte hier.

Im vorangegangenen Kapitel dieses umfassenden Leitfadens zur Verhinderung von Identitätsangriffen auf Entra ID-Agenten haben wir die Kernobjekte definiert, aus denen sich das Agent-ID-Modell zusammensetzt. Mit diesem übergreifenden Modell im Hinterkopf – und hoffentlich nach einem kurzen Abstecher, um die Erstellung von Agent-IDs mit MS Graph zu üben – sind wir nun bereit, ein tieferes Verständnis dafür zu entwickeln, wie Identitäten auf der Agent-ID-Plattform strukturiert sind.

Lassen Sie uns wieder einsteigen.

Einführung in das Datenmodell von Microsoft Graph

Um zu verstehen, wie die vier Identitätsbausteine in der zugrunde liegenden Datenhierarchie von Microsoft Graph dargestellt sind, können wir den Endpunkt für Graph-Metadaten untersuchen.

Microsoft Graph stellt sein Datenmodell über den OData-Metadaten-Endpunkt unter https://graph.microsoft.com/beta/$metadata. Wenn Sie darauf zugreifen, erhalten Sie ein XML-Dokument, das Entitätstypen, komplexe Typen, Aufzählungen und Beziehungen definiert, die die API unterstützt. Einfacher ausgedrückt handelt es sich hierbei um die Strukturübersicht von Microsoft Graph. Es gibt zwar nicht Aufschluss über alle Möglichkeiten, die die Plattform zur Laufzeit bietet, zeigt uns jedoch, wie Microsoft die Objekte modelliert hat.

Microsoft erläutert, dass diese Metadaten Entwicklern dabei helfen, das Datenmodell und die Beziehungen zwischen Entitäten zu verstehen. Für Sicherheitsforscher ist dieser Endpunkt äußerst wertvoll, da er die Vererbungshierarchie und die Eigenschaftsdefinitionen offenlegt, die das Verhalten von Entra-ID-Objekten bestimmen, einschließlich der neuen Agent-ID-Typen.

Allerdings befindet sich „Agent ID“ noch in der Weiterentwicklung, und einige Details des Schemas können sich im Zuge der Weiterentwicklung der Plattform noch ändern.

Bevor wir uns mit den Objekten selbst befassen, sollten wir zunächst klarstellen, dass es zwei Metadatenkonstrukte gibt, die es zu unterscheiden gilt: EntityType und ComplexType.

• Ein EntityType stellt in der Regel ein Objekt dar, das direkt über seinen eigenen Endpunkt abgefragt werden kann, über Navigationseigenschaften (Beziehungen zu anderen Entitäten) verfügt und unabhängig gespeichert, abgerufen und aktualisiert werden kann. Beispiele für solche Entitätstypen sind user, application, servicePrincipal, und group.
• A ComplexType ist ein strukturierter Werttyp, der mehrere Eigenschaften zusammenfasst. Er besitzt keine eigene Identität, sondern ist in eine Entität (oder sogar in eine andere) eingebettet. ComplexType) und können nicht direkt als eigenständiges Objekt abgefragt werden. Beispiele für solche Typen sind apiApplication, appRole, federatedIdentityCredential, und keyCredential.

Stellen Sie sich das einmal so vor: ein EntityType entspricht einer Zeile in einer Datenbanktabelle, und ein ComplexType ist ein JSON-Objekt, das in dieser Zeile verschachtelt ist.

In der XML-Metadaten-Antwort ist der abstrakte Basisentitätstyp zu erkennen, von dem fast alle Graph-Entitätstypen ableiten (und aus diesem Grund verfügt fast jede Microsoft Graph-Ressource letztendlich über eine ID-Zeichenkette):

Das nächste Stück ist das directoryObject Entität, die von der Entität erbt.

Von dort aus können wir uns Folgendes ansehen: servicePrincipal Typ und dessen Struktur.

Eine textbasierte Benutzeroberfläche ist, gelinde gesagt, nicht gerade das leserfreundlichste Format für die Navigation durch ein 428 KB großes Metadaten-Dokument; daher haben wir kurzerhand eine lokale Web-App programmiert, um das Durchlaufen dieser Entitätsbeziehungen etwas übersichtlicher zu gestalten.

Anstatt nun zu versuchen, den Entitätstyp „agentIdentity“ zu verstehen, indem Sie dessen Rohmetadaten unter die Lupe nehmen:

… können wir die Objekthierarchie visuell erkunden und die Beziehungen rund um jeden Typ auf eine eher forschungsorientierte Weise untersuchen:

Aus den Metadaten geht hervor, dass agentIdentity erbt von servicePrincipal (mit OpenType="true"(was bedeutet, dass möglicherweise auch weitere dynamische oder undokumentierte Eigenschaften vorhanden sind) und fügt auf der Ebene der Untertypen die folgende kleine Gruppe agentenspezifischer Elemente hinzu:

• Zwei Eigenschaften:
  • agentIdentityBlueprintId (eine obligatorische Zeichenfolge, die die Identität des Agenten mit seinem übergeordneten Blueprint verknüpft)
  • createdDateTime
• Drei Navigationseigenschaften:
  • Sponsoren (eine Sammlung von directoryObject)
  • inheritedAppRoleAssignments (eine Sammlung von appRoleAssignment)
  • inheritedOauth2PermissionGrants (eine Sammlung von oAuth2PermissionGrant)

Die beiden letzten sind neu in das Beta-Schema aufgenommen worden und sind besonders wichtig, da sie den Mechanismus der Berechtigungsvererbung vom übergeordneten „Agent Identity Blueprint“-Prinzipal auf die Agentenidentität darstellen. Microsoft dokumentiert diese vererbten App-Rollenzuweisungen und delegierten Berechtigungen als wirksame Berechtigungen, die zum Zeitpunkt der Token-Ausstellung angewendet werden.

An dieser Stelle wird auch der Unterschied zwischen „klassischen Agenten“ und „modernen Agenten“ in Entra ID allmählich deutlicher.

• Klassische Agenten, wie sie beispielsweise von Copilot Studio und Azure AI Foundry vor der Einführung des neuen Agent-ID-Modells erstellt wurden, werden im Hintergrund durch reguläre Service-Principal-Objekte dargestellt.
• Moderne Agenten, werden hingegen durch die neue agentIdentity Subtyp.

Vor diesem Hintergrund lässt sich leicht nachvollziehen, warum die Filterung nach der Spalte „Agent Blueprint ID“ im Agent-ID-Portal (Vorschau) dabei helfen kann, diese beiden Bereiche voneinander zu trennen. Objekte mit einer agentIdentityBlueprintId gehören zum neuen Agent-ID-Modell, während ältere, auf Service-Principals basierende Agenten dies nicht tun.

Es ist anzumerken, dass die Metadaten der Version 1.0 derzeit eine schlankere Definition des Schemas enthalten, ohne die beiden inherited* Navigationseigenschaften aktivieren agentIdentity. Eine solche Lücke zwischen der Beta-Version und der Version 1.0 ist für Vorschaufunktionen zwar typisch, hat jedoch erhebliche Auswirkungen auf die Sicherheit für Sicherheitsverantwortliche, die das Produkt bewerten möchten bereits integrierte Entra-Agenten in ihrer Organisation. Jedes Audit-Tool, jedes CSPM-Produkt oder jedes Skript zur Berechtigungsauflistung, das diese vererbten Berechtigungsbeziehungen nicht berücksichtigt, könnte einen Teil des Gesamtbildes der effektiven Berechtigungen für Objekte mit Agent-ID übersehen.

Und wenn wir vererbbare Berechtigungen für einen Blueprint konfigurieren, die Administratorzustimmung für den Blueprint-Träger erteilen und einen damit verknüpften Agenten über verschiedene API-Versionen abfragen, wird diese Lücke sichtbar.

Alles andere – alle über 40 Eigenschaften und über 20 Navigationseigenschaften aus dem servicePrincipal Objekt – wird strukturell vererbt. Dazu gehören Eigenschaften wie keyCredentials, passwordCredentials, owners, federatedIdentityCredentials, und memberOf.

Genau an dieser Stelle kann uns das Schema jedoch in die Irre führen.

Die OData-Vererbung beschreibt die Struktur des Objektmodells. Sie garantiert nicht, dass jede geerbte Funktion zur Laufzeit tatsächlich verfügbar ist. In der Dokumentation von Microsoft wird dies ausdrücklich in Bezug auf Ressourcen im Zusammenhang mit der Agenten-ID erwähnt :

…obwohl diese Ressource von `servicePrincipal` abgeleitet ist, sind einige Eigenschaften nicht anwendbar.

Die Eigenschaften von Anmeldedaten sind das deutlichste Beispiel hierfür, da Agentenidentitäten keine eigenen Anmeldedaten besitzen: keine Passwörter, keine Zertifikate, keine Client-Geheimnisse. Sie sind darauf angewiesen, dass der übergeordnete Blueprint in ihrem Namen Token beschafft; Versuche, Anmeldedaten direkt einem Agentenidentitätsobjekt hinzuzufügen, werden von der API abgelehnt.

Während also keyCredentials und passwordCredentials sollten sie im vererbten Schema vorkommen, sind sie bei Agentenidentitäten null oder leer und somit praktisch nicht verfügbar. Diese Durchsetzung erfolgt nicht über die Metadatendatei selbst. Sie erfolgt über Codepfade der Laufzeitlogik in der API-Schicht, die den Subtyp erkennen und Operationen ablehnen müssen, die nicht angewendet werden dürfen.

Ähnliches gilt für die agentIdentityBlueprintPrincipal Objekt, das ebenfalls von servicePrincipal und fügt in seiner Subtypdefinition lediglich die Beziehung „Eigentümer“ hinzu. Wie die Agentenidentität erbt auch dieser Typ die gesamte Berechtigungsstruktur von servicePrincipal Theoretisch ist dies zwar so vorgesehen, doch in der Praxis werden die Anmeldeinformationen über das „Blueprint“-Anwendungsobjekt verwaltet, und die auf diesem Objekt durchgeführten Operationen sind an endpunktbezogene Sicherheitsmaßnahmen, dynamische Laufzeitprüfungen und dergleichen gebunden.

Dies ist eine der wichtigsten Erkenntnisse zum Thema Sicherheit im Agent-ID-Modell: Das Schema gibt zwar an, welche Berechtigungen das Objekt erbt, doch die Plattform muss weiterhin sicherstellen, dass das Objekt nur die ihm erlaubten Aktionen ausführen darf.

Der vom Nutzer geprägte Teil des Problems

Die agentUser Die Entität folgt demselben Vererbungsmuster, das wir bereits untersucht haben, doch dieses Mal ist sie über der user Objekt statt servicePrincipal.

Und wenn die Überlagerung von Agenten-Subtypen auf der Service-Principal-Ebene heikel ist, ist die Überlagerung auf der Benutzerebene wohl noch heikler. Das Benutzerobjekt berührt Authentifizierungsrichtlinien, Lizenzierung, Funktionen zur Zusammenarbeit, Gruppenmitgliedschaft, Organisationsstruktur sowie administrative Zuweisungsprozesse, die ursprünglich auf menschliche Identitäten konzipiert wurden.

Betrachtet man die Metadaten, agentUser erbt von graph.user und fügt auf der Ebene des Untertyps weder neue Eigenschaften noch neue Navigationseigenschaften hinzu. Mit anderen Worten: Jede Eigenschaft und jede dokumentiert Die Beziehung, die ein Agent-Benutzer unterhält, ergibt sich aus dem Typ der Benutzerbasis.

„Keine neuen Merkmale“ bedeutet jedoch nicht, dass kein Unterscheidungsmerkmal vorliegt.

Die identityParentId Die Eigenschaft, die den Agentenbenutzer mit der Identität seines übergeordneten Agenten verknüpft, ist im Basistyp „Benutzer“ selbst definiert. Für reguläre menschlich Bei normalen Benutzern ist diese Eigenschaft stets null, bei Agentenbenutzern enthält sie jedoch die Objekt-ID der zugehörigen Agentenidentität und ist bei der Erstellung erforderlich. In der Dokumentation von Microsoft wird zudem darauf hingewiesen, dass diese Beziehung nach ihrer Herstellung unveränderlich ist und weder gelöscht noch geändert werden kann.

Anders als in der agentIdentity und agentIdentityBlueprintPrincipal Objekte: Microsoft hat sich hier für eine architektonische Lösung entschieden, bei der die Unterscheidungsmerkmal auf den übergeordneten Typ verlagert wird, anstatt es auf den Untertyp festzulegen. Das bedeutet, dass die OData-Metadaten allein uns nicht verraten, dass agentUser etwas anderes als ein Benutzer ist und das einzige Signal auf Schemaebene das @odata.type Diskriminator am Objekt selbst.

Diese Unterscheidung ist von Bedeutung, da die Agent-Benutzer für bestimmte Aufgaben konzipiert sind. Im Gegensatz zu Agent-Identitäten, bei denen es sich um von Service-Principals abgeleitete Objekte handelt, die sich über rein anwendungsbezogene Token-Abläufe authentifizieren, sind Agent-Benutzer speziell für Kontexte vorgesehen, in denen eine benutzerbezogene Identität erforderlich ist.

Was die Token betrifft, so erhalten sie Token mit dem idtyp=user Anspruch, was bedeutet, dass sie auf APIs und Dienste zugreifen können, die speziell nach einem Benutzertoken statt nach einem App-Token prüfen (Outlook, Teams, SharePoint und alle anderen Dienste, die den Zugriff vom Identitätstyp abhängig machen), sodass sie über Postfächer verfügen, Teams-Kanälen beitreten und in Organigrammen erscheinen können. Eine Vision eines KI-persönlichen Assistenten in ihrer ganzen Pracht.

Microsoft hat mehrere Sicherheitsbeschränkungen hinsichtlich der Benutzeridentitäten von Agenten dokumentiert:

• Sie dürfen keine Passwörter oder Passkeys haben.
• Ihnen dürfen keine privilegierten Administratorrollen zugewiesen werden.
• Benutzerdefinierte Rollenzuweisungen und Gruppen, denen Rollen zugewiesen werden können, stehen ihnen nicht zur Verfügung.
• Ihr Standard-Berechtigungsmodell ähnelt dem von Gastbenutzern, verfügt jedoch über etwas umfassendere Möglichkeiten zur Auflistung von Benutzern und Gruppen.

Dies sind sinnvolle Sicherheitsvorkehrungen. Doch jede einzelne davon muss auf API- und policy individuell für jeden Codepfad durchgesetzt werden, der mit einem user Objekt.

Das ist der heikle Punkt. Wenn ein Endpunkt agentUser als bloß ein weiteres user und vergisst, die untertyp-spezifischen Einschränkungen anzuwenden, ist das Ergebnis nicht nur ein Fehler. Es kann zu einem Problem im Zusammenhang mit der Berechtigungsgrenze werden.

So ist es beispielsweise trotz der offizielle Sicherheitsauflagen Im Zusammenhang mit der Vergabe von privilegierten Rollen konnten wir im Testverfahren Agentenbenutzern 3 von 32 Rollen, die mit isPrivileged=true:

• Global Reader: Lesezugriff auf das gesamte Verzeichnis und alle Microsoft 365-Daten
• Security Reader: Lesezugriff auf Sicherheitswerkzeuge, Microsoft Defender und Identity Protection
• KI-Administrator: Administrative Kontrolle über KI- und agentenbezogene Funktionen

Außerdem konnten wir zahlreiche Rollen zuweisen, die nicht als privilegiert gekennzeichnet sind (oder als standardAssigned), die in der Praxis jedoch faktisch der Stufe 0 entsprechen, wie beispielsweise der Abrechnungsadministrator, der Exchange-Administrator, der SharePoint-Administrator und Konten für die Verzeichnissynchronisierung.

Dieses Muster ist nicht neu und kommt nicht nur bei Agentenidentitäten vor.

Die übermäßige Vergabe von Berechtigungen für die Rolle „AI Administrator“ und der im vorigen Kapitel erörterte^{Silverfort-Befund¹} sind die aktuellsten Beispiele, reihen sich jedoch in eine gut dokumentierte Tradition von „Scoping-Lücken“ bei Entra ID ein. In diesen Fällen wirkt sich eine Berechtigung oder Rolle, die scheinbar auf eine engere Objektklasse angewendet wird, letztendlich auf den übergeordneten Basistyp oder einen sensibleren Kontrollbereich aus, als erwartet. Die klassischen Privilegieneskalationspfade des „Application Administrator“ und des „Cloud Application Administrator“ sind hierfür Paradebeispiele.

Umfassend dokumentiert von Dirk-jan Mollema²sowie SpecterOps,³ Diese Eskalationspfade nutzen die Tatsache aus, dass die Rollen Anmeldedaten zu jede Dienstprinzipal im Mandanten. Verfügt ein Dienstprinzipal über Anwendungsberechtigungen mit erheblichen Auswirkungen, wie beispielsweise RoleManagement.ReadWrite.Directory oder AppRoleAssignment.ReadWrite.All—oder dem privilegierte Verzeichnisrollen zugewiesen wurden—kann das Hinzufügen von Anmeldedaten dazu führen, dass sich der Angreifer als dieser Dienstteilnehmer authentifizieren und dessen effektive Berechtigungen übernehmen kann.

Die Frage nach dem Anwendungsbereich ist hier subtil; die Rolle wird ehrlich als „Verwaltung von Anwendungen“ beschrieben. Die gefährliche Annahme besteht darin, dass „Verwaltung von Anwendungen“ nicht auch bedeuten sollte, „beliebige Dienstprinzipale mit hohen Berechtigungen übernehmen zu können“. Microsoft führte später Steuerelemente zur Sperrung von App-Instanz-Eigenschaften ein, um dieses Risiko teilweise zu verringern, doch die zugrunde liegende Problemstellung bleibt von Bedeutung: Die Kontrolle über ein Objekt kann zur Kontrolle über die diesem Objekt bereits zugewiesenen Berechtigungen führen.

Die Studie von Semperis aus dem Jahr 2024 zum Thema UnOAuthorized zeigte eine weitere Ausprägung dieses Musters auf. Mehrere Microsoft-First-Party-Service-Principals (erinnern Sie sich an diesen Typ aus der Taxonomie?) konnten von Anwendungsadministratoren und Cloud-Anwendungsadministratoren genutzt werden, um Benutzer zu privilegierten Rollen hinzuzufügen oder aus diesen zu entfernen. Das Problem bestand nicht einfach abstrakt gesehen in „zu vielen Berechtigungen“. Es handelte sich vielmehr um eine Diskrepanz zwischen der beabsichtigten Rollenabgrenzung und der Art und Weise, wie OAuth-2.0-Bereiche und First-Party-Service-Principals in der Praxis ausgewertet wurden.

Ebenso gilt dies für Datadog I SPy⁴Die Offenlegung ab 2025 zeigte eine weitere Abweichung. In bestimmten Szenarien verfügen Dienstprinzipale mit den Rollen „Cloud-Anwendungsadministrator“, „Anwendungsadministrator“ oder Application.ReadWrite.All könnte die Dienstinstanz von Office 365 Exchange Online durch Hinzufügen von Anmeldedaten kapern. In Hybridumgebungen könnte dies über eine Verbunddomänenvertrauensstellung zu Zugriffsrechten eines Globaladministrators führen. Eine andere Angriffsfläche, dieselbe Lehre: Berechtigungen, die auf „Anwendungen“ beschränkt sind, können weitaus gefährlicher werden, wenn die betroffene Anwendung selbst eine privilegierte Vertrauensinstanz darstellt.

Und die von Dirk-jan Mollema aufgedeckte „Actor Token“-Sicherheitslücke^{⁵ (CVE-2025-55241)} gehört, obwohl sie strukturell anders beschaffen ist, zur selben übergeordneten Kategorie. In diesem Fall ermöglichten undokumentierte interne Token zur Identitätsübernahme zwischen Diensten in Verbindung mit einer Lücke bei der Mandantenvalidierung in der veralteten Azure AD Graph-API die mandantenübergreifende Identitätsübernahme für jeden Benutzer – einschließlich globaler Administratoren –, ohne dass Protokolle erstellt wurden und ohne Durchsetzung des bedingten Zugriffs. Die Lücke im Anwendungsbereich lag hier an der Mandantengrenze und nicht an der Grenze des Objektuntertyps, doch die zentrale Erkenntnis ist bekannt: Wenn eine privilegierte Primitive ohne strenge Validierung an jeder Verwendungsstelle eingeführt wird, wird letztendlich eine dieser Stellen zu einem Einfallstor.

Was bedeutet das nun alles?

Nun, zunächst einmal handelt es sich bei der Agent-ID nicht um einen eigenständigen neuen Objekttyp. Es handelt sich vielmehr um ein neues Identitätsmodell, das auf den Grundelementen aufbaut, die Entra ID bereits sehr gut kennt: Anwendungen, Dienstprinzipale, Benutzer, OAuth-Berechtigungen, Zuweisungen von App-Rollen, Anmeldedaten und Verzeichnisrollen.

Und zweitens ist dieser Ansatz zwar praktisch, bedeutet aber auch, dass das Sicherheitsmodell von einem heikleren Faktor abhängt. Die Hierarchie des Metadatenschemas kann uns zwar Aufschluss darüber geben, was ein Objekt erbt, doch erst das Laufzeitverhalten zeigt uns, welche der geerbten Fähigkeiten tatsächlich zugänglich sind.

Dies ist der zentrale Widerspruch von Agent ID: Microsoft räumt KI-Agenten innerhalb von Entra ID eine erstklassige Stellung ein, tut dies jedoch durch die Erweiterung von Objekttypen, die bereits seit Jahren eine wichtige Rolle für die Sicherheit spielen. Jede geerbte Eigenschaft, jede Rollenaktion, jeder Token-Fluss und jeder Endpunkt wird nun zu einem Teil des Problems.

Bevor wir also darüber sprechen, wie man Agent-Identitäten missbrauchen, schützen oder überwachen kann, müssen wir zunächst verstehen, wie diese Identitäten eigentlich aufgebaut sind.

Und nun ist diese Vorstellung hoffentlich etwas klarer geworden.

Gut, sprechen wir über Berechtigungen

Die Agent-ID-Plattform führt neue Identitätsarten ein, die autonome Aktionen ausführen, im Namen von Benutzern handeln und dauerhafte Berechtigungen besitzen können. Das Verständnis ihres Berechtigungsmodells ist unerlässlich, um eine Ausweitung von Berechtigungen zu verhindern und unbeabsichtigte Zugriffspfade mit weitreichenden Auswirkungen zu vermeiden. Dieses Modell führt zudem ein neues Konzept der vererbbaren Berechtigungen ein, das wir verstehen müssen.

App-spezifische und delegierte Berechtigungen

Genau wie bei regulären Anwendungen und Dienstprinzipalen können auch für Agent-Identitätsvorlagen und Agent-Identitäten anwendungsspezifische Berechtigungen oder delegierte Berechtigungen zugewiesen werden.

Wie wir bereits gesehen haben, enthält die Blueprint-Vorlage für die Agentenidentität stets eine rein anwendungsbezogene Berechtigung – AgentIdentity.CreateAsManager—standardmäßig, wodurch es Agent-Identitäten erstellen und verwalten kann.

Bei Agentenidentitäten sollten „App-only“-Berechtigungen verwendet werden, wenn der Agent vollständig autonom arbeitet. Delegierte Berechtigungen kommen zum Tragen, wenn ein Benutzer in den Arbeitsablauf eingebunden ist und der Agent im Namen dieses Benutzers handeln muss.

Vererbbare Berechtigungen

Vererbbare Berechtigungen sind eine Konfiguration zur Berechtigungsvererbung, die auf der Ebene der Agent-Identitätsvorlage definiert wird. Sie ermöglichen es, dass aus der Vorlage erstellte Agent-Identitäten genehmigte Berechtigungen automatisch von der Vorlage erben, anstatt dass dieselbe Einwilligung für jede Agent-Identität separat erteilt werden muss.

Ursprünglich trat dies vor allem im Zusammenhang mit delegierten Berechtigungen auf, doch in der aktuellen Microsoft-Dokumentation wird nun beschrieben, dass vererbbare Berechtigungen sowohl delegierte Gültigkeitsbereiche als auch Anwendungsrollen unterstützen. Delegierte Gültigkeitsbereiche erscheinen im delegierten Zugriffstoken der Agentenidentität in der scp Behauptung, während Anwendungsrollen im reinen App-Zugriffstoken im roles Behauptung.

Damit vererbbare Berechtigungen wirksam werden, reicht die Konfiguration des Blueprints allein nicht aus. Zwei Voraussetzungen müssen erfüllt sein:

• Die entsprechende Ressourcen-App muss im Blueprint konfiguriert werden. inheritablePermissions.
• Die Berechtigung muss zudem dem Blueprint-Prinzipal erteilt werden.

Microsoft beschreibt dies als den Unterschied zwischen Deklaration, Zuweisung und Vererbung: inheritablePermissions ist eine Konfiguration, während die Einwilligung auf der Ebene des „Blueprint“-Prinzipals die Autorisierung gewährt.

Das bedeutet, dass die allAllowed Diese Einstellung sollte nicht so verstanden werden, dass „der Agent automatisch alle Berechtigungen erhält, die von der Ressourcenanwendung bereitgestellt werden“. Sie bedeutet vielmehr, dass alle berechtigten Berechtigungen dieses Typs für diese Ressourcenanwendung, die dem Blueprint-Prinzipal gewährt wurden, an die Agentenidentitäten weitervererbt werden können. Das effektive Token ist dann das Ergebnis der Zusammenführung der vererbten Berechtigungen und aller Berechtigungen, die der jeweiligen Agentenidentität direkt gewährt wurden.

Die Konfiguration erfolgt über die Ressourcenanwendung, wobei delegierte Gültigkeitsbereiche und Anwendungsrollen für dieselbe Ressource unabhängig voneinander konfiguriert werden können. So kann beispielsweise ein Blueprint delegierte Gültigkeitsbereiche erben, nicht jedoch Anwendungsrollen; umgekehrt kann er Anwendungsrollen erben, nicht jedoch delegierte Gültigkeitsbereiche. In den Beispielen von Microsoft wird dies anhand von inheritableScopes und inheritableRoles getrennt.

Damit die delegierten, vererbbaren Berechtigungen wirksam werden, muss der Blueprint-Dienstprinzipal bereits über die entsprechenden OAuth2PermissionGrants Einträge für diese Bereiche, nachdem auf Blueprint-Ebene eine Zustimmung erteilt wurde.

Für delegierte Berechtigungen gelten die folgenden dokumentierten Muster zur Vererbung des Geltungsbereichs:

• allAllowed: Diese Muster übernehmen alle verfügbaren delegierten Gültigkeitsbereiche für die von ihnen gewährte Ressource.
• noScopes: Diese Muster erben keine delegierten Gültigkeitsbereiche für diese Ressourcen-App.
• enumerated: Diese Muster, die ausschließlich in der Beta-API-Dokumentation aufgeführt sind, umfassen nur die dort angegebenen Bereiche. Bei Verwendung des Aufzählungsmusters können Sie bis zu 40 Bereiche pro Ressourcenanwendung einbeziehen.

Was die Anwendungsberechtigungen betrifft, sind derzeit folgende, ausschließlich auf die App beschränkte Vererbungsmuster dokumentiert:

• allAllowed: Diese Muster übernehmen alle verfügbaren Anwendungsbereiche der Ressourcen-App, für die sie die Berechtigung erteilt haben.
• noRoles: Diese Vorlagen erben keine Anwendungsrollen für die betreffende App.

In der offiziellen Dokumentation ist keine explizite Option für die „App-only“-Vererbung aufgeführt. Nach einigen Tests haben wir jedoch festgestellt, dass diese Option in den Ablauf der „App-only“-Vererbung einbezogen werden kann.

Das folgende Schema veranschaulicht das Konzept hinter delegierten, aufzählbaren und vererbbaren Berechtigungen. Ein ähnliches Schema wäre auch für die rein app-spezifischen Berechtigungen relevant, die weitgehend auf dieselbe Weise funktionieren. (Die Unterschiede werden in Übungsaufgabe 2 dargestellt.)

Ein Blueprint kann vererbbare Berechtigungen für bis zu 60 Ressourcenanwendungen definieren. Diese Begrenzung gilt nicht ausschließlich für Blueprints.

Es ist zudem wichtig zu beachten, dass bestimmte risikoreiche Microsoft Graph-Berechtigungen für Agentenidentitäten gesperrt sind. Microsoft dokumentiert, dass gesperrte delegierte Berechtigungsbereiche oder App-Rollen nicht an Agentenidentitäten vergeben werden können, und dass die Einbeziehung eines gesperrten delegierten Berechtigungsbereichs oder einer gesperrten App-Rolle dazu führt, dass die Anfrage abgelehnt wird.

Vererbbare Berechtigungen sind optional. Auch ohne deren Verwendung können Berechtigungen weiterhin direkt und individuell für jede Agentenidentität erteilt werden. Der Unterschied besteht darin, dass direkte Berechtigungen nur für diese bestimmte Agentenidentität gelten, während vererbbare Berechtigungen es einem Administrator ermöglichen, Berechtigungen einmalig auf Blueprint-Ebene zu genehmigen, sodass die entsprechenden Berechtigungen auf alle bestehenden und zukünftigen Agentenidentitäten übertragen werden, die auf der Grundlage dieses Blueprints erstellt werden.

Gruppenmitgliedschaft (nur für Agentenbenutzer)

Die Mitgliedschaft in einer Gruppe ist auf Agentenbenutzer beschränkt. Agentenbenutzer können zu Sicherheitsgruppen hinzugefügt werden, jedoch nicht zu Gruppen, denen Rollen zugewiesen werden können. Sie erben Berechtigungen aus ihren Gruppenmitgliedschaften auf dieselbe Weise wie reguläre Benutzer.

Microsoft Entra-Rollen

Agentenidentitäten können Microsoft Entra-Verzeichnisrollen zugewiesen werden, ähnlich wie bei Dienstprinzipalen, jedoch mit wesentlichen Einschränkungen. Rollen mit weitreichenden Berechtigungen, wie beispielsweise „Global Administrator“, „Privileged Role Administrator“ und „User Administrator“, können Agentenidentitäten nicht zugewiesen werden. Es wird nur eine definierte Teilmenge der Microsoft Entra-Rollen unterstützt, und einige dieser Rollen sind nach wie vor administrativer Natur; daher sollten sie sorgfältig unter Berücksichtigung des vorgesehenen Verwendungszwecks des Agenten und der Anforderungen an das Prinzip der geringsten Berechtigungen zugewiesen werden.

Die vollständige Liste der unterstützten Rollen finden Sie hier.

Zugangspaket

Neben der direkten Zuweisung von Zugriffsrechten an eine Agentenidentität können Unternehmen auch Zugriffspakete nutzen. Ein Zugriffspaket ermöglicht es einem Agenten oder einer Gruppe von Agenten mit denselben Anforderungen, auf Ressourcen zuzugreifen. Zugriffspakete können Entra-Rollen, Mitgliedschaften in Sicherheitsgruppen, delegierte OAuth2-Berechtigungen sowie Anwendungsberechtigungen umfassen – all dies haben wir bereits zuvor beschrieben.

Zugriffspakete werden von einem Administrator konfiguriert, der Folgendes festlegt:

• Welche Ressourcen sind enthalten?
• Wer darf einen Antrag auf Zugang stellen?
• Wer muss den Zugriff genehmigen?
• Wie lange der Zugang besteht
• sowie weitere policy

Ein Agentenkonto kann selbst ein Zugriffspaket beantragen, oder ein Sponsor bzw. Manager kann dies im Namen des Agenten tun. Es kann auch direkt vom Administrator zugewiesen werden. Nach der Genehmigung erhält der Agent einen zeitlich begrenzten Zugriff auf die darin enthaltenen Ressourcen, und ein Sponsor kann bei Bedarf eine Verlängerung beantragen.

Die Zusammenhänge bei den Berechtigungen im Überblick

Zusammenfassend lässt sich das Berechtigungsmodell wie folgt beschreiben: Jede Komponente der Agent-ID-Plattform kann eigene Berechtigungen besitzen. Agent-Identitäten können rein anwendungsbezogene Berechtigungen oder delegierte Berechtigungen enthalten, Agent-Benutzer können Gruppenzugehörigkeiten erhalten, und Agent-Identitätsvorlagen können vererbbare Berechtigungen definieren, die an jede daraus erstellte Agent-Identität weitergegeben werden. Je nach Authentifizierungsablauf werden die relevanten Elemente zur Laufzeit miteinander kombiniert.

Im Falle eines „On Behalf Of“-Ablaufs in Verbindung mit neuen vererbbaren Berechtigungen sehen die endgültigen Agentenberechtigungen wie folgt aus:

Ein ähnlicher Ablauf ist auch bei der Verwendung von rein app-spezifischen Berechtigungen mit vererbbaren Berechtigungen zu erwarten. Ersetzen Sie dazu einfach alle delegierten Begriffe durch rein app-spezifische Begriffe.

Weiter: Üben Sie das Festlegen von Berechtigungen für die Agentenidentität

Machen Sie nun einen Abstecher zu unserem zweiten Übungs-Checkpoint und gehen Sie die Schritte durch, um der Agentenidentität, die Sie in der ersten Übung eingerichtet haben, Berechtigungen zuzuweisen.

Üben Sie die Einrichtung von Berechtigungen für die Identität von Agenten.

Entdecken Sie den Leitfaden

• Einleitung: Entra ID Agent-Identitätsangriffe verstehen und verhindern: Ein umfassender Leitfaden
• Kapitel 1: Lernen Sie die Identitäten der Entra-ID-Agenten kennen (übrigens: Es handelt sich dabei nicht um Personen)
• Kapitel 2: Die Taxonomie von Workload-Identitäten in Entra ID: Unternehmensanwendungen, Service-Principals und andere Formen organisierter Verwirrung
• Kapitel 3: Einführung in die Microsoft Agent-ID und die Agent Identity Platform
• Übungs-Checkpunkt 1: Erstellen einer Agenten-ID mit MS Graph
• Übungs-Checkpunkt 2: Festlegen der Berechtigungen für die Agentenidentität

Endnoten

1. https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/
2. Berechtigungserweiterung in Azure AD – Übernahme der Standardanwendungsberechtigungen als Anwendungsadministrator – dirkjanm.io
3. Privilegienerweiterung in Azure durch Missbrauch von Dienstprinzipalen – SpecterOps
4. I SPy: Eskalation zum globalen Administrator von Entra ID mithilfe einer First-Party-App | Datadog Security Labs
5. Sicherheitslücke im „Actor Token“