第三章 合规记录框架：GDPR、PCI-DSS、等保2.0
做密码改造审计日志，光懂技术是不够的。你还必须清楚：你的日志要满足哪些合规要求？
我自己这几年跟各种合规审计打过交道，最头疼的就是不同标准要求还不一样。有的要保留180天，有的要保留1年，还有的干脆说“永久保存”。
这一章，我们把三个主流框架——GDPR、PCI-DSS、等保2.0——对审计日志和密码记录的核心要求拎出来讲明白。坦白说，很多项目出问题，不是因为编码写错了，而是日志结构压根没对准合规基线。
3.1 GDPR：不只是“被遗忘权”
一提到GDPR，很多人就想到要能删用户数据。没错，但审计日志怎么办？你能把日志也删了吗？
我参与过一个面向欧洲用户的SaaS改造，客户要求日志里不能出现明文密码哈希，但又必须能追溯谁执行了密码变更。你想想看，这中间的门道其实很深。
GDPR对审计日志的实际要求，我总结了下面几点：
- 可追溯性：所有涉及个人数据的访问、修改、删除操作，必须记录用户ID、时间戳、操作类型、数据对象标识。
- 最小化原则：日志本身不能包含不必要的数据。密码明文不行，连哈希值也要考虑是否属于“个人数据”。
- 保留期限：原则上日志保存不超过业务必要性时长，常见做法是6个月到2年。记得设置自动清理策略。
- 防篡改：日志写入后不能被修改或删除，除非触发合规删除流程。
3.2 PCI-DSS：密码改造的硬约束
PCI-DSS对密码相关日志的要求，可以说是所有标准里最具体的。做过支付系统的人应该深有体会——每次PCI年审，审计员第一件事就是翻日志。
我经历过一次PCI-DSS 4.0的重新认证，光密码日志字段定义就改了三个版本。为什么？因为标准明确要求：
- 日志必须记录所有密码变更事件，包括管理后台的密码重置、用户自助改密、甚至轮换。
- 日志不可被非授权修改，写入后只能用只读方式访问，系统管理员也不能改。
- 至少保留1年，且在线可查至少3个月。
- 日志必须包含原始结果：成功或失败都要记。失败的密码尝试次数记录更是硬性指标。
3.3 等保2.0：三级及以上密码改造要点
国内项目跑不掉等保2.0。对于密码改造审计日志，等保2.0三级和四级有强制要求。说得更直白一点，很多政企客户验收时，审计日志能力就是一票否决项。
我帮一个省级政务云做过密码改造，对方等保测评报告里的整改项，有一半跟日志不完整有关。核心要求我列出来：
- 日志覆盖全部密码操作：包括登录、改密、重置、密钥生成、证书颁发等。
- 字段完整：事件类型、发生时间、用户标识（或系统进程）、源IP、目的对象、结果。
- 日志保护：三级要求日志记录完整性保护（防篡改），四级要求日志存储冗余且实时同步。
- 保存时间：三级不少于6个月，四级不少于1年。实际项目建议保留更久以防复查。
3.4 三大框架对比清单
刚入行的朋友往往觉得这些标准各自独立，其实它们有很多重叠。下面的表格帮你快速对齐：
| 维度 | GDPR | PCI-DSS | 等保2.0（三级） |
|---|---|---|---|
| 密码明文禁止 | 是（含哈希需评估） | 是（任何可逆形式都不行） | 是（符合国密标准即可） |
| 日志保留期限 | 业务必要期限（常6-24月） | 至少1年，在线3个月 | 不少于6个月 |
| 防篡改要求 | 高（写入后不可改） | 极高（系统管理员也不能改） | 高（完整性校验） |
| 失败记录要求 | 建议记录 | 强制记录 | 强制记录 |
| 适用场景 | 个人数据保护 | 支付卡数据环境 | 关键信息基础设施 |
3.5 合规日志设计的核心逻辑
理解了每个标准的要求，你可能会问：那我到底以哪个为准？
我的做法是——取交集中最严格的那个。如果你的系统同时面临GDPR、PCI-DSS和等保2.0，那就PCI-DSS的1年保留期 + GDPRs的防篡改 + 等保的完整字段。这样不管哪个审计员来，你都不会慌。
下面这张图把三个标准的关注点和关系画清楚了，你可以用它来跟团队对齐思路：
有了这个框架做基准，你在设计密码改造审计日志时就不会漏项。下一层我们要落到具体的日志字段结构和事件分类——那是第四章的内容了。