Semion Vasilevitzky und Jonathan Elkabas

Anmerkung der Redaktion: Willkommen zu Kapitel 6 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 frühere Kapitel und Übungsaufgaben noch einmal durchzugehen, beginnen Sie bitte hier.

Die Agent-ID-Plattform führt neue Identitätsarten und Betriebsmuster ein, und da sich diese Funktion erst in der Anfangsphase ihrer Entwicklung befindet, treten ihre tatsächlichen Fehlkonfigurationen und Angriffspfade erst allmählich zutage. In diesem Abschnitt werden wir nicht versuchen, jedes mögliche Risiko oder jede Schwachstelle abzudecken. Stattdessen werden wir eine kleine Auswahl einfacher, aber wichtiger Fehlkonfigurationen hervorheben, die wahrscheinlich häufiger auftreten werden, sobald Unternehmen damit beginnen, Agent-ID in großem Maßstab einzuführen.


Wem gehört dieser Makler? Makler-IDs ohne Eigentümer und ohne Sponsor

Nicht verwaltete Agentenidentitäten (d. h. solche ohne Eigentümer und Sponsor) führen zu einer Lücke in der Identitätsverwaltung. Wenn keine verantwortliche Person oder kein verantwortliches Team zugewiesen ist, besteht eine höhere Wahrscheinlichkeit, dass diese Workload-Identitäten bei Audits übersehen und bei incident response nicht erfasst werden.

Auf der Übersichtsseite „Entra-Agent-ID“ können wir die Anzahl der nicht verwalteten Agentenidentitäten einsehen.

Abbildung 1. Anzeige nicht verwalteter Agentenidentitäten in der Microsoft Agent-ID-Übersicht

Obwohl bei der Erstellung einer Agentenidentität mindestens ein Sponsor angegeben werden muss, kann es dennoch vorkommen, dass Identitäten im Laufe der Zeit nicht mehr verwaltet werden. Diese Situation könnte beispielsweise eintreten, wenn ein Benutzer, der als Sponsor fungierte, gelöscht wurde, etwa nach seinem Ausscheiden aus der Organisation.

Eine weitere ähnliche Situation, die jedoch nicht auf der Übersichtsseite angezeigt wird, tritt auf, wenn das Sponsor- oder Eigentümerkonto deaktiviert wird. In diesen Fällen scheint die Agentenidentität zwar einen zugewiesenen Eigentümer oder Sponsor zu haben, doch ist das zugewiesene Konto innerhalb der Organisation nicht mehr aktiv. Dadurch wird die Identität praktisch „verwaist“ und kann von Administratoren leicht übersehen werden.

Im Idealfall sollte für jede Agentenidentität stets eine aktive Person verantwortlich sein, die sich ihres Zwecks bewusst ist. Die Gewährleistung einer kontinuierlichen Verantwortlichkeit ist ein wesentlicher Bestandteil der Identitätsverwaltung.

In Semperis Lightning Intelligence sowie Directory Services Protector DSP)– zwei Lösungen, die Teil der Identity Resilience Platform– weisen wir bereits auf diese beiden Situationen hin. In einem übersichtlichen Dashboard sehen Sie nicht nur die Anzahl der nicht verwalteten Agentenidentitäten, sondern auch die genaue Liste.

Abbildung 2. Anzeige nicht verwalteter Agentenidentitäten auf der Semperis-Plattform

Sie können außerdem die besprochenen verwaisten Agentenidentitäten einsehen und erfahren, welche Sponsoren oder Eigentümer genau deaktiviert sind, wodurch diese Agentenidentitäten in der Praxis verwaist sind.

Abbildung 3. Aufdeckung der Identität der Sponsoren und Eigentümer deaktivierter Agenten

Wer kennt mein Geheimnis? Blaupausen unter Verwendung von Client-Geheimnissen

Wie wir bereits im Praxis-Checkpoint 1 dieses Leitfadens beschrieben haben, ist ein Client-Secret einer der Anmeldedaten-Typen, die einer Agent-Identitätsvorlage zugewiesen werden können. Dieser Anmeldedaten-Typ gilt als unsicher, da er häufig in Konfigurationsdateien, Skripten, CI/CD-Pipelines oder Quell-Repositorys gespeichert wird, wo er unbeabsichtigt offengelegt werden kann. Erlangt ein Angreifer ein Client-Secret, kann er sich als diese Agent-Identitätsvorlage oder als die damit verbundenen Agent-Identitäten authentifizieren, ohne dass eine interaktive Anmeldung oder MFA erforderlich ist.

Microsoft warnt ausdrücklich davor, dass:

Aufgrund von Sicherheitsrisiken sollten Client-Geheimnisse in Produktionsumgebungen nicht als Client-Anmeldedaten für Agent-Identitätsvorlagen verwendet werden.

Stattdessen empfiehlt Microsoft die Verwendung von FIC-Anmeldedaten (Federated Identity Credentials) in Verbindung mit verwalteten Identitäten oder Zertifikaten zur Authentifizierung.

Mit den Semperis-Indikatoren haben Sie die Möglichkeit, alle Identitäts-Blueprints für Agenten mit geheimen Daten an einem zentralen Ort zu verfolgen und die genau falsch konfigurierten Anmeldedaten jedes einzelnen Blueprints einzusehen.

Abbildung 4. Einblick in falsch konfigurierte Anmeldedaten der Agent-Identitätsvorlage

Zu viel Macht: Identitäten von Akteuren mit besonders großen Privilegien

Bisher haben wir darüber gesprochen, wie Agenten „App-only“- oder delegierte Berechtigungen erhalten und wie die Rollenzuweisung in diesem Modell aussieht. Obwohl Microsoft einschränkt, welche Berechtigungen und Rollen Agentenidentitäten zugewiesen werden können, ist die Anwendung des Prinzips der geringsten Berechtigungen nach wie vor von entscheidender Bedeutung.

Berechtigungen mit hohen Privilegien für eine Agentenidentität erhöhen das Risiko selbst dann, wenn kein Angreifer vorhanden ist. Agentenidentitäten können automatisch ausgeführt werden und Aktionen in großem Umfang durchführen. Wenn ein Agent falsch konfiguriert ist, sich unerwartet verhält oder nicht korrekt in einen Arbeitsablauf integriert ist, können hohe Privilegien einen einfachen Fehler zu einem mandantenweiten Vorfall machen. Aus Sicherheitssicht vergrößern Agentenidentitäten mit übermäßigen Privilegien die Angriffsfläche und würden zu einem Ziel für Angreifer werden.

Organisationsadministratoren sollten die den Agentenidentitäten zugewiesenen Berechtigungen regelmäßig überprüfen und auf das für den Betrieb des Agenten erforderliche Minimum beschränken.

Die Semperis-Indikatoren zeigen Ihnen an einem Ort die Identitäten der Agenten mit besonders weitreichenden Berechtigungen sowie deren genaue Rollen mit übermäßigen Berechtigungen an.

Abbildung 5. Identifizierung von Rollen mit übermäßigen Berechtigungen

Schlussfolgerungen

Agentenidentitäten sind nicht nur ein weiteres Kontrollkästchen im Microsoft Entra-Verwaltungscenter. Sie stellen den Versuch von Microsoft dar, KI-Agenten eine formale Identität innerhalb des Verzeichnisses zu verleihen. Kein vages Automatisierungsobjekt. Nicht nur ein Dienstprinzipal, der eine neue Rolle einnimmt. Ein neues Identitätsmodell, das versucht, Agenten als etwas darzustellen, das die Plattform erkennen, steuern, autorisieren und prüfen kann.

Und das ist von Bedeutung, denn in dem Moment, in dem ein Agent eine Systemgrenze überschreiten, eine API aufrufen, Organisationsdaten lesen, den Status aktualisieren, eine Nachricht senden, auf ein Postfach zugreifen oder im Namen einer Instanz handeln muss, die größer ist als er selbst, handelt es sich nicht mehr nur um „KI-Logik“. Er wird zu einem Teilnehmer am Identitätssystem. Er benötigt einen Prinzipal. Er benötigt Berechtigungen. Er benötigt ein Token. Er benötigt einen Eintrag im Verzeichnis.

Agent ID ist die Antwort von Microsoft auf diesen Bedarf.

Im Zentrum dieses Modells steht der „Agent Identity Blueprint“ – die Vorlage, auf deren Grundlage Agentenidentitäten erstellt werden und über die vererbte Berechtigungen weitergegeben werden können. Um dieses Modell herum hat Microsoft mehrere zugehörige Objekte eingeführt: Agentenidentitäten, Agentenbenutzer, Blueprint-Prinzipale und durch Service-Principals gestützte Legacy-Agenten. Zusammen bilden sie eine neue operative Ebene für KI-Agenten innerhalb von Entra ID.

Wie wir jedoch im Laufe dieses Leitfadens gesehen haben, existiert die Agent-ID nicht isoliert. Sie baut auf bestehenden Entra-ID-Grundelementen auf, und diese Grundelemente sind bereits mit einer bestimmten Struktur, Berechtigungen, Annahmen und historischem Ballast verbunden.

Agentenidentitäten leiten sich von Dienstprinzipalen ab. Agentenbenutzer leiten sich von Benutzern ab. Blueprints leiten sich von Anwendungen ab. Berechtigungen werden über die bekannten OAuth-Mechanismen und Mechanismen zur Zuweisung von App-Rollen weitergegeben. Die Durchsetzung von Rollen hängt weiterhin von RBAC-Aktionen, API-Prüfungen und dem Laufzeitverhalten ab. Die Bezeichnungen sind neu, doch die zugrunde liegende Steuerungsebene ist sehr vertraut.

Und um ehrlich zu sein, liegt darin sowohl die (operative) Stärke als auch das (Sicherheits-)Risiko des Modells.

Das bedeutet, dass sich die Agent-ID nahtlos in Entra ID, Microsoft Graph, Audit-Protokolle, App-Berechtigungen und bestehende Verwaltungsabläufe integrieren lässt. Es bedeutet aber auch, dass jede geerbte Funktion, jede verborgene Annahme und jedes alte Problem im Zusammenhang mit dem Geltungsbereich in einem neuen Kontext wieder an Bedeutung gewinnt.

Agentenidentitäten schaffen eine neue Angriffsfläche, und wir müssen damit rechnen, dass neue Angriffswege entstehen, sobald Unternehmen damit beginnen, diese einzusetzen. Einige davon werden wahrscheinlich auf Blueprints mit zu weitreichenden Berechtigungen zurückzuführen sein. Manche von unklaren Rollenabgrenzungen. Manche von geerbten Berechtigungen, die die Sicherheitsverantwortlichen noch nicht korrekt erfassen. Manche davon, dass Agenten-Benutzer Bereiche nutzen, die ursprünglich für menschliche Benutzer konzipiert wurden. Manche von „Conditional Access“ und dem Verhalten von Tokens, das noch eingehender in der Praxis getestet werden muss. Und manche, wie immer, von den unscheinbaren Stellen, die niemand beachtet hat, weil sie im Portal und in der Dokumentation harmlos erschienen.

Wichtig ist, dass man Agenten nicht als etwas Magisches oder als etwas betrachtet, das von dem, was wir bereits wissen, getrennt ist, denn sie sind Identitäten.

Und Identitäten werden authentifiziert, autorisiert, führen Aktionen aus und hinterlassen Spuren. Der altbekannte AAA-Zyklus trägt nun eine Maske in Form von KI.

Wenn es also eine praktische Erkenntnis aus dieser Untersuchung gibt, dann ist es diese.

Beschränken Sie sich nicht auf die Portalbezeichnung oder die Dokumentationstabelle. Orientieren Sie sich am Objektmodell. Verfolgen Sie die Vererbungsstruktur. Verfolgen Sie das Token. Verfolgen Sie die Berechtigungen. Verfolgen Sie die Rollenaktionen. Verfolgen Sie die Überwachungs- und Anmeldeprotokolle. Das tatsächliche Verhalten der Plattform zeigt sich in der Regel irgendwo zwischen dem, was das Schema beschreibt, dem, was die Dokumentation verspricht, und dem, was die Laufzeit tatsächlich zulässt.

Da sich die Agent-ID ständig weiterentwickelt, werden die schwierigen Fragen nicht nur technischer Natur sein. Es werden Fragen des Vertrauens sein: Wie viel Zugriff sind wir bereit, diesen Identitäten zu gewähren, wie klar können wir nachvollziehen, was sie tun, und wie gut kann die Plattform Grenzen um sie herum durchsetzen, sobald sie in großem Maßstab zum Einsatz kommen?

Denn Agenten sind nicht einfach nur Code, der still im Hintergrund läuft. Es handelt sich um Code mit Handlungsfähigkeit, der mit einer Identität verbunden ist, Berechtigungen besitzt, Entscheidungen trifft und im Namen einer anderen Person oder Sache Grenzen überschreitet.

Und sobald Code Handlungsfähigkeit, Identität und Vertrauen besitzt, ist er mehr als nur „Automatisierung“.

Es wird zu einem delegierten Willen innerhalb des Systems, der unsere Berechtigungen, unsere Annahmen und letztendlich auch unsere Konsequenzen in sich trägt.


Raten Sie nicht – scannen Sie. Wie kann Semperis Ihnen dabei helfen?

Die Tools von Semperis bieten bereits die Möglichkeit, Lücken in der Governance zu identifizieren, potenzielle Schwachstellen aufzuzeigen und dabei zu helfen, derartige Fehlkonfigurationen und Risiken aufzudecken. Dieser Bereich befindet sich noch in der Entwicklung, und hier bei Semperis arbeiten wir bereits an zusätzlichen Indikatoren für Schwachstellen sowie an erweiterten Erkennungsfunktionen, die im Laufe der Zeit eingeführt werden sollen.

Wenn Sie die Nutzung von Agentenidentitäten in Ihren Identitätssystemen ausweiten, werden Sie sicherlich bei jedem Schritt auf neue Fragen stoßen. Wenden Sie sich jederzeit an uns; wir helfen Ihnen gerne weiter.


Weitere Lektüre


Entdecken Sie den Leitfaden