你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

数据加密模型

若要了解 Azure 资源提供程序如何实现静态加密,需要了解不同的加密模型及其优点和缺点。 为了确保公共语言和分类,Azure 资源提供程序共享这些定义。

默认情况下,Azure 使用平台管理的密钥自动加密静态数据。 可以选择根据安全性和符合性要求选择其他密钥管理方法。 服务器端加密包括三种场景:

  • 服务器端加密,使用平台管理密钥(默认)。

    • Azure 资源提供程序执行加密和解密作。
    • Microsoft自动管理密钥。
    • 默认情况下启用,无需配置。
    • 完整的云功能。
  • 服务器端加密,使用Azure 密钥保管库中的客户管理密钥(可选)。

    • Azure 资源提供程序执行加密和解密作。
    • 你通过 Azure 密钥保管库 控制密钥。
    • 需要客户配置和管理。
    • 完整的云功能。
  • 服务器端加密通过使用客户管理的密钥在客户控制的硬件上进行(高级选项)。

    • Azure 资源提供程序执行加密和解密作。
    • 可在客户控制的硬件上控制密钥。
    • 复杂的配置和有限的 Azure 服务支持。
    • 完整的云功能。

服务器端加密模型是指 Azure 服务执行的加密。 在该模型中,资源提供程序执行加密和解密作。 例如,Azure 存储可能会在明文操作中接收数据,并在内部执行加密和解密。 资源提供商可能会使用Microsoft或客户管理的加密密钥,具体取决于你的配置。

示意图显示 Azure 服务执行服务器端加密并用管理加密密钥存储加密数据。

每个服务器端静态加密模型都具有密钥管理的独特特征。 这些特征包括创建和存储加密密钥的位置和方式,以及访问模型和密钥轮换过程。

对于客户端侧加密,请考虑:

  • Azure服务看不到解密的数据。
  • 客户在本地(或其他安全存储中)管理和存储密钥。 Azure服务无权访问密钥。
  • 减少云功能。

Azure 支持的加密模型分为两大类:客户端加密服务器端加密。 无论使用哪种静态加密模型,Azure 服务始终建议使用安全传输,例如 TLS 或 HTTPS。 因此,传输中的地址加密通过传输协议实现。 它不应成为决定采用哪种静止加密模型的主要因素。

客户端加密模型

客户端加密模型指的是服务或调用应用程序在资源提供者或 Azure 外部执行的加密。 Azure 中的服务应用程序或客户数据中心中运行的应用程序可以执行加密。 无论哪种情况,使用这种加密模型时,Azure资源提供者都会收到一个加密的数据块,但无法以任何方式解密数据或访问加密密钥。 在此模型中,调用服务或应用程序处理密钥管理,并使其对 Azure 服务保持不透明。

图示显示一个应用程序在发送加密数据到Azure服务之前对数据进行加密。

使用平台管理密钥进行服务器端加密(默认)

对于大多数组织来说,关键要求是确保数据在静止时被加密。 服务器端加密通过使用平台管理密钥(以前称为服务管理密钥)满足了这一需求,默认提供自动加密。 这种方法允许静止加密,无需配置或管理加密密钥。 Microsoft负责密钥管理任务,如密钥的发布、轮换和备份。

大多数 Azure 服务默认将此模型实现为默认行为,通过使用平台管理的密钥自动加密静态数据,无需客户操作。 Azure 资源提供程序创建密钥,将其置于安全的存储中,然后根据需要对其进行检索。 该服务拥有对密钥的完全访问权限,并对凭证生命周期管理保持完全控制权。 这种控制提供了强大的加密保护,且无管理开销。

图示了使用平台管理密钥实现服务器端加密的Microsoft管理密钥存储。

服务器端加密通过使用平台管理密钥满足了静止加密的需求,且无开销。 Azure默认在Azure服务中支持这种加密,提供自动数据保护,无需任何配置或管理。 在将数据存储到Azure服务时,您可以立即享受强加密保护,无需额外步骤、成本或持续管理。

使用平台管理密钥的服务器端加密意味着服务拥有存储和管理密钥的完全访问权限。 虽然有些组织可能希望管理密钥,因为他们期望更高的安全性,但在评估这种模式时,也要考虑定制密钥存储解决方案的成本和风险。 在许多情况下,组织可能会确定本地解决方案的资源约束或风险大于云管理静态密钥的风险。 然而,对于需要控制加密密钥创建或生命周期,或需要不同人员管理服务加密密钥(将密钥管理与整体管理模式分离)的组织来说,这种模型可能不足以满足需求。

密钥访问权限

当你使用服务器端加密并使用平台管理密钥时,服务负责密钥的创建、存储和服务访问。 通常,基础的 Azure 资源提供者会将数据加密密钥存储在靠近数据且可快速访问的存储中,而密钥加密密钥则存储在安全的内部存储中。

优点

  • 简单设置。
  • Microsoft管理密钥轮换、备份和冗余。
  • 不会产生与实施自定义密钥管理方案相关的成本或风险。

考虑

  • 对加密密钥(密钥规范、生命周期、撤销等)没有控制。 此选项适用于大多数用例,但可能不符合专门的合规性要求。
  • 无法将密钥管理与服务的整体管理模型隔离开来。 需要职责分离的组织可能需要客户管理的密钥。

使用 Azure 密钥保管库 和 Azure 密钥保管库 Managed HSM 中客户管理的密钥进行服务器端加密(可选)

对于组织有特定要求控制其加密密钥的场景,超出默认平台管理加密,你可以选择在 密钥保管库 或 Azure 密钥保管库 Managed HSM 中使用客户管理密钥,选择服务器端加密。 这种方法建立在默认静止加密的基础上,允许你使用自己的密钥,而 Azure 继续处理加密和解密操作。

有些服务可能只在 Azure 密钥保管库 中存储根密钥加密密钥(KEK),并将加密数据加密密钥(DEK)存储在更靠近数据的内部位置。 在这种情况下,你可以使用自带密钥(BYOK)模型导入密钥到 密钥保管库,或在 密钥保管库 中生成新密钥,然后用它们加密所需的资源。 虽然资源提供者执行加密和解密操作,但所有加密操作的根密钥都使用你配置的 KEK。

密钥加密密钥丢失意味着数据丢失。 因此,请勿删除密钥。 创建或轮换密钥时,请始终备份密钥。 当KEK被轮换时,服务会用新的密钥版本包裹数据加密密钥——底层数据不会被重新加密。 旧密钥版本和新密钥版本都必须保持启用状态,直到所有数据加密密钥都被新密钥版本封装完成。 为防止意外或恶意的加密删除,必须在存储密钥加密密钥的保险库上启用 软删除和清除保护 。 不要删除密钥,而是在密钥加密密钥上将 enabled 属性设置为 false。 使用访问控制来撤消对 Azure 密钥保管库托管的 HSM中的单个用户或服务的访问权限。

Warning

如果你怀疑某个密钥被泄露,不要立即禁用或删除它。 禁用或删除密钥会使所有依赖服务下线,但不会使备份并恢复到另一个保险库的密钥副本失效。 这些副本仍然完全正常运行。 而是轮换到新密钥,并在禁用已泄露密钥之前迁移所有依赖服务。 有关完整的事件响应过程,请参阅 备份安全注意事项密钥泄露响应

对于客户管理的密钥场景,使用Azure 密钥保管库 Premium层(HSM支持)作为强制使用HSM保护密钥的合规要求的最低标准。 对于需要密钥主权或专用HSM容量的工作负载,可以使用Azure 密钥保管库托管HSM。 对于那些有监管或合同要求,要求密钥材料必须物理存放在 Microsoft 基础设施之外的组织,Azure 密钥保管库 托管 HSM 也支持外部密钥管理(预览版),将 KEK 保持在完全 Azure 外部的客户运营 HSM 中。

注意

关于支持 Azure 密钥保管库 和 Azure 密钥保管库 Managed HSM 中客户管理密钥的服务列表,请参见支持 Azure 密钥保管库 和 Azure 密钥保管库 Managed HSM 中的 CMK 服务

密钥访问权限

在使用客户管理密钥的服务器端加密模型中,Azure 密钥保管库 服务访问密钥以根据需要进行加密和解密。 你可以通过访问控制策略使静态加密密钥对服务可用。 此策略授予服务标识接收密钥所需的访问权限。 可以使用该订阅中的标识来配置代表关联的订阅运行的 Azure 服务。 该服务可以执行 Microsoft Entra 身份验证,然后会收到一个身份验证令牌,将服务本身标识为代表该订阅的服务。 服务随后将令牌交给 密钥保管库,以获取其可访问的密钥。

对于使用加密密钥的操作,你可以授予服务标识对以下任一操作的访问权限:decryptencryptunwrapKeywrapKeyverifysigngetlistupdatecreateimportdeletebackuprestore

为了获得用于加密或解密静态数据的密钥,资源管理器 服务实例运行时必须拥有UnwrapKey(用于获取解密密钥)和WrapKey(在创建新密钥时插入密钥到密钥保管库)的服务身份。

注意

有关 密钥保管库 授权的更多信息,请参见 Secure your key vault

优点

  • 完全控制所使用的密钥。 加密密钥由你控制的密钥保管库管理。
  • 你可以用一个根密钥加密多个服务。
  • 你可以将密钥管理与服务的整体管理模式分离。
  • 你可以在不同地区定义服务和密钥位置。

缺点

  • 你完全负责密钥访问管理。
  • 你完全负责关键生命周期管理。
  • 额外的设置和配置负担。

通过在客户控制的硬件中使用客户管理密钥实现服务器端加密(专用选项)

某些 Azure 服务为具有专用安全要求的组织启用“托管自己的密钥”(HYOK)密钥管理模型。 这种管理模式在高度受控的场景中非常有用,这些场景需要对静态数据进行加密,并在完全不受Microsoft控制的专有仓库中进行密钥管理。 它超越了默认的平台管理加密和Azure 密钥保管库中的可选客户管理密钥。

在该模型中,服务必须使用外部站点的密钥来解密DEK。 性能和可用性保证受到影响,配置更为复杂。 此外,由于服务在加密和解密操作中无法访问DEK,该模型的整体安全保障类似于Azure 密钥保管库中由客户管理密钥时。 因此,此模型不适用于大多数组织,除非它们具有非常具体的法规或安全要求,这些要求无法在Azure 密钥保管库中使用平台管理的密钥或客户管理的密钥。 由于这些限制,大多数 Azure 服务不支持服务器端加密,即在客户控制的硬件中使用客户管理的密钥。 双密钥加密中的两个密钥之一遵循该模型。

密钥访问权限

当你在客户控制的硬件中使用服务器端加密和客户管理密钥时,你会将密钥加密密钥保存在你配置的系统中。 支持此模型的 Azure 服务提供了建立与客户提供的密钥存储的安全连接的方法。

优点

  • 你对根密钥有完全控制权,因为加密密钥由客户提供的商店管理。
  • 你可以用一个根密钥加密多个服务。
  • 你可以将密钥管理与服务的整体管理模式分离。
  • 你可以在不同地区定义服务和密钥位置。

缺点

  • 你完全负责密钥存储、安全性、性能和可用性。
  • 你完全负责密钥访问管理。
  • 你完全负责关键生命周期管理。
  • 会产生大量设置、配置和持续维护费用。
  • 该模型增加了客户数据中心与 Azure 数据中心之间对网络可用性的依赖。