Digitale Kollegen

von Martin Kuppinger

Nicht-menschliche Identitäten sind allgegenwärtig: Ob Workloads in der Cloud, Servicekonten in IT-Systemen oder autonome Agenten in KI-Anwendungen. Doch viele dieser Identitäten sind schlecht oder gar nicht verwaltet. Ein strategischer, ganzheitlicher Ansatz für das Management dieser Identitäten wird zur Pflicht.

Nicht-menschliche Identitäten (Non-Human Identities, NHI) sind kein neues Phänomen. Ihre Anzahl und Komplexität nehmen jedoch exponentiell zu. Dabei umfasst der Begriff Identitäten für Workloads, Services, Internet-of-Things-(IoT)-Geräte, Maschinen sowie zunehmend auch autonome Anwendungen der künstlichen Intelligenz (KI). Studien und Beobachtungen in Unternehmen zeigen, dass NHI die Anzahl menschlicher Identitäten um ein Vielfaches übertreffen: Über Verhältnisse von 40:1 bis zu 80:1 wird berichtet. Unabhängig von der korrekten Zahl macht das deutlich, dass es sich um ein IAM- und Cybersicherheitsproblem von erheblichem Ausmaß und mit massiver Skalierung handelt. Daraus entstehen sowohl vielfältige Sicherheitsrisiken als auch der Bedarf für Automatisierung.

Die Herausforderung liegt nicht allein in der schieren Zahl. NHI entstehen oft automatisiert, zum Beispiel im Rahmen von Continuous-Integration/Continuous-Delivery-(CI/CD)-Pipelines oder durch Instanzen von Kubernetes-Pods. Ihre Lebensdauer kann wenige Sekunden oder mehrere Jahre betragen. Und ihre Privilegien reichen von einfachen Lesezugriffen bis zu umfassenden Administrationsrechten.

Ein Großteil der heutigen NHI ist entweder gar nicht bekannt oder arbeitet mit statischen Zugangsinformationen (Credentials), die sich über lange Zeiträume nicht ändern. Diese Kombination aus Intransparenz und dauerhaften Privilegien schafft eine massive Angriffsfläche, die klassische Konzepte im Bereich Identity and Access Management (IAM) nicht adressiert. Diese betrachtet nur menschliche Identitäten sowie einen kleinen Ausschnitt an NHIs, nämlich die von PAM (Privileged Access Management) verwalteten technischen und funktionalen Benutzerkonten wie Dienst -und Systemkonten.

Management von Non-Human Identities

Der Begriff "Non-Human Identity Management" beschreibt Strategien, Technologien und Prozesse zur Verwaltung nicht-menschlicher Identitäten. Dabei existieren unterschiedliche Bezeichnungen, die teils synonym, teils für Teilbereiche verwendet werden (Tabelle 1).

Das NHI-Management umfasst die Identifikation, Erstellung, Governance und das Löschen dieser Identitäten einschließlich des Managements von Credentials (Authentifizierungsinformationen), dem Erstellen, Verwalten und Zuordnen von Richtlinien und dem Management von resultierenden Risiken. Ziel ist es, auch für NHI Grundprinzipien wie Least Privilege (Minimalprinzip) und Zero Standing Privileges (keine dauerhaften Berechtigungen) durchzusetzen.

Die Vielfalt der Begriffe im Umfeld nicht-menschlicher Identitäten spiegelt auch die Komplexität des Themas wider. Während Workload Identity häufig im Kontext von cloudnativen Architekturen und DevOps eine Rolle spielt, zielt Machine Identity stärker auf klassische System-zu-System-Kommunikation, etwa im Rahmen von TLS-Zertifikaten oder Gerätezertifikaten für IoT. Agentic AI Identity hingegen beschreibt eine neue Klasse von Identitäten, die zunehmend durch autonome, lernfähige Systeme geprägt wird. Diese Identitäten bringen zusätzliche Anforderungen mit sich – etwa hinsichtlich des Entscheidungskontexts sowie der Fähigkeit, sich im Lauf der Zeit zu verändern.

Ein zukunftsorientiertes Modell für das NHI-Management sollte daher nicht auf festen Typisierungen basieren, sondern auf der Beschreibung von Attributen und Fähigkeiten. Hierzu zählen beispielsweise die Dauer der Existenz einer Identität (kurzlebig/ephemer vs. persistent), ihre Herkunft (automatisch generiert vs. manuell angelegt), der Grad der Autonomie sowie die Art der Interaktion mit Systemen. Eine solche attributbasierte Herangehensweise ermöglicht eine flexiblere Governance und fördert ein besseres Verständnis darüber, wie Identitäten zu behandeln sind, unabhängig davon, wie sie bezeichnet werden.

CIEM als Gegenstück zum Identitätsmanagement

Cloud Infrastructure Entitlement Management (CIEM) fokussiert auf die Verwaltung und Analyse von Zugriffsrechten in Cloudinfrastrukturen. Damit steht CIEM im Spannungsfeld zwischen NHI-Management und Zugriffs-Governance (Access Governance). Ein alternativer Begriff könnte daher "Non-Human Access Management" (NHA) sein, der die Funktion von CIEM wesentlich genauer beschreiben würde und auch deutlich macht, dass zwischen NHI und CIEM sehr enge Beziehungen bestehen, die in der Praxis aber derzeit meist nicht umgesetzt sind.

CIEM-Werkzeuge analysieren, welche NHI auf welche Ressourcen Zugriff haben, ob diese Rechte zu weitreichend sind und ob Prinzipien wie Least Privilege verletzt werden. CIEM stellt damit das notwendige Gegengewicht zum Identitätsmanagement dar: Wo NHI-Management für die Verwaltung der Identität und der zugehörigen Credentials zuständig ist, betrachtet CIEM den Zugang zu konkreten Ressourcen in der Cloud.

Besonders in dynamischen Cloudumgebungen mit Infrastructure-as-Code und automatisierter Bereitstellung ist es für Unternehmen nahezu unmöglich, manuell den Überblick über alle Zugriffsrechte nicht-menschlicher Identitäten zu behalten. CIEM-Werkzeuge ermöglichen hier Transparenz durch kontinuierliche Analyse und Visualisierung der Entitlement-Strukturen. Sie erkennen überprivilegierte Rollen und empfehlen Optimierungen auf Basis tatsächlicher Nutzungsmuster – ein wesentlicher Schritt zur Umsetzung des Least-Privilege-Prinzips in komplexen Cloudlandschaften.

Zudem bieten moderne CIEM-Ansätze zunehmend integrierte Funktionen zur Korrelation mit anderen Sicherheitstechnologien. So lassen sich etwa Anomalien im Zugriffsverhalten durch die Kombination mit Identity Threat Detection & Response (ITDR) identifizieren. Durch die automatisierte Korrektur fehlerhafter oder riskanter Entitlements (Berechtigungen) entsteht ein adaptives Sicherheitsmodell, das auch auf volatile und kurzfristig erzeugte Workload Identities reagieren kann. Damit wird CIEM zu einem unverzichtbaren Baustein einer modernen, risikoorientierten Cloudsecurity-Architektur.

Schnittstellen zu anderen Sicherheitssegmenten

NHI-Management steht nicht isoliert. Zahlreiche andere Segmente im Bereich Identity and Access Management und Cybersicherheit weisen Überschneidungen oder Beziehungen zu NHI Management auf (Tabelle 2). Diese Segmente müssen in ein ganzheitliches Identitäts- und Sicherheitsmodell wie eine Identity Fabric integriert werden, das sowohl menschliche als auch nicht-menschliche Akteure abdeckt.

Privileged Access Management war historisch nicht ausschließlich auf privilegierte menschliche Benutzer fokussiert. Schon früh adressierte PAM auch funktionale und technische Konten, insbesondere sogenannte Shared Accounts oder Dienstkonten auf Betriebssystem- und Datenbankebene. Diese Konten bilden einen Teilbereich nicht-menschlicher Identitäten, da sie entweder automatisiert genutzt oder von mehreren Personen mit erhöhten Berechtigungen gemeinsam verwendet werden. Mit der Ausweitung dynamischer, kurzlebiger Workload Identities muss PAM jedoch weitergedacht und enger mit modernen NHI-Management-Konzepten verzahnt werden.

Secrets-Management ist ein zentraler Baustein im Umgang mit NHI, da fast jede nicht-menschliche Identität Authentifizierungsinformationen in Form von Secrets benötigt. Die sichere Verwaltung, Versionierung und Rotation dieser Secrets ist essenziell, um Sicherheitsrisiken und -schwachstellen zu vermeiden. Ein isolierter Einsatz von Vault-Technologien genügt jedoch nicht. Secrets, einschließlich der Credentials für die Authentifizierung, stehen in Verbindung mit den Identitäten, zum Beispiel von Workloads, mit definierten Besitzern von Anwendungen und Softwarekomponenten und mit den Sicherheitsrichtlinien.

Die Verwaltung nur von Secrets unterschiedlicher Art, von SSH Keys und SSH-Zertifikaten bis zu API-Tokens, ist nicht ausreichend. Ziel muss es sein, Secrets nicht nur in einem Vault abzuspeichern, sondern in einem kontrollierten Lebenszyklus zu führen.

Cloudnative Application Protection Platforms (CNAPP) erweitern den Schutz auf Anwendungsebene. Sie kombinieren unter anderem CIEM, CWPP und Schwachstellenmanagement. Im Zusammenhang mit NHI ist CNAPP besonders relevant, weil es Kontextinformationen über Workloads und deren Interaktionen liefert. Diese Informationen ermöglichen es, den Risikokontext einzelner Identitäten besser zu bewerten, etwa wenn eine Workload Identity Zugriff auf besonders sensitive Ressourcen anfordert oder von einer verwundbaren Anwendungskomponente ausgeht.

Cloud Workload Protection Platforms (CWPP) fokussieren auf den Schutz von Workloads in Cloud- und Hybridumgebungen. Sie überwachen Laufzeitverhalten, identifizieren Schwachstellen und können Workloads auf Basis von Policies isolieren oder blockieren. In Bezug auf NHI liefern CWPP-Lösungen wertvolle Signale darüber, welche Workload-Identitäten in welchem Kontext aktiv sind, ob sie von potenziell kompromittierten Instanzen stammen oder auffälliges Verhalten zeigen. Damit ergänzen sie die rein zugriffsbasierte Sichtweise anderer Sicherheitstechnologien um eine operative Perspektive.

Ein weiteres zentrales Bindeglied ist Identity Governance & Administration (IGA). Auch für NHI müssen Eigentümer benannt, Lebenszyklen definiert und Zugriffsrechte regelmäßig überprüft werden. Klassische IGA-Prozesse wie Re-Zertifizierungen und das Joiner-Mover-Leaver-Prinzip lassen sich adaptieren, um auch für nicht-menschliche Identitäten Kontrolle und Verantwortlichkeit sicherzustellen. Dies erfordert jedoch angepasste Workflows und Bewertungslogiken, die etwa auf technische Metadaten und Nutzungsmuster statt personenbezogener Attribute zurückgreifen. Außerdem ist hier ein hohes Maß an Automatisierung erforderlich, schon aufgrund der Volatilität von NHIs und deren großer Anzahl.

Nicht zuletzt kommt dem Zusammenspiel mit Identity Threat Detection & Response (ITDR) eine besondere Rolle zu. NHI agieren hochautomatisiert, häufig im Hintergrund – was sie besonders anfällig für Missbrauch und schwer zu überwachen macht. Nur durch verhaltensbasierte Analyse lassen sich Anomalien, etwa die missbräuchliche Nutzung eines Secrets oder die Ausweitung eines Zugriffsmusters, zeitnah erkennen. ITDR erweitert damit die Reaktionsfähigkeit auf Bedrohungen im Kontext von NHI deutlich und muss integraler Bestandteil jeder Sicherheitsstrategie in diesem Bereich sein.

Was heutige Produkte liefern – und was fehlt

Viele der aktuell als NHI-Management vermarkteten Produkte adressieren primär die Verwaltung von Secrets, weniger jedoch das gesamte Identitäts- und Berechtigungsmodell. Dabei sind mehrere Dimensionen zu berücksichtigen:

- Secret vs. Identität: Ein Secret ist nicht gleich einer Identität. Secrets sind Zugangsinformationen; die Identität definiert die Entität, ihre Eigenschaften und Zuständigkeiten.

- Statisch vs. dynamisch: Langlebige Secrets widersprechen Sicherheitsprinzipien. Ephemere Identitäten mit kurzlebigen Tokens sind das Ziel.

- Credential vs. Entitlement: Der Besitz eines Secrets allein sagt nichts über Berechtigungen aus. Das Mapping von Identität zu Entitlement ist entscheidend.

In der Praxis fehlt es vielen Produkten an einer durchgängigen Sicht auf den Zusammenhang zwischen Identität, zugewiesenem Secret, technischer und organisatorischer Ownership und tatsächlichem Zugriffsrecht. Einzelne Komponenten wie Token-Issuer, Vaults oder Identity Provider (IdP) agieren typischerweise isoliert und ohne konsistente Richtlinien und deren Durchsetzung. Dadurch entstehen Grauzonen in der Sicherheitsarchitektur, insbesondere wenn Identitäten durch automatische Prozesse außerhalb klassischer IAM-Provisioning erzeugt werden.

Ein weiteres Defizit besteht im Fehlen eines definierten und verwalteten Lebenszyklusmanagement für NHI. Während für menschliche Identitäten typische Ereignisse wie Eintritt, Rollenwechsel oder Austritt klar definiert und automatisiert sind, fehlen vergleichbare Trigger für NHI. Ohne explizite Definition von Ablaufdaten, Abhängigkeiten oder Nutzungskontext bleiben viele Identitäten aktiv, obwohl sie nicht mehr benötigt werden. Diese Art von Schattenidentitäten stellt ein erhebliches Risiko dar, insbesondere in Kombination mit überprivilegierten Secrets.

Darüber hinaus bestehen Schwächen bei der Integration von Analyse- und Reaktionsmechanismen. Nur wenige Produkte bieten native Unterstützung für kontinuierliches Monitoring der Secret-Nutzung oder erkennen Anomalien im Verhalten einzelner Workloads. Hier wäre, wie bereits erwähnt, eine engere Verknüpfung mit Identity Threat Detection & Response erforderlich, um das Verhalten nicht-menschlicher Identitäten situativ zu bewerten und automatische Gegenmaßnahmen einleiten zu können. Solche Funktionen sind heute noch eher die Ausnahme als der Standard.

Tabelle 3 zeigt, welche Vaults heute sehr häufig und in welchen Kontexten typischerweise zum Einsatz kommen. Diese Vaults müssen in das übergeordnete NHI-Management einfließen, um eine zentrale Sicht auf Identitäten, Policies, Secrets und Access zu erreichen.

NHI als Teil der Identity Fabric

Eine isolierte Betrachtung von Non-Human-Identity-Management greift zu kurz. In modernen IT-Landschaften, die zunehmend durch hybride, dynamische und verteilte Architekturen geprägt sind, müssen sämtliche Identitäten, menschliche wie nicht-menschliche, Teil eines gemeinsamen Identitäts- und Zugriffsmodells sein. Die Identity Fabric bildet hierfür das strukturelle und konzeptionelle Rückgrat. Sie ermöglicht es, unterschiedliche Identitätsarten mit ihren spezifischen Anforderungen konsistent und integriert zu verwalten.

Eine Identity Fabric umfasst typischerweise Funktionen zur Identitätsbereitstellung, Authentifizierung, Autorisierung, Governance und zum Zugriffsschutz über Plattformgrenzen hinweg. Für NHI bedeutet dies, dass sie nicht als Sonderfall, sondern als gleichwertige Entitäten behandelt werden müssen, mit denselben Anforderungen an Nachvollziehbarkeit, Kontrolle und Automatisierung. Dies erfordert eine klare Erweiterung klassischer IAM-Modelle um NHI-spezifische Elemente, etwa zur Verwaltung ephemerer Workloads, plattformübergreifender Secrets oder autonom agierender Agenten.

Ein strategischer NHI-Ansatz innerhalb der Identity Fabric beginnt mit einer vollständigen Erfassung aller nicht-menschlichen Identitäten. Diese Discovery muss kontinuierlich erfolgen und sowohl deklarative (zum Beispiel Infrastrukturdefinitionen) als auch beobachtbare (etwa Laufzeitdaten) Quellen einbeziehen. Darauf aufbauend folgt eine eindeutige Zuordnung von Verantwortlichkeiten: Wer ist der Owner einer Identität, wer darf diese verwenden, wer kontrolliert die zugewiesenen Berechtigungen? Ohne diese Governance bleibt NHI-Management fragmentiert und schwer auditierbar.

Darüber hinaus muss die Identity Fabric auch die technischen Mechanismen zur Absicherung und Durchsetzung bereitstellen. Dazu zählen automatisierte Bereitstellungs- und Löschprozesse, standardisierte Schnittstellen zur Integration von Vaults und Policy Engines sowie zentrale Steuerungsmechanismen für Zugriffskontrolle und Rollenmanagement. Ein Policy-as-Code-Ansatz mit automatisch auf Basis der Richtlinien generiertem Code kann hier helfen, Richtlinien über System- und Plattformgrenzen hinweg konsistent durchzusetzen und gleichzeitig die Anforderungen der Softwareentwicklung an Geschwindigkeit und Flexibilität zu erfüllen.

Wichtig ist auch, dass die Identity Fabric über ein integratives Metamodell verfügt, das verschiedene Identitätstypen, Credential-Arten, Nutzungskontexte und Vertrauensniveaus abbilden kann. Dieses Modell dient als Grundlage für automatisierte Entscheidungen, etwa zur Vergabe temporärer Zugriffsrechte oder zur Eskalation bei Regelverstößen. Es hilft zudem, regulatorische Anforderungen wie Nachvollziehbarkeit, Data Residency oder Mandantentrennung auch für NHI umzusetzen.

Ein solches strategisches Konzept muss von Beginn an auch auf Heterogenität ausgelegt sein. In der Realität verwenden Unternehmen meist mehrere Cloudplattformen, unterschiedliche Vault-Technologien und verschiedene Ansätze für die Softwareentwicklung. Eine zentrale Identity Fabric muss diese Vielfalt orchestrieren, ohne sie künstlich einzuschränken. Ziel ist eine übergreifende Steuerung, nicht die Homogenisierung der Werkzeuge. Deshalb ist Modularität ein wesentlicher Erfolgsfaktor: Unternehmen sollten auf interoperable Bausteine setzen, die sich flexibel in bestehende Landschaften einfügen lassen.

Schließlich hat die Integration von NHI in die Identity Fabric auch eine kulturelle Komponente. Die Zusammenarbeit zwischen IT-Sicherheit, IAM, Cloud-Governance und Softwareentwicklung muss institutionalisiert werden. Dies gelingt nur durch klar definierte Prozesse, abgestimmte Schnittstellen und ein gemeinsames Zielbild. Die Identity Fabric ist damit nicht nur eine technologische Architektur, sondern auch der organisatorische Rahmen für ein modernes, skalierbares Identitätsmanagement. NHI sind in diesem Konstrukt also keine Ausnahme mehr – sondern integraler Bestandteil.

Organisatorische Herausforderungen

Die Verantwortung für NHI liegt typischerweise zwischen Softwareentwicklung, DevOps, IAM und IT-Security. Dieses geteilte Zuständigkeitsmodell führt oft zu Lücken. Klare Rollenzuordnungen sind erforderlich:

- IAM / IT-Security definiert Governance und Sicherheitsmechanismen.

- Softwareentwicklung konsumiert Dienste und Vaults im Rahmen agiler Prozesse.

Ziel ist eine arbeitsteilige Kooperation. Sicherheit darf die Entwicklung nicht ausbremsen, sondern muss durch automatisierte Dienste und Richtlinien unterstützen. Gerade in DevOps-Umgebungen sind verschiedene Vaults parallel im Einsatz (Tabelle 3). Diese müssen erkannt, verwaltet und kontrolliert eingebunden werden.

Eine zusätzliche Herausforderung ergibt sich aus der fehlenden Standardisierung von Verantwortlichkeitsmodellen für nicht-menschliche Identitäten. Während Rollen und Zuständigkeiten bei menschlichen Nutzern häufig im Rahmen von Onboarding-Prozessen und Organisationsstrukturen festgelegt sind, fehlen bei NHI oft vergleichbare Mechanismen. Unternehmen benötigen daher definierte Verfahren zur Zuweisung technischer Ownerships, die nachvollziehbar dokumentiert und regelmäßig überprüft werden. Dies umfasst auch Prozesse zur Übertragung von Verantwortlichkeiten bei Projektwechseln oder beim Ausscheiden technischer Eigentümer.

Ebenso zentral ist die Verzahnung der Sicherheitsanforderungen mit den Deployment-Pipelines in der Anwendungsentwicklung. Sicherheitsrichtlinien müssen so formuliert und implementiert sein, dass sie sich nahtlos in bestehende Prozesse für CI/CD integrieren lassen. Statt Sicherheit als separate Kontrollinstanz nachgelagert zu prüfen, sollten Prüfungen und Policy-Checks integraler Bestandteil der Automatisierung sein. Auf diese Weise können sowohl Sicherheits- als auch Entwicklungsziele effizient erreicht werden, ohne dass Zielkonflikte entstehen.

Fazit

Nicht-menschliche Identitäten sind ein zentrales Element moderner IT-Landschaften. Ihre sichere Verwaltung erfordert mehr als punktuelle Lösungen. Unternehmen benötigen eine ganzheitliche Strategie für NHI Management, eingebettet in eine Identity Fabric, abgestimmt auf Cloud- und DevOps-Realitäten. Ein zukunftsfähiges NHI-Management sollte auf einem modularen Architekturprinzip beruhen, das die Vielfalt der eingesetzten Plattformen, Vaults und Entwicklungsmethoden berücksichtigt. So lässt sich die notwendige Flexibilität mit zentraler Steuerbarkeit verbinden.

Dabei müssen zentrale Governance-Vorgaben auf Organisationsebene mit dezentralen Umsetzungsmöglichkeiten in den Entwicklungsteams kombiniert werden. Dieses Spannungsfeld lässt sich nur mit definierten Schnittstellen, abgestimmten Rollenmodellen und gemeinsamer Zieldefinition auflösen. Die Absicherung nicht-menschlicher Identitäten entscheidet über die Resilienz digitaler Infrastrukturen. Die Herausforderungen im Umgang mit NHI betreffen dabei nicht nur die IT-Abteilungen, sondern die gesamte Organisation.

Begriff	Definition / Fokus	Abgrenzung
Non-Human Identity	Oberbegriff für alle digitalen Identitäten ohne Bezug zu einem Menschen	Umfasst auch Workloads, Maschinen, Agenten
Machine Identity	Identität physischer oder virtueller Systeme (etwa Server, IoT-Geräte)	Typischerweise langlebig, mit Zertifikaten gesichert
Workload Identity	Identitäten für temporäre Prozesse (etwa Container, Serverless Functions)	Ephemer, dynamisch, tokenbasiert
Service Account / API Identity	Funktionale Konten für Dienste, Pipelines, APIs	Oft statisch, mit hohem Berechtigungsniveau
Agentic AI Identity	Identität für autonome KI-Agenten	Kontextbezogen, adaptiv, zielorientiert

Security-Segment	Beziehung zu NHI-Management
Privileged Access Management	Verwaltung privilegierter NHI und privilegierter, Menschen zugeordneter Benutzerkonten, insbesondere technischer und geteilter Servicekonten.
Secrets Management	Absicherung und Rotation von Zugriffsinformationen (Tokens, Keys) für NHI.
Identity Governance & Administration (IGA)	Governance, Verantwortlichkeiten und Lifecycle- Management auch für NHI.
Cloud-Native Application Protection Platform (CNAPP)	Betrachtung von Sicherheitsaspekten auf Anwendungsebene, inklusive NHI-Kontext.
Cloud Workload Protection Platforms (CWPP)	Schutz von Workloads inklusive deren Identitäten, Laufzeitüberwachung und Schwachstellenanalyse.
Identity Threat Detection & Response (ITDR)	Detektion anomalen Verhaltens nicht-menschlicher Identitäten.

Vault	Anbieter / Technologie	Typischer Einsatzbereich
HashiCorp Vault [1]	Open Source / Enterprise	Multicloud, Development Security Operations (DevSecOps), Kubernetes
AWS Secrets Manager [2]	Amazon Web Services (AWS)	AWS Services, Lambda, Elastic Container Service (ECS), et cetera
Azure Key Vault [3]	Microsoft Azure	Entra ID, Functions, App Services
Google Secret Manager [4]	Google Cloud Platform (GCP)	GCP-native Workloads, IAM-Integration

Identität für Maschinen, Workloads und Agenten