Eine Richtlinie zur Datenaufbewahrung und -löschung lässt sich nicht mit einer einzigen DELETE-Anweisung umsetzen. In einer PHP-Anwendung können dieselben Informationen in mehreren Tabellen, Dateien, Caches, Protokollen und externen Diensten vorkommen. Wird nur der primäre Datensatz gelöscht, können aktive Kopien zurückbleiben. Werden Daten ohne Prüfung der Abhängigkeiten gelöscht, können Abläufe gestört oder Daten entfernt werden, die erhalten bleiben müssen.
Das praktische Ziel besteht darin, jede Regel in einen Ablauf zu überführen, der die betroffenen Daten identifiziert, die geeignete Maßnahme anwendet, Ausnahmen behandelt und überprüfbare Nachweise hinterlässt. Die Richtlinie sollte mit den für Produkt, Technologie und Daten verantwortlichen Bereichen abgestimmt und anhand der für das Geschäft geltenden Pflichten geprüft werden. Allgemeingültige gesetzliche Fristen sollten nicht abgeleitet werden: Sie hängen vom jeweiligen Kontext ab und müssen validiert werden, bevor sie automatisiert werden.
Beginnen Sie mit Kategorien und Aufbewahrungsregeln
Bevor Sie die Löschung entwerfen, klassifizieren Sie die Informationen nach Zweck und Verwendung. Für ein Profil, eine Adresse, die für einen noch laufenden Vorgang benötigt wird, einen Aktivitätsverlauf und einen Buchhaltungsdatensatz können unterschiedliche Regeln gelten, auch wenn sie demselben Konto zugeordnet sind.
Dokumentieren Sie für jede Kategorie mindestens Folgendes:
- Zweck und Verantwortliche: Warum werden die Daten gespeichert und welches Team entscheidet über ihre Aufbewahrung?
- Auslösendes Ereignis: zum Beispiel die Kontoschließung, das Ende einer Beziehung oder ein validierter Antrag.
- Frist und Bedingung: Wann wird die Maßnahme geprüft oder ausgeführt, einschließlich möglicher begründeter Aussetzungen?
- Maßnahme: löschen, anonymisieren, mit eingeschränktem Zugriff aufbewahren oder zur manuellen Prüfung weiterleiten.
- Abhängigkeiten: Systeme und Prozesse, die abgeschlossen sein müssen, bevor der Fall als erledigt gilt.
„Aufbewahren“ bedeutet nicht, Daten aus Bequemlichkeit unbegrenzt zu behalten. Es braucht dafür einen Grund, einen definierten Umfang und einen Überprüfungstermin oder eine Überprüfungsbedingung. Muss ein Teil der Informationen aus betrieblichen Gründen erhalten bleiben, trennen Sie diesen Bestand vom Rest und beschränken Sie den Zugriff darauf.
Erfassen Sie Kopien, Referenzen und verbundene Systeme
Das Inventar sollte dem tatsächlichen Weg der Daten folgen und nicht nur dem Datenbankschema. Prüfen Sie verwandte Tabellen, JSON-Felder, hochgeladene Dateien, Exporte, Suchindizes, Caches, Warteschlangen, Anwendungsprotokolle und integrierte Systeme. Berücksichtigen Sie auch Abläufe, durch die Kopien entstehen: Berichte, Support-Tools, Analysen oder Importprozesse.
Notieren Sie für jeden Speicherort, anhand welcher Kennung die Daten gefunden werden können, wer verantwortlich ist, wie sie gelöscht oder aktualisiert werden und was geschieht, wenn das System nicht verfügbar ist. Prüfen Sie Beziehungen anhand von Fremdschlüsseln und Anwendungslogik: Eine Beziehung in der Datenbank kann eine kaskadierende Löschung verhindern, während eine kaskadierende Löschung mehr entfernen kann als vorgesehen.
Behandeln Sie Backups als eigenen Fall. Möglicherweise lässt sich ein einzelner Eintrag daraus nicht löschen, ohne das gesamte Backup wiederherzustellen. Legen Sie fest, wie der Zugriff darauf beschränkt wird, wie lange sie aufbewahrt werden und welches Verfahren verhindert, dass gelöschte Daten nach einer Wiederherstellung in aktive Systeme zurückgelangen. Dokumentieren Sie die Entscheidung und stimmen Sie sie mit den für Infrastruktur und Compliance verantwortlichen Personen ab.
Entscheiden Sie, wann Daten gelöscht, anonymisiert oder aufbewahrt werden
Bei einer physischen Löschung werden die Daten aus einem aktiven System entfernt; sie ist jedoch nicht für jeden Datensatz die richtige Option. Eine Anonymisierung kann geeignet sein, wenn statistische Informationen erhalten bleiben müssen und die Möglichkeit, sie einer Person zuzuordnen, wirksam beseitigt werden kann. Einen Namen durch eine stabile Kennung zu ersetzen, reicht nicht aus, wenn sich die Zuordnung über eine andere Tabelle wiederherstellen lässt.
Eine Aufbewahrung mit eingeschränktem Zugriff kann für Daten sinnvoll sein, die für einen Vorgang oder eine bestätigte Verpflichtung noch benötigt werden. Halten Sie diese Elemente getrennt, versehen Sie sie mit spezifischen Berechtigungen und legen Sie eine Überprüfungsregel fest. Lässt sich nicht sicher bestimmen, welche Maßnahme angemessen ist – etwa wegen eines Rechtsstreits, einer unbekannten Abhängigkeit oder einer widersprüchlichen Identität –, leiten Sie den Fall an eine Prüfwarteschlange weiter, statt zu improvisieren.
Auch die funktionalen Auswirkungen müssen geprüft werden: Was geschieht mit Bestellungen, Abonnements, Tickets, API-Schlüsseln oder geteilten Dokumenten, wenn ein Konto gelöscht wird? Das Verhalten muss in der Benutzeroberfläche, der PHP-Logik und den verbundenen Diensten explizit und konsistent sein.
Implementieren Sie einen idempotenten und nachvollziehbaren Ablauf
Ein Löschprozess wird häufig im Hintergrund ausgeführt, über eine Warteschlange oder einen geplanten Task. Modellieren Sie den Fall mit expliziten Zuständen, zum Beispiel: beantragt, validiert, in Bearbeitung, wartet auf externe Systeme, abgeschlossen oder Prüfung erforderlich. Definieren Sie zulässige Zustandsübergänge und legen Sie fest, wer einen erneuten Versuch starten oder eine Ausnahme schließen darf.
Idempotenz ist entscheidend: Die Wiederholung eines Schritts darf keine Effekte duplizieren oder Schäden verursachen. Prüfen Sie vor dem Löschen einer Datei, ob sie existiert; überprüfen Sie bei der Bearbeitung eines Antrags den aktuellen Status; verwenden Sie beim Aufruf eines externen Dienstes gegebenenfalls verfügbare Idempotenzmechanismen. Lässt sich das nicht sicherstellen, protokollieren Sie die Antwort und entwerfen Sie vor einem blinden erneuten Versuch einen Abgleich.
Ein konzeptionelles PHP-Beispiel könnte die Orchestrierung von den Aktionen der einzelnen Systeme trennen:
foreach ($steps as $step) {
if ($step->isComplete($requestId)) {
continue;
}
$step->execute($subjectReference);
$step->markComplete($requestId);
}Das Beispiel löst keine verteilten Transaktionen: Eine Datenbank und ein externer Anbieter verwenden nicht zwangsläufig dieselbe Transaktion. Speichern Sie den Fortschritt zuverlässig, behandeln Sie Fehler pro Schritt und ermöglichen Sie die Fortsetzung der Arbeit. Schlägt ein Vorgang mittendrin fehl, muss der Status erkennen lassen, was noch fehlt; der Vorgang darf nicht als abgeschlossen angezeigt werden.
Protokollieren Sie die Ausführung, ohne eine weitere personenbezogene Kopie anzulegen
Die Nachvollziehbarkeit ermöglicht festzustellen, wer oder welcher Prozess wann, für welchen Antrag und mit welchem Ergebnis gehandelt hat. Protokollieren Sie interne Vorgangskennungen, Status, Schritte und für die Diagnose nützliche Fehlercodes. Vermeiden Sie es, Namen, E-Mail-Adressen, Dokumente, Dateiinhalte oder vollständige API-Payloads in Protokolle zu kopieren.
Auch eine pseudonyme Benutzerkennung kann sensibel sein, wenn sich damit eine Person wieder identifizieren lässt. Beschränken Sie den Zugriff auf das Protokoll, begrenzen Sie dessen Aufbewahrungsdauer und trennen Sie nach Möglichkeit betriebliche Informationen von der Identität. Fehlermeldungen sollten helfen, das betroffene System zu lokalisieren, ohne personenbezogene Daten in Monitoring-Tools offenzulegen.
Überprüfen Sie das Ergebnis und bereiten Sie Ausnahmen vor
Die Tests müssen sowohl den Normalfall als auch teilweise Fehler abdecken. Verwenden Sie Testdaten und prüfen Sie die im Inventar identifizierten Speicherorte, nicht nur die primäre Tabelle. Berücksichtigen Sie Szenarien wie eine löschverhindernde Beziehung, eine fehlende Datei, einen nicht verfügbaren externen Anbieter, einen erneuten Versuch und eine Ausnahme, die geprüft werden muss.
Eine hilfreiche operative Checkliste fragt: Wurde jede bekannte Kopie gefunden? Wurde in jeder Kategorie die vorgesehene Maßnahme angewendet? Ist ein Schritt noch offen? Haben externe Systeme das Ergebnis bestätigt? Enthalten die Protokolle nur die erforderlichen Informationen? Bleibt der Prozess bei einem erneuten Versuch sicher? Ergänzen Sie regelmäßige Prüfungen, um neue Tabellen, Integrationen oder Datenpfade zu erkennen, die im Inventar noch nicht erfasst sind.
Hypothetisches Beispiel: Schließen eines Kontos
Nehmen wir an, eine Person beantragt, ihr Konto in einer PHP-Anwendung zu schließen. Der Ablauf validiert den Antrag und prüft die festgelegten Regeln für Profil, Dateien, Aktivitäten und Informationen zu laufenden Vorgängen. Das Profil und infrage kommende Dateien werden gelöscht; bestimmte Datensätze werden bei Vorliegen eines genehmigten Grundes mit eingeschränktem Zugriff aufbewahrt; für Analysen vorgesehene Daten bleiben nur erhalten, wenn sie wirksam anonymisiert wurden.
Die Anwendung protokolliert jeden Schritt, ohne die E-Mail-Adresse oder Dateiinhalte aufzunehmen. Antwortet ein externer Dienst nicht, erhält der Fall den Status „ausstehend“; ein späterer Prozess startet je nach Richtlinie einen erneuten Versuch oder fordert einen Eingriff an. Der Fall wird erst dann als abgeschlossen markiert, wenn alle erforderlichen Maßnahmen bestätigt wurden oder eine formelle Ausnahme dokumentiert und genehmigt ist.
Klären Sie vor der Implementierung noch offene Entscheidungen: Welche Systeme enthalten die Daten? Wer genehmigt Ausnahmen? Was bedeutet „abgeschlossen“ für jedes Zielsystem? Wie werden Backups behandelt und wer prüft Fehler? Durch diese Festlegungen wird aus einer Löschabsicht ein wartbarer, überprüfbarer und sicherer Prozess.
