Geisteridentitäten in der Unternehmens-IT

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:

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?