{"schema_version":"1.0","service":"Publicasta","type":"article","id":391,"slug":"leaked_aws_keys_quarantine_cloud_security_checklist_2026","title":"Ein geleakter AWS-Schlüssel bleibt Zugriff, bis er rotiert und gelöscht ist","excerpt":"Truffle Security prüfte tausende AWS-Schlüssel erneut, die bereits in öffentlichen Artefakten standen. Beunruhigend ist nicht nur das Leck: Viele funktionierten Jahre später noch, auch Root- und AdministratorAccess-Schlüssel.","language":"de","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de","image":{"url":"https://publicasta.com/storage/projects/9/pages/391/2026/08/ea74d13c-c357-428a-a970-c2bec00446cc.webp","alt":"Abstrakte Cloud-Konsole mit exponiertem Schlüssel, Quarantäneband und Rotationscheckliste"},"publisher":{"id":9,"slug":"cybersecurity","name":"Cybersicherheit ohne Panik","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-08-23T17:27:32+00:00","updated_at":"2026-08-23T17:27:32+00:00","content_markdown":"Ein geleakter Cloud-Schlüssel ist kein vergangenes Ereignis. Er ist ein aktiver Login, bis jemand das Gegenteil beweist, ihn rotiert, löscht und prüft, was er erreichen konnte. Genau das macht die Untersuchung von Truffle Security aus dem August 2026 wichtig: Gefährlich war nicht nur die Veröffentlichung von AWS credentials, sondern ihr langes Leben danach.\n\n ![Abstrakte Cloud-Konsole mit exponiertem Schlüssel, Quarantäneband und Rotationscheckliste](https://publicasta.com/storage/projects/9/pages/391/2026/08/ea74d13c-c357-428a-a970-c2bec00446cc.webp)\n\n Truffle Security meldete 431.875 verifizierte AWS-Secret-Funde, verdichtet auf 64.024 eindeutige access keys in 50.654 Konten. Danach wurden 10.616 vollständige Schlüsselpaarungen erneut geprüft, die zwischen August 2022 und August 2026 öffentlich aufgetaucht waren. 88% authentifizierten weiterhin. Von 9.308 aktiven Schlüsseln waren 817 geschäftsbezogen; 768 gaben volle Kontrolle über ein AWS-Konto: 526 Root-Schlüssel und 242 IAM-User mit AdministratorAccess.\n\n BleepingComputer, The Register, TNW und andere griffen die Geschichte auf. Corey Quinn fokussierte in The Register auf AWSCompromisedKeyQuarantineV3. AWS beschreibt diese verwaltete Policy als Schutz gegen bestimmte Betrugsfolgen, ohne bestehende Ressourcen zu beeinträchtigen. Quinns Punkt: Quarantäne ist keine Behebung. Sie kann offensichtlichen Missbrauch begrenzen und trotzdem genug Restzugriff lassen.\n\n Das ist Cybersicherheit ohne Panik, weil die Antwort nüchtern ist. Root access keys sollten fast nie existieren. Langlebige IAM access keys brauchen Besitzer, Ablaufdatum und Rotation. Ein Secret in Git history, Docker image, CI log, Notebook oder Dataset ist veröffentlicht. Eine Quarantäne-Policy ist der Start eines Incidents, nicht dessen Ende.\n\n ## Was gefunden wurde\n\n Die große Zahl 431.875 enthält Wiederholungen in Forks, Mirrors, Logs, Images und Datasets. Wichtiger sind die deduplizierten 64.024 Schlüssel und die 10.616 vollständigen Paare, die Truffle Security am 10. August 2026 erneut prüfen konnte. 9.308 funktionierten.\n\n Der geschäftliche Teil ist kleiner, aber härter. 817 aktive Keys waren Unternehmen zuordenbar, 768 hatten vollständige administrative Kontrolle. Besonders kritisch sind 130 lebende Root-Schlüssel auf Organization-Management-Accounts. Das ist nicht nur ein vergessener Entwickler-Secret, sondern potenziell der Generalschlüssel für eine Cloud-Organisation.\n\n Das Alter macht es schlimmer. Der Median eines noch aktiven geleakten Schlüssels lag bei 1.831 Tagen. Viele Credentials waren also jahrelang öffentlich. Nur 13,7% der untersuchten Fälle hatten einen neueren Key neben dem geleakten. Das deutet nicht auf Rotation, sondern auf Weiterbetrieb hin.\n\n Hugging Face tauchte als große Quelle exponierter Keys in öffentlichen Datasets auf. Das sollte nicht als neuer Hugging-Face-Breach gelesen werden. Es zeigt, dass ML-Datasets, Notebooks und Modell-Repositories das alte Softwareproblem erben: Menschen veröffentlichen Artefakte, in denen manchmal Credentials stehen.\n\n ## Warum Root anders ist\n\n Ein IAM-Key kann gefährlich sein. Ein Root-Key ist schlimmer. Der Root-User repräsentiert das AWS-Konto selbst. AWS empfiehlt, Root-Credentials zu schützen, Root nicht im Alltag zu nutzen und IAM Identity Center, Rollen und temporäre Credentials einzusetzen.\n\n Der Unterschied ist der Scope. IAM-Identitäten lassen sich über Berechtigungen, Bedingungen und Organizations begrenzen. Root steht über vielem davon. Wenn ein Root-Key leakt, geht es um Abrechnung, Kontoeinstellungen, Wiederherstellungspfade und manchmal den Management-Account der Organisation.\n\n Root-Schlüssel überleben auch Besitzer. Ingenieure wechseln, Auftragnehmer gehen, alte Automatisierung nutzt weiter den einen Key, der 2021 funktionierte. Niemand will ihn anfassen, weil Produktion brechen könnte. Genau deshalb ist er gefährlich.\n\n Ein reifes Cloud-Programm muss wissen: Gibt es Root access keys? Wer hat sie genehmigt? Wann verschwinden sie? Ohne Antwort gibt es keine Kontrolle.\n\n ## Eine Zeile zu löschen reicht nicht\n\n Wenn ein Credential ein öffentliches Artefakt erreicht, muss es als kopiert gelten. Das Entfernen aus dem letzten Git-Commit löscht nicht die Historie. Ein geschlossenes Repository löscht keine Forks, Mirrors, Caches, Docker-Layer, CI-Logs, Notebooks, Suchindizes oder Datasets.\n\n Ein geleakter AWS-Key ist daher wie ein veröffentlichtes Passwort zu behandeln. Rotieren oder löschen, Nutzung prüfen, abhängige Workloads identifizieren, Aktivität untersuchen. Bei Root oder AdministratorAccess gehören CloudTrail, Billing, Secret-Inventar und Suche nach Persistenz dazu.\n\n Viele Entwickler lernen aus Secret-Scanning-Alarmen: “Ich habe die Zeile entfernt.” Die richtige Lektion lautet: “Die Zeile hat ein Credential offengelegt, das ersetzt werden muss.” Das ist der Unterschied zwischen Kosmetik und Zugriffsentzug.\n\n Docker-Images und ML-Datasets erschweren das. Ein Key kann in einem alten Image-Layer, einer Notebook-Ausgabe, einem Debug-Log, einem Benchmark-Korpus oder einer ZIP-Datei liegen. Secret Management muss mehr als Repositories scannen.\n\n ## Was AWS-Quarantäne bedeutet\n\n AWSCompromisedKeyQuarantineV3 ist eine AWS Managed Policy. Die Dokumentation sagt, sie werde bei kompromittierten oder öffentlich exponierten IAM-Credentials genutzt und verweigere bestimmte Aktionen, um Betrugsschäden zu begrenzen, ohne bestehende Ressourcen zu beeinträchtigen.\n\n Diese letzte Einschränkung ist entscheidend. Quarantäne ist Risikominderung, nicht Sanierung. Ein quarantined key bleibt ein Incident-Signal. Er beweist nicht, dass das Konto sicher ist. Wenn bestehende Ressourcen geschont werden, können bestehende Pfade weiter funktionieren.\n\n Quinns Kritik betrifft genau dieses Restrisiko: Datenbankaktionen, Systems-Management-Sessions, AssumeRole, Audit-Log-Störungen, Messaging-Missbrauch, Secret-Zugriff, Backups und Infrastrukturänderungen. Man muss daraus kein Angriffshandbuch machen. Für Verteidiger reicht: Quarantine is a temporary guardrail, not incident closure.\n\n Das Dilemma ist real. Automatisches Abschalten jedes öffentlichen Keys kann Kundenproduktion brechen. Weiteres Authentifizieren vermeidet Outages, hält aber Exposure. Deshalb brauchen Organisationen ein eigenes Playbook.\n\n ## Was heute zu prüfen ist\n\n Beginnen Sie mit Root. Prüfen Sie jedes AWS-Konto auf root access keys. Falls vorhanden: Grund, Besitzer, letzter Gebrauch, Löschdatum. Für die meisten Unternehmen ist der Zielzustand: keine Root-Keys, Root mit MFA und nur für seltene echte Root-Aufgaben.\n\n Inventarisieren Sie IAM access keys. Sortieren Sie nach Alter, Last-used, Besitzer, Workload und Berechtigung. AdministratorAccess, Wildcards, kein Besitzer, keine Rotation oder kein aktueller Gebrauch sind hohe Priorität.\n\n Suchen Sie nach AWSCompromisedKeyQuarantine-Anhängen. Wenn AWS Quarantäne gesetzt hat, ist das ein Incident-Signal. Finden, rotieren, löschen, CloudTrail prüfen, Billing und Budget-Anomalien ansehen, AssumeRole-Pfade kontrollieren.\n\n Scannen Sie mehr als Code: Git history, Forks, Registries, Container-Images, Build-Logs, CI-Variablen, Notebooks, Support-Bundles, öffentliche Datasets und Modell-Repositories. Secrets leben heute auch in Datenartefakten.\n\n Ersetzen Sie statische Credentials. CI/CD sollte OIDC federation und kurzlebige Rollen nutzen. Menschen sollten IAM Identity Center oder Federation nutzen. Workloads sollten Rollen mit engem Scope verwenden. Legacy-Keys brauchen Owner, Ablauf und Monitoring.\n\n ## Ohne Produktionsbruch rotieren\n\n Viele geleakte Keys bleiben aktiv aus Angst vor Outage. Diese Angst ist nachvollziehbar: Löschen kann Builds, Backups, Pipelines oder alte Services brechen. Die Antwort ist Rotation mit Belegen.\n\n Identifizieren Sie Principal und zuletzt genutzte Services. CloudTrail, last accessed data, App-Logs und Kostenanomalien helfen. Danach Besitzer finden, Ersatz mit engeren Rechten bauen, überwacht ausrollen und alten Key löschen. Wenn Löschung warten muss, braucht es eine befristete Ausnahme mit Owner.\n\n Bei Root und AdministratorAccess sollte man möglichen Fremdzugriff annehmen: API-Aktivität, Secret-Zugriffe, AssumeRole, IAM-Änderungen, Bucket-Policies, Backups und ungewöhnliche Kosten prüfen. Budget alerts und anomaly detection gehören dazu.\n\n Das Ziel ist geübte Rotation vor dem Notfall. Teams mit Ownern und Mustern reagieren in Stunden. Teams ohne Ownership verhandeln wochenlang mit einem kompromittierten Schlüssel.\n\n ## Ruhiges Fazit\n\n Die Studie bedeutet nicht, dass jedes AWS-Konto kompromittiert ist. Sie bedeutet auch nicht, dass AWS-Quarantäne nutzlos ist oder man wahllos Keys löschen sollte. Panik bricht Produktion; Verdrängung schafft Breaches.\n\n Die passende Reaktion: jedes öffentliche Credential als kompromittiert behandeln, Root-Keys entfernen, langlebige IAM-Keys durch Rollen und Federation ersetzen, reale Artefakte scannen, auf Quarantäne reagieren, Rotation üben und Budgetalarme aktivieren.\n\n Der unangenehme Teil ist leise: Ein Key leakt, ein Scanner meldet, der Provider begrenzt einiges, jemand löscht eine Zeile, alle gehen weiter. Aber das Credential authentifiziert noch. Das löst man mit Ownership, Inventory, short-lived credentials and operational discipline.","available_translations":[{"language":"ar","title":"مفتاح AWS المسرّب يبقى وصولاً فعلياً حتى يُدار ويُحذف","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ar"},{"language":"de","title":"Ein geleakter AWS-Schlüssel bleibt Zugriff, bis er rotiert und gelöscht ist","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=de","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de"},{"language":"en","title":"Leaked AWS keys are still working because rotation is the missing control","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=en","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=en","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=en"},{"language":"es","title":"Una clave AWS filtrada sigue siendo acceso hasta que se rota y se borra","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=es","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=es","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=es"},{"language":"fr","title":"Une clé AWS exposée reste un accès tant qu’elle n’est pas supprimée","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=fr"},{"language":"pl","title":"Wyciekły klucz AWS to aktywny dostęp, dopóki go nie usuniesz","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=pl"},{"language":"ru","title":"Утёкший AWS-ключ — это действующий доступ, пока его не удалили","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru"},{"language":"zh","title":"泄露的 AWS 密钥只要还能认证，就仍然是有效访问","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=de","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de","html":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de","canonical":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de","markdown":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=de","json":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=de","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}