Ein Leitfaden zur Absicherung nicht-menschlicher Identitäten

Was sind nicht-menschliche Identitäten (NHIs)?

Auf den ersten Blick scheint der Begriff nicht-menschliche Identität alles zu umfassen, was keine Person ist, wie Server, Geräte, Workloads, Dienstkonten und so weiter. Aber das Verständnis der Branche von Identität hat sich weiterentwickelt. In älteren Umgebungen beziehen sich Maschinenidentitäten im Allgemeinen auf Zertifikate, SSH-Schlüssel, Gerätekonten oder Dienstkonten, die mit Betriebssystemen oder Hardware verbunden sind. Diese waren relativ statisch, vorhersehbar und eng mit den Infrastruktur-Stacks verbunden. In einer cloud-nativen, API-gesteuerten Umgebung reicht diese Definition jedoch nicht mehr aus. NHIs umfassen eine viel breitere und dynamischere Gruppe von Identitäten, darunter die folgenden:

• Workload-Identitäten. Diese repräsentieren Cloud-Workloads – VMs, Container, serverlose Funktionen –, die sich bei Cloud-Ressourcen authentifizieren dürfen. Beispiele hierfür sind AWS IAM-Rollen (Identity and Access Management) für EC2 oder Lambda, Azure Managed Identities und Google Cloud-Dienstkonten. Diese Identitäten bestehen oft nur für Mikrosekunden bis Stunden und generieren häufig temporäre Anmeldedaten.
• Dienstkonten. Dazu gehören Betriebssystem- oder Anwendungskonten, die von internen Diensten, Anwendungen, Datenbanken oder Backup-Systemen verwendet werden. Sie führen häufig Hintergrundprozesse oder geplante Aufgaben aus. Obwohl sie zu den ältesten Formen von NHIs gehören, sind sie nach wie vor eine der am wenigsten regulierten und am meisten privilegierten.
• Anwendungsidentitäten. Hierbei handelt es sich um Softwarekomponenten wie APIs, Microservices und Webanwendungen, die sich bei Datenbanken, Message Brokern oder APIs von Drittanbietern authentifizieren. Diese Identitäten können API-Token, OAuth-Geheimnisse oder eingebettete Schlüssel verwenden.
• Geheimnisse und API-Schlüssel. Dazu gehören Anmeldedaten, die direkt von Software, Skripten, Automatisierungspipelines oder Infrastructure-as-Code-Vorlagen verwendet werden. Oft handelt es sich dabei um API-Schlüssel – SaaS, Cloud, Zahlungsgateways –, Datenbankverbindungszeichenfolgen, OAuth-Client-Geheimnisse, GitHub- und GitLab-Token sowie Container-Registrierungstoken.
• Kombinierte KI- und ML-Identitäten. Mit dem Aufkommen von KI-Agenten, großen sprachbasierten Workflows und autonomen Pipelines erstellen und verwenden modellgesteuerte Prozesse Identitäten, um APIs aufzurufen, Daten abzurufen oder automatisierte Aktionen durchzuführen.
• OT- und IoT-Identitäten. Sensoren, industrielle Steuerungssysteme, Kameras, medizinische Geräte und andere eingebettete Systeme authentifizieren sich gegenüber Verwaltungskonsolen oder Datensammlern. Sofern nicht ausdrücklich geregelt, verwenden sie häufig schwache oder werkseitig voreingestellte Anmeldedaten.

Während sich Maschinenidentitäten und NHIs überschneiden, weisen nicht-menschliche Identitäten die folgenden drei grundlegenden Unterschiede auf:

• Skalierbarkeit. Herkömmliche Maschinenidentitäten – Zertifikate, Gerätekonten – sind relativ gering in ihrer Anzahl und langlebig. NHIs skalieren in die Zehntausende oder Millionen und werden dynamisch durch CI/CD-Pipelines (Continuous Integration/Continuous Delivery), automatisch skalierende Workloads, KI und selbstheilende Infrastruktur sowie ereignisgesteuerte Automatisierung erstellt. Die meisten älteren IAM- und PAM-Tools (Privileged Access Management) wurden nie für ein solches Volumen und eine solche Fluktuation entwickelt.
• Vielfalt der Authentifizierungsmethoden. Maschinenidentitäten haben in der Vergangenheit Zertifikate oder Kerberos zur Authentifizierung verwendet. NHIs authentifizieren sich mit einer viel breiteren Palette von Methoden, darunter JSON-Web-Token, Cloud-IAM-Rollen, OAuth2/Open ID Connect-Geheimnisse, langlebige API-Schlüssel und mehr. Jede davon erfordert eine einzigartige Governance, Rotation, Lebenszyklusverwaltung und Telemetrieabwicklung.
• Mehr Autonomie. NHIs sind oft autonomer als herkömmliche Maschinenidentitäten und führen in vielen Fällen eigenständig Aktionen aus. Sie initiieren API-Aufrufe, verschieben Daten, starten Ressourcen, führen Skripte aus und interagieren mit kritischen Systemen. Diese Autonomie bedeutet, dass NHIs bei einer Kompromittierung extrem schnell großflächige Schäden verursachen können, wobei herkömmliche Sicherheitskontrollen das Verhalten von NHIs möglicherweise nicht als abnormal erkennen.

Herausforderungen beim Schutz von nicht-menschlichen Identitäten (NHIs)

NHIs stellen eine neue Klasse von sich schnell verändernden, hochwirksamen Identitätsrisiken dar, die mit den vorhandenen Tools oder mentalen Modellen für menschliche Identitäten nicht einfach zu bewältigen sind. Diese Herausforderung wird noch größer, wenn Unternehmen die Automatisierung und die Einführung der Cloud vorantreiben. Die Ausbreitung von NHIs schreitet zudem schneller voran als die Weiterentwicklung der Governance.

Die folgenden Umstände machen den Schutz von NHIs besonders schwierig:

• Mangelnde Verantwortlichkeit und Rechenschaftspflicht. NHIs werden oft automatisch von Infrastrukturteams, DevOps-Pipelines, Anwendungsteams und SaaS-Integrationen erstellt. In vielen Fällen ist nicht klar, wer für die Identität verantwortlich ist, wer Berechtigungen kontrolliert und genehmigt oder wer Schlüssel rotieren sollte und so weiter. Dieses Vakuum in Bezug auf die Verantwortlichkeit führt dazu, dass Identitäten viel länger bestehen bleiben als beabsichtigt.
• Übermäßige Berechtigungen. NHIs erhalten häufig weitreichende, überdimensionierte Berechtigungen, darunter Wildcard-IAM-Rollen in der Cloud, Dienstkonten mit vollständigen Domänenadministratorrechten und API-Schlüssel mit vollständigen Lese-/Schreibberechtigungen. Da NHIs Geschäftsprozesse automatisieren, befürchten Teams, diese zu stören, und vermeiden es, Berechtigungen zu reduzieren. Infolgedessen kann eine Reihe von Identitäten auf riesige Mengen sensibler Daten oder Infrastrukturen zugreifen.
• Langlebige und fest codierte Anmeldedaten. Viele nicht-menschliche Identitäten verwenden API-Schlüssel, die nie rotiert werden, in Code-Repositorys fest codierte Geheimnisse, in Konfigurationsdateien oder Skripten gespeicherte Anmeldedaten und gemeinsam genutzte Geheimnisse, die in verschiedenen Anwendungen wiederverwendet werden. Dies führt zu einer hohen Wahrscheinlichkeit von Datenlecks, die häufig auf Fehler von Entwicklern, Fehlkonfigurationen oder CI/CD-Protokolle zurückzuführen sind, die Geheimnisse offenlegen.
• Fehlende Verhaltensgrundlagen. Das Verhalten menschlicher Benutzer ist relativ vorhersehbar. Anmeldungen erfolgen während der Arbeitszeiten, Benutzerkonten rufen selten Tausende von APIs pro Minute auf, und Zugriffsmuster entsprechen in der Regel den beruflichen Aufgaben. NHIs sind schwieriger zu charakterisieren, da sie API-Dienste mit hoher Frequenz nutzen, automatisierte Aktivitätsspitzen aufweisen, unregelmäßige Muster aufgrund von Workflows oder Triggern zeigen und potenziell mit vielen Systemen interagieren. Dies macht die Erkennung von Anomalien komplexer und schwieriger zu optimieren.
• Begrenzte Telemetrie und Überwachung. Security-Tools wurden auf der Grundlage menschlicher Identitätsmuster entwickelt. SIEM-, Benutzer- und Entitätsverhaltensanalysen sowie PAM-Produkte analysieren häufig keine NHI-Authentifizierungsprotokolle und modellieren keine NHI-Risikobewertung, sodass ihnen möglicherweise die Transparenz hinsichtlich der Kommunikation zwischen den Diensten fehlt. Selbst in der Cloud, wo umfangreiche IAM-Protokolle vorhanden sind, können diese Dateien unübersichtlich und umfangreich sein und sich über verschiedene Dienste verteilen.
• Weitergabe von Anmeldedaten in Multi-Cloud- und SaaS-Integrationen. Da viele Unternehmen NHIs verwenden, um Cloud-Umgebungen, CI/CD-Tools, SaaS-Plattformen und herkömmliche lokale Infrastrukturen miteinander zu verbinden, werden Geheimnisse häufig über mehrere Systeme hinweg dupliziert oder wiederverwendet, was die Behebung und Rotation erschwert, wenn eine einzelne Identität kompromittiert wird.

Wie man nicht-menschliche Identitäten absichert

Zero Trust, eine von vielen Organisationen bevorzugte Schutzmethode, lässt sich nur schwer auf NHI-Szenarien anwenden. Zero Trust basiert auf Konzepten und Kontrollen wie kontinuierlicher Authentifizierung, expliziter Verifizierung und kontextgesteuertem Zugriff. Für nicht-menschliche Identitäten sind diese Kontrollen schwieriger zu implementieren, da NHIs in vielen Fällen keine Sitzung durchführen. Darüber hinaus ist die Gerätekonfiguration irrelevant, Kontextsignale wie Standort und Verhalten sind schwieriger zu definieren und zu modellieren, und neuere Kontrollen wie adaptive MFA sind in der Regel nicht anwendbar. Dadurch stehen Unternehmen weitaus weniger Mechanismen zur Zugriffskontrolle zur Verfügung.

Nicht-menschliche Identitäten stellen eine neue Klasse von sich schnell verändernden, hochwirksamen Identitätsrisiken dar, die mit den bestehenden Tools oder Denkmustern für menschliche Identitäten nicht einfach zu bewältigen sind.

Um die NHI-Sicherheit effektiv zu verwalten, müssen Unternehmen ihre Strategien ändern und ein Framework einsetzen, das den gesamten NHI-Lebenszyklus von der Erstellung über die Überwachung bis hin zur Stilllegung verwaltet.

Festlegung der NHI-Klassifizierung und Eigentumsverhältnisse

Erstellen Sie eine unternehmensweite NHI-Taxonomie mit Kategorien wie Dienstkonten, Workload-Identitäten, API-Schlüsseln sowie App- und Dienst-Tokens. Für jede Identität sollte ein eindeutiger Eigentümer verantwortlich sein, der für die Genehmigung von Berechtigungen, Rotationsrichtlinien, Nutzungsüberprüfungen und Löschungen oder Stilllegungen zuständig ist.

Implementieren Sie für NHIs das Prinzip der geringsten Privilegien (POLP). Übernehmen Sie Cloud-native Best Practices, wie zum Beispiel die Verwendung von Tokens mit minimalen Berechtigungen, die Vermeidung von Wildcard-Berechtigungen oder Administratorrollen, wo immer möglich, die Verwendung von Cloud-IAM-Rollen anstelle von statischen Anmeldedaten und die Anwendung von Mikrosegmentierung, um den Blast Radius wo immer möglich zu begrenzen. Wechseln Sie für Dienstkonten von domänenweiten Berechtigungen zu aufgabenspezifischen Berechtigungen.

Zentralisierung der Verwaltung von Geheimnissen und Anmeldedaten

Ersetzen Sie fest codierte oder statische Anmeldedaten durch Secret Manager wie AWS Secrets Manager, HashiCorp Vault oder Azure Key Vault, Credential Broker, Identitätsverbund mit kurzlebigen Tokens und automatisierte Rotations-Workflows. Speichern Sie Geheimnisse niemals an Orten wie Git-Repositorys, CI/CD-Protokollen, Terraform- oder Ansible-Playbooks oder Container-Images. Statische Anmeldedaten sollten nur als letztes Mittel verwendet werden.

Wenn möglich, sollten Sie eine kontinuierliche Überwachung und Verhaltensanalyse für NHIs einsetzen, die Service-zu-Service-Authentifizierungsmuster verstehen. Verfolgen Sie die Zugriffshäufigkeit von NHIs, API-Aufrufe und Fehlerspitzen und erstellen Sie Verhaltensbaselines für Workloads und Dienstkonten. Cloud-Plattformen stellen Protokolle bereit, wie beispielsweise AWS CloudTrail oder Microsoft-Entra-ID-Anmeldeprotokolle, aber Teams müssen diese im Kontext der Organisation aggregieren und interpretieren.

Automatisieren, wo immer es möglich ist

Manuelle Identitätsverwaltung ist nicht skalierbar. Nutzen Sie Automatisierung, um gängige Aktionen durchzuführen, wie beispielsweise die automatische Genehmigung von Berechtigungen mit geringsten Privilegien, die automatische Aufhebung ungenutzter NHIs, die automatische Rotation von Geheimnissen nach einem Zeitplan und die Stilllegung von Identitäten, wenn Workloads ausgemustert werden. CI/CD-Pipelines sollten kurzlebige Anmeldedaten generieren, die mit der Workload verschwinden.

Arbeiten Sie auf Zero Trust hin, indem Sie Folgendes umsetzen:

• Gegenseitiges TLS zwischen Diensten, Service Mesh oder Workload-Identitäts-Frameworks wie SPIFFE/SPIRE.
• Kontinuierliche Identitätsprüfung bei jedem API-Aufruf.
• Durchsetzung von Richtlinien basierend auf dem Identitätskontext.

Diese Kontrollen tragen dazu bei, dass die Kommunikation zwischen den Diensten authentifiziert, autorisiert und überprüfbar ist.

Testen Sie die NHI-bezogene Ausfallsicherheit und die Reaktion auf Vorfälle.

Führen Sie regelmäßig Übungen durch, wie beispielsweise simulierte Token-Diebstähle, API-Key-Replay-Tests und Workload-Kompromittierungsübungen. Überprüfen Sie während dieser Übungen die Sichtbarkeit der Protokollierung, bestimmen Sie den Blast-Radius, testen Sie die Widerrufs- und Rotationsgeschwindigkeit und überprüfen Sie, ob nachgelagerte Systeme Anomalien erkennen.

Der Status quo und die Zukunft nicht-menschlicher Identitäten

Da Unternehmen die Automatisierung, die Maschine-zu-Maschine-Kommunikation, die Cloud-Einführung und die KI-Integration vorantreiben, wird die NHI-Sicherheit zunehmend an Bedeutung gewinnen. Mit diesem Wachstum gehen eine Vielzahl von Anmeldedaten, unklare Eigentumsverhältnisse, überprivilegierte Dienstkonten, schwer zu überwachende Authentifizierungsabläufe und andere Risiken einher.

Sicherheitsteams müssen ihre Strategien zur Identitätsverwaltung weiterentwickeln, um dieser neuen Realität Rechnung zu tragen. Die Zukunft der Identitätssicherheit liegt in automatisiertem Lebenszyklusmanagement, der Durchsetzung des Prinzips der geringsten Privilegien, Verhaltensanalysen und einer starken Verwaltung von Anmeldedaten, die auf die Natur von NHIs und nicht auf Menschen zugeschnitten ist. Unternehmen, die diesen Wandel begrüßen, werden ihre Widerstandsfähigkeit stärken, ihre Angriffsfläche verringern und weitaus besser auf eine Welt vorbereitet sein, in der Arbeit zunehmend nicht mehr von Menschen, sondern von autonomen digitalen Akteuren erledigt wird.