Nicht-menschliche Identitäten (NHI) erklärt und wie man sie sichert

Die meisten Organisationen können kein vollständiges Inventar der nicht-menschlichen Identitäten (NHI) erstellen, die in ihrer Umgebung betrieben werden. Dienstkonten, API-Schlüssel und Anwendungsanmeldeinformationen sammeln sich in Active Directory (AD) und Cloud-Plattformen an, oft ohne klare Eigentümerschaft, dokumentierten Zweck oder definierten Überprüfungszyklus.

Diese Lücke birgt ein echtes Risiko. Laut dem Netwrix 2025 Cybersecurity Trends Report, haben 46 % der Organisationen im letzten Jahr einen Kompromiss von Konten erlebt, im Vergleich zu nur 16 % im Jahr 2020. Maschinen-zu-Maschinen-Identitäten wie Dienstkonten und Tokens sind ein wachsender Faktor in diesem Trend, und die meisten IT-Teams im Mittelstand haben nicht die Sichtbarkeit, um sie effektiv zu verwalten.

Was sind nicht-menschliche Identitäten in der Cybersicherheit und warum sind sie wichtig?

Nicht-menschliche Identitäten (NHIs) sind digitale Anmeldeinformationen, die es Maschinen, Anwendungen und automatisierten Prozessen ermöglichen, sich zu authentifizieren und auf Ressourcen ohne menschliches Eingreifen zuzugreifen. Dienstkonten, API-Schlüssel, verwaltete Identitäten, OAuth-Token und KI-Agenten fallen alle unter das NHI-Dach.

Ihre Zahlen wachsen schnell. Jede Cloud-Ressource, CI/CD-Pipeline, Automatisierungsworkflow und KI-Integration schafft neue NHIs, die Anmeldeinformationen und Berechtigungen benötigen. In den meisten Organisationen übersteigen die Maschinenidentitäten die menschlichen Benutzer um einen Faktor von 10:1 oder mehr.

Wenn Ihre Backup-Software um 2 Uhr morgens eine Verbindung zu einer Datenbank herstellt, gibt sie kein Passwort ein. Sie authentifiziert sich mit einem Dienstkonto mit gespeicherten Anmeldeinformationen. Das ist ein NHI. Das Gleiche gilt für den API-Schlüssel, den Ihr Ticketsystem verwendet, um CRM-Daten abzurufen, oder das OAuth-Token, das die Mitarbeiterdaten mit Entra ID synchronisiert.

Wie Jeff Warren, Chief Product Officer bei Netwrix, im Bericht über die Cybersecurity-Trends 2025 feststellte, werden identitätsgesteuerte Angriffe voraussichtlich noch dominanter, wobei "der Missbrauch von Maschinen-zu-Maschinen-Identitäten wie Dienstkonten und Tokens" zu den aufkommenden Vektoren gehört.

Menschliche Identitäten vs. nicht-menschliche Identitäten

Menschliche und nicht-menschliche Identitäten unterscheiden sich darin, wie sie besessen, authentifiziert, verwaltet und überwacht werden:

• Eigentum: Menschliche Identitäten haben klare Eigentümer. NHIs haben oft gemeinsames oder unklaren Eigentum, was es schwierig macht, Verantwortung durchzusetzen.
• Authentifizierung: Menschen verwenden Passwörter in Kombination mit MFA. NHIs verwenden Schlüssel, Tokens und Zertifikate, und MFA gilt nicht.
• Lebenszyklus: Menschliche Identitäten folgen von HR gesteuerten Prozessen (Einstellung, Rollenwechsel, Austritt). NHIs werden ad hoc von Entwicklern und Administratoren erstellt, ohne eine entsprechende Lebenszyklusverwaltung.
• Verhalten: Menschlicher Zugang ist interaktiv und variabel. NHI-Zugang ist programmatisch und repetitiv, was die Anomalieerkennung sowohl einfacher macht, um eine Basislinie zu erstellen, als auch schwieriger, sie in großem Maßstab zu überprüfen.

Passwortrichtlinien, MFA, SSO und Zugriffsprüfungen lassen sich nicht sauber auf NHIs übertragen. Deshalb benötigen Maschinenidentitäten ihren eigenen Governance-Ansatz.

Der verwandte Begriff „Maschinenidentität“ bezieht sich speziell auf Identitäten auf Infrastruktur-Ebene wie Server, VMs und Zertifikate. NHI ist breiter gefasst und umfasst diese sowie Anwendungsidentifikatoren wie API-Schlüssel, Tokens und Bots.

Nicht-menschliche Identitätsauthentifizierungsmethoden

NHIs authentifizieren sich programmgesteuert anstelle von interaktivem Login, indem sie vier Hauptmethoden verwenden:

• Token-basiert: API-Schlüssel, Bearer-Token und JWT-Token
• Schlüsselbasiert: SSH-Schlüssel und Dienstkonto-Schlüssel
• Zertifikatsbasiert: X.509-Zertifikate und gegenseitiges TLS (mTLS)
• Arbeitslast-Identitätsföderation: Cloud-native Mechanismen wie AWS IAM-Rollen, Azure verwaltete Identitäten und GCP-Dienstkonten

Das kritische Risiko in allen vier Fällen besteht darin, dass MFA und SSO nicht angewendet werden. Wenn eine Anmeldeinformation kompromittiert wird, gibt es keinen zweiten Faktor, um die Ausnutzung zu verhindern, und der Angreifer erbt den Zugriff, den diese Identität hat.

Häufige Arten von nicht-menschlichen Identitäten

Das Verständnis der verschiedenen Arten von NHIs in Ihrer Umgebung ist der erste Schritt, um sie effektiv zu verwalten. Die folgenden Kategorien repräsentieren die häufigsten nicht-menschlichen Identitäten, die Sie in lokalen und Cloud-Umgebungen antreffen werden.

1. Dienstkonten und Anwendungsidentitäten

Dienstkonten sind spezialisierte Konten, die es Anwendungen ermöglichen, Aufgaben ohne menschliche Anmeldeinformationen auszuführen. Ihre Backup-Software verwendet eines, um auf SQL Server-Datenbanken zuzugreifen, und Ihre Überwachungstools verwenden sie, um Leistungsdaten zu sammeln. In AD-Umgebungen werden diese durch das Attribut ServicePrincipalName (SPN) identifiziert.

Die zentrale Sicherheitsherausforderung besteht darin, dass Passwörter selten geändert werden. Die moderne Best Practice besteht darin, zu Gruppierte Verwaltete Dienstkonten (gMSAs), die eine automatische Passwortverwaltung über Active Directory bereitstellen und manuelle Eingriffe des Administrators eliminieren.

Anwendungsidentitäten erweitern dieses Konzept auf cloud-native Umgebungen, in denen Cloud-Plattformen dedizierte Identitäten für Anwendungen zuweisen, um auf APIs, Datenbanken und andere Cloud-Ressourcen zuzugreifen.

2. API-Schlüssel und Geheimnisse

API-Schlüssel und Geheimnisse erfüllen die gleiche grundlegende Funktion: Sie ermöglichen es einem System, sich ohne menschliches Eingreifen bei einem anderen zu authentifizieren. Sie sind in interne Tools, SaaS-Integrationen und Verbindungen zu Drittanbieterdiensten eingebettet, um programmgesteuerten Zugriff zu gewähren, ohne dass jemand sich anmelden muss.

That third-party category is broader than most teams realize. When a printer communicates with its manufacturer for supply monitoring, or when manufacturing equipment sends telemetry to an OEM for remote maintenance, those connections rely on API keys or embedded credentials that authenticate across organizational boundaries. These vendor-managed NHIs often fall outside standard identity governance because they're provisioned by the vendor, not by your IT team.

Die Herausforderung bei all dem ist ihre statische Natur. Im Gegensatz zu Passwörtern, die an Benutzerkonten gebunden sind, laufen API-Schlüssel in den meisten Systemen standardmäßig nicht ab und landen oft in Konfigurationsdateien, Code-Repositories, Umgebungsvariablen und sogar in Chat-Protokollen.

Das Gleiche gilt für Geheimnisse, die in Tresoren oder Konfigurationsdateien gespeichert sind, einschließlich Passwörter, Verbindungszeichenfolgen und Verschlüsselungsschlüssel. Diese Anmeldeinformationen tragen dasselbe Zugriffsrisiko wie jeder API-Schlüssel, erhalten jedoch oft weniger Aufmerksamkeit.

Sobald diese Anmeldeinformationen geleakt werden, sind sie sofort ausnutzbar, und Organisationen wissen oft nicht, dass eines davon bereits verwendet wurde, bis es bereits genutzt wurde. Wenn die kompromittierte Anmeldeinformation zu einer Drittanbieter-Integration gehört, erstreckt sich der Explosionsradius über Ihre Umgebung hinaus in die Beziehungen zu Anbietern, die durch Rahmenwerke wie NIS2 und DORA geregelt sind, die beide Risikokontrollen in der Lieferkette für digitale Dienstabhängigkeiten vorschreiben.

3. Verwaltete Identitäten

Verwaltete Identitäten stellen Microsofts modernen Ansatz zur NHI-Authentifizierung in Azure dar. Systemzugewiesene verwaltete Identitäten sind direkt mit bestimmten Azure-Ressourcen verknüpft und beseitigen die Notwendigkeit, Anmeldeinformationen vollständig zu speichern. Benutzerzugewiesene verwaltete Identitäten können über mehrere Ressourcen hinweg geteilt werden.

Managed Identities lösen das Problem jedoch nur innerhalb des Azure-Ökosystems. Organisationen, die hybride Umgebungen betreiben, benötigen weiterhin Sichtbarkeit auf lokale Dienstkonten und plattformübergreifende Anmeldeinformationen, die von Managed Identities nicht abgedeckt werden.

4. OAuth-Token

OAuth-Token ermöglichen delegierten Zugriff zwischen Anwendungen. Wenn Ihre HR-Plattform die Mitarbeiterdaten mit Ihrem Identitätsanbieter synchronisiert oder Ihr Reporting-Tool Datensätze aus einem SaaS-CRM abruft, basieren diese Verbindungen auf OAuth-Aktualisierungstoken, um einen dauerhaften Zugriff aufrechtzuerhalten.

Diese Tokens haben oft eine längere Lebensdauer als beabsichtigt und sammeln sich in Ihren SaaS-Integrationen an, während Teams mehr Tools miteinander verbinden.

5. Cloud-Arbeitslast- und Containeridentitäten

Arbeitslastidentitäten umfassen die Anmeldeinformationen, die Containeranwendungen, serverlose Funktionen und Cloud-Arbeitslasten zugewiesen sind. Ihre Kubernetes-Bereitstellungen, Azure Container Instances und AWS Lambda-Funktionen benötigen alle Anmeldeinformationen, um auf andere Dienste zuzugreifen.

Cloud-Plattformen weisen diesen Workloads Identitäten zu, einschließlich VMs, Containern, serverlosen Funktionen und Kubernetes-Pods, um auf Cloud-Ressourcen, Speicher und APIs zuzugreifen. Diese Workload-Identitäten werden schnell erstellt und zerstört, oft schneller als die Sicherheits-Teams sie verfolgen können.

6. Identitäten von Maschinen und Geräten

Physische und virtuelle Maschinen, IoT-Geräte und Infrastrukturkomponenten tragen alle ihre eigenen Identitäten. Zertifikate authentifizieren häufig diese Maschinenidentitäten und schaffen eine Schicht der NHI-Governance, die sich mit, aber über die Anmeldeinformationen auf Anwendungsebene hinaus erstreckt. Mit dem Wachstum der IoT-Adoption wächst auch diese Identitätspopulation.

7. Bots und KI-Agenten

Bots und KI-Agenten stellen die neueste und am schnellsten wachsende Kategorie nicht-menschlicher Identitäten dar. Zum Beispiel:

• Microsoft Copilot benötigt Zugriff auf Ihre Dateien und E-Mails, um nützlich zu sein
• Robotic Process Automation (RPA) Bots benötigen Anmeldeinformationen, um mit Geschäftsanwendungen zu interagieren
• CI/CD-Bots benötigen Zugriff, um Code bereitzustellen
• Orchestrierungswerkzeuge und KI-Agenten agieren als nicht-menschliche Identitäten, oft mit umfassendem Zugriff, um Automatisierungsworkflows zu ermöglichen

Jeder dieser erstellt Identitätsbeziehungen, die die gleiche Governance wie jede andere NHI erfordern, aber sie werden oft schnell von Geschäftsteams ohne Sicherheitsüberprüfung bereitgestellt.

Das zusätzliche Risiko besteht darin, dass KI-Tools mit Code-Repositories und Entwicklungsumgebungen interagieren. Dies kann unbeabsichtigt Anmeldeinformationen in Eingabeaufforderungen, Ausgaben und Protokollen offenlegen und Leckvektoren schaffen, die das traditionelle Scannen von Geheimnissen nicht immer erfasst.

Jeder dieser Identitätstypen erfordert unterschiedliche Verwaltungsansätze, aber alle teilen gemeinsame Governance-Herausforderungen: Eigentumstracking, Berechtigungsrotation und Stilllegung, wenn sie nicht mehr benötigt werden.

Wie man nicht-menschliche Identitäten in Ihrer Umgebung entdeckt

Bevor Sie NHIs verwalten können, müssen Sie sie finden. Ein strukturierter Entdeckungsprozess hilft Ihnen, den Umfang des Problems zu verstehen, aber die meisten Organisationen erkennen schnell, dass manuelle Ansätze nur an der Oberfläche kratzen.

Beginnen Sie mit Ihrem Identitätsanbieter

Abfragen Sie Active Directory nach Konten mit Dienstprinzipalnamen, eigenständigen verwalteten Dienstkonten und gruppenverwalteten Dienstkonten.

Für Cloud-Umgebungen ziehen Sie ein Inventar von Dienstprinzipalen, Anwendungsregistrierungen und verwalteten Identitäten aus der Administrationskonsole Ihres Identitätsanbieters. Konzentrieren Sie sich auf vier Attribute für jede Identität: welche Anwendung sie verwendet, welche Anmeldeinformationen sie hält, auf welche Ressourcen sie zugreifen kann und wem sie gehört.

Erweitern Sie Ihre Code- und Automatisierungsebene

Arbeiten Sie mit Ihrem DevOps-Team zusammen, um Anmeldeinformationen zu identifizieren, die in CI/CD-Pipeline-Konfigurationen, Infrastruktur-als-Code-Vorlagen und Umgebungsvariablen gespeichert sind. Repository-Scan-Tools können hardcodierte Anmeldeinformationen und API-Schlüssel, die in die Versionskontrolle eingegeben wurden, kennzeichnen. Hier leben oft die meisten nicht nachverfolgten NHIs.

Überprüfen Sie Ihre SaaS-Integrationen

Überprüfen Sie OAuth-Berechtigungen und API-Verbindungen in Ihren SaaS-Anwendungen. Viele Organisationen entdecken Dutzende aktiver OAuth-Token von Integrationen, die vor Monaten oder Jahren von Personen eingerichtet wurden, die das Team oder das Unternehmen inzwischen verlassen haben.

Dokumentieren Sie, was Sie finden

Für jedes NHI, das Sie entdecken, notieren Sie den Eigentümer (eine Person, kein Team), die geschäftliche Begründung, den Typ der Anmeldeinformationen und den Rotationsstatus sowie das letzte Mal, dass jemand validiert hat, dass es noch benötigt wird. Dieses Inventar wird zur Grundlage für alles, was folgt.

Eine wichtige Warnung: Manuelle Entdeckung gibt Ihnen einen Momentaufnahme, kein lebendiges Inventar. Umgebungen ändern sich täglich, und ein vierteljährlicher Export wird das Dienstkonto, das jemand letzten Dienstag erstellt hat, nicht erfassen.

Kontinuierliche, automatisierte Entdeckung ist das, was Organisationen trennt, die ihre NHI-Bevölkerung kennen, von denen, die nur denken, dass sie es tun.

Wie man nicht-menschliche Identitäten sichert und verwaltet

Das Management nicht-menschlicher Identitäten (NHIM) ist die Praxis, Maschinenidentitäten zu entdecken, zu verwalten und zu sichern, die das traditionelle IAM und das Privileged Access Management (PAM) nicht bewältigen konnten.

Das bedeutet, den Zugriff ohne menschlichen Akteur zu steuern, Anmeldeinformationen zu verwalten, die MFA nicht verwenden können, und die Eigentümerschaft für Identitäten zu verfolgen, die von Entwicklern und Automatisierung anstelle von HR-Prozessen erstellt wurden.

Sobald Sie identifiziert haben, was in Ihrer Umgebung vorhanden ist, sorgt die Governance dafür, dass es unter Kontrolle bleibt. Effektive NHI-Sicherheit behandelt Maschinenidentitäten als Bürger erster Klasse in Ihrem Identitätssicherheitsprogramm, mit definierten Richtlinien für jede Phase ihres Lebenszyklus.

So sieht das in der Praxis aus:

• Weisen Sie bei der Erstellung jedem NHI einen Eigentümer zu: Es sollte keine Identität existieren, ohne dass eine benannte Person (keine Verteilerliste, kein Teamalias) für ihren Zugriff und Lebenszyklus verantwortlich ist. Machen Sie das Eigentum zu einem Pflichtfeld in Ihrem Bereitstellungsprozess.
• Setzen Sie das Prinzip des geringsten Privilegs von Anfang an durch: Gewähren Sie nur die spezifischen Berechtigungen, die jedes NHI für seine Funktion benötigt, beschränkt auf die engste Ressourcenebene, die möglich ist. Vermeiden Sie bereichsweite oder domänenweite Berechtigungen für Dienstkonten, die nur Zugriff auf eine einzige Anwendung benötigen.
• Automatisieren Sie die Rotation von Anmeldeinformationen, wo immer dies möglich ist: gMSAs erledigen dies automatisch für lokale AD-Workloads. Für Cloud-Service-Prinzipien und API-Schlüssel integrieren Sie die Rotation in Ihre Bereitstellungspipelines oder verwenden Sie eine Lösung zur Verwaltung von Geheimnissen.

Die richtige Frequenz hängt vom Typ der Anmeldeinformationen und dem Expositionsrisiko ab, da wichtige Rahmenwerke wie NIST, CIS, und PCI DSS keine universelle Rotationsperiode für privilegierte Konten vorschreiben.

• Überwachen Sie Verhaltensanomalien: Ein Dienstkonto, das plötzlich auf Ressourcen außerhalb seines normalen Musters zugreift, oder ein API-Schlüssel, der sich von einem unbekannten Standort authentifiziert, sollte einen Alarm auslösen. Konzentrieren Sie sich auf die Überwachung von Abweichungen von festgelegten Basislinien, anstatt zu versuchen, jedes Ereignis zu überprüfen.
• Aggressiv außer Betrieb nehmen: Veraltete NHIs sind eine der am meisten ausnutzbaren Schwächen in jeder Umgebung. Integrieren Sie Deaktivierungs-Trigger in Ihren Prozess: Wenn sich eine Identität in 90 Tagen nicht authentifiziert hat, kennzeichnen Sie sie zur Überprüfung. Wenn der Eigentümer es nicht rechtfertigen kann, deaktivieren Sie es. Wenn es 30 Tage lang niemandem auffällt, entfernen Sie es.
• Zugriff in einem wiederkehrenden Zeitplan zertifizieren:Erfordern, dass NHI-Eigentümer erneut bestätigen, dass jede Identität weiterhin ihre aktuellen Berechtigungen benötigt. Jährliche Überprüfungen sind ein Ausgangspunkt, aber vierteljährliche sind besser für privilegierte Identitäten.

Diese Kontrollen entsprechen direkt den Anforderungen, die bereits in wichtigen Compliance-Rahmenwerken verankert sind:

• CMMC Level 2 erfordert Zugriffskontrolle und Kontoverwaltung für alle Identitäten, einschließlich nicht-menschlicher
• Die SOC 2-Kriterien für vertrauenswürdige Dienste erfordern Zugriffskontrollen, die auch für nicht-menschliche Identitäten gelten
• HIPAA verlangt Prüfprotokolle für alle Zugriffe auf geschützte Gesundheitsinformationen, einschließlich Zugriffe durch automatisierte Prozesse und Dienstkonten
• Die NIS2 (EU) verlangt von den Organisationen, die Risiken der ICT-Lieferkette zu verwalten, einschließlich der Anmeldeinformationen von Drittanbietern und der von Anbietern verwalteten Identitäten, die auf Ihre Umgebung zugreifen
• DORA (EU-Finanzsektor) verlangt ein Risikomanagement für ICT-Drittanbieter mit spezifischen Anforderungen zur Überwachung und Steuerung digitaler Dienstabhängigkeiten, einschließlich der Maschinenidentitäten, die diese Dienste verwenden

Wenn Sie die NHI-Governance aufbauen, bauen Sie gleichzeitig Nachweise für die Einhaltung auf.

Wie Netwrix die Sicherheit nicht-menschlicher Identitäten unterstützt

Jede oben genannte Governance-Praxis hängt von einer Sache ab: zu wissen, welche nicht-menschlichen Identitäten in Ihrer Umgebung existieren und was sie tun. Das ist die Lücke, die die meisten Organisationen schwer selbst schließen können, und hier kommt Netwrix ins Spiel.

Die Netwrix 1Secure-Plattform bietet kontinuierliche Sichtbarkeit in die Identitätslage in Active Directory und Cloud-Umgebungen. Für nicht-menschliche Identitäten zeigt es insbesondere inaktive Konten, veraltete Konten und übermäßig permissive Zugriffsberechtigungen, die gegen die Unternehmensrichtlinien verstoßen, und gibt den Sicherheitsteams ein aktuelles Bild des Zustands anstelle eines vierteljährlichen Schnappschusses.

Wo manuelle Abfragen Ihnen einen zeitpunktbezogenen Export geben, behält 1Secure eine fortlaufende Ansicht, während neue Identitäten erstellt und bestehende geändert werden.

Für Active Directory speziell, Netwrix Auditor verfolgt Änderungen an Dienstkonten, überwacht Authentifizierungsereignisse und prüft Änderungen an Gruppenrichtlinien, wodurch die Sichtbarkeitslücken geschlossen werden, die native Tools offen lassen.

Wenn jemand ein neues Dienstkonto erstellt, seine Gruppenmitgliedschaft ändert oder versucht, sich interaktiv anzumelden, kennzeichnet Auditor dies. Teams können beginnen, Auditfragen zur NHI-Aktivität mit für Menschen lesbaren Berichten zu beantworten, die direkt auf Compliance-Rahmenwerke wie HIPAA, SOC 2 und CMMC.

Für privilegierte nicht-menschliche Identitäten, die erhöhten Zugriff benötigen, Netwrix Privilege Secure beseitigt dauerhafte Privilegien durch bedarfsorientierte Bereitstellung mit vollständiger Sitzungsaufzeichnung für Prüfpfade. Anstatt dass Dienstkonten rund um die Uhr persistierenden Administratorzugriff haben, gewährt Privilege Secure erhöhte Berechtigungen nur bei Bedarf und widerruft sie automatisch, wenn die Aufgabe abgeschlossen ist.

Bereit, die Sichtbarkeitslücke bei nicht-menschlichen Identitäten zu schließen?Buchen Sie eine Demo um zu sehen, wie Netwrix in Ihrer Umgebung funktioniert.