Ihr Backup lässt gelöschte Benutzer stillschweigend wiederauferstehen

Jedes inkrementelle Backup macht dieselbe stille Annahme: Um zu sichern, was sich geändert hat, suche die Zeilen, die sich geändert haben. Auf einem Key-Value-Store wie Azure Table Storage oder DynamoDB heißt „was sich geändert hat": „Zeilen, deren Last-Modified-Zeitstempel neuer ist als meine letzte Wassermarke." Tabelle durchlaufen, alles Neuere einsammeln, wegschreiben. Schnell, billig, korrekt.

Korrekt für Schreibvorgänge. Jetzt löschen Sie eine Zeile.

Die Zeile bekommt kein „gelöscht"-Flag. Sie bekommt keinen neueren Zeitstempel. Sie wandert in keinen Papierkorb. Sie hört einfach auf zu existieren. Diese Stores haben keine Delete-Marker und keinen Change-Feed für Löschungen, eine gelöschte Zeile hinterlässt also exakt nichts. Ihr inkrementelles Backup, das Änderungen über neuere Zeitstempel findet, scannt geradewegs an der leeren Stelle vorbei, an der die Zeile einmal stand, und findet nichts. Es gibt nichts zu finden. Die Löschung ist unsichtbar.

Das heißt: Ihr Backup enthält die Zeile noch. Und genau hier wird aus einer Datenverlust-Geschichte eine Sicherheitsgeschichte.

Überlegen Sie, was eine Löschung in einem Auth-System üblicherweise bedeutet. Sie haben diesen Benutzer nicht zum Spaß gelöscht. Sie haben einen Mitarbeiter im Offboarding entfernt. Sie haben ein Konto gelöscht, dessen Passwort in einem Breach-Dump aufgetaucht ist. Sie haben einen OAuth-Grant widerrufen, nachdem ein Token geleakt war. Sie haben einem Admin am Tag seines Abschieds den Zugriff entzogen. Jede dieser Aktionen ist eine Sicherheitsentscheidung, und keine davon übersteht ein Backup, das Löschungen nicht sehen kann.

Also stellen Sie wieder her. Vielleicht nach einem echten Desaster, vielleicht nur in einen Staging-Klon. Das Backup tut genau, worum Sie es gebeten haben: Es setzt jede Zeile zurück, die es kennt. Der entfernte Mitarbeiter ist wieder ein Benutzer. Das kompromittierte Passwort ist wieder gültig. Der widerrufene Grant funktioniert wieder. Der entfernte Admin ist wieder Admin. Ihre Wiederherstellung hat keine Daten verloren. Sie hat Ihre Sicherheitsentscheidungen rückgängig gemacht, lautlos, und Ihnen ein System übergeben, das gesund aussieht und still kompromittiert ist. Ein Backup, das eine Löschung vergisst, ist schlimmer als kein Backup, weil Sie ihm vertrauen.

Die Lösung: Behandeln Sie eine Löschung nicht länger als die Abwesenheit einer Zeile, sondern als Ereignis. Löschungen sind Daten.

Also geben wir Löschungen ihre eigene Tabelle. Jede Löschung im System läuft durch einen injizierten ITombstoneWriter, der einen Tombstone festhält: den Schlüssel und den Zeitpunkt des Ablebens. Es gibt keinen Codepfad, der eine Zeile löscht, ohne einen Tombstone zu hinterlassen, denn Löschung und Tombstone sind eine einzige Operation. Ein inkrementelles Backup besteht dann aus zwei Teilen, erfasst an einer einzigen Wassermarke: den Upserts (Zeilen mit neuerem Zeitstempel) und den Tombstones (Löschungen seit der letzten Wassermarke). Die Wiederherstellung spielt beide in zeitlicher Reihenfolge ab, eine Löschung greift also genau wie ein Schreibvorgang, und ein Schlüssel, der gelöscht und später neu angelegt wurde, landet bei dem, was zuletzt passiert ist. Die leere Stelle hat endlich einen Eintrag.

Das ist der ganze Trick, und er ist klein. Der Grund, warum er zählt, ist es nicht.

Das Muster überlebt Table Storage und DynamoDB. Jedes System, das eine Löschung als „die Zeile ist weg" modelliert, kann Löschungen nicht sichern, replizieren oder synchronisieren, weil es nichts zu transportieren gibt. Es zeigt sich in naiven Event-Replays, die nur Creates und Updates abspielen. Es zeigt sich in Caches, die ablaufen, aber nie invalidiert werden. Es zeigt sich in Read-Replicas, die auseinanderdriften, weil die Löschung nie ankam. Und am gefährlichsten ist es genau dort, wo Löschungen Ihr Mittel sind, Sicherheit durchzusetzen, was in einem Identity-System überall ist: Widerruf, Offboarding, Rotation, Sperrung. Wenn Ihre Durability-Geschichte nur das erfasst, was existiert, wird sie treu und brav das bewahren, was Sie mit viel Aufwand aus der Existenz entfernt haben.

Prüfen Sie Ihre eigenen Backups also mit einer einzigen Frage: Wenn ich jetzt sofort einen Benutzer lösche, ein Backup ziehe und es wiederherstelle, ist dieser Benutzer dann weg? Wenn die ehrliche Antwort „Ich bin nicht sicher" lautet, ist Ihr Backup eine Zeitmaschine, die in die falsche Richtung zeigt. Sie schützt Sie nicht vor Ihren Fehlern. Sie erweckt sie wieder zum Leben: das Passwort, das Sie rotiert haben, den Mitarbeiter, den Sie entfernt haben, das Token, das Sie widerrufen haben.

Löschungen sind Daten. Sichern Sie sie auch so.

Wenn Sie lieber hätten, dass Ihre Backups eine Löschung respektieren, ohne dass Sie es beweisen müssen, ist genau das der Zweck einer Plattform. Authagonal versieht jede Löschung mit einem Tombstone, eine Wiederherstellung bringt also niemals ein widerrufenes Credential zurück.