TL; DR
Das Microsoft Agentenidentitätsplattform (Vorschau) gibt KI-Agenten ihre eigenen Identitäten in Entra ID (Baupläne, Agentenidentitäten, Agentenbenutzer) können Sie wie jeden anderen Prinzipal verwalten und schützen. Zur Verwaltung dieser neuen Steuerungsebene hat Microsoft Folgendes eingeführt: Agenten-ID-Administrator Rolle. Offiziell ist sie nur auf agentenbezogene Objekte beschränkt.
Wir haben festgestellt, dass Konten mit einzige die Rolle des Agenten-ID-Administrators könnte übernehmen Beliebige Dienstprinzipale – einschließlich solcher, die nichts mit Agentenidentitäten zu tun haben – indem man Eigentümer wird, dann Anmeldeinformationen hinzufügt und sich als dieser Prinzipal authentifiziert. Das ist eine vollständige Übernahme des Schulleiters.Bei Mietern, bei denen hochprivilegierte Dienstherren existieren, wird es zu einem Privilege-Escalation-Angriffe Pfad.
Obwohl die Rolle des Agenten-ID-Administrators noch nicht weit verbreitet ist, verfügen die meisten Mandanten über mindestens einen privilegierten Dienstprinzipal. Wir haben außerdem festgestellt, dass viele Mandanten bereits Agentenidentitäten nutzen, teilweise in großem Umfang. Mit zunehmender Verbreitung der Rolle des Agenten-ID-Administrators könnte diese Lücke im Anwendungsbereich zu einem erheblichen Risiko für die Identitätssicherheit werden.
Wir haben dieses Verhalten dem Microsoft Security Response Center (MSRC) gemeldet, und es war in jeder Wolke fixiertDie Rolle „Agenten-ID-Administrator“ kann nicht mehr die Besitzer von Nicht-Agenten-Dienstprinzipalen verwalten.
Wenn Sie mit den oben beschriebenen Konzepten bereits vertraut sind, fahren Sie mit folgendem Abschnitt fort: Wo die Grenze bricht.
Die nachfolgende Analyse basiert auf unseren vollständigen Forschungsergebnissen.
Was Sie wissen müssen
Anwendungs- und Dienstprinzipien in Entra ID
Registrieren einer Anwendung in Microsoft Entra ID erstellt zwei zusammengehörige Objekte in der Mieter, das ist der Tenant, bei dem die App ursprünglich registriert ist: ein Anwendungsobjekt und einem Hauptdienst.
Das Anwendung Das Objekt dient als globale Definition der App und beschreibt deren Konfiguration.
Das Dienstleiter stellt die App als Identität innerhalb eines Mandanten dar und ist das Objekt, das sich authentifiziert, Rollen und Berechtigungen zugewiesen bekommt und auf Ressourcen zugreift. Wenn die Anwendung konfiguriert ist als mandantenfähigZusätzliche Dienstprinzipale werden in anderen Mandanten erstellt, wenn die App dort verwendet wird; alle basieren auf demselben Anwendungsobjekt.
Microsoft Entra ID hat verschiedene Arten von Dienstprinzipien, wie zum Beispiel Anwendungsdienst Schulleiter und verwaltete Identitäten. An Anwendungsdienstprinzipal ist die Instanz einer Anwendung in einem Mandanten, die aus dem Anwendungsobjekt erstellt wurde.
In diesem Blog konzentrieren wir uns ausschließlich auf diesen Typ, da das hier beschriebene Verhalten speziell für Anwendungsdienstprinzipale gilt.
Microsoft Agent-ID eingeben
Microsoft Agent-ID eingeben ermöglicht es Ihnen, KI-Agenten als erstklassige Identitäten zu behandeln in Entra IDDas bedeutet bedingter Zugriff, Governance und Lebenszyklusmanagement für KI-Agenten in Ihrem Tenant. Im Hintergrund basiert es auf … Microsoft Agent Identity Platformist ein Framework für Identität und Autorisierung von KI-Agenten. Es führt einige neue Objekttypen ein (Blueprints, Agentenidentitäten, Agentenbenutzer), die alle über Microsoft Graph verwaltet werden können (derzeit nur Beta-API). Die Plattform befindet sich noch in der Vorschauphase, die Rollen sind aber bereits öffentlich verfügbar und können zugewiesen und verwendet werden.
Kurz gesagt, die Plattform bietet Folgendes:
- BlaupausenDie Vorlagen, die Agentenidentitäten definieren und erstellen.
- Grundprinzipien des Entwurfs: Die mandantenspezifische Instanz eines Blueprints, wenn dieser einem Mandanten hinzugefügt wird.
- AgentenidentitätenSpezielle Dienstprinzipien, die KI-Agenten zur Authentifizierung bei APIs und Diensten verwenden.
- AgentenbenutzerHierbei handelt es sich um optionale benutzerähnliche Objekte für Agenten, die einen UPN oder eine E-Mail-Adresse benötigen und in Authentifizierungsabläufen im Auftrag von verwendet werden.
Warum das wichtig ist: Agentenidentitäten basieren auf bekannten Verzeichnisstrukturen: Anwendungen, Dienstprinzipalen und Benutzern. Genau auf dieser gemeinsamen Grundlage liegt unsere Erkenntnis.
Agenten-ID-Administratorrolle
Microsoft fügte hinzu Agenten-ID-Administrator Rolle zur Verwaltung der neuen Agentenidentitäts-Kontrollebene. Laut Dokumentation, er ist Geltungsbereich:
Mit anderen Worten: Nur AgentenkramNicht alle Dienstprinzipale. Diese Unterscheidung ist wichtig. Dienstprinzipale sind die Identitäten hinter Automatisierung, CI/CD, Sicherheitstools und privilegierten Integrationen. Wer sie kontrolliert, kontrolliert einen Großteil der Umgebung.
Noch eine BeobachtungIn der Dokumentation steht, dass diese Rolle … privilegiertIn der Entra-Benutzeroberfläche (die auf den Beta-Verzeichnisrollendefinitionen basiert) wird dies jedoch nicht so angezeigt. Das kann dazu führen, dass Administratoren die Rolle ohne die gleiche Sorgfalt zuweisen wie privilegierte Rollen.
Microsoft bestätigte die Diskrepanz zwischen der Entra-Benutzeroberfläche und der Dokumentation. in Bezug auf der Indikator für „Privilegierte“. wird behoben.
Wo die Grenze bricht
Folgendes haben wir beobachtet: Einem Benutzer mit der Rolle „Agenten-ID-Administrator“ kann er sich selbst als Besitzer von Dienstprinzipalen hinzufügen, die über agentenbezogene Identitäten hinausgehen, einschließlich beliebiger Dienstprinzipale im Mandanten. Anschließend kann er Anmeldeinformationen hinzufügen und sich für diese Anwendungen authentifizieren.
Schritt 1: HinzufügenEigentümer (Erfolgreich gegen nicht-agentische Dienstleistungsauftraggeber; Sie können sich selbst oder andere Auftraggeber hinzufügen):
Schritt 2: Anmeldeinformationen hinzufügen (funktionierte erst, nachdem wir die Eigentümer geworden waren):
Unterm Strich Eigentum ist ein Übernahme der primitiven – Eigentümer werden, dann ein Geheimnis hinzufügen und sich als dieser Dienstprinzipal authentifizieren.
Während die Rolle für Agent Identitäten, in der Praxis kann dies zu einer Änderung der Eigentumsverhältnisse führen. für Dienstleiter.
Warum wir glauben, dass dies geschieht: Einige Agentenidentitäten sind als Dienstprinzipale (und verwandte Typen) implementiert. Die Rolle umfasst Aktionen wie:
microsoft.directory/agentIdentities/owners/updatemicrosoft.directory/agentIdentityBlueprintPrincipals/owners/update
Administratoren können also die Besitzer von Agentenobjekten verwalten. Wenn diese Prüfungen nicht strikt auf agentenbasierte Dienstprinzipale beschränkt sind, wirkt sich die Berechtigung auf die allgemeine Dienstprinzipalebene aus.
Eine klassische Zielfernrohrlücke wenn ein Objekttyp von einem anderen erbt.
Wir taten kein Frontalunterricht. siehe Gleiches für AnwendungenDas Hinzufügen von sich selbst als Besitzer der Anwendungsressource wurde abgelehnt. Daher scheint das Problem spezifisch für die Dienstprinzipaloberfläche zu sein.
Nach der Behebung des Problems werden Versuche, die Besitzrechte für Nicht-Agent-Dienstprinzipale mithilfe der Rolle „Agent-ID-Administrator“ zuzuweisen, nun blockiert. Der Vorgang führt zu folgendem Fehler:
Auswirkungen
Übernahme des Dienstleiters
Die Übernahme der Kontrolle über einen Dienstprinzipal bietet einen entscheidenden Angriffspunkt. Sobald ein Angreifer die Kontrolle erlangt hat, kann er Anmeldeinformationen hinzufügen, sich als Dienstprinzipal authentifizieren und innerhalb des Rahmens seiner bestehenden Berechtigungen agieren, beispielsweise API-Zugriff, Verzeichnisrollen oder Integrationen.
Die Auswirkungen hängen von den Berechtigungen des betroffenen Dienstprinzipals ab. In Umgebungen, in denen Dienstprinzipale häufig verwendet werden oder über erweiterte Berechtigungen verfügen, kann dies zu einer erheblichen Eskalation führen. Die Mandantenkonfiguration kann die Auswirkungen ebenfalls beeinflussen, beispielsweise bei Anwendungen mit breiter Zustimmung oder permissiven Konfigurationen.
Vor der Behebung des Fehlers ermöglichte die Rolle „Agent ID Administrator“ die Zuweisung der Besitzrechte an Dienstprinzipalen über agentenbezogene Identitäten hinaus, wodurch ähnliche Funktionen wie in Rollen wie „Application Administrator“ effektiv ermöglicht wurden, jedoch ohne dass der Anwendungsbereich speziell auf Agenten beschränkt war.
Wenn das Ziel privilegiert ist
Der Eskalationswinkel ist einfach: if Ein Dienstprinzipal verfügt über erweiterte Rechte (Verzeichnisrollen, weitreichende Graph-Berechtigungen); durch die Übernahme erhalten Sie diese Rechte. Viele Organisationen verwenden solche Dienstprinzipale.
Sie können ermitteln, welche Dienstprinzipale privilegiert sind, und diese dann gezielt angreifen. In der Praxis bedeutet dies zwei Arten von Prüfungen:
- Dienstprinzipale mit privilegierten Verzeichnisrollen: Verwenden Sie die Microsoft Graph API (Beta,
isPrivilegedin Rollendefinitionen), um aufzulisten, welche Dienstprinzipale Verzeichnisrollen auf Administratorebene innehaben. - Dienstprinzipale mit weitreichenden Graph-Berechtigungen: Abfrage von App-Rollenzuweisungen an Microsoft Graph für sensible Berechtigungen (z. B.
Directory.ReadWrite.All,RoleManagement.ReadWrite.Directory,Application.ReadWrite.All).
Auflistung privilegierter Dienstprinzipale
Führen Sie Folgendes aus, nachdem az login. Benötigt jqVerwenden Sie ein Konto, das Rollenzuweisungen und App-Rollenzuweisungen lesen kann (z. B. Agent ID Administrator).
1. Dienstprinzipale mit privilegierten Verzeichnisrollen
BASE="https://graph.microsoft.com"
roles="$(az rest -m GET --url "${BASE}/beta/roleManagement/directory/roleDefinitions?\$filter=isPrivileged eq true&\$select=id,displayName" -o json)"
u="${BASE}/beta/roleManagement/directory/roleAssignments?\$expand=principal(\$select=id,displayName)&\$top=999"
{
echo -e "SP_NAME\tSP_ID\tROLE"
echo -e "--------\t------\t----"
while :; do
j="$(az rest -m GET --url "$u" -o json 2>/dev/null)" || break
jq -r --argjson roles "$roles" '
($roles.value | map(select(.displayName|test("Reader";"i")|not) | {key:.id, value:.displayName}) | from_entries) as $r
| .value[]
| select(.principal."@odata.type"=="#microsoft.graph.servicePrincipal")
| select($r[.roleDefinitionId] != null)
| [.principal.displayName, (.principal.id // .principalId), $r[.roleDefinitionId]] | @tsv
' <<<"$j"
u="$(jq -r '."@odata.nextLink"//empty' <<<"$j")"
[[ -z "$u" ]] && break
done | sort -t$'\t' -k1,1
} | column -t -s $'\t'
2. Dienstprinzipale mit weitreichenden Graph-App-Berechtigungen
BASE="https://graph.microsoft.com"
PERM_IDS='["9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8","06b708a9-e830-4db3-a914-8e69da51d44f","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9","19dbc75e-c2e2-444c-a770-ec69d8559fc7","dd199f4a-f148-40a4-a2ec-f0069cc799ec","50483e42-d915-4231-9639-7fdb7fd190e5","01c0a623-fc9b-48e9-b794-0756f8e8f067","62a82d76-70ea-41e2-9197-370581804d09","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7"]'
PERM_NAMES='{"9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8":"RoleManagement.ReadWrite.Directory","06b708a9-e830-4db3-a914-8e69da51d44f":"AppRoleAssignment.ReadWrite.All","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9":"Application.ReadWrite.All","19dbc75e-c2e2-444c-a770-ec69d8559fc7":"Directory.ReadWrite.All","dd199f4a-f148-40a4-a2ec-f0069cc799ec":"RoleAssignmentSchedule.ReadWrite.Directory","50483e42-d915-4231-9639-7fdb7fd190e5":"UserAuthenticationMethod.ReadWrite.All","01c0a623-fc9b-48e9-b794-0756f8e8f067":"Policy.ReadWrite.ConditionalAccess","62a82d76-70ea-41e2-9197-370581804d09":"Group.ReadWrite.All","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7":"User-PasswordProfile.ReadWrite.All"}'
GRAPH_SP_ID="00000003-0000-0000-c000-000000000000"
az rest --method GET --url "${BASE}/v1.0/servicePrincipals(appId='${GRAPH_SP_ID}')/appRoleAssignedTo" -o json 2>/dev/null \
| jq -r --argjson ids "$PERM_IDS" --argjson names "$PERM_NAMES" '
["SP_NAME", "SP_ID", "PERMISSIONS"], ["--------", "------", "-------------"],
([.value[] | select(.appRoleId as $rid | $ids | index($rid))] | group_by(.principalId)[] |
[.[0].principalDisplayName, .[0].principalId, ([.[].appRoleId | $names[.]] | join(", "))]) | @tsv
' | column -t -s $'\t'
Hinweis: Diese Techniken filtern nicht speziell nach Dienstprinzipalen, die keine Agenten sind.
End-to-End-Angriffsablauf
Die untenstehende Figur zieht Aufzählung (die obigen Skripte) und Übernahme in einer einzigen Ansicht.
Demo-Aufnahme
Der Clip zeigt den Ablauf: einen privilegierten Dienstprinzipal finden (wir haben für die Demo nur Verzeichnisrollen durchsucht), ihn übernehmen und sich dann anmelden.
Demo: Ein Testbenutzer mit Agenten-ID-Administrator übernimmt eine privilegierte Nicht-Agent Der Dienstprinzipal (dem die Rolle des globalen Administrators zugewiesen wurde) meldet sich dann mit den neuen Anmeldeinformationen an – Rechteausweitung.
Die Demo war simuliert an. Nach der Installation können Sie HEIC-Dateien mit der Graph Beta API; wir auch bestätigt das gleiche Verhalten des Fehlers auf v1.0.
Momentaufnahme aus der realen Welt
Wir haben uns die Kundenumgebungen angesehen: die Agenten-ID-Administrator Die Rolle selbst ist noch nicht weit verbreitet, die Einrichtung des Eskalationspfads hingegen schon. Etwa 99 % der Mieter muss mindestens einen privilegierten Dienstprinzipal haben (nicht notwendigerweise agentenbezogen). Etwas mehr als die Hälfte Agentenidentitäten werden genutzt – und fast die Hälfte davon hat über 100. Da immer mehr Organisationen die Rolle der Verwaltung von Agentenidentitäten übernehmen, wird die dadurch entstehende Lücke im Aufgabenbereich zu einem echten Risiko.
Takeaways
Microsoft hat dieses Problem zwar behoben, doch die Kernaussage bleibt bestehen: Neue Identitätstypen basieren häufig auf bestehenden Grundstrukturen, was zu Lücken in der Abgrenzung von Rollenberechtigungen führen kann. In diesem Fall resultierte dies in einem umfassenderen Zugriff als beabsichtigt. Die Überprüfung dieser Annahmen ist daher unerlässlich. Darüber hinaus wird das Gesamtrisiko durch die Mandantenstruktur beeinflusst, insbesondere im Hinblick auf privilegierte Dienstprinzipale, deren Missbrauch weiterhin ein bekanntes und folgenreiches Angriffsmuster darstellt.
Warum man das leicht übersehen konnte
- Eigentümerwechsel bei Dienstprinzipalen können wie normale App-Administratoraktivitäten aussehen, es sei denn, Sie korrelieren, wer die Aktion durchgeführt hat, mit dem Zieldienstprinzipaltyp.
- Rollen, die in der Entra-Benutzeroberfläche nicht eindeutig als hochprivilegiert gekennzeichnet sind, werden möglicherweise mit weniger strenger Prüfung vergeben.
- Es gibt kein eingebautes Signal, das darauf hinweist, wenn eine Rolle außerhalb ihres erwarteten Aufgabenbereichs agiert; dazu ist es erforderlich, die Rollenaktivität mit der betroffenen Ressource zu korrelieren.
Empfehlungen
- Überwachung der Nutzung sensibler Rolleninsbesondere Maßnahmen im Zusammenhang mit der Inhaberschaft des Dienstanbieters oder Änderungen der Zugangsdaten.
- Warnung bei Änderungen der DienstinhaberschaftDies sind einige der wichtigsten Ereignisse im Rahmen der Entra-App-Governance.
- Behandeln Sie privilegierte Dienstherren wie Kronjuwelen.: Prüfen, welche Dienstprinzipale Verzeichnisrollen oder wichtige Graphberechtigungen besitzen; diese schützen und überwachen.
- Erstellung von Prüfberechtigungen für DienstprinzipaleNeue Geheimnisse oder Zertifikate für wichtige Dienstverantwortliche sollten selten sein und überprüft werden.
Erkennungen
HinweisDiese Erkennungen wurden für das beschriebene Problem erstellt, da dieses aber behoben wurde, können sie als Vorlagen zur Identifizierung ähnlicher Muster verwendet werden.
Konten, denen die Agenten-ID „Administrator“ zugewiesen wurde
- Über die Azure CLI: Aktuelle Aufgaben abrufen:
# Role definition ID for Agent ID Administrator
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=roleDefinitionId eq 'db506228-d27e-4b7d-95e5-295956d6615f'" \
--query "value[].principalId" -o tsv
- Über Log Analytics (AuditLogs): Abfrage der Rollenzuweisungsaktivitäten für die Rolle „Agenten-ID-Administrator“ (Tabelle und Zeitbereich nach Bedarf anpassen).
AuditLogs
| where OperationName has "Add member to role"
| where tostring(TargetResources) has "db506228-d27e-4b7d-95e5-295956d6615f" //
Agent ID Administrator
| mv-expand TR = TargetResources
| summarize
Role = max(iff(TR.type == "Role", tostring(TR.displayName), "")),
Assignee = max(iff(TR.type != "Role", tostring(TR.displayName), "")),
AssigneeUPN = max(iff(TR.type != "Role", tostring(TR.userPrincipalName),"")),
AssigneeId = max(iff(TR.type != "Role", tostring(TR.id), ""))
by TimeGenerated,
Result,
Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
tostring(InitiatedBy.app.displayName))
| order by TimeGenerated desc Aktivitäten (Protokollanalyse / Audit-Protokolle)
- Eigentümer zum Dienstprinzipal hinzufügen: erfolgreiche Ereignisse. Passen Sie den Zeitraum bei Bedarf an.
let AgentIdAdminActors = dynamic(["obj-id1","obj-id2"]); // principals assigned
Agent ID Administrator
AuditLogs
| where OperationName == "Add owner to service principal"
| where Result == "success"
| where coalesce(InitiatedBy.user.id, InitiatedBy.app.id) in (AgentIdAdminActors)
| order by TimeGenerated desc - Fügen Sie dem Dienstprinzipal Anmeldeinformationen hinzu.: erfolgreiche Ereignisse.
AuditLogs
| where OperationName == "Add service principal credentials"
| where Result == "success"
| project
TimeGenerated,
OperationName,
Result,
Actor = coalesce(InitiatedBy.user.userPrincipalName,
InitiatedBy.app.displayName),
TargetSP = TargetResources[0].displayName,
TargetSPId = TargetResources[0].id
| order by TimeGenerated desc Offenlegungszeitplan
- 24. Februar 2026 – Sicherheitslücke identifiziert
- 1. März 2026 – Bericht an Microsoft übermittelt (MSRC)
- 3. März 2026 – Fall von Microsoft eröffnet
- 26. März 2026 – Microsoft bestätigte das Verhalten
- 4. April 2026 – Die Fehlerbehebung erreichte den Vorab-Veröffentlichungsstatus und das Verhalten war nicht mehr reproduzierbar.
- 9. April 2026 – MSRC hat bestätigt, dass die Fehlerbehebung vollständig implementiert wurde.
Agentenidentitäten Sie sind Teil des umfassenderen Wandels hin zu nicht-menschlichen Identitäten, die für das Zeitalter der KI-Agenten entwickelt wurden. Die Microsoft Agent Identity Platform ist ein wichtiger Schritt nach vorn für die Verwaltung und Steuerung dieser Identitäten durch Unternehmen.
Diese Studie hebt einen wichtigen Aspekt dieses Modells hervor: Agentenidentitäten basieren auf bestehenden Identitätskomponenten wie Dienstprinzipalen. Werden Rollenberechtigungen ohne strikte Abgrenzung auf gemeinsamen Grundlagen angewendet, kann der Zugriff über die ursprünglich beabsichtigte Reichweite hinausgehen. In diesem Fall führte diese Lücke zu einem umfassenderen Zugriff, insbesondere bei privilegierten Dienstprinzipalen.
Microsoft hat sich dieses Problems angenommen.Dies unterstreicht jedoch eine allgemeinere Erkenntnis: Es ist unerlässlich zu überprüfen, wie Rollen definiert sind und wo Berechtigungen gelten, insbesondere beim Umgang mit gemeinsam genutzten Identitätskomponenten.
Für praktische Hinweise zur Überwachung und Absicherung Ihrer Umgebung siehe Empfehlungen unter dem Takeaways Abschnitt oben.
