Nicht-menschliche Identitäten sind zur größten unverwalteten Angriffsfläche in der Cloud-Sicherheit geworden

In einer typischen Enterprise-Cloud-Umgebung von heute übertreffen maschinelle Identitäten – Service-Accounts, API-Keys, OAuth-Tokens, CI/CD-Credentials und Workload-Identitäten – menschliche Benutzerkonten in Verhältnissen, die üblicherweise zwischen 45:1 und 90:1 angegeben werden. Sicherheitsteams haben zwei Jahrzehnte damit verbracht, Identity- und Access-Management rund um Menschen aufzubauen: Onboarding, Offboarding, Multi-Faktor-Authentifizierung, regelmäßige Zugriffsüberprüfungen. Fast keine dieser Infrastrukturen wurde für Maschinen gebaut – und das zeigt sich. Nicht-menschliche Identitäten (NHIs) sind stillschweigend zur größten unverwalteten Angriffsfläche in der Cloud-Sicherheit geworden, und die meisten Organisationen können eine grundlegende Frage nicht beantworten: Wie viele Maschinen-Credentials existieren in ihrer Umgebung, wer oder was besitzt jedes einzelne, und wann wurde es zuletzt verwendet?

Warum traditionelles IAM Maschinen nicht abdeckt

Die Governance menschlicher Identitäten stützt sich auf Annahmen, die für Maschinen nicht gelten. Eine Person hat einen Vorgesetzten, der den fortbestehenden Bedarf bestätigen kann. Eine Person bekommt ein Exit-Interview und eine Offboarding-Checkliste, wenn sie das Unternehmen verlässt. Die Zugriffsanfrage einer Person durchläuft einen Review-Zyklus. Service-Accounts hingegen werden häufig ad hoc von einem Entwickler erstellt, der einen neuen Microservice provisioniert, mit weitreichenden Berechtigungen ausgestattet, um späteres Debugging von Permission-Fehlern zu vermeiden – und dann nie wieder angefasst. Das Credential überlebt das Projekt, den Entwickler, der es erstellt hat, und oft auch den ursprünglichen Zweck seiner Existenz. Multipliziert man dieses Muster über jede CI/CD-Pipeline, jede Drittanbieter-SaaS-Integration, jeden internen Service, der einen anderen internen Service aufruft, wird das Inventarproblem enorm.

Wie Maschinen-Credentials tatsächlich kompromittiert werden

Die Muster von Sicherheitsverletzungen sind in Incident-Reports auffallend konsistent. Langlebige API-Keys werden von Entwicklern in öffentliche GitHub-Repositories committet, die vergessen, sie in eine .gitignore-Datei aufzunehmen – automatisierte Scanner finden und nutzen diese innerhalb von Minuten nach der Offenlegung aus. Überprivilegierte Service-Accounts, die Admin-Zugriff erhalten haben, weil das schneller war als die korrekte Eingrenzung von Berechtigungen, verwandeln ein einziges kompromittiertes Credential in vollständigen Umgebungszugriff. Veraltete OAuth-Tokens einer SaaS-Integration, die vor achtzehn Monaten stillgelegt wurde, bleiben gültig, weil niemand sie widerrufen hat. Und in Cloud-nativen Umgebungen werden Workload-Identitäten, die kurzlebig und auf einen einzelnen Pod oder eine Funktion beschränkt sein sollten, stattdessen als statische, langlebige Secrets in Container-Images eingebacken.

Keine dieser Techniken ist exotisch. Es sind grundlegende Hygiene-Fehler in großem Maßstab – und Angreifer wissen das. Credential-basierte Angriffe auf maschinelle Identitäten sind zu einem der zuverlässigsten Initial-Access-Vektoren geworden, gerade weil die defensiven Tools, die einen verdächtigen menschlichen Login erkennen würden – anomale Geografie, ungewöhnliche Zugriffszeit, Device-Fingerprinting – oft nicht sauber auf ein Skript anwendbar sind, das um 3 Uhr morgens eine API aus einem Rechenzentrum aufruft, was völlig normales Maschinenverhalten ist.

Was sich tatsächlich ändert

Eine neue Kategorie von Security-Tools ist entstanden, die sich speziell dieser Lücke widmet. Anbieter wie Astrix Security, Entro, Oasis Security und Token Security bauen Produkte, die NHIs über Cloud- und SaaS-Umgebungen hinweg entdecken, inventarisieren und überwachen – auf eine Weise, für die allgemeine IAM-Tools nie konzipiert wurden. Diese Plattformen beginnen typischerweise mit der Erstellung eines umfassenden Inventars – etwas, das die meisten Organisationen nie hatten – und legen dann ein Risiko-Scoring auf Basis von Privilegien-Level, Credential-Alter und Nutzungsmustern darüber, um schließlich Remediation wie Credential-Rotation oder Zugriffs-Eingrenzung zu automatisieren.

Auch Cloud-Anbieter haben sich bewegt. AWS, Google Cloud und Azure bieten inzwischen alle Workload Identity Federation an, die es einem Service ermöglicht, sich mit kurzlebigen, automatisch rotierten Tokens zu authentifizieren, die an seine tatsächliche Runtime-Identität gebunden sind, statt an einen statischen, langlebigen Key. Das eliminiert eine ganze Risikokategorie – das geleakte statische Credential – per Design, aber die Adoption erfordert eine Neuarchitektur bestehender Integrationen, weshalb die Migration trotz seit mehreren Jahren verfügbarer Tools langsam vorangeht.

Was Sicherheitsteams tatsächlich tun sollten

Beginnen Sie mit Discovery, nicht mit Remediation. Sie können nicht sichern, was Sie nicht sehen können, und die meisten Organisationen unterschätzen ihre NHI-Anzahl um eine Größenordnung, bis sie einen ordnungsgemäßen Scan über Cloud-Accounts, SaaS-Admin-Konsolen, CI/CD-Systeme und Source-Code-Repositories durchführen. Sobald Sie ein Inventar haben, priorisieren Sie nach Blast Radius: Ein Credential mit Admin-Level-Cloud-Zugriff ist wichtiger als ein Read-only-API-Key für ein internes Tool mit geringer Sensitivität – unabhängig davon, welches älter oder sichtbarer ist.

Wechseln Sie überall dort, wo die Plattform es unterstützt, zu kurzlebigen Credentials – Workload Identity Federation für Cloud-zu-Cloud-Authentifizierung, OIDC-Tokens für CI/CD-Pipelines statt statischer Secrets in der Pipeline-Konfiguration. Für Credentials, die langlebig bleiben müssen, erzwingen Sie Rotation nach einem festen Zeitplan, statt darauf zu vertrauen, dass jemand es manuell erledigt, und setzen Sie Ablaufdaten als Standard statt als Ausnahme. Weisen Sie schließlich Eigentum zu. Jedes Maschinen-Credential sollte einer Person oder einem Team zugeordnet sein, das dafür verantwortlich ist – genauso wie jedes menschliche Konto einem Mitarbeiter zugeordnet ist. Ein Credential ohne Eigentümer ist ein Credential, von dem niemand bemerkt, dass es veraltet, das bei verdächtiger Nutzung nicht markiert oder bei der Stilllegung des Systems, das es bedient, nicht widerrufen wird – genau die Lücke, die Angreifer derzeit in großem Maßstab ausnutzen.