Non-Human Identities: Die meist unterschätzte Angriffsfläche

Mit der wachsenden Komplexität moderner IT-Landschaften hat sich der Identitätsbegriff längst von klassischen Benutzerkonten entfernt. Systeme, Anwendungen, Cloud-Dienste und zahlreiche weitere Softwarekomponenten greifen auf sensible Ressourcen zu und interagieren miteinander. Diese nicht-menschlichen Akteure – sogenannte Non-Human Identities (NHIs) – sind inzwischen entscheidend für den täglichen Betrieb vieler Organisationen.

Aus meiner Zeit als Penetration Tester weiß ich: Fehlkonfigurierte oder öffentlich einsehbare Machine Identities gehörten zu den effektivsten Einstiegspunkten, um ersten Zugriff zu erlangen oder meine Position innerhalb der geprüften Umgebungen zu festigen.

Ihr Wesen, ihre Risiken und die notwendigen Best Practices für ein wirksames Management zu verstehen, ist heute ein zentraler Baustein robuster Cybersicherheit.

Was versteht man unter einer Non-Human Identity?

Eine NHI bezeichnet jede digitale Entität, die sich authentifizieren und autorisieren muss, um auf Ressourcen zuzugreifen – ohne selbst ein menschlicher Nutzer zu sein. Dieser Begriff umfasst eine breite Palette von Komponenten, darunter:

· Service Accounts: Von Anwendungen oder Diensten genutzt, um mit dem Betriebssystem, Datenbanken oder anderen Applikationen zu interagieren.

· API-Schlüssel: Ermöglichen Anwendungen die Kommunikation untereinander – komplett ohne menschliches Zutun.

· Secrets und Zertifikate: Dienen der Authentifizierung und Verschlüsselung.

· Cloud Workloads: Virtuelle Maschinen, Container oder serverlose Funktionen in der Cloud.

· Bots und automatisierte Skripte: Führen wiederkehrende Aufgaben aus oder interagieren mit Systemen. (Vielleicht nutzen Sie selbst eines für Slack- oder Discord-Nachrichten.)

· IoT-Geräte: Sensoren, Kameras und andere vernetzte Geräte, die Daten austauschen und kommunizieren.

Wenn über NHIs gesprochen wird, richtet sich der Blick oft schnell auf API Keys oder JWT-Tokens. Diese Mechanismen sind heute weit verbreitet und bilden die Grundlage sicherer Kommunikation zwischen Diensten. Doch NHIs können viele Formen annehmen: klassische Benutzername-/Passwort-Kombinationen, Zertifikate, Maschinen-Tokens und vieles mehr.

Wichtig ist auch zu berücksichtigen, dass menschliche Benutzer indirekt über NHIs handeln. Nutzt jemand etwa eine Web-Anwendung, die im Hintergrund API-Requests ausführt, dann interagiert das System nicht mit der Person selbst, sondern mit einer nicht-menschlichen Identität – beispielsweise einem Service Account oder einem Systemtoken –, auch wenn die Aktion vom Menschen ausgelöst wurde.

Und manchmal – weil Menschen eben Menschen sind – werden Service-Account-Credentials direkt durch Personen verwendet. Ein bekanntes, bequemes Schlupfloch, das mit minimalem Aufwand weitreichende Privilegien eröffnet.

Warum stellen NHIs ein zentrales Sicherheitsrisiko dar?

Die rapide Zunahme nicht-menschlicher Identitäten macht die Sicherheitslandschaft deutlich komplexer. Mehrere Faktoren verstärken diese Herausforderung:

· Menge und Vielfalt: NHIs übertreffen menschliche Benutzerzahlen oft um ein Vielfaches. Sie treten in unterschiedlichsten Formen auf – Microservices, Bots, Cronjobs, Cloud Functions usw. – was ihre Erfassung und einheitliche Governance erheblich erschwert.

· Fehlende Transparenz: Im Gegensatz zu normalen Benutzerkonten sind NHIs häufig nicht dokumentiert oder tief in Infrastrukturlayern verborgen. Fehlende Verantwortlichkeiten und unzureichendes Lifecycle-Management führen zu gefährlichen Blindspots – sowohl in der Security-Telemetrie als auch in Incident-Response-Prozessen.

· Komplexes Berechtigungsmanagement: Rechte zu vergeben oder zu entziehen ist bei NHIs besonders anspruchsvoll. Ohne strikte Governance sammeln sie schnell überhöhte, veraltete oder nicht mehr benötigte Privilegien an – ein ideales Szenario für laterale Bewegungen oder Privilegieneskalation.

· Default-Privilegien & Overprovisioning: NHIs werden häufig mit Standard- oder geerbten Berechtigungen erstellt – oft basierend auf den Rechten des Benutzers oder Systems, das sie generiert hat. Beispiel: Wird ein Personal Access Token in GitHub oder GitLab erstellt, erhält es standardmäßig sehr breite Berechtigungsscope – sofern sie nicht manuell eingeschränkt werden. Da es kaum automatisierte Mechanismen gibt, diese Rechte zu reduzieren oder korrekt zu dimensionieren, entsteht schnell dauerhafte Überexponierung.

· Ungenügende Rotation von Secrets: NHIs basieren auf Credentials wie API Keys, Tokens oder Zertifikaten. Diese werden häufig hartcodiert, selten oder gar nicht rotiert – oder schlicht vergessen. Das macht Systeme besonders anfällig für langfristige Kompromittierungen.

· Begrenztes Monitoring: Die Aktivitäten von NHIs werden selten umfassend überwacht. Oft gibt es weder Echtzeit-Transparenz noch verhaltensbasierte Analysen. Da NHIs im Hintergrund „leise“ arbeiten, lösen sie kaum Alarme aus und erscheinen kaum in klassischen Security-Dashboards. Das schafft einen gefährlichen blinden Fleck, in dem Fehlkonfigurationen oder bösartige Aktivitäten lange unentdeckt bleiben können.

· Attraktive Ziele für Angreifer: Aufgrund ihres breiten und oft privilegierten Zugriffs sind NHIs besonders wertvoll für Angreifer. Wer eine solche Identität kompromittiert, erhält häufig unkontrollierten, schwer erkennbaren Zugang – perfekt für laterale Bewegung oder Datenexfiltration.

Ironischerweise werden viele dieser Probleme erst sichtbar, wenn ein Penetrationstest oder ein externer Audit durchgeführt wird. Plötzlich stehen dem CISO und dem Security-Management kritische Lücken vor Augen. Diese reaktive Entdeckung zeigt ein grundlegendes Problem: Organisationen wissen häufig nicht, wie exponiert ihre NHI-Landschaft tatsächlich ist – bis jemand aktiv versucht, sie zu kompromittieren. Und selbst dann bleiben Security- und IT-Teams oft unsicher, wie sie wirksam reagieren sollen.

Um das Ausmaß noch greifbarer zu machen, lohnt sich ein Blick auf reale Zahlen. Die folgenden Daten stammen aus GitGuardians Report „The State of the Secret Sprawl 2025“.

Im Jahr 2024 entdeckte GitGuardian unglaubliche 23,8 Millionen geleakte Secrets in öffentlichen GitHub-Repositories – ein Anstieg von 25 Prozent gegenüber dem Vorjahr. Besonders alarmierend ist, dass 4,6 Prozent aller öffentlichen und sogar 35 Prozent aller privaten Repositories mindestens ein offengelegtes Secret enthielten. Private Repos werden häufig weniger streng behandelt, was auf ein trügerisches Sicherheitsgefühl zurückzuführen ist.

Noch besorgniserregender ist die Langlebigkeit dieser Leaks: 70 Prozent der 2022 kompromittierten Secrets waren auch 2024 noch aktiv, was auf erhebliche Defizite bei der Bereinigung und Verwaltung hindeutet.

Unter den in öffentlichen Repositories offengelegten Zugangsdaten waren MongoDB-Credentials mit 18,8 Prozent am häufigsten vertreten. In privaten Repositories tauchten hingegen AWS-IAM-Schlüssel in 8 Prozent der Fälle auf – fünfmal häufiger als in öffentlichen Projekten.

Diese anhaltende Problematik wird vor allem durch den Einsatz langfristig gültiger Credentials, durch fehlende Ablauf- und Rotationsrichtlinien sowie durch das Fehlen automatisierter Prozesse für die Rotation und den Entzug von Secrets begünstigt.

Risiken im Zusammenhang mit Non-Human Identities (OWASP Top 10 NHI)

Das OWASP (Open Web Application Security Project) hat kürzlich eine eigene Top-10-Liste der größten Risiken im Umgang mit Non-Human Identities veröffentlicht – ein deutlicher Hinweis darauf, wie relevant dieses Thema inzwischen für die IT-Sicherheit geworden ist. Dazu zählen:

1. Unzureichende Inventarisierung und Verwaltung von NHIs: Fehlende Sichtbarkeit und fehlende Kontrolle über vorhandene nicht-menschliche Identitäten.

2. Hartcodierte Secrets: API-Schlüssel, Passwörter oder Zertifikate, die direkt im Code oder in Konfigurationsdateien hinterlegt sind.

3. Kompromittiertes Secrets-Management: Unsichere Speicherung oder mangelnde Rotation von Secrets.

4. Übermäßige Berechtigungen: NHIs erhalten weiterreichende Rechte, als für ihre eigentliche Funktion nötig wäre.

5. Fehlende starke Authentifizierung und Autorisierung: Einsatz schwacher Authentifizierungsmechanismen oder fehlende, robuste Berechtigungsrichtlinien.

6. Unzureichendes Monitoring und Auditing: Mangelnde Nachverfolgung der NHI-Aktivität, wodurch auffälliges Verhalten unerkannt bleibt.

7. Unsichere Bereitstellung und Aufhebung von NHIs: Schwache Prozesse beim Erstellen oder Löschen von Identitäten, was verwaiste Zugänge hinterlassen kann.

8. Missbräuchliche Nutzung von NHIs: Kompromittierte NHIs werden von Angreifern genutzt, um unerlaubte Aktionen auszuführen.

9. Schwachstellen in NHI-Managementplattformen: Sicherheitslücken in Tools oder Systemen, die NHIs verwalten sollen.

10. Fehlendes Lifecycle-Management: Keine klaren Richtlinien für Erstellung, Nutzung, Entzug oder Löschung von NHIs.

Ich empfehle jedem, der sich tiefer mit dem Thema beschäftigen möchte, diese Liste sowie die weiterführenden Artikel auf der OWASP-Website als Einstieg zu lesen.

Best Practices für den Umgang mit Non-Human Identities

Um die wachsenden Sicherheitsrisiken rund um NHIs wirksam zu kontrollieren, benötigen Unternehmen einen proaktiven, strukturierten und am gesamten Lebenszyklus orientierten Ansatz. Das bedeutet: NHI-Governance muss fester Bestandteil aller Identity- und Access-Management-Prozesse sein.

Sensibilisierung und Schulungen

Wenn es um die Absicherung von NHIs geht, ist mein erster Impuls immer derselbe: Teams müssen verstehen, warum NHI-Sicherheit so wichtig ist und welche Best Practices gelten. Gamifizierte Formate wie kleine Capture-the-Flag-Challenges, bei denen NHIs bewusst missbraucht werden können (Grüße an das Terraform-Projekt-Repository), sind oft besonders wirksam, um Risiken greifbar zu machen.

Umfassende Discovery und Inventarisierung

Wie bei menschlichen Benutzerprivilegien beginnt der Prozess damit, alle NHIs in der gesamten Infrastruktur zu identifizieren und ihre jeweiligen Rechte zu überprüfen. Spezialisierte Tools unterstützen dabei, Service Accounts, Token und weitere Machine Identities automatisiert sowohl in Cloud- als auch in On-Prem-Umgebungen aufzuspüren.

Zentralisiertes Secrets Management

API-Schlüssel, Tokens und Zertifikate sollten konsequent über sichere Vault-Lösungen verwaltet werden – etwa WALLIX Bastion oder OpenBao Vault. Solche Plattformen bieten Verschlüsselung, granulare Zugriffskontrolle sowie Audit-Logging für alle hinterlegten Secrets und bilden damit die Grundlage eines sicheren NHI-Ökosystems.

Prinzip der minimalen Rechtevergabe

NHIs sollten stets nur die Berechtigungen erhalten, die sie tatsächlich benötigen – eigentlich selbstverständlich, aber in der Praxis lohnt es sich, diese Regel immer wieder zu betonen. Dazu gehören robuste Authentifizierungsmechanismen und granular definierte Autorisierungsrichtlinien:

1. Regelmäßige Rotation von Secrets ist zentral, um langfristig gültige Zugangsdaten zu vermeiden. Plattformen wie OpenBAO oder WALLIX Vault unterstützen automatisierte Rotationsrichtlinien, sodass Credentials ohne manuellen Aufwand regelmäßig erneuert werden.

2. Ebenso wichtig sind eine kontinuierliche Überwachung und Protokollierung aller NHI-Aktivitäten, um Anomalien früh zu erkennen.

3. Ergänzend sollten Unternehmen die Provisionierung und Deprovisionierung von NHIs automatisieren, um unverwaltete Zugänge zu vermeiden. Die meisten CI/CD-Systeme ermöglichen inzwischen die Lifecycle-Automatisierung durch Vault-Integrationen, Funktionen, Plugins – oder ein wenig Kreativität.

4. Ein weiterer zentraler Schritt ist die Einführung eines klar definierten NHI-Lebenszyklus: von der Erstellung über die Nutzung bis zur Entfernung. Diese Vorgaben sollten ausdrücklich in der IT-Sicherheitsrichtlinie festgehalten und allen Mitarbeitenden zugänglich gemacht werden. Viele Vault-Lösungen bieten zudem Lifecycle-Hooks und Metadaten-Tagging, um Eigentümerschaft, Zweck und Ablaufdaten sauber zu dokumentieren.

5. Regelmäßige, NHI-spezifische Sicherheitsbewertungen runden das Ganze ab. Sicherheitsprüfungen sollten sich nicht nur auf einzelne Anwendungen oder die Gesamtlandschaft konzentrieren, sondern gezielt NHIs einbeziehen. Dazu gehört etwa, die Berechtigungsumfänge von GitHub- oder GitLab-Tokens zu testen, die Entwickler erstellen – diese sind standardmäßig häufig überberechtigt und werden selten rotiert.

Hardwarebasierte Sicherheit

Für Non-Human Identities lohnt sich zudem der Einsatz hardwarebasierter Sicherheitsmechanismen wie TPM 2.0. Trusted Platform Modules speichern kryptografische Schlüssel sicher, unterstützen Secure Boot und ermöglichen Device Attestation. So lässt sich sicherstellen, dass nur vertrauenswürdige NHIs Zugang zu sensiblen Systemen oder Daten erhalten. Das stärkt die Bindung zwischen Identität und Gerät und schützt vor Manipulationen auf Hardware-Ebene – ein wesentlicher Baustein für starke Authentifizierung und Autorisierung.

Fazit

Non-Human Identities (NHIs) sind heute ein tragendes Fundament moderner digitaler Ökosysteme. Sie ermöglichen Automatisierung, Skalierbarkeit und nahtlose Integrationen über Plattformen hinweg.

Doch mit ihrer wachsenden Verbreitung steigt auch das Risiko. Und dabei haben wir das explosive Zusammenspiel von NHIs und KI noch nicht einmal angesprochen – etwa, wenn der KI-Assistent in VS-Code plötzlich Zugriff auf den gesamten Quellcode erhält, inklusive sämtlicher hinterlegter NHIs…

Die sichere Verwaltung von NHIs ist längst kein optionaler Zusatz mehr, sondern ein strategisches Muss, um kritische Systeme und Daten zu schützen – und ein weiterer unverzichtbarer Punkt auf jeder Security Roadmap.

Wer die besonderen Herausforderungen von NHIs erkennt und eine robuste Governance etabliert, kann aus einer potenziellen Schwachstelle sogar eine Stärke machen. Proaktive Erkennung, konsequente Least-Privilege-Modelle, klar definierte Lebenszyklen und kontinuierliches Monitoring sind dabei nicht nur Best Practices – sie sind essenzielle Verteidigungsmaßnahmen in der heutigen Bedrohungslandschaft.

In die Sicherheit von NHIs zu investieren bedeutet, in die Widerstandsfähigkeit, Vertrauenswürdigkeit und Zukunftsfähigkeit der digitalen Infrastruktur von morgen zu investieren.