← Alle Artikel

Falsch konfigurierte Speicher-Buckets (S3): Das Risiko öffentlicher Daten

13. September 2026

Falsch konfigurierte Speicher-Buckets (S3): Das Risiko öffentlicher Daten

Cloud-Objektspeicher (AWS S3, Azure Blob, Google Cloud Storage) macht es leicht, über das Internet zugängliche Daten zu speichern. Diese Bequemlichkeit bringt eine der häufigsten Ursachen für Datenlecks: versehentlich öffentlich gelassene Buckets. Bleibt ein Bucket mit Backups, Nutzerdaten oder Geheimnissen “public”, kann jeder ihn finden und herunterladen — ohne eine Schwachstelle auszunutzen, allein durch Fehlkonfiguration.

Warum es so oft passiert

  • “Öffentlich” versehentlich wählen: Eine Berechtigung, um eine Datei zu teilen, breitet sich auf den ganzen Bucket aus.
  • Zu weite Zugriffsrichtlinien: Regeln wie "Principal": "*" bedeuten “jeder”.
  • Standards missverstehen: Teams legen manchmal Daten ab, ohne zu prüfen, für wen der Bucket wirklich offen ist.
  • Die URL für “geheim” halten: Eine lange, unratbare URL bietet keine Vertraulichkeit; nicht durch Zugriffskontrolle geschützter Inhalt ist offen.

Auswirkung

Ein offener Bucket kann zu einer direkten Datenschutzverletzung werden: personenbezogene Daten, Backups, Protokolle, sogar Konfigurationsgeheimnisse. Der Angreifer muss nichts “knacken”; er listet und lädt den Inhalt herunter. Das macht exponierten Speicher zu einem der Leck-Typen mit geringstem Aufwand und höchster Auswirkung.

Sichere Konfiguration

  1. Standardmäßig privat halten. Öffentlicher Zugriff sollte eine bewusste, begründete, seltene Ausnahme sein.
  2. Schutz auf Kontoebene aktivieren wie “Block Public Access”, der versehentliche Freigabe verhindert.
  3. Least-Privilege-Richtlinien schreiben. "Principal": "*" und unnötig breite Aktionen vermeiden.
  4. Daten ruhend verschlüsseln.
  5. Zugriffsprotokolle aktivieren und überwachen.
  6. Regelmäßig prüfen. Periodisch kontrollieren, welche Buckets öffentlich sind; CSPM-Tools automatisieren das.

Zusammenfassung

Falsch konfigurierte Speicher-Buckets lecken Daten ohne Schwachstelle — allein weil sie “public” gelassen werden. Die Lösung: standardmäßig privat, Public-Access-Blocks auf Kontoebene, Least-Privilege-Richtlinien, Verschlüsselung und regelmäßige Prüfung. Verlassen Sie sich nie auf “eine lange URL ist geheim”.

Quellen: AWS S3 Block Public Access, OWASP: Security Misconfiguration (A05:2021).

Könnte Ihr Cloud-Speicher oder Ihre Angriffsfläche unbeabsichtigt Inhalte preisgeben? Der Scan von CyberTestify bewertet aus dem Internet sichtbare Assets.