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

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

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

在此方案中，用于加密数据库加密密钥 (DEK) 的密钥（称作 TDE 保护器）是客户管理的非对称密钥，该密钥存储在客户自有的且由其管理的 Azure Key Vault (AKV)（一个基于云的外部密钥管理系统）中。 Key Vault 是用于存储 RSA 加密密钥的高度可用且可缩放的安全存储。 它不允许直接访问存储的密钥，但会向已获授权的实体提供使用该密钥进行加密/解密的服务。 密钥可以由密钥库生成，也可以导入。

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

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

客户管理的 TDE 的优势

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

• 全面精细控制 TDE 保护器的使用和管理；

• TDE 保护器的使用透明性；

• 可以在组织中密钥和数据的管理方面实现职责分离；

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

• 集中管理 AKV 中的密钥；

• 获得最终客户的更大信任，因为 AKV 的设计可以避免 Azure 看到或提取加密密钥；

客户管理的 TDE 的工作原理

要使 Azure 中的逻辑服务器使用 AKV 中存储的 TDE 保护程序对 DEK 进行加密，密钥保管库管理员需要使用其唯一的 Microsoft Entra 标识向服务器授予访问权限。 可通过两种访问模式向服务器授予对密钥保管库的访问权限：

• Azure 基于角色的访问控制 (RBAC) - 使用 Azure RBAC 向用户、组或应用程序授予对密钥保管库的访问权限。 此方法具有灵活性和粒度优势，因此建议使用。 服务器标识需要密钥库加密服务加密用户角色才能使用该密钥进行加密和解密操作。

• 保管库访问策略 - 使用密钥保管库访问策略向服务器授予对密钥保管库的访问权限。 此方法更简单、更直接，但灵活性较差。 服务器标识需要具有对密钥保管库的以下权限：

  • get - 用于检索 Key Vault 中密钥的公共部分和属性
  • wrapKey - 用于保护（加密）DEK
  • unwrapKey - 用于取消保护（解密）DEK

在密钥保管库的“访问配置”Azure 门户菜单中，可以选择“Azure 基于角色的访问控制”或“保管库访问策略”。 有关为 TDE 设置 Azure Key Vault 访问配置的分步说明，请参阅使用 Azure Key Vault设置 SQL Server TDE 可扩展密钥管理。 有关访问模式的详细信息，请参阅 Azure Key Vault 安全性。

“密钥保管库管理员”还可以启用密钥保管库审核事件的日志记录，以便以后可以审核这些事件。

将服务器配置为使用 AKV 中的 TDE 保护器后，该服务器会将每个启用了 TDE 的数据库的 DEK 发送到 Key Vault 用于加密。 Key Vault 返回已加密的 DEK，该 DEK 随后将存储在用户数据库中。

如果需要，服务器会将受保护的 DEK 发送到 Key Vault 用于解密。

如果已启用日志记录，审核员可以使用 Azure Monitor 查看 Key Vault 审核事件日志。

配置客户管理的 TDE 的要求

配置 AKV 的要求

• 必须对密钥保管库启用软删除和清除保护功能，防止因意外删除密钥（或密钥保管库）而发生数据丢失。

• 使用其 Microsoft Entra 标识向服务器或托管实例授予对密钥保管库的访问权限（get、wrapKey、unwrapKey）。 服务器标识可以是系统分配的托管标识，也可以是分配给服务器的用户分配的托管标识。 使用 Azure 门户时，创建服务器时会自动创建 Microsoft Entra 标识。 使用 PowerShell 或 Azure CLI 时，必须显式创建 Microsoft Entra 标识，并进行验证。 有关使用 PowerShell 进行配置的详细分步说明，请参阅配置支持 BYOK 的 TDE 和为 SQL 托管实例配置支持 BYOK 的 TDE。

  • 根据密钥保管库的权限模型（访问策略或 Azure RBAC），可以通过在密钥保管库上创建访问策略来授予密钥保管库访问权限，也可以使用密钥保管库加密服务加密用户创建新的 Azure RBAC 角色分配，从而授予密钥保管库访问权限。

• 将防火墙与 AKV 配合使用时，必须启用选项“允许受信任的 Microsoft 服务绕过此防火墙”。 有关详细信息，请参阅配置 Azure Key Vault 防火墙和虚拟网络。

为 AKV 启用软删除和清除保护

软删除和清除保护是 Azure Key Vault 的重要功能，它允许恢复已删除的保管库和已删除的密钥保管库对象，降低用户意外或恶意删除密钥或密钥保管库的风险。

• 软删除的资源将保留 90 天，除非客户恢复或清除这些资源。 “恢复”和“清除”操作在 Key Vault 访问策略中各自具有相关联的权限 。 新密钥保管库默认启用软删除功能，也可使用 Azure 门户、PowerShell 或 Azure CLI 来启用它。

• 可以使用 Azure CLI 或 PowerShell 开启清除保护。 启用清除保护后，在保持期结束之前，无法清除处于已删除状态的保管库或对象。 默认保持期为 90 天，但可通过 Azure 门户配置为 7 到 90 天。

• Azure SQL 要求在包含加密密钥（用作服务器或托管实例的 TDE 保护器）的密钥保管库上启用软删除和清除保护。 这有助于防止意外或恶意删除密钥保管库或密钥的情况，那样可能会导致数据库进入“不可访问”状态。

• 在现有的服务器上或在创建服务器期间配置 TDE 保护器时，Azure SQL 会验证所使用的密钥保管库是否启用了软删除和清除保护。 如果未在密钥保管库上启用软删除和清除保护，则 TDE 保护器设置会失败并出现错误。 在这种情况下，必须先在密钥保管库上启用软删除和清除保护，然后才应执行 TDE 保护器设置。

配置 TDE 保护器的要求

• TDE 保护器只能是非对称的 RSA 密钥。 支持的密钥长度为 2048 位到 3072 位。

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

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

• 若要将现有密钥导入密钥保管库，请确保以受支持的文件格式（.pfx、.byok 或 .backup）提供该密钥。

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

配置 AKV 时的建议

• 将最多 500 个“常规用途”或 200 个“业务关键”数据库关联到单个订阅中的一个 Key Vault，以确保在服务器访问 Key Vault 中的 TDE 保护器时实现高可用性。 这些数字是根据经验以及 Key Vault 服务限制中的描述得出的。 这是为了防止服务器故障转移后出现问题，因为故障转移过程对保管库触发的密钥操作数目与该服务器中的数据库数目相同。

• 在 Key Vault 中设置资源锁可以控制谁能删除此关键资源，并防止意外或未经授权的删除。 详细了解资源锁。

• 对所有加密密钥启用审核和报告：Key Vault 提供可以轻松注入到其他安全信息和事件管理工具的日志。 Operations Management Suite Log Analytics 是已集成的服务的一个示例。

• 将每个服务器链接到位于不同区域中包含相同密钥材料的两个 Key Vault，以确保已加密数据库的高可用性。 将某一密钥保管库中的密钥标记为 TDE 保护器。 如果第一个区域中发生了故障，影响了其中的密钥保管库，系统将自动切换为具有相同密钥材料的第二个区域中的密钥保管库。

配置 TDE 保护程序时的建议

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

• 如果密钥是在 Key Vault 中生成的，请在首次使用 AKV 中的密钥之前创建密钥备份。 备份只能还原到 Azure Key Vault。 详细了解 Backup-AzKeyVaultKey 命令。

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

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

• 即使是在切换到服务管理的密钥之后，也应该保留 AKV 中以前使用的所有密钥。 这可以确保能够使用 AKV 中存储的 TDE 保护器还原数据库备份。 通过 Azure Key Vault 创建的 TDE 保护器必须一直保留到使用服务托管的密钥创建所有剩余存储的备份为止。 使用 Backup-AzKeyVaultKey 创建这些密钥的可恢复备份副本。

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

轮换 TDE 保护器

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

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

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

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

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

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

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

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

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

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

不可访问的 TDE 保护器

如果将 TDE 配置为使用客户管理的密钥，必须持续访问 TDE 保护程序才能使数据库保持在线状态。 如果服务器失去了对 AKV 中客户管理的 TDE 保护程序的访问权限，则在最长 10 分钟后，数据库会开始拒绝所有连接，同时显示相应的错误消息，并将其状态更改为“不可访问”。 对于处于“不可访问”状态的数据库，唯一允许的操作是将其删除。

恢复对密钥的访问权限后，使数据库重新联机需要额外的时间和步骤，具体取决于无法访问密钥的持续时间和数据库中的数据大小：

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

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

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

• 从服务器撤消 Key Vault 的“get”“wrapKey”和“unwrapKey”权限

• 删除密钥

• 删除 Key Vault

• 更改 Key Vault 的防火墙规则

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

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

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

在 SQL 托管实例上，尝试访问 Azure Key Vault 中的 TDE 保护程序时出现的网络错误可能不会导致数据库将其状态更改为“无法访问”，但随后会导致实例不可用。 这主要发生在密钥保管库资源存在但无法从托管实例到达其终结点时。 可以访问密钥保管库终结点但连接被拒绝、缺少权限等的所有情况都将导致数据库将其状态更改为“无法访问”。

缺少与密钥保管库网络的连接的最常见原因是：

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

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

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

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

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

监视客户管理的 TDE

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

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

使用客户管理的 TDE 进行数据库备份和还原

使用 Key Vault 中的密钥通过 TDE 加密数据库后，所有新生成的备份也会使用同一个 TDE 保护器进行加密。 更改 TDE 保护器后，数据库的旧备份不会更新为使用最新的 TDE 保护器。

若要还原使用 Key Vault 中的 TDE 保护器加密的备份，请确保密钥材料可供目标服务器使用。 因此，我们建议在 Key Vault 中保留所有旧版 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 中存储的 TDE 保护器，则还原时需要此密钥，即使数据库同时已改用服务托管的 TDE。

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

即使没有为服务器配置异地冗余，我们也强烈建议将服务器配置为使用两个不同区域中的包含相同密钥材料的两个不同 Key Vault。 不应将另一区域的辅助 Key Vault 中的密钥标记为 TDE 保护器，甚至不允许这样做。 如果发生了影响主要 Key Vault 的服务中断，只有在满足上述条件时，系统才会自动切换到辅助 Key Vault 中具有相同指纹的另一个已链接密钥（如果存在）。 请注意，如果由于撤销了访问权限或者由于删除了密钥或密钥保管库而无法访问 TDE 保护器，则不会发生这种切换，因为这可能意味着客户有意地想要限制服务器访问密钥。 通过在密钥保管库外创建密钥，并将其导入到位于不同区域的两个密钥保管库中，可以在这两个密钥保管库中提供相同的密钥材料。

另外，还可以使用位于某一区域的主要密钥保管库来生成密钥，并将密钥克隆到不同 Azure 区域的密钥保管库中来实现此目的。 使用 Backup-AzKeyVaultKey cmdlet 从主要密钥保管库检索加密格式的密钥，然后使用 Restore-AzKeyVaultKey cmdlet 并指定第二个区域中的密钥保管库来克隆密钥。 或者，使用 Azure 门户来备份和还原密钥。 仅允许在同一 Azure 订阅和 Azure 地理区域内的密钥保管库之间执行密钥备份/还原操作。

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

在活动异地复制和故障转移组方案中，相关的主服务器和辅助服务器既可以链接到同一密钥保管库（在任何区域），也可以链接到独立的密钥保管库。 如果独立的密钥保管库链接到主服务器和辅助服务器，客户负责使各个 Key Vault 中的密钥材料保持一致，使异地辅助节点保持同步，并在主要节点由于区域发生服务中断或者触发故障转移而不可访问时，辅助节点可以使用客户链接 Key Vault 中的同一密钥接管工作。 最多可以配置四个辅助节点，不支持链接（辅助节点的辅助节点）。

为了避免由于密钥材料不完整而在建立异地复制或者在异地复制期间出现问题，请务必在配置客户管理的 TDE 时遵循以下规则（如果主服务器和辅助服务器使用独立的密钥保管库）：

• 涉及的所有 Key Vault 必须具有相同的属性，并为相应的服务器提供相同的访问权限。

• 涉及的所有 Key Vault 必须包含相同的密钥材料。 这不仅适用于当前的 TDE 保护器，而且还适用于以前在备份文件中使用的所有 TDE 保护器。

• TDE 保护器的初始设置和轮换必须先在辅助节点上执行，然后在主要节点上执行。

若要测试故障转移，请遵循活动异地复制概述中的步骤。 应定期完成测试故障转移，以验证 SQL 数据库是否已维护对这两个密钥保管库的访问权限。

一个区域的 Azure SQL 数据库服务器和 SQL 托管实例现在可以链接到任何其他区域的密钥保管库。 服务器和密钥保管库不必位于同一区域。 这样，为简单起见，主服务器和辅助服务器可以连接到同一个密钥保管库（可位于任何区域）。 这有助于避免在两个服务器上使用单独的密钥保管库时密钥材料可能不同步的情况。 Azure Key Vault 具有多个冗余层，以确保在发生服务或区域故障的情况下，密钥和密钥保管库仍可供使用。 Azure Key Vault 可用性和冗余

适用于客户管理的 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