3. HSM审计日志标准：PCI-HSM与FIPS 140-2/3

这一章我们聊聊标准。
说白了，HSM 的审计日志不是你想怎么记就怎么记的。
要是拿去合规审计，标准就是硬杠杠。

我自己刚入行那会儿，接过一个项目——客户买的 HSM 明明功能都齐，结果 PCI 审计没过。
整改了三个月。
原因很简单：日志该有的字段不全，时间戳没上锁，还缺了管理员操作记录。

所以搞清楚 PCI-HSM 和 FIPS 140-2/3 对审计日志到底提了哪些要求，是每个 HSM 开发者和运维者的基本功。

3.1 标准概览

先列个表，看个全貌。

标准	发布机构	适用场景	审计日志关注点
PCI-HSM	PCI SSC	金融支付、发卡、交易授权	密钥生命周期、管理员操作、物理安全事件
FIPS 140-2	NIST	美国政府、军用、商用密码模块	密码边界、服务指示器、自检事件、错误状态
FIPS 140-3	NIST	FIPS 140-2 的升级版（2019年生效）	新增审计日志完整性、不可抵赖性、时间同步要求

嗯，这里要注意：FIPS 140-3 在审计日志上比 140-2 严了不少。
我见过不少团队还在按 140-2 的老习惯写日志，结果换到 140-3 认证时被打回来。挺冤的。

3.2 PCI-HSM 对审计日志的具体要求

PCI-HSM 是支付行业的专属标准。
它的审计日志要求，说白了就是要能“管住钥匙，盯住人”。

我之前有个项目踩过一个坑——客户的 HSM 日志用的是外部 NTP 时间。
结果审计发现时间源没做身份验证，被中间人篡改了。
整改方案是把 NTP 服务器配置成 HSM 内部的受信时间源，再对日志时间戳加上硬件签名。

3.3 FIPS 140-2/3 对审计日志的具体要求

FIPS 140 系列面向的是密码模块本身——也就是你 HSM 里的那颗密码芯片或固件。
审计日志这块，它更关心“模块是否跑在安全状态里”。

3.3.1 FIPS 140-2 的要求（基础版）

• 服务指示器：模块必须能输出当前状态（如：加密服务已启用、自检失败、错误状态）。
• 自检事件记录：上电自检（POST）和条件自检（如密钥生成后检测随机数质量）的结果必须可审计。
• 错误事件：密码操作失败、密钥损坏、违反安全策略等。
• 日志存储：没有强制要求外部持久化，但模块内部必须有非易失性存储来保存关键事件。

3.3.2 FIPS 140-3 的新增要求（升级版）

• 审计日志完整性：必须支持日志的链式哈希或数字签名，防止事后篡改或删除。说白了，就是区块链那套思想——每条日志都带上上一条的哈希。
• 不可抵赖性：操作者身份和操作内容必须绑定，且无法被否认。
• 时间同步审计：模块必须记录时间源信息，并能检测时间跳变。
• 日志导出要求：支持加密导出，且导出过程中日志完整性要维持。
• 审计日志配置不可篡改：谁开了审计、谁关了审计、谁改了审计级别——这些操作本身也要记入日志。

说个真实案例：
我们团队测试过一款 140-3 候选的 HSM，把审计日志的“链式哈希”部分做成了可选配置。
结果实验室直接判定不合格。
因为标准里写的是 shall（必须），不是 should（建议）。

3.4 PCI-HSM 与 FIPS 140-3 审计要求对比

两种标准有重叠，也有侧重。我整理了一张表：

对比维度	PCI-HSM	FIPS 140-3
日志覆盖范围	密钥操作 + 管理员 + 物理安全	密码服务 + 自检 + 状态变化 + 错误
时间戳要求	硬件时钟 + 不可篡改 + NTP审计	硬件时钟 + 时间源审计 + 跳变检测
完整性保护	HMAC / 数字签名	链式哈希 / 数字签名
日志保留期限	至少 12 个月	无明确要求，但建议产品生命周期内可查
审计配置审计	要求“审计事件本身也要审计”	明确要求（140-3新增）
不可抵赖性	间接要求（通过签名实现）	直接要求（140-3新增）

你看，PCI-HSM 更像“操作日志”，FIPS 140-3 更像“状态与事件日志”。
实际设计中，如果 HSM 要有双认证（比如既做支付又做政务），就要同时满足两套标准。

3.5 一张图看清标准对日志生成的影响

下面这个 SVG 展示了审计日志从生成到合规的全链路：

3.6 共性要求总结

不管你是跟 PCI-HSM 走，还是跟 FIPS 140-3 走，有几点是共同的：

1. 完整性必须做：HMAC、签名、链式哈希——至少选一个。
2. 时间源必须可靠：硬件时钟是底线，NTP 要加密验证。
3. 日志本身也要被审计：谁敢关审计，谁就要被记上一笔。
4. 不可抵赖：操作者和操作内容要能绑定，不能事后说“我没干”。
5. 安全导出：日志不能裸着出去，必须加密+签名。