Wenn ein KI-Agent die Anmeldeinformationen eines menschlichen Benutzers verwendet, um auf Datenbanken zuzugreifen, erhält das System keine verborgene „Agentenidentität“ hinter dem Konto; es sieht den Benutzer selbst. Dies ist die zentrale Schlussfolgerung einer Messung von Naseeb Ahmed Mian in einer Produktionsumgebung mit Azure, Azure CLI und sqlcmd.
In der untersuchten Konfiguration stellten die Fähigkeiten des Software-Agenten über den Befehl sqlcmd unter Verwendung der Authentifizierung durch Azure CLI eine Verbindung zu den Datenbanken her. Der Befehl rief das nach der Benutzeranmeldung zwischengespeicherte Zugriffstoken ab und übergab es an die Datenbank. Infolgedessen erschienen die Verbindungen unter dem Namen des Benutzers, zusammen mit seinem Gerätenamen und dem Tool sqlcmd – unabhängig davon, ob er die Abfrage selbst schrieb oder der Agent sie ausführte.
Das Auditprotokoll sieht die Anmeldeinformationen, nicht die Absicht
Das Sitzungsprotokoll zeigte den Anmeldenamen des Benutzers, den Namen der Arbeitsstation und die Client-Schnittstelle, enthielt jedoch kein Feld, das die vom Agenten ausgeführten Aktionen unterschied. Dadurch sind menschliche und automatisierte Abfragen im Protokoll identisch, und nachgelagerte Kontrollen können auf Grundlage der Ausführungsquelle weder eine unterschiedliche Ratenbegrenzung noch einen Genehmigungsschritt oder eine andere Aufbewahrungsrichtlinie anwenden.
Das Problem beschränkt sich nicht auf Sicherheitsuntersuchungen. Wird eine vor Monaten ausgeführte Abfrage später angefochten, kann das Protokoll nicht belegen, ob der Benutzer sie geschrieben hat oder ein automatisiertes Tool sie gestartet hat. Es ordnet die Aktion den Anmeldeinformationen präzise zu, schweigt jedoch über die Absicht und den tatsächlichen Akteur.
Was gibt das Zugriffstoken preis?
Das von Azure CLI übergebene Token enthielt den Bereich user_impersonation sowie einen Claim, der darauf hinwies, dass die Authentifizierung einen Multi-Faktor-Authentifizierungsfaktor umfasste. Praktisch kommt jede vom Agenten ausgeführte Aktion mit dem Nachweis, dass der Benutzer die Multi-Faktor-Authentifizierung erfolgreich durchlaufen hat – selbst wenn dies Stunden zuvor und im Rahmen einer anderen Aufgabe geschah.
Auch die Tokenlaufzeit von 84 Minuten stellt nicht zwangsläufig das Ende der Ausführung des Agenten dar. Die CLI erneuert das Token automatisch mithilfe eines Aktualisierungstokens. Daher kann die unbeaufsichtigte Ausführung fortgesetzt werden, bis das Aktualisierungstoken abläuft oder das Benutzerkonto deaktiviert wird.
Gruppenmitgliedschaften erweitern das Bild
Die Prüfung der Rollenzuweisungen zeigte nur eine einzige Zeile: die Rolle „Reader“ in einem Nichtproduktionsabonnement. Das Zugriffstoken enthielt jedoch 37 Gruppen, während eine Abfrage der direkten Mitgliedschaften 34 Gruppen ergab; dabei gab es verschachtelte Gruppen. Zu den für den Zugriff relevanten Gruppen gehörten Rollen wie SQL-Datenbank-Viewer, Benutzer mit erhöhten Berechtigungen, Ressourcenmitwirkender und Datenbankadministrator.
Die Gefahr besteht darin, dass diese Mitgliedschaften die tatsächlichen Berechtigungen auf der Datenebene enthalten können und bei Prüfungen der Rollen auf der Steuerungsebene nicht unbedingt sichtbar sind. Daher kann der Zugriffsbereich des Agenten bei einer herkömmlichen Überprüfung begrenzt erscheinen, während ihm die Gruppenmitgliedschaft größere Befugnisse verleiht.
Was ändert sich praktisch?
Bei der Prüfung derselben Identität auf zwei Produktionsspeichern im Abstand von einer Stunde zeigten sich zwei stark voneinander abweichende Ergebnisse. In einem Fall besaß die Identität nur die Berechtigungen CONNECT und SELECT und konnte keine Verbindung zur sicheren Ebene herstellen. Ein anderer produktiver Analyseendpunkt zeigte dagegen 430 Tabellen und 107 Berechtigungen, darunter Lese- und Schreibzugriff, Schemadefinition und Datenbankverwaltung.
Der Vergleich macht deutlich, dass der Berechtigungsumfang nicht allein durch die Identität bestimmt wird; auch der Zugriffspfad, die Engine und die mit dem Endpunkt verbundenen Kontrollen sind entscheidende Faktoren. Ein Endpunkt kann laut Dokumentation schreibgeschützt sein, während seine Sicherheitsregeln nicht zwangsläufig übernommen werden, wenn die Daten über eine andere Engine abgerufen werden.
Die redaktionelle Einordnung von certi.news: Das Problem besteht nicht darin, dass der Agent „keine Identität“ hat, sondern darin, dass die Identität des Menschen als schneller Ersatz für eine unabhängige Maschinenidentität verwendet wurde. Dies versagt an drei Stellen: Zuordnung, Ausweitung der Berechtigungen und Widerruf. Die Messung zeigte außerdem, dass die Umgebung, in der die Anmeldeinformationen die Möglichkeit zum Löschen aus einer sicheren Datenbank besaßen, die einzige Umgebung ohne aktiviertes Auditprotokoll war. Wichtige Fragen bleiben hinsichtlich der Konsistenz der Gruppenmitgliedschaften, des Fortbestehens temporärer Berechtigungen in ausgestellten Tokens und der Fähigkeit von Organisationen offen, die Ausführungsabsicht und nicht nur den Inhaber der Anmeldeinformationen zu protokollieren.