Unit 42 Cloud Identities Research zeigt die Grenzen berechtigungsbasierter Sicherheit auf

Unit 42 analysierte mehr als 40.000 Cloud-Identitäten und legte damit einen Konflikt offen, den Berechtigungsprüfungen allein nicht lösen können. Die Unit 42 Cloud Identities Research argumentiert, dass Sicherheitsteams verstehen müssen, was eine Identität tatsächlich tut – nicht nur, was sie tun kann.

Die am 14. September 2026 veröffentlichte Studie erfasst Aktivitäten aus 125 Cloud-Umgebungen über einen Beobachtungszeitraum von zwei Monaten. Ihr Modell gruppiert Identitäten anhand der in AWS CloudTrail protokollierten Vorgänge. Diese Gruppen entsprechen erkennbaren Rollen, darunter Administratoren, Backup-Agenten, Sicherheitstools, DevOps-Nutzer und Continuous-Delivery-Systeme.

Im Kern steht der Gegensatz zwischen der Ableitung von Verhaltensrollen und statischen Identitätsbezeichnungen. Ein vertrauenswürdiger Name, eine bekannte Richtlinie oder gültige Zugangsdaten können bestehen bleiben, nachdem ein Angreifer den Zweck einer Identität verändert hat. Unit 42 schlägt vor, beobachtetes Verhalten in Rollenkontext zu überführen und Abweichungen von diesem Kontext zur Verbesserung automatisierter Erkennung zu nutzen.

Unit 42 ordnete Identitäten anhand von Aktionen statt Namen zu

Die Studie verändert die Identitätsanalyse, indem sie API-Aktivitäten als Beleg für die operative Rolle einer Identität behandelt.

Die Forschung zu Verhaltensidentitäten geht von einem praktischen Problem aus. Cloud-Landschaften umfassen heute Mitarbeitende, Anwendungen, Deployment-Pipelines, Sicherheitsprodukte und autonome Agenten. Ihre Namen und zugewiesenen Berechtigungen verraten oft wenig über ihre aktuelle Funktion.

Eine Identität namens „backup“ könnte legitim jede Nacht einen bestimmten Storage-Bucket lesen. Dieselbe Identität könnte später Nutzer auflisten, Richtlinien prüfen oder Compute-Ressourcen erstellen. Diese Aktionen wären relevant, selbst wenn ihr Name und ihre Berechtigungen unverändert blieben.

Unit 42 repräsentierte jede Identität anhand der AWS-Vorgänge, die sie während des Untersuchungszeitraums aufrief. Anschließend verglichen die Forschenden diese Verhaltensprofile über die teilnehmenden Umgebungen hinweg. Ähnliche Kombinationen von Vorgängen führten Identitäten in unterschiedliche Gruppen.

Die resultierende Karte umfasste 30 große Cluster mit ungefähr 20.000 Identitäten. Die Forschenden ordneten diese Cluster wiederkehrenden Funktionen wie Administration, Infrastrukturautomatisierung, Netzwerkbetrieb, Sicherheit, Backup, FinOps und Datendiensten zu.

Der administrative Cluster lieferte das deutlichste Beispiel. Er enthielt rund 5.000 Identitäten über mehr als 100 Cloud-Projekte hinweg. Etwa 94 Prozent seiner Identitäten erzeugten ConsoleLogin-Ereignisse, verglichen mit weniger als 1 Prozent in anderen Clustern.

Rund 60 Prozent riefen außerdem Vorgänge auf, die mit normaler Konsolenaktivität verbunden sind, darunter GetCostAndUsage und GetCostForecast. Diese Vorgänge halfen dabei, interaktive Administratoren von Maschinenidentitäten zu unterscheiden, die einen engeren Satz von APIs nutzen.

Diese Evidenz ist wichtig, weil kein einzelnes Ereignis eine Absicht belegt. ConsoleLogin weist auf eine interaktive Anmeldung hin, beweist aber nicht, dass der Nutzer ein Administrator ist. Anfragen zur Kostenverwaltung können auch automatisch auftreten, wenn die Konsole geladen wird.

Unit 42 kombinierte vier Analyseformen, um sich nicht auf ein einzelnes bequemes Signal zu stützen. Untersucht wurden die Häufigkeit von Vorgängen, unterscheidende Vorgänge, Identitätsattribute und wiederkehrende Namensmuster innerhalb jedes Clusters.

Ein Namensmuster war besonders aufschlussreich. AWS IAM Identity Center erzeugt ein erkennbares Präfix, wenn AdministratorAccess über seinen Standard-Berechtigungssatz zugewiesen wird. Das Präfix erschien häufig im administrativen Cluster und stützte die verhaltensbezogene Interpretation.

Namen dienten als unterstützende Evidenz, nicht als Grundlage des Modells. Diese Unterscheidung verhindert, dass die Methode lediglich bereits an Identitäten angehängte Bezeichnungen wiederentdeckt. Sie macht den Ansatz auch nützlicher, wenn Namen vage, veraltet oder absichtlich irreführend sind.

Die Studie berichtet nicht über einen neu beobachteten Sicherheitsvorfall oder eine Schwachstelle. Sie stellt ein Erkennungsdesign vor, das auf realen Betriebs-Telemetriedaten basiert. Ihr Nachrichtenwert liegt darin, die Klassifizierung von Cloud-Identitäten skalierbarer und nachvollziehbarer zu machen.

Die meisten Identitätsinventare beantworten, wem Zugangsdaten gehören und welche Aktionen ihre Richtlinien erlauben. Unit 42 fügt eine dritte Frage hinzu: Welche funktionale Rolle offenbart die Aktivität der Identität? Diese zusätzliche Ebene erzeugt die Spannung, die die gesamte Studie prägt.

Statische Berechtigungen lassen die wichtigste Frage offen

Eine Berechtigung zeigt Verteidigern, was möglich ist, während Verhalten offenlegt, welche Fähigkeiten eine Identität gerade ausübt.

Richtlinien für Identity and Access Management bleiben unverzichtbar. Sie bestimmen, ob ein Prinzipal ein Geheimnis lesen, eine Instanz starten, Protokollierung verändern oder eine andere Rolle übernehmen darf. Das Prinzip der minimalen Berechtigung begrenzt den Schaden, den kompromittierte Zugangsdaten verursachen können.

Eine Richtlinienanalyse kann die operative Realität jedoch nicht vollständig beschreiben. Unternehmen gewähren häufig weitreichende Zugriffe, um Deployments oder Notfallarbeiten nicht zu blockieren. Ältere Rollen sammeln zudem Berechtigungen an, wenn sich Projekte, Teams und Verantwortlichkeiten ändern.

Einige überprivilegierte Identitäten arbeiten über Jahre hinweg unbedenklich. Andere werden nach dem Diebstahl von Zugangsdaten zu wertvollen Einstiegspunkten. Das Berechtigungsdokument wirkt in beiden Fällen riskant, kann jedoch nicht zeigen, welche Identität begonnen hat, außerhalb ihrer etablierten Funktion zu handeln.

Verhaltenskontext liefert diese fehlende Unterscheidung. Ein Backup-Prozess, der wiederholt auf ein geschütztes Ziel zugreift, schafft eine eng gefasste Ausgangsbasis. Ressourcenaufzählung, Identitätserkundung oder administrative Änderungen würden eine bedeutende Abweichung von dieser Basis darstellen.

Derselbe API-Aufruf kann in einem anderen Kontext ein anderes Risiko bergen. ListBuckets könnte von einem Sicherheitsinventarprodukt erwartet werden. Bei einer Arbeitslast, die historisch Anwendungsprotokolle in einen einzigen Bucket geschrieben hat, würde er eine genauere Prüfung verdienen.

Deshalb setzt die Unit 42 Cloud Identities Research reine Posture-Security-Programme unter Druck. Cloud Security Posture Management erkennt übermäßige Berechtigungen und Konfigurationsprobleme. Es erklärt nicht automatisch, ob beobachtete Aktionen der tatsächlichen Aufgabe einer Identität entsprechen.

Angreifer profitieren von dieser Lücke. Sie können vorhandene Zugangsdaten, geerbte Richtlinien und harmlos wirkende Ressourcennamen verwenden. Ihre Aktivitäten erscheinen dann unter einer Identität, die Sicherheitsteams bereits kennen.

Für eine Tarnung muss der Kontoname nicht geändert werden. Ein Angreifer muss nur schädliche Vorgänge über eine Identität ausführen, die Verteidiger als vertrauenswürdig betrachten. Statische Inventare können dieses Vertrauen bewahren, nachdem sich das Verhalten verändert hat.

AWS setzt bereits Verhaltensanalysen in seinem verwalteten Dienst zur Bedrohungserkennung ein. Laut seiner Dokumentation zur Anomalieerkennung erstellt GuardDuty Profile aus Feldern von CloudTrail-Ereignissen, um anomale oder nicht autorisierte Aktivitäten zu erkennen.

GuardDuty berücksichtigt außerdem Faktoren wie die anfragende Identität, API und den Standort. Seine Findings können Aktivitäten identifizieren, die mit Credential Access, Discovery, Persistenz, Privilege Escalation, Exfiltration und Impact verbunden sind.

Diese bestehende Fähigkeit bestätigt die grundsätzliche Richtung, hebt den Beitrag von Unit 42 jedoch nicht auf. Verwaltete Erkennungen präsentieren üblicherweise Findings, nachdem die Modelle und Regeln eines Anbieters verdächtige Aktivitäten identifiziert haben. Kunden haben nur begrenzte Einsicht in die genaue Ausgangsbasis oder den Klassifizierungsprozess.

Unit 42 konzentriert sich darauf, eine funktionale Rolle zuzuweisen, die Verteidiger verstehen und wiederverwenden können. Das Modell fragt, ob sich eine Identität wie ein Administrator, ein Deployment-System, ein Scanner oder ein Backup-Dienst verhält. Diese Rolle kann nachfolgende Erkennungen anreichern.

Die Unterscheidung verändert auch die Triage. Ein unbekannter API-Aufruf ist nicht automatisch bösartig, und ein gängiger API-Aufruf ist nicht automatisch harmlos. Analysten müssen die Aktion mit der erwarteten Funktion der Identität vergleichen.

Dadurch entsteht Druck auf Anbieter von Cloud-Sicherheit, interne Erkennungsteams und Plattformen für Identity Governance. Jede dieser Gruppen muss Berechtigungsdaten mit Laufzeitaktivitäten verbinden. Ein Produkt, das nur eine Seite zeigt, zwingt Analysten dazu, die andere manuell zu rekonstruieren.

Der Druck steigt, da sich nichtmenschliche Identitäten vermehren. Workloads, CI/CD-Systeme, Servicekonten, Automatisierungstools und KI-Agenten können kontinuierlich handeln. Ihr Verhaltensvolumen macht eine manuelle Klassifizierung unpraktisch.

Die Antwort von Unit 42 besteht nicht darin, Berechtigungen zu verwerfen. Vielmehr sollen erlaubte Fähigkeiten mit beobachteten Vorgängen kombiniert werden. Beide Perspektiven beantworten unterschiedliche Fragen und werden nützlicher, wenn sie gemeinsam bewertet werden.

So funktioniert das Clustering von Unit 42 Cloud Identities

Unit 42 nutzt unüberwachtes Clustering, um Verhaltensrollen zu entdecken, und verdichtet diese Erkenntnisse anschließend zu einfacheren Klassifikatoren.

Die erste Phase beginnt mit Cloud-Audit-Logs. AWS CloudTrail zeichnet Ereignisse auf, die von Nutzern, Rollen und Diensten erzeugt werden, einschließlich der betreffenden Identität und API. AWS erläutert diese Felder in seiner CloudTrail-Ereignisreferenz.

Unit 42 wandelt jede Identität in einen booleschen Vektor um. Jede Position steht für einen verfügbaren Vorgang, während true oder false erfasst, ob die Identität diesen Vorgang im Beobachtungsfenster aufgerufen hat.

Dadurch entsteht ein schwieriger Datensatz. Laut der Studie stellt AWS über ungefähr 240 Dienste hinweg mehr als 15.000 mögliche Vorgänge bereit. Die meisten Identitäten rufen nur eine kleine Teilmenge auf, wodurch große und überwiegend leere Vektoren entstehen.

Die Pipeline nutzt Uniform Manifold Approximation and Projection, kurz UMAP, zur Reduzierung dieser Vektoren. UMAP wandelt hochdimensionale Beobachtungen in kleinere Repräsentationen um und versucht dabei, aussagekräftige Nachbarschaftsstrukturen zu erhalten.

Die Forschenden verwendeten Kosinusähnlichkeit als Distanzmaß. Dieses Maß vergleicht die Richtung zweier Vektoren statt ihrer absoluten Größe. Es betont, welche Vorgänge Identitäten gemeinsam haben, statt jene Identität zu bevorzugen, die mehr Aktivität erzeugt hat.

Ein UMAP-Durchlauf erzeugte dichte Repräsentationen mit 32 kontinuierlichen Werten. Ein separater Durchlauf projizierte die Identitäten zur Visualisierung in zwei Dimensionen. Diese beiden Ausgaben erfüllen unterschiedliche Zwecke und sollten nicht als austauschbar behandelt werden.

Die dichte Repräsentation wird anschließend in HDBSCAN überführt, eine Clustering-Methode, die Regionen mit hoher Punktdichte identifiziert. Anders als Algorithmen, die eine feste Anzahl von Gruppen erfordern, kann HDBSCAN Cluster entdecken und ungewöhnliche Punkte als Rauschen markieren.

Beide Methoden verfügen über etablierte Forschungsgrundlagen. Das ursprüngliche UMAP-Paper beschreibt die Technik zur Dimensionsreduktion, während das HDBSCAN-Paper hierarchisches dichtebasiertes Clustering behandelt.

Sobald Identitäten Cluster-Zuweisungen erhalten, müssen Analysten jede Gruppe weiterhin interpretieren. Eine Cluster-Kennung wird nicht mit einem Label wie „Administrator“ oder „Backup-Dienst“ geliefert. Die Studie wendet daher mehrere Tests an, um ihre Rolle abzuleiten.

Die Häufigkeit von Vorgängen zeigt, welche APIs in einem Cluster durchgehend auftreten. Eine klassenbasierte Bewertungsmethode identifiziert Vorgänge, die innerhalb einer Gruppe häufig vorkommen, außerhalb jedoch selten bleiben. Damit lassen sich bloß populäre APIs von tatsächlich unterscheidenden Signalen trennen.

Die Attributzuordnung fügt eine weitere Perspektive hinzu. Forschende können Identitäten hervorheben, die bestimmte Dienste verwenden, spezifische Vorgänge aufrufen oder wiederkehrende Zeichenfolgen enthalten. Konzentrierte Attribute liefern Evidenz für eine vorgeschlagene funktionale Bezeichnung.

Schließlich identifiziert die Substring-Analyse wiederkehrende Fragmente in Identitätsnamen. Dadurch lassen sich Konventionen aufdecken, die durch Deployment-Systeme oder Produkte zur Identitätsverwaltung entstanden sind. Das ist sicherer, als aus dem Namen einer einzelnen Identität allein auf eine Rolle zu schließen.

Zusammen verwandeln diese Methoden ein visuelles Muster in eine interpretierbare Verhaltenskategorie. Diese Interpretation bleibt eine analytische Bewertung, stützt sich jedoch auf mehrere Evidenzformen.

Der Clustering-Ansatz von Unit 42 für Cloud-Identitäten ist daher kein magischer Identitätsdecoder. Er ist eine strukturierte Pipeline, um wiederkehrende Betriebsmuster zu finden. Erst menschliche Analyse verbindet diese Muster mit realen organisatorischen Funktionen.

Diese Einschränkung ist zugleich eine Stärke. Sicherheitsteams können nachvollziehen, warum ein Cluster eine bestimmte Bezeichnung erhalten hat. Sie können prüfen, ob charakteristische Vorgänge zu ihrer eigenen Umgebung passen, bevor sie die Klassifizierung produktiv einsetzen.

Der Prozess ähnelt einer explorativen Kartografie. Unüberwachtes Lernen zeichnet die Karte, ohne eine vordefinierte Liste von Rollen zu erhalten. Anschließend bestimmen Analysten, welche Regionen bekannten operativen Verhaltensweisen entsprechen.

Das wiederholte Ausführen der gesamten Mapping-Pipeline würde allerdings Rechen- und Betriebskosten verursachen. Zudem könnten sich Cluster-IDs verschieben, wenn sich Datensätze und Parameter ändern. Unit 42 begegnet diesem Problem in der nächsten Phase.

Der eigentliche Fortschritt liegt im Weg von Modellen zu SQL

Der operativ wichtigste Schritt besteht darin, entdeckte Cluster in kleine, interpretierbare Regeln zu überführen, die bestehende Datensysteme ausführen können.

Nachdem Unit 42 einen nützlichen Cluster identifiziert hat, trainiert das Team einen Klassifikator mit logistischer Regression auf den ursprünglichen booleschen Operationsvektoren. Die logistische Regression berechnet, wie einzelne Merkmale die Wahrscheinlichkeit verändern, dass eine Beobachtung zu einer ausgewählten Klasse gehört.

Ein Team könnte einen Klassifikator für Administratorverhalten und einen weiteren für Security-Tools trainieren. Neue Identitäten würden dann anhand der relevanten Modelle bewertet, ohne die vollständige Verhaltenskarte neu aufzubauen.

Unit 42 setzt außerdem L1-Regularisierung ein. Diese Strafe drängt Koeffizienten wenig hilfreicher Merkmale gegen null. Die verbleibenden Operationen bilden eine deutlich kleinere Menge positiver und negativer Indikatoren.

Diese Sparsamkeit ist für Security Operations wichtig. Ein Modell mit Tausenden interagierender Merkmale wäre schwer zu prüfen, zu erklären oder zu reproduzieren. Ein Klassifikator auf Basis einiger Dutzend gewichteter Operationen lässt sich wesentlich leichter operationalisieren.

Analysten können sehen, welche API-Aufrufe eine Identität in Richtung einer Administratorklassifizierung bewegen. Sie können auch erkennen, welche Operationen sie davon wegbewegen. Diese Transparenz ermöglicht eine Überprüfung, bevor die Logik Warnmeldungen beeinflusst.

Die Forschenden sagen, dass sich diese gewichtete Logik mit Standard-SQL-Abfragen ausdrücken lässt. Die meisten Sicherheitsorganisationen zentralisieren Cloud-Logs bereits in Data Warehouses, Security Data Lakes oder Analyseplattformen. SQL senkt die Einstiegshürde für die Bereitstellung.

Das bedeutet nicht, dass der gesamte Machine-Learning-Workflow verschwindet. Die ursprüngliche Clustering-Phase entdeckt weiterhin aussagekräftige Gruppen und liefert Trainingslabels. Der schlanke Klassifikator ist eine lokale Annäherung an diese frühere Analyse.

Diese Unterscheidung schützt den Artikel vor einer irreführenden Schlussfolgerung. Unit 42 hat nicht jedes Cloud-Sicherheitsproblem auf eine SQL-Anweisung reduziert. Gezeigt wurde, wie eine erlernte Klassifikationsgrenze zu transparenter Abfragelogik werden kann.

Dieses Design stellt einen praktischen Kompromiss zwischen maßgeschneidertem Machine Learning und starren, handgeschriebenen Regeln dar. Vollständig manuelle Erkennungen setzen voraus, dass Analysten relevante Kombinationen im Voraus vorhersagen. Komplexe Modelle können teuer und schwer erklärbar sein.

Verhaltens-Clustering entdeckt Kandidatenmuster aus beobachteten Daten. Sparse Klassifikatoren bewahren anschließend ausgewählte Muster in einem überprüfbaren Format. Detection-Teams erhalten wiederverwendbaren Kontext, ohne die explorative Pipeline kontinuierlich betreiben zu müssen.

Betrachten wir das Beispiel eines Backup-Dienstes. Ein Klassifikator könnte Vorgänge erkennen, die mit regelmäßigen Backup-Aktivitäten verbunden sind, und eine funktionale Rolle zuweisen. Die Detection-Logik kann administrative Erkundung oder Änderungen an Richtlinien dann als Verhalten behandeln, das mit dieser Rolle kollidiert.

Die Warnung ist aussagekräftiger, weil sie einen Widerspruch statt nur eines seltenen Ereignisses beschreibt. „Backup-Identität führte Administratorverhalten aus“ gibt Analysten mehr Kontext als „ungewöhnliche API beobachtet“. Es verknüpft die Ausgangsbasis des Akteurs mit der verdächtigen Aktion.

Der gleiche Ansatz könnte CI/CD-Systeme unterstützen. Deployment-Identitäten führen häufig wiederkehrende Infrastrukturvorgänge über vorhersehbare Dienste hinweg aus. Missbrauch von Zugangsdaten könnte Konsolenaktivität, umfassende Erkundung oder unabhängigen Datenzugriff einführen.

Security-Produkte stellen eine weitere nützliche Kategorie dar. Sie inventarisieren regelmäßig Ressourcen und prüfen Konfigurationen. Ohne Rollenkontext können diese Aktivitäten wie Angreiferaufklärung aussehen und vermeidbares Rauschen erzeugen.

Funktionale Klassifizierung kann daher zwei unterschiedliche Fehler reduzieren. Sie kann False Positives verringern, wenn weitreichender Zugriff zu einem bekannten Scanner passt. Sie kann den Verdacht erhöhen, wenn eng spezialisierte Automatisierung beginnt, sich wie ein Administrator zu verhalten.

Hier konkurriert die Ableitung von Verhaltensrollen am unmittelbarsten mit statischer Kennzeichnung. Ein Name wie „security-scanner“ verlangt von Analysten, der Konfiguration zu vertrauen. Ein beobachtetes Muster liefert ihnen Belege dafür, dass die Identität diese Funktion weiterhin ausführt.

Die Methode ergänzt auch die Berechtigungsanalyse. Ein Security-Scanner kann sich normal verhalten und dennoch übermäßige Rechte besitzen. Posture-Tools sollten diese Gefährdung weiterhin melden, selbst wenn Laufzeiterkennungen nichts Verdächtiges finden.

Umgekehrt kann sich eine stark eingeschränkte Identität innerhalb ihres zulässigen Bereichs weiterhin unerwartet verhalten. Verhaltensüberwachung sollte diese Änderung markieren, selbst wenn eine Richtlinienprüfung keinen Verstoß feststellt.

Das Modell schafft daher eine zusätzliche Datenschicht und ersetzt keine bestehende Kontrolle. Berechtigungen definieren Grenzen. Clustering leitet Rollen ab. Detection-Logik erkennt Abweichungen, die untersucht werden sollten.

Unit 42 sagt, die Methodik könne über AWS CloudTrail hinaus auf andere Cloud-Anbieter, Kubernetes und Softwaredienste ausgeweitet werden. Diese Erweiterung ist plausibel, weil auch diese Systeme Audit-Ereignisse mit Identitätsbezug erzeugen.

Portabilität erfordert jedoch eine neue Validierung. Azure, Google Cloud, Kubernetes und SaaS-Plattformen stellen unterschiedliche Ereignisvokabulare und Identitätsstrukturen bereit. Ein auf AWS-Operationen trainierter Klassifikator lässt sich nicht unverändert übertragen.

Was die Forschung noch nicht belegt

Der Datensatz zeigt kohärente Verhaltenscluster, belegt jedoch keine universelle Erkennungsgenauigkeit über Organisationen, Anbieter oder sich verändernde Workloads hinweg.

Unit 42 berichtet von erheblichem Umfang, darunter mehr als 40.000 Identitäten und 125 Umgebungen. Diese Breite stützt die Behauptung, dass wiederkehrende Verhaltensrollen in mehreren Cloud-Landschaften auftreten. Sie beantwortet jedoch nicht jede Frage zum Produktiveinsatz.

Die Veröffentlichung enthält keinen vollständigen Benchmark mit Precision, Recall, False-Positive-Raten und Leistung über alle identifizierten Rollen hinweg. Sie besagt, dass die logistische Regression ausgewählte Cluster präzise identifizieren kann, doch öffentliche Leser können nicht jedes Ergebnis unabhängig reproduzieren.

Die Studie konzentriert sich außerdem auf ein Beobachtungsfenster von zwei Monaten. Dieser Zeitraum erfasst wiederkehrende Vorgänge, doch einige legitime Identitäten werden nur bei vierteljährlichen Wiederherstellungstests, Migrationen oder Incident Response aktiv. Kurze Baselines können seltene, aber autorisierte Arbeit falsch klassifizieren.

Boolesche Vektoren bringen einen weiteren Zielkonflikt mit sich. Sie halten fest, ob eine Operation stattgefunden hat, lassen aber außer Acht, wie häufig sie auftrat. Eine Identität, die eine API einmal aufruft, sieht bei diesem Merkmal identisch aus wie eine, die sie Tausende Male aufruft.

Diese Vereinfachung hilft, die Dimensionalität zu kontrollieren, und unterstützt die Interpretierbarkeit. Sie kann jedoch Volumensignale ausblenden, die Routinearbeit von Missbrauch unterscheiden. Häufigkeit, Zeitpunkt, Geografie, Anfrageparameter und Ressourcenziele können bei der Untersuchung allesamt relevant sein.

Concept Drift stellt ein weiteres Problem dar. Funktionales Verhalten verändert sich, wenn Teams neue Dienste einführen, Pipelines überarbeiten oder Architekturen migrieren. Ein auf den Operationen von gestern trainierter Klassifikator kann legitime Änderungen an Deployments als verdächtig behandeln.

Auch Angreifer können sich anpassen. Wenn sie die erwartete Verhaltensrolle verstehen, können sie Operationen wählen, die ihrer normalen Aktivität ähneln. Verhaltensklassifizierung erhöht die Kosten für Tarnung, beseitigt Umgehung jedoch nicht.

Der Ansatz hängt von zuverlässiger Telemetrie ab. Fehlende CloudTrail-Abdeckung, deaktivierte Protokollierung, inkonsistente Aufbewahrung oder unvollständige kontoübergreifende Sammlung verzerren die Identitätsvektoren. Ein sauberes Modell kann Ereignisse nicht wiederherstellen, die nie erfasst wurden.

Auch Identitätsgrenzen können unscharf werden. Angenommene Rollen, föderierte Sitzungen, Workload-Zugangsdaten und gemeinsam genutzte Automatisierungspfade können mehrere Akteure zu einem scheinbaren Principal zusammenfassen. Die Rollenableitung ist nur so präzise wie die Kennungen in den Quellprotokollen.

Organisationsübergreifende Daten bringen eine weitere Unsicherheit mit sich. Gemeinsames Verhalten kann stabile Branchenmuster offenlegen, doch jedes Unternehmen konfiguriert Konten anders. Operationen, die in einer Umgebung stark mit Administratoren verbunden sind, können andernorts automatisch auftreten.

Der Administratorcluster veranschaulicht dieses Risiko. ConsoleLogin ist im berichteten Datensatz äußerst charakteristisch. Automatische Konsolenanfragen, föderierte Zugriffsdesigns und Änderungen an Anbieteroberflächen können jedoch verändern, welche Operationen eine interaktive Sitzung begleiten.

Selbst der Ausdruck „funktionale Rolle“ kann mehr Gewissheit vermitteln, als die Evidenz trägt. Ein Cluster beschreibt Verhaltensähnlichkeit während eines Beobachtungszeitraums. Er beweist weder organisatorische Zuständigkeit noch Autorisierung oder Geschäftszweck.

Sicherheitsteams sollten zugewiesene Rollen daher als kontextbezogene Metadaten behandeln. Sie sollten diese mit Berechtigungsdaten, Ressourcenbereich, Netzwerkindikatoren, Authentifizierungssignalen und Threat Intelligence kombinieren. Keine einzelne Dimension belegt bösartige Absicht.

Auch der kommerzielle Kontext verdient Prüfung. Unit 42 ist die Threat-Research-Organisation von Palo Alto Networks, und die Veröffentlichung verknüpft die Methodik mit Cortex Cloud und verwandten Produkten. Die technischen Erkenntnisse bleiben wertvoll, Produktbehauptungen erfordern jedoch kundenseitige Validierung.

Organisationen sollten prüfen, ob Klassifizierungen über Konten und Zeit hinweg stabil bleiben. Sie sollten die Qualität der Warnmeldungen messen, bevor Rollenabweichungen automatisierte Eindämmungsmaßnahmen auslösen dürfen. Eine fehlerhafte Reaktion könnte Backups, Deployments oder Sicherheitsüberwachung unterbrechen.

Eine Dry-Run-Bewertung bietet einen sichereren Einführungspfad. Teams können abgeleitete Rollen berechnen, sie mit bekannter Asset-Zuständigkeit vergleichen und Abweichungen beobachten, ohne Produktionszugriff zu verändern. Anschließend können Analysten Schwellenwerte und Ausnahmen verfeinern.

Der beste Test ist nicht, ob die Visualisierung überzeugend wirkt. Entscheidend ist, ob der Rollenkontext Untersuchungen verkürzt und gleichzeitig aussagekräftige Erkennungen bewahrt. Dieses Ergebnis erfordert operative Evidenz über die Forschungspublikation hinaus.

Drei Signale werden zeigen, ob verhaltensbasierte Identitätserkennung trägt

Der nächste Test besteht darin, ob die Ableitung von Verhaltensrollen nach Verlassen der Forschungsumgebung genau, portabel und nützlich bleibt.

Das erste Signal ist messbare Erkennungsleistung. Unit 42 oder Kunden müssen Precision-, Recall- und False-Positive-Ergebnisse für mehrere Rollen veröffentlichen. Die Administratorklassifizierung allein kann keine Leistung für Backup-Agenten, Deployment-Systeme oder autonome Agenten belegen.

Die Ergebnisse sollten unbekannte Umgebungen einschließen, statt Identitäten aus derselben organisatorischen Population zu verwenden. Gute Leistung in externen Umgebungen würde die Behauptung stützen, dass funktionale Muster generalisierbar sind. Starke Rückgänge würden umgebungsspezifische Annahmen offenlegen.

Das zweite Signal ist plattformübergreifende Validierung. Die Forschenden sagen, ihre Methodik könne auf Kubernetes, SaaS-Anwendungen und andere Cloud-Anbieter ausgeweitet werden. Eine dokumentierte Implementierung außerhalb von AWS würde diese Behauptung prüfen.

Portabilität sollte mehr bedeuten als die Verarbeitung eines anderen Logformats. Die Methode muss erkennbare Rollen identifizieren, stabile Klassifikatoren erzeugen und tatsächliche Erkennungsentscheidungen verbessern. Andernfalls leisten möglicherweise AWS-API-Konventionen mehr Arbeit als das allgemeine Framework.

Das dritte Signal ist die operative Akzeptanz durch transparente Detection-Workflows. Sicherheitsteams sollten auf Integrationen achten, die innerhalb einer Warnmeldung die abgeleitete Rolle, beitragende Operationen, Konfidenz und widersprüchliches Verhalten offenlegen.

Ein einfacher Risikoscore würde den Hauptvorteil der Forschung verschleiern. Der Wert liegt darin zu erklären, dass eine bekannte Backup-Identität begonnen hat, sich wie ein Administrator zu verhalten. Analysten benötigen diese Beziehung, um die Dringlichkeit einzuschätzen und eine Reaktion zu wählen.

Die stärksten Implementierungen werden Rollenänderungen zudem im Zeitverlauf nachverfolgen. Ein Deployment-Konto kann berechtigterweise auf neue Services ausgeweitet werden. Systeme benötigen Umschulungspläne, Drift-Monitoring, versionierte Klassifikatoren und Prüfprozesse für verändertes Verhalten.

Teams sollten nicht jede Abweichung als Vorfall behandeln. Manche Abweichungen spiegeln Wartungsarbeiten, Migrationen oder neue Produktreleases wider. Das Rollensignal sollte Untersuchungen priorisieren, während andere Belege bestimmen, ob eine Eindämmung gerechtfertigt ist.

Menschliche und maschinelle Identitäten sollten ebenfalls getrennt bewertet werden. Interaktive Administratoren, geplante Services und autonome Agenten erzeugen Aktivitäten in unterschiedlichem Tempo. Sie benötigen möglicherweise unterschiedliche Beobachtungszeiträume und Schwellenwerte.

Autonome Agenten machen diese Frage besonders dringlich. Ein Agent könnte bei der Verfolgung eines genehmigten Ziels variable Abläufe über viele Services hinweg ausführen. Statische Jobbezeichnungen beschreiben dieses Verhalten nur unzureichend.

Doch variables Verhalten erschwert auch die Clusterbildung. Der legitime Handlungsspielraum eines Agenten kann sich mit Aufklärung, Konfigurationsänderungen und Datenzugriff überschneiden. Verteidiger benötigen Kontext zu Zielen, Genehmigungen, Ressourcen und Ausführungshistorien.

Der Vorschlag von Unit 42 zu Cloud-Identitäten liefert einen Teil dieses Kontexts. Er erstellt eine empirische Beschreibung davon, wie sich eine Identität unter vergleichbaren Identitäten verhält. Er entscheidet nicht darüber, ob das zugrunde liegende Ziel autorisiert war.

Für Entwickler lautet die unmittelbare Frage, ob Deployment- und Service-Identitäten klare, beobachtbare Muster aufweisen. Teams sollten prüfen, ob Audit-Ereignisse über angenommene Rollen und Automatisierungssitzungen hinweg konsistent verknüpft werden können.

Unternehmenskäufer sollten Anbieter fragen, wie funktionale Rollen abgeleitet werden. Sie sollten zudem Belege verlangen, die erklären, welche Ereignisse jede Klassifikation bestimmen. „KI-gestützte Anomalieerkennung“ ist für eine Sicherheitsentscheidung mit hoher Tragweite keine ausreichende Information.

Sicherheitsverantwortliche sollten Verhaltensbefunde mit Zugriffsprüfungen vergleichen. Eine Identität, die operativ eng begrenzt wirkt, aber weitreichende Berechtigungen behält, stellt ein vermeidbares Risiko dar. Eine Identität, die plötzlich die Rolle wechselt, stellt eine potenzielle aktive Bedrohung dar.

Wissensarbeiter und Nutzer von KI-Produkten haben ein verwandtes Interesse. Geschäftsanwendungen verbinden Assistenten und Agenten zunehmend mit Unternehmensdaten. Jede Verbindung schafft eine Identität, deren tatsächliches Verhalten über eine einfache Benutzerbezeichnung hinausgehen kann.

Die nächsten ein bis drei Monate sollten zeigen, ob Palo Alto Networks weitere Validierungen veröffentlicht, die Rollenabdeckung erweitert oder die Logik in Kunden-Workflows direkter offenlegt. Unabhängige Tests würden das Argument zusätzlich stärken.

Leser sollten drei konkrete Fragen verfolgen: Funktionieren die Klassifikatoren in unbekannten Umgebungen, lassen sie sich über AWS hinaus übertragen, und verbessern sie die Entscheidungen von Analysten? Die Antworten werden bestimmen, ob verhaltensbasierte Identitätskarten zu einem routinemäßigen Sicherheitskontext werden.

Die zentrale Bewertung der Studie gilt bereits: Berechtigungsdokumente sind notwendig, aber sie liefern kein vollständiges Bild des Identitätsrisikos. Verteidiger benötigen auch Belege dafür, was Zugangsdaten, Workloads und Agenten tatsächlich tun.

Überprüfen Sie Ihr eigenes Cloud-Inventar unter diesem Blickwinkel. Welche Identitäten haben Namen und Berechtigungen, aber keine verifizierte Verhaltensrolle? Die Lücken in dieser Antwort zeigen, wo die Forschung von Unit 42 zu Cloud-Identitäten am wichtigsten ist.