Nicht-menschliche Identitäten: Die übersehenen Schlüssel

Management Summary

Ehrliche Bestandsaufnahme: In vielen Umgebungen sind Maschinenidentitäten gefährlicher als Benutzerkonten. Service-Konten mit Dauerrechten, hartkodierte Secrets, ewige Tokens und fehlende Telemetrie sind perfekte Einfallstore – unsichtbar, bequem, oft „technisch nötig“ deklariert. Wer Zero Trust ernst meint, muss nicht nur Menschen prüfen, sondern Workloads, Dienste und Geräte gleich mit. Der Weg ist klar: konsequentes Inventar, minimale Rechte, kurzlebige Anmeldeinformationen, harte Secrets-Rotation und durchgesetztes mTLS – belegt durch KPIs, nicht durch Absichtserklärungen.

Warum nicht-menschliche Identitäten unterschätzt werden

• Unsichtbarkeit im Alltag: Es gibt keinen Mitarbeiter, der „falsch klickt“. Darum landen Service-Konten selten in Awareness-Programmen – und rutschen durch jede Kontrolle.
• Bequemlichkeit vs. Sicherheit: Dauerrechte und statische Passwörter „funktionieren halt“. Bis sie kopiert, geleakt oder aus Repos gefischt werden.
• Skalierungseffekt: Ein kompromittiertes Build-Token oder IoT-Zertifikat öffnet ganze Flotten – laterale Bewegung ohne Alarm.
• Fehlende Eigentümerschaft: Wer „besitzt“ das Konto? Dev? Ops? Fachbereich? Ohne klaren Owner bleibt alles liegen.

Typische Schwachstellen

• Hartkodierte Secrets in Code, CI/CD-Variablen, IaC-Templates → erzwungenes Secret-Scanning, Verbot von Klartext, zentraler Secrets-Store, Secrets-Rotation ≤ 30 Tage.
• Dauerhafte Tokens/Zertifikate → kurzlebige, signierte Workload-Identitäten; automatische Erneuerung, Widerruf bei Anomalien.
• Überprivilegierte Service-Konten → strikte Scopes, Least Privilege, Zugriff zeit- oder ereignisgesteuert; keine Shared-Accounts.
• Fehlende Transport-Sicherheit zwischen Diensten → verpflichtendes mTLS (beidseitige Prüfung) mit automatischer Zertifikatsrotation.
• Kein Inventar/keine Telemetrie → zentrales Register für Maschinenidentitäten, Nutzungs- & Ausstellungslogs, Alarme bei „unmöglichen“ Mustern.

Prinzipien für belastbare Maschinen-Identität

1. Explizite Existenz: Jede nicht-menschliche Identität ist registriert (Owner, Zweck, Scope, Ablaufdatum).
2. Kurzlebigkeit vor Komfort: Tokens/Zertifikate leben Stunden–Tage, nicht Monate. Rotation ist Pflicht, nicht Projektziel.
3. Vertrauen ist nachweisbar: mTLS + Signaturen + Atteste; kein „wir glauben, dass …“.
4. Least Privilege by Design: Rechte sind spezifisch, trennscharf und verfallen automatisch.
5. Detektierbarkeit: Jede Nutzung hinterlässt Korrelation (Identität × Ziel × Zeitpunkt × Quelle) – sonst kein Einsatz.

90-Tage-Plan

Tag 0–15 – Sichtbarkeit & Stoppkriterien

• Vollinventar aller Service-Konten, Tokens, Zertifikate, API-Keys (inkl. Owner, Scope, Ablauf).
• Policies: Verbot hartkodierter Secrets; minimale Laufzeiten; Pflicht zu mTLS für interne Service-zu-Service-Pfad.
• Baseline-KPIs ziehen (s. u.).

Tag 16–45 – Härtung & Kurzlebigkeit

• Zentraler Secrets-Store einführen/vereinheitlichen; automatisierte Secrets-Rotation starten.
• Kurzlebige Workload-Identitäten (signierte, zeitlich begrenzte Anmeldedaten) für die Top-3 kritischen Services.
• mTLS auf kritischen Pfaden aktivieren (beidseitige Prüfung, Auto-Renew).

Tag 46–75 – Automatisieren & löschen

• CI/CD-Gates: Build bricht ab bei hartkodierten Secrets, abgelaufenen Zertifikaten, übergroßen Scopes.
• Rechte-Diät: Überprivilegierte Service-Konten reduzieren; ungenutzte Identitäten löschen.
• Anomalie-Erkennung: Ungewöhnliche Nutzung (Zeit, Quelle, Volumen) → Auto-Revoke + Pager.

Tag 76–90 – Verankern & beweisen

• Rotationszyklen fest drehen (≤ 30 Tage Token, ≤ 90 Tage Zertifikate – je nach Risiko).
• Break-Glass-Prozess für Maschinenidentitäten testen (ausstellen, nutzen, widerrufen, auditieren).
• Quartalsweises Steering mit KPIs; Budget an Wirkung koppeln (z. B. „Pinned-Rate“, „Rotation-Quote“).

KPIs, die Reife messbar machen

• Inventory-Abdeckung: % registrierte Maschinenidentitäten mit Owner, Scope, Ablaufdatum.
• Rotation-Quote: % Secrets/Zertifikate innerhalb Ziel-Zyklen rotiert.
• Kurzlebigkeits-Score: Median-Lebensdauer von Tokens/Zertifikaten je Kritikalität.
• mTLS-Abdeckung: % kritischer Service-Pfad mit durchgesetztem mTLS (inkl. beidseitiger Prüfung).
• Scope-Hygiene: Anteil Service-Konten mit minimalen Rechten (keine Wildcards, keine Admin-All).
• Leak/Find-Rate: Anzahl gefundener Secrets pro Monat und Zeit bis Entzug/Rotation.

Anti-Pattern

• „Technisch nötig“ als Ausrede für Dauerrechte – nein. Belegt den Zwang, befristet, kompensiert das Risiko.
• „mTLS später“ – später heißt nie. Ohne beidseitige Prüfung ist „internes“ Netzwerk ein offenes Feld.
• „Nur Dev-Umgebung“ – Angreifer lieben Dev: echte Datenmodelle, echte Keys, wenig Monitoring.
• „Wir loggen nicht – Datenschutz“ – Datenschutz ist kein Logging-Verbot. Protokolliert sparsam, aber prüfbar.

Praxis-Checkliste

• Secrets-Scanning in allen Repos/CI-Pipelines erzwingen; Fail-Build bei Fund.
• Zentraler Secrets-Store mit Secrets-Rotation und kurzlebigen Ausleihen (Just-in-Time für Dienste).
• mTLS Pflicht für interne Services; automatische Zertifikatsvergabe/-verlängerung.
• Rechte-Review für Service-Konten: Scopes minimieren, Ablaufdaten setzen, Owner benennen.
• Telemetrie-Pflicht: Nutzung je Identität korrelieren; Auto-Revoke bei Anomalie.
• Löschdisziplin: Unbenutzte Maschinenidentitäten entfernen – monatlicher Takt.

Fazit: Identität ist mehr als Mensch

Wer nur Benutzer härten will, baut die Haustür aus Stahl – und lässt die Seitentür offen. Maschinenidentitäten sind heute die realistische Angriffsroute Nummer eins: leise, skalierbar, oft ohne Alarm. Mit kurzlebigen Credentials, strikten Scopes, verpflichtendem mTLS, gelebter Secrets-Rotation und belastbaren KPIs wird aus Bauchgefühl kontrollierte Sicherheit. Alles andere ist teure Hoffnung.

FAQ zum Blogbeitrag