硬件安全模块 - 使用 AWS CloudHSM 专有管理加密密钥
详解使用 AWS CloudHSM 专有管理加密密钥。介绍单租户 HSM 的独占使用、通过 PKCS#11 和 JCE 进行的直接控制、密钥保管以及与 KMS 的选型依据。还介绍向 hsm2m.medium 一代的迁移，以及 TLS 卸载和 Oracle TDE 集成。
加密密钥管理的要求与 CloudHSM 的定位
加密密钥的管理是信息安全的根基。在 AWS 上，将密钥材料封闭在硬件中的选项有 AWS KMS（Key Management Service）和 AWS CloudHSM 这 2 种。截至 2026 年 8 月，KMS 和 CloudHSM 的 FIPS 模式的当前一代都在通过 FIPS 140-3 Level 3 验证的 HSM（Hardware Security Module）上处理密钥材料。KMS 使用通过 FIPS 140-3 Security Level 3 验证的 HSM 群保护密钥，明文密钥材料既不会离开 HSM 的边界，也不会写入磁盘。CloudHSM 的 FIPS 模式集群也在后述的 hsm2m.medium 一代取得了 FIPS 140-3 Level 3 验证。因此，“选择验证级别高的一方”这一以往的思路已不能用于当前的选型判断。 现在的区别在于是否独占密钥专用硬件、在多大程度上亲手直接控制密钥，以及由谁持有密钥的保管权（管理主体）。CloudHSM 提供的是单租户的通用 HSM，集群内密钥的生成 / 存储 / 使用全部在 HSM 内部完成。用户和角色的管理通过 IAM 之外的 HSM 自身的认证机制进行，因此使用者承担的责任范围也相应扩大。AWS 负责硬件的预置、补丁应用和加密备份的保管，但无法访问 HSM 内的密钥，数据平面的通信内容对 AWS 也不可见。另一方面，KMS 是多租户的托管服务，由服务方承担密钥的创建、轮换和可用性保障。当合规要求或内部政策要求“独占密钥专用硬件”或“明确密钥材料的所在位置和管理主体”时，CloudHSM 就会成为候选。
向 hsm2m.medium 一代的迁移与 FIPS 验证的现状
CloudHSM 的 HSM 类型正处于换代之中。以下是截至 2026 年 8 月的情况。新一代的 hsm2m.medium 于 2024 年 8 月 20 日正式推出，旧一代的 hsm1.medium 自 2025 年 4 月起在任何区域都无法再创建新集群。2026 年 1 月起，CloudHSM 开始进行自动迁移，hsm1.medium 已于 2026 年 3 月 31 日终止支持。FIPS 验证也按代区分。hsm1.medium 曾通过 FIPS 140-2 Level 3 的证书 #4218 验证，但已于 2026 年 1 月 4 日移入 CMVP 的 historical 列表。hsm2m.medium 通过 FIPS 140-3 Level 3 的证书 #4703 验证。 hsm2m.medium 的设计也发生了变化。创建集群时可以选择 FIPS 模式或非 FIPS 模式，该设置在创建后无法更改。整个集群合计可以存储 16,666 个密钥，其中非对称密钥最多 3,333 个。客户端与 HSM 之间通过双向 TLS 进行认证，使用时需要 Client SDK 5.9.0 或更高版本。迁移路径有 2 条。一条是选择加入由 CloudHSM 管理的迁移，让现有集群完成换代。另一条是从 hsm1.medium 的备份新建 hsm2m.medium 集群，切换后再删除旧集群。选择前者时，前提条件之一是最近 7 天的所有连接均为 Client SDK 5.9 以上（如果执行 ECDSA 的 Verify 则为 5.13 以上）。其他前提条件是集群处于 ACTIVE 状态，以及 HSM 为 27 台以下。另外，备份无法跨 FIPS 模式和非 FIPS 模式恢复。关于代际，只能单向地将 hsm1.medium 的备份恢复到 FIPS 模式的 hsm2m.medium 集群。无法将 hsm2m.medium 的备份恢复到 hsm1.medium 集群。因此，无法采取将一直以非 FIPS 模式运行的集群替换为 FIPS 模式之类的路径。
集群架构与标准 API
CloudHSM 以集群为单位进行管理。创建集群时指定自己 AWS 账户中的 VPC 和子网。每添加 1 台 HSM，CloudHSM 就会在指定的子网中放置一个 ENI（Elastic Network Interface）。HSM 的实体位于 CloudHSM 所拥有的另一个 VPC 中，应用程序通过该 ENI 与 HSM 通信。有时会被说成“HSM 放置在自己的 VPC 内”，但准确地说，出现在自己子网中的只有网络接口。HSM 与对应的 ENI 位于同一个可用区，因此推荐的架构是每个可用区准备 1 个子网，并将 HSM 分散到 2 个以上的可用区。集群内的 HSM 之间会自动同步密钥，因此即使失去 1 台 HSM，也可以在其余 HSM 上继续使用密钥。 应用程序一侧通过安装 Client SDK 5 来使用 HSM。PKCS#11 库符合 PKCS#11 版本 2.40，可以从 C/C++ 应用程序或支持 HSM 的中间件处理密钥。面向 Java 提供了构建在 JCE（Java Cryptography Extension）提供程序框架之上的提供程序，可以从 Java 应用程序操作 HSM 上的密钥。面向 Windows 提供了 CNG 提供程序和 KSP（Key Storage Provider）。通过 OpenSSL 使用时，提供了 OpenSSL Dynamic Engine 和 OpenSSL Provider。这些都是行业标准的接口，因此对现有应用程序的修改大多仅限于连接设置和密钥的指定，几乎不需要重写加密处理的代码。客户端软件一般安装在 VPC 内的 EC2 实例上，但只要是能够到达 HSM 的 ENI 的环境，就不必是 EC2。使用创建集群时生成的安全组，允许从客户端到 HSM 的通信。
与 KMS 的选用 - 5 个选型依据
在 FIPS 验证级别已无法区分两者的现在，选型按以下 5 个依据进行判断。 第 1 个依据是单租户独占。CloudHSM 按小时独占自己专用的 HSM，该硬件上的密钥只存在于自己的集群中。KMS 共享由 AWS 运营的多租户 HSM 队列。第 2 个依据是直接控制。如果需要通过 PKCS#11、JCE、CNG/KSP 或 OpenSSL 直接调用 HSM 的机制，或者现有中间件是以 HSM 连接为前提设计的，适合使用 CloudHSM。KMS 的操作通过 KMS 的 API 以及与各项 AWS 服务的集成进行。 第 3 个依据是密钥保管。在 CloudHSM 中，用户和角色由自己创建，备份的获取和恢复也作为自己的运维进行设计。在 KMS 的标准密钥存储中，密钥材料的保管和冗余由 AWS 承担。作为两者的折中，KMS 提供了 3 种密钥存储选项。按照现行文档的称呼，有通常的“标准密钥存储”。除此之外，还有将密钥材料放在自己的 CloudHSM 集群中、同时通过 KMS 的 API 进行操作的“AWS CloudHSM 密钥存储”。另外，还有将密钥材料放在 AWS 外部密钥管理系统中的“外部密钥存储”。如果希望将 S3、EBS、RDS 等 AWS 服务的服务器端加密与自有 HSM 结合，经由该 AWS CloudHSM 密钥存储是标准的路径。 第 4 个依据是合规的特定要求。如果要求仅指“通过 FIPS 140-3 Level 3 验证的模块”，单靠 KMS 也可以满足。出现差别的是要求指定单租户性、密钥的物理独占，或在特定审计方案下运营 HSM 的情况。据介绍，CloudHSM 的 FIPS 模式集群可用于满足 PCI PIN、PCI-3DS 和 SOC2 的要求。此外，还需要确认前提因地区而异，例如 KMS 在中国区域的 HSM 采用的是 OSCCA 的认证，而不是 CMVP 的验证。 第 5 个依据是运维责任与可用性的保障。在 KMS 中，可用性、补丁应用和扩展由服务方负责。在 CloudHSM 中，HSM 的台数设计、可用区分散、从备份恢复的步骤，以及对 Client SDK 和 HSM 代次的跟进由用户负责。费用结构也如后文所述差异很大，因此，对照这 5 个依据确认“独占和直接控制是否真的是要求”之后再选择 CloudHSM，是实务上的顺序。
TLS 卸载与数据库加密
CloudHSM 的代表性用例是 TLS/SSL 卸载。将 Web 服务器（Nginx、Apache）的 TLS 私钥保存在 CloudHSM 内，并在 HSM 内执行 TLS 握手时的私钥操作。私钥不会加载到服务器的内存或磁盘上，因此即使服务器被入侵，也可以避免私钥本身被带走的风险。对于 Nginx 和 Apache，官方介绍了将 CloudHSM 设置为 OpenSSL Dynamic Engine 的配置。对于 Java 的 Tomcat，提供了通过 JSSE 进行 TLS 卸载的步骤。 在数据库加密方面，可以使用 CloudHSM 管理 Oracle TDE（Transparent Data Encryption）的主加密密钥。在 Oracle Database 一侧的设置中将 CloudHSM 客户端指定为 PKCS#11 库，数据库的加密密钥就会在 HSM 内部受到保护。此外，将 Windows Server 配置为证书颁发机构、并将 CA 的私钥保存在 HSM 中的用法，也提供了官方的设置步骤。无论哪种情况，价值的核心都在于密钥不离开 HSM 这一特性，应用程序一侧只需通过标准 API 引用密钥即可。
CloudHSM 的费用
这里列出的单价是截至 2026 年 8 月弗吉尼亚北部区域和东京区域的值，月费按 1 个月 730 小时换算。 首先整理计费的维度。CloudHSM 的计费对象只有集群中预置的 HSM 的运行时间。不足 1 小时的部分也按 1 小时计费，单价因区域而异。单价不会因用户数或所保管的密钥数而改变。此外，与 HSM 之间的网络数据传输会按通常的数据传输费用另行计费。反之，不包含任何 HSM 的集群，以及 CloudHSM 自动获取的加密备份的保管，均不收取费用。 每台 hsm2m.medium 的单价在弗吉尼亚北部为每小时 1.60 美元，在东京为每小时 1.81 美元。按 730 小时换算，每台在弗吉尼亚北部约为 1,168 美元，在东京约为 1,321 美元。为了高可用性而在 2 个可用区各放置 1 台的架构，在弗吉尼亚北部每月约为 2,336 美元，在东京每月约为 2,643 美元。单价因区域而异，因此在估算时请分别确认目标区域的值。 关于最低计费和免费套餐，CloudHSM 没有免费套餐，也不提供类似预留实例的预付折扣。另一方面，对于验证用集群等不需要持续运行的用途，官方介绍了一种成本对策，即在不使用的期间将 HSM 减少到 0 台，并从备份恢复以重新开始。KMS 方面的费用基本上是每个密钥每月 1 美元（按小时分摊）和每 1 万个请求 0.03 美元，并在所有区域合计适用每月 20,000 个请求的免费套餐。但是，GenerateDataKeyPair 和 GenerateDataKeyPairWithoutPlaintext 不在免费套餐范围内。针对非对称密钥的 Sign、Verify、Encrypt、Decrypt、GetPublicKey 也不在免费套餐范围内。在使用 AWS CloudHSM 密钥存储的架构中，两者的费用会叠加。在 KMS 官方费用页面刊载的示例中，1 个密钥、约 199 万个计费请求以及 2 台 HSM 运行 31 天的合计为每月 2,387.77 美元。其中 2,380.80 美元是 HSM 的运行费用。从这一明细可以看出，专有 HSM 的成本支配了整个架构的成本。
专有管理所伴随的运维责任
CloudHSM 的最大特点是可以将加密密钥完全置于企业自身的管理之下，但这同时也意味着企业自身要承担密钥可用性和备份的责任。在托管的密钥管理服务中，密钥的冗余和备份由服务方承担，但在专有的 HSM 中，需要自己进行这方面的设计。一旦丢失密钥，就无法解密已加密的数据，因此将集群冗余部署在多个可用区并安全地备份密钥的运维是不可或缺的。 责任范围并不仅限于密钥的可用性。HSM 上的用户和角色在 IAM 之外管理，因此还需要将凭证的发放与吊销、权限的盘点作为自有流程加以完善。备份无法跨 FIPS 模式和非 FIPS 模式恢复，代际也仅限于从 hsm1.medium 到 hsm2m.medium 的单向。因此，灾难恢复的步骤必须以当前使用的代次和模式为前提来编写。此外，像从 hsm1.medium 迁移到 hsm2m.medium 这样跟进 HSM 代次和 Client SDK 版本的工作也会定期发生。获得完全控制的同时，也会产生维持这种控制的责任。选择专有管理时，重要的是判断是否具备承担这一运维负担的团队和能力。
总结 - CloudHSM 的使用方针
AWS CloudHSM 是希望以单租户硬件独占管理加密密钥时选择的服务。KMS 和 CloudHSM 都已转向使用通过 FIPS 140-3 Level 3 验证的 HSM 的一代，因此按验证级别高低进行选择的判断已经不再成立。判断依据有 5 点：硬件的独占、通过 PKCS#11 或 JCE 等进行的直接控制、密钥保管权的所在、合规要求是否指定到单租户性，以及能否承担运维责任。如果希望在将密钥材料放在自己集群中的同时保持与 AWS 服务的集成，也可以考虑 KMS 的 AWS CloudHSM 密钥存储这一折中方案。HSM 类型中 hsm2m.medium 是当前一代，hsm1.medium 已于 2026 年 3 月 31 日终止支持，因此正在运营现有集群时，确认迁移状况是第一步。费用在 2 台架构下每月约 2,336 美元（弗吉尼亚北部）到约 2,643 美元（东京），处于相当的水平。因此，建议对照上述 5 个依据确认要求之后再决定是否采用（截至 2026 年 8 月）。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。