# Geisteridentitäten in der Unternehmens-IT

*Aufspüren, bereinigen und dauerhaft sichern von nicht-menschlichen Identitäten (NHI)*

By [Robin – Cybersecurity | Thoughts are free](https://paragraph.com/@rbn93), 2026-04-20

geisteridentitäten, nicht-menschliche identitäten, nhi, service accounts, api-token, identity security, cloud identity management, least privilege

---

### Warum dieser Guide jetzt entscheidend ist

In jedem mittelgroßen bis großen Unternehmen entfallen **40 bis 50 automatisierte Zugangsdaten pro Mitarbeiter** – Dienstkonten, API-Token, OAuth-Berechtigungen, KI-Agenten, Service-Principals, Machine-to-Machine-Verbindungen und automatisierte Workflows.

Wenn Projekte enden oder Mitarbeiter das Unternehmen verlassen, bleiben die meisten dieser „Geisteridentitäten“ aktiv – mit vollen Administratorrechten und ohne jede Überwachung.

Angreifer müssen keine Firewalls knacken. Sie nehmen sich einfach die Schlüssel, die Sie selbst liegen gelassen haben.

KI-Agenten und automatisierte Pipelines vervielfachen diese Identitäten schneller, als jedes Sicherheitsteam manuell nachhalten kann. Viele besitzen Administratorrechte, die sie nie benötigt haben. Ein einziges kompromittiertes Token reicht aus, um laterale Bewegung durch die gesamte Infrastruktur zu ermöglichen. Die durchschnittliche Verweildauer solcher Eindringlinge liegt bei über **200 Tagen**.

Herkömmliche Identity-and-Access-Management-Lösungen (IAM) sind dafür nicht ausgelegt. Sie verwalten Menschen. Maschinen werden ignoriert.

Dieser Guide liefert Ihnen ein **praktisches, sofort umsetzbares Handbuch** – kein Produkt-Demo, sondern einen vollständigen Rahmen, den Sie noch in dieser Woche an Ihr Security- und Cloud-Team weitergeben können.

* * *

### Kapitel 1: Was genau sind Geisteridentitäten?

**Definition**  
Nicht-menschliche Identitäten (Non-Human Identities = NHI) sind alle Zugangsdaten, die nicht direkt einem menschlichen Benutzerkonto zugeordnet sind:

Kategorie

Beispiele

Typische Gefahr

Dienstkonten

svc-app01, automation-bot

Dauerhaft aktiv, oft Admin-Rechte

API-Token & Keys

GitHub PAT, AWS Access Key, Azure AD App

Keine Passwort-Rotation, unbefristet

OAuth / OIDC Grants

App-Berechtigungen für Microsoft 365, Slack

„Offline Access“-Tokens

KI-Agenten & Bots

LangChain-Agenten, Custom GPTs, RPA-Bots

Oft Broad Scope + Admin-Rechte

Infrastructure-as-Code

Terraform Cloud Tokens, GitHub Actions Secrets

Hohe Privilegien in CI/CD

Machine Identities

Kubernetes ServiceAccounts, VM Managed Identities

Lateral Movement in Containern

**Das Kernproblem**: Diese Identitäten haben keinen „Mitarbeiter-Lebenszyklus“. Sie sterben nicht automatisch, wenn ein Projekt endet.

* * *

### Kapitel 2: Vollständiger Erkennungsscan aller nicht-menschlichen Identitäten

Ziel: Innerhalb von **48 Stunden** ein vollständiges Inventar aller NHI erstellen – unabhängig von Cloud, On-Prem oder SaaS.

#### Schritt-für-Schritt-Scan-Prozess

1.  **Quellen inventarisieren** (erste 4 Stunden)
    
    *   Alle Cloud-Provider (AWS, Azure, GCP, Alibaba)
        
    *   Identity Provider (Entra ID / Azure AD, Okta, Ping, Keycloak)
        
    *   CI/CD-Systeme (GitHub, GitLab, Jenkins, Bitbucket)
        
    *   SaaS-Anwendungen mit OAuth (Microsoft 365, Slack, Salesforce, Notion, etc.)
        
    *   Container-Orchestrierung (Kubernetes, OpenShift)
        
    *   Secrets-Management-Tools (HashiCorp Vault, AWS Secrets Manager, etc.)
        
2.  **Technische Erkennungsmethoden**
    
    *   **Cloud-native Abfragen**:
        
        *   AWS: `aws iam list-users --query "Users[?UserName!='*human*']"` + `list-access-keys`
            
        *   Azure: Microsoft Graph `GET /applications` + `servicePrincipals`
            
        *   GCP: `gcloud iam service-accounts list`
            
    *   **Graph-basierte Analyse**: Nutzen Sie Microsoft Graph Explorer oder Azure Resource Graph, um App-Owner und Berechtigungen zu visualisieren.
        
    *   **Token-Scanning**: Skripte, die alle Repositories auf hardcoded Tokens scannen (TruffleHog, Git-Secrets, gitleaks).
        
    *   **OAuth-Consent-Scan**: Liste aller Apps mit „Admin Consent“ oder Broad Scopes (`Mail.ReadWrite.All`, `Directory.ReadWrite.All` etc.).
        
3.  **KI-gestützte Entdeckung** (empfohlen)
    
    *   Tools wie Microsoft Entra Permissions Management, Orca Security, Wiz oder Sonrai Security können NHI automatisch entdecken.
        
    *   Alternativ: Eigenes Python-Skript mit SDKs aller Provider + zentrale Datenbank (z. B. Neo4j für Graph-Beziehungen).
        

**Ergebnis nach Scan**: Eine Tabelle mit mindestens folgenden Spalten:

*   Identitätsname / Client-ID
    
*   Typ (Service Principal, API Token, etc.)
    
*   Erstellungsdatum
    
*   Letzte Nutzung
    
*   Besitzer / Verantwortlicher (falls bekannt)
    
*   Berechtigungen (Scope / Role)
    
*   Risiko-Score (hoch = Admin + inaktiv > 90 Tage)
    

* * *

### Kapitel 3: Rahmenkonzept zur richtigen Dimensionierung von Berechtigungen (Least Privilege für NHI)

Herkömmliche „Just Enough Access“ funktioniert bei Menschen. Bei Maschinen brauchen Sie ein **dreistufiges Berechtigungs-Framework**:

#### Stufe 1: Just-in-Time (JIT) statt Just-in-Case

*   Token nur für die exakte Dauer der Aufgabe erzeugen (z. B. 15 Minuten für einen CI/CD-Job).
    
*   Azure: Managed Identities + Conditional Access Policies mit „Client Credentials“ + kurzer Gültigkeit.
    
*   AWS: IAM Roles mit `DurationSeconds` + AWS STS AssumeRole mit Session-Dauer.
    

#### Stufe 2: Scope-Minimierung („Least Privilege by Design“)

Regel: Jede NHI darf **nur** die Ressourcen und Aktionen nutzen, die sie tatsächlich braucht.

Beispiel-Checkliste pro Identität:

*   \[ \] Braucht diese App wirklich `Directory.ReadWrite.All` oder reicht `User.Read`?
    
*   \[ \] Darf der KI-Agent wirklich alle E-Mails lesen oder nur bestimmte Postfächer?
    
*   \[ \] Muss das Service-Konto in allen Subscriptions Admin sein oder nur in einer Resource Group?
    

#### Stufe 3: Automatische Berechtigungs-Überprüfung

*   Monatliche „Permission Review“-Workflows (automatisiert per Power Automate oder GitHub Actions).
    
*   Nutzung von „Permission Analytics“-Tools, die „Effective Permissions“ berechnen.
    

* * *

### Kapitel 4: Automatisierte Lebenszyklus-Richtlinie für NHI

**Ziel**: Keine Identität darf länger leben als ihr Projekt.

#### Kern-Elemente der Richtlinie

1.  **Erstellung**
    
    *   Jede neue NHI muss ein „Owner“-Attribut + „Expiration Date“ erhalten.
        
    *   Pflichtfeld: Business Justification + verknüpftes Ticket.
        
2.  **Betrieb**
    
    *   Automatische Rotation aller langfristigen Secrets alle 90 Tage (max. 180 Tage).
        
    *   Inaktive Identitäten (> 45 Tage keine Nutzung) → automatische Deaktivierung.
        
3.  **Widerruf**
    
    *   Bei Projektende (Ticket-Status „Closed“) oder Mitarbeiter-Austritt → sofortiger Widerruf aller zugehörigen NHI (automatisierter Workflow).
        
4.  **Notfall-Widerruf**
    
    *   „Break-Glass“-Prozess: Ein Klick widerruft alle Token eines bestimmten Owners.
        

**Technische Umsetzung** (Beispiel Azure + PowerShell):

    # Automatischer Widerruf nach 90 Tagen Inaktivität
    $apps = Get-MgApplication -All
    foreach ($app in $apps) {
        if ($app.CreatedDateTime -lt (Get-Date).AddDays(-90) -and $app.SignInActivity.LastSignInDateTime -eq $null) {
            Revoke-MgApplicationConsent -AppId $app.AppId
        }
    }
    

* * *

### Kapitel 5: Gebrauchsfertige Checkliste zur Identitätsbereinigung

**Phase 1 – Discovery (Woche 1)**

*   \[ \] Vollständiger Scan aller Clouds und SaaS abgeschlossen
    
*   \[ \] Alle NHI in zentraler Datenbank erfasst
    
*   \[ \] 100 % der Identitäten haben einen Owner zugewiesen
    

**Phase 2 – Risikobewertung (Woche 1–2)**

*   \[ \] Identitäten mit Admin-Rechten markiert
    
*   \[ \] Inaktive Identitäten (> 60 Tage) priorisiert
    
*   \[ \] Tokens mit Broad Scopes identifiziert
    

**Phase 3 – Bereinigung (Woche 2–4)**

*   \[ \] 50 % der High-Risk-NHI auf Least Privilege heruntergestuft
    
*   \[ \] Alle inaktiven Identitäten deaktiviert oder gelöscht
    
*   \[ \] Rotation aller verbleibenden langfristigen Secrets durchgeführt
    

**Phase 4 – Dauerhafte Absicherung (ab Woche 4)**

*   \[ \] Automatisierte Lebenszyklus-Policy aktiv
    
*   \[ \] Monatliches Permission-Review-Meeting etabliert
    
*   \[ \] Alerting bei neuen Admin-NHI oder ungewöhnlicher Token-Nutzung
    

* * *

### Kapitel 6: Praktische Umsetzung im Team & nächste Schritte

1.  **Rollen & Verantwortlichkeiten**
    
    *   Security Team: Scan & Richtlinie
        
    *   Cloud Platform Team: Technische Umsetzung
        
    *   Application Owner: Berechtigungs-Review
        
    *   CISO: Quartals-Reporting „NHI Risk Score“
        
2.  **Messbare KPIs**
    
    *   Anzahl aktiver NHI pro Mitarbeiter (Ziel: < 10)
        
    *   Prozentsatz von NHI mit Least Privilege (Ziel: > 95 %)
        
    *   Durchschnittliche Lebensdauer aktiver Tokens
        
    *   Zeit bis zur Entdeckung kompromittierter NHI (Ziel: < 24 h)
        
3.  **Sofort-Maßnahmen für diese Woche**
    
    *   Heute: Scan in einer Cloud starten (z. B. nur Azure AD)
        
    *   Morgen: Erste High-Risk-Liste erstellen
        
    *   Freitag: Erste 20 gefährlichste Identitäten bereinigen
        

* * *

**Fazit**

Geisteridentitäten sind die größte versteckte Angriffsfläche in modernen Unternehmen. Sie entstehen nicht durch böswillige Angreifer, sondern durch normale Projektarbeit.

Mit dem hier beschriebenen Rahmen können Sie diese Angriffsfläche innerhalb von vier Wochen massiv reduzieren – und langfristig auf nahezu null bringen.

Der Guide ist bewusst so gestaltet, dass Sie ihn **1:1 an Ihr Team weitergeben** können. Kopieren Sie die Checklisten, Skripte und Richtlinien direkt in Ihre internen Dokumente.

Lassen Sie nicht zu, dass versteckte Schlüssel Ihre Daten gefährden.

**Starten Sie heute mit dem ersten Scan.**

Sie haben jetzt alles, was Sie brauchen. Die Frage ist nur: Wann beginnen Sie?

---

*Originally published on [Robin – Cybersecurity | Thoughts are free](https://paragraph.com/@rbn93/geisteridentitaten-in-der-unternehmens-it)*