Partager via

托管 HSM 中的安全域概述

托管 HSM 是一个单租户、已通过美国联邦信息处理标准 (FIPS) 140-3 验证且高度可用的硬件安全模块 (HSM)，其中包含客户控制的安全域。

要想运行，托管 HSM 必须具有一个安全域。 安全域是一个加密的 Blob 文件，其中包含 HSM 备份、用户凭据、签名密钥和托管 HSM 独有的数据加密密钥等项目。

托管 HSM 安全域具有以下用途：

  • 通过以加密方式将每个托管 HSM 关联到由你独自控制的信任根密钥来建立“所有权”。 这可确保 Azure 无法访问托管 HSM 上的加密密钥材料。

  • 为托管 HSM 实例中的密钥材料设置加密边界。

  • 允许你在发生灾难时完全恢复托管 HSM 实例。 涵盖以下灾难场景：

    • 在灾难性故障中，托管 HSM 实例的所有成员 HSM 实例均被破坏。
    • 客户将托管 HSM 实例进行了软删除，当强制保留期限到期后，资源被彻底清除。
    • 客户通过执行备份（其中包含托管 HSM 实例和所有数据）存档了某个项目，然后删除了与该项目关联的所有 Azure 资源。

如果没有安全域，灾难恢复无法实现。 Azure 无法恢复安全域，并且无法在没有安全域的情况下访问密钥。 因此，保护安全域对于实现业务连续性以及确保不会以加密方式将你锁定在系统之外至关重要。

安全域保护最佳做法

实施以下最佳做法，帮助确保保护安全域。

下载已加密的安全域

安全域是在初始化期间，在托管 HSM 硬件和服务软件安全区中生成的。 预配托管 HSM 后，必须至少创建 3 个 RSA 密钥对，并在请求安全域下载时将公钥发送到服务。 你还需要指定将来解密安全域所需的最小密钥数量（法定数量）。

托管 HSM 将初始化安全域，并通过使用 Shamir 的机密共享算法提供的公钥对其进行加密。 下载安全域后，托管 HSM 将进入已激活状态，并准备好供你使用。

存储安全域密钥

安全域的密钥必须保存在脱机存储设备中（例如已加密的 USB 驱动器），其中法定成员每个部分应在单独的存储设备上拆分存储。 该存储设备必须保管在不同的地理位置，并存放在物理保险箱或锁柜中。 对于超敏感和高保障用例，甚至可以选择将安全域私钥存储在本地的脱机 HSM 上。

定期审查托管 HSM 法定人数的安全策略尤为重要。 安全策略必须准确；必须保留安全域及其私钥存储位置的最新记录，并且必须知道谁有权控制安全域。

以下是安全域密钥处理禁止事项：

  • 绝对不能允许某个人以物理方式访问所有仲裁密钥。 换言之，m 必须大于 1（理想情况下应该 >= 3）。
  • 切勿将安全域密钥存储到具有 Internet 连接的计算机上。 连接到 Internet 的计算机面临各种威胁，例如病毒和恶意黑客。 可以通过脱机存储安全域密钥来大幅降低风险。

建立安全域多数共识

保护安全域并防止加密锁定的最佳方式是使用托管 HSM 概念 仲裁实现多人控制。 法定人数是一种分裂密钥阈值，将用于加密安全域的密钥在多个人员之间拆分。 法定人数强制实施多人员控制。 这样，安全域就不会依赖于可能离职或怀有恶意的单个人员。

我们建议实施 m 人的法定人数，其中 m 大于或等于 3。 托管 HSM 安全域的最大法定人数为 10。

尽管更大的 m 大小可以提供更高的安全性，但它在处理安全域方面会造成额外的管理开销。 因此，必须慎重选择安全域的仲裁数量，并至少确保 m>= 3。

此外，应定期审查和更新安全域仲裁组的大小（例如，如果发生人员变动）。 记录安全域持有者尤其重要。 记录中应记载每一次所有权移交或更改。 策略应严格遵循法定人数和文档要求。

由于这些密钥允许访问托管 HSM 最敏感和最关键的信息，因此安全域私钥必须由组织中受信任的要职人员持有。 安全域持有者应充当独立的角色，并分散在组织中不同的地理位置。

例如，一个安全域的仲裁可能由四对密钥组成，其中每个私钥分别由一名不同的人员持有。 至少需要由两个人员来共同重建一个安全域。 可将这些组成部分分配给关键人员，例如：

  • 业务部技术主管
  • 安全架构师
  • 安全工程师
  • 应用程序开发人员

每个组织的情况各不相同，可以根据其需求强制实施不同的安全策略。 我们建议定期审查安全策略以确保其合规性，并为仲裁及其规模做出相关决策。 你的组织可以选择审查的时间，但我们建议至少每季度开展一次安全域审查，并在出现以下情况时进行审查：

  • 某位法定人数成员离开组织。
  • 遇到新的或潜在的威胁时，你可能决定增加法定成员的数量。
  • 实施仲裁的流程发生了变化。
  • 属于安全域法定人数成员的 USB 驱动器或 HSM 丢失或被攻破。

安全域遭到入侵或丢失

如果安全域遭到入侵，恶意参与者可能会使用它来创建自己的托管 HSM 实例。 恶意参与者可以使用对密钥备份的访问来开始解密受托管 HSM 上的密钥保护的数据。

丢失的安全域被认为已遭到入侵。

安全域泄露后，必须使用当前密钥材料解密通过当前托管 HSM 加密的所有数据。 必须预配新的 Azure 密钥保管库托管 HSM 实例，并且必须实施指向新 URL 的新安全域。

由于无法将密钥材料从一个托管 HSM 实例迁移到另一个具有不同安全域的实例，因此实现安全域必须经过很好的考虑，并且必须通过准确、定期审查的记录保存来保护它。

安全域密钥遭到入侵或丢失

如果保护安全域密钥的安全性遭到入侵或丢失，或者策略要求定期更换安全域密钥，则可以下载一个由一套新的密钥组保护的新安全域副本。 具有托管 HSM 管理员角色的用户可以使用一组新的安全域整合密钥，再次执行安全域下载命令。 在删除旧密钥和以往的安全域副本之前，应对新的密钥和安全域进行测试，并且安全进行存储。 使用新的保护密钥重新下载安全域，不会影响 HSM 中的任何现有密钥。 安全域本身不会更改，只有保护它的密钥更改。

重要

托管 HSM 管理员角色是一个高度特权角色。 应针对“SecurityDomainBackup”和“SecurityDomainBackupStatusGet”操作设置通知和警报，强烈建议在托管 HSM 管理员角色上启用 PIM。

总结

安全域及其对应的私钥在托管 HSM 操作中发挥着重要作用。 这些工件类似于保险箱的组合，管理不善可能很容易削弱强大的算法和系统。 如果攻击者知道了安全措施组合，则即使是最强大的安全措施也不能提供安全保障。 安全域及其私钥的适当管理对于有效使用托管 HSM 至关重要。

在制定和实施所需的策略、系统与标准来满足和增强组织安全目标之前，强烈建议查看 NIST 专刊 800-57 来了解密钥管理最佳做法。

后续步骤

  • Last updated on