Verwaltung des Lebenszyklus nicht-menschlicher Identitäten in modernen Umgebungen

Einführung: Warum der Lebenszyklus nicht-menschlicher Identitäten Aufmerksamkeit verdient

Nicht-menschliche Identitäten (NHIs) umfassen jede Anmeldeinformation oder Identitätskonstruktion, die es einem System, einer Anwendung oder einem automatisierten Prozess ermöglicht, sich zu authentifizieren und mit anderen Ressourcen zu interagieren, ohne dass ein menschliches Konto direkt beteiligt ist. NHIs umfassen Dienstkonten, die Anwendungen oder Diensten gewidmet sind, API-Schlüssel, die statische Tokens für den Zugriff auf externe Dienste sind, kurzlebige Tokens wie OAuth-Tokens oder JWT-Tokens sowie Automatisierungsanmeldeinformationen, die in CI/CD-Pipelines, Konfigurationsmanagement-Tools oder RPA-Workflows verwendet werden. In Organisationen mit vielfältiger Infrastruktur und komplexen Automatisierungsroutinen übersteigen NHIs die Anzahl der menschlichen Benutzer um das Zehnfache oder mehr. Selbst eine mittelgroße Organisation kann Hunderte von NHIs haben, und große Unternehmen können Tausende besitzen. Für weitere Informationen zu NHI-Typen und Sicherheitsherausforderungen lesen Sie unseren Artikel über non-human identity security.

Das Management des Lebenszyklus menschlicher Identitäten ist gut etabliert und ausgereift, wobei HR-gesteuerte Workflows es der IT ermöglichen, die Bereitstellung und Deaktivierung von neuen, wechselnden und ausscheidenden Mitarbeitern mit RBAC-Rollen und regelmäßigen Zugriffsüberprüfungen zu verwalten. Andererseits haben NHIs keine definierte Managementstruktur. Sie werden oft ad hoc von Entwicklern oder DevOps-Teams erstellt, erhalten aus Bequemlichkeit übermäßige oder weitreichende Berechtigungen, bleiben ohne dokumentierten Eigentümer und sind mit statischen Anmeldeinformationen konfiguriert, die selten geändert werden.

Ohne formelles NHI-Lifecycle-Management stehen Organisationen vor drei Herausforderungen:

• Identitätsausbreitung: Unkontrollierte Verbreitung von NHIs in der Infrastruktur, was die Governance extrem erschwert, da Sie nicht überprüfen und schützen können, was Sie nicht finden.
• Verwaiste Anmeldeinformationen: NHIs, die ihren legitimen Besitzer oder Zweck verloren haben, aber noch aktiv sind. Da kein Team sie aktiv nutzt, bleiben sie ein verstecktes Risiko, das Angreifer ausnutzen können.
• Sicherheitslücken: NHIs bleiben typischerweise außerhalb des Überwachungsbereichs von Sicherheitstools wie SIEM oder SOAR, die darauf ausgelegt sind, verdächtige Aktivitäten von menschlichen Konten zu erkennen. Identity Governance-Plattformen konzentrieren sich ebenfalls auf menschliche Konten und schließen NHIs in der Regel nicht ein, was eine erhebliche Angriffsfläche offenlässt.

Dieser Artikel konzentriert sich auf die fünf Phasen des NHI-Lebenszyklus, von der Entdeckung und Erstellung über die Überwachung, das Risikomanagement bis hin zur sicheren Außerbetriebnahme.

Definition nicht-menschlicher Identitäten in den heutigen IT-Ökosystemen

Nicht-menschliche Identitäten (NHIs) sind digitale Identitäten, die Maschinen, Anwendungen, Diensten, Containern, Skripten und automatisierten Prozessen zugewiesen werden, die autonom arbeiten. Ohne menschliche Interaktion authentifizieren sie sich, erhalten Berechtigungen, greifen auf Ressourcen zu und führen programmatisch Aktionen innerhalb von IT-Systemen aus. Zum Beispiel kann eine in AWS gehostete Anwendung eine IAM-Rolle verwenden, um auf Speicherdateien zuzugreifen, oder ein Microservice, der in Kubernetes läuft, kann ein Servicekonto verwenden, um mit anderen Diensten zu kommunizieren.

NHIs authentifizieren sich mit maschinenfreundlichen Mechanismen wie API-Schlüsseln, geteilten Geheimnissen, Zertifikaten, JWT- oder OAuth-Tokens und Workload-Identitäten. Im Gegensatz zu menschlichen Konten melden sie sich nicht interaktiv an, verwenden keine Passwörter im herkömmlichen Sinne und verlassen sich oft auf gespeicherte Anmeldeinformationen. Da sie automatisch ausgeführt werden, können NHIs Hunderte oder Tausende von Aktionen mit sehr hoher Geschwindigkeit ausführen und müssen mit denselben Sicherheitskontrollen und Standards wie menschliche Identitäten verwaltet werden.

NHIs sind in der heutigen komplexen IT-Infrastruktur unverzichtbar. Moderne Organisationen müssen cloud-native Bereitstellungsarchitekturen übernehmen, und Microservices sowie DevOps-Praktiken erfordern als Grundlage die Kommunikation von Maschine zu Maschine.

• API-Interaktion: Moderne Anwendungen sind stark von APIs abhängig. Anwendungen kommunizieren mit Datenbanken, Zahlungs-Gateways, Speicherdiensten, Überwachungstools und Drittanbieter-SaaS-Plattformen über APIs. Jede dieser Interaktionen wird von einem NHI unterstützt und erfordert eine Authentifizierung.
• DevOps- und CI/CD-Pipelines: Continuous Integration- und Continuous Deployment-Pipelines automatisieren Software-Builds, Tests und Deployments. Diese Pipelines verwenden NHI-Agenten zur Authentifizierung bei Quellcode-Repositories, Artefakt-Registries, Container-Plattformen, Cloud-Umgebungen für Deployments und Benachrichtigungstools. Jede Interaktion erfordert eine Authentifizierung mit einem eigenen NHI, und diese Identitäten haben oft erweiterte Berechtigungen.
• Cloud-Arbeitslasten: Cloud-native Umgebungen erstellen und löschen dynamisch Arbeitslasten wie virtuelle Maschinen, Container, serverlose Funktionen und Kubernetes-Pods. Diese Arbeitslasten erhalten NHIs zugewiesen, um auf Speicher zuzugreifen, Datenbanken abzufragen und Messaging-Dienste zu nutzen. All diese erstellten, geänderten und außer Dienst gestellten NHIs erfordern ein Lebenszyklusmanagement mit angemessener Sichtbarkeit.
• Geplante Aufgaben und Automatisierung: Über Cloud und DevOps hinaus sind traditionelle IT-Umgebungen auch auf NHIs für Batch-Verarbeitungsaufträge, geplante Skripte, Daten-Synchronisationsaufgaben, Backup-Dienste und Überwachungsagenten angewiesen. Diese Automatisierungsaufgaben laufen unter Dienstkonten mit erhöhten Rechten und werden oft nicht rotiert, überwacht oder richtig eingeschränkt.

Gängige Arten von nicht-menschlichen Identitäten, die Organisationen verwalten

Dienstkonten und Anwendungsidentitäten: Diese Identitäten sind dedizierte, nicht-interaktive Konten, die speziell für Anwendungen, Dienste und Prozesse erstellt wurden, um sich zu authentifizieren und sicher auf Ressourcen zuzugreifen. Zum Beispiel stellt eine Gehaltsabrechnungsanwendung, die sich mit einer SQL-Datenbank verbindet, um Mitarbeiterdaten über ein Dienstkonto abzurufen, die Kontinuität unabhängig von Personalwechseln sicher. Dabei handelt es sich typischerweise um feste Anmeldeinformationen oder Schlüssel, die selten geändert werden, im Laufe der Zeit oft übermäßige Berechtigungen ansammeln und häufig über mehrere Anwendungen und Umgebungen hinweg gemeinsam genutzt werden.

API-Schlüssel, Tokens und Zertifikate: Diese Identitäten werden für die Maschine-zu-Maschine-Kommunikation verwendet. Anstatt sich mit Benutzernamen und Passwörtern anzumelden, verwenden Anwendungen und Dienste diese Identitäten, um sich sicher zu identifizieren. API-Schlüssel sind oft statische geheime Zeichenfolgen, die von einem Dienst (wie AWS, Entra ID oder Stripe) ausgegeben werden, um eine aufrufende Anwendung zu identifizieren und zu autorisieren. OAuth- oder JSON-Web-Tokens (JWT) sind kurzlebige Tokens, die nach einem Authentifizierungsereignis ausgegeben werden und dem Inhaber ohne weitere Überprüfung Zugang gewähren. PKI-basierte Zertifikate werden für gegenseitige TLS-Authentifizierung, Code-Signierung und Service-Mesh-Kommunikation verwendet. Obwohl diese Zertifikate ein Ablaufdatum haben, sind nicht verwaltete Zertifikate eine der Hauptursachen für Dienstunterbrechungen.

Cloud-Arbeitslasten und Container-Identitäten: NHIs werden dynamisch virtuellen Maschinen, Containern, serverlosen Funktionen und Kubernetes-Pods zugewiesen. Diese Arbeitslasten interagieren miteinander und außerhalb der Cloud mit anderen Cloud-Plattformen oder On-Premises-Infrastrukturen. Während verwaltete Identitäten den Bedarf an fest codierten Geheimnissen reduzieren, sind falsch konfigurierte Berechtigungen, die mit IAM-Rollen verbunden sind, die diese Arbeitslasten verwenden, Hauptziele für Angreifer.

DevOps-, CI/CD- und Automatisierungsidentitäten: DevOps-Umgebungen verlassen sich stark auf Automatisierungsidentitäten. CI/CD-Pipeline-Tools wie Jenkins, GitHub Actions, GitLab CI und CircleCI benötigen Anmeldeinformationen, um Code auszuchecken, Artefakte zu übertragen, in Cloud-Umgebungen bereitzustellen und die Infrastruktur zu aktualisieren. Infrastructure-as-Code-Tools wie Terraform und Ansible benötigen Cloud-Anbieter-Anmeldeinformationen mit umfassenden Berechtigungen. Wenn sie kompromittiert werden, können diese Automatisierungsidentitäten Angreifern sofortige Kontrolle über Produktionsumgebungen verschaffen.

KI-Agenten und autonome Systemidentitäten: Da Organisationen KI-gesteuerte Automatisierung schneller übernehmen, entsteht eine neue Klasse von NHI. Diese KI-Agenten und autonomen Systemidentitäten repräsentieren KI-Co-Piloten, die mit Unternehmenssystemen interagieren, intelligente Bots, die operative Aufgaben ausführen, Machine-Learning-Modelle, die auf Datenpipelines zugreifen, und Robotic Process Automation (RPA)-Bots, die Formulare ausfüllen und Daten transformieren. Organisationen müssen bei der Einführung dieser KI-Agenten vorsichtig sein und ein Identitätslebenszyklus-Managementsystem definieren, das den Zugriff kontrolliert und überwacht und eine Prüfspur bereitstellt.

Menschliche vs. nicht-menschliche Identitäten: ein Lebenszyklusvergleich

Sowohl menschliche als auch nicht-menschliche Identitäten benötigen Governance; ihre Lebenszyklen unterscheiden sich jedoch grundlegend in Struktur, Eigentum, Risikoprofil und operativem Verhalten. Traditionelle IAM-Prozesse wurden hauptsächlich für menschliche Benutzer entwickelt, und wenn sie unverändert auf NHIs angewendet werden, bieten sie oft keine ausreichende Kontrolle.

Traditionelle IAM-Workflows sind auf den menschlichen Beschäftigungszyklus ausgelegt. Sie gehen von einer klaren Kontobesitzerschaft aus und davon, dass der HR-Status Ereignisse auslöst. NHIs folgen diesen Mustern nicht und erfordern ein speziell entwickeltes Lifecycle-Management, da sie keine HR-Akte, keinen Manager, keine interaktiven Anmeldeereignisse und keinen natürlichen Offboarding-Zeitrahmen haben.

Was der Lebenszyklus einer nicht-menschlichen Identität tatsächlich umfasst

NHIs erfordern ein strukturiertes Lifecycle-Management wie menschliche Benutzer, aber das Management muss sich an Szenarien wie Automatisierung, Maschine-zu-Maschine-Kommunikation und Hochgeschwindigkeits-Skalierbarkeit anpassen. Im Folgenden sind die fünf kritischen Phasen des NHI-Lebenszyklus aufgeführt:

Die Verwaltung von NHIs mit einem Lebenszyklusansatz stellt sicher, dass keine Sicherheitslücken vorhanden sind. Jede Phase fungiert als Sicherheitskontrolle: keine Entdeckung führt zu Schattenidentitäten, schwache Bereitstellung führt zu Privilegienausweitung, keine Überwachung bedeutet, dass Kompromittierungen unentdeckt bleiben, keine Anmeldeinformationsrotation bedeutet, dass ein geleakter Schlüssel dauerhaften Zugriff gewährt, und keine Stilllegung hinterlässt verwaiste Anmeldeinformationen, die unentdeckte dauerhafte Hintertüren schaffen.

Phase 1: Erkennung und Inventarisierung von nicht-menschlichen Identitäten

Discovery ist der entscheidende erste Schritt bei der Verwaltung von nicht-menschlichen Identitäten, denn die erste Regel der Sicherheit lautet: „Sie können nicht schützen, was Sie nicht sehen können.“ Bevor Governance, Richtlinien oder Sicherheitskontrollen angewendet werden können, müssen Organisationen ein umfassendes, genaues und kontinuierlich aktualisiertes Inventar jeder NHI in ihrer Umgebung erstellen.

Was Entdeckung erfordert

Kontinuierliches Scannen: NHIs sind nicht statisch. Entwickler stellen Servicekonten bei Bedarf bereit, CI/CD-Pipelines erzeugen kurzlebige Tokens, und cloud-native Workloads erstellen dynamisch neue Identitäten. Ein Audit zu einem bestimmten Zeitpunkt erfasst einen Schnappschuss, der fast sofort veraltet ist. Effektive Erkennung erfordert kontinuierliches, automatisiertes Scannen, das nach Zeitplan oder ereignisbasiert läuft und neu erstellte Identitäten erkennt, sobald sie erscheinen.

Umfassende Abdeckung über verschiedene Umgebungen: Moderne Organisationen arbeiten in hybriden und Multi-Cloud-Umgebungen. Discovery muss kontinuierlich lokale Verzeichnisse wie Active Directory, Cloud-IAM-Systeme in AWS, Azure und GCP, SaaS-Plattformen, Container-Orchestrierungssysteme und Secrets Vaults scannen. Wenn Discovery nur auf ein oder zwei Umgebungen beschränkt ist, bleibt ein großer Teil der NHI-Angriffsfläche unsichtbar.

Attributzuordnung: Discovery geht nicht nur darum, Identitäten aufzulisten; es muss auch den vollständigen Kontext jeder Identität erfassen, um Sicherheits- und Governance-Kontrollen anzuwenden. Dazu gehört die Zuordnung wichtiger Attribute für jede NHI, wie z. B. welches Team oder welche Einzelperson die Identität besitzt, welche Geschäfts­funktion sie erfüllt, welche Systeme oder Dienste davon abhängen und wann die Zugangsdaten zuletzt geändert wurden.

Häufige Herausforderungen bei der Entdeckung

1. Im Gegensatz zu menschlichen Identitäten, die in einem HR-System oder primären Identity Provider zentralisiert sind, befinden sich NHIs selten an einem einzigen Ort. Sie existieren in IAM-Konsolen in Cloud-Plattformen, lokalen Servicekonto-Konfigurationen auf Servern, in Tresoren gespeicherten Geheimnissen und in Konfigurationsdateien oder Code-Repositories eingebetteten API-Schlüsseln. Diese Identitätsspreizung erschwert es, ohne spezialisierte NHI-Verwaltungstools ein genaues Inventar zu erhalten.
2. Im Gegensatz zu menschlichen Identitäten, die aus HR-Systemen in ein zentrales Verzeichnis synchronisiert werden, haben NHIs typischerweise kein autoritatives Ursprungssystem. Mehrere Identitäten können dieselbe Funktion erfüllen, verwaiste Identitäten bleiben nach der Stilllegung von Anwendungen aktiv, und doppelte Anmeldeinformationen existieren in verschiedenen Umgebungen. Sicherheitsteams müssen Daten aus mehreren Quellen aggregieren und korrelieren, um eine einheitliche Inventarplattform zu erstellen.
3. Eine der herausforderndsten Situationen bei der NHI-Erkennung sind Schattenidentitäten. Entwickler und DevOps-Ingenieure erstellen häufig Identitäten für schnelle Lösungen, Tests und zügige Bereitstellungen außerhalb formaler Bereitstellungsprozesse. Diese Identitäten fehlen ordnungsgemäße Dokumentation und Umfang, was sie zu einem hohen Risiko macht und schwer zu entdecken ist.

Phase 2: Sichere Bereitstellung und Zugriffszuteilung

Die erste Verteidigungslinie ist die Bereitstellungsphase. Wie NHIs erstellt werden, bestimmt ihr Risikoprofil während ihres gesamten Lebenszyklus. Wenn eine Identity übermäßige Berechtigungen hat, die nicht dokumentiert sind und keine klare Eigentümerschaft besteht, wird dies zu einem Risiko, das jahrelang unentdeckt bestehen kann.

Best Practices für die Bereitstellung

Standardisieren Sie Erstellungs-Workflows: Jedes NHI muss durch einen vordefinierten, wiederholbaren Prozess erstellt werden, und der Zugriff muss mit rollenbasierten Zugriffskontroll- oder attributbasierten Zugriffskontrollmodellen übereinstimmen. Das bedeutet, dass genehmigte Vorlagen für gängige Identitätstypen wie Servicekonten, API-Schlüssel und CI/CD-Pipeline-Token erstellt werden müssen, um sicherzustellen, dass kein NHI außerhalb einer Governance-Richtlinie in die Umgebung gelangt.

Setzen Sie das Prinzip der minimalen Rechte von Anfang an durch: Eines der größten Risiken bei der NHI-Bereitstellung besteht darin, während der Entwicklungsphase weitreichenden Zugriff zu gewähren, der in der Produktion dauerhaft wird. Least privilege muss zum Zeitpunkt der Identitätserstellung angewendet werden: Definieren Sie genaue Systeme und API-Anforderungen, prüfen Sie sorgfältig, welche Berechtigungen vergeben werden sollen, vermeiden Sie Wildcard-Berechtigungen in Cloud-IAM-Richtlinien und beginnen Sie mit minimalem Zugriff.

Eigentümerschaft zuweisen: Jeder NHI muss mit einer Einzelperson, Rolle oder einem Team verknüpft sein, um eine klare Eigentümerschaft festzulegen. Die Eigentümerschaft muss regelmäßig in der Change Management Database (CMDB) und in IAM-Plattformen aktualisiert werden, sodass jede erforderliche Änderung mit dem Eigentümer abgestimmt und von ihm genehmigt werden muss. Wenn der Eigentümer die Organisation verlässt, muss die Eigentümerschaft sofort neu zugewiesen werden.

Ablaufdaten festlegen: Viele NHIs werden für temporäre Projekte, Migrationen, Testumgebungen, Anbieterintegrationen und kurzfristige Automatisierungsaufgaben erstellt, werden aber selten nach Ablauf des Bedarfs deaktiviert. Weisen Sie jedem NHI eine Lebensdauer (TTL) zu. Nach Ablauf muss der Eigentümer den Bedarf überprüfen, und wenn er nicht genehmigt wird, muss das NHI automatisch aus dem System entfernt werden.

Bereitstellungsfallen, die vermieden werden sollten

• Übermäßige Berechtigungen: Unter Lieferdruck gewähren Teams oft übermäßige Berechtigungen, „nur damit es funktioniert“. Übermäßige Berechtigungen werden selten reduziert, sobald alles funktioniert, und schaffen versteckte Pfade zur Privilegieneskalation, die Chancen für laterale Bewegungen oder schwerwiegende Compliance-Verstöße bieten können.
• Kopieren von Berechtigungen aus bestehenden NHIs: Beim Erstellen einer neuen Identität ist es einfacher, Berechtigungen von bestehenden zu kopieren, vorausgesetzt, dies ist der genehmigte Weg. Dies führt jedoch zu Problemen wie der Vererbung veralteter oder übermäßiger Berechtigungen, die nie formell genehmigt wurden.
• Erstellung von NHIs ohne Dokumentation und Verantwortlichkeit: Wenn NHIs ohne Dokumentation erstellt werden und das Inventar nicht aktualisiert wird, können Sicherheitsteams diese nicht in ihren Umfang einbeziehen, Risikobewertungen veralten und es gibt keinen Plan für Vorfallreaktion oder Außerbetriebnahme.

Phase 3: fortlaufende Überwachung und Verhaltenskontrolle

Sobald ein NHI bereitgestellt ist, endet die Sicherheitsarbeit nicht. Sie verlagert sich auf die kontinuierliche Überwachung, nicht nur auf statische Zugriffsüberprüfungen in regelmäßigen Abständen, sondern auf die Überwachung, wie Berechtigungen verwendet werden und wie sich Rollen und Berechtigungen im Laufe der Zeit entwickeln. Die kontinuierliche Überwachung stellt sicher, dass das, was ein NHI tut, mit dem übereinstimmt, was es tun sollte, und wenn Abweichungen festgestellt werden, können Untersuchung und Behebung verhindern, dass die Abweichung zu einem Vorfall wird.

Was überwacht werden soll

Nutzungsmuster: Das Verstehen und Überwachen, wie häufig und in welchem Kontext ein NHI arbeitet, bildet die Grundlage für das Verständnis der damit verbundenen Risiken. Ist ein NHI täglich aktiv oder nur an den letzten Tagen der Woche oder des Monats? Wenn es 100 Anfragen pro Stunde verarbeitet, was ist die Ursache für einen plötzlichen Anstieg auf 10.000 Anfragen? Ein Anstieg der Nutzungshäufigkeit oder des Anrufvolumens außerhalb des üblichen Betriebsfensters kann auf Kompromittierung oder Missbrauch hinweisen. Wenn ein NHI über einen längeren Zeitraum nicht aktiv ist, könnte dies auf einen außer Betrieb genommenen Dienst hinweisen, dessen Zugangsdaten nie widerrufen wurden.

Zugriffsbereich: Die Überwachung dessen, worauf ein NHI zugreift, wie Ressourcen, APIs, Datenspeicher oder Dienste, ist entscheidend für die Sichtbarkeit und dafür, dass das tatsächliche Laufzeitverhalten dem beabsichtigten Zugriffsdesign entspricht. Selbst wenn ein NHI normal arbeitet, stellt übermäßiger Zugriff ein potenzielles Risiko dar. Die Sichtbarkeit des Zugriffsbereichs muss regelmäßige Zugriffsüberprüfungen, Rollenzuweisungen und Risikobewertungen basierend auf der Kritikalität des Zugriffs umfassen.

Ungewöhnliche Änderungen: Jegliche Zugriffsänderungen, insbesondere unerwartete oder unautorisierte, sollten für Sicherheitsteams ein Warnsignal sein. Dazu gehören neue Rollenvergaben, Richtlinienanhänge, Änderungen der Gruppenmitgliedschaft oder geheime Zugriffsrechte, die nicht Teil eines Änderungsmanagementprozesses waren. Da NHIs keine Anfragen selbst initiieren können, sollte eine unerwartete Zugriffsänderung als mögliche böswillige Aktivität, Insider-Missbrauch oder Fehlkonfiguration der Automatisierung betrachtet und umgehend untersucht werden.

Berechtigungsdrift: Im Laufe der Zeit neigen NHIs dazu, Berechtigungen für verschiedene Aufgaben oder temporäre Projekte anzusammeln und erhalten mehr Zugriff als ursprünglich vorgesehen. Häufige Ursachen sind Projekterweiterungen, temporärer Zugriff, der zur Fehlerbehebung hinzugefügt und nie entfernt wurde, sowie Änderungen der Rollenvererbung aufgrund komplexer Gruppenschachtelungen. Die Berechtigungsdrift muss streng überwacht werden, indem die aktuellen Berechtigungen mit den Basis-Berechtigungsvorlagen verglichen werden.

Protokollierung und Compliance

NHI-Aktivitätsprotokolle sind nicht optional; sie sind genauso wichtig wie menschliche Aktivitätsprotokolle für Compliance-Anforderungen, Audit-Bereitschaft und Vorfallreaktion. Rahmenwerke wie PCI DSS, HIPAA, SOC 2 und GDPR verlangen Nachvollziehbarkeit, Verantwortlichkeit und Prüfpfade des Systemzugriffs, egal ob es sich um ein menschliches Konto oder eine nicht-menschliche Identität handelt.

• Rückverfolgbarkeit: Jede automatisierte Aktion muss einer bestimmten Identität zugeordnet werden können, damit die Eigentümerschaft festgestellt werden kann.
• Auditnachweise: Organisationen müssen nachweisen können, wer auf sensible Systeme zugegriffen hat, wann der Zugriff erfolgte, welche Aktionen durchgeführt wurden und ob der Zugriff autorisiert war.
• Vorfalluntersuchung: Während forensischer Untersuchungen von Sicherheitsverletzungen helfen Identitätsprotokolle dabei festzustellen, ob Anmeldeinformationen kompromittiert wurden, laterale Bewegungen nachzuverfolgen, den Umfang der Datenexfiltration zu bestimmen und eine klare Zeitleiste zu erstellen, um Angriffsereignisse zu rekonstruieren.

Stufe 4: Verwaltung von Anmeldeinformationen-Risiken

Langfristige Geheimnisse sind einer der gefährlichsten Aspekte der Sicherheit von nicht-menschlichen Identitäten und stellen ein systemisches Risiko dar. Im Gegensatz zu menschlichen Anmeldeinformationen, bei denen Passwortänderungen durch Richtlinien durchgesetzt werden und MFA eine zusätzliche Sicherheitsebene bietet, bleiben NHI-Anmeldeinformationen oft monatelang oder sogar jahrelang statisch. Wenn diese Anmeldeinformationen geleakt werden, bleiben sie aktiv ausnutzbar, bis die Berechtigungen ausdrücklich widerrufen oder die Identität gelöscht wird.

Warum Rotation wichtig ist

Unentdeckte Offenlegung: Anmeldedaten können durch Protokolle, Entwicklerumgebungen oder ausgeklügelte Techniken geleakt werden, ohne einen Alarm auszulösen. Wenn ein Geheimnis versehentlich in Git eingecheckt, über einen falsch konfigurierten Cloud-Speicher-Bucket offengelegt oder aus dem Speicher oder Protokollen extrahiert wird, erhalten Angreifer dauerhaften Zugriff, und Organisationen haben keine Ahnung, dass bereits eine Kompromittierung stattgefunden hat.

Rotation begrenzt den Schadensradius: Rotation wirkt als zeitliche Begrenzung für mögliche Kompromittierungen. Durch häufiges Ändern von Zugangsdaten werden Angreifer mit stillem Zugriff automatisch ausgesperrt. Zum Beispiel wird ein Schlüssel, der alle 24 Stunden rotiert wird, am nächsten Tag nutzlos, wenn er gestohlen wurde. Ein kurzlebiges Token, das 15 Minuten gültig ist, begrenzt die Exposition auf nur 15 Minuten. Das Prinzip ist einfach: Je länger ein Geheimnis existiert, desto größer ist die Wahrscheinlichkeit, dass es durch einen unentdeckten Angriffsvektor offengelegt wurde.

Compliance und Governance: Moderne Sicherheits- und Compliance-Rahmenwerke verlangen ausdrücklich Kontrollen für das Credential-Management und betrachten die Rotation von Zugangsdaten nicht mehr als optional, sondern als obligatorische Kontrolle. Prüfer benötigen Nachweise darüber, wie oft Servicekonto-Zugangsdaten rotiert werden, ob die Rotation automatisiert ist und was passiert, wenn ein Geheimnis offengelegt wird.

Best Practices für Rotation

Definieren Sie Rotationsrichtlinien: Die manuelle Rotation von Zugangsdaten ist von Natur aus nicht zuverlässig, da Teams sie vergessen oder keine klare Zuständigkeit haben können. Eine formelle Rotationsrichtlinie sollte festlegen, welche Zugangsdaten rotiert werden müssen, die maximale Lebensdauer pro Zugangsdatenart, wer die Rotation besitzt und dafür verantwortlich ist und welche Werkzeuge verwendet werden sollen. Richtliniengesteuerte Rotation sorgt für Konsistenz in unterschiedlichen Umgebungen und schafft eine klare Prüfspur.

Legen Sie Rotationspläne fest: Nicht alle Zugangsdaten bergen das gleiche Risiko, und die Rotationshäufigkeit sollte entsprechend festgelegt werden. Hochprivilegierte Dienstkonten sollten täglich oder wöchentlich rotiert werden, Cloud-API-Schlüssel mit weitreichenden Berechtigungen sollten wöchentlich oder monatlich rotiert werden, und Benutzerzugangstoken sollten nur kurz gültig sein (für Minuten, nicht Tage). Das Ziel ist es, die Rotation zu einem Hintergrundprozess statt zu einer periodischen Notfallmaßnahme zu machen.

Reagieren Sie sofort auf Sicherheitsvorfälle:Die Rotation sollte nicht nur zeitbasiert sein; sie muss auch ereignisgesteuert auf kontinuierlicher Überwachung basieren. Organisationen müssen einen definierten Prozess für die Reaktion auf Vorfälle mit Anmeldeinformationen haben, der sofort ausgelöst wird, wenn ein Kompromittierungsverdacht besteht oder bestätigt wird. Wenn eine Sicherheitslücke erkannt wird, sollte ein automatisierter Prozess die kompromittierten Anmeldeinformationen widerrufen, ein neues Geheimnis generieren, alle abhängigen Dienste aktualisieren sowie Protokolle erstellen und die Beteiligten benachrichtigen.

Phase 5: Außerbetriebnahme und Offboarding von nicht-menschlichen Identitäten

Außerbetriebnahme ist oft die am meisten vernachlässigte Phase im Lebenszyklus der non-human identity. Während sich Organisationen auf die Bereitstellung und Überwachung konzentrieren, erfolgt die Stilllegung von NHI meist im Rahmen informeller Kampagnen oder gar nicht. Infolgedessen verbleiben viele verwaiste NHIs im System als Geisterkonten, die eine versteckte Angriffsfläche schaffen.

Identifizierung von NHIs zur Stilllegung

Eine effektive Stilllegung beginnt mit Transparenz. Organisationen müssen proaktiv NHIs erkennen, die nicht mehr existieren sollten.

Unbenutzte Identitäten: Viele NHIs werden für kurzfristige Projekte, temporäre Integrationen, Testumgebungen oder Migrationsinitiativen erstellt. Sobald diese Projekte beendet sind, verbleiben diese NHIs mit gültigen Anmeldeinformationen im System. Es sollte eine Richtlinie geben, die bewertet, wann ein NHI nicht mehr verwendet wird, z. B. keine Authentifizierungsereignisse innerhalb definierter Zeiträume (30, 60 oder 90 Tage).

Verwaiste Identitäten: NHIs werden verwaist, wenn ihre Besitzer oder verantwortlichen Teams die Organisation verlassen, anderen Projekten zugewiesen werden oder wenn Anwendungen, für die das NHI erstellt wurde, eingestellt werden, ohne dass das NHI bereinigt wird. Ohne Eigentümer gibt es niemanden, der Zugriffsrechte überprüft, Anmeldeinformationen ändert oder ungewöhnliche Aktivitäten überwacht. Verwaiste Identitäten sind besonders gefährlich, da sie innerhalb der Systeme legitim erscheinen, aber keine Aufsicht haben.

Doppelte Identitäten: In dezentralen DevOps-Umgebungen können mehrere Teams separate Identitäten für identische Aufgaben erstellen, was zu redundanten Servicekonten, sich überschneidenden API-Schlüsseln oder mehreren Anmeldeinformationen mit ähnlichen Zugriffsrechten führt. Doppelte Identitäten erhöhen die Komplexität und das Risiko, da Prüfpfade schwerer zu pflegen sind und das Widerrufen des Zugriffs einer Identität das Zugriffsrisiko nicht beseitigt.

Sicherer Außerbetriebnahmeprozess

Das Entfernen eines NHI ohne sorgfältige Validierung ist an sich ein Risiko. Es kann Anwendungen oder abhängige Dienste in der Produktion beeinträchtigen. Der Außerbetriebnahmeprozess sollte systematisch durchgeführt werden.

1. Identifizieren und profilieren: Verwenden Sie automatisierte Erkennungstools, um Identitäten basierend auf Inaktivität oder fehlendem gültigem Eigentümer zu kennzeichnen, unabhängig davon, ob die zugehörige Anwendung oder der Dienst eingestellt wurde oder ob die NHI als doppelte Identität bestätigt wurde. Identifizierte NHIs sollten zur Überprüfung an Anwendungsbesitzer, Sicherheits- und DevOps-Teams gesendet werden.
2. Abhängigkeitsprüfung: Bevor Sie ein NHI deaktivieren oder löschen, vergewissern Sie sich, dass es keine Hintergrundaufgaben, geplanten Automatisierungsaufgaben, Integrationen von Drittanbietern, Notfallwiederherstellungsprozesse oder Altsysteme aktiv unterstützt. Die Überprüfung der Abhängigkeiten erfordert das Durchsehen von Authentifizierungsprotokollen, das Prüfen von CI/CD-Konfigurationen, das Scannen von Infrastructure-as-Code-Vorlagen und die Rücksprache mit den Anwendungsbesitzern.
3. Vor dem Löschen deaktivieren: Niemals sofort löschen. Die beste Vorgehensweise ist eine schrittweise Entfernung: Zuerst die Authentifizierungsfunktion deaktivieren, auf Fehler oder Systemprobleme überwachen, eine definierte Schonfrist (7 bis 30 Tage) einräumen und dauerhaft löschen, wenn keine Auswirkungen auftreten. Dies ermöglicht es den Teams, mögliche Auswirkungen zu überprüfen und eine schnelle Rücknahme zu ermöglichen.
4. Dokumentation der Entfernung für Prüfzwecke: Sobald alle Phasen der Außerbetriebnahme abgeschlossen sind, führen Sie eine endgültige Löschung durch und stellen Sie sicher, dass diese Aktion in den Protokollen der SIEM-Plattform für die Prüfspur protokolliert wird. Dokumentieren Sie die notwendigen Informationen, einschließlich des Namens der Identity mit ihrer eindeutigen Kennung, der zugehörigen Systeme und Berechtigungen, des Entfernungsgrundes, der Details zum Überprüfungs- und Genehmigungsworkflow sowie des Löschdatums.

Häufige Fallstricke im NHI-Lebenszyklusmanagement

Wie Netwrix das NHI-Lifecycle-Management unterstützt

Netwrix Identity Manager bietet ein umfassendes Framework für Identity Governance und Administration (IGA), das menschliche Konten und nicht-menschliche Identitäten in einer Plattform mit automatisierten Lebenszyklusprozessen verwaltet. Netwrix Identity Manager erstellt ein zentrales Identitätsverzeichnis, das alle Identitätstypen umfasst, um ein einheitliches Inventar zu schaffen, das als Grundlage für das Identity Lifecycle Management dient.

Erkennung und Inventarisierung: Alle Identitätstypen, einschließlich NHIs, werden in ein zentrales Identity Manager-Repository synchronisiert, das Transparenz bietet und die Identitätsverstreuung reduziert. Connectoren ziehen Identitäts- und Berechtigungsdaten aus verschiedenen Verzeichnissen (Active Directory, Microsoft Entra ID) und Geschäftsanwendungen und bringen NHIs neben menschlichen Identitäten in den Governance-Bereich.

Kontrollierte Bereitstellung: Für jede Identität wird ein standardisierter Bereitstellungsworkflow definiert, der ad-hoc-Bereitstellungen mit übermäßigen Berechtigungen reduziert. Richtlinienbasierte Workflows werden ausgelöst, wenn eine Identität erstellt wird, und erzwingen das Prinzip der geringsten Rechte, um nur den Zugriff bereitzustellen, der für die Identitätsrolle erforderlich ist. Die rollenbasierte Zugriffskontrolle stellt sicher, dass Identitäten nur die für ihre Funktion geeigneten Berechtigungen erhalten.

Fortlaufende Überwachung und Überprüfung: Netwrix Identity Manager verfolgt Berechtigungen, Änderungsereignisse und den Compliance-Status für alle Identitäten, die er verwaltet. Es bietet integrierte Funktionen für Zugangszertifizierungskampagnen mit Risikoanalysen, um zu erkennen, wann NHIs übermäßige Berechtigungen ansammeln, und überwacht Zugriffsverhalten sowie Ressourcennutzung. Es hilft dabei, inaktive oder verwaiste Identitäten, Privilegienausweitung und Verstöße gegen die Trennung der Aufgaben sowohl bei menschlichen als auch nicht-menschlichen Identitäten zu erkennen.

Zugriffsbehebung und Bereinigung: Netwrix Identity Manager ermöglicht es Organisationen, die Berechtigungen jeder Identität anhand von Richtlinienregeln zu analysieren. NHIs, die keinen Zugriff mehr benötigen oder Berechtigungen haben, die über das Richtlinienmaß hinausgehen, können zur Behebung markiert werden. Regeln können definiert werden, um ungenutzte Konten zu identifizieren, die sich für einen festgelegten Zeitraum (z. B. 90 Tage) nicht angemeldet haben, verwaiste NHIs, deren Besitzer nicht vorhanden ist, oder übermäßige Berechtigungen, die während der Zugriffszertifizierung aufgedeckt wurden.

Lebenszyklusabschluss: Netwrix Identity Manager automatisiert die Phasen der Bereitstellung, Aktualisierung und Stilllegung mit umfassenden Workflows, die Joiner-Mover-Leaver (JML)-Prozesse berücksichtigen. Wenn eine Anwendung oder ein Dienst eingestellt wird, ein Projekt endet oder ein menschlicher Eigentümer das Unternehmen verlässt oder zum nächsten Projekt wechselt, stellt Netwrix Identity Manager sicher, dass die zugehörigen NHIs die Berechtigungen entzogen bekommen und schließlich gelöscht werden.

Fazit: Von der Identitätsvermehrung zur Lebenszykluskontrolle

In der modernen IT-Infrastruktur sind nicht-menschliche Identitäten zum dominierenden Identitätstyp geworden und werden nicht verschwinden. Sie vermehren sich exponentiell. Jeder neue Automatisierungsmechanismus, jede Cloud-Arbeitslast und jeder KI-Agent trägt zum ständig wachsenden NHI-Fußabdruck bei. Der Wandel vom monolithischen Anwendungsdesign zu Microservices bedeutet mehrere Identitäten für jeden Unterdienst, der mit anderen Diensten kommuniziert. Cloud-Arbeitslasten wie virtuelle Maschinen, serverlose Funktionen, Container und verwaltete Dienste benötigen alle mehr NHIs. DevOps-Pipelines verlassen sich stark auf Serviceprinzipale, Bereitstellungstoken, Git-Integrationen, API-Anmeldeinformationen und Build-Agenten. NHIs übersteigen jetzt die Anzahl menschlicher Identitäten im Verhältnis 10 zu 1, und dieses Verhältnis steigt weiter an.

Das NHI-Lifecycle-Management verwandelt NHIs von einem wachsenden Risiko in eine verwaltete Vermögensklasse und ermöglicht es Organisationen, NHIs mit effektiveren Kontrollen zu verwalten, die für den Umfang und die Auswirkungen erforderlich sind, die sie haben. Durch die Behandlung jeder Phase (Erkennung, Bereitstellung, Überwachung, Rotation und Stilllegung) können Organisationen die Identitätsverbreitung reduzieren, das Prinzip der geringsten Privilegien durchsetzen und die Sicherheitslücken schließen, die traditionelle IAM für NHIs nicht adressieren kann.