Azure Synapse Analytics 的客户管理型 TDE

适用于：Azure Synapse Analytics 专用 SQL 池（以前称为 SQL DW）

Tip

Microsoft Fabric Data Warehouse是数据湖基础上的企业规模关系仓库，具有未来就绪的体系结构、内置 AI 和新功能。 如果不熟悉数据仓库，请从Fabric Data Warehouse开始。 现有的指定 SQL 池工作负荷可以升级到 Fabric，以跨数据科学、实时分析和报告访问新功能。

• 启动Fabric免费试用版。
• 织物数据仓库迁移助手。

采用客户管理的密钥 (CMK) 的透明数据加密 (TDE) 支持使用自带密钥 (BYOK) 方案来实现静态数据保护，并使组织能够在密钥和数据管理方面实现职责分离。 通过使用客户管理的 TDE，您将负责密钥生命周期管理（密钥创建、上传、轮换、删除）、密钥使用权限以及对密钥操作的审核，并对这些方面拥有完全控制权。

在这种情况下，透明数据加密（TDE）保护器是一个由客户管理的密钥，用于保护数据库加密密钥（DEK）。 你可以将TDE保护器存储在Azure 密钥保管库或Azure 密钥保管库 Managed HSM中，这两者是基于云的安全密钥管理服务，设计为高可用性和可扩展性。 两项服务都支持由FIPS 140-2验证硬件保护的加密密钥：Azure 密钥保管库支持FIPS 140-2二级，Azure 密钥保管库托管HSM支持FIPS 140-2三级。 这两种服务都支持非对称和对称密钥类型，支持的算法和使用方式取决于TDE部署模型。 你可以在服务中生成密钥，导入，或安全地从本地的 HSM 转移。 对密钥的直接访问受限，因此授权服务执行密码操作时不会暴露密钥材料。

注意

本文介绍了独立的专用SQL池（前称SQL DW）。

• 对于 Azure Synapse Analytics 专用的 SQL 池（前称 SQL DW），在服务器层设置 TDE 保护器。 所有与该服务器关联的加密数据库都会继承TDE保护器。
• 在 Synapse 工作区中，使用在工作区级别配置的客户管理密钥对专用 SQL 池和无服务器 SQL 池中的数据进行加密。 有关 Synapse 工作区中专用 SQL 池的透明数据加密的详细信息，请参阅 Azure Synapse Analytics 加密。

客户管理密钥 （CMK） 和自带密钥 （BYOK）

在本文中，客户管理的密钥 (CMK) 和创建自己的密钥 (BYOK) 术语可互换使用，但它们表示一些差异。

• 客户管理密钥（CMK） ——您管理密钥生命周期，包括密钥的创建、轮换和删除。 将密钥存储在 Azure 密钥保管库 或 Azure Managed HSM 中，并用它来加密数据库加密密钥（DEK）。

• 自带密钥（BYOK）——您可以安全地将您自己的密钥从本地硬件安全模块（HSM）引入或导入到 Azure 密钥保管库。 此类导入的密钥可以用作 Azure 密钥保管库 中的其他任何密钥，包括用作客户管理的密钥来加密 DEK。 有关详细信息，请参阅将受 HSM 保护的密钥导入托管 HSM (BYOK)。

客户管理的 TDE 的优势

客户管理的透明数据加密 (TDE) 提供以下优势：

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

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

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

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

• 在 Azure 密钥保管库 中集中管理密钥。

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

Important

对于使用服务托管 TDE 并希望开始使用客户管理 TDE 的用户来说，数据在切换过程中保持加密状态，且不会发生停机，也无需对数据库文件重新加密。 从服务托管的密钥切换到客户管理的密钥只需重新加密 DEK，此操作非常快捷且可在线完成。

在 Azure 密钥保管库中配置客户管理的 TDE 所需的权限

选择要使用的 Azure 密钥保管库 类型。

为了让 Azure 中的 SQL 逻辑服务器使用存储在 Azure 密钥保管库 中的 TDE 保护器来加密 DEK，密钥保管库 管理员需要通过服务器独特的 Microsoft Entra 身份赋予该服务器访问权限。 服务器标识可以是系统分配的托管标识，也可以是分配给服务器的用户分配的托管标识。 可通过两种访问模式向服务器授予对密钥保管库的访问权限：

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

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

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

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

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

当你配置服务器使用Azure 密钥保管库中的TDE保护器时，服务器会将每个启用TDE数据库的DEK发送到密钥库进行加密。 密钥库返回加密后的DEK，服务器将其存储在用户数据库中。

需要时，服务器会将受保护的DEK发送到密钥库进行解密。

如果启用了日志记录，审计人员可以使用 Azure Monitor 来查看 Key Vault AuditEvent 日志。

注意

密钥库的权限更改可能要10分钟左右才会生效。 这段时间包括在 AKV 中撤销对 TDE 保护程序的访问权限，而用户可能仍然拥有访问权限。

在 Azure 密钥保管库 中配置客户管理的 TDE 的要求

• 启用 Azure 密钥保管库 上的软删除和清除保护功能。 此配置有助于防止意外或恶意删除密钥保管库或密钥的情况，那样可能会导致数据库进入不可访问状态。 在现有的服务器上或在创建服务器期间配置 TDE 保护程序时，Azure SQL 会验证所使用的密钥保管库是否开启了软删除和清除保护。 如果未在密钥保管库上启用软删除和清除保护，则 TDE 保护器设置会失败并出现错误。 此时，启用密钥库的软删除和清除保护，然后执行TDE保护器的设置。

• 将防火墙与 Azure 密钥保管库 配合使用时，必须启用“ 允许受信任的Microsoft服务绕过防火墙”选项，除非对 Azure 密钥保管库 使用专用终结点。 有关详细信息，请参阅 配置 Azure 密钥保管库 防火墙和虚拟网络。

配置 TDE 保护器的关键要求

使用客户管理的密钥的透明数据加密通过存储在 Azure 密钥保管库 中的外部密钥（称为 TDE 保护程序）来保护数据库加密密钥 (DEK)。

以下要求适用。

支持的密钥类型和大小

TDE 保护程序可以由存储在 Azure 密钥保管库 中的非对称密钥提供支持。 支持的密钥大小为2048位和3072位。

密钥状态和有效性要求

• 如果你指定了密钥激活日期，请将其设置为过去的日期和时间。
• 如果你指定了密钥的到期日，请将其设置为未来的日期和时间。
• 密钥必须处于“已启用”状态。

密钥导入要求

如果您将现有密钥导入 Azure 密钥保管库，请以以下支持格式之一提供该密钥：

• .pfx
• .byok
• .backup

有关在 Azure 密钥保管库 中配置客户管理的 TDE 的建议

若要保持高可用性并避免流量限制问题，请遵循每个订阅的以下准则：

• 为了确保最佳性能和可靠性，使用专用的 Azure 密钥保管库 来管理 Azure SQL。 不要把这个密钥库分享给其他服务。 如果密钥库因共享使用或过度密钥操作而负载过重，可能会负面影响数据库性能，尤其是在加密密钥访问时。 Azure 密钥保管库 强制实施 流量限制。 如果超出这些限制，作可能会延迟或失败。 这种风险在服务器故障切换期间最高，故障切换会触发服务器上每个数据库的密钥操作。

  有关限速行为的更多信息，请参见 Azure 密钥保管库 限速指南。

  • 你可以关联到单个 Azure 密钥保管库 的超大规模数据库数量取决于页面服务器的数量。 每个页面服务器都链接到一个逻辑数据文件。 要查找页面服务器数量，请运行以下查询。

    -- # of page servers (primary copies) for this database
    SELECT COUNT(*) AS page_server_count
    FROM sys.database_files
    WHERE type_desc = 'ROWS';
    

    不要将超过 500 个页面服务器 与单个 Azure 密钥保管库 关联。 随着数据库的增长，页服务器数会自动增加，因此定期监视数据库大小非常重要。 如果页面服务器数量超过 500 个，每个超大规模数据库都使用专用的 Azure 密钥保管库，并且不要与其他 Azure SQL 资源共享该密钥库。

  • 监视 和配置 Azure 密钥保管库 警报。 有关监控和提醒的更多信息，请参见“监控 Azure 密钥保管库” 和“配置 Azure 密钥保管库 警报”。

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

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

• 使用 Azure 区域中的密钥保管库，该保管库可将其内容复制到已配对区域以实现最大可用性。 有关详细信息，请参阅使用 Azure 密钥保管库 的最佳做法和 Azure 密钥保管库 可用性和冗余。

有关配置 TDE 保护器的建议

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

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

• 每当你对密钥做任何更改（例如密钥属性、标签、ACL）时，就创建一个新的备份。

• 在轮换密钥时，将旧版本的密钥保存在密钥库或托管HSM中，这样你可以恢复较早的数据库备份。 当数据库的TDE保护器更换时，数据库的旧备份 不会更新 以使用最新的TDE保护器。 在还原时，每个备份需要包含创建该备份时用于加密该备份的 TDE 保护器。 要旋转密钥，请按照《 旋转透明数据加密（TDE）保护器》一文中的说明操作。

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

• 若要在安全事件期间删除可能泄露的密钥，且不会丢失数据的风险，请按照 使用 PowerShell 删除透明数据加密（TDE）保护程序一文中的步骤作。 始终轮换到新的 TDE 保护程序，并在删除或禁用已泄露密钥之前验证所有数据库是否都使用新密钥。 在不先旋转的情况下删除或禁用密钥，会导致所有加密数据库变得不可访问，且不会使之前备份并恢复到另一个保险库的密钥副本失效。

轮换 TDE 保护器

当你轮换 TDE 保护器时，你会替换保护数据库加密密钥（DEK）的密钥。 密钥轮换是在线操作，只需几秒钟。 该操作仅解密并重新加密数据库加密密钥，而非整个数据库。

可以通过将配置切换为使用存储在 Azure 密钥保管库 中的新密钥来轮换 TDE 保护器。 根据产品和支持的配置，这个密钥可以是：

• 切换到同一密钥的新密钥版本
• 切换到其他密钥

TDE保护器的旋转 可以手动完成，也可以使用自动旋转功能实现。

你可以在为服务器配置 TDE 保护器时启用TDE 保护器的自动轮换。 默认情况下，自动轮换处于禁用状态。 启用后，服务器会持续检查密钥库中用于TDE保护器的密钥是否有新版本。 如果服务器检测到密钥的新版本，它会自动在24小时内将服务器或数据库的TDE保护器切换到最新的密钥版本。

注意

当你用 CMK 手动或自动旋转键来设置 TDE 时，你总是使用系统支持的最新版本键。 该设置不允许使用以前或较低版本的密钥。 始终使用最新的密钥版本符合 Azure SQL 安全策略，该策略禁止使用可能泄露的早期密钥版本。

不可访问的 TDE 保护器

当你配置 TDE 使用客户管理的密钥时，数据库需要持续访问 TDE 保护器才能保持在线。 如果服务器失去对 Azure 密钥保管库 中客户管理的 TDE 保护器的访问权限，数据库会在 10 分钟内开始拒绝所有连接，显示错误信息，并将状态变为不可访问。 对于处于“不可访问”状态的数据库，唯一允许的操作是将其删除。

不可访问状态

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

如果服务器因任何 Azure Key Vault 错误（如 4XX 错误）而失去对客户管理的 Azure 密钥保管库 TDE 保护器的访问权限，数据库将在 30 分钟后转为不可访问状态。

Azure 密钥保管库 错误后还原数据库访问

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

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

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

以下展示了在门户上使不可访问的数据库重新联机所需的额外步骤。

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

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

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

• 删除密钥

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

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

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

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

SQL 托管实例与 Azure 密钥保管库 之间的连接被阻止

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

与 Azure 密钥保管库 网络连接不足的最常见原因是：

• Azure 密钥保管库 通过专用终结点公开，而与托管实例子网关联的网络安全组 (NSG) 的出站规则中不允许使用 Azure 密钥保管库 服务的专用 IP 地址。

• DNS 解析错误，例如密钥保管库或托管 HSM FQDN 未解析或解析为无效 IP 地址时。

测试 从 SQL 托管实例到托管 TDE 加密保护器的 Azure 密钥保管库的连接。

• 终结点是保管库 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进行数据库备份和恢复

使用 Azure 密钥保管库 中的密钥通过 TDE 加密数据库后，也会使用相同的 TDE 保护程序加密所有新生成的备份。 更改 TDE 保护程序后，数据库的旧备份不会更新为使用最新的 TDE 保护程序。

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

Important

随时不能为服务器设置多个 TDE 保护程序。 在 Azure 门户窗格中，使用 “将密钥设置为默认 TDE 保护器” 标记的密钥是 TDE 保护器。 但是，可以将多个密钥链接到服务器，而不将它们标记为 TDE 保护程序。 这些密钥不用于保护DEK，但如果备份文件用带有对应指纹的密钥加密，可以在从备份恢复时使用。

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

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

若要详细了解 Azure Synapse Analytics 中专用 SQL 池的备份恢复，请参阅恢复专用 SQL 池。

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

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

通过利用 Azure 密钥保管库 的多层冗余，使用客户管理密钥的 TDE 可以受益于 Azure 密钥保管库 的可用性和韧性。 他们完全可以依赖 Azure 密钥保管库 冗余解决方案。

Azure 密钥保管库 的多重冗余层确保即使单个服务组件失效或 Azure 区域或可用性区域宕机，也能访问密钥。 有关详细信息，请参阅 Azure 密钥保管库 可用性和冗余。

Azure 密钥保管库 无需用户干预即可自动提供以下可用性和弹性组件：

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

相关内容

• Azure Synapse Analytics 的透明数据加密
• 旋转TDE保护器
• 删除 TDE 保护器
• Azure 密钥保管库 可用性和冗余