日志里把密钥和用户手机号打出来了：脱敏放在哪一层，已写进去的怎么清

2026-07-29

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

**这件事最常见的归错因，是把它当成”某个人打日志时手滑”。**于是处置动作变成找出那行代码、改掉、提醒团队注意。三周后同样的东西又出现在另一个接口的日志里。真实的成因通常不是手滑，而是脱敏被放在了调用点——而调用点是永远补不全的：新接口会加、异常堆栈会自己带出对象、中间件会全量打印、第三方 SDK 也会打自己的日志。你要判断的第一件事不是”谁写的”，而是”它是从哪条通道进去的”，因为通道决定了脱敏该落在哪一层。

顺带说清楚分工：凭据一旦确认外泄之后的应急动作（作废、影响面评估、对外沟通节奏）在密钥不小心提交上去了，先撤销还是先清历史，顺里；把代码和业务数据交给 AI 工具本身带来的风险面在用 AI 必须避开的隐私与数据安全坑里。本篇只管日志这一条通道：怎么定位它、脱敏放哪一层、已经落盘的怎么收拾。

一、先分因：从现象倒推通道

别急着写正则。先拿一条真实的问题日志（脱敏后复制到本地文本里看），回答三个问题：它是出现在日志正文里，还是结构化字段里？它是每条请求都有，还是只有特定接口有？它是所有环境都有，还是只在某个环境有？这三问基本能把通道锁到一两种。

现象	大概率成因	怎么验证	处置动作
只有个别接口的日志带密钥/证件号	调用点手写拼接，把整个入参对象或凭据变量塞进了日志	在这些接口的处理函数里搜日志调用语句；本地构造一次请求看输出	就地改掉，同时把这个字段模式补进管道级过滤，别只改一处
所有请求日志都带完整 header	访问日志中间件按”全量打印”配置，没有字段白名单	看中间件配置里是否有字段清单；用测试环境发一次带鉴权头的请求	改成白名单，鉴权头与 Cookie 一律替换成占位符
异常堆栈里出现密钥	异常消息里带了配置对象或请求对象，序列化时全字段展开	主动触发一次同类异常，看堆栈完整文本	给配置类/凭据类型定制字符串表示，异常里只留错误码与摘要
正文干净，结构化字段里有	对象序列化默认导出全部字段	取一条结构化日志用 `python -m json.tool` 展开，逐个键看	在序列化层加字段黑名单或专门的敏感类型
只在某一套环境出现	该环境日志级别开到了 debug，把完整请求/响应打了出来	核对各环境的日志级别来源（环境变量、配置中心、启动参数）	生产固定级别；调试级别的完整打印只允许对样本数据开
日志里没有，告警通知里有	告警把原始上下文整段带进了 IM/邮件正文	翻一条历史告警消息全文	告警只带 traceId 与摘要，正文去掉原始载荷
泄露面突然扩大，但代码没改	日志目录被纳入了 AI 工具的可读范围，或有人把日志片段贴给了模型	看工具的文件读取范围与忽略配置；问一句最近谁贴过报错	把日志目录加进忽略清单；贴之前先过一遍脱敏脚本

最后一行值得多说一句。现在排障习惯变了，遇到报错第一反应是把整段日志贴进对话框。原始日志里往往同时有 traceId、请求体、鉴权头。一旦贴出去，它就从”内部文件”变成了”外部服务里的一条记录”，删本地文件已经没有意义。另外，如果你用的是海外厂商的模型服务，官方对中国大陆有区域限制、不支持直连；市面上存在第三方中转，我不背书也不给渠道，但你要清楚：多一跳中转就多一处日志留存点，贴进去的东西你不再有处置权。

二、脱敏该放在哪一层

按”离数据源多近”排，一共四层，可靠性从低到高：

**第一层，调用点。**就是那句 log.info(...)。它的问题不是不能用，而是不能作为防线——它依赖每个人每次都记得。把它当作”最后一次机会”，不要当作策略。

**第二层，类型与序列化层。**把”敏感”变成类型的属性，而不是打日志时的临场判断。做法是给密钥、令牌、证件号这类值包一个专门的类型，它的字符串表示永远返回掩码，只有显式调用取值方法才拿得到明文。Python 里覆写 __repr__ 和 __str__，Java 里覆写 toString，Go 里实现 String() 与 MarshalJSON。这样不管谁在哪里把它字符串化，出来的都是掩码。这是主力防线，因为它对新增代码天然生效。

但这层的边界要说在前头，否则很容易误以为上了它就万无一失：字符串化和结构化序列化是两条不同的路，覆写字符串表示只挡住了前一条。拿 Python 举个能当场验证的例子——如果你图省事把密钥做成 str 的子类，覆写 __str__ 和 __repr__ 确实能挡住 f-string、%s 和 print，但挡不住 json.dumps：标准库判定它是字符串就按原值输出了，根本不会调用你写的方法，明文照样进 JSON 日志。所以结构化输出必须单独处理，两条路子选一条：让密钥类型不去继承 str（用一个普通类把明文包在私有属性里，序列化时走自定义 encoder），或者直接用现成的封装类型（Pydantic 的 SecretStr 就是这个思路，打印出来是掩码，取明文要显式调一次取值方法）。Java 和 Go 同理——覆写了 toString 不代表 Jackson、encoding/json 会照做，得把序列化注解或 MarshalJSON 一起补上。

还有一处必须承认：显式取值方法拿到的就是明文，谁把取值结果直接塞进日志，第二层拦不住。所以第二层再稳也替代不了第三层的兜底。

**第三层，日志管道的处理器。**在日志写出前统一过一遍：字段名黑名单 + 值模式正则。它的价值在于跨服务、跨语言能统一策略，也能覆盖你改不动的第三方 SDK 输出。它的局限也明确：正则只认得你见过的格式，值被 base64 或 URL 编码后就漏了。所以它是兜底，不是主力。

**第四层，采集与存储端的清洗。**在日志被送进集中存储时再过一遍。它唯一不可替代的场景是：线上正在流血、代码来不及改。但它救不了已经落在本机磁盘上的那份文件。

判断依据其实很简单：**能用类型表达的，放第二层；跨技术栈要统一的，放第三层；来不及改代码要立刻止血的，先开第三、四层，再回头补第二层。**如果你发现同一类泄露已经在三个不同调用点改过还在冒，那就不是运气不好，是层选错了。

关于凭据本身怎么存、怎么传、怎么换，API Key 怎么管才不泄漏讲得更细，这里不重复。

三、已经写进去的怎么收拾

顺序很重要，很多团队顺序反了，先花两小时删文件，最后才想起来密钥还是活的。

**第一步，先判定是不是凭据，是就立刻按已泄露处理。**密钥、令牌、会话凭证、数据库口令，只要它进过日志文件，就默认它已经被读到过——日志会被采集、会被备份、会被贴进工单。此时最有效的动作不是删，是让它失效。轮换的操作节奏与灰度切换见 API 密钥轮换。轮换做完，删日志的紧迫性立刻降一个数量级。

**第二步，画副本地图。**只删主库等于没删。至少要列这些位置：

应用本机的当前日志文件与轮转归档（含 .gz）
集中日志系统里的索引
磁盘快照、数据库备份、容器镜像里烤进去的日志
告警消息、工单系统、IM 会话里粘贴过的片段
CI 构建日志（这一处最常被忘，而且往往全员可见）
崩溃上报、APM 的错误详情

**第三步，按可写性分类。**能改的就地处理，改不了的转第四步。扫描和确认可以这样做：

# 先扫当前与轮转后的日志，前缀按你实际使用的凭据格式替换
grep -rnaE '(sk|tok|key)[-_][A-Za-z0-9]{16,}' /var/log/myapp/ | head -n 50

# 手机号那条的 \b 不能省：日志里的毫秒时间戳（如 1753000000000）
# 内部就藏着能被 1[3-9] 开头吃掉的十一位数字，不加边界会淹在误报里
zgrep -aE '\b1[3-9][0-9]{9}\b' /var/log/myapp/*.gz | head -n 20

# 确认凭据有没有顺手进过代码仓库
git log --all -S 'BEGIN PRIVATE KEY' --oneline

# 只看变量名，不打印值，确认哪些凭据挂在环境里
printenv | cut -d= -f1 | grep -iE 'key|token|secret|passwd'

就地脱敏用一段脚本比手工靠谱，跑完保留一份处理记录：

import re, pathlib

PATTERNS = [
    ('cred',  re.compile(r'(sk|tok|key)[-_][A-Za-z0-9]{16,}'), '<REDACTED_CRED>'),
    ('phone', re.compile(r'\b1[3-9]\d{9}\b'), '<REDACTED_PHONE>'),
]

report = []
for p in sorted(pathlib.Path('/var/log/myapp').glob('*.log')):
    text = p.read_text(encoding='utf-8', errors='replace')
    hits = {}
    for name, pat, repl in PATTERNS:
        text, n = pat.subn(repl, text)
        if n:
            hits[name] = n
    if hits:
        p.write_text(text, encoding='utf-8')
        report.append(f'{p}\t{hits}')

pathlib.Path('redact-report.txt').write_text('\n'.join(report), encoding='utf-8')
print('\n'.join(report) or '未命中')

用 subn 而不是 sub，是为了拿到每类模式在每个文件里的命中条数——这份计数就是处置记录，事后复盘和交代影响面都要用它，只输出到屏幕上转头就没了。没命中的文件不重写，避免平白改掉修改时间干扰后续排查。

跑之前确认三件事。一是日志正在被写入的话，直接覆写可能丢尾部内容，先做轮转再处理。二是这段只处理未压缩的 .log，轮转后的 .gz 不在 glob 范围内，要么先解压再纳入，要么单独写一段用 gzip 模块读写，别看到脚本跑完就以为归档也干净了。三是 errors='replace' 会把无法解码的字节换成替换字符，日志里混了二进制片段时这一步是有损的，介意就改成按字节处理；有审计要求、不允许原地改写日志的系统，直接走第四步。

**第四步，改不动的部分转成”承认它已经出去了”。**不可变归档、只读保留期内的第三方存储、已经发到外部服务的片段，都属于这一类。此时正确的动作是：凭据作废、账户加监控、按你所在组织的流程记录这次事件。涉及个人信息时是否需要对外通知、通知谁，不同法域和不同行业要求不一样，这我不替你判断，走你们法务或合规的既定流程。

四、什么情况下别再折腾

**止损信号一：追删已经追到第三方保留期。**日志进了你无权删除的托管服务，剩下能做的只有提交删除请求并等待。继续投入人力”想办法抹掉”的收益趋近于零，把这些时间用在轮换和监控上更值。

**止损信号二：改历史的代价开始外溢。**如果密钥同时进了代码仓库，重写 git 历史意味着所有人重新克隆、所有开放中的分支重做。密钥已经作废的前提下，重写历史更多是洁癖而非必要。先作废，历史清理排到低优先级窗口做。

**止损信号三：同一类泄露修了三次还在冒。**这时停止打补丁，回到第二节重新选层。继续在调用点堆修改只会让你误以为在收敛。

**止损信号四：已经外发。**贴进外部服务、发进跨公司群、写进对外邮件的内容，删不回来。唯一有效动作是让内容失效。

还有一个回滚点要提前想好：脱敏处理器上线后，如果发现日志变得没法排障——比如把 traceId、订单号也一起打码了，链路串不起来——直接回滚这条过滤规则，改成保留可关联特征（对标识做稳定哈希只留前几位，或掩码时保留末尾几位）。日志的可用性和安全性要一起达标：只顾安全那一头的规则，等到下次线上出事、排障的人发现链路串不起来，多半会被谁悄悄关掉，而关掉这件事往往没人记得同步给你。日志量本身失控导致没人看的问题，另见几万行日志喂给模型总是没结果？先定位再截取而。

五、避坑清单

**只用正则当唯一防线。**为什么会踩：正则改起来最快，上线当天就能看到日志变干净，成就感强。怎么避：把正则明确定位成兜底层，同时排一个工期做类型层改造；正则规则要覆盖 base64 与 URL 编码后的形态，否则换个传输方式就失配。

**只脱敏了请求头，漏了 query 和响应体。**为什么会踩：中间件里最显眼的就是 header，改完一测确实没了。怎么避：把”请求行、请求头、请求体、响应体、异常堆栈”当作五个独立入口逐个验证，每个入口写一条断言。

**打码打得太狠，事后没法定位。**为什么会踩：处置时人处在紧张状态，倾向于宁可多打。怎么避：区分”标识”和”秘密”——标识做稳定哈希保留可关联性，秘密整体替换。上线前拿一个真实故障场景走一遍，确认还能串起链路。

**只清了生产，忘了 CI 和本地。**为什么会踩：处置清单是按线上事故模板写的，天然只覆盖运行环境。怎么避：把 CI 构建日志、开发机的日志目录、容器镜像固定写进副本地图模板，每次照着走。

**日志目录被 AI 工具读走。**为什么会踩：忽略配置一般只写了依赖目录和构建产物，很少有人想到 log。怎么避：在工具的忽略配置里显式加上日志目录与本地环境文件；养成习惯，粘贴报错前先过一遍脱敏脚本。

**修完不加回归。**为什么会踩：这类问题修完当下确认过就散了，没人相信它会再来。怎么避：加两道——单元测试断言凭据类型序列化后不含明文；CI 里加一条对构建日志和示例日志的模式扫描，命中就失败。

**把”删掉日志文件”当作处置终点。**为什么会踩：删除这个动作反馈明确，容易产生问题已解决的错觉。怎么避：把处置定义成”凭据已失效 + 副本地图已走完 + 防线已上移一层”，三条都打勾才算结束。

收尾

这类问题的处置质量，取决于你有没有在第一时间分清两件事：哪些是必须立刻失效的秘密，哪些是需要慢慢清的痕迹。前者拖不得，后者急不得。

收工前对着这份清单过一遍：

泄露的是凭据还是个人信息？凭据是否已经完成轮换并确认旧值失效？
副本地图是否覆盖了轮转归档、备份快照、CI 日志、告警消息、工单粘贴？
脱敏防线是否已经从调用点上移到类型层或管道层？
类型层的掩码有没有连结构化序列化一起验过（不只是 print 一下看着是掩码，还要把对象真的 JSON 化一次看输出）？
请求行、请求头、请求体、响应体、异常堆栈这五个入口是否逐个验证过？
打码后是否还能用 traceId 串起一次完整调用？
是否加了回归（序列化断言 + CI 扫描），下一个新接口不会重蹈？
涉及个人信息的部分，是否已按组织内既有流程记录并上报？