敏感信息检查工具

上周三，敏感一位做后端的信息朋友给我发来一张截图。他负责的检查API接口在测试环境返回了用户列表，里面赫然带着手机号和身份证号。工具问题出在一个刚合并的敏感代码分支上——有人为了调试方便，把脱敏逻辑注释掉了。信息这事如果发生在生产环境，检查够他喝一壶的工具。

敏感信息泄露往往就是敏感这么不起眼。不是信息黑客攻破防火墙，不是检查数据库被拖库，而是工具某个开发顺手打了个日志，某个运营导了份Excel，敏感某个测试忘了删掉一段mock数据。信息我见过最离谱的检查案例，是一家公司的前端代码里直接硬编码了内部管理后台的账号密码，注释写着“临时用，后面改”，结果一挂就是两年。

所以，敏感信息检查工具到底在查什么？说白了就三件事：找出来、标出来、拦下来。

找什么？手机号、身份证号、银行卡号、邮箱地址、API密钥、数据库连接串、内网IP、JWT令牌。这些东西散落在代码仓库、日志文件、配置文件、数据库表、甚至聊天记录里。工具要做的第一件事，就是定义清楚“什么算敏感”。规则库得持续更新——比如现在很多工具已经支持识别特定云厂商的AccessKey格式，因为格式足够特征化，正则一抓一个准。

怎么找？两种路子。一种是正则匹配，简单粗暴，适合结构化强的数据。手机号就是1[3-9]\d{ 9}，身份证号就是十八位数字加最后一位可能是X。另一种是上下文分析，光看格式不够，还得看变量名。一个叫user_phone的字段和一个叫order_id的字段，哪怕都是十一位数字，敏感程度天差地别。好的工具会把变量名、注释、甚至所在文件的路径都纳入判断。

找到之后呢？光报警没用。我见过太多团队，扫描工具跑一遍，报告出来几百条告警，没人看。真正有用的做法是分级：critical级别的直接阻断CI/CD流水线，代码合不进去；warning级别的发通知给负责人，限期处理；info级别的只记录，供审计用。

有个细节值得说。很多工具默认只扫代码仓库，但敏感信息泄露的大头其实在日志里。一个请求进来，参数里带着手机号，框架自动打了条debug日志，这手机号就落盘了。日志文件通常没有版本控制，没人review，一存就是几个月。所以检查工具得能接日志管道，在写入前做一次过滤。

另一个坑是误报。正则写得太宽，会把订单号、时间戳、甚至随机字符串都标成敏感信息。开发被误报烦了，就会习惯性点“忽略”，然后真正的泄露也一起被忽略。降低误报的办法是加白名单和熵值判断。比如银行卡号有Luhn算法校验，API密钥通常有足够的随机性，熵值低于阈值的字符串可以直接放过。

我自己用过的工具里，gitleaks适合扫Git历史，trufflehog对云凭证的识别很准，detect-secrets的插件机制方便扩展。但工具终归是工具，关键还是流程。把扫描嵌到pre-commit钩子里，比事后扫整个仓库有效得多。开发者提交前就被告知“你这段代码里有敏感信息”，改起来成本最低。

最后说个观察。很多团队买了商业DLP产品，部署得轰轰烈烈，结果三个月后没人登录后台。反倒是几个开源脚本加一条CI规则，坚持跑了一年多，拦下了十几起真实泄露。工具不在贵，在有人看，在能形成肌肉记忆。敏感信息检查这件事，技术只占三成，剩下七成是习惯。