ShutterGap: Warum tägliche CSPM-Scans 99 % der AWS-Snapshot-Leaks verpassen

Wer schon einmal eine On-Call-Rotation für eine AWS-Umgebung übernommen hat, kennt das stille Unbehagen bei den Worten „öffentlicher Snapshot". Die neue ShutterGap-Forschung von Aryon Security zeigt, dass das Problem schlimmer ist, als die Dashboards vermuten lassen: 20 % der öffentlich geteilten RDS-Snapshots sind weniger als zwei Minuten sichtbar, und 99 % der gelöschten RDS- und DocumentDB-Snapshots verschwinden innerhalb von 30 Minuten nach ihrer Erstellung. Wenn Ihr CSPM im Tagesrhythmus läuft, ist es für die Mehrheit der realen Exposure-Ereignisse praktisch blind.

Die Zahlen

Der Kernbefund, wie CyberSecurityNews berichtete, ist ein zeitlicher Versatz zwischen der Geschwindigkeit, mit der AWS-Ressourcen kurz öffentlich sichtbar werden, und der Trägheit, mit der die meisten Sicherheitstools sie überprüfen. In einem einzigen 90-minütigen Beobachtungsfenster in us-east-1 änderte sich die Anzahl der öffentlich verfügbaren RDS-Snapshots 12 Mal. Sechs tauchten auf. Sechs verschwanden. Das entspricht etwa einer Zustandsänderung alle sieben einhalb Minuten – in einer Region, für einen Ressourcentyp.

Legt man nun einen täglichen Scan-Rhythmus darüber: Wenn Ihr CSPM nur alle 24 Stunden prüft und 20 % der Exposures weniger als zwei Minuten bestehen, verpasst man sie mit einer Wahrscheinlichkeit, die an Gewissheit grenzt. Selbst das 30-Minuten-Fenster, in dem bereits 99 % der gelöschten Snapshots verschwunden sind, liegt weit innerhalb des Rauschens der meisten Posture-Management-Zeitpläne. Produktionsvorfälle, die ich im Fintech-Bereich erlebt habe, folgen typischerweise diesem Muster: Das Audit-Log zeigt, dass die Fehlkonfiguration existierte, der Scanner zeigt nichts, und die Nachbesprechung dreht sich darum, ob ein Baum im Wald umgefallen ist, ohne dass es jemand gehört hat.

Aryon blieb nicht beim Zählen der Flickereignisse stehen. Sie haben eine Stichprobe von 24 öffentlich geteilten RDS-Snapshots gezogen, diese wiederhergestellt und sich angesehen, was darin enthalten war. Die wiederhergestellten Datenbanken enthielten AWS-Konto-Identifikatoren, E-Mail-Adressen, potenzielle Secrets, Muster, die auf Private Keys hindeuteten, und Hinweise auf Finanzdaten. Die Extraktion wurde an diesem Punkt gestoppt – das ist die verantwortungsvolle Entscheidung –, aber das Signal ist eindeutig: Diese ephemeren Exposures sind keine leeren Test-Fixtures. Sie enthalten das Material, das ein Angreifer tatsächlich sucht.

Die überwachte Angriffsfläche ging über RDS hinaus. Aryon beobachtete auch Amazon DocumentDB-Snapshots, Amazon Machine Images und AWS Systems Manager-Dokumente – alles Ressourcentypen, die das öffentliche Teilen von Haus aus unterstützen. Nichts davon ist eine AWS-Sicherheitslücke. Es handelt sich um Konfigurationsfehler der Kunden, und AWS hat Kunden seit Jahren darauf hingewiesen, keine sensiblen Daten in öffentlich teilbaren Ressourcen zu speichern. Das Problem ist, dass ein modernes Plattform-Team täglich Hunderte von Infrastrukturänderungen ausliefert. Ein gewisser Anteil davon wird fehlerhaft sein. Die Frage ist, ob Ihre Kontrollen diese Fehler in Sekunden oder in Stunden erkennen.

Was wirklich neu ist

Das Konzept falsch konfigurierter öffentlicher Snapshots ist nicht neu. Neu ist die empirische Messung der Expositionsdauer und die operative Schlussfolgerung, die sich daraus ergibt. Seit Jahren wird der Industrie Posture Management als Antwort auf Cloud-Fehlkonfigurationen verkauft. Kaufen Sie den Scanner, binden Sie ihn in Slack ein, schließen Sie die Tickets. ShutterGap bricht dieses Denkmodell auf, indem es zeigt, dass das ausnutzbare Zeitfenster kleiner ist als die Taktauflösung des Scanners.

Das zweite wirklich neue Detail sind die Angriffs-Ökonomik. Ein Angreifer muss die Datenbank nicht während des Zeitfensters exfiltrieren. Er muss lediglich eine Snapshot-Kopie in sein eigenes AWS-Konto übertragen. Sobald die Kopie angekommen ist, kann der ursprüngliche Eigentümer den öffentlichen Zugriff nach Belieben entziehen – die Daten sind weg. Das macht ShutterGap von einer Race Condition zu einem Persistenz-Primitiv. Zwei Minuten Exposition bedeuten permanenten Kompromiss, wenn jemand zusieht.

Und jemand sieht zu. Öffentliche AWS-Ressourceninventare sind trivial aufzählbar. Jeder kompetente Angreifer kann einen kontinuierlichen Poller gegen dieselben APIs betreiben, die Aryon verwendet hat, und alles Interessante im Moment seines Auftauchens kopieren. Die Kosten für den Betrieb dieser Infrastruktur sind im Vergleich zum Wert eines einzigen produktiven RDS-Snapshots mit enthaltenen Credentials minimal.

Meine Einschätzung: Das verschiebt die CSPM-Diskussion von „Wie viele Findings haben wir diese Woche geschlossen?" zu „Was haben wir von vornherein verhindert?" Die Aryon-Empfehlungen setzen stark auf Service Control Policies – und das ist der richtige Instinkt. SCPs sind unspektakulär, erzeugen keine hübschen Dashboards, und sie funktionieren. Das Blockieren von Änderungen an Snapshot-Sharing-Attributen, die Aufrechterhaltung der Sperre für öffentliches AMI-Sharing und die Verhinderung des öffentlichen SSM-Dokument-Sharings sind allesamt einmalige Policy-Schreibvorgänge, die ganze Klassen von Findings dauerhaft neutralisieren. Das ist weit effizienter, als einen Analysten 40 Mal pro Quartal denselben wiederkehrenden Alert triagieren zu lassen.

Was für Sicherheitsteams bereits eingepreist ist

Die meisten erfahrenen Plattformverantwortlichen haben bereits vermutet, dass tägliche Scans unzureichend sind. Das ist eingepreist. Jeder, der eine ernstzunehmende Cloud-Umgebung betrieben hat, hat schon einmal beobachtet, wie ein Entwickler um 14:00 Uhr einen Bucket öffentlich macht und um 14:04 Uhr wieder schließt – und intuitiv begriffen, dass kein Scanner das je sehen würde. Was nicht eingepreist war, ist das Ausmaß. Sechs neue öffentliche RDS-Snapshots in 90 Minuten in einer Region ist nicht ein Entwickler, der einen Fehler macht. Es ist ein systemisches Verhaltensmuster, das wahrscheinlich mit Snapshot-Copy-Workflows, Cross-Account-Sharing-Skripten und Disaster-Recovery-Tests zusammenhängt, die kurzzeitig den öffentlichen Zugriff als Abkürzung aktivieren.

Ebenfalls eingepreist: die Idee, dass Prävention im Cloud-Security-Bereich besser ist als Detektion. Das sagt jeder auf Konferenzen. Neu ist eine konkrete Messung, die genau quantifiziert, wie schlecht die Detektion abschneidet, wenn das Expositionsfenster unter zwei Minuten liegt. Diese Zahl ist ein Hebel zur Budgetrechtfertigung. Wenn Sie ein CTO sind und Ihre Cloud-Security-Ausgaben zu 90 % aus Detection-Tooling und zu 10 % aus präventiven Guardrails bestehen, ist diese Forschung das Memo, das Sie versenden, um das Verhältnis umzukehren.

Nicht eingepreist: der CloudTrail-Forensik-Aspekt. Die Überprüfung von CloudTrail auf RDS-ModifyDBSnapshotAttribute-, EC2-ModifyImageAttribute- und SSM-ModifyDocumentPermission-Events ist Standardempfehlung, aber die meisten Teams, mit denen ich gearbeitet habe, schauen sich diese Logs erst nach einem Vorfall an. Eine kontinuierliche Abfrage dieser Logs mit Alarmierung, wenn die Attributänderung eine Ressource öffentlich macht, schließt die Sichtbarkeitslücke, ohne auf den nächsten CSPM-Scan warten zu müssen. Es ist im Wesentlichen kostenlos, wenn Sie CloudTrail bereits an ein SIEM liefern. Die unbequeme Erkenntnis: Die meisten Organisationen tun das nicht – oder sie liefern es und fragen nie ab.

Gegenteilige Sichtweise

Die allgemeine Schlussfolgerung wird lauten: „Kaufen Sie ein Echtzeit-Cloud-Detection-Produkt." Dem würde ich widersprechen. Die gegenteilige Lesart lautet, dass ShutterGap kein Detektionsproblem ist. Es ist ein IAM-Berechtigungsproblem, das sich als Monitoring-Problem tarnt. Wenn Ihre Entwickler ModifyDBSnapshotAttribute mit einem öffentlichen Flag von vornherein nicht aufrufen können, passiert das Flickern nie. Kein Scanner nötig.

Der Grund, warum Organisationen das nicht tun, ist kulturell, nicht technisch. Die Einschränkung des Snapshot-Sharings über SCPs bedeutet, dass jemand die Ausnahme-Anfragen prüfen muss, wenn ein legitimes Cross-Account-Sharing benötigt wird. Das erzeugt Reibung, und Plattformteams optimieren gegen Reibung. Daher kauft die Industrie stattdessen ein weiteres Detection-Produkt, weil ein Produktkauf ein einmaliger politischer Kampf ist, während eine Berechtigungsgrenze eine dauerhafte ist.

Es gibt auch ein vernünftiges Argument, dass die 24-Snapshot-Stichprobe klein ist. Aryon hat die Extraktion verantwortungsvoll gestoppt – das ist richtig –, aber das bedeutet, dass die Behauptung über „signifikante Geschäftsinformationen" auf einer schmalen Basis beruht. Ein Skeptiker könnte argumentieren, dass die meisten geflickerten Snapshots leere Test-Fixtures sind. Möglich. Aber wenn auch nur ein einstelliger Prozentsatz echte Secrets enthält, ist der erwartete Verlust pro Jahr für eine große Umgebung enorm. Die Basisrate muss nicht hoch sein, damit das Risiko die Behebung rechtfertigt.

Wichtigste Erkenntnisse

• Tägliche CSPM-Scans können ShutterGap nicht erkennen. Bei 20 % der öffentlichen RDS-Snapshots, die weniger als zwei Minuten exponiert sind, und 99 %, die in 30 Minuten verschwinden, erfasst ein 24-Stunden-Rhythmus fast nichts.
• Prävention via SCP ist die eigentliche Lösung. Blockieren Sie ModifyDBSnapshotAttribute für öffentliches Sharing, halten Sie öffentliches AMI-Sharing gesperrt und verhindern Sie öffentliches SSM-Dokument-Sharing auf Organisationsebene. Einmal einrichten, dauerhaft besser schlafen.
• Behandeln Sie Exposition als dauerhaft, nicht als temporär. Ein Angreifer benötigt nur Sekunden, um eine Snapshot-Kopie in sein eigenes Konto zu übertragen. Der nachträgliche Entzug des öffentlichen Zugriffs macht den Kompromiss nicht rückgängig.
• CloudTrail mit Echtzeit-Alarmierung verbinden. Abfragen Sie RDS-ModifyDBSnapshotAttribute-, EC2-ModifyImageAttribute- und SSM-ModifyDocumentPermission-Events in Echtzeit – nicht erst beim nächsten Quartals-Review.
• Verschlüsselung für neue RDS-Instanzen vorschreiben. Das stoppt die Exposition nicht, erhöht aber den Aufwand für die Wiederherstellung eines kopierten Snapshots in einem fremden Konto und verschafft forensische Zeit.