Erasure by Key Deletion in a Multi-Region SaaS
CareLoop is a SaaS provider for 900 clinics, storing records for 40 million patients in AWS us-east-1 and eu-central-1. Each tenant's objects live under an S3 prefix and are encrypted with a per-tenant data key wrapped by a regional KMS CMK. The company receives about 40 GDPR erasure requests per month with a 30-day deadline. Engineering proposes three changes: (A) replace the regional CMKs with one multi-region key so both regions share key material and operations are simpler; (B) satisfy erasure by scheduling deletion of the tenant CMK, since the data becomes unreadable; (C) support analytics by storing an unsalted SHA-256 hash of each patient's national ID instead of the value. Legal has flagged that some tenants are in the EU and that backups are retained for 35 days in S3 Glacier. Finance notes that KMS deletion windows are 7-30 days and irreversible.
1. Evaluate proposal A. What are the data-residency, blast-radius and operational consequences of a single multi-region key?
Read the worked answer
A multi-region KMS key replicates key material across the regions where it is enabled. That is convenient for disaster recovery and for decrypting replicated objects, but it means EU tenant key material exists in us-east-1. Whether that is a transfer depends on the legal analysis, but it plainly weakens the residency story Legal is relying on, and it removes the ability to say that EU data is decryptable only with a key held in the EU. The safer design is a per-region key hierarchy: a regional CMK per environment, with per-tenant data keys wrapped under the CMK of the region where the tenant's data resides. If cross-region DR is required, define which tenants may replicate and re-wrap only for those tenants, with their consent or contract terms.
Blast radius is the second problem. One key policy shared by 900 tenants means a misconfigured policy, a compromised administrator or an accidental disable affects everyone at once. Per-tenant, per-region keys let an incident or an erasure be scoped to one tenant. Operationally, multi-region keys also encourage engineers to treat key management as a single global object, which makes later residency changes harder.
Recommendation: reject A as proposed. Keep regional keys, standardise the wrapping and rotation process instead, and document the key-to-tenant-to-region mapping. If the real driver is operational toil, automate key creation and rotation rather than collapsing the hierarchy.
2. Evaluate proposal B. Does deleting the CMK achieve erasure within the 30-day deadline, and what would you require before relying on it?
Read the worked answer
Deleting the CMK makes the wrapped data keys unusable, so the ciphertext under that tenant's prefix becomes unreadable, provided no copy of the key material or unwrapped data key survives. That is the theory; the practical gaps are what matter. First, KMS deletion is scheduled 7-30 days ahead and is irreversible. If a request arrives on day 1 and deletion is scheduled for day 30, erasure completes at the edge of the deadline, and any delay pushes it past. Second, backups in Glacier persist for 35 days, which already exceeds the 30-day deadline. If the key is destroyed, those backups remain ciphertext and unreadable, which supports the erasure outcome, but only if no backup contains a plaintext data key or a copy of the CMK. Third, caches, analytics copies, logs and snapshots may hold plaintext or separately wrapped keys outside the prefix.
Before relying on crypto-shredding, require a documented key map, confirmation that the tenant has no legal hold, deletion of every wrapped data key and object version under the prefix, a check that no plaintext copy exists in derived systems, and a recorded deletion certificate. Shorten backup retention for erasure cases or confirm unreadability in writing. Two-person approval should gate irreversible deletion, with a defined exception path if a request is later found to be fraudulent.
Used this way, crypto-shredding is a valid control, but it is a process with evidence, not a single KMS API call.
3. Evaluate proposal C. Does an unsalted SHA-256 hash of a national ID de-identify the data? What would you do instead?
Read the worked answer
No. A national ID has low entropy, often nine to eleven digits with a check character, so the entire input space is small enough to enumerate. An attacker can compute SHA-256 for every candidate and build a lookup table in minutes to hours on ordinary hardware. Unsalted hashing also allows linkage: the same ID produces the same hash across tenants and datasets, so the analytics store becomes a join key that re-identifies people when combined with any other table. Under GDPR the hash remains personal data because identification is reasonably likely.
If analytics genuinely need a stable identifier, use a keyed function: HMAC-SHA-256 with a secret key held in KMS or an HSM, scoped per tenant or per purpose, with rotation and access control. That prevents offline enumeration without the key. Alternatively use tokenisation with a vault, or format-preserving encryption if the downstream system needs the same shape. If the analytics only need to count distinct patients, use a salted, per-dataset hash with a high-entropy salt and accept that cross-dataset joins will not work.
Also question whether the national ID is needed at all; a random pseudonymous identifier generated at ingest is usually sufficient and avoids the legal exposure. Document the purpose, retention and access controls for whichever approach is chosen.