日志脱敏

【背景】 做了 8 年安全加固，最近在帮一个电商团队做日志治理，卡在日志脱敏上，想听听大家线上怎么取舍。背景： - 日增日志 200GB+，链路 Filebeat → Elasticsearch； - 日志里混着手机号、身份证号、银行卡号、

背景 最近一次线上事故复盘，我被夹在两个要求之间： - 安全/合规侧：日志里不能出现明文手机号、身份证、卡号，审计要能证明「日志无 PII」，出问题要能拿日志去交差； - SRE/研发侧：支付失败链路里，用户手机号 + 订单号是唯一定位依据

«作者：温墨白-899｜分布式系统 / 安全加固｜15 年经验 栈：grpc-go 1.60、SLS（阿里云日志服务）、Go 1.21 结论先行：任何写进日志的字段，默认当作"攻击者可读、可搜索、可批量下载"。3 行 debug 日志能烧掉

【背景】 我做安全加固复盘时发现一个反复出现的现象：安全基线里写了"密钥不落明文日志"，可审计时几乎总能在历史日志里翻到 AccessKey 片段、JWT 或用户手机号。它不像 CVE 有明确编号，而是散落在几十个服务的滚动日志里，靠人肉

一、现象：一次「找日志」的例行操作，挖出 40 万条明文手机号 上个月给一家做本地生活的 SaaS 客户做季度安全加固复盘。他们上个月刚收到监管问询函，触发点很具体：某竞对员工以「用户投诉退款」为由进客服群，报了一个手机号要求查订单，值班同

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

【背景】 我负责一套跑在 K8s 1.28（containerd，自建集群）上的 Java 17 / Spring Boot 3.1 业务，日志链路是：应用打 stdout → 节点 filebeat 采集 → Logstash 过滤 →

先说背景：日志是排障的命脉，但同时也是敏感信息泄露的重灾区。最近帮两个团队做安全加固，翻他们生产日志，身份证、手机号、银行卡号、甚至完整 JWT token 都明文躺在文件里——平时觉得没事，真出了数据泄露事故才追悔莫及。可反过来，把字段全