Azure 托管 HSM 扩展指南

本文档介绍如何正确规划 Azure 托管 HSM 的容量。

容量规划的常见客户方案

客户托管密钥静态加密

使用客户管理的密钥的 Azure 服务执行少量的获取密钥、包装和解包作，然后定期检查访问权限时缓存结果。 这意味着每小时只进行几次呼叫。 由于此行为，使用托管 HSM 进行静态加密时，不太可能达到本文档中所述的吞吐量限制。

自定义应用程序

对于对自定义应用程序使用托管 HSM 的客户，基准编号可用作构建自定义应用程序的大致预期。 托管 HSM 不会对加密操作事务进行限制，并充分发挥 HSM 硬件和 CPU 的性能。 这些数字应用作容量规划的指南，不过我们建议进行负载测试和验证性能编号。 这些数字是 HSM 及其当前固件的固有限制。

规划加密操作的交易容量

每个托管 HSM 实例构成三个负载均衡的 HSM 分区。 吞吐量限制是为每个分区分配的基础硬件容量的功能。 表显示内部测量的近似最大吞吐量，至少有一个分区可用。 如果所有三个分区都可用，则实际吞吐量可能高达 3 倍。 在修复硬件故障、修补服务器和其他服务代码更新期间，偶尔会关闭分区。 对于容量规划，可以放心地假设有 2 个分区可用。 如果需要每秒的操作数量有保证，请记住在容量规划中只考虑一个分区可用。

若要扩展大量数据的加密能力，我们建议使用密钥层次结构，其中只有密钥加密密钥存储在托管 HSM 中，并用于封装低层密钥。 有关详细信息，请参阅 Azure 静态数据加密：使用密钥层次结构进行信封加密

基准数字是通过内部性能测试对当前硬件及其当前固件进行逐个关键操作计算得出的。 每个密钥操作都在单分区的 MHSM 池上运行，并且每个请求使用相同的密钥。 显示的数字是每秒平均操作次数，持续 5 分钟。

这些数字假定使用一个键来实现最大吞吐量。 例如，如果使用单个 RSA-2048 密钥，最大吞吐量为 900 个签名作。 如果使用每秒 900 个不同密钥，每秒一个事务，则它们将无法实现相同的吞吐量。

这些数字将在托管 HSM 固件更新后更新，基于我们的内部性能测试。

RSA 密钥操作（每个 HSM 实例每秒操作次数）

EC 密钥操作（每个 HSM 实例每秒操作次数）

下表描述了每个曲线类型的每秒作数。

AES 密钥操作（每个 HSM 实例每秒的操作次数）

Wrap/Unwrap 的吞吐量限制适用于 AES-KW 算法。

管理操作的事务限制（每个 HSM 实例的并发操作数）