通过 AWS CloudHSM 实现专用密钥管理 - 符合 FIPS 140-3 Level 3 的加密
通过专有 HSM 实例实现符合 FIPS 140-3 Level 3 的密钥管理。介绍与 KMS 的区分使用以及通过 KMS 自定义密钥存储实现两者集成的方法。
CloudHSM 概述
CloudHSM 是一项通过专用硬件安全模块（HSM）管理加密密钥的服务。与 KMS 使用多租户共享 HSM 不同，CloudHSM 提供专有的 HSM 实例。当前一代的实例类型为 hsm2m.medium，FIPS 模式的集群已通过 FIPS 140-3 Level 3 验证（证书 #4703，截至 2026 年 8 月）。上一代 hsm1.medium 所获得的 FIPS 140-2 Level 3（证书 #4218）已于 2026 年 1 月 4 日移入 CMVP 的 historical list，因此在以认证等级为依据向审计方说明时，应参照当前一代的 140-3。集群在创建时选择 FIPS 模式或非 FIPS 模式之一，创建后无法更改模式（仅 hsm2m.medium 可以选择非 FIPS 模式）。备份也无法跨模式恢复，因此必须在初始设计阶段确定模式的选择。hsm2m.medium 在 1 个集群中最多可存储 16,666 个密钥，并支持客户端与 HSM 之间的双向 TLS（mTLS）。连接使用 Client SDK 5（5.9.0 及以后版本）。密钥在 HSM 内生成和存储，密钥材料永远不会以明文形式导出到 HSM 外部。即使是 AWS 工作人员，在设计上也无法访问密钥，密钥的完全所有权归用户所有。FIPS 模式的集群满足 PCI PIN、PCI-3DS、SOC 2 的要求，因此在处理金融、医疗、政府机构合规要求的配置中，应选择 FIPS 模式。
与 KMS 的区分使用
KMS 适用于大多数用例，运维负担低且与 AWS 服务的集成丰富。KMS 与 CloudHSM 的 FIPS 模式都在通过 FIPS 140-3 Level 3 验证的 HSM 中保护密钥（截至 2026 年 8 月），因此“选择验证等级更高的一方”这种思路如今已不成立。选型依据以下 5 个维度进行。第一个维度是是否需要单租户独占：CloudHSM 独占仅供自己使用的 HSM，而 KMS 使用由 AWS 运营的共享 HSM 设备群。第二个维度是是否需要直接控制加密处理：使用 CloudHSM 时，应用程序可通过 PKCS#11、JCE、CNG/KSP、OpenSSL 的标准接口直接操作 HSM，而 KMS 仅限于通过 KMS API 进行操作。第三个维度是密钥的保管权，即由谁持有密钥材料、由谁创建密钥的使用者：在 CloudHSM 中，HSM 用户的创建和密钥的生命周期都由使用方负责，AWS 不接触密钥材料。第四个维度是合规方面的特定要求：如果审计要求涉及专有硬件或自有的密钥层级，则 CloudHSM 是前提条件。第五个维度是运维责任与可用性：KMS 的可用性和补丁应用由 AWS 负责，而 CloudHSM 的集群设计、备份和凭据管理由使用方负责。KMS 自定义密钥存储结合了两者的优势，在保持 KMS 的 API 和集成性的同时，将密钥存储在 CloudHSM 中。在吞吐量方面，KMS 的对称密钥操作有共享的请求速率配额，默认值在许多区域为每秒 10,000 个请求，在东京、俄亥俄、新加坡、悉尼、法兰克福、伦敦为每秒 20,000 个请求，在弗吉尼亚北部、俄勒冈、爱尔兰为每秒 100,000 个请求（截至 2026 年 8 月的官方文档记载值）。RSA 密钥、ECC 密钥等非对称密钥操作另有每秒 1,000 个请求的配额，AWS CloudHSM 密钥存储和外部密钥存储的密钥为每秒 1,800 个请求，这两者无法申请提高。CloudHSM 单台的处理性能未公开，因此需用自己的工作负载实测所需的吞吐量，并通过 HSM 的台数进行调整。
集群设计与高可用性
CloudHSM 集群在多个 AZ 中部署 HSM 实例，通过密钥自动同步确保高可用性。推荐至少在 2 个 AZ 中部署 HSM，即使一个 HSM 发生故障，也可以在另一个 AZ 的 HSM 上继续处理。客户端 SDK 以轮询方式将请求分发到集群内的 HSM，故障时自动进行故障转移。HSM 的备份会自动加密保存到 S3，用于集群恢复或跨区域复制。通过 PKCS#11、JCE、OpenSSL 的标准接口从应用程序执行加密操作，可将现有应用程序代码的修改降至最低。
代表性使用场景
CloudHSM 的主要用例包括 SSL/TLS 卸载、数据库加密（TDE）、代码签名和文档签名、私有证书颁发机构（CA）密钥存储、金融交易签名（PCI DSS 合规）以及令牌化。在 SSL/TLS 卸载中，Web 服务器的私钥存储在 HSM 中，通过 OpenSSL 引擎委托签名处理，从而消除 EC2 实例内存中的私钥。与 Oracle TDE 和 Microsoft SQL Server TDE 集成以在 HSM 中保护数据库加密密钥也是常见配置。与 AWS Private CA 结合，将 CA 私钥保管在 CloudHSM 中并在 HSM 中执行证书签名处理，可降低 CA 密钥泄露风险。
CloudHSM 的定价与运维注意事项
费用（截至 2026 年 8 月，弗吉尼亚北部 / 东京）的计费维度只有 HSM 实例的运行时间，不会因存储的密钥数量或 HSM 用户数量而变化。单价为每台 hsm2m.medium 在弗吉尼亚北部 1.60 美元/小时、在东京 1.81 美元/小时。运行不足 1 小时也按 1 小时计费。按每月 730 小时换算，1 台配置约为 1,168 美元 / 约 1,321 美元，为实现高可用性在 2 个 AZ 中部署 2 台时约为 2,336 美元 / 约 2,643 美元。不含 HSM 的空集群以及备份的存储不收费，数据传输另行计费。没有免费套餐，也没有预留购买折扣。KMS 的基本费用为每个客户管理的密钥每月 1 美元、每 1 万个请求 0.03 美元，并且每月有 20,000 个请求的免费套餐（GenerateDataKeyPair 系列和非对称密钥的操作不在免费套餐范围内）。由于固定费用的差距很大，CloudHSM 应仅限于有专有 HSM 或特定合规要求的范围内使用。运维方面的注意事项是，如果丢失 Crypto Officer（CO）的凭据，将永久无法访问集群中的密钥，因此凭据的安全保管不可或缺。HSM 用户管理（CU: Crypto User、CO: Crypto Officer）独立于 AWS IAM，通过 HSM 内部的用户管理命令进行。集群的初始化流程为：在 Linux 上将签发的证书放置到 /opt/cloudhsm/etc/ 并使配置文件的名称一致，然后执行 CloudHSM CLI（Client SDK 5）的 cluster activate，设置初始 admin 密码并启用 admin（CO）。之后以 CO 身份创建 CU，并允许应用程序执行密钥操作。上一代的 CloudHSM Management Utility（CMU）和 Key Management Utility（KMU）是 Client SDK 3 和 hsm1.medium 专用的工具，在当前一代中无法使用。
需要专用 HSM 的场景
许多加密用途都可以通过托管的密钥管理服务充分应对。即便如此，在存在特定要求的情况下，仍需要专用 HSM。典型情况是，法规或合规要求在满足规定认证等级的专用硬件上进行密钥管理。此外，如果希望保证密钥由本公司完全独占和管理、包括云服务商在内的任何外部方都无法接触，专用 HSM 也是一个选项。也有需要自有加密处理或符合特定行业标准的场景。现实的做法是，仅在有这些严格要求的部分使用专用 HSM，其余部分则由托管服务承担。
总结
CloudHSM 是通过专有硬件安全模块管理加密密钥、满足以 FIPS 140-3 Level 3 验证为前提的严格合规要求的服务。通过 KMS 自定义密钥存储可从 KMS API 操作 CloudHSM 的密钥，通过 PKCS#11 和 JCE 的标准接口也可轻松与现有应用程序集成。由于固定费用较高，重要的是仅在专有性和密钥保管要求明确的范围内采用，并慎重规划凭据管理和高可用性设计。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。