Können Sie Daten löschen, wenn es nötig ist? Eine Checkliste für Aufbewahrung und Löschung bei selbst gehosteten Anwendungen

Warum die Löschfähigkeit ein Kriterium für die Anwendungsauswahl ist – und nicht nur eine Aufgabe für die Datenschutzrichtlinie

Eine Anwendung kann einfach bereitzustellen, zu exportieren und zu sichern sein und dennoch schwer zu steuern sein, wenn Informationen entfernt werden müssen. Die praktische Frage ist nicht nur, ob die Oberfläche eine Schaltfläche „Löschen“ bietet. Entscheidend ist, ob Ihr Team die betreffenden Daten auffinden, die richtige Aufbewahrungsregel anwenden, begründete Ausnahmen wahren und nachweisen kann, was geschehen ist.

Das ist für personenbezogene Daten relevant, aber auch ein operatives Thema für Kundendatensätze, Mitarbeiterdaten, hochgeladene Dateien, Kommentare, Zugangsdaten, Projektmaterial und Diagnoseinformationen. Die Datenschutzleitlinien der Europäischen Kommission zur DSGVO beschreiben Speicherbegrenzung als die Pflicht, personenbezogene Daten nicht länger als nötig aufzubewahren und Fristen für deren Löschung oder Überprüfung festzulegen. Das ist ein hilfreiches Betriebsprinzip, auch wenn die DSGVO nicht der einzige für Ihre Organisation geltende Rahmen ist.

Behandeln Sie die Löschfähigkeit als Einführungskriterium. Bewerten Sie sie während einer Testphase oder eines Proof of Concept, solange Sie noch eine andere Anwendung wählen oder ausgleichende Kontrollen gestalten können. Gehen Sie nicht davon aus, dass Selbsthosting die Löschung einfach macht: Daten können über die Anwendungsdatenbank, persistenten Speicher, Backups, Logs und verbundene Dienste verteilt sein.

• Machen Sie Aufbewahrung und Löschung neben Zugriffskontrolle, Exporten sowie Sicherung und Wiederherstellung zu einem dokumentierten Abnahmekriterium.
• Bewerten Sie die tatsächlich bereitgestellten Komponenten, nicht nur die Produktdokumentation oder Bezeichnungen in der Benutzeroberfläche.
• Fordern Sie einen wiederholbaren Test mit Beispieldaten, bevor Sie Produktionsdaten im System speichern.
• Beziehen Sie bei rechtlichen, vertraglichen und branchenspezifischen Fragen zur Aufbewahrung die zuständigen internen oder externen Berater ein.

Beginnen Sie mit einem Dateninventar: Datensätze, Dateien, Kommentare, Benutzerprofile, Audit-Ereignisse, Logs, Exporte und abgeleitete Daten

Informationen, die Sie nicht erfasst haben, können Sie nicht zuverlässig löschen. Erstellen Sie ein Inventar nach Datenarten und Kopien, statt sich auf eine einzelne Kategorie wie „Kundendaten“ zu verlassen. Beginnen Sie mit dem, was Benutzer sehen können, und verfolgen Sie dann die technischen Wege, über die Daten verarbeitet, repliziert oder aufbewahrt werden.

Erfassen Sie für jede Kategorie den Systemstandort, den Datenverantwortlichen, den Zweck, die Aufbewahrungsregel, die Löschmethode, die Zugriffsrollen, Integrationen, die Behandlung in Backups und die Nachweisquelle. Die NIST-Leitlinien zum Log-Management erinnern daran, dass Aufbewahrung und Entsorgung sowohl auf System- als auch auf Infrastrukturebene gelten; Anwendungsdaten allein bilden nicht das vollständige Inventar.

Berücksichtigen Sie abgeleitete und operative Kopien. Ein Name oder Kennzeichen kann in einem Kommentar, Dateianhangsnamen, exportierten Tabellenblatt, einer Benachrichtigung, einem Suchindex, Cache-Eintrag oder in Log-Metadaten vorkommen. Die Docker-Dokumentation weist außerdem darauf hin, dass Logging-Treiber Werte von Umgebungsvariablen und Labels eines Containers in die Log-Ausgabe aufnehmen können. Prüfen Sie daher, was Ihre Bereitstellung in diesen Feldern hinterlegt.

• Primäre Datensätze: Kontakte, Transaktionen, Projekte, Tickets, Inhalte, Formulare und Geschäftsobjekte.
• Benutzerbezogene Daten: Profile, Authentifizierungskennungen, Rollen, Einstellungen und Kontostatus.
• Von Benutzern erstellte Inhalte: Uploads, Anhänge, Kommentare, Revisionen, Bilder und eingebettete Dokumente.
• Betriebsdaten: Audit-Ereignisse, Anwendungs-Logs, Container-Logs, Datenbank-Logs, Fehlerberichte und gegebenenfalls Metriken.
• Abgeleitete Kopien: Exporte, Berichte, Suchindizes, Caches, Vorschauen, Benachrichtigungen und Payloads von Hintergrundjobs.
• Speicher- und Resilienzkopien: Datenbank-Dumps, persistente Volumes, Snapshots von Dateispeichern und Backup-Archive.
• Externe Kopien: E-Mail-Anbieter, Identitätsanbieter, Webhook-Empfänger, Analyseplattformen, Automatisierungstools und Objektspeicher.

Definieren Sie die Ereignisse, die Aufbewahrung, Löschung, Anonymisierung oder Legal Hold auslösen

Ein Aufbewahrungsplan sollte ereignisgesteuert sein. „Zwei Jahre aufbewahren“ ist unvollständig, solange nicht klar ist, wann die Frist beginnt, was sie beendet, wer eine Ausnahme genehmigt und wie die Regel umgesetzt wird. Häufige auslösende Ereignisse sind Kontoschließung, Vertragsende, Projektabschluss, Widerruf einer Einwilligung, abgeschlossene Supportarbeit und ein genehmigter Löschantrag.

Trennen Sie Löschung von Anonymisierung. Löschung zielt darauf ab, die identifizierten Daten innerhalb des festgelegten Systemumfangs zu entfernen. Anonymisierung kann einen Datensatz für Berichte nutzbar lassen, jedoch nur dann, wenn er im jeweiligen Kontext keine Person mehr identifiziert. Bezeichnen Sie das bloße Entfernen eines Anzeigenamens nicht als Anonymisierung, ohne die verbleibenden Felder und ihre Verknüpfbarkeit zu bewerten.

Definieren Sie außerdem Verfahren für Legal Hold oder Aufbewahrungsanordnungen, bevor ein dringender Fall eintritt. Artikel 17 der DSGVO begründet unter bestimmten Umständen ein Recht auf Löschung, dieses ist jedoch bedingt und nicht absolut. Auch NIST-Leitlinien fordern, dass Aufbewahrungsanfragen festlegen, wie betroffene Log-Datensätze gekennzeichnet, gespeichert und geschützt werden. Ihr Workflow benötigt eine dokumentierte Möglichkeit, die routinemäßige Vernichtung bei einer gültigen Verpflichtung auszusetzen, die Aufbewahrungsanordnung zugleich auf die betroffenen Informationen zu begrenzen und sie regelmäßig zu überprüfen.

• Definieren Sie für jede Datenklasse: auslösendes Ereignis, Aufbewahrungsfrist oder Überprüfungsintervall, Maßnahme, Genehmiger, Ausnahmepfad und aufbewahrte Nachweise.
• Geben Sie an, ob die Maßnahme dauerhafte Löschung, Archivierung, eingeschränkte Aufbewahrung, Anonymisierung oder Pseudonymisierung ist.
• Dokumentieren Sie den Umfang eines Legal Hold: betroffene Angelegenheiten, Datenquellen, Startdatum, Verwahrer, Zugriffsbeschränkungen und Überprüfungsdatum.
• Protokollieren Sie den Grund, wenn ein Löschantrag abgelehnt, verzögert oder nur teilweise erfüllt wird.
• Legen Sie fest, wie eine Aufbewahrungsanordnung endet und wie die normale Verarbeitung im Datenlebenszyklus danach wieder aufgenommen wird.

Testen Sie, was „Löschen“ in der Anwendung bedeutet: Soft Delete, dauerhafte Löschung, Archivierung und Kontodeaktivierung

Begriffe in einer Benutzeroberfläche sind keine technischen Garantien. „Löschen“, „entfernen“, „archivieren“, „deaktivieren“ und „sperren“ können sehr unterschiedliche Ergebnisse erzeugen. Ein gelöschtes Element kann für normale Benutzer ausgeblendet sein, aber für Administratoren weiterhin verfügbar bleiben; ein Konto kann sich möglicherweise nicht mehr anmelden, während sein Profil und seine Inhalte unverändert erhalten bleiben; ein Archiv kann den vollständigen Datensatz bewusst aufbewahren.

Führen Sie einen kontrollierten Test mit synthetischen, eindeutig identifizierbaren Daten durch. Erstellen Sie einen Datensatz, zugehörige Kommentare, einen Anhang und – sofern die Anwendung es zulässt – ein Benutzerkonto. Führen Sie anschließend jede verfügbare Aktion aus und prüfen Sie die erwarteten benutzerseitigen und administrativen Ergebnisse. Testen Sie Rollengrenzen: Können normale Benutzer, Manager, Administratoren und API-Clients die Inhalte weiterhin finden oder abrufen?

Wenn die Anwendung PostgreSQL verwendet, unterscheiden Sie zwischen Sichtbarkeit auf Anwendungsebene und der unmittelbaren physischen Entfernung alter Zeilenversionen. PostgreSQL erläutert, dass unter MVCC ein DELETE oder UPDATE die alte Zeilenversion nicht sofort entfernt; VACUUM gibt den Speicher später zur Wiederverwendung frei. Standard-VACUUM macht Speicher im Allgemeinen wiederverwendbar, statt ihn an das Betriebssystem zurückzugeben, während VACUUM FULL eine Tabelle zur Verdichtung neu schreibt. Dies ist eine Tatsache der Datenbankwartung, kein Grund, Anwendungskontrollen zu umgehen oder unbelegte Behauptungen über Wiederherstellbarkeit aufzustellen. Legen Sie gemeinsam mit qualifizierten technischen und Compliance-Verantwortlichen den für Ihren Anwendungsfall geeigneten Prüfstandard fest.

• Fehlt das Element in normalen Ansichten, Suchen, APIs und administrativen Oberflächen?
• Kann ein Administrator es wiederherstellen? Falls ja: unter welcher Rolle und wie lange?
• Erfasst die Löschung auch untergeordnete Datensätze, Kommentare, Anhänge und Revisionen?
• Unterscheidet sich das Löschen eines Kontos von dessen Deaktivierung oder dem Entzug des Zugriffs?
• Stellt die Anwendung einen Export oder Audit-Nachweis der Aktion bereit, ohne unnötige Inhalte aufzubewahren?
• Sind Massenlöschungen und automatisierte Aufbewahrungsmaßnahmen verfügbar, oder ist nur eine manuelle Verarbeitung möglich?

Verfolgen Sie zugehörige Daten: Anhänge, Revisionen, Suchindizes, Benachrichtigungen, Caches und Daten aus Hintergrundjobs

Ein erfolgreicher Löschtest folgt Beziehungen und nicht nur dem Hauptdatensatz. Beginnen Sie mit einem bekannten Marker in Ihrem synthetischen Datensatz und suchen Sie in allen zugehörigen Inhalten danach. Prüfen Sie Datenbanktabellen nur, wenn Sie dazu berechtigt und fachlich qualifiziert sind; andernfalls bitten Sie den Anwendungsbetreuer, das Datenmodell zu erläutern und unterstützte Nachweise bereitzustellen.

Anhänge erfordern besondere Aufmerksamkeit, weil sie in einer Datenbank, einem lokalen persistenten Verzeichnis oder einem externen Objektspeicher liegen können. Revisionen und Dokumentvorschauen können die aktuelle Version überdauern. Suchindizes und Caches können vorübergehend veraltet bleiben. E-Mail-Benachrichtigungen und eingereihte Hintergrundjobs können bereits kopierte Werte enthalten. Legen Sie fest, welche Verzögerung – falls überhaupt – für jede Komponente akzeptabel ist und wie Sie die letztendliche Entfernung überprüfen.

Die Konfiguration des Objektspeichers kann die Bedeutung von „Löschen“ verändern. AWS dokumentiert, dass bei einem S3-Bucket mit aktivierter Versionierung eine Löschanfrage ohne Versions-ID einen Löschmarker hinzufügt, statt das Objekt dauerhaft zu löschen. Für eine dauerhafte Löschung müssen die angegebenen aufbewahrten Versionen gelöscht werden. Wenn eine Anwendung versionierten Objektspeicher oder einen kompatiblen Dienst verwendet, testen Sie das genaue Speicherverhalten und Ihre Möglichkeit, jede relevante Version zu identifizieren.

• Dokumentieren Sie den Speicherort von Anhängen und ob Dateien kopiert, umgewandelt oder in einer Vorschau dargestellt werden.
• Prüfen Sie Revisionen, Verlauf, Papierkorb- oder Recycling-Funktionen und deren Ablaufeinstellungen.
• Suchen Sie vor und nach der Löschung über die unterstützte Anwendungssuche und APIs nach dem Testmarker.
• Ermitteln Sie das Aktualisierungsverhalten von Caches und Indizes, einschließlich asynchroner Jobs.
• Prüfen Sie Benachrichtigungsvorlagen, E-Mail-Zustellwege und Job-Warteschlangen auf kopierte Inhalte.
• Überprüfen Sie bei externem Objektspeicher Versionierung, Löschmarker, Lebenszyklusregeln und Löschbelege.

Prüfen Sie verbundene Systeme: Identitätsanbieter, E-Mail-Dienste, Webhooks, Analyseplattformen, Automatisierungstools und externen Speicher

Integrationen machen Anwendungsdaten nützlicher, erweitern aber die Grenze der Löschung. Eine Anwendung kann einen lokalen Datensatz entfernen, während ein E-Mail-Anbieter eine Benachrichtigung aufbewahrt, ein Automatisierungsworkflow seinen Payload speichert, ein Webhook-Ziel eine Kopie erhält oder ein Identitätsanbieter Kontoattribute nach eigenen Lebenszyklusregeln aufbewahrt.

Dokumentieren Sie jede ausgehende und eingehende Verbindung. Ermitteln Sie für ausgehende Datenflüsse, welche Felder übertragen werden, ob ein vollständiger Payload oder nur ein Kennzeichen gesendet wird, ob Wiederholungsversuche oder Dead-Letter-Verarbeitung Daten aufbewahren und ob der Empfänger sie löschen kann. Ermitteln Sie für eingehende Datenflüsse, ob das externe System einen Datensatz nach dessen Löschung erneut erzeugen kann.

Dies ist auch ein Entscheidungspunkt. Wenn eine kritische Integration Ihre Aufbewahrungsanforderungen nicht unterstützen kann und keine akzeptable architektonische Alternative existiert, sollten Sie eine lokale Schaltfläche „Löschen“ nicht als ausreichend betrachten. Wählen Sie ein anderes Integrationsdesign oder eine andere Anwendung.

• Identität: Kontokennungen, Profilattribute, Deprovisionierungsprozess und Regeln für das führende System.
• E-Mail: Nachrichteninhalte, Anhänge, Zustell-Logs, Sperrlisten und Aufbewahrungskontrollen.
• Webhooks und Automatisierung: Payload-Inhalte, Wiederholungsversuche, Workflow-Verläufe, Ausführungs-Logs und nachgelagerte Empfänger.
• Analyse: Ereignisfelder, Kennungen, gegebenenfalls IP-bezogene Daten und Löschschnittstelle.
• Externer Speicher: Objektlebenszyklus, Versionierung, Replikate, Zugriffskontrollen und Audit-Aufzeichnungen.
• Dokumentieren Sie für jedes verbundene System und jeden Löschpfad einen Ansprechpartner oder Verantwortlichen.

Trennen Sie die Löschung von Live-Daten von Backup-Aufbewahrung und Wiederherstellungsverfahren

Die Löschung von Live-Daten und das Ablaufen von Backups lösen unterschiedliche Probleme. Das Entfernen von Informationen aus der Produktionsanwendung entfernt sie nicht automatisch aus bereits erstellten Backup-Archiven. Umgekehrt belegt das Ablaufen von Backups nicht, dass die Live-Anwendung einen Datensatz gelöscht hat. Dokumentieren Sie beide Lebenszyklen ausdrücklich.

Docker weist darauf hin, dass ein Daten-Volume nach dem Löschen seines Containers bestehen bleibt. Das Löschen oder Neuerstellen eines Containers ist daher kein Nachweis dafür, dass die zugrunde liegenden Anwendungsdaten entfernt wurden. Docker dokumentiert außerdem Verfahren zum Sichern von Volume-Inhalten und zu deren Wiederherstellung in dasselbe oder ein anderes Container-Volume. Deshalb gehören Wiederherstellungspfade in die Bewertung.

Bei einer von Airbip verwalteten Anwendung laufen Instanzen als Docker-Workloads auf Airbip-Cloud-Servern, und Airbip bietet konfigurierbare tägliche, wöchentliche und monatliche Backups. Kunden sollten den erforderlichen Backup-Zeitplan und die Aufbewahrungskonfiguration definieren und anschließend bestätigen, wie diese Konfiguration mit den Löschregeln auf Anwendungsebene übereinstimmt. Verwaltete Infrastruktur kann Abläufe im Datenlebenszyklus praktikabel machen, entscheidet jedoch nicht, was Ihre Organisation aufgrund einer Aufbewahrungsanordnung aufbewahren, löschen oder sichern muss.

Testen Sie Wiederherstellungen sicher. Stellen Sie ein Backup, sofern zulässig, in einer isolierten, zugriffskontrollierten Umgebung wieder her, prüfen Sie, ob die erwarteten historischen Daten vorhanden sind, und bestätigen Sie, dass sie nicht mit aktuellen Produktionsdaten verwechselt werden können. Legen Sie fest, wer eine Wiederherstellung genehmigen darf, welche Kontrollen nach der Wiederherstellung gelten und wie wiederhergestellte Daten nach dem Ende des Tests oder Vorfalls behandelt werden.

• Erstellen Sie getrennte Aufbewahrungspläne für Produktionsdaten, Backups, Snapshots und exportierte Archive.
• Ermitteln Sie innerhalb Ihrer dokumentierten Umgebung alle Backup-Speicherorte, Häufigkeiten, Aufbewahrungszeiträume, Verschlüsselungen und Berechtigungen zur Wiederherstellung.
• Legen Sie fest, ob Löschanträge nur zukünftige Backups betreffen und wie lange historische Kopien gemäß dem Backup-Plan verbleiben können.
• Testen Sie ein Wiederherstellungsverfahren, ohne Produktionsdaten zu überschreiben.
• Richten Sie Kontrollen ein, die verhindern, dass die Wiederherstellung eines veralteten Backups Daten unbemerkt wieder in die Produktion einführt.
• Setzen Sie das Entfernen eines Containers, das Entfernen eines Volumes, das Ablaufen eines Backups und die Sanitization von Speichermedien nicht gleich; dies sind getrennte Kontrollen.

Bewerten Sie Nachweise für Administratoren: Löschprotokolle, Audit-Trails, exportierbare Berichte und dokumentierte Grenzen

Ein Löschprozess ist leichter zu verteidigen und zu betreiben, wenn er angemessene Nachweise erzeugt. Sie sollten mindestens den Antrag oder Auslöser, die Entscheidung, den Bediener oder automatisierten Prozess, das Datum, die einbezogenen Systeme, Ausnahmen und den Abschlussstatus identifizieren können. Vermeiden Sie einen Audit-Trail, der unnötigerweise die Daten erneut wiedergibt, die Sie entfernen wollten.

Prüfen Sie, ob die Anwendung Audit-Ereignisse, administrative Berichte oder unterstützte APIs bietet, die diese Nachweise erzeugen können. Sind die Nachweise unvollständig, prüfen Sie, ob eine dokumentierte Betriebsaufzeichnung die Lücke schließen kann. Ein manuelles Register kann bei wenigen Vorgängen akzeptabel sein, wird jedoch anfällig, wenn viele Benutzer, Integrationen oder Speicherorte beteiligt sind.

Logs benötigen eigene Kontrollen. NIST empfiehlt Organisationen, Aufbewahrung, Entsorgung, Sicherung und Verantwortlichkeiten für die Log-Management-Infrastruktur zu regeln. Docker unterstützt mehrere Logging-Treiber und Ziele. Docker erklärt außerdem, dass Änderungen an der Standard-Logging-Konfiguration für neu erstellte Container gelten, während bestehende Container ihre vorhandene Konfiguration bis zu ihrer Neuerstellung beibehalten. Prüfen Sie die bereitgestellte Konfiguration, statt anzunehmen, dass eine Richtlinienänderung bereits jeden Workload verändert hat.

• Können Sie einen Löschbericht mit Status und Zeitstempeln exportieren, ohne unnötige sensible Inhalte offenzulegen?
• Unterscheidet der Audit-Trail zwischen einer Benutzeraktion, einer Administratoraktion und einem automatisierten Aufbewahrungsjob?
• Können Sie eine teilweise Erfüllung, einen Legal Hold oder eine begründete Ablehnung dokumentieren?
• Wohin werden Container-, Plattform- und Anwendungs-Logs übertragen, und wer verantwortet deren Aufbewahrungs- und Entsorgungseinstellungen?
• Erfordern Konfigurationsänderungen die Neuerstellung von Workloads, bevor sie wirksam werden?
• Sind Nachweisaufzeichnungen zugriffskontrolliert und nur so lange aufbewahrt, wie erforderlich?