隐私与合规架构 — 当「删除」不再是 DELETEPrivacy & Compliance: Right to Erasure, Anonymization, Audit Trail, Consent

问题场景与约束

设计一个 5000 万用户的多租户 SaaS 数据平台，用户覆盖欧盟。用户点「删除我的账号」，你必须在 30 天内（GDPR Article 17）把他的 PII 从所有地方抹掉——但数据散落在 40 个微服务的 OLTP 库、Snowflake 数仓、Redis 缓存、Kafka 事件流、ES 索引，以及过去 90 天的每一份 DB 备份里。

为什么这是最反直觉的 System Design 题：分布式系统所有的设计习惯都在跟合规作对。append-only、不可变日志、多副本、事件溯源——全为「数据永不丢」；而 GDPR 要的恰是「让特定数据彻底消失并能证明」。约束还包括：删除须可验证、不能误删法定保留数据（税务/反欺诈有最短保留期）、脱敏数据不能被重识别、每次 PII 访问都要留痕。

高层架构

编排器是「删除的事务协调者」；数据目录回答「PII 在哪」；密钥库让删除退化成删一把密钥；审计链证明「确实做了」

四个核心能力：①编排器把删除扇出成几十个子任务并追踪完成（本质是长事务 / Saga）；②数据目录解决「PII 散在哪」这个最致命的问题；③密钥库 + crypto-shredding 把「在备份里物理删除」的不可能任务变成「删一把密钥」；④同意网关在每次处理前检查用户是否授权了该用途。

关键技术点

1. 删除权：Crypto-shredding vs 物理删除 vs Tombstone

原理：GDPR 的删除不要求物理擦除，只要求数据永久不可恢复。这打开了一条捷径——crypto-shredding（加密粉碎）：给每个用户一把独立的数据加密密钥 DEK，用它加密该用户所有 PII；删除时只销毁这把 DEK，散落在 40 个库和 90 份备份里的密文瞬间全部变成无法解密的乱码，无需追杀每一份副本。欧盟数据保护委员会（前 Article 29 工作组）承认加密擦除是有效删除方式。

# Crypto-shredding：删除退化成删一把密钥 (伪代码)
def write_pii(user_id, field, value):
    dek = kms.get_or_create_key(f"user:{user_id}")   # per-user DEK
    db.put(user_id, field, aes_encrypt(dek, value))   # 存的是密文

def read_pii(user_id, field):
    dek = kms.get_key(f"user:{user_id}")              # 密钥没了 → 抛异常 → 视为已删
    return aes_decrypt(dek, db.get(user_id, field))

def erase_user(user_id):
    kms.destroy_key(f"user:{user_id}")   # 唯一动作：备份/数仓/Kafka 里的密文全部报废
    audit.append("ERASE", user_id, proof=kms.key_destroyed_receipt(user_id))

2. 数据脱敏：伪匿名化 vs 匿名化（重识别是死穴）

原理：数仓要做分析、测试环境要仿真数据，但不能直接用真 PII。两条路径法律后果完全不同：伪匿名化（pseudonymization）——把姓名换成 token、但保留一张可逆映射表——数据仍属于 PII，仍受 GDPR 全约束（映射表泄露即前功尽弃）；匿名化（anonymization）——彻底切断与个人的关联、不可逆——才脱离 GDPR 管辖。难点是「彻底」几乎做不到：去掉姓名远远不够，准标识符（quasi-identifier）的组合能重识别——经典结论：邮编 + 生日 + 性别三者组合就能唯一定位美国绝大多数人。

3. 审计追踪：不可篡改地证明「谁碰了 PII」

原理：合规不仅要「做对」，还要能举证做对了。审计日志记录每一次 PII 的访问 / 修改 / 删除 / 导出——谁、何时、为何、动了哪条。要求是 append-only + tamper-evident（防篡改可检测）：即便 DBA 有 root，也不能悄悄改历史。核心技术是哈希链：每条日志带上「前一条的哈希」，形成链条，改中间任一条会让后续所有哈希对不上——和区块链同源思想（见 Day 36），但无需共识，单机 Merkle/哈希链即可。

# Tamper-evident 审计链 (伪代码)
def append_audit(actor, action, subject_id, purpose):
    prev = store.last().hash if store.last() else GENESIS
    entry = {actor, action, subject_id, purpose, ts, prev_hash: prev}
    entry.hash = sha256(canonical(entry))   # 含 prev_hash → 链式绑定
    store.append(entry)                      # WORM / 只追加介质
# 校验：从头重算每条 hash，任一处对不上 → 有人篡改过

4. 同意管理：把「用户授权了什么用途」当作真相源

原理：GDPR 的核心是目的限制（purpose limitation）——为「发货」收集的地址不能拿去「精准广告」。所以同意不是注册时勾一次的 checkbox，而是一个 (用户 × 用途 × 状态 × 时间) 的真相源，且必须能实时传播到每个下游处理点：营销服务处理前先问「这个用户同意 marketing 了吗？」——像 policy / feature flag 一样在数据流里当门禁。撤回同意（withdraw）要像删除一样级联：不仅停止未来处理，已流入下游管道的数据也要按用途清理。

扩展与优化

• 数据目录自动化：手工维护「PII 在哪」必然漂移。用 schema 扫描 + 分类器（正则/ML 识别邮箱、身份证、信用卡）自动打标签，编排器据此扇出，避免漏删。
• 删除即 Saga：跨 40 个服务是长事务，用编排器 + 每服务幂等删除接口 + 重试 + 死信，任一步失败可补偿重放；核对「所有子任务 done」才对用户标记完成。
• 法定保留豁免：删除前先过「保留策略引擎」——税务发票、反欺诈记录有法定最短保留期，这些字段脱敏而非删除，删的是可删部分。
• 数据本地化联动：欧盟 PII 的密钥与密文都留在欧盟区（见 Day 42 多区域），crypto-shred 的密钥库也要按区隔离。

常见陷阱 + 面试问题

• 用户请求删除，数据在 40 个服务 + 数仓 + 90 天备份里，你怎么设计端到端删除并证明删干净？
• Crypto-shredding 的密钥库本身是单点，KMS 数据损坏会怎样？怎么在「可删」和「别把活人数据锁死」之间平衡？
• 为什么去掉姓名的数据仍可能重识别？举例说明准标识符攻击，以及 k-匿名如何被同质性攻破。
• 用户撤回了广告同意，但事件已进入 Kafka 下游管道。怎么保证下游停止用它做广告，并证明？
• append-only 审计链和「删除权」直接冲突，你如何同时满足两者？

深入资源

• 《Designing Data-Intensive Applications》Ch 12（Kleppmann）：结尾专门讨论数据的伦理、追踪与「被遗忘」的系统性难题。
• GDPR Article 17 & 25 原文：删除权与「Privacy by Design / by Default」——合规架构的法条起点。
• 《Forgotten @ Scale》（IBM, arXiv:1910.13784）：大规模系统落地删除权的设计模式（定位 / 删除 / 证明）。
• Sweeney, k-Anonymity（2002）：准标识符与重识别的奠基论文；配合差分隐私（Dwork）理解隐私的数学边界。
• AWS KMS / Kafka crypto-shredding 官方与社区文档：信封加密与 per-key 删除的工程落地。

深入思考