9.300 geleakte AWS-Schlüssel waren Jahre später noch gültig

Öffentlich geleakte AWS-Zugangsdaten sind offenbar häufig keine kurzlebigen Pannen. Eine von Truffle Security durchgeführte Untersuchung von August 2022 bis August 2026 zeigt, dass viele Schlüssel noch Jahre später gültig waren – teils mit ausreichenden Rechten, um Unternehmenskonten vollständig zu übernehmen.

Die zentrale Erkenntnis: Aus einem Leak wurde oft ein Dauerproblem

Truffle Security sammelte 431.875 Vorkommen von AWS-Secrets aus öffentlichen Quellcode-Repositorien, Git-Verläufen, Datensätzen, Docker-Images, Container-Registries und Protokollen aus Continuous-Integration-Systemen. Nach dem Entfernen von Duplikaten entsprach der Datensatz 64.024 eindeutigen AWS-Zugangsschlüsseln, die mit 50.654 AWS-Konten verbunden waren.

Die Forschenden konnten 10.616 vollständige Schlüsselpaare überprüfen. Bei einem erneuten Test am 10. August authentifizierten sich 88 Prozent weiterhin. Damit blieben mehr als 9.300 öffentlich geleakte Schlüssel nutzbar.

Ein Eintrag in einem öffentlichen Repository bedeutet zwar nicht automatisch, dass ein Schlüssel noch gefährlich ist. Zum akuten Risiko wird er, wenn er nicht widerrufen wurde, weiterhin eine Anmeldung ermöglicht und relevante Berechtigungen besitzt. In dieser Untersuchung trafen diese drei Bedingungen häufig zusammen.

Hunderte Unternehmensschlüssel ermöglichten volle Kontrolle

Von den noch aktiven Schlüsseln, die Unternehmenskonten zugeordnet wurden, entfielen 817 auf Firmen. Darunter waren:

• 526 Schlüssel von AWS-Root-Konten
• 242 Schlüssel von IAM-Nutzern mit der AWS-Richtlinie AdministratorAccess
• insgesamt 768 Schlüssel, die vollständige Administratorrechte über ein AWS-Konto eines Unternehmens ermöglichten

Root-Zugangsdaten bieten AWS-Kunden die höchste verfügbare Kontrollebene. Eine IAM-Identität mit AdministratorAccess kann mit weitreichenden Rechten auf AWS-Dienste zugreifen. Ein gültiger Schlüssel auf einer dieser Ebenen kann daher die Übernahme eines Kontos, unbefugten Datenzugriff, das Anlegen eigener Ressourcen oder missbräuchlich steigende Cloud-Rechnungen ermöglichen.

Die Ergebnisse zeigen somit nicht nur ein Problem beim Umgang mit Quellcode, sondern auch beim Berechtigungs- und Lebenszyklusmanagement. Einen Schlüssel aus einer sichtbaren Datei zu entfernen, schützt ein Konto nicht, wenn jemand die Zugangsdaten bereits kopiert hat. Der Schlüssel muss widerrufen oder ersetzt werden.

Hugging Face war die größte einzelne Fundstelle

Auf Hugging Face wurden 8.482 AWS-Zugangsdaten gefunden – mehr als an jeder anderen einzelnen Quelle. Laut Truffle Security waren 17,9 Prozent dieser AWS-Zugangsdaten Root-Credentials.

Der Befund steht im Zusammenhang mit einem umfassenderen Scan öffentlicher Hugging-Face-Daten. Truffle Security erklärte, 7,6 Petabyte an Datensätzen untersucht und in Tausenden Datensätzen aktive Zugangsdaten gefunden zu haben. Das zeigt, dass Geheimnisse nicht nur in klassischen Software-Repositorien fortbestehen, sondern auch in öffentlich verteilten Daten landen können.

Für Sicherheitsteams bedeutet das: Ein Scan des aktuellen Quellcodes reicht nicht aus. Git-Historien, Build-Artefakte, Container-Images, Registries, veröffentlichte Datensätze und CI-Ausgaben können Zugangsdaten weiterhin enthalten, selbst wenn Entwickler sie längst entfernt glauben.

Viele Schlüssel waren Jahre alt und kaum rotiert

Das gemeldete Medianalter der Zugangsdaten lag bei etwa 1.831 Tagen – also bei rund fünf Jahren. Der älteste Schlüssel war 17,4 Jahre alt. Nur 13,7 Prozent der Einträge hatten einen neueren, demselben Nutzer zugeordneten Schlüssel. Das deutet darauf hin, dass die meisten Zugangsdaten nicht im Rahmen eines regulären Prozesses ausgetauscht worden waren.

Langlebige Zugriffsschlüssel vergrößern das Zeitfenster für eine unbefugte Nutzung und erschweren die Zuordnung zu einem Verantwortlichen. Sie können Personalwechsel, Anwendungsumzüge, Bereinigungen von Repositorien und Änderungen bei Zuständigkeiten überdauern.

Das Alter eines Schlüssels sollte deshalb als Risikosignal gelten. Ein öffentlich gewordener Schlüssel ist nicht automatisch harmlos, nur weil er mehrere Jahre alt ist. Unternehmen sollten seine Gültigkeit prüfen, ihn widerrufen und den möglichen Missbrauch untersuchen – es sei denn, sie können eindeutig belegen, dass er nicht mehr funktioniert.

Budget-Warnungen waren die Ausnahme

Truffle Security konnte Kontoinformationen von 2.754 AWS-Konten auslesen. Nur 262 davon hatten Budget-Warnungen aktiviert.

Budget-Warnungen ersetzen weder den Widerruf von Zugangsdaten noch eine Erkennung von Angriffen. Sie können aber frühzeitig auf ungewöhnlich hohe Ausgaben hinweisen, etwa wenn Angreifer Ressourcen für Kryptomining anlegen oder eine Cloud-Umgebung anderweitig missbrauchen. Ohne einen Benachrichtigungsweg, der die zuständigen und handlungsfähigen Personen erreicht, können solche Kosten weiterlaufen, nachdem ein Konto kompromittiert wurde.

Was AWS-Benachrichtigungen leisten – und was nicht

Laut der Berichterstattung können die Schutzmechanismen von AWS offengelegte Zugriffsschlüssel erkennen, betroffene Kunden benachrichtigen und Einschränkungen oder Quarantänemaßnahmen anwenden. Die weiterhin gültigen Testschlüssel zeigen jedoch, dass eine Erkennung oder Benachrichtigung nicht zuverlässig zu einer schnellen Sperrung oder Rotation durch die Kunden führte.

Die Erkennung ist nur der erste Schritt. Eine vollständige Reaktion muss den Besitzer identifizieren, die Reichweite und Berechtigungen des Schlüssels bestimmen, mögliche missbräuchliche Nutzung prüfen und die Zugangsdaten anschließend ungültig machen. Truffle Security beschreibt die eigene Validierung als schreibgeschützt: Geprüft wurden Authentifizierung sowie Berechtigungs- und Kontometadaten, ohne Ressourcen von Kunden zu verändern. Diese Darstellung stammt von Truffle Security; nicht jedes Detail der Methode lässt sich anhand aller hier vorliegenden Quellen unabhängig bestätigen.

Was Unternehmen nach einem AWS-Leak tun sollten

1. Schlüssel sofort widerrufen oder ersetzen

Deaktivieren oder löschen Sie jede öffentlich zugängliche Zugangsdaten und stellen Sie nur dann Ersatz aus, wenn der Zugriff weiterhin benötigt wird. Das Löschen einer Datei aus einem Repository oder das Umschreiben der Git-Historie macht bereits kopierte Zugangsdaten nicht ungültig.

2. Root-Zugriffsschlüssel abschaffen

AWS-Root-Zugangsschlüssel sollten nicht für den alltäglichen programmatischen Zugriff verwendet werden. Löschen Sie Root-Schlüssel und verlagern Sie Workloads auf kontrollierte Identitäten mit möglichst eng gefassten Berechtigungen.

3. Berechtigungen und Verantwortliche prüfen

Klären Sie, zu welchem Konto, Nutzer, Dienst und welchen Ressourcen die Zugangsdaten gehörten. Priorität haben Schlüssel mit Root-Rechten, AdministratorAccess, weitreichendem Datenzugriff oder der Möglichkeit, Infrastruktur anzulegen.

4. Nutzung vor und nach der Sperrung untersuchen

Prüfen Sie Authentifizierungsaktivitäten, CloudTrail-Protokolle, Änderungen an IAM, neu angelegte Ressourcen und Abrechnungsdaten auf verdächtige Vorgänge. Der Widerruf verhindert die weitere Nutzung des geleakten Schlüssels, zeigt aber nicht, ob er zuvor bereits missbraucht wurde.

5. Dauerhafte Schlüssel durch kurzlebige Identitäten ersetzen

Verwenden Sie nach Möglichkeit kurzlebige IAM-Rollen und Workload-Identitäten statt dauerhaft gültiger Zugriffsschlüssel. Das Prinzip der geringsten Berechtigung begrenzt den Schaden, den ein gestohlenes Secret anrichten kann.

6. Budget-Warnungen und einen Reaktionsweg einrichten

Konfigurieren Sie AWS-Budgets-Warnungen und die Überwachung von Kostenanomalien. Die Benachrichtigungen sollten Personen erreichen, die schnell handeln können. Finanzielle Überwachung ist jedoch nur ein Auffangnetz – kein Ersatz für Secret-Scanning, Schlüsselrotation und regelmäßige Zugriffsprüfungen.

Die übergeordnete Lehre

Die wichtigste Erkenntnis der Untersuchung ist nicht allein die Zahl der gefundenen Secrets. Entscheidend ist die Kombination aus öffentlicher Zugänglichkeit, fortbestehender Gültigkeit, hohen Berechtigungen, extremem Alter und schwacher Überwachung. Öffentliche Datenspeicher können Zugangsdaten bewahren, lange nachdem ein Unternehmen vergessen hat, wo sie eingesetzt wurden. Ein kopierter Schlüssel bleibt nutzbar, bis er ausdrücklich widerrufen wird.

Für Cloud-Teams ist deshalb eine klare Grundregel sinnvoll: Behandeln Sie jedes offengelegte AWS-Secret als kompromittiert, prüfen Sie seine Reichweite, widerrufen oder ersetzen Sie es sofort und stellen Sie langfristig auf kurzlebige Identitäten mit minimalen Berechtigungen um.