Das Problem: 100:1 und niemand sieht es

Während Sie diesen Satz lesen, laufen in Ihrer AWS-Umgebung vermutlich tausende Identitäten, die keinem Menschen gehören. Kaum jemand hat sie im Blick und genau das macht sie gefährlich.

Service Accounts, API Keys, Workload Identities, CI/CD-Credentials, AI-Agent-Tokens: Laut dem Identity Security Outlook 2026 von ManageEngine berichten Organisationen von Machine-to-Human-Verhältnissen von 100:1, in einzelnen Branchen bis zu 500:1.

Das ist an sich kein Sicherheitsproblem. Zum Problem wird es, weil diese Non-Human Identities (NHIs) selten sauber erfasst sind: keine durchgängige IAM-Governance, keine automatische Rotation, kaum Monitoring. Kompromittiert ein Angreifer eine davon, hat er im schlimmsten Fall einen Generalschlüssel zur gesamten Cloud-Infrastruktur.

Die Zahlen dahinter

Der 2025 State of Non-Human Identities and Secrets in Cybersecurity-Report von Entro Security liefert ein konkretes Bild der Praxis in Unternehmen:

Dazu kommt: 44 % aller Tokens sind irgendwo im Klartext auffindbar — in Teams-Chats, Jira-Tickets, Confluence-Seiten oder Code-Commits. 60 % der NHIs werden von mehr als einer Anwendung gemeinsam genutzt, was jede einzelne zu einem Single Point of Failure macht. Und 71 % werden nicht innerhalb empfohlener Fristen rotiert.

Das klassische Muster dahinter: Ein Entwickler braucht eine Lambda-Funktion, die ein S3-Bucket lesen soll. Unter Zeitdruck wird AdministratorAccess angehängt. Die Funktion läuft und niemand geht später zurück, um die Rechte zu verschlanken.

Wie ein realer Vorfall das Risiko zeigt

Im März 2026 wurde Trivy, ein bei Zehntausenden CI/CD-Pipelines eingesetzter Open-Source-Vulnerability-Scanner von Aqua Security, selbst zum Angriffsvektor (CVE-2026-33634). Angreifer verschafften sich Schreibzugriff auf das trivy-action-Repository und verschoben rückwirkend 76 von 77 Versions-Tags auf manipulierte Commits, die einen mehrstufigen Credential-Stealer nachluden. Jede Pipeline, die die Action über ein Tag statt über einen gepinnten Commit-Hash referenzierte, zog beim nächsten Lauf automatisch die kompromittierte Version.

Bemerkenswert: Es handelte sich um den zweiten Vorfall in dieser Kette. Nach einem ersten Vorfall Ende Februar 2026 wurden zwar Credentials rotiert - aber nicht atomar, sodass die Angreifer das Rotationsfenster nutzen konnten, um weiterhin gültige Tokens abzugreifen.

Der Fall zeigt zwei Dinge auf einmal: Wie leicht sich Vertrauen in der Software-Lieferkette missbrauchen lässt, sobald mutable Tags statt gepinnter Commit-Hashes verwendet werden und wie wenig eine einzelne Rotationsrunde bringt, wenn sie nicht vollständig und gleichzeitig für alle betroffenen Secrets erfolgt.

AWS Best Practices: Von statischen Keys zu Workload Identity

AWS bietet die nötigen Werkzeuge dafür - sie werden nur selten konsequent eingesetzt.

IAM Roles statt Access Keys

Grundregel: keine langlebigen IAM Access Keys für Workloads. Stattdessen Instance Profiles für EC2, Execution Roles für Lambda, Task IAM Roles für ECS und IAM Roles for Service Accounts (IRSA) für EKS-Pods. Diese liefern über den AWS Security Token Service (STS) temporäre, automatisch rotierende Credentials. Ein statischer Key, der nie abläuft, ist das Wertvollste, das ein Angreifer stehlen kann.

IRSA für Kubernetes

Wer EKS betreibt, kommt an IRSA praktisch nicht vorbei. IRSA koppelt Kubernetes Service Accounts über OIDC-Föderation an IAM Roles. Pods erhalten so temporäre AWS-Credentials, ohne dass Secrets in ConfigMaps landen.

AWS Secrets Manager mit automatischer Rotation

Für Secrets, die sich nicht vermeiden lassen - Datenbank-Passwörter, Drittanbieter-API-Keys - gehört AWS Secrets Manager statt Environment Variables oder Config-Dateien eingesetzt, mit konfigurierter automatischer Rotation, die on-demand oder nach Zeitplan läuft, ohne laufende Anwendungen zu unterbrechen.

Cloud Infrastructure Entitlement Management (CIEM)

CIEM wird 2026 zum Pflichtprogramm. Tools wie AWS IAM Access Analyzer, Microsoft Defender for Cloud oder Palo Alto Cortex Cloud inventarisieren jede menschliche und nicht-menschliche Identität, berechnen die tatsächlich genutzten Permissions und markieren riskanten Standing Access. IAM Access Analyzer zeigt konkret, welche Rechte wirklich in Anspruch genommen werden - darauf lassen sich Policies rightsizen, statt sie nach Bauchgefühl zu vergeben.

Ein praktischer 30-Tage-Plan

Was Sie jetzt tun sollten

Beginnen Sie mit einer einfachen Frage: Wie viele Service Accounts haben Sie eigentlich? Wenn Sie es nicht wissen, ist das Ihr erstes Projekt. Führen Sie danach einen IAM-Access-Analyzer-Bericht durch und sehen Sie sich die Lücke zwischen vergebenen und tatsächlich genutzten Rechten an - diese Lücke ist Ihre Angriffsfläche. Der nächste Schritt ist dann die Migration zu temporären, automatisch rotierten Credentials. Kein Nice-to-have mehr, sondern Grundvoraussetzung.