Viele der größten Datenpannen entstehen nicht durch „Super-Hacker“, sondern durch Fehlkonfigurationen: ein falsch gesetztes Zugriffsrecht, ein öffentlich freigegebener Cloud-Bucket oder eine Testdatenbank ohne Passwort. Obwohl Cloud-Security-Tools und Best Practices seit Jahren bekannt sind, tauchen weiterhin Fälle auf, in denen sensible Daten ungewollt öffentlich erreichbar sind – oft über Wochen oder Monate.
Warum passiert das immer noch?
Cloud-Plattformen sind flexibel – und genau das ist das Risiko. Teams arbeiten schnell, setzen neue Services auf, teilen Dateien kurzfristig, erstellen Testumgebungen und vergessen später, Rechte wieder zu schließen. Dazu kommt, dass Berechtigungsmodelle komplex sind und sich über mehrere Ebenen (Account, Projekt, Bucket, Objekt) erstrecken.
- Tempo: Deployments und Releases sind schneller als Security-Reviews.
- Komplexe Rechte: Rollen, Policies, Gruppen, Links, Token – alles greift ineinander.
- Schatten-IT: einzelne Teams erstellen „kurz mal“ Speicher ohne zentrale Governance.
- Testdaten: „nur für QA“ ist oft trotzdem personenbezogen oder vertraulich.
Die häufigsten Fehlkonfigurationen
1) Öffentlich freigegebene Buckets/Ordner
Ein Storage-Bucket oder ein Ordner wird „für den schnellen Zugriff“ öffentlich gemacht. Später bleibt die Einstellung bestehen – und Suchmaschinen, Crawler oder simple URL-Scanner finden die Daten.
2) Freigabelinks ohne Ablaufdatum
„Anyone with the link“ ist praktisch – aber gefährlich, wenn Links weitergeleitet, aus Versehen veröffentlicht oder in Tickets/Chats geleakt werden. Ohne Ablaufdatum bleiben sie lange nutzbar.
3) Falsch konfigurierte Zugriffsschlüssel
API-Keys oder Service-Accounts besitzen zu breite Rechte („Admin“-Scope) und werden in Logs, Repos oder Build-Pipelines sichtbar. Wird ein Key entwendet, kann ein Angreifer Daten lesen oder löschen.
4) Datenbanken und Dashboards ohne Authentifizierung
Testinstanzen (z. B. Suchserver, Monitoring-Dashboards, NoSQL-Datenbanken) werden ins Netz gestellt, aber nicht abgesichert. Oft sind Standardports offen oder Admin-Passwörter wurden nie gesetzt.
Cloud-Leaks sind häufig kein „Hack“ – sondern ein öffentliches Türschild, das niemand bemerkt hat.
Was Unternehmen sofort verbessern können
Viele Maßnahmen sind simpel, wirken aber stark – wenn sie konsequent umgesetzt werden:
- Default „private“: Öffentliche Freigaben nur per Ausnahmeprozess.
- Least Privilege: Service-Accounts und Keys nur mit minimalen Rechten.
- Ablaufdaten: Freigabelinks und Tokens mit kurzer Laufzeit.
- Automatisierte Checks: Policies als Code, Security-Scanner in CI/CD.
- Monitoring: Alerts bei neuen Public-Buckets, ungewöhnlichen Downloads, Zugriff aus fremden Regionen.
Incident-Playbook: Wenn doch etwas offen war
Wenn ein Leak vermutet wird, zählen schnelle und nachvollziehbare Schritte:
- Zugriff schließen (Public Access sofort entfernen).
- Logs sichern und Zugriffe analysieren (wer, wann, wie viel).
- Keys rotieren (API-Keys, Tokens, Passwörter).
- Betroffene Daten bewerten (Personendaten, Geschäftsgeheimnisse, Kundeninfos).
- Kommunikation nach rechtlichen Vorgaben vorbereiten (je nach Jurisdiktion).
Fazit
Fehlkonfigurationen sind eine der häufigsten Ursachen für Datenpannen – weil sie im Alltag leicht entstehen und lange unentdeckt bleiben können. Wer „private by default“, klare Ausnahmeprozesse, automatisierte Checks und starkes Monitoring etabliert, reduziert das Risiko drastisch. In der Cloud entscheidet oft nicht ein einzelner Exploit, sondern die Frage: Wer darf wirklich was – und wer merkt es, wenn sich das ändert?
