PII

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

«作者：温若衡-259｜分布式系统 / 安全加固｜8 年经验 栈：MySQL 8.0.36（InnoDB）、Spring Boot 3.2 / HikariCP 5.1.0、PostgreSQL 15（对照）、RDS 控制台 结论先行：「最

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

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

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