使用客户管理的密钥进行 Azure SQL 透明数据加密

适用范围：Azure SQL 数据库Azure SQL 托管实例Azure Synapse Analytics（仅限专用 SQL 池）

Azure SQL 中采用客户管理的密钥 (CMK) 的透明数据加密 (TDE) 支持创建自己的密钥 (BYOK) 应用场景来实现静态数据保护，并使组织能够在密钥和数据管理方面实现职责分离。 使用客户管理的 TDE 时，客户需要负责并可全面控制密钥生命周期管理（密钥创建、上传、轮换、删除）、密钥使用权限，以及密钥操作的审核。

在此方案中，透明数据加密（TDE）保护程序（用于保护数据库加密密钥（DEK）的客户管理的非对称密钥存储在 Azure Key Vault 或 Azure Key Vault 托管 HSM 中。 这些服务是安全的基于云的密钥管理服务，旨在实现高可用性和可伸缩性。 Azure Key Vault 支持 RSA 密钥，可由 FIPS 140-2 级别 2 验证的 HSM 提供支持。 对于需要更高保证的客户，Azure Key Vault 托管 HSM 提供 FIPS 140-2 级别 3 验证的硬件。 密钥可以在服务中生成、导入或 安全地从本地 HSM 传输。 直接访问密钥受到限制 - 授权服务执行加密作，而无需公开密钥材料。

对于 Azure SQL 数据库和 Azure Synapse Analytics，TDE 保护器在服务器级别设置，并由该服务器关联的所有已加密数据库继承。 对于 Azure SQL 托管实例，TDE 保护器是在实例级别设置的，并由该实例上所有加密的数据库继承。 除非另有说明，否则术语“服务器”在整个文档中指的是 SQL 数据库和 Azure Synapse 中的服务器和 SQL 托管实例中的托管实例。

可在 Azure SQL 数据库中的数据库级别管理 TDE 保护器。 有关详细信息，请参阅在数据库级别使用客户管理的密钥进行透明数据加密 (TDE)。

客户管理的 TDE 的优势

客户管理的 TDE 为客户提供以下优势：

• 完全、精细地控制 TDE 保护程序的使用情况和管理。

• TDE 保护器使用情况的透明度。

• 能够实现在组织内密钥和数据管理中的职责分离。

• Azure Key Vault 管理员可以撤销密钥访问权限，使加密的数据库不可访问。

• 在 Azure Key Vault 中集中管理密钥。

• 更信任最终用户，因为 Azure Key Vault 的设计使Microsoft无法查看或提取加密密钥。

配置客户管理 TDE 的权限

选择要使用的 Azure Key Vault 类型。

配置客户管理的 TDE 的要求

配置 TDE 保护程序的要求

• TDE 保护器只能为非对称的 RSA 或 RSA HSM 密钥。 支持的密钥长度为 2,048 位和 3,072 位。

• 密钥激活日期（如果已设置）必须是过去的日期和时间。 过期日期（如果已设置）必须是将来的日期和时间。

• 密钥必须处于“已启用”状态。

• 如果要将现有密钥导入密钥保管库，请确保它以受支持的文件格式之一提供： .pfx， .byok或 .backup。 若要将受 HSM 保护的密钥导入 Azure 托管 HSM，请参阅将受 HSM 保护的密钥导入托管 HSM（BYOK）。

有关配置客户管理的 TDE 的建议

配置 TDE 保护程序时的建议

• 将 TDE 保护器的副本保存在安全位置，或将其托管到托管服务。

• 如果在密钥保管库中生成密钥，请在首次使用 Azure Key Vault 中的密钥之前创建密钥备份。 备份只能还原到 Azure Key Vault。 详细了解 Backup-AzKeyVaultKey 命令。 Azure 托管 HSM 支持创建 HSM 的全部内容的完整备份，包括所有密钥、版本、属性、标记和角色分配。 有关详细信息，请参阅 完整备份和还原和选择性密钥还原。

• 每次对密钥（例如密钥属性、标记、ACL）做了任何更改后，请创建新的备份。

• 轮换密钥时，请将旧版密钥保留在密钥保管库或托管 HSM 中，以便可以还原较旧的数据库备份。 更改数据库的 TDE 保护器后，数据库的旧备份不会更新为使用最新的 TDE 保护器。 在还原时，每个备份需要包含创建该备份时用于加密该备份的 TDE 保护器。 可以遵照使用 PowerShell 轮换透明数据加密保护器中的说明执行密钥轮换。

• 即使在切换到服务管理的密钥后，仍将以前使用的所有密钥保留在 Azure Key Vault 或 Azure 托管 HSM 中。 它可确保使用存储在 Azure Key Vault 或 Azure 托管 HSM 中的 TDE 保护程序还原数据库备份。 使用 Azure Key Vault 或 Azure 托管 HSM 创建的 TDE 保护程序必须保持，直到使用服务管理的密钥创建所有剩余的存储备份。 使用 Backup-AzKeyVaultKey 创建这些密钥的可恢复备份副本。

• 若要在出现安全事件期间删除可能已泄露的密钥并避免数据丢失的风险，请遵循删除可能已泄露的密钥中所述的步骤。

轮换 TDE 保护器

为服务器轮换 TDE 保护器意味着切换到用于保护服务器上数据库的新非对称密钥。 密钥轮换是一种联机操作，应该只需数秒即可完成， 因为此操作只在解密数据库的加密密钥后重新将其加密，而不是对整个数据库进行操作。

TDE 保护程序轮换可以手动完成，也可以使用自动轮换功能完成。

为服务器配置 TDE 保护程序时，可以启用 TDE 保护程序的自动轮换功能。 默认情况下，自动轮换处于禁用状态。 启用后，服务器将持续检查密钥保管库或托管 HSM，以检测用作 TDE 保护器的密钥的任何新版本。 如果检测到新版密钥，服务器或数据库上的 TDE 保护程序将在24 小时内自动轮换到最新密钥版本。

与 Azure Key Vault 中的自动密钥轮换或 Azure 托管 HSM 中的自动轮换一起使用时，此功能支持在 Azure SQL 数据库和 Azure SQL 托管实例上实现 TDE 保护程序的端到端零接触轮换。

配置 TDE 保护程序的自动轮换时的异地复制注意事项

为避免在建立异地复制时或在异地复制期间出现问题，在主服务器或辅助服务器上启用 TDE 保护程序的自动轮换时，请务必在配置异地复制时遵循以下规则：

• 主服务器和辅助服务器都必须具有对主服务器密钥保管库（保留主服务器的 TDE 保护程序密钥的密钥库）的 Get、wrapKey 和 unwrapKey 权限。

• 对于已启用自动密钥轮换的服务器，在启动异地复制前，请将用作主服务器上的 TDE 保护程序的加密密钥添加到辅助服务器。 辅助服务器需要访问同一密钥保管库中的密钥或与主服务器一起使用的托管 HSM（而不是具有相同密钥材料的另一个密钥）。 或者，在启动异地复制之前，请确保辅助 服务器的托管标识 （用户分配或系统分配）对主服务器的密钥保管库或托管 HSM 具有所需的权限，并且系统将尝试将密钥添加到辅助服务器。

• 对于现有异地复制设置，在主服务器上启用自动密钥轮换前，请将用作主服务器上的 TDE 保护程序的加密密钥添加到辅助服务器上。 辅助服务器需要访问同一密钥保管库中的密钥或与主服务器一起使用的托管 HSM（而不是具有相同密钥材料的另一个密钥）。 或者，在启用自动密钥前，请确保辅助服务器的托管标识（用户分配或系统分配）具有对主服务器的密钥保管库的所需权限，且系统会尝试将密钥添加到辅助服务器。

• 支持使用 TDE 的客户管理的密钥 (CMK) 的异地复制方案。 如果要在 Azure 门户中配置 TDE，则必须在所有服务器上配置具有自动密钥轮换功能的 TDE。 有关使用 TDE 为异地复制配置设置自动密钥轮换的详细信息，请参阅异地复制配置的自动密钥轮换。

不可访问的 TDE 保护器

如果将 TDE 配置为使用客户管理的密钥，必须持续访问 TDE 保护程序才能使数据库保持在线状态。 如果服务器无法访问 Azure Key Vault 或 Azure 托管 HSM 中的客户管理的 TDE 保护程序，则数据库最多 10 分钟就会开始拒绝所有具有相应错误消息的连接，并将其状态更改为 不可访问。 对于处于“不可访问”状态的数据库，唯一允许的操作是将其删除。

不可访问状态

如果数据库由于间歇性网络中断（例如 5XX 错误）而无法访问数据库，则无需执行任何作，因为数据库将自动恢复联机。 为了减少访问 Azure Key Vault 或 Azure 托管 HSM 中的 TDE 保护程序时网络错误或中断的影响，服务尝试将数据库移动到不可访问状态之前，引入了 24 小时缓冲区。 如果在达到不可访问状态之前发生故障转移，数据库会因加密缓存丢失而变为不可用。

如果服务器由于任何 Azure Key Vault 错误 （例如 4XX 错误）而无法访问 Azure Key Vault 或 Azure 托管 HSM 中的客户管理的 TDE 保护程序，数据库将在 30 分钟后移动到不可访问的状态。

在 Azure Key Vault 或 Azure 管理的 HSM 出现错误后恢复数据库访问权限

还原对密钥的访问权限后，使数据库重新联机需要额外的时间和步骤，这可能会因密钥不可用的持续时间和数据库中数据的大小而异。

如果在 30 分钟内还原密钥访问，则数据库将在随后的一小时内自动修复。 但是，如果在 30 分钟以上后还原密钥访问，则无法自动修复数据库。 在这种情况下，还原数据库需要通过 Azure 门户执行额外的过程，并且可能会很耗时，具体取决于数据库的大小。

数据库重新联机后，以前配置的服务器级设置（包括故障转移组配置、标记和数据库级设置（如弹性池配置、读取缩放、自动暂停、时间点还原历史记录、长期保留策略等）将丢失。 因此，建议客户实施通知系统，以检测 30 分钟内加密密钥访问丢失的情况。 30 分钟窗口过期后，建议验证恢复的数据库上的所有服务器和数据库级别设置。

下面介绍在门户上使不可访问的数据库重新联机所需的其他步骤。

意外的 TDE 保护器访问权限吊销

可能会发生这样的情况：对密钥保管库或托管 HSM 具有足够访问权限的人员通过下列方式意外禁用了服务器对密钥的访问：

• 从服务器撤消密钥保管库或托管 HSM 的 get、wrapKey、unwrapKey 权限

• 删除密钥

• 删除密钥保管库或托管 HSM

• 更改密钥保管库或托管 HSM 防火墙规则

• 删除 Microsoft Entra ID 中服务器的托管标识

详细了解数据库不可访问的常见原因。

SQL 托管实例与 Azure Key Vault 或 Azure 托管 HSM 之间的连接被阻止

SQL 托管实例与密钥保管库或托管 HSM 之间的网络连接块主要发生在密钥保管库或托管 HSM 资源存在但无法从托管实例访问其终结点时发生。 可以访问密钥保管库或托管 HSM 终结点但连接被拒绝、缺少权限等的所有方案都会导致数据库将其状态更改为 不可访问。

与 Azure Key Vault 或 Azure 托管 HSM 的网络连接不足的最常见原因是：

• Azure Key Vault 或 Azure 托管 HSM 通过专用终结点公开，并且与托管实例子网关联的网络安全组 (NSG) 的出站规则中不允许使用 Azure Key Vault 或 Azure 托管 HSM 服务的专用 IP 地址。
• DNS 解析错误，例如密钥保管库或托管 HSM FQDN 未解析或解析为无效 IP 地址时。

测试从 SQL 托管实例到托管 TDE 保护程序的 Azure Key Vault 或 Azure 托管 HSM 的连接。

• 终结点是保管库 FQDN，类似于 <vault_name>.vault.azure.net（不带 https://）。
• 测试的端口是 443。
• RemoteAddress 的结果须存在且为正确的 IP 地址
• TCP 测试的结果应为 TcpTestSucceeded: True。

如果测试返回 TcpTestSucceeded: False，则查看网络配置：

• 检查已解析的 IP 地址，确认其有效。 缺少值意味着 DNS 解析存在问题。
  • 确认托管实例上的网络安全组具有涵盖端口 443 上已解析 IP 地址的出站规则，尤其是当解析的地址属于密钥保管库或托管 HSM 的专用终结点时。
  • 检查其他网络配置，如路由表，是否存在虚拟设备及其配置等。

监视客户管理的 TDE

若要监视数据库的状态并针对 TDE 保护器访问权限的丢失启用警报，请配置以下 Azure 功能：

• Azure 资源运行状况。 首次与失去 TDE 保护器访问权限的不可访问的数据库建立连接遭到拒绝后，该数据库将显示为“不可用”。
• 活动日志。访问客户管理的密钥保管库中的 TDE 保护器失败时，会将相应的条目添加到活动日志。 为这些事件创建警报可使你尽快恢复访问权限。
• 可根据你的偏好（例如电子邮件/短信/推送/语音、逻辑应用、Webhook、ITSM 或自动化 Runbook）来定义操作组，以发送通知和警报。

启用客户管理的 TDE 的数据库 backup 和 restore

使用来自 Azure Key Vault 或 Azure 托管 HSM 的密钥通过 TDE 加密数据库后，任何新生成的备份也会使用相同的 TDE 保护程序进行加密。 更改 TDE 保护器后，数据库的旧备份不会更新为使用最新的 TDE 保护器。

若要从 Azure Key Vault 或 Azure 托管 HSM 还原使用 TDE 保护程序加密的备份，请确保密钥材料可用于目标服务器。 因此，我们建议在密钥保管库或托管 HSM 中保留 TDE 保护程序的所有旧版本，以便可以还原数据库备份。

如果还原备份所需的密钥对目标服务器不再可用，则在还原尝试时将返回以下错误消息：“目标服务器 <Servername> 无权访问在 <时间戳 #1> 和 <时间戳 #2> 之间创建的所有 AKV URI。 还原所有 AKV URI 后重试操作。”

若要缓解此问题，请对目标服务器运行 Get-AzSqlServerKeyVaultKey cmdlet，或对目标托管实例运行 Get-AzSqlInstanceKeyVaultKey，以返回可用密钥的列表并标识缺少的密钥。 为了确保可以还原所有备份，请确保要还原的目标服务器有权访问全部所需的密钥。 这些密钥无需标记为 TDE 保护器。

若要详细了解 SQL 数据库的备份恢复，请参阅恢复 SQL 数据库中的数据库。 若要详细了解 Azure Synapse Analytics 中专用 SQL 池的备份恢复，请参阅恢复专用 SQL 池。 有关使用 SQL 托管实例进行 SQL Server 本机备份/还原，请参阅快速入门：将数据库还原到 SQL 托管实例。

日志文件的另一个注意事项：备份的日志文件仍会使用原始 TDE 保护器保持加密，即使 TDE 保护器已轮换，并且数据库正在使用新的 TDE 保护器。 还原时，需要使用这两个密钥来还原数据库。 如果日志文件使用的是存储在 Azure Key Vault 或 Azure 托管 HSM 中的 TDE 保护程序，则在还原时需要此密钥，即使数据库在此期间已更改为使用服务管理的 TDE。

使用客户管理的 TDE 实现高可用性

借助 Azure Key Vault 或 Azure 托管 HSM 提供多层冗余，使用客户托管密钥的 TDE 可以利用 Azure Key Vault 或 Azure 托管 HSM 可用性和复原能力，并完全依赖于 Azure Key Vault 或 Azure 托管 HSM 冗余解决方案。

即使单个服务组件发生故障或 Azure 区域或可用性区域出现故障，Azure Key Vault 多个冗余层也能确保密钥访问。 有关详细信息，请参阅 Azure Key Vault 可用性和冗余。

Azure Key Vault 提供以下可用性和复原能力组件，这些组件在无需用户干预的情况下自动提供：

• 数据复制
• 区域内故障转移
• 跨区域故障转移

使用 Azure 托管 HSM 多区域复制，可以将 Azure 托管 HSM 池从一个 Azure 区域（称为主要区域）扩展到另一个 Azure 区域（称为扩展区域）。 配置后，这两个区域都处于活动状态，能够处理请求，并且通过自动复制共享相同的密钥材料、角色和权限。 有关详细信息，请参阅 在 Azure 托管 HSM 上启用多区域复制。

异地灾难恢复和客户管理的 TDE

在 活动异地复制 和 故障转移组 方案中，所涉及的主服务器和辅助服务器可以链接到任何区域中的 Azure Key Vault 或 Azure 托管 HSM。 服务器和密钥保管库或托管 HSM 不必并置在同一区域中。 这样，为简单起见，主服务器和辅助服务器可以连接到同一个密钥保管库或托管 HSM（可位于任何区域）。 这有助于避免当单独的密钥保管库或托管 HSM 用于两个服务器时，密钥材料可能不同步的情况。 

Azure Key Vault 和 Azure 托管 HSM 具有多层冗余，以确保密钥和密钥保管库在发生服务或区域故障时仍可用。 非配对区域和配对区域均支持冗余。 有关详细信息，请参阅 Azure Key Vault 可用性和冗余。

根据客户的要求，有多种选项可用于存储 TDE 保护程序密钥：

• 利用 Azure 密钥保管库和原生的配对区域复原能力或非配对区域复原能力。

• 在跨多个区域的单独 Azure Key Vault 中利用客户 HSM 并在 Azure Key Vault 中加载密钥。

• 利用 Azure 托管 HSM 和跨区域复制选项。

  • 通过此选项，客户可以选择要复制密钥的所需区域。

下图展示了一种针对配对区域（主要区域和次要区域）的配置方案，该方案结合了 Azure Key Vault 的跨区域故障转移功能，以及使用故障转移组实现异地复制的 Azure SQL 设置：

适用于异地 DR 的 Azure Key Vault 备注

• Azure SQL 中的主服务器和辅助服务器都访问主要区域中的 Azure Key Vault。

• Azure Key Vault 的故障转移是由 Azure Key Vault 服务启动的，而不是由客户启动。

• 如果 Azure Key Vault 故障转移到次要区域，Azure SQL 中的服务器仍可访问相同的 Azure Key Vault。 虽然在内部，Azure Key Vault 连接会被重定向到次要区域的 Azure Key Vault。

• 只有在主要的 Azure Key Vault 可用时，才能创建新密钥、导入和执行密钥轮换。

• 发生故障转移后，在可再次访问配对区域的主要区域中的 Azure Key Vault 之前，不允许进行密钥轮换。

• 客户无法手动连接到辅助区域。

• Azure Key Vault 处于只读状态，而主要区域中的 Azure Key Vault 不可用

• 客户无法选择或检查 Azure Key Vault 当前所在的区域。

• 对于非配对区域，Azure SQL 服务器都访问第一个区域中的 Azure Key Vault（如图所示）。该 Key Vault 则使用区域冗余存储，将其数据同步复制到同一区域内多个独立的可用性区域中。

有关详细信息，请参阅 Azure Key Vault 可用性和冗余、Azure 区域对和未配对区域，以及 Azure Key Vault 的服务级别协议。

适用于异地 DR 的 Azure SQL 备注

• 使用 Azure SQL MI 和 Azure SQL DB 的区域冗余选项来提高复原能力。 有关详细信息，请参阅什么是 Azure 可用性区域？。

• 将故障转移组用于 Azure SQL MI 和 Azure SQL DB，以便实现到辅助区域的灾难恢复。 有关详细信息，请参阅故障转移组概述和最佳做法。

• 当数据库是活动异地复制或故障转移组的一部分并且 变得不可访问时，SQL 控制平面会中断链接并将数据库转换为独立数据库。 修复密钥权限后，通常可将主数据库重新联机。 辅助数据库无法联机，因为 Azure SQL 不按设计为辅助数据库进行完整备份。 建议删除辅助数据库并重新建立链接。

• 如果在 Azure SQL 中使用专用终结点，该配置可能需要更复杂的 DNS 区域（例如，它不能在同一 DNS 区域中向同一资源创建两个专用终结点）。

• 确保应用程序利用重试逻辑。

在某些情况下，客户可能会优先选择 Azure 托管 HSM 解决方案而不是 Azure Key Vault：

• 手动连接到次要保管库的要求。

• 即使发生故障，也必须能够对保管库进行读取访问。

• 灵活选择将他们的密钥材料复制到哪个区域

  • 需要启用跨区域复制，以便在第二个区域中创建第二个 Azure 托管 HSM 池。

• 使用 Azure 托管 HSM，客户可以在原始副本丢失或不可用时为 HSM 创建确切的副本。

• 使用 Azure 托管 HSM 满足安全或法规要求。

• 能够备份整个保管库，而不是备份单个密钥。

有关详细信息，请参阅对 Azure 托管 HSM 启用多区域复制和托管 HSM 灾难恢复。

适用于客户管理的 TDE 的 Azure Policy

Azure Policy 可用于在创建或更新 Azure SQL 数据库服务器或 Azure SQL 托管实例时强制实现客户管理的 TDE。 使用此策略时，如果不是在使用客户管理的密钥进行配置的情况下尝试在 Azure 中创建或更新逻辑服务器或托管实例，那么任何尝试都会失败。 Azure Policy 可以应用于整个 Azure 订阅，也可以仅应用于资源组。

有关 Azure Policy 的详细信息，请参阅什么是 Azure Policy 和 Azure Policy 定义结构。

Azure Policy 中客户管理的 TDE 支持以下两个内置策略：

• SQL Server 应使用客户管理的密钥进行静态数据加密
• 托管实例应使用客户管理的密钥进行静态数据加密

可以通过转到 Azure 门户并搜索“策略”服务来管理客户管理的 TDE 策略。 在“定义”下，搜索客户管理的密钥。

这些策略有三方面的影响：

• 审核 - 默认设置，将只在 Azure Policy 活动日志中捕获审核报告
• 拒绝 - 防止在未配置客户管理的密钥的情况下创建或更新逻辑服务器或托管实例
• 禁用 - 将禁用该策略，并且在未启用客户管理的密钥的情况下不会限制用户创建或更新逻辑服务器或托管实例

如果“客户管理的 TDE 的 Azure Policy”设置为“拒绝”，则 Azure SQL 逻辑服务器或托管实例创建将失败。 此失败的详细信息将记录在资源组的“活动日志”中。

相关内容

• 轮换 SQL 数据库的透明数据加密保护器
• 删除 SQL 数据库的透明数据加密 (TDE) 保护器
• 使用 PowerShell 通过自己的密钥管理 SQL 托管实例中的透明数据加密
• Microsoft Defender for SQL