Welche S3-Bucket-Fehlkonfigurationen sind verbreitet und wie verhindert man sie?
Kurzantwort
Die klassischen Fehler sind öffentliche ACLs oder Bucket-Richtlinien, die anonymen Zugriff oder Zugriff für alle AWS-Benutzer erlauben, zu weit gefasste Principals oder Wildcard-Aktionen, fehlende Standardverschlüsselung und fehlendes Logging. Man verhindert sie, indem man Block Public Access auf Kontoebene aktiviert, IAM-/Bucket-Richtlinien nach dem Prinzip der geringsten Rechte einsetzt, Standardverschlüsselung und TLS erzwingt und Zugriffs-Logging sowie Config-Regeln einschaltet, um Abweichungen zu erkennen.
Die S3-Fehlkonfiguration ist der Lehrbuch-Cloud-Breach, weil Objektspeicher leicht öffentlich gemacht werden kann und die Folgen — Millionen offengelegter Datensätze — schwerwiegend sind. Das Interview will wissen, ob du verstehst, warum diese Lecks immer wieder passieren und wie man Exposition strukturell schwer macht.
Die häufigen Fehler
- Öffentliche ACLs / Bucket-Richtlinien. Lesezugriff für
AllUsers(jeder im Internet) oderAuthenticatedUsers(jedes AWS-Konto, nicht nur deines — eine häufige Falle) gewähren. - Wildcard-Principals oder -Aktionen. Eine Richtlinie mit
"Principal": "*"oder"Action": "s3:*"ist weit umfassender als beabsichtigt. - Keine Standardverschlüsselung und keine Anforderung, dass Anfragen TLS nutzen, sodass Objekte im Klartext gelesen oder geschrieben werden können.
- Kein Zugriffs-Logging oder objektbezogenes CloudTrail, sodass ein Leck unbemerkt bleibt und schwer zu untersuchen ist.
Wie man sie verhindert
- Block Public Access auf Kontoebene. Das überschreibt einzelne Bucket-Einstellungen und ist die wertvollste Einzelkontrolle — es macht „versehentlich öffentlich" nahezu unmöglich.
- Richtlinien geringster Rechte. Benenne konkrete Principals, schränke Aktionen ein und bevorzuge IAM-Rollen gegenüber weit gefassten Bucket-Richtlinien.
- Verschlüsselung und TLS erzwingen. Aktiviere Standardverschlüsselung und füge eine Richtlinienbedingung hinzu, die Anfragen ablehnt, bei denen
aws:SecureTransportfalse ist. - Abweichungen erkennen. Nutze Config-Regeln oder ein CSPM-Tool, um jeden Bucket, der öffentlich wird oder seine Verschlüsselung verliert, kontinuierlich zu kennzeichnen.
Die zentrale Erkenntnis: Verschlüsselung im Ruhezustand stoppt kein anonymes Lesen, wenn die Richtlinie es erlaubt — der Dienst entschlüsselt transparent für eine autorisierte Anfrage, und eine öffentliche Richtlinie macht die ganze Welt „autorisiert".
Worauf Interviewer achten
Block Public Access zuerst nennen, AllUsers von AuthenticatedUsers unterscheiden und wissen, dass sowohl Erkennung als auch Prävention zählen.
Wahrscheinliche Anschlussfragen
- Was blockiert S3 Block Public Access tatsächlich, und auf welchen Ebenen?
- Wie würdest du einen öffentlich lesbaren Bucket über Hunderte von Konten hinweg erkennen?
- Warum hilft Verschlüsselung im Ruhezustand nicht, wenn die Bucket-Richtlinie anonyme Lesezugriffe erlaubt?