NHI: Warum Service Accounts plötzlich ein Thema sind

Service Accounts gab es schon immer.

Ein Beispiel: In nahezu jedem Active Directory finden sich Dutzende. Ein Administrator hat sie einst angelegt, damit ein Dienst auf eine Datenbank zugreifen kann. Der Administrator ist längst weg, der Account läuft noch.

Mit Cloud, APIs, Microservices und CI/CD-Pipelines wurden aus wenigen Service Accounts schnell sehr viele. Genau hier beginnt die Geschichte von Non-Human Identities (NHIs).

Früher war ein Service Account ein konkretes Objekt: ein Windows-Konto im Active Directory, das einen Dienst ausführte. Jemand hat es angelegt, irgendwo dokumentiert und gehofft, dass es nie Probleme macht. Das funktionierte, weil die Zahlen überschaubar waren. Eine Organisation mit 500 Mitarbeitenden hatte vielleicht 50 Service Accounts – jemand kannte sie alle, zumindest ungefähr.

Heute sieht das anders aus. Laut aktuellen Analysen übersteigen nicht-menschliche Identitäten die menschlichen in vielen Enterprise-Umgebungen deutlich, teils um ein Vielfaches, und wachsen weiterhin stark.

Die neue Realität: 500 Mitarbeitende, aber zehntausende NHIs.

Keine Excel-Tabelle der Welt ist dafür gebaut und kein Administrator kann das manuell überblicken. Viele klassische IAM-Prozesse wurden für menschliche Lebenszyklen konzipiert und stoßen beim rasant steigenden NHI-Volumen schnell an ihre Grenzen.

Active Directory wurde um das Jahr 2000 eingeführt. Das zugrunde liegende Identity-Modell war stark auf menschliche Benutzer ausgelegt: Gruppen, Passwörter und Anmelderichtlinien orientierten sich primär daran, dass sich Menschen an Unternehmenssystemen anmelden.

Service Accounts wurden in vielen Unternehmen pragmatisch umgesetzt. Wenn ein Dienst ohne menschliche Interaktion auf andere Systeme oder Datenbanken zugreifen musste, nutzten Administratoren häufig normale Benutzerkonten aus dem Active Directory. Sie vergaben technische Namen und aktivierten oft „Passwort läuft nie ab“, damit der Betrieb nicht plötzlich stillstand.

Microsoft hat später zwar Managed Service Accounts (MSAs) und Group Managed Service Accounts (gMSAs) eingeführt – technisch deutlich besser und mit automatischer Passwort-Rotation –, doch die Adoption blieb begrenzt. In den meisten Umgebungen stehen noch heute hunderte klassischer Domain-Accounts, die kritische Dienste betreiben und seit Jahren keinen Passwort-Reset gesehen haben.

Mit dem Wandel der IT-Architektur explodierten die Zahlen:

• Cloud-Dienste brachten SaaS-Modelle.
• Microservices machten aus einer monolithischen Applikation plötzlich zehn eigenständige Dienste.
• DevOps führte zu CI/CD-Pipelines, die vollautomatisiert neue Identitäten erzeugen.

Jeder API-Call, jede Integration und jedes Skript benötigt Credentials. Mit der zunehmenden Nutzung von KI-Agenten in Unternehmen wächst die Zahl nicht-menschlicher Identitäten nun noch weiter. Anders als klassische Automatisierungen führen agentische KI-Systeme Aufgaben nicht nur starr aus, sondern treffen innerhalb definierter Grenzen eigenständig Entscheidungen darüber, welche Systeme, APIs oder Datenquellen sie nutzen.

Analysten beschreiben NHIs als Identitäten für Maschinen, Workloads, Service Accounts und AI Agents. Automatisierung, cloud-native Architekturen und autonome KI-Agenten erhöhen die Anzahl und Komplexität nicht-menschlicher Identitäten massiv.

Gleichzeitig zeigt eine Studie der Cloud Security Alliance, dass ein relevanter Teil der Unternehmen neue KI-bezogene Identitäten bislang nicht systematisch erfasst oder überwacht. Dadurch entstehen zusätzliche blinde Flecken in Governance-, IAM- und Secrets-Management-Prozessen.

Hier liegt ein entscheidender Punkt, den viele unterschätzen. Die Diskussion über NHI-Sicherheit dreht sich meistens um schlechte Governance: Accounts werden nicht rotiert, Rechte nicht entzogen, das Offboarding wird vergessen. Das stimmt alles. Aber darunter liegt ein noch grundlegenderes Problem:

Ein erheblicher Teil der NHIs ist in keinem IAM-System angebunden und somit für das Unternehmen schlicht „unsichtbar“.

• Ein Service Account wird von einem Entwickler angelegt, um einen Test-Workflow anzubinden. Der Test wird produktiv, der Account bleibt. Im IGA-Tool oder im PAM taucht er nie auf. Er existiert in einem blinden Fleck.
• Das gilt ebenso für API-Keys, die direkt in Anwendungen hartcodiert sind.
• Für OAuth-Token, die ein SaaS-Tool bei der Integration automatisch erzeugt hat.
• Für CI/CD-Credentials, die in Pipeline-Konfigurationen leben und nie in einen Secrets Manager überführt wurden.

Was nicht angebunden ist, kann nicht verwaltet (governed) werden. Was nicht verwaltet werden kann, wird nicht rotiert. Und was nicht rotiert wird, bleibt aktiv, manchmal für Jahre. Laut OWASP existieren häufig Secrets ohne sinnvolle Ablaufzeiten, weil sie schlicht nie überprüft werden. Das ist der Ausgangspunkt für etliche NHI-Angriffe: Eine Identität, die dem IAM-System völlig unbekannt war.

• Der GitHub-Action-Vorfall (März 2025): Angreifer kompromittierten die weit verbreitete GitHub Action tj-actions/changed-files. Dadurch konnten sensible CI/CD-Secrets aus tausenden Repositories abgegriffen werden. Der Vorfall zeigte, wie kritisch nicht-menschliche Identitäten und Tokens in modernen Entwicklungsumgebungen geworden sind: Ein einziger kompromittierter Access Token innerhalb einer automatisierten CI/CD-Kette reichte aus, um weitreichenden Zugriff auf Build- und Deployment-Prozesse zu erhalten.
• Der Fall Tata Motors (2025): Hardcodierte Credentials in mehreren öffentlichen Anwendungen ermöglichten potenziell Zugriff auf über 70 TB Daten. Die Schwachstellen lagen seit Jahren vor. Der Fall verdeutlicht ein typisches Problem moderner NHI-Sicherheit: langlebige Credentials, die unbemerkt in Anwendungen, Skripten oder Integrationen verbleiben.

Genau dieses Muster taucht in etlichen aktuellen Sicherheitsvorfällen rund um Maschinenidentitäten auf: gültige Credentials, fehlende Transparenz und Identitäten, die nie sauber inventarisiert oder kontrolliert wurden.

Traditionelle IAM-Systeme wurden um menschliche Verhaltensmuster herum entwickelt: Onboarding über das HR-System, Rollenänderung beim Abteilungswechsel, Offboarding beim Austritt. Dazu kommen Arbeitszeiten, Standorte und vorhersehbares Verhalten als Baseline für die Anomalieerkennung.

NHIs folgen keinem dieser Muster. Sie laufen rund um die Uhr (24/7). Sie tauchen in keiner HR-Datenbank auf. Sie haben keinen Vorgesetzten, der ihre Zugriffsrechte im jährlichen Review bestätigt. Das Ergebnis zeigt sich in drei konsistenten Lücken:

1. Fehlende Ownership: Viele Organisationen tracken die Erstellung neuer KI-bezogener Identitäten überhaupt nicht. Was nicht erfasst wird, wird nicht verantwortet. Was nicht verantwortet wird, wird nicht gepflegt.
2. Standardmäßige Überprivilegierung: Ein Großteil aller NHIs besitzt weit mehr Rechte, als sie für ihre eigentliche Funktion benötigen. Das ist ein massives Governance-Problem, denn technische Accounts werden oft pauschal mit Admin-Rechten ausgestattet.
3. Kein Offboarding: Ein Microservice wird abgeschaltet, sein API-Key bleibt aktiv. Ein Entwickler verlässt das Unternehmen, sein persönlicher Access Token läuft weiter. Unsachgemäßes Offboarding stellt eines der größten NHI-Risiken dar.

• Bestandsaufnahme zuerst: Was nicht bekannt ist, kann nicht geschützt werden. Der erste Schritt ist immer die umfassende Inventarisierung: Welche NHIs existieren überhaupt im Active Directory, in der Cloud, in SaaS-Integrationen und in den CI/CD-Pipelines?
• Ownership definieren: Jede NHI braucht einen menschlichen Verantwortlichen. Eine konkrete Person oder Rolle, die für die Rotation, Berechtigungsreviews und die schlussendliche Dekommissionierung zuständig ist.
• Least Privilege durchsetzen: Jede Identität darf strikt nur die Rechte erhalten, die sie für ihre spezifische Aufgabe zwingend benötigt.
• Lifecycle automatisieren: Die automatische Erkennung neuer NHIs, die regelmäßige automatisierte Rotation von Secrets sowie das automatische Offboarding beim Abschalten eines Services müssen zum Standard werden.

Mehr Informationen finden Sie auch auf unserer Service-Seite zum Thema NHI-Management.