Anmerkung der Redaktion: Willkommen zum vierten und letzten Übungsleitfaden der Reihe „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 frühere Kapitel und Übungslektionen noch einmal durchzugehen, beginnen Sie bitte hier.
In Kapitel 5 unseres Leitfadens haben Sie die Agent-Registrierung von Microsoft kennengelernt und deren Verwendung geübt sowie die Abläufe von drei Authentifizierungsabläufen für Agentenidentitäten in Entra ID durchgespielt.
In diesem „Practice Checkpoint“ werden wir die drei besprochenen Abläufe überprüfen, indem wir jeden einzelnen von Anfang bis Ende über Microsoft Graph nachverfolgen und die tatsächlichen Token-Claims in jedem Schritt anzeigen, um alle Zusammenhänge zu verdeutlichen.
Aus Gründen der Einheitlichkeit und Übersichtlichkeit werden wir weiterhin dieselbe Agentenidentität verwenden, die wir in den vorherigen Schritten erstellt haben, und die in den einzelnen Abläufen erzeugten Token überprüfen.
Hier finden Sie eine kurze Zusammenfassung der Informationen, die Sie benötigen:
- Blueprint-ID = 3534ec06-21ea-4080-abd4-95116e260203
- Blueprint-SP-ID = 17a48807-f813-421b-85b9-8c7e794bc4b9
- Agenten-ID = b85d92be-fa90-486b-94ed-b5ad91d35ceb
- User-Agent-ID = 2954440b-1617-46b1-9156-dad15f1f824f
- Vererbbare delegierte Berechtigungen = Group.Read.All
- Direkte, ausschließlich auf die App bezogene Berechtigungen auf der Ebene der Agentenidentität = User.Read.All
Autonomer Durchfluss
In diesem Ablauf muss die Agentenidentität selbst auf eine Ressource zugreifen.
Zunächst müssen wir das T1-Token abrufen. Dies ähnelt dem Abruf eines Zugriffstokens für einen Agent-Identitäts-Blueprint, weist jedoch zwei wesentliche Unterschiede auf:
- Geltungsbereich =
api://AzureADTokenExchange/.default - include fmi_path =
<agent-identity-id>
Wir können das T1-Token entschlüsseln, wobei gilt:
- Oid wird der SP-ID des Entwurfs zugeordnet.
- „azp“ wird der Blueprint-ID der Agentenidentität zugeordnet.
- aud gehört zur Anwendung „AAD Token Exchange Endpoint“, die
api://AzureADTokenExchange.
Mithilfe des T1-Tokens können wir nun das Zugriffstoken für die Agentenidentität abrufen.
Betrachtet man das Graph-Token, so lässt sich Folgendes feststellen:
- Die Behauptung bezieht sich auf Microsoft Graph.
- Die „appid“ sowie der „oid“- Claim entsprechen der ID des Agenten.
- Die Rollen Der Anspruch umfasst die
User.Read.AllBerechtigung, die wir zuvor vergeben und direkt der Agentenidentität als rein app-spezifische Berechtigung zugewiesen haben.
Zu diesem Zeitpunkt kann die Agentenidentität entsprechend ihren reinen App-Berechtigungen den Graph im Mandanten aufrufen.
„Im Auftrag von“-Ablang
In diesem Ablauf führt die Agentenidentität delegierte Aktionen als Benutzer aus und veranschaulicht vererbbare delegierte Gültigkeitsbereiche.
Zunächst müssen wir ein Client-Token (TC) abrufen. Dazu müssen wir zunächst die OAuth2-Berechtigungsbereiche im Blueprint festlegen und dies mit meinem Benutzer bestätigen.
Als nächsten Schritt werden wir über die Benutzeroberfläche eine SAP-Anwendung anlegen.
Wir werden die soeben erstellten Blueprint-Berechtigungen zu unserer DemoSAP-Anwendung hinzufügen:
Für diese Demo werden wir auch den öffentlichen Client-Ablauf zulassen:
Nun können wir ein TC-Token abrufen. Die ClientID ist die soeben erstellte Anwendungs-ID:
Als Nächstes müssen wir die üblichen Einwilligungsabfragen durchgehen.
Dadurch wird das TC-Token zurückgegeben, das mir als Benutzer gehört. Wir können erkennen, dass der „aud“-Eintrag die Blueprint-ID ist:
Nun können wir das T1-Token mit derselben Methode abrufen, die wir bereits verwendet haben.
Bevor wir fortfahren, müssen wir unsere Zustimmung erteilen, damit die Agentenidentität im Namen unseres Benutzers handeln kann. Dies geschieht über einen standardmäßigen OAuth2PermissionGrants-Aufruf mit dem Geltungsbereich, den wir als vererbbare Berechtigungen zugewiesen haben.
Falls Sie im Abschnitt „Konfiguration vererbbarer Berechtigungen“ bereits „AllPrincipals“ zugestimmt haben, können Sie diesen Aufruf überspringen.
Schließlich können wir mithilfe der TC- und T1-Token das Zugriffstoken (TR) abrufen.
Das entschlüsselte Zugriffstoken lautet wie folgt:
- SCP-Anspruch mit den vererbbaren „Group.Read.All“-Berechtigungen, die wir zuvor auf Blueprint-Ebene hinzugefügt haben.
- Der Anzeigename der App und der „appid“-Claim, die die Identität des Agenten angeben, der im Namen des Benutzers handelt.
- Die Claims „idtyp“, „name“ und „oid“ gehören alle dem Benutzer (da es sich um ein delegiertes Token handelt).
Benutzerablauf des Agenten
Dieser Ablauf ist für einen Agentenbenutzer relevant, der Aktionen im Benutzerkontext ausführen muss.
Wie beim autonomen Ablauf mit Agentenidentität müssen wir ein T1-Token erhalten.
Als Nächstes müssten wir zustimmen, dass die Agentenidentität im Namen des Agentenbenutzers handeln darf, so wie wir es im OBO-Ablauf getan haben.
Dieses Mal werden wir die Benutzer-ID des Agenten als Prinzipal-ID angeben. Falls Sie im Abschnitt „Konfiguration vererbbarer Berechtigungen“ bereits „AllPrincipals“ zugestimmt haben, können Sie diesen Aufruf überspringen.
Nun können wir mithilfe des T1-Tokens das T2-Token erhalten.
Das entschlüsselte T2-Token enthält die Claims „azp“, „oid“ und „sub“, die alle auf die ID des Agenten gesetzt sind.
Mithilfe der T1- und T2-Token können wir das TR-Zugriffstoken abrufen.
Wie wir sehen können, wurde dieses Zugriffstoken für Microsoft Graph ausgestellt. Es enthält folgende Angaben:
- Die Angabe „idtyp“ bezieht sich auf einen Benutzer
- Die OID -Angabe entspricht der Benutzer-ID des Agenten
- „appid“ ist auf die ID des Agenten gesetzt, der der übergeordnete Benutzer des Agenten ist.
- scp enthält die
Group.Read.All, die Zielfernrohre, die wir zuvor angebracht haben.
Nun verfügen Sie über eine funktionierende Agentenidentität. Wie schützen Sie diese?
Durch den Aufbau Ihrer Agentenidentität im Rahmen dieser Übungssitzungen sollten Sie ein praktisches Verständnis dafür gewonnen haben, wie Agenten in Ihrem Entra ID-Mandanten arbeiten werden.
Lesen Sie nun das letzte Kapitel unseres Leitfadens, um sich einen Überblick darüber zu verschaffen, was schiefgehen kann – und wie Sie diese neuen Identitäten schützen können.
Erfahren Sie in Kapitel 6, wie Sie Katastrophen verhindern können.
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
- Kapitel 4: Agentenidentitäten: Ein tiefer Einblick in das Design
- Übungs-Checkpunkt 2: Festlegen der Berechtigungen für die Agentenidentität
- Kapitel 5: Das Agentenregister und die Funktionsweise von Agentenidentitäten in Entra ID
- Übungsschritt 3: Registrierung eines Agenten – mit und ohne Agenten-ID
- Kapitel 6: Wo es bei den Agentenidentitäten in Entra ID zu Problemen kommen könnte – und wie man eine Katastrophe verhindert
