Der Dienstleister sagte, die Daten seien gelöscht. Nach einem Sicherheitsvorfall bei seinem Logistikdienstleister ShipMonk erklärte Trezor jedoch, dort seien zusätzliche historische Bestelldaten aus den Jahren 2019 bis 2021 verblieben. Nach Angaben von Trezor waren 80’689 Kunden betroffen.
Der Fall zeigt nicht bloss fehlende Vertragstreue. Er stellt eine unangenehme Frage: Wann darf eine Organisation sagen, dass Daten wirklich gelöscht sind?
Die Antwort lautet nicht einfach: wenn der Datensatz aus der Anwendung verschwunden ist. Entscheidend ist, ob er noch wiederhergestellt werden kann. Denn eine Löschentscheidung kann beim nächsten Wiederanlauf aus einer Sicherung stillschweigend rückgängig gemacht werden.
Ein Löschauftrag ist kein Löschbeweis
Ein Vertrag beschreibt, was ein Dienstleister tun soll. Er beweist nicht, welche Kopien tatsächlich noch vorhanden sind. Das können historische Backups, Supportexporte oder technische Replikate sein. Genau dort liegt das Risiko: Daten verschwinden aus dem laufenden Betrieb, bleiben aber in einem Bestand, den niemand mehr als produktiv betrachtet und deshalb kaum kontrolliert.
Für Betroffene spielt dieser Unterschied keine Rolle. Wenn die Daten bei einem Vorfall vorhanden sind, können sie betroffen sein. Eine Löschbestätigung ohne prüfbare Evidenz ist deshalb keine Kontrolle, sondern eine Behauptung über einen Zustand, den das Unternehmen im Ernstfall erklären können muss.
Die Wiederherstellbarkeit entscheidet
Ein Datensatz in einer produktiven Datenbank kann gezielt gelöscht werden. Das verhindert seine normale Nutzung. Eine Sicherung hat jedoch eine andere Aufgabe: Sie hält gerade einen älteren Zustand für den Wiederanlauf bereit. Solange dieser Zustand wiederhergestellt werden kann, sind die Daten technisch noch vorhanden.
Das ist nicht immer falsch. Unveränderbare Backups schützen vor Manipulation und ermöglichen den Wiederanlauf nach einem Angriff. Die bewusste Aufbewahrung bis zum Ablauf einer definierten Frist kann deshalb angemessen sein. Sie darf nur nicht als vollständige Löschung verkauft werden. Es ist eine begrenzte Restaufbewahrung mit einem klaren Schutzauftrag.
Besonders gefährlich sind Kopien ausserhalb dieses Plans. Ein Supportpaket, eine Testumgebung oder ein Export für eine Fehleranalyse fällt oft nicht unter den geregelten Backup-Lebenszyklus. Fehlt dort ein Eigentümer und eine Frist, wird die Löschung aus der Produktivumgebung wertlos.
Es gibt keine universelle Löschmethode
Wo das Speicherverfahren es erlaubt, ist die gezielte Bereinigung die sauberste Lösung. Sie entfernt Daten aus aktiven Datenbanken, Dateien und kontrollierbaren Replikaten. Wirksam ist sie erst, wenn das Ergebnis nicht nur protokolliert, sondern nachvollziehbar geprüft wird.
Bei verschlüsselten Beständen kann die Vernichtung des ausschliesslich zugehörigen Schlüssels den Zugriff beenden. Diese kryptografische Löschung funktioniert aber nur, wenn keine Schlüsselkopie und keine unverschlüsselte Nebenablage bestehen. «Verschlüsselt» ist kein Beleg, solange nicht klar ist, welcher Schlüssel wo liegt und wer ihn noch verwenden kann.
Bei unveränderbaren Sicherungen bleibt oft eine bewusste Restaufbewahrung bis zum kontrollierten Ablauf. Reicht das Schutzniveau nicht aus, muss die ganze Sicherungskette saniert oder ersetzt werden. Das kostet Wiederherstellungsoptionen. Genau dieser Zielkonflikt gehört in den Entscheid, nicht in eine technische Fussnote.
Der Wiederanlauf muss die Löschung respektieren
IT Service Continuity Management, kurz ITSCM, plant den Wiederanlauf nach einem Ausfall. Es bestimmt damit auch, welche historischen Daten wieder zurückkommen können. Ein Restore-Prozess muss deshalb festlegen, ob gelöschte Daten nach der Wiederherstellung erneut entfernt werden, wie lange sie in einer Sicherung verbleiben dürfen und wann eine neue saubere Sicherungskette beginnt.
Der belastbare Nachweis besteht nicht aus einer Bestätigung des Dienstleisters. Er braucht ein Dateninventar, eine Zuordnung der Kopien zu ihrer Aufbewahrungsfrist, technische Protokolle und getestete Wiederherstellungen. Erst ein Test zeigt, ob der Wiederanlauf die beschlossene Löschung respektiert oder alte Daten wieder dauerhaft in den Betrieb trägt.
Die Frage, die vorher beantwortet sein muss
Nicht «Wurde der Datensatz gelöscht?», sondern: «Aus welchen Beständen kann er noch zurückkehren, wer kann darauf zugreifen und wann endet diese Möglichkeit nachweisbar?» Diese Frage verbindet Datenverantwortung, Betrieb, Informationssicherheit und Notfallvorsorge. Die Daten sind erst dann wirklich gelöscht, wenn ihre Wiederherstellung für den definierten Schutzzweck nicht mehr möglich ist. Andernfalls braucht es einen bewussten Entscheid über Dauer, Zugriff und Risiko der Restaufbewahrung. Alles andere ist nur Löschung im laufenden Betriebsdatenbestand.
Quellen
- Trezor: Sicherheitsvorfall bei ShipMonk
- BleepingComputer: erweiterte Betroffenenzahl
- NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization
- NIST: Contingency planning
Autor
Dieser Beitrag stammt von Martin Bischoff, Interim CIO/CISO für regulierte Organisationen in der DACH-Region und Herausgeber von STOP.LI. Für die Umsetzung steht seine Gesellschaft 4T2 Solutions GmbH zur Verfügung.
Comments are closed