Die 5 Metriken, die jedes Security-Team für die Governance nicht-menschlicher Identitäten braucht
Die meisten Unternehmen können grundlegende Fragen zu ihren NHIs nicht beantworten. Hier sind die 5 messbaren Metriken - mit Formeln, Baselines und Zielwerten -, die NHI-Governance von Raterei in ein belastbares Programm verwandeln.
6 Min. Lesezeit · Zuletzt aktualisiert Juli 2026
Die meisten Security-Teams können ihre Mean-Time-to-Detect für Endpoint-Alerts nennen. Stellt man dieselbe Frage zu einem kompromittierten Service-Account, folgt Schweigen. Diese Lücke ist das NHI-Governance-Problem in einem Satz.
Nicht-menschliche Identitäten übersteigen menschliche Identitäten inzwischen im Verhältnis 144 zu 1 - ein Anstieg von 56 % innerhalb eines einzigen Jahres, laut [1]. Dennoch verwalten die meisten Unternehmen sie noch so, wie sie menschliche Konten im Jahr 2015 verwaltet haben: Excel-Listen, periodische Reviews und Hoffnung. Das Ergebnis ist eine wachsende Population ungetrackter, nicht zugewiesener Machine-Identities mit dauerhaften Zugriffen, die niemand überprüft - und [2] stellt fest, dass die Exposition bereits seit Monaten oder Jahren besteht, wenn ein Auditor oder Angreifer sie schließlich entdeckt.
Bevor man NHIs governet, muss man sie finden. Nur etwa 28 % der Unternehmen glauben, verhindern zu können, dass ein rogue Agent Schaden anrichtet, so der [3]. Schritt null ist kontinuierliche Discovery - ein dauerhaft aktives Inventar, das jeden Service-Account, jeden API-Key, jedes OAuth-Token und jeden KI-Agenten beim Anlegen erfasst, nicht erst sechs Monate später im Rahmen eines Audits. Alles Folgende setzt voraus, dass dieser Schritt bereits erfolgt ist.
Sobald ein Inventar vorliegt, braucht man ein Messframework. Hier sind die fünf Metriken, die zählen - was jede bedeutet, warum sie Risiken vorhersagt, wie man sie berechnet und welchen Zielwert man anstreben sollte.
Metrik 1: NHI-Coverage-Rate
Was sie misst: Den Prozentsatz der entdeckten NHIs, die aktiv gegovert werden - d. h. die einen namentlich benannten Owner, einen definierten Zweck haben und in die Lifecycle-Richtlinien / Policies eingebunden sind.
Warum sie Risiken vorhersagt: Eine nicht-gegoverte NHI ist für Access-Reviews, Rotationspläne und Deprovisionierungs-Workflows unsichtbar. [4] stellte fest, dass es in den meisten Unternehmen nie eine einzige Source of Truth für NHIs gab und auch keine standardisierten Onboarding-, Offboarding- oder Ownership-Prozesse - was Inventare bestenfalls unvollständig lässt. Jede nicht-gegoverte Identität ist ein potenzieller blinder Fleck, den ein Angreifer ausnutzen kann, ohne einen einzigen Alert auszulösen.
Berechnung:
NHI-Coverage-Rate = (Gegoverte NHIs ÷ Gesamt entdeckte NHIs) × 100
Als Baseline einen vollständigen Discovery-Scan über IdP, Cloud-Umgebungen, CI/CD-Pipelines und SaaS-Apps durchführen. Jede Identität zählen, die einen zugewiesenen Owner hat und in eine Policy eingebunden ist. Durch die Gesamtzahl der entdeckten Identitäten dividieren. Die meisten Unternehmen, die diese Übung zum ersten Mal durchführen, stellen fest, dass die Coverage unter 40 % liegt.
Zielwert: ≥ 90 %. Alles unter 70 % bedeutet, dass ein wesentlicher Teil des Machine-Identity-Bestands außerhalb der Governance-Kontrollen operiert.
Metrik 2: Rate verwaister NHIs
Was sie misst: Den Prozentsatz der NHIs, deren Owner das Unternehmen verlassen hat oder deren verantwortliches Team nicht mehr existiert - Identitäten, für die faktisch niemand verantwortlich ist.
Warum sie Risiken vorhersagt: Überraschende 75 % der Unternehmen berichten, dass sie Machine-Identities ohne dediziertes Personal zur Verwaltung haben, so [5]. Wenn ein Engineer das Unternehmen verlässt, gehen die von ihm erstellten API-Keys und Service-Accounts nicht mit. [6] stellte fest, dass nur 19 % der Unternehmen automatisierte Prozesse für das Offboarding von API-Keys haben. Der SolarWinds-Breach ist das Paradebeispiel: Ein verwaistes Secret ermöglichte es Angreifern, Tausende von Systemen zu kompromittieren - lange nachdem der Mensch, der es erstellt hatte, längst weg war.
Berechnung:
Rate verwaister NHIs = (NHIs ohne aktiven Owner ÷ Gesamt gegoverte NHIs) × 100
Das NHI-Inventar mit dem HRIS abgleichen. Jede NHI markieren, deren Owner-Konto deaktiviert ist oder deren verantwortliches Team aufgelöst wurde. Auch NHIs markieren, die Verteilerlisten als Owner haben - [2] stellt fest, dass bei NHIs, die einem Team-Alias gehören, niemand Verantwortung übernimmt und veraltete Identitäten sich ansammeln.
Zielwert: < 5 %. Null ist das Ziel; 5 % ist die realistische Obergrenze für eine dynamische Organisation. Über 10 % ist ein wesentliches Risiko, das einen sofortigen Remediation-Sprint erfordert.
Metrik 3: Rate überprivilegierter NHIs
Was sie misst: Den Prozentsatz der NHIs, deren erteilte Berechtigungen nachweislich über das hinausgehen, was sie tatsächlich nutzen - gemessen an der tatsächlichen Laufzeitaktivität, nicht am angegebenen Zweck.
Warum sie Risiken vorhersagt: Dies ist die alarmierendste Zahl im NHI-Bereich. 97 % der NHIs haben übermäßige Berechtigungen, laut dem [7]. Der Mechanismus ist banal: Ein Entwickler braucht unter Zeitdruck einen Service-Account, hängt AdministratorAccess dran und macht weiter. Niemand überprüft es erneut. Dieser Account hat nun Vollzugriff auf die gesamte AWS-Umgebung für eine Aufgabe, die nur Lesezugriff auf einen einzigen S3-Bucket benötigt hätte. Gerade einmal 0,01 % der Machine-Identities kontrollieren 80 % der Cloud-Ressourcen, so [8]. Systeme mit KI-Zugriffen nach dem Least-Privilege-Prinzip haben eine Sicherheitsvorfallsrate von 17 % gegenüber 76 % bei überprivilegierten Systemen - ein [9].
Berechnung:
Rate überprivilegierter NHIs = (NHIs mit Berechtigungen > tatsächliche Nutzung ÷ Gesamt gegoverte NHIs) × 100
Erteilte Berechtigungen mit einem 30-90-Tage-Fenster tatsächlicher API-Aufrufe und Ressourcenzugriffe vergleichen. Jede NHI, die eine Berechtigung in diesem Zeitraum nicht genutzt hat, ist ein Kandidat für Right-Sizing. Cloud-Anbieter stellen diese Daten nativ bereit (AWS IAM Access Analyzer, GCP Policy Analyzer); die Herausforderung besteht darin, sie über den gesamten Stack hinweg zu aggregieren.
Zielwert: < 20 %. Die Branchen-Baseline liegt bei 97 % - selbst das Erreichen von 50 % ist daher ein bedeutender Fortschritt. Das Ziel ist kontinuierliches Right-Sizing, kein einmaliges Audit.
Nehmen Sie kein Right-Sizing in der Produktion vor, ohne einen Rollback-Plan zu haben. Eine Berechtigung zu entfernen, die eine NHI seit 90 Tagen nicht genutzt hat, klingt sicher – bis ein vierteljährlicher Batch-Job oder ein Disaster-Recovery-Workflow auftaucht, der nur einmal im Jahr läuft. Führen Sie Berechtigungsreduzierungen immer schrittweise durch und überwachen Sie mögliche Fehler, bevor Sie die Änderungen festschreiben.
Metrik 4: Credential-Alter / Rate veralteter statischer Secrets
Was sie misst: Den Prozentsatz der NHI-Credentials (API-Keys, Service-Account-Passwörter, Tokens, Zertifikate), die das definierte maximale Alter ohne Rotation überschreiten.
Warum sie Risiken vorhersagt: Statische Secrets sind ein Geschenk, das nicht aufhört zu geben - für Angreifer. 71 % der NHIs werden nicht innerhalb der empfohlenen Zeitrahmen rotiert, so [10]. 7,5 % der Machine-Identities in Cloud-Umgebungen sind zwischen 5 und 10 Jahre alt, und über 2 % der aktiven Secrets sind mehr als ein Jahrzehnt alt, laut [11]. Der Internet-Archive-Breach (Oktober 2024) ist der Lehrbuchfall: Angreifer nutzten nicht-rotierte API-Keys aus, die aus einem GitLab-Repository geleakt worden waren, und verschafften sich Zugang zu über 800.000 Support-Tickets. [12] zeigt, dass 70 % der Secrets nach zwei Jahren noch gültig sind - das bedeutet, die meisten Unternehmen tragen jahrelang angesammelte Credential-Exposition mit sich.
Berechnung:
Rate veralteter statischer Secrets = (NHI-Credentials, die die Max-Age-Policy überschreiten ÷ Gesamt NHI-Credentials) × 100
Eine Max-Age-Policy nach Credential-Typ festlegen: API-Keys ≤ 90 Tage, Service-Account-Passwörter ≤ 60 Tage, Zertifikate bis zu ihrem Ablaufdatum verwalten. Secrets Manager, IdP und Cloud-IAM nach letzten Rotationsdaten abfragen. Credentials ohne aufgezeichnetes Rotationsdatum sollten als maximal veraltet behandelt werden.
Zielwert: < 10 % überschreiten die Policy. Für hochprivilegierte NHIs ist der Zielwert 0 %. Rotation wo immer möglich automatisieren - [13] stellt fest, dass manuelle Rotation im großen Maßstab scheitert, wenn Service-Abhängigkeiten, hartcodierte Credentials und Wartungsfenster aufeinandertreffen.
Metrik 5: Mean Time to Deprovision (MTTD-NHI)
Was sie misst: Die durchschnittliche Zeit zwischen dem Zeitpunkt, zu dem eine NHI für die Deprovisionierung qualifiziert ist (Projektende, Mitarbeiteraustritt, Service-Abschaltung), und dem vollständigen Entzug ihrer Credentials in allen Systemen.
Warum sie Risiken vorhersagt: Access-Management hat ein Timing-Problem. [14] stellt fest, dass die meisten Unternehmen Zugriffe in Stunden erteilen können, das Entziehen jedoch Tage dauern kann - und genau in dieser Lücke passieren Breaches. Bei NHIs ist das Problem noch gravierender: Es gibt keinen HR-Offboarding-Trigger, keinen Manager, der das Ticket genehmigt, und kein natürliches Lifecycle-Ereignis, das eine Aktion auslöst. Nur 20 % der Unternehmen haben formale Prozesse für das Offboarding und den Entzug von API-Keys, so der [15]. Jeder Tag, an dem eine für die Deprovisionierung qualifizierte NHI aktiv bleibt, ist ein Tag, an dem ein Angreifer sie nutzen kann.
Berechnung:
MTTD-NHI = Durchschnitt(Deprovisionierungs-Abschlussdatum - Datum des Auslöse-Ereignisses) über alle NHI-Offboarding-Ereignisse im Zeitraum
Auslöse-Ereignisse umfassen: Mitarbeiterkündigung (für NHIs, die dieser Person gehörten), Projektabschluss, Service-Abschaltung oder fehlgeschlagenes Access-Review. Sowohl das Auslöse-Ereignis als auch das Datum erfassen, an dem alle zugehörigen Credentials bestätigt entzogen wurden - nicht nur im IdP deaktiviert, sondern in jedem nachgelagerten System entzogen.
Zielwert: < 4 Stunden für hochprivilegierte NHIs; < 24 Stunden für Standard-NHIs. Wenn die aktuelle MTTD-NHI in Wochen gemessen wird, ist das die erste Metrik, die angegangen werden sollte - sie hat den direktesten Einfluss auf den Blast-Radius eines Breaches.
Der interaktive NHI-Governance-Scorecard
Den nachstehenden Rechner verwenden, um das aktuelle Programm anhand aller fünf Metriken zu bewerten und zu sehen, wo der Fokus zuerst liegen sollte.
Von Metriken zu einem Governance-Programm
Diese fünf Zahlen zu messen ist der Anfang, nicht das Ende. Die Abfolge, die in der Praxis funktioniert:
- Zuerst discovern. Man kann nicht goverten, was man nicht gefunden hat. Kontinuierliche Discovery - kein quartalsweiser Scan - ist die Voraussetzung für jede der oben genannten Metriken.
- Ownership zuweisen. Jede NHI braucht einen namentlich benannten menschlichen Owner. Ohne Ownership sind Coverage- und Orphan-Metriken bedeutungslos.
- Berechtigungen right-sizen. Laufzeitdaten verwenden, nicht den angegebenen Zweck. Die 97-%-Rate überprivilegierter NHIs existiert, weil niemand zurückgegangen ist, um es zu überprüfen.
- Rotation automatisieren. Manuelle Rotation scheitert im großen Maßstab. Policy-gesteuerte, automatisierte Rotation ist der einzige Weg, Staleness-Raten unter 10 % zu halten, wenn Tausende von NHIs verwaltet werden.
- Deprovisionierung mit Lifecycle-Triggern verknüpfen. HRIS-Kündigungen, Projektabschlüsse und fehlgeschlagene Access-Reviews sollten die NHI-Deprovisionierung automatisch anstoßen - und kein Ticket erzeugen, das in einer Queue wartet.
Dies ist genau das Lifecycle-Modell, das in unserem Beitrag über die NHI-Explosion als Treiber von Enterprise-Risiken beschrieben wird - und der Business-Case für operative Effizienz wird ausführlich in Calculating the True ROI of Identity Automation dargelegt.
Eine Scorecard auf einer Seite, die Sie noch heute nutzen können:
| Metrik | Formel | Ihr Ausgangswert | Ziel |
|---|---|---|---|
| NHI Coverage Rate | Verwaltet ÷ Entdeckt × 100 | __% | ≥ 90% |
| Orphaned-NHI Rate | NHIs ohne Eigentümer ÷ Verwaltet × 100 | __% | < 5% |
| Excessive-Privilege Rate | Überprivilegiert ÷ Verwaltet × 100 | __% | < 20% |
| Static-Secret Staleness Rate | Veraltete Anmeldedaten ÷ Gesamte Anmeldedaten × 100 | __% | < 10% |
| Mean Time to Deprovision | Durchschn.(Widerrufsdatum − Auslösedatum) | __ Std. | < 4 Std. |
Führen Sie diese Auswertung vierteljährlich durch. Teilen Sie sie mit Ihrem Vorstand. Die Metriken, die sich nicht verbessern, werden in Ihrem nächsten Vorfallbericht auftauchen.
Unternehmen, die über NHIs kompromittiert werden, sind nicht jene, denen es gleichgültig war - es sind jene, die nie gemessen haben. Unternehmen mit schwachem NHI-Management haben eine um 22 % höhere Wahrscheinlichkeit, Opfer von Finanzkriminalität zu werden, und zahlen zur Wiederherstellung durchschnittlich rund 150.000 US-Dollar mehr als der Durchschnitt, so der [16]. Ein Scorecard löst das Problem nicht. Aber er macht das Problem sichtbar - und sichtbare Probleme werden behoben.