Aus der Datenbank gelöscht – in den Backups noch lebendig

Jedes Unternehmen hat eine Aufbewahrungsrichtlinie. Sie existiert irgendwo in einem Dokument, wahrscheinlich zuletzt aktualisiert, als jemand merkte, dass die Prüfung bevorstand, und sie besagt etwas Zuversichtliches wie „personenbezogene Daten werden nach 90 Tagen gelöscht“, eine Zahl, die gewählt wurde, um beeindruckend kurz zu klingen, anstatt aus einer dokumentierten Zweckbindungsanalyse abgeleitet zu sein. Das Management nickt. Die Rechtsabteilung stimmt zu. Das Dokument wird abgelegt.

Die Daten sind indes unsterblich. Besonders in den Backups, die bei der Richtlinienbesprechung niemand erwähnt hat und die in den letzten drei Jahren stillschweigend alles aufbewahrt haben.

Das ist die Lücke, über die niemand spricht: der Unterschied zwischen einer Aufbewahrungsrichtlinie und deren tatsächlicher Durchsetzung. Das Schreiben der Richtlinie dauert einen Nachmittag. Die Durchsetzung in einem echten Produktionssystem (Datenbanken, Backups, Logs, Drittanbieter, archivierte Exporte, Data Warehouses, Schattenkopien) dauert erheblich länger und bringt architektonische Entscheidungen ans Licht, die Sie wahrscheinlich nicht mit Blick auf die Löschung getroffen haben.

Warum die meisten Aufbewahrungsdurchsetzungen scheitern, bevor sie beginnen

Das Kernproblem ist, dass sich Daten an mehr Orten ansammeln, als den Verfassern der Richtlinie bekannt war. Sie dachten an die Hauptdatenbank. Sie dachten nicht an die Logging-Pipeline, die Request-Bodies mit Benutzerdaten erfasst und unbegrenzt aufbewahrt, weil niemand eine Log-Rotationsrichtlinie festgelegt hat, die tatsächlich läuft. Oder an das Analyse-Warehouse, in das vor achtzehn Monaten Rohereignisdaten für ein Projekt gekippt wurden, das nie ausgeliefert wurde, und das immer noch vollständige Benutzerkennungen enthält, weil die Pseudonymisierung „auf der Roadmap“ stand. Oder an das nächtliche Datenbank-Backup, das neunzig Tage lang aufbewahrt wird, was bedeutet, dass Daten, die Sie am ersten Tag aus Ihrer Live-Datenbank gelöscht haben, bis zum einundneunzigsten Tag intakt in einem Backup liegen, möglicherweise länger, wenn jemand vor einer größeren Veröffentlichung „nur für den Fall“ manuell eine Kopie archiviert hat.

Ihre Aufbewahrungspflicht erstreckt sich auch auf jede Drittanbieter-Integration, die Sie im vorherigen Beitrag abgebildet haben. Wenn Sie einen Benutzer aus Ihrem System löschen, aber Ihr CRM immer noch dessen Datensatz hat, Ihr Fehlerüberwachungstool immer noch dessen Stack-Traces hat und Ihre KI-Modell-API immer noch dessen Konversationsverlauf in einem Fine-Tuning-Datensatz hat, haben Sie tatsächlich nichts gelöscht. Sie haben nur die Kopie gelöscht, die Sie kontrollieren.

Und dann ist da noch die CSV-Datei, die jemand für eine einmalige Analyse exportiert und auf seinem Laptop gespeichert hat. Das können Sie nicht automatisieren, aber Sie können es zu einem disziplinarischen Problem machen, anstatt es technisch zu vernachlässigen.

Löschung, Anonymisierung, Pseudonymisierung: Warum die Unterscheidung wichtig ist

Bevor Sie eine einzige Zeile Löschcode schreiben, entscheiden Sie, welchen Ansatz Sie tatsächlich verfolgen, denn sie sind wirklich unterschiedlich und die DSGVO behandelt sie unterschiedlich.

Löschung bedeutet, dass die Daten weg sind. Wenn jemand nach der Löschung eine Auskunftsanfrage stellt, lautet die korrekte Antwort: „Wir speichern keine Daten über Sie.“ Sauber, einfach und am schwierigsten sauber in großem Maßstab umzusetzen.

Anonymisierung bedeutet, dass die Daten noch existieren, aber keiner Einzelperson mehr zugeordnet werden können. Weder von Ihnen, noch von jemand anderem, nicht einmal mit zusätzlichen Datensätzen oder zumutbarem Aufwand. Wenn Sie dies richtig machen, gilt die DSGVO nicht mehr für die anonymisierten Daten. Sie können sie unbegrenzt aufbewahren. Verwenden Sie sie für Analysen, QA-Datensätze, Modelltraining, Lasttests, was auch immer Sie benötigen. Dies ist keine Lücke. Es ist die beabsichtigte Lösung. Die DSGVO fördert die Anonymisierung aktiv, gerade damit Organisationen Daten für legitime sekundäre Zwecke aufbewahren können, ohne dass die Aufbewahrungsfrist abläuft. Die Verordnung möchte, dass Sie dies tun. Sie möchte nur, dass Sie es richtig tun.

Der Haken ist, dass eine ordnungsgemäße Anonymisierung schwieriger ist, als es aussieht. Das Entfernen eines Namens und einer E-Mail aus einem Datensatz ist keine Anonymisierung, wenn die verbleibenden Felder (Altersgruppe, Postleitzahl, Berufsbezeichnung, Kontoerstellungsdatum) spezifisch genug sind, dass eine entschlossene Person die Einzelperson trotzdem identifizieren könnte. Dies wird als Re-Identifikationsrisiko bezeichnet, und dessen Unterschätzung führt dazu, dass Anonymisierungsprojekte stillschweigend zu Pseudonymisierungsprojekten werden, die niemanden täuschen, am wenigsten eine Aufsichtsbehörde.

Pseudonymisierung (Ersetzen direkter Identifikatoren durch Token, während eine Zuordnungstabelle irgendwo aufbewahrt wird) ist operativ nützlich, und die DSGVO honoriert dies, aber sie erfüllt eine Löschpflicht nicht von selbst. Die Person ist immer noch über die Zuordnungstabelle identifizierbar. Das Löschen der Zuordnungstabelle hilft, ist aber auch nicht garantiert ausreichend, da die pseudonymisierten Datensätze möglicherweise immer noch über andere Attribute im Datensatz re-identifizierbar sind. Wenn Sie sich auf Pseudonymisierung verlassen wollen, um Aufbewahrungspflichten zu erfüllen, holen Sie sich eine ordnungsgemäße Stellungnahme ein, bevor Sie den Auftrag ausliefern, und nicht danach.

Die praktische Aufteilung für die meisten Entwickler: Löschen Sie personenbezogene Daten, die Sie für den ursprünglichen Zweck nicht mehr benötigen, anonymisieren Sie Daten, für die Sie einen echten legitimen Grund haben, sie für sekundäre Zwecke wie QA, Tests und Modellverbesserung aufzubewahren. Führen Sie die Anonymisierung ordnungsgemäß durch: Entfernen Sie direkte Identifikatoren, bewerten Sie das Re-Identifikationsrisiko anhand der verbleibenden Felder, dokumentieren Sie Ihre Bewertung. Wenn Sie dies nicht selbstbewusst tun können, löschen Sie stattdessen. Eine falsche Anonymisierung als erledigt zu bezeichnen, ist schlimmer als es nicht zu versuchen.

Wie man die Löschung tatsächlich implementiert

Beginnen Sie damit, jeden Ort zu kartieren, an dem die Daten eines Benutzers gespeichert sind. Nicht die Orte, von denen Sie glauben, dass sie dort gespeichert sind. Die Orte, an denen sie tatsächlich gespeichert sind. Führen Sie die Übung genauso durch, wie Sie die Integrationsprüfung im vorherigen Beitrag durchgeführt haben: Beginnen Sie mit dem, was beobachtbar ist (Datenbanktabellen, Log-Ziele, Drittanbieter-Integrationen), nicht mit dem, was das Architekturdiagramm besagt.

Beantworten Sie für jeden Ort drei Fragen. Können Sie bei Bedarf löschen oder anonymisieren? Können Sie diese Löschung nach einem Zeitplan automatisieren? Können Sie überprüfen, ob die Löschung stattgefunden hat?

Die dritte Frage ist die, die die meisten Teams überspringen. Ein Löschauftrag, der stillschweigend fehlschlägt und Erfolg meldet, ist schlimmer als gar kein Löschauftrag, denn Sie haben jetzt einen Compliance-Datensatz, der behauptet, Daten seien gelöscht worden, obwohl dies nicht der Fall war. Bauen Sie die Verifizierung von Anfang an ein. Protokollieren Sie die Löschung, protokollieren Sie die Anzahl der betroffenen Datensätze, alarmieren Sie bei Löschungen mit Null-Anzahl für Benutzer, die Daten hätten haben sollen.

Für Ihre Hauptdatenbank ist die Löschung in der Regel unkompliziert: ein geplanter Job, der auf created_at oder last_active basiert, mit einer Soft-Delete-Periode, falls Ihr Support-Team ein Wiederherstellungsfenster benötigt. Die Soft-Delete-Periode ist ebenfalls eine Aufbewahrungsfrist. Definieren Sie sie explizit und setzen Sie sie durch.

Für Logs legen Sie Aufbewahrungsrichtlinien auf Pipeline-Ebene fest, nicht als manuelle Bereinigungsaufgabe. Wenn Ihre Logging-Infrastruktur dies unterstützt, filtern Sie PII bei der Erfassung aus Log-Einträgen heraus, anstatt zu versuchen, sie später zu löschen. Das nachträgliche Löschen spezifischer Datensätze aus einem Log-Stream ist mühsam. Sie gar nicht erst zu schreiben, ist viel einfacher.

Für Backups müssen Sie einen gewissen Verzug akzeptieren. Wenn Ihre Backups dreißig Tage lang aufbewahrt werden, bleiben Daten, die aus Ihrem Live-System gelöscht wurden, bis zu dreißig Tage lang in den Backups bestehen. Dokumentieren Sie dies. Dies ist im Allgemeinen unter der DSGVO akzeptabel, vorausgesetzt, Ihre Aufbewahrungsrichtlinie berücksichtigt dies und Sie verwenden Backups nicht als Mittel zur Umgehung von Löschpflichten. Nicht akzeptabel ist die unbegrenzte Aufbewahrung von Backups, weil niemand jemals die Aufbewahrungseinstellung des Backup-Jobs überprüft hat.

Für Drittanbieter müssen Löschanträge nachgelagert fließen. Dies bedeutet entweder automatisierte API-Aufrufe, um die Löschung bei jedem Anbieter auszulösen, oder einen dokumentierten manuellen Prozess mit einem Abschlussnachweis. Die meisten großen Anbieter unterstützen Lösch-APIs. Nutzen Sie diese. Für Anbieter, die dies nicht tun, ist dies ein Gespräch, das Sie führen sollten, bevor Sie sich bei allem, was personenbezogene Daten betrifft, auf sie verlassen.

Das Backup-Problem in einfachen Worten

Backups verdienen einen eigenen Absatz, denn hier scheitern die meisten Aufbewahrungsprogramme stillschweigend.

Ein Backup ist eine Momentaufnahme zu einem bestimmten Zeitpunkt. Wenn Sie Daten aus Ihrem Live-System löschen, wird diese Löschung nicht auf bestehende Backups übertragen. Die gelöschten Daten existieren immer noch in jedem Backup, das vor der Löschung erstellt wurde. Das ist in Ordnung und erwartet. Die Frage ist, wie lange diese Backups aufbewahrt werden.

Die Antwort in den meisten Unternehmen lautet „länger als irgendjemand wusste“. Backup-Aufbewahrungseinstellungen werden einmal konfiguriert und vergessen. Speicher ist billig. Niemand überprüft die Backup-Aufbewahrungsrichtlinie anhand der Datenaufbewahrungsrichtlinie. Das Ergebnis ist ein Friedhof von Momentaufnahmen, die die personenbezogenen Daten von Benutzern enthalten, die ihre Konten vor Jahren gelöscht haben.

Überprüfen Sie jetzt Ihre Backup-Aufbewahrungseinstellungen. Passen Sie sie an Ihre Datenaufbewahrungsrichtlinie an. Wenn Ihre Richtlinie besagt, dass Daten nach neunzig Tagen gelöscht werden, sollten Ihre Backups nicht ein Jahr lang aufbewahrt werden. Und wenn Sie eine Löschungsanfrage für eine bestimmte Person erhalten, vermerken Sie in Ihren Aufzeichnungen, dass die Löschung abgeschlossen sein wird, sobald das relevante Backup-Fenster abläuft. Das ist die ehrliche Antwort, und sie ist vertretbar.

Was gut aussieht

Ein Aufbewahrungsprogramm, das tatsächlich funktioniert, hat vier Eigenschaften:

Es ist automatisiert. Manuelle Löschprozesse scheitern, weil Menschen vergessen, krank werden, das Unternehmen verlassen und den Löschrückstand desjenigen erben, der vor ihnen gegangen ist. Wenn es nicht automatisiert ist, ist es kein Aufbewahrungsprogramm. Es ist eine gute Absicht.

Es ist verifiziert. Jeder Löschauftrag erstellt einen Datensatz darüber, was wann gelöscht wurde und wie viele Datensätze betroffen waren. Anomalien lösen Warnungen aus. Der Verifizierungsdatensatz wird aufbewahrt. Ja, es ist eine gewisse Ironie, Datensätze über Ihre Löschdatensätze zu führen, aber so sehen Prüfnachweise aus.

Es deckt den gesamten Datenbestand ab. Hauptdatenbank, Logs, Backups, Drittanbieter, Data Warehouses, exportierte Dateien, wo möglich. Eine Aufbewahrungsdurchsetzung, die nur die Hauptdatenbank betrifft, ist keine Aufbewahrungsdurchsetzung. Es ist das Aufräumen eines Regals, während sich der Rest des Hauses ansammelt.

Es ist getestet. Führen Sie einen Löschauftrag für einen Testdatensatz aus, bevor Sie ihn für die Produktion ausführen. Überprüfen Sie das Ergebnis. Tun Sie dies jedes Mal, wenn sich der Auftrag ändert. „Der Löschauftrag läuft“ und „der Löschauftrag funktioniert korrekt“ sind unterschiedliche Aussagen, und Sie möchten Beweise für beides.