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

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

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

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

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

【审计中的具体数据（补充）】 在我们那次 20+ 微服务、247 个接口的审计里，发现的情况比预想严重：

• 3 个接口的 log.info 里直接打了完整的 requestBody（含手机号 + 银行卡号），原因是开发同学为了"方便排查"把 log.info("request: {}", body) 写在了 controller 入口；
• 12 个接口的 log.debug 里打了 SQL 参数（含身份证号、地址），灰度环境 log level 被运维脚本统一调到 INFO，这些 debug 日志在灰度环境全部落盘了——生产环境是安全的，灰度环境是裸奔的；
• 1 个定时任务的异常堆栈里把完整的 User 对象 toString() 打了出来（含姓名、手机号、身份证号），这条异常只在每月对账时触发一次，跑了 14 个月没被任何人发现，直到我们逐接口 grep 才挖出来。

这三类漏点的共同特征：不是"故意打"，而是"顺手打"或"异常路径打"——正常路径的脱敏做得不错，异常路径（堆栈、debug、toString）几乎没人管。

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

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

【采集层脱敏的可复现配置（补充）】 采集层兜底正则不是"写个 \d{11} 就完事"，不同字段的脱敏策略不同。以下是我们实际用的 Logstash filter 配置（脱敏规则部分）：

# logstash filter.conf（节选）
filter {
  # 手机号：1[3-9]\d{9}，保留前 3 后 4
  mutate {
    gsub => [
      "message",
      /(?<!\d)(1[3-9]\d{9})(?!\d)/,
      "%{1}"   # 先用占位标记，下面统一替换
    ]
  }
  # 银行卡号：16~19 位纯数字，保留后 4
  mutate {
    gsub => [
      "message",
      /(?<!\d)(\d{16,19})(?!\d)/,
      "****%{1:0-4}"   # 简化示意，实际用 ruby filter 更精确
    ]
  }
  # 身份证号：18 位（末位可能是 X），保留前 3 后 4
  # 姓名：这个正则做不了，必须靠应用层语义脱敏
  # 地址：同上，必须靠应用层

  # 关键：对异常堆栈里的 toString() 输出做整体打码
  # 匹配 "User{id=..., name=..., phone=..., idCard=...}" 模式
  mutate {
    gsub => [
      "message",
      /name\s*=\s*([^,\s]+)/,
      "name=[已脱敏]"
    ]
    gsub => [
      "message",
      /idCard\s*=\s*([^,\s]+)/,
      "idCard=[已脱敏]"
    ]
  }
}

注意最后一段：异常堆栈里的 toString() 输出是最容易漏的，正则必须覆盖 key=value 这种 Java 对象打印格式。上面这个配置是我们生产上实际在用的（脱敏了具体字段名），但正则永远不可能覆盖所有字段名变体（phone / mobile / tel / cellphone / contact_no 都可能出现），所以它只能做兜底，不能做主力。

【四、一个容易漏的运营坑：存量日志（新增）】 上面讲的是"新日志怎么脱"，但有一个运营层面的坑很少有人提：你部署脱敏管道的那一刻，之前已经落盘 / 已经进 ELK 的日志还是裸的。

具体场景：

• 你的 ELK retention 是 90 天，你 1 月 1 日上线脱敏管道，那 10 月 1 日 ~ 12 月 31 日的日志里，手机号和卡号还是明文；
• 你的 Kafka retention 是 7 天，如果采集管道（Filebeat → Kafka → Logstash → ES）中间任何一环挂了，日志会积压在 Kafka 或本地磁盘上 7 天——这 7 天里的日志是未脱敏的；
• 你的本地磁盘 /var/log/app/ 下还有 3 天的滚动日志（log4j2 的 SizeBasedTriggeringPolicy 默认保留 3 个文件），这些日志在 Filebeat 采集之前就已经在磁盘上了。

我们的处理策略（不完美，但比没有强）：

1. 上线脱敏管道前，先跑一次"存量扫描"：对 ELK 里过去 90 天的日志跑一遍脱敏正则，统计命中条数（我们那次是 2.3 万条含手机号、4700 条含卡号）；
2. 对命中的日志，在 ES 里做一次 reindex + 脱敏（代价：ES 索引重建，需要预留双倍存储）；
3. 本地磁盘的滚动日志，直接 shred -u 删除（而不是 rm，防止磁盘恢复）；
4. 在安全事件响应 runbook 里加一条："如果脱敏管道宕机超过 30 分钟，检查期间落盘的日志是否含敏感字段，必要时 shred 本地磁盘日志文件。"

核心认知：脱敏不是一次性项目，是持续运营。 你上线脱敏管道的那天不是终点，而是"存量 + 增量 + 异常路径"三条线的起点。

【想听大家聊聊】

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

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