安全审计日志里"敏感字段到底打不打"，你们是在哪一层做脱敏的？

【背景】 做了 8 年安全加固，我最近在给一个 20+ 微服务的团队做审计日志改造，被同一个问题反复问："支付流水里那个卡号字段、登录日志里那个手机号，到底该不该打？"——听起来是个二选一，实际牵出来的分歧比我预期的多得多。

打个比方：审计日志像监控摄像头。你要么装摄像头但画面糊到看不清人（合规但没用），要么画面高清到能读出工牌（好用但出了内鬼就是灾难），要么装个"智能模糊"的——人脸自动打码、车牌保留后四位（既要又要，工程上最贵）。大多数团队卡在这第三种方案的"智能"两字上。

【常见分歧 / 几种做法】 我在三家不同公司见过三种典型姿势：

1. 应用层脱敏：业务代码里统一 SensitiveMaskUtil.mask(...)，日志框架拦截器再兜一层。优点：最贴近数据语义，知道哪个字段是卡号、哪个是姓名；缺点：每个新接口都要记着调，漏一个就是漏一次，安全审计时还得逐接口 grep 一遍 log.info。
2. 网关 / Sidecar 层脱敏：在 API 网关或 sidecar 里按 JSON path 规则统一抹掉敏感字段。优点：业务无感、集中治理；缺点：网关不认识业务语义，"订单号"和"身份证号"长得一样，只能靠字段名硬编码，遇到 data、payload 这种万能字段就抓瞎。
3. 日志采集 / 存储层脱敏（Logstash / FluentBit / ELK ingest pipeline）：日志先原样落盘或过内存，采集时按正则/规则抹。优点：对运行时零侵入；缺点：敏感数据在内存和磁盘上"裸奔"过一段路，一旦采集管道挂了、日志落本地磁盘，脱敏就形同虚设——相当于先拍裸照再打码，照片本身已经留下了。

【我的倾向与理由】 我个人更倾向 1+3 组合：应用层做语义级脱敏（因为业务方最知道哪个字段敏感），采集层做兜底正则（防漏、防新接口忘记调 util）。网关层我反而不主推——它是"防君子不防小人"，真出事时你会发现网关日志里还留着一份完整的原始 body，脱敏等于没做。

理由很朴素：脱敏的责任应该离数据最近的那一层承担，就像门禁应该装在屋里而不是小区门口。小区门口那个闸机（网关）只能算"提醒"，屋里那把锁（应用层）才是真的防线。

另一个我更想抛出来的问题是**"脱敏到什么粒度"：卡号留后 4 位？手机号中间 4 位打码？身份证号留前后 3 位？我见过"留后 4 位"被用来反推全号（因为同银行号段可枚举）的事故，也见过"全打码"导致客服排障时根本没法定位到具体用户、最后偷偷从别的渠道捞明文的情况——后者其实比前者更危险，因为它绕过了审计**。

【想听大家聊聊】

1. 你们团队目前脱敏主要落在哪一层？应用层、网关层、还是采集层？踩过"漏脱敏"的坑吗，怎么发现的？
2. 脱敏粒度你们是怎么定的？有没有"留几位 / 不留"的书面规范，还是每个业务自己拍脑袋？
3. 有没有做过"脱敏日志 + 反查能力"的平衡方案？比如用 hash 索引代替明文，让客服能按 hash 反查用户但拿不到原文？
4. 如果让你只能选一层做脱敏（预算 / 人力只够一层），你会选哪层，为什么？

欢迎带具体场景来聊——比如"我们的日志是走 Kafka 还是直接进 ELK""网关是 APISIX 还是自研""有没有 sidecar"——越具体越好讨论，纯口号式的"我们要安全左移"就略过了哈 :)