Sicherheit nicht-menschlicher Identitäten (NHI): Maschinen, Service-Accounts und KI-Agenten

Inhaltsverzeichnis

• Was ist eine nicht-menschliche Identität?
• NHI, Maschinenidentität und Workload-Identität
• Warum NHIs der blinde Fleck im IT-Mittelstand sind
• Die vier NHI-Risiken, die Unternehmen mit 50 bis 500 Mitarbeitenden wirklich treffen
• Was NIS2, DSGVO und ISO 27001 für nicht-menschliche Identitäten verlangen
• Ein Governance-Framework in fünf Schritten
• Wie Sie NHIs in Ihre nächste Zugriffsüberprüfung aufnehmen
• Wie Corma nicht-menschliche Identitäten steuert
• Häufige Fragen

Die meisten Identitätssicherheitsprogramme sind um Menschen herum gebaut: Onboarding, SSO, MFA, Offboarding, eine jährliche Zugriffsüberprüfung. In der Zwischenzeit ist in jedem SaaS-Stack eine zweite Population gewachsen, die niemand ins Organigramm aufgenommen hat. Service-Accounts, API-Keys, OAuth-Freigaben zwischen zwei SaaS-Tools, Zapier- und Make-Automatisierungen, und inzwischen KI-Agenten mit eigenen Konnektoren.

Die veröffentlichten Schätzungen, um welchen Faktor diese Identitäten die Beschäftigten übersteigen, reichen von 25 bis über 100, je nachdem, wer zählt und was gezählt wird. Die Richtung ist unbestritten. Für ein IT-Team von zwei oder drei Personen in einem Unternehmen mit 200 Beschäftigten liegt das Problem jedoch anders: Diese Identitäten wurden nie über Ihr Verzeichnis bereitgestellt, sie erscheinen nicht auf Ihrer Austritts-Checkliste, und die meisten haben keinen Eigentümer.

Dieser Leitfaden behandelt, was eine nicht-menschliche Identität ist, wie sich die Begriffe tatsächlich abgrenzen, welche vier Risiken im Mittelstand real auftreten, was NIS2, die DSGVO und ISO 27001:2022 erwarten, und ein Governance-Framework in fünf Schritten, das Sie mit Ihren vorhandenen Werkzeugen umsetzen können. Ohne Secrets-Management-Plattform.

Was ist eine nicht-menschliche Identität?

Eine nicht-menschliche Identität (NHI) ist eine digitale Identität, die von Software und nicht von einer Person genutzt wird, um sich zu authentifizieren und auf Systeme zuzugreifen. Dazu gehören Service-Accounts, API-Keys, OAuth-Token, Zertifikate, Cloud-Workloads und KI-Agenten.

Im Unterschied zu einer menschlichen Identität, die durch ein Passwort plus zweiten Faktor geschützt und einer namentlich benannten Person zugeordnet ist, authentifiziert sich eine NHI mit einem Secret: einem Token, einem Schlüssel oder einem Zertifikat. Aus diesem Unterschied folgen drei Konsequenzen, die alles Weitere in diesem Artikel erklären.

• Kein MFA. Eine Maschine bestätigt keine Push-Benachrichtigung, folglich bildet die einzelne Anmeldeinformation die gesamte Sicherheitsgrenze.
• Keine Arbeitszeiten. Eine NHI hat kein normales Verhaltensmuster, von dem sie abweichen könnte, was die Anomalieerkennung erschwert.
• Kein Austrittsdatum. Menschen werden offgeboardet. Secrets bleiben in der Regel gültig, bis jemand sie aktiv widerruft.

Die fünf Familien nicht-menschlicher Identitäten

In einer SaaS-Umgebung im Mittelstand lassen sich NHI-Inventare in fünf Kategorien einteilen. Die Unterscheidung ist wichtig, weil jede Familie anders entsteht und daher anders entdeckt wird.

Die entscheidende Beobachtung für ein Unternehmen mit 50 bis 500 Beschäftigten: Das Volumen liegt nicht in Kubernetes-Workloads oder mutual-TLS-Zertifikaten. Es liegt in OAuth-Freigaben und SaaS-seitigen Service-Accounts, die von Mitarbeitenden erzeugt werden, die ein Tool mit einem anderen verbinden.

NHI, Maschinenidentität und Workload-Identität

Die drei Begriffe werden von Anbietern austauschbar verwendet, was in Audits echte Verwirrung erzeugt. Es sind keine Synonyme, und die Abgrenzung ist praktisch, nicht akademisch.

• Nicht-menschliche Identität ist der Sammelbegriff. Er umfasst jede Identität, die keine Person ist.
• Maschinenidentität ist enger und historisch PKI-zentriert: Gemeint sind meist die kryptografischen Anmeldeinformationen (X.509-Zertifikate, TLS, SSH-Schlüssel), mit denen Geräte und Dienste einander vertrauen. Das ist das Vokabular der Anbieter für Zertifikats-Lebenszyklusmanagement.
• Workload-Identität ist noch enger: eine Identität, die einer laufenden Recheneinheit zugeordnet ist (Container, Pod, Serverless-Funktion), üblicherweise kurzlebig und dynamisch von der Cloud-Plattform ausgestellt.

Welcher Begriff gehört in Ihre Richtlinie?

Verwenden Sie nicht-menschliche Identität in Governance-Dokumenten und Audit-Nachweisen, denn nur dieser Begriff ist weit genug, um die OAuth-Freigabe abzudecken, die Ihr Marketing-Team im letzten Quartal erstellt hat. Reservieren Sie Maschinenidentität für Verfahren zur Schlüssel- und Zertifikatsrotation und Workload-Identität für alles Cloud-native. Werden die drei in einer Richtlinie vermischt, landen Service-Accounts ausserhalb des Geltungsbereichs.

Falls Ihr Team das umgebende Vokabular noch klärt: Das Corma-Glossar zu Identity und Access Management deckt die angrenzenden Begriffe ab, und Identity Governance im Vergleich zu Identity Management erklärt, wo die Verantwortlichkeiten liegen.

Warum NHIs der blinde Fleck im IT-Mittelstand sind

Nicht-menschliche Identitäten sind ein blinder Fleck, weil sie ausserhalb des Verzeichnisses entstehen, durch Personen, die nicht in der IT arbeiten, und aus vollkommen legitimen Gründen.

Wie viele NHIs gibt es tatsächlich?

Die veröffentlichten Verhältniszahlen schwanken stark und sollten immer mit Quelle und Datum gelesen werden, denn sie messen unterschiedliche Populationen. Zertifikatsanbieter zählen Zertifikate. SaaS-Sicherheitsanbieter zählen Integrationen. Cloud-Anbieter zählen Workloads.

Behandeln Sie diese Zahlen als Grössenordnung, nicht als Benchmark. Die nützliche Übung besteht darin, die eigenen zu zählen, und genau das ist Schritt 1 des Frameworks weiter unten.

Wie NHIs entstehen, ohne dass jemand entscheidet

Niemand stellt ein Ticket, um eine nicht-menschliche Identität anzulegen. Die üblichen Wege:

• Eine Marketingverantwortliche verbindet das CRM mit der E-Mail-Plattform und klickt auf Zulassen, während der Consent-Screen Lese- und Schreibzugriff auf Kontakte anfordert.
• Ein Entwickler erzeugt einen persönlichen API-Token für ein internes Dashboard und verlässt anschliessend das Unternehmen.
• Ein Finanzanalyst automatisiert einen Export mit Zapier und nutzt dabei seine eigenen Anmeldedaten als Verbindung.
• Jemand aktiviert einen KI-Assistenten in einem SaaS-Tool, und dieser Assistent erbt einen Konnektor mit weitreichenden Berechtigungen.

Jede dieser Handlungen erzeugt einen dauerhaften Zugriffsweg ohne MFA. Keine davon erscheint in Ihrem Verzeichnis. Es ist dasselbe Discovery-Problem wie bei Shadow IT, und es verlangt dieselbe Antwort: kontinuierliche Erkennung über den gesamten SaaS-Bestand statt eines statischen Asset-Registers.

Warum SSO, MFA und Ihr JML-Prozess sie übersehen

Ihre drei wichtigsten Identitätskontrollen sind strukturell blind für NHIs.

• SSO deckt Anwendungen ab, nicht die Maschine-zu-Maschine-Verbindungen zwischen ihnen. Eine OAuth-Freigabe zwischen zwei Anwendungen läuft nicht bei jedem Aufruf über Ihr Verzeichnis.
• MFA lässt sich nicht auf einen Token anwenden. Das ist die grösste Asymmetrie: Ein Angreifer mit einem gültigen API-Key trifft auf keinen zweiten Faktor.
• Der Joiner-Mover-Leaver-Prozess deaktiviert das menschliche Konto. Die von dieser Person erzeugten Token und die unter ihrem Namen laufenden Automatisierungen überleben das Offboarding in der Regel. Unser Leitfaden zum Identitäts-Lebenszyklus und Offboarding für Anwendungen ohne SCIM, SAML oder SSO behandelt die manuelle Seite dieser Lücke.

Die vier NHI-Risiken, die Unternehmen mit 50 bis 500 Mitarbeitenden wirklich treffen

NHI-Inhalte für Grossunternehmen konzentrieren sich auf kompromittierte CI/CD-Pipelines und Lateral Movement in Kubernetes. Diese Risiken sind real, aber es ist nicht das, was in einem Unternehmen mit 200 Personen bricht. Diese vier schon.

1. Verwaiste Identitäten, die ihren Erzeuger überleben

Wenn eine Person das Unternehmen verlässt, wird ihr Benutzerkonto deaktiviert. Der von ihr eingerichtete Service-Account, der Token auf ihren Namen und die von ihr gebaute Zapier-Verbindung funktionieren weiter. Eine verwaiste NHI ist eine nicht-menschliche Identität, deren Eigentümer das Unternehmen verlassen hat oder deren Zweck nicht mehr besteht, deren Anmeldeinformationen aber weiterhin gültig sind. Das ist das klarste Beispiel für einen Zugriffsweg, den keine Überprüfung erfasst, weil keine Überprüfung dort hinsieht.

2. Überprivilegierte OAuth-Freigaben

OAuth-Consent-Screens sind für den App-Anbieter optimiert, nicht für das Sicherheitsteam. Ein Tool, das lediglich Kalenderverfügbarkeiten lesen muss, fordert häufig Vollzugriff auf das Postfach, weil der grobe Berechtigungsumfang einfacher auszuliefern ist. Obsidian Security berichtete 2026, dass Organisationen im Durchschnitt 40 bis 60 Drittanbieter-Integrationen pro kritischer SaaS-Anwendung haben und dass 15 bis 25 Prozent davon seit mehr als 90 Tagen inaktiv waren, ihre vollen Berechtigungen aber behielten.

3. Statische Secrets, die nie rotiert wurden

Menschliche Passwörter haben Ablaufregeln. API-Keys meist nicht. Ein Schlüssel, der 2022 für eine einmalige Migration erzeugt, in eine Tabelle kopiert und nie widerrufen wurde, ist faktisch ein dauerhafter Generalschlüssel. Bei seiner Nutzung wird kein Alarm ausgelöst, weil es keine Vergleichsbasis gab.

4. KI-Agenten-Konnektoren ohne verantwortlichen Eigentümer

Das ist die am schnellsten wachsende und am wenigsten gesteuerte Kategorie. Ein KI-Agent authentifiziert sich wie jede andere NHI, handelt aber mit deutlich mehr Autonomie: Er entscheidet, welche Systeme er aufruft und welche Daten er liest. Wenn Ihr Agenten-Inventar die Frage "wer hat das freigegeben, und worauf kann es zugreifen" nicht beantwortet, haben Sie eine Governance-Lücke, die beim nächsten Audit geprüft wird. Die operative Seite haben wir in der Governance von KI-Agenten behandelt, die praktischen Herausforderungen in Herausforderungen des KI-Agenten-Managements für IT-Teams. Die nicht freigegebene Variante deckt der Aufstieg von Shadow AI ab.

Was NIS2, DSGVO und ISO 27001 für nicht-menschliche Identitäten verlangen

Keiner dieser Texte enthält den Ausdruck "nicht-menschliche Identität". Alle gelten dennoch dafür, weil sie in Begriffen von Identitäten, Konten und Zugriffsrechten formuliert sind und nicht in Begriffen von Beschäftigten. Genau hier haben europäische Mittelstandsunternehmen eine konkrete, datierte Pflicht und nicht nur eine Best Practice.

NIS2

Artikel 21(2) der NIS2-Richtlinie listet die Mindestmassnahmen zum Risikomanagement auf, die betroffene Einrichtungen umsetzen müssen. Drei davon treffen unmittelbar nicht-menschliche Identitäten:

• Richtlinien für die Zugriffskontrolle müssen jeden Zugriff auf Systeme abdecken, und ein API-Key ist ein Zugriff.
• Asset-Management setzt voraus zu wissen, was existiert, und dazu gehören Anmeldeinformationen.
• Sicherheit des Personals verbindet sich mit dem Austrittsprozess, und genau dort entstehen verwaiste NHIs.

Artikel 21 verlangt zudem Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierungslösungen, sofern angemessen. Da MFA auf einen Token nicht anwendbar ist, besteht die erwartete kompensierende Massnahme in Lifecycle-Governance: eingegrenzte Berechtigungen, Rotation und Widerruf. In Deutschland ist das BSI die zuständige Behörde für NIS2. Den grösseren Rahmen behandelt unser Leitfaden dazu, was die NIS2-Richtlinie für Ihr Unternehmen bedeutet.

DSGVO

Sobald eine NHI auf Kunden- oder Beschäftigtendaten zugreift, wird daraus ein Datenschutzthema, und das betrifft die meisten CRM- und HR-Integrationen.

• Artikel 32 DSGVO verlangt angemessene technische Massnahmen zur Sicherheit der Verarbeitung, wozu die Zugriffskontrolle gehört, menschlich wie automatisiert.
• Artikel 30 verlangt ein Verzeichnis von Verarbeitungstätigkeiten. Ein KI-Agent, der eine Kontaktdatenbank liest, ist Teil einer Verarbeitung, und die Zugriffskette gehört dokumentiert.
• Die Aufsichtsbehörden, darunter der BfDI, betonen regelmässig die Beschränkung von Zugriffen auf das Erforderliche. Ein API-Key mit Vollberechtigungen, der von einem Tool gehalten wird, das ihn nicht mehr benötigt, ist ein dokumentierbarer Mangel.

ISO/IEC 27001:2022

Anhang A ist deutlicher. Vier Massnahmen gelten ohne Zweifel für NHIs:

• A.5.16 Identitätsmanagement: Der gesamte Lebenszyklus von Identitäten ist zu steuern, und die Norm stellt ausdrücklich klar, dass Identitäten nicht-menschlichen Entitäten zugewiesen werden können.
• A.5.17 Authentifizierungsinformationen: Zuweisung und Verwaltung von Secrets, also der Umgang mit Ihren API-Keys und Token.
• A.5.18 Zugangsrechte: Bereitstellung, Überprüfung und Entzug von Zugangsrechten.
• A.8.2 Privilegierte Zugangsrechte: Einschränkung und Kontrolle erweiterter Zugriffe, die die meisten Service-Accounts besitzen.

In der Praxis akzeptiert ein Auditor, der nach A.5.16 fragt, eine Nutzerliste aus Ihrem Verzeichnis. Ein Auditor, der die Revision 2022 gelesen hat, fragt zusätzlich nach dem Service-Account-Inventar, mit einem Eigentümer pro Zeile. Unser Leitfaden zu ISO 27001 und IAM bildet den weiteren Massnahmenkatalog ab, und Corma selbst ist nach ISO/IEC 27001:2022 zertifiziert.

Ein Governance-Framework in fünf Schritten

Sie brauchen keine Secrets-Management-Plattform, um zu starten. Sie brauchen ein Inventar, einen Eigentümer pro Zeile und eine wiederkehrende Überprüfung. Hier die Reihenfolge.

Schritt 1: Erkennen

Erstellen Sie eine einzige Liste aller nicht-menschlichen Identitäten in Ihrem Bestand. Ziehen Sie vier Quellen heran: die Service-Account-Liste Ihres Verzeichnisses, das OAuth-Anwendungsinventar in Google Workspace oder Microsoft Entra ID, den Bereich verbundene Anwendungen in jedem Ihrer 20 wichtigsten SaaS-Tools und Ihre Automatisierungsplattformen. Eine SaaS-Management-Plattform erledigt das laufend statt vierteljährlich, was zählt, weil sich die Population wöchentlich verändert.

Schritt 2: Jeder Zeile einen menschlichen Eigentümer zuweisen

Das ist der Schritt mit dem höchsten Ertrag, und er kostet nichts ausser Beharrlichkeit. Jede NHI erhält eine namentlich benannte Person, die dafür verantwortlich ist, ob sie weiter existieren soll. Eine Identität ohne Eigentümer ist eine offene Entscheidung, und die Standardentscheidung sollte der Widerruf sein. Hat der Eigentümer das Unternehmen verlassen, ist die Zeile per Definition verwaist.

Schritt 3: Least Privilege durchsetzen

Fragen Sie für jede Identität, was sie tatsächlich benötigt, nicht was ihr gewährt wurde. Setzen Sie Schreibzugriff auf Lesezugriff zurück, wo der Anwendungsfall es zulässt. Ersetzen Sie geteilte Admin-Service-Accounts durch eingegrenzte. Ein konsistenter Berechtigungsumfang ist leichter, wenn das zugrunde liegende Zugriffsmodell sauber ist, und genau dafür sind RBAC- und ABAC-Zugriffskontrollmodelle gedacht.

Schritt 4: Nach Zeitplan überprüfen

Nicht-menschliche Identitäten gehören in denselben wiederkehrenden Zyklus wie menschliche Konten. Vierteljährlich für alles mit Schreib- oder Admin-Berechtigung, jährlich für reine Leserechte. Die Prüffrage ist eng: Hat diese Identität noch einen Zweck, und ist der Eigentümer noch da? Automatisierte Zugriffsüberprüfungen verwandeln diese Tabellenkalkulationsübung in einen prüffähigen Workflow.

Schritt 5: Standardmässig widerrufen

Verankern Sie den Widerruf im Austrittsprozess, nicht in einem separaten Projekt. Wenn eine Person offgeboardet wird, muss die Checkliste die von ihr erzeugten Token und die unter ihrem Namen laufenden Automatisierungen enthalten. Automatisiertes Provisioning und Deprovisioning schliesst den Kreis auf der menschlichen Seite, die NHI-Seite braucht eine ausdrückliche Zeile im gleichen Runbook.

Wie Sie NHIs in Ihre nächste Zugriffsüberprüfung aufnehmen

Der schnellste Weg zur Abdeckung ist kein neues Programm. Es sind drei zusätzliche Spalten in der Überprüfung, die Sie bereits durchführen.

• Spalte 1: Identitätstyp. Mensch, Service-Account, OAuth-Freigabe, API-Key oder KI-Agent. Allein das zeigt, welcher Anteil Ihrer Zugriffsfläche bisher ausserhalb des Geltungsbereichs lag.
• Spalte 2: verantwortlicher Eigentümer. Eine Person, niemals ein Team-Alias. Über Team-Aliasse verflüchtigt sich Verantwortung.
• Spalte 3: letzte Nutzung. Jede Identität mit Schreibberechtigung, die länger als 90 Tage ungenutzt ist, ist ein Widerrufskandidat und kein Prüfpunkt.

Führen Sie sie einmal mit diesen Spalten durch, und das Ergebnis dient unmittelbar als Nachweis für ISO 27001 A.5.18. Es ist üblicherweise auch der Moment, in dem ein Team entdeckt, dass ein Drittel seiner Integrationen niemandem gehört. Corma-Kunden gehen von der Governance-Seite heran: Satelia, ein Gesundheitsunternehmen unter strengen Datenschutzanforderungen, nutzt Corma für Identity Governance in einer regulierten Umgebung, und Brevo steuert SaaS-Management im grossen Bestand.

Wie Corma nicht-menschliche Identitäten steuert

Die meisten NHI-Werkzeuge wurden für Sicherheitsteams in Grossunternehmen entwickelt und setzen einen Secrets-Vault, ein PKI-Programm und eigene Ressourcen voraus. Corma geht das Problem von der anderen Seite an, denn die NHIs, die im Mittelstand zählen, leben in SaaS-Anwendungen und nicht in der Infrastruktur.

Corma ist eine europäische Plattform für SaaS-Management und Identity Governance, die menschliche und nicht-menschliche Zugriffe über den gesamten SaaS-Bestand hinweg aus einem einzigen Inventar erkennt, zuordnet und überprüft. Konkret:

• Erkennung über den gesamten SaaS-Bestand, einschliesslich OAuth-Freigaben und verbundener Anwendungen, die Ihr Verzeichnis nie berührt haben, über native Konnektoren zu Google Workspace, Microsoft Entra ID, Okta und JumpCloud.
• Zuordnung von Eigentum, damit jeder Service-Account und jede Integration einen verantwortlichen Menschen hat und kein leeres Feld.
• Zugriffsüberprüfungen, die nicht-menschliche Identitäten einbeziehen, im gleichen prüffähigen Zyklus wie Beschäftigte, mit der Nachweiskette, die ein ISO-27001- oder NIS2-Auditor verlangt.
• Offboarding, das die Token erreicht, nicht nur das Benutzerkonto, über automatisiertes User Provisioning und Deprovisioning.
• Europäisches Hosting und DSGVO-native Architektur, mit Zertifizierung nach ISO/IEC 27001:2022, was zählt, wenn das Identitätsinventar selbst personenbezogene Daten enthält.
• Anerkennung im Gartner Magic Quadrant 2025 für SaaS Management Platforms, mit einem konvergenten Ansatz aus Identity und Access Management und Identity Governance, den die meisten Anbieter auf zwei Produkte verteilen.

Sicherheitsteams unter Audit-Druck finden die Compliance-Perspektive auf der Seite Corma IAM-Lösung für Sicherheitsteams.

Möchten Sie Ihr eigenes Inventar nicht-menschlicher Identitäten sehen? Demo anfragen und wir gehen die OAuth-Freigaben und Service-Accounts in Ihrem Bestand gemeinsam durch.

Häufige Fragen

Was ist eine nicht-menschliche Identität?

Eine nicht-menschliche Identität ist eine digitale Identität, die von Software und nicht von einer Person genutzt wird, um sich zu authentifizieren und auf Systeme zuzugreifen. Sie umfasst Service-Accounts, API-Keys, OAuth-Token, Zertifikate, Cloud-Workloads und KI-Agenten. Das bestimmende Merkmal ist, dass sie sich mit einem Secret authentifiziert und nicht mit einem Passwort plus zweitem Faktor.

Was sind Beispiele für nicht-menschliche Identitäten?

Das häufigste Beispiel in einer SaaS-Umgebung ist die OAuth-Freigabe: Verbindet eine Mitarbeiterin ihr CRM mit einem E-Mail-Marketing-Tool und bestätigt die Berechtigungsanfrage, entsteht eine dauerhafte nicht-menschliche Identität zwischen den beiden Anwendungen. Weitere alltägliche Beispiele sind ein Service-Account, der ein Reporting-Tool mit einer Datenbank verbindet, ein API-Key, der ein internes Dashboard betreibt, und eine Zapier-Automatisierung, die unter den Anmeldedaten einer Person läuft.

Was sind nicht-menschliche Identitäten im IAM?

Im IAM sind nicht-menschliche Identitäten die Kontenklasse, die von den klassischen Kontrollen nicht erfasst wird. SSO deckt Anwendungen ab, nicht die Maschine-zu-Maschine-Verbindungen zwischen ihnen, MFA lässt sich auf Token nicht anwenden, und der Joiner-Mover-Leaver-Prozess deaktiviert das menschliche Konto, ohne die von dieser Person erzeugten Token zu berühren. Deshalb gehören NHIs in die Identity Governance und nicht ausschliesslich in die Authentifizierung.

Sind KI-Agenten nicht-menschliche Identitäten?

Ja. Ein KI-Agent authentifiziert sich mit einer Anmeldeinformation und handelt bei jeder Aktion ohne direkte menschliche Eingabe, was ihn per Definition zu einer nicht-menschlichen Identität macht. Er unterscheidet sich von einem klassischen Service-Account durch seine Autonomie: Ein Agent entscheidet, welche Systeme er aufruft und welche Daten er liest, weshalb Berechtigungsbegrenzung und ein verantwortlicher Eigentümer wichtiger sind, nicht unwichtiger.

Was ist der Unterschied zwischen nicht-menschlicher Identität und Maschinenidentität?

Nicht-menschliche Identität ist der Sammelbegriff für jede Identität, die keine Person ist. Maschinenidentität ist eine engere, historisch PKI-zentrierte Teilmenge und bezeichnet kryptografische Anmeldeinformationen wie X.509-Zertifikate, TLS und SSH-Schlüssel, mit denen Geräte und Dienste einander vertrauen. Jede Maschinenidentität ist eine nicht-menschliche Identität, aber eine OAuth-Freigabe zwischen zwei SaaS-Anwendungen ist eine nicht-menschliche Identität, die die meisten Maschinenidentitäts-Werkzeuge nicht abdecken.

Wer ist für die Sicherheit nicht-menschlicher Identitäten verantwortlich?

Die Gesamtverantwortung liegt bei der Rolle, die Identity Governance trägt, üblicherweise die IT- oder Sicherheitsleitung. Das Betriebsmodell funktioniert jedoch nur, wenn jede einzelne Identität einen namentlich benannten menschlichen Eigentümer hat. Identitäten ohne Eigentümer sind die Hauptursache der meisten NHI-Vorfälle, weil niemand in der Lage ist zu entscheiden, ob die Identität weiter bestehen soll.

Lässt sich MFA auf eine nicht-menschliche Identität anwenden?

Nein. Eine Maschine kann keine Zweitfaktor-Abfrage beantworten, weshalb die einzelne Anmeldeinformation die gesamte Sicherheitsgrenze bildet. Die anerkannten kompensierenden Massnahmen sind eingegrenzte Berechtigungen, kurzlebige Anmeldeinformationen wo die Plattform es unterstützt, Rotation der Secrets sowie eine wiederkehrende Überprüfung mit Widerruf aller ungenutzten Identitäten.