第四节：密码迁移日志的关键字段拆解
密码迁移日志长什么样？说白了，就是一张记录了“谁、什么时候、干了什么、结果如何”的流水账。但这份流水账要是少了一个字段，审计老师傅能一眼看出来。
我刚做密码迁移那会儿，就吃过这个亏——日志里忘了记录源系统标识，结果复盘时根本查不出密码是从哪个老系统迁过来的。嗯，从那以后我把字段清单贴在显示器边框上，一个都不敢漏。
今天我们逐个过一遍核心字段。你别光看名字，要看背后的合规逻辑。
4.1 用户ID —— 唯一身份锚点
用户ID不能含糊。不能只用“张三”这种中文名，因为重名太常见了。必须用系统内部的唯一标识符。
- 推荐字段：UUID、EmployeeID、UPN（User Principal Name）
- 避坑点：同一个人的ID在源系统和目标系统里可能不同。日志里要同时记录“源系统用户ID”和“目标系统用户ID”，并用关联映射表做对照。
4.2 时间戳 —— 审计的时间轴
时间戳看似简单，但坑特别多。时间戳得有统一的时区，不能源系统用UTC、目标系统用东八区，那样时间轴就对不上了。
- 格式：yyyy-MM-dd HH:mm:ss.SSS + 时区偏移
- 精度：毫秒级，因为大量迁移操作可能在同秒完成
- 必须包含：开始时间、结束时间、持续时间（毫秒）
我记得有一次做合规审计，对方要求把时间戳全部转成UTC。结果我们的日志里有一半不带时区，得靠源系统IP反查，折腾了两天。
4.3 操作类型 —— 记录“做了什么”
操作类型必须是一个有限的枚举值，不能自由输入。自由输入会导致“迁移”“migrate”“move”同时出现，没法聚合统计。
| 操作类型 | 说明 | 典型场景 |
|---|---|---|
| PASSWORD_HASH_READ | 从源系统读取密码哈希 | 旧AD导出哈希 |
| PASSWORD_HASH_WRITE | 向目标系统写入哈希 | 写入新IDP |
| PASSWORD_VERIFY | 迁移后验证密码一致性 | 用户登录检测 |
| PASSWORD_REHASH | 重新哈希（算法升级时） | bcrypt→argon2 |
| ROLLBACK | 回滚操作 | 迁移失败后恢复 |
你想想看，如果没有操作类型字段，审计人员看到一条日志只知道“处理了密码”，但具体是读还是写？系统根本说不清楚。
4.4 状态码 —— 迁移成功还是失败
状态码是给机器看的，也是给审计人员看的。我建议参考HTTP状态码设计自己的合规状态码体系。
- 2xx：成功。200=迁移成功，201=回滚成功
- 4xx：客户端错误。401=身份验证失败，404=用户未找到
- 5xx：服务端错误。500=内部错误，503=依赖服务不可用
合规铁律：状态码不能只有“成功”或“失败”。必须区分“密码读取成功但写入失败”“密码验证失败”等具体原因。否则合规审计时会判定为“日志不完整”。
我曾经因为状态码太笼统，被甲方打回重做。他们的合规Team要求：失败时必须记录失败原因代码，不能只写“失败”。
4.5 源目标系统 —— 迁移的上下游
源系统和目标系统标识必须明确。不能只写“旧系统”“新系统”，要写系统全称和版本号。
- 源系统：系统名称 + 版本 + 实例ID（如：OpenLDAP_2.4.57_main）
- 目标系统：系统名称 + 版本 + 实例ID（如：Azure_AD_2.0_prod-china）
- 特殊字段：迁移批次ID，用于将多条日志关联成一个迁移任务
4.6 补充字段（建议多记录）
除了上面五个核心字段，我还强烈建议加上这几个：
- 请求追踪ID：一个全局唯一ID，贯穿迁移链路
- 执行节点：哪台服务器执行的迁移操作
- 密码强度标记：迁移前的哈希强度，用于事后分析弱密码集中迁移风险
- 签名校验值：对日志行做HMAC，防止日志被篡改
4.7 字段关系一张图
下面这张图把关键字段拼到了一起，你看看迁移日志的完整链路：
4.8 字段组合的合规意义
单独看每个字段好像没什么，但把它们组合起来，就能回答审计中的核心问题：
- 用户ID + 时间戳：某个用户的密码是什么时候被迁的？
- 操作类型 + 状态码：读成功了但写失败？说明目标系统有问题。
- 源系统 + 目标系统 + 时间戳：整个迁移任务的进度和成功率。
- 请求追踪ID + 所有字段：端到端全链路追踪，一次都别漏。
一句话总结：日志字段不是越多越好，而是每个字段都要有明确的合规用途。多一个无意义的字段等于多一个可能的合规漏洞。
设计日志字段时，我建议你在开发阶段就对着《审计日志合规检查清单》一条条过。别等项目上线了再补，那比重新写一遍还痛苦。