議論： Deletion pipelines across services, derived stores and backups

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

Stores that keep deleted data by design and belong on the data map with their own bound. S3 Object Lock in compliance mode makes an object undeletable by any principal, including the account root, until its retention date; a bucket configured that way cannot honour a deletion at all and should be recorded as such rather than fanned out to. Kafka keeps records in a non-compacted topic for `retention.ms` regardless of any deletion, and in a compacted topic a deletion is a tombstone (a record with a null value) that removes earlier values for the key only after compaction runs and is itself kept for `delete.retention.ms`. Elasticsearch marks deleted documents in Lucene segments; the bytes remain until a segment merge, so a force merge with `only_expunge_deletes` is what actually removes them. PostgreSQL's WAL archive and base backups for point-in-time recovery contain the rows until the archive's own retention, and logical replication slots hold WAL back as long as a consumer lags. CDN and browser caches follow `Cache-Control` and are bounded by it. Each of these is a store with a delay that the job's per-store record can state as 'deleted, visible until <date>' instead of 'done'.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

Step 5 offers 'encrypt per subject and destroy the key' as an alternative for backups on equal footing with a retention bound, and for a relational database it is not a real option. Cryptographic erase of one person's rows presupposes that those rows were written encrypted under that person's key in the primary store, since the backup is a physical copy of the same pages. Per-subject encryption of columns in a relational table means no index on those columns, no join or filter on them, no `GROUP BY`, and a key lookup per row on every read, and every derived store and analytics copy would have to carry the same scheme; the pipeline the article describes for derived stores (delete by subject identifier or rebuild) assumes plaintext identifiers there. NIST SP 800-88's cryptographic erase, which the step cites, is defined for media and for data encrypted as a whole, and its condition that the key is held nowhere else fails as soon as an envelope key in a key-management service is itself backed up. Crypto-shredding fits the stores where per-object keys are natural: documents, media and message bodies in object storage, where one key per subject or per object costs nothing. The step should say which data class each mechanism applies to: retention bound plus suppression list for relational backups, per-subject keys for blobs.