托管 HSM 中的密钥主权、可用性、性能和可伸缩性
加密密钥是用于保护现代计算机系统（无论是在本地还是云中）的信任根。 因此，控制谁对这些密钥拥有权限对于构建安全且合规的应用程序至关重要。
在 Azure 中，我们对于如何在云中进行密钥管理的愿景是密钥主权。 密钥主权是指客户所在组织可以完全且独占地控制谁可以访问和更改密钥管理策略，以及由哪些 Azure 服务使用这些密钥。 在客户做出这些决策后，Azure 人员将无法通过技术手段更改这些决策。 密钥管理服务代码执行客户的决策，直到客户告诉它不这样做，Azure 人员无法干预。
同时，我们认为云中的每项服务必须接受全面的管理。 在服务级别协议 (SLA) 的支持下，服务必须提供所需的可用性、复原能力、安全性和云基本承诺。 为了提供托管服务，Azure 需要修补密钥管理服务器，升级硬件安全模块 (HSM) 固件，修复故障硬件，执行故障转移以及执行其他高特权操作。 正如大多数安全专业人员所知，拒绝具有高特权或物理访问权限的人员访问系统内的数据是一个难题。
本文介绍了如何通过结合使用机密计算技术与 HSM 在 Azure 密钥保管库托管 HSM 服务中解决此问题，从而为客户提供完整的密钥主权和完全托管服务 SLA。
托管 HSM 硬件环境
在任何 Azure 区域中，客户的托管 HSM 池位于安全的 Azure 数据中心内。 三个实例分布在多个服务器上。 每个实例部署在不同的机架中，以确保冗余。 每台服务器具有一个 FIPS 140-2 级别 3 验证的 Marvell LiquidSecurity HSM 适配器，其中包含多个加密核心。 核心用于创建完全隔离的 HSM 分区，其中包括完全隔离的凭据、数据存储和访问控制。
数据中心内实例的物理分隔对于确保单个组件（例如机架顶部交换机、机架中的电源管理单元）的丢失不会影响池的所有实例至关重要。 这些服务器专用于 Azure 安全 HSM 团队。 服务器不会与其他 Azure 团队共享，并且不会在这些服务器上部署任何客户工作负载。 物理访问控制（包括锁定的机架）用于防止未经授权访问服务器。 这些控制措施符合 FedRAMP-High、PCI、SOC 1/2/3、ISO 270x 和其他安全和隐私标准，并作为 Azure 合规性计划的一部分定期进行独立验证。 HSM 具有增强的物理安全性，经验证符合 FIPS 140-2 级别 3 要求。 整个托管 HSM 服务基于标准安全 Azure 平台（包括受信任启动）构建，可防范高级持久威胁。
HSM 适配器可以为数十个隔离的 HSM 分区提供支持。 在每台服务器上运行的是一个名为节点服务的控制进程。 节点服务会获取每个适配器的所有权，并安装适配器所有者的凭据（在本例中为 Microsoft）。 HSM 的设计确保适配器的所有权机制不允许 Azure 访问存储在客户分区中的数据。 它只允许 Azure 创建、删除客户分区以及调整其大小。 它支持对客户的任何分区进行盲备份。 在盲备份中，备份由客户提供的密钥包装，盲备份是由客户提供的密钥包装的备份，只能通过客户拥有的托管 HSM 实例内的服务代码进行还原，并且 Microsoft 无法读取其中的内容。
托管 HSM 池的体系结构
图 1 显示了 HSM 池的体系结构，该池由三台 Linux VM 组成，每个 VM 在自己的数据中心机架中的 HSM 服务器上运行，以支持可用性。 重要组件包括：
- HSM 结构控制器 (HFC) 是服务的控制平面。 HFC 驱动池的自动修补和修复。
- 符合 FIPS 140-2 级别 3 的加密边界专属于每名客户，其中包括三个 Intel 安全防护扩展 (Intel SGX) 机密飞地，每个飞地连接到一个 HSM 实例。 此边界的根密钥生成并存储在三个 HSM 中。 如本文稍后所述，与 Azure 关联的人员无权访问此边界内的数据。 只有代表客户运行在 Intel SGX 飞地（包括节点服务代理）中的服务代码具有访问权限。
受信任执行环境 (TEE)
托管 HSM 池由三个服务实例组成。 每个服务实例都实施为使用 Intel SGX 功能和开放飞地 SDK 的受信任执行环境 (TEE)。 TEE 内的执行可确保托管服务的虚拟机 (VM) 或 VM 主机服务器上的任何人无权访问客户机密、数据或 HSM 分区。 每个 TEE 专用于特定客户，它运行 TLS 管理、请求处理和对 HSM 分区的访问控制。 除了作为安全域包的一部分之外，此 TEE 之外不存在任何明文形式的凭据或客户特定数据加密密钥。 该包将加密到客户提供的密钥，并在首次创建池时下载。
TEE 使用经过证明的 TLS 在它们之间进行通信。 经证明的 TLS 会将 Intel SGX 平台的远程证明功能与 TLS 1.2 结合使用。 通过此操作，TEE 中的 MSHM 代码可将其通信限制为仅由同一 MHSM 服务代码签名密钥签名的其他代码，以防范中间人攻击。 托管 HSM 服务的代码签名密钥存储在 Azure 产品发布和安全服务中（该服务也用于存储其他密钥，例如 Windows 代码签名密钥）。 密钥由托管 HSM 团队控制。 任何其他 Azure 团队都不能使用此密钥来签署其代码，此规定是我们的变更管理监管和合规义务的一部分。
用于 TEE 到 TEE 通信的 TLS 证书由 TEE 中的服务代码自行颁发。 证书包含由服务器上的 Intel SGX 飞地生成的平台报告。 平台报表使用在制造时由 Intel 融合到 CPU 的密钥中派生的密钥进行签名。 报表通过代码签名密钥和二进制哈希标识加载到 Intel SGX 飞地中的代码。 根据此平台报表，服务实例可以确定对等机也由托管 HSM 服务代码签名密钥进行签名，并且通过平台报表进行的一些加密纠缠时，它还可以确定自行颁发的证书签名密钥也必须在 TEE 内部生成，从而防止外部模拟。
提供具有完全客户管理的密钥控制的可用性 SLA
为了确保高可用性，HFC 服务会在客户选择的 Azure 区域中创建三个 HSM 实例。
托管 HSM 池创建
托管 HSM 池的高可用性属性来自自动托管的三个冗余 HSM 实例，这些实例始终保持同步（或者如果使用多区域复制，则保持所有六个实例同步）。 池创建由 HSM 服务管理，该服务会在客户选择的 Azure 区域中的可用硬件之间分配池。
请求新池时，HFC 将在 HSM 适配器上具有可用空间的多个机架中选择三台服务器，然后开始创建池：
HFC 将通过使用一组参数指示三个 TEE 中每一个上的节点服务代理启动服务代码的新实例。 这些参数可标识客户的 Microsoft Entra 租户、所有三个实例的内部虚拟网络 IP 地址，以及一些其他服务配置。 一个分区会随机分配为主实例。
将启动三个实例。 每个实例都连接到其本地 HSM 适配器上的一个分区，然后使用随机生成的用户名和凭据将分区归零并初始化（从而确保人工操作员或其他 TEE 实例无法访问该分区）。
主实例使用 HSM 中生成的私钥创建分区所有者根证书。 它通过使用此根证书对 HSM 分区的分区级证书进行签名来建立池的所有权。 主实例还会生成数据加密秘钥，用于保护服务中的所有静态客户数据。 对于密钥材料，将会使用双重包装，因为 HSM 本身也会保护密钥材料。
接下来，此所有权数据将同步到两个辅助实例。 每个辅助实例使用经证明的 TLS 联系主实例。 主实例使用私钥和数据加密密钥共享分区所有者根证书。 辅助实例现在使用分区根证书向其自己的 HSM 分区颁发分区证书。 完成此操作后，将在同一分区根证书拥有的三台独立服务器上拥有 HSM 分区。
通过经证明的 TLS 链接，主实例的 HSM 分区可通过使用 HSM 供应商提供的安全 API 与辅助实例共享其生成的数据包装密钥（用于加密三个 HSM 之间的消息）。 在此交换过程中，各个 HSM 确认它们具有相同的分区所有者证书，然后它们使用 Diffie-Hellman 方案对消息进行加密，使 Azure 服务代码无法读取它们。 服务代码所能做的就是在 HSM 之间传输不透明的 Blob。
此时，所有三个实例已经就绪，可以作为池在客户的虚拟网络中公开。 它们共享同一分区所有者证书、同一数据加密秘钥，以及公共数据包装密钥。 但是，每个实例都拥有其 HSM 分区的唯一凭据。 现在，最后的步骤已经完成。
每个实例将为其面向公众的 TLS 证书生成一个 RSA 密钥对和一个证书签名请求 (CSR)。 CSR 由 Azure 公钥基础结构 (PKI) 系统使用 Azure 公共根进行签名，并将生成的 TLS 证书返回给实例。
所有三个实例会从其本地 CPU 获取自己的 Intel SGX 密封密钥。 密钥是通过使用 CPU 自己的唯一密钥和 TEE 的代码签名密钥生成的。
池会从 Intel SGX 密封密钥派生唯一的池密钥，使用此池密钥加密其所有机密，然后将加密的 Blob 写入磁盘。 这些 Blob 只能通过由运行在同一物理 CPU 上的同一 Intel SGX 密封密钥进行代码签名来解密。 机密与该特定实例绑定。
安全启动过程现已完成。 此过程已允许创建三重冗余 HSM 池，以及创建客户数据主权的加密保证。
通过使用机密服务修复在运行时维护可用性 SLA
本文所述的池创建过程可以解释托管 HSM 服务如何通过安全管理构成服务基础的服务器来提供其高可用性 SLA。 假设服务器、HSM 适配器甚至机架的电源出现故障。 托管 HSM 服务的目标是将池恢复为三个运行正常的实例，而无需任何客户干预，也无需在 TEE 外部以明文形式公开机密。 这是通过机密服务修复实现的。
首先，HFC 会检测哪些池在故障服务器上具有实例。 HFC 在池的区域中查找新的正常运行的服务器，以便将替换实例部署到其中。 它会启动新实例，然后在初始预配步骤中完全将其视为辅助实例：初始化 HSM，查找其主实例，通过证明 TLS 安全地交换机密，将 HSM 签名到所有权层次结构中，然后将其服务数据密封到新的 CPU。 服务现已完全自动且完全保密地密封。
通过使用安全域从灾难中恢复
安全域 (SD) 是一个安全 Blob，其中包含从头开始重新生成 HSM 分区所需的所有凭据：分区所有者密钥、分区凭据、数据包装密钥以及 HSM 的初始备份。 在服务上线之前，客户必须通过提供一组 RSA 加密密钥来下载安全域，以确保其安全。 安全域数据源自 TEE，并由一个生成的对称密钥和 Shamir 的机密共享算法的实现提供保护，
该算法根据客户选择的仲裁参数将密钥份额拆分到客户提供的 RSA 公钥上。 在此过程中，不会以明文形式在 TEE 中运行的服务代码之外公开任何服务密钥或凭据。 只有客户（通过向 TEE 提供其 RSA 密钥的仲裁）才能在执行恢复方案期间解密安全域。
仅当由于某些灾难导致整个 Azure 区域丢失，并且 Azure 同时丢失了池的所有三个实例时，才需要安全域。 如果仅丢失一个甚至两个实例，则机密服务修复会在不发出任何提示的情况下恢复到三个正常实例，而无需客户干预。 如果整个区域丢失，因为 Intel SGX 密封密钥对每个 CPU 都是唯一的，所以 Azure 无法恢复 HSM 凭据和分区所有者密钥。 它们仅存在于实例的上下文中。
万一发生这种灾难，客户可以恢复其以前的池状态和数据，方法是创建一个新的空白池并将其注入安全域，然后提供其 RSA 密钥仲裁来证明对安全域的所有权。 如果客户启用了多区域复制，则在需要客户干预以从安全域恢复池之前，一定发生了两个区域同时遇到完全故障这一尤为不可能的灾难。
控制对服务的访问
如前所述，TEE 中的服务代码是唯一有权访问 HSM 本身的实体，因为不会向客户或其他任何人提供必要的凭据。 客户的池绑定到其 Microsoft Entra 实例，用于身份验证和授权。 在初始预配时，客户可以选择一组初始员工来分配池的管理员角色。 这些个人以及客户的 Microsoft Entra 租户全局管理员角色中的员工可以在池中设置访问控制策略。 所有访问控制策略由服务存储在与加密密钥相同的数据库中，这些策略也进行了加密。 只有 TEE 中的服务代码有权访问这些访问控制策略。
摘要
通过使用先进的、硬件支持的机密飞地技术，托管 HSM 使客户无需在可用性和控制加密密钥之间进行权衡。 如本文所述，在此实现中，任何 Azure 人员或代表都无法访问客户管理的密钥材料或相关机密，即使他们可以亲身访问托管 HSM 主机和 HSM 也是如此。 借助这种安全性，金融服务、制造业、公共部门、国防和其他垂直领域的客户能够满怀信心地加速向云迁移。