Ein Datenleck – Data Breach oder Datenschutzverletzung – ist jedes Ereignis, bei dem Daten unbeabsichtigt oder unberechtigt von Personen eingesehen, kopiert, übertragen, verändert, offengelegt oder zerstört werden können, die dazu nicht autorisiert sind. Das umfasst sowohl gezielte Angriffe (Hacker stehlen Datenbank) als auch unbeabsichtigte Offenlegungen (falsch konfigurierter S3-Bucket macht Kundendaten öffentlich zugänglich) als auch interne Fehler (E-Mail mit Kundendaten an falsche Adresse).
Im DSGVO-Kontext ist ein Datenleck mit personenbezogenen Daten eine Datenschutzverletzung nach Art. 33/34, die potenzielle Meldepflichten auslöst: 72 Stunden nach Kenntnisnahme an die Datenschutzbehörde, und unter Umständen auch direkte Information der betroffenen Personen. Für Automatisierungsdienstleister, die im Auftrag ihrer Kunden personenbezogene Daten verarbeiten, ist ein Datenleck nicht nur ein eigenes Problem, sondern trifft auch alle Kunden, deren Daten betroffen sind.
Datenleck-Typen nach Ursache
Vertraulichkeit Unbefugter Zugriff/Offenlegung: Hacker-Angriff, falsch konfigurierte Zugriffsrechte, öffentlicher S3-Bucket, gestohlene Credentials. Häufigste Form.
Integrität Unberechtigte Veränderung: Manipulation von Daten durch Angreifer oder Insider. Buchungsmanipulation, geänderte Zahlungsziele, korrumpierte Datensätze.
Verfügbarkeit Datenverlust/-vernichtung: Ransomware verschlüsselt Daten, versehentliches Löschen ohne Backup, Hardware-Ausfall ohne Redundanz. Kein Zugriff mehr möglich.
Reaktion auf ein Datenleck
- Sofort (0–2 Stunden): Vorfall eindämmen, betroffene Systeme isolieren oder Zugang sperren. Keine Spekulationen über Ausmaß bis erste Analyse
- Analyse (2–24 Stunden): Was genau ist abgeflossen? Welche Daten? Wie viele Betroffene? Welcher Zeitraum? Sind personenbezogene Daten betroffen?
- DSGVO-Prüfung (< 72 Stunden): Sind personenbezogene Daten betroffen und besteht Risiko für Betroffene? Wenn ja: Meldepflicht an Datenschutzbehörde. Frist: 72 Stunden nach Kenntnisnahme
- Betroffene informieren: Bei hohem Risiko für Betroffene: direkte Benachrichtigung (Art. 34 DSGVO). Klar, verständlich, ohne Verschleierung
- Behebung und Prävention: Schwachstelle schließen, zusätzliche Schutzmaßnahmen implementieren, Lessons Learned
Praxisbeispiel
Ein Automationsdienstleister entdeckt, dass ein S3-Bucket mit Backup-Daten seit 6 Wochen öffentlich zugänglich war (falsche ACL-Konfiguration nach Migration). Im Bucket: Backup-Daten von 3 Kunden, enthält Rechnungsdaten mit Kundennamen und Adressen (personenbezogen), keine Zahlungsdaten oder Passwörter. Reaktion: Bucket sofort auf privat gesetzt (10:14 Uhr). Analyse: Welche Daten genau, wie viele Betroffene? Log-Analyse: War auf die Bucket-Dateien zugegriffen worden? (S3-Access-Logs: keine Zugriffe von externen IPs erkennbar). DSGVO-Prüfung: Personenbezogene Daten waren 6 Wochen potenziell einsehbar. Auch ohne nachgewiesenen Zugriff: Datenschutzbehörde innerhalb 72 Stunden informiert (Vorsichtsmeldung). 3 Kunden informiert. Ursache: Automatisches ACL-Reset bei Migration nicht berücksichtigt. Präventionsmaßnahme: Automatischer S3-Bucket-Policy-Check täglich via AWS Config.
