Warum Non-Human Identities zur Top-Bedrohung werden

Maschinen-Identitäten – also Zugangsdaten, die nicht zu Menschen gehören – treiben heute die Automatisierung in der Cloud: CI/CD-Pipelines, Microservices, Bots und APIs. Genau diese API-Keys und Access Tokens sind jedoch zum attraktiven Angriffsziel geworden. Sie umgehen multifaktorbasierte Logins, arbeiten rund um die Uhr und fallen in vielen SIEM-Regeln durch das Raster. Für Cyberkriminelle sind sie die perfekte Eintrittskarte – ob für Credential Stuffing, laterale Bewegungen oder zur Vorbereitung von Ransomware-Erpressungen.

Im aktuellen Security-Kontext – geprägt von Cloud-First-Strategien, Zero-Trust-Initiativen und komplexen Software-Lieferketten – wächst die Angriffsfläche rapide. Während Unternehmen in Security Awareness investieren, bleibt der Schutz nicht-menschlicher Identitäten häufig zurück. Das Risiko: Ein kleiner Token-Leak auf GitHub verwandelt sich in einen großflächigen Cloud-Breach.

Wie Angreifer Maschinen-Credentials missbrauchen

Der typische Ablauf ist unspektakulär – und genau darin liegt die Gefahr. Ein API-Schlüssel landet versehentlich im Code-Commit, in einem Container-Image oder in Logfiles. Automatisierte Crawler finden den Schlüssel, testen ihn und beginnen, Ressourcen zu inventarisieren. Ohne MFA-Barriere und mit weitreichenden Rechten ist der Zugang Gold wert.

Leise Persistenz und seitliche Bewegung

Statt sofort Daten zu exfiltrieren, richten professionelle Angreifer zunächst Persistenz ein: zusätzliche Service-Accounts, neue Zugriffsrichtlinien oder verdeckte Webhooks. Von dort aus bewegen sie sich seitlich – etwa von einem Storage-Bucket zu einer CI/CD-Umgebung und weiter zu Produktionsdatenbanken. Diese schrittweise Ausbreitung bleibt oft unentdeckt, weil die Aktivitäten in den legitimen „Maschinenrauschen“ fallen. Erkennung wird dadurch zur Königsdisziplin der IT-Sicherheit.

Supply-Chain- und CI/CD-Angriffe

Ein kompromittierter Build-Token kann die gesamte Software-Lieferkette gefährden. Angreifer injizieren schädliche Abhängigkeiten, manipulieren Artefakte oder stehlen Signier-Schlüssel. Das Ergebnis sind Breaches, die als legitime Updates erscheinen – ein Traum für Phishing-Kampagnen und eine potente Vorstufe für Ransomware. Mehr Hintergründe findest du in unserem Beitrag Zero Trust in der Praxis.

Erkennung und Metriken: Was du sehen musst

Identity-First Security heißt: Du erkennst Anomalien auf Identitäts- und Token-Ebene, nicht nur auf Netzwerkebene. Hilfreiche Signale sind:

• Ungewöhnliche Nutzungsmuster: neue Regionen, Uhrzeiten, plötzlich erhöhte API-Rate, zuvor ungenutzte Dienste
• Kontext-Mismatches: Token wird aus dem Internet genutzt, obwohl er nur intern vorgesehen war; Zugriff ohne erwartete IP-Range
• Policy-Drifts: Rollenänderungen, die Maschinenkonten unerwartet mehr Rechte geben
• Token-Langlebigkeit: lang laufende, nie rotierte Geheimnisse, die Zugriff über Release-Zyklen hinweg erlauben

Baue detections, die speziell auf Non-Human Identities zugeschnitten sind: „Impossible Travel“ für Services (Region-Hopping), behavioral baselines pro Workload und Alarmierung bei Zugriffen über Public IPs. Eine Checkliste für Cloud-Logging und Detection findest du in unserem Beitrag Cloud Security Checklist.

Schutzmaßnahmen: Von Policy bis Technik

Der wirksame Schutz vor geleakten Maschinen-IDs ist eine Kombination aus Architektur, Prozessen und Tools. Die folgenden Maßnahmen adressieren die größten Risiken – von Secret Management bis Zero-Day-Resilienz.

Geheimnis-Management und Rotation

• Short-lived Credentials: Setze auf kurzlebige, dyanmische Tokens (z. B. STS, OIDC-Federation), statt statischer Schlüssel.
• Zentrale Secret Stores: Verwende dedizierte Tresore (z. B. Cloud Secret Manager), niemals .env-Dateien im Repo.
• Automatisierte Rotation: Erzwinge regelmäßige Schlüsselrotation über Pipelines – kein manuelles Ticketing.
• „No Secrets in Code“: Serverseitige Konfiguration statt Build-Time-Embedding. Unterstütze Teams mit Trainings und Simulationen, um Leaks zu verhindern.

Identity-First Zero Trust für Workloads

• Least Privilege für Maschinen: Trenne Rollen nach Umgebung (Dev/Stage/Prod), setze resource-level Policies.
• Conditional Access für Services: Binde Tokens an erwartete IDS, Namespaces, IP-Ranges oder attestation-basierte Nachweise.
• Workload Identity Federation: Vermeide gespeicherte Schlüssel, nutze Identitätsableitung aus Runtime (Kubernetes SA, AWS/GCP/Azure-Metadaten).

Härtung von CI/CD und Cloud

• Secrets-Scanning: Scanne Commits, Container-Images und Artefakte vor dem Merge/Release. Blockiere Builds bei Funden.
• SBOM & Signaturen: Erzeuge SBOMs, signiere Artefakte (z. B. Sigstore) und prüfe sie in der Deployment-Phase.
• Isolierte Runner: Nutze kurzlebige Build-Runner, restriktive Netzpolitik und keinen ausgehenden Internetzugang, wo möglich.
• Monitoring-by-Default: Aktiviere Cloud-native Audit-Logs, API-Logging und service account-spezifische Alerts.
• Vorfall-Playbooks: Definiere Runbooks für Token-Leaks: Revoke, Rotate, Re-issue, Scope prüfen, forensische Auswertung. Siehe auch unser Ransomware-Playbook.

Beispiel aus der Praxis: Ein kleiner Token, großer Schaden

Ein mittelständisches SaaS-Unternehmen verlor durch einen versehentlich mitgeführten Test-Token in einem öffentlichen Repo die Kontrolle über mehrere Cloud-Ressourcen. Innerhalb von 20 Minuten nutzten Angreifer den Token, um zusätzliche Service-Keys zu erstellen und Datenbestände zu inventarisieren. Die Persistenz blieb zunächst unentdeckt, weil das SIEM den Traffic als legitimen CI/CD-Flow wertete. Erst die Korrelation von „neuer Region + erhöhte API-Rate + Policy-Drift“ führte zur Erkennung. Die Lessons Learned: Token-Laufzeit auf 1 Stunde begrenzen, pre-commit-Scanning erzwingen, Conditional Access für Service-Accounts aktivieren und Build-Runner isolieren.

Pro und Contra: Automatisiertes Secrets-Scanning

• Pro: Frühzeitige Erkennung verhindert Breaches; geringe Hürde in Dev-Workflows; schnelle Risikoreduktion für Cloud- und API-Sicherheit.
• Pro: Compliance-Unterstützung (z. B. ISO 27001, SOC 2) und bessere Nachvollziehbarkeit in Audits.
• Contra: False Positives können Teams ermüden – gutes Tuning und Developer-Schulungen sind entscheidend.
• Contra: Scanning alleine reicht nicht: Ohne Rotation, Least Privilege und Monitoring bleiben Lücken bestehen.

Handlungsempfehlungen für deine Sicherheitsstrategie

1. Führe ein Inventar aller Maschinen-Identitäten, inklusive Besitzern, Scope und Rotationsterminen.
2. Etabliere kurzlebige, attestierte Tokens (OIDC/ST S) und verbanne langfristige statische Schlüssel.
3. Implementiere unternehmensweite Secrets-Policies mit Pre-Commit-, CI- und Registry-Scanning.
4. Baue detections für Workload-Identitäten und teste sie regelmäßig in Purple-Team-Übungen.
5. Schule Teams mit fokussierten Security-Awareness-Trainings zu Secret-Hygiene und Datenklassifizierung.
6. Verankere Zero Trust für Services: Conditional Access, Netzsegmentierung und minimal erforderliche Rechte. Siehe Zero-Trust-Guide.

Fazit: Jetzt handeln, bevor der nächste Token leakt

Non-Human Identities sind der unsichtbare Dreh- und Angelpunkt moderner Cloud-Sicherheit. Wenn API-Keys und Tokens in fremde Hände geraten, ist der Weg zu Datendiebstahl, Ransomware oder Lieferketten-Manipulationen kurz. Die gute Nachricht: Mit kurzlebigen Identitäten, konsequentem Secret-Management, Zero-Trust-Prinzipien und wirksamen Detections lässt sich das Risiko drastisch reduzieren.

Starte heute: Prüfe deine Pipelines, aktiviere automatisiertes Scanning, verkürze Token-Laufzeiten und trainiere deine Teams. Weitere vertiefende Inhalte findest du in unserem Security-Blogarchiv und in den Leitfäden zu Cloud-Sicherheit und Zero Trust.