📚 课程目录第2章审计日志中的敏感字段类型（如密码、身份证号、信用卡号等）

审计日志中的敏感字段类型

做审计日志保护，第一件事就是搞清楚——到底哪些字段算敏感？别以为只有密码才算。我在一个金融项目里见过，运维把用户 IP 和浏览器指纹都当敏感字段列进去了，结果 Tokenization 范围太大，性能直接崩了。所以这一节，我们把常见敏感字段类型掰开揉碎讲清楚。

⚠️ 核心原则：不是所有日志里的字段都需要 Tokenization。只有符合「一旦泄露会导致身份盗用、资金损失、法律责任」的字段，才值得投入成本。先分类，再分级。

这类字段直接指向一个人，或能组合出个人身份。最常见的：

身份证号：18 位编码，唯一且终身不变。一旦泄露，诈骗团伙可用来实名认证、贷款、注册公司。我在一个政务系统里见过，审计日志明文记录了查询用户的身份证号——那是真吓人。
护照号 / 驾驶证号：出境记录、驾照信息同样属于高敏身份标识。
社保号 / 医保卡号：通常和金融账户绑定，泄露后易被冒用。
手机号：虽然是半公开信息，但在日志里连续出现可以拼接出用户行为轨迹。
邮箱地址：常作为登录名，泄露后容易被暴力破解。

💡 我的习惯：判断一个字段是否属于身份标识，就看它能不能「直接或间接」定位到一个人。光靠名字不算，但名字 + 生日 + 住址的组合就算。

这类字段一旦泄漏，就是真金白银的损失。我有个客户是做支付网关的，他们的审计日志里记录了完整的信用卡号——那是 PCI DSS 的雷区。常见类型：

字段	敏感原因	Tokenization 保护建议
信用卡号（PAN）	完整 PAN 可用于线上无卡交易；前 6 位（BIN）+ 后 4 位可被部分还原	除 BIN+后4位外其余全部 Tokenization
信用卡 CVV / 有效期	CVV 是强认证要素，明文存储直接违规	CVV 严禁存储在日志中，有效期可 Tokenization
银行卡号（借记卡）	可发起转账、快捷支付	同信用卡处理
支付宝 / 微信支付账户 ID	可关联用户消费记录	全字段 Tokenization，仅保留 hash 用于关联分析
交易流水号	单独看不太敏感，结合金额和账户可还原用户行为	建议对内部关联字段做 Tokenization 或脱敏

嗯，这里要特别强调：信用卡 CVV 和完整有效期是不能明文出现在日志里的。PCI DSS 3.2 明确要求即使加密存储也不行。我曾经在一个审计整改项目里发现，某个 API 网关把请求体完整打印到了日志里，里面就包含了用户输入的 CVV —— 那个团队后来花了两个月整改，还面临罚款风险。

这类字段直接用于登录或验证身份。泄一个，等于把大门钥匙给了别人。

密码：虽然现代系统都存哈希，但审计日志里如果记录了登录请求中的明文密码，就是灾难。我见过一个案例：某运维为了排查登录失败问题，临时在日志里打印了用户密码——然后忘了删。
会话 / JWT：登录后的认证令牌，能直接模拟用户操作。
/ 应用密钥：系统间调用的凭据，泄露后外部可以直接调用你的内部接口。
OAuth 授权码 / Refresh ：常出现在登录回调日志里，被攻击者截获后可长期保持会话。

  📌 避坑指南：我曾经处理过一个事故——开发人员在日志里打印了 OAuth 回调的完整 URL，里面带着 authorization code。攻击者通过日志泄露拿到了这个 code，换取了 access 。教训是：所有 URL 参数中的认证信息必须在日志采集层就脱敏，不要等到存储层再处理。

这类字段可能不是用户数据，但一旦泄漏，攻击者可以绕过整个安全体系。

你想想看，一个数据库连接串如果出现在审计日志里，攻击者只要拿到日志文件，就能直接连数据库——这比 SQL 注入还直接。所以，我的建议是：所有密钥类字段进入日志前必须经过强 Tokenization，甚至可以考虑不在日志中输出任何原始密钥字符串。

这块是医疗行业的重点。字段包括：

这些数据受 HIPAA（美国） / 《个人信息保护法》（中国）保护。日志中如果明文记录了患者姓名 + 诊断，就算脱敏不完整。我曾经参与过一个远程问诊平台的审计，他们日志里居然包含医生和患者的聊天全文——里面全是病情描述。最后只能全部 Tokenization，共用一个池来保证关联分析可用。

说个实话，不管怎么分类，最重要的是建立一套可复用的规则。我在一个大型电商公司搭过 Tokenization 系统，当时我们定了三条简单规则：

有了这个分类框架，你才能在下章设计 Tokenization 策略时，知道哪些字段该全量替换，哪些可以部分保留。别一股脑全上 Tokenization，到最后关联分析做不了，那就麻烦了。