Azure 托管 HSM 缩放指导

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

容量规划的常见客户方案

静态加密客户管理的密钥

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

自定义应用程序

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

规划加密操作的交易容量

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

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

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

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

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

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

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

下表说明了针对每个曲线类型每秒可执行的操作次数。

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

包装/解包吞吐量限制适用于 AES-KW 算法。

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

有关 Azure 托管 HSM 服务限制，请参阅 托管 HSM 服务限制。