核查 VPN 的 FIPS 声明背后的 CMVP 证书

经过验证的模块是一个证书编号、一个版本和一组运行条件。在接受产品的 FIPS 声明之前，先把这三样都找齐。

写着 FIPS 已验证的厂商页面不是你可以归档的证据。证据是一个证书编号、一个模块名称、一个经过验证的版本以及随附的运行条件，而这些必须与你部署的构建相符。NIST CMVP 常见问题对产品声称兼容与模块实际通过验证之间的区别说得很直白。请按顺序完成下面四个步骤，并把记录与部署放在一起。

第 1 步：拿到证书编号，而不是徽章

向厂商索要涵盖你打算运行的产品中加密模块的 CMVP 证书编号。证书编号是一个具体、可核查的对象，而徽章只是营销。如果答复描述的是算法而不是模块，那它回答的是另一个问题。再要一次编号，而不是接受一张徽章的 PDF。编号背后的记录才是审计人员能够追查的东西。

然后在官方的已验证模块查询中查找该编号，并阅读记录本身，而不是它的摘要。记录会列出厂商、模块、已验证版本和状态，并链接到说明该模块应如何运行的安全策略文档。

把这五个字段写下来，因为下一步要把它们与构建比对。一张表格里的一列就够了。

第 2 步：把模块版本与构建对上

VPN 客户端版本与内嵌模块版本很少共用同一个编号，这是正常的。关键在于你构建中的模块版本是否出现在已验证记录里。一次更新可以在不改产品名称的情况下更换模块，从而悄悄把部署移出已验证配置。

询问哪个组件使用该模块，以及在受支持的配置中如何选择已批准模式。一个能在未批准模式下运行的构建，与一个为已批准模式配置的构建并不是同样的证据。

从本地构建读取信息，这样比对用的是构建产物而不是下载页面。下面的命令打印的正是这一点。

openssl version -a
openssl list -providers -verbose
cat /proc/sys/crypto/fips_enabled

当模块报告的版本与证书不同时，声明已经偏移，需要先更新记录，再让任何人签字。

第 3 步：阅读运行条件

证书附有描述验证所覆盖环境的条件。这些条件可能指明平台、配置、允许的密钥长度以及必须受限的服务。忽略这些条件的普通安装就是在已验证边界之外部署，即使二进制文件完全相同。这就是安全策略文档与证书编号同等重要的原因。

把厂商指南放在证书旁边，因为它说明了哪些设置会选择已批准模式，哪些会把产品带出该模式。

如果这些条件在你的环境中无法满足，诚实的说法就是：这次部署位于已验证配置之外。指出那条无法满足的条件，能把这句话变成团队可以修复或接受的事项。

第 4 步：确认今天的状况

CMVP 记录带有一个状态，而状态并非永久。NIST 的常见问题说明了 2026 年 FIPS 140-2 的过渡日期，此后有效列表上只剩 FIPS 140-3 验证。一张在采购获批时仍然有效的证书，今天可能已是历史状态。

历史状态与已撤销是不同的状态，二者对采购各有含义。要查实时记录，而不是项目文件夹里的截图，并记下你核查的日期。

然后问合规或采购负责人，他们的要求接受哪种状态，因为这是政策决定而不是技术结论。把答案连同日期记录下来。

对照部署核查记录

比较收集到的四个值：证书编号、构建中的模块版本、当前生效的运行条件以及当前状态。任何不一致都是一项发现，而这项发现应写入部署记录，而不是放进幻灯片。

把证据与构建存放在一起，包括日期和核查人。每个发布版本一个目录就够了。

date -u +%FT%TZ
openssl version -a | head -3
cat /proc/sys/crypto/fips_enabled

也要把声明留在它的边界之内。模块验证对 VPN 的协议处理、授权决策或日志策略一无所知。它是关于某一个已定义加密组件的具体证据，而把它当作产品评分，正是合规文件最终描述起没人部署过的东西的方式。

相关文章