第2章 合规性要求基础：GDPR、HIPAA、PCI-DSS对日志的要求

做加密SDK，绕不开合规。这不是选择题，而是必答题。

我刚开始接触这个领域时，以为只要把日志写得够详细就行。结果遇到一个客户拿着GDPR审计报告找我，说你们的日志存储超期了。嗯，那之后我才真正开始研究“合规性”这三个字背后到底在要求什么。

2.1 为什么合规要求盯上日志

三个字：可追溯。审计需要证据，证据从哪里来？日志。

GDPR、HIPAA、PCI-DSS 虽然针对不同行业，但它们对日志的核心要求高度重合：

• 谁（主体身份）
• 什么时候（时间戳）
• 做了什么（操作记录）
• 结果如何（成功/失败）
• 原始数据不得被篡改

说白了，就是“事后能查清”。我在一个医疗项目里遇到过这样的场景：某次数据访问事后发现异常，但日志里只记录了“用户A访问数据表X”，没有记录具体查询条件——审计直接判定不符合HIPAA。从那次起，我习惯在日志里至少保留操作摘要。

2.2 三大法规的日志要求对比

我帮你整理了一张对比表，这是我做SDK合规改造时经常参考的。

法规	覆盖范围	日志要求重点	保留期限
GDPR	欧盟公民个人数据	访问、修改、删除、同意记录	无明确上限，通常3年+
HIPAA	美国医疗健康数据	数据创建、访问、修改、删除、销毁	至少6年
PCI-DSS	信用卡持卡人数据	所有访问系统组件的行为，包括失败登录	至少1年（在线7天）

看着简单，落地时坑很多。比如GDPR要求“删除”操作必须记录，但很多人只记录了成功删除，忘记记录用户发起的删除请求本身——这会导致无法证明你确实执行了用户的“被遗忘权”。

2.3 GDPR：隐私时代的日志规则

GDPR 第30条明确要求数据控制者“维护处理活动的记录”。这里有个容易忽略的点：日志本身就属于个人数据（如果包含IP、用户ID等）。

• 必须记录的操作：个人数据的收集、存储、修改、查询、披露、删除。
• 时间精度：至少精确到秒。我见过不少SDK只记录到分钟，审计直接打回。
• 匿名化/假名化：日志里如果直接存身份证号，就是违规。必须在写入前先脱敏。
• 访问权支持：日志要能支撑用户查询“你存了我什么数据”。

2.4 HIPAA：医疗数据的审计追踪

HIPAA 的安全规则（45 CFR §164.312）要求“实施硬件、软件和/或程序机制，以记录并检查电子受保护健康信息（ePHI）的创建、访问、修改和删除活动”。

关键点：

• 谁访问了谁的数据：必须能关联到具体用户ID和角色。
• 访问了什么字段：不是记录整个文件，而是需要知道查看的是哪个具体字段。这个粒度要求很高。
• 日志保护：日志本身也要受到访问控制，不能谁都能读。
• 备份与恢复：日志需要备份，且备份也要符合加密要求。

我记得有一次评审，对方问“你们的日志存储在同一个数据库吗？”我说是。审计员直接说“不行，日志数据库和生产数据库必须物理或逻辑隔离”。从那以后我们的SDK架构里日志就单独走一个通道。

2.5 PCI-DSS：支付行业的严格要求

PCI-DSS 第10条“定期监控和测试网络”是整个标准里最让工程师头疼的部分之一。它要求：

1. 所有访问持卡人数据的行为必须记录。
2. 所有管理员活动必须记录。
3. 所有失败的登录尝试必须记录。
4. 日志必须包含：用户ID、事件类型、日期时间、成功/失败标识、来源IP、受影响系统/数据名称。
5. 日志必须保护：防篡改，至少要每日备份到集中日志服务器。
6. 日志保留：至少1年在线可用，至少3个月可立即访问。

你们猜最容易踩的坑是什么？是“同步时间”。PCI-DSS要求所有日志时间戳必须同步到同一个NTP源。我见过有项目一台服务器时间差了5分钟，结果审计时对不上事件顺序，判定为不合规。

2.6 三大法规的共性要求（一张图看清）

为了帮你快速建立知识体系，我画了一张结构图。

2.7 落地建议：日志字段的“合规基座”

不管哪条法规，你都可以从下面这个最小字段集入手。这是我做过三次合规改造后沉淀出来的。

• 事件ID（全局唯一，用于关联）
• 时间戳（UTC，精确到毫秒，带时区信息）
• 主体标识（用户ID、角色、应用ID）
• 操作类型（CRUD + 登录/登出 + 授权变更）
• 资源标识（被操作的数据对象ID或路径）
• 结果（成功/失败/拒绝）
• 来源IP + User-Agent
• 原始请求摘要（脱敏后的关键参数哈希）
• 签名或MAC（用于防篡改校验）

2.8 总结一句话

合规性要求日志的完整性、不可抵赖性、保留期限内可用性。你不用背每一条法规，但必须理解这三条是底座。我习惯在设计日志模块时先问自己：“如果明天被审计，这份日志能在法庭上站住脚吗？”如果答案是否定的，那就得重来。