PII 进日志到底脱敏还是加密？合规线与可观测性这道题，你们线上怎么解？

背景 最近一次线上事故复盘，我被夹在两个要求之间：

• 安全/合规侧：日志里不能出现明文手机号、身份证、卡号，审计要能证明「日志无 PII」，出问题要能拿日志去交差；
• SRE/研发侧：支付失败链路里，用户手机号 + 订单号是唯一定位依据，脱敏后只能拿到 138****1234，等排到人肉去数据库反查，MTTR 直接翻倍。

这不是我们一家的问题：安全团队按「最小暴露」写红线，SRE 按「可观测性优先」写告警——两条线一碰就打架，最后通常是「先脱敏上线，出事再补权限」这种带病上线。

常见分歧 / 几种做法

1. 应用层脱敏：业务代码在写日志前调 MaskUtil.mask(phone)。
   • 优点：源头控制，网关不用改。
   • 缺点：散落各处、漏一处全盘皆输；新接口 / 新字段靠 code review 兜底，实际漏的不少。
2. 网关 / sidecar 统一脱敏：按 header、path、body 字段白名单做正则替换。
   • 优点：一处收口，新服务默认安全。
   • 缺点：正则维护地狱；结构化日志字段（JSON body 里的 userId、cardNo）识别成本高；对「看起来不是 PII、实际是 PII」的字段无能为力。
3. 双份日志：脱敏版给审计 / 外发，原始版进独立存储（加密 + 权限隔离 + 短 TTL，比如 7 天），排查走审批临时放开。
   • 优点：合规与可观测性各取所需。
   • 缺点：存储成本翻倍；原始日志本身就是「高价值攻击目标」，权限模型设计不好等于给内鬼留后门。
4. 字段级加密 + 密钥分离：PII 字段应用层用 KMS 加密后再写日志，密钥由独立服务持；排查时用「解密工具」按需还原。
   • 优点：日志里「看起来就是乱码」，脱敏和加密语义更接近合规要的东西。
   • 缺点：日志检索基本废掉；解密工具本身就是新的攻击面。

我的倾向与理由 我偏向 2（网关统一脱敏）+ 3（双份日志，短 TTL）+ 严格权限模型 的组合，理由：

• 应用层脱敏（方案 1）在大规模微服务下一定会漏，靠人兜底不可持续；
• 加密方案（方案 4）对「日志要能 grep」这个核心诉求伤害太大，我不建议作为默认；
• 双份日志的关键不是「多存一份」，而是 原始日志的访问审批 + 审计留痕 + 短 TTL，这三样任何一样缺失，方案就退化成「把明文换个地方存」。

一个容易忽略的点：脱敏规则本身要版本化、要能回放——事故复盘时你需要的不只是「当时的脱敏结果」，还有「当时用的哪一版脱敏规则」，否则审计追到底就断链了。

想听大家在什么场景下怎么选

1. 你们线上 PII 脱敏是应用层、网关层还是混合？有没有踩过「漏脱敏字段」的真实案例，最后怎么收口的？
2. 双份日志有没有人真跑起来？原始日志的存储成本、访问审批流、TTL 你们分别怎么定的？
3. 有没有团队用字段级加密替代脱敏？解密工具本身怎么做权限与审计？
4. 合规审计方（内审 / 外审 / 监管）对「脱敏 vs 加密」到底有没有硬性区分？有没有因为「只是脱敏、没加密」被点名整改的案例？
5. 一个更尖锐的问题：如果只能选一条红线，你选「日志里不允许出现 PII」还是「PII 必须以加密形态存储」？

欢迎把你们的规则表、审批流、事故复盘片段贴出来，比抽象讨论有用。