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

适用于: Azure SQL 数据库 Azure SQL 托管实例 Azure Synapse Analytics(仅限专用 SQL 池)

采用客户管理的密钥 (CMK) 的 Azure SQL 透明数据加密 (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)

注意

本文适用于 Azure SQL 数据库、Azure SQL 托管实例和 Azure Synapse Analytics(专用 SQL 池 [以前称为 SQL DW])。 有关 Synapse 工作区内专用 SQL 池的透明数据加密的文档,请参阅 Azure Synapse Analytics 加密

注意

Microsoft Entra ID 是 Azure Active Directory (Azure AD) 的新名称。 目前我们正在更新文档。

客户管理的 TDE 的优势

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

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

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

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

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

  • 集中管理 AKV 中的密钥;

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

重要

对于当前正在使用服务托管的 TDE 并想要开始使用客户管理的 TDE 的用户,在切换过程中数据将保持加密状态,且不会造成停机,也不需要重新加密数据库文件。 从服务托管的密钥切换到客户管理的密钥只需重新加密 DEK,此操作非常快捷且可在线完成。

客户管理的 TDE 的工作原理

客户管理的 TDE 的设置和运行

要使 Azure 中的逻辑服务器使用 AKV 中存储的 TDE 保护程序对 DEK 进行加密,密钥保管库管理员需要使用其唯一的 Microsoft Entra 标识向服务器授予以下访问权限:

  • get - 用于检索 Key Vault 中密钥的公共部分和属性

  • wrapKey - 用于保护(加密)DEK

  • unwrapKey - 用于取消保护(解密)DEK

Key Vault 管理员还可以启用 Key Vault 审核事件的日志记录,以便以后可以审核这些事件。

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

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

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

注意

对密钥保管库进行的任何权限更改都可能需要 10 分钟左右的时间才能生效。 这包括撤销对 AKV 中 TDE 保护程序的访问权限,但让用户在此时间范围内仍具有访问权限。

配置客户管理的 TDE 的要求

配置 AKV 的要求

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

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

    • 根据密钥保管库的权限模型(访问策略或 Azure RBAC),可以通过在密钥保管库上创建访问策略来授予密钥保管库访问权限,也可以使用密钥保管库加密服务加密用户创建新的 Azure RBAC 角色分配,从而授予密钥保管库访问权限。
  • 将防火墙与 AKV 配合使用时,必须启用选项“允许受信任的 Microsoft 服务绕过此防火墙”。 有关详细信息,请参阅配置 Azure Key Vault 防火墙和虚拟网络

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

重要

在新的或现有的服务器或托管实例上配置客户托管的 TDE 时,必须在密钥保管库上启用软删除和清除保护。

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

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

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

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

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

配置 TDE 保护器的要求

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

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

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

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

注意

v2.8.0 之前的 Thales CipherTrust Manager 版本存在问题,导致新导入 Azure Key Vault 的密钥无法与 Azure SQL 数据库或 Azure SQL 托管实例共同用于客户管理的 TDE 方案。 在此处可以找到关于此问题的更多详细信息。 对于此类情况,请在将密钥导入密钥保管库后等待 24 小时,然后开始将其用作服务器或托管实例的 TDE 保护器。 该问题已在 Thales CipherTrust Manager v2.8.0 中得到解决。

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

配置 AKV 时的建议

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

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

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

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

注意

为了更灵活地配置客户管理的 TDE,一个区域中的 Azure SQL 数据库和 Azure SQL 托管实例现在可以链接到任何其他区域中的密钥保管库。 服务器和密钥保管库不一定位于同一区域。

配置 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 保护程序将在 60 分钟内自动轮换到最新密钥版本。

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

注意

如果使用手动或自动密钥轮换通过 CMK 设置 TDE,则可始终使用支持的密钥的最新版本。 该设置不允许使用以前或较低版本的密钥。 始终使用最新的密钥版本符合 Azure SQL 安全策略,该策略禁止使用可能泄露的早期密钥版本。 出于数据库备份或还原目的,可能需要以前的密钥版本,尤其是在必须保留早期密钥版本的长期保留备份中。 对于异地复制设置,源服务器所需的所有密钥都需要存在于目标服务器上。

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

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

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

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

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

不可访问的 TDE 保护器

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

注意

如果数据库由于间歇性网络中断而不可访问,则无需采取任何措施,数据库即可自动恢复联机状态。

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

注意

  • 如果在 30 分钟内恢复了密钥访问权限,数据库将在下一小时自动修复。
  • 如果在超过 30 分钟后恢复了密钥访问权限,数据库将无法自动修复。 若要使数据库恢复正常运行,需要在 Azure 门户上执行其他步骤,这可能需要很长时间,具体取决于数据库的大小。
  • 数据库重新联机后,将丢失以前配置的服务器级别设置,其中可能包括故障转移组配置、标记和数据库级设置(例如弹性池配置、读取缩放、自动暂停、时间点还原历史记录、长期保留策略等)。 因此,建议客户实现一个通知系统,以在 30 分钟内识别加密密钥访问丢失。 30 分钟时间过去后,建议验证恢复的数据库上的所有服务器和数据库级别设置。

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

TDE BYOK 不可访问的数据库

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

对 Key Vault 拥有足够访问权限的某人可能会意外地通过以下方式禁用服务器对密钥的访问权限:

  • 从服务器撤消 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 保护器,以便可以还原数据库备份。

重要

无论何时,为服务器设置的 TDE 保护器都不能超过一个。 它是在 Azure 门户窗格中标记为“使该密钥成为默认的 TDE 保护器”的密钥。 但是,可将其他多个密钥链接到服务器,而无需将其标记为 TDE 保护器。 这些密钥不是用于保护 DEK,而是在从备份还原期间使用(如果备份文件是使用具有相应指纹的密钥加密的)。

如果还原备份所需的密钥对目标服务器不再可用,则在还原尝试时将返回以下错误消息:“目标服务器 <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 中具有相同指纹的另一个已链接密钥(如果存在)。 请注意,如果由于撤销了访问权限或者由于删除了密钥或 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 逻辑服务器或托管实例创建将失败。 此失败的详细信息将记录在资源组的“活动日志”中。

重要

已弃用含 AuditIfNotExist 效果的客户管理的 TDE 的旧版内置策略。 使用已弃用策略的现有策略分配不受影响,并将继续正常运作。

后续步骤

建议查看以下 PowerShell 示例脚本,以了解可对客户管理的 TDE 执行的常见操作:

此外,启用 Microsoft Defender for SQL 以保护你的数据库及其数据。它包括用于发现和缓解潜在数据库漏洞以及检测可能对数据库构成威胁的异常活动的功能。