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

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

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

Azure SQL 中采用客户管理的密钥 (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 转移。 对密钥的直接访问受限，因此授权服务执行密码操作时不会暴露密钥材料。

对于 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)。

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

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

  • 客户管理的密钥 (CMK) - 客户管理密钥生命周期，包括密钥的创建、轮换和删除。 该密钥存储在 Azure 密钥保管库 或 Azure 托管 HSM 中，用于加密 Azure SQL 中的数据库加密密钥（DEK），Azure VM 上的 SQL Server 和本地 SQL Server。

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

客户管理的 TDE 的优势

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

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

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

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

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

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

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

重要说明

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

配置客户管理 TDE 的权限

关系图显示客户管理的 TDE 的设置和运行。

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

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

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

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

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

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

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

将服务器配置为使用 Azure 密钥保管库 中的 TDE 保护程序时，服务器会将每个已启用 TDE 的数据库的 DEK 发送到密钥保管库进行加密。 Key Vault 返回已加密的 DEK，该 DEK 随后将存储在用户数据库中。

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

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

注意

对于密钥保管库，任何权限更改可能需要大约 10 分钟才能生效。 这包括撤销对 AKV 中的 TDE 保护程序的访问权限，并且此时间范围内的用户可能仍具有访问权限。

配置客户管理的 TDE 的要求

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

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

配置 TDE 保护器的关键要求

采用客户管理的密钥的透明数据加密使用外部密钥（称为 TDE 保护器），该密钥存储在 Azure 密钥保管库 或 Azure Managed HSM 中，用于保护数据库加密密钥（DEK）。

以下要求适用。

支持的密钥类型和大小

根据 Azure SQL 产品/服务和 TDE 配置的不同，TDE 保护器可以由存储在 Azure 密钥保管库 或 Azure 密钥保管库 Managed HSM 中的非对称密钥或对称密钥提供支持。

  • 非对称密钥（RSA 或 RSA HSM）

    • 受 Azure 密钥保管库 和 Azure 密钥保管库 托管 HSM 支持
    • 支持的密钥大小：2,048位和3,072位
    • 支持 Azure SQL 数据库、Azure SQL 托管实例 和 Azure Synapse Analytics

  • 对称密钥 （AES）

    • 支援於 Azure 密钥保管库 Premium （preview） 和 Azure 密钥保管库 Managed HSM
    • 支持的密钥大小：128位、192位和256位
    • 仅支持 Azure SQL 数据库，目前处于公开预览阶段

注意

透明数据加密 with symmetric key（AES）目前处于预览阶段。 预览功能发布时功能有限，但Microsoft以预览形式提供，方便客户抢先体验并反馈。 预览功能受单独的补充预览条款的约束，并且不受 SLA 的约束。 在某些情况下，我们会尽力提供支持。 但是，Microsoft 支持部门渴望获得你对预览功能的反馈，并可能在某些情况下提供尽力支持。 预览功能可能有限或受限，并且可能仅在所选地理区域中可用。

对称密钥（AES）密钥的管理行为

你可以使用存储在 Azure 密钥保管库 Premium（预览版）或 Azure 密钥保管库 Managed HSM 中的对称（AES）密钥作为 TDE 保护器。 要开始使用本地硬件安全模块（HSM）中的密钥，将密钥导入任一服务。 初始导入后，所有持续的密钥生命周期操作都在 Azure 密钥保管库 Premium（预览版）或 Azure 密钥保管库 Managed HSM 中进行。 点点恢复、地理灾难恢复和密钥重新验证都依赖于剩余可用的密钥。 维护导入密钥的本地备份，以支持恢复和重新验证场景。 这种行为仅适用于对称（AES）密钥，不适用于非对称（RSA）密钥。

密钥状态和有效性要求

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

密钥导入要求

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

  • .pfx
  • .byok
  • .backup

若要将受 HSM 保护的密钥导入 Azure 托管 HSM，请参阅将受 HSM 保护的密钥导入托管 HSM（BYOK）。

注意

v2.8.0 之前的 Thales CipherTrust Manager 版本出现问题，可防止新导入到 Azure 密钥保管库 的密钥与 Azure SQL 数据库或 Azure SQL 托管实例一起使用，以用于客户管理的 TDE 方案。 有关此问题的更多详细信息，请参阅 CipherTrust Cloud Key Manager 发行说明。 在这种情况下，在将密钥导入 Azure 密钥保管库 后等待 24 小时，开始将其用作服务器或托管实例的 TDE 保护程序。 此问题已在 Thales CipherTrust Manager v2.8.0 中解决。

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

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

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

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

    • 对 Azure SQL 资源使用 专用的 Azure 密钥保管库 。

    • 将不超过 500 个常规用途数据库与单个 Azure 密钥保管库 相关联。

    • 将不超过 200 个业务关键数据库与单个 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 密钥保管库 警报。

  • 为了配合长期密码学弹性规划，考虑使用 AES-256 对称密钥作为 TDE 保护器。

    大规模量子计算预计将破解如RSA等公钥密码算法。 对称密码学，包括AES，在足够大的密钥大小下被认为是量子弹性的。

    Microsoft更广泛的量子安全战略强调加密敏捷性。 在支持这些算法的地方采用更强的对称算法，并规划未来随着指导和标准演变的密码学转型。

    重要说明

    目前，只有 Azure SQL 数据库 支持使用对称密钥 (AES) 的透明数据加密，并且目前处于公开预览阶段。

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

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

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

注意

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

有关配置 TDE 保护器的建议

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

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

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

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

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

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

小窍门

使用版本化和无版本 Azure 密钥保管库 密钥来实现 TDE

设置 TDE 保护程序时，可以使用特定密钥版本或无版本密钥标识符引用 Azure 密钥保管库 密钥。

在这两种情况下，Azure SQL 数据库始终解析并使用 Azure 密钥保管库 或 Azure 密钥保管库 托管 HSM 中已启用的密钥的最新版本。 使用无版本密钥标识符避免在 TDE 保护程序配置中嵌入特定密钥版本。

目前仅 Azure SQL 数据库支持无版本密钥标识符。

示例：

  • 包含特定版本的密钥标识符

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • 无版本密钥标识符

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

轮换 TDE 保护器

轮换 TDE 保护器可让您替换用于保护数据库加密密钥 (DEK) 的密钥。 密钥轮换是一种联机操作，应该只需数秒即可完成， 因为此操作只在解密数据库的加密密钥后重新将其加密，而不是对整个数据库进行操作。

可以通过将配置切换为使用存储在 Azure 密钥保管库 或 Azure 密钥保管库 Managed HSM 中的新密钥来轮换 TDE 保护器。 根据Azure SQL产品/服务和支持的配置，可能包括：

  • 切换到同一密钥的新密钥版本
  • 切换到其他密钥
  • 在支持的密钥类型（如非对称（RSA）和对称密钥（AES）之间进行切换

注意

目前，只有 Azure SQL 数据库 支持使用对称密钥 (AES) 的透明数据加密，并且目前处于公开预览阶段。

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

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

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

注意

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

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

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

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

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

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

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

不可访问的 TDE 保护器

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

不可访问状态

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

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

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

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

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

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

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

TDE BYOK 不可访问数据库的屏幕截图。

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

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

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

  • 删除密钥

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

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

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

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

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

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

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

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

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

测试从 SQL 托管实例到托管 TDE 保护程序的 Azure 密钥保管库 或 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 密钥保管库 或 Azure 托管 HSM 的密钥通过 TDE 加密数据库后，任何新生成的备份也会使用相同的 TDE 保护程序进行加密。 更改 TDE 保护程序后，数据库的旧备份不会更新为使用最新的 TDE 保护程序。

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

重要说明

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

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

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

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

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

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

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

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

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

注意

对于所有配对区域，Azure 密钥保管库 密钥将复制到这两个区域，并且两个区域中都有可在这些密钥上运行的硬件安全模块（HSM）。 有关详细信息，请参阅数据复制。 这适用于标准和高级 Azure 密钥保管库 服务层级，以及软件或硬件密钥。

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

使用客户管理的 TDE 进行异地灾难恢复

主动的地理复制 和 故障切换组 支持客户管理的TDE。 主服务器和次要服务器可以使用Azure 密钥保管库或Azure Managed HSM，且支持区域内均可使用。 服务器和密钥存储不一定在同一区域。

为了成功进行故障切换，两台服务器必须访问包含所需密钥的每一个 Azure 密钥保管库 或 Azure Managed HSM。

配置注意事项

在 Azure 门户中配置活动异地复制或故障转移组时，请注意以下事项：

  • TDE 保护器位置：主服务器和次服务器可以使用相同的 Azure 密钥保管库 或 Azure 托管 HSM。 使用同一个密钥存储可以降低密钥材料不同步的风险。如果你在多个区域使用不同的密钥库，必须保持所需的密钥材料同步。 有关密钥存储弹性的信息，请参见 Azure 密钥保管库 的可用性与冗余以及托管 HSM 中的多区域复制。

  • 区域冗余：在可用的情况下，Azure SQL 数据库 或 Azure SQL 托管实例 的区域冗余能在区域内提供额外的弹性。 有关详细信息，请参阅什么是 Azure 可用性区域？。

  • 密钥权限：主服务器和次服务器都必须对每个包含必要TDE保护器的Azure 密钥保管库或Azure托管HSM都拥有所需权限。

  • 密钥可用性： 确保所需密钥在主服务器和副服务器上均可获得。 服务器之间不需要使用相同的TDE保护器，但每个服务器必须拥有相同的密钥材料。 您可以通过使用 Azure 门户、PowerShell、Azure CLI 或 Azure SQL REST API 向服务器添加密钥。 如果故障切换时所需密钥不可用，数据库可能会无法访问。

  • 私有端点：如果你在 Azure SQL 中使用私有端点，配置可能需要更复杂的 DNS 区域（例如，它不能在同一 DNS 区域内为同一资源创建两个私有端点）。

  • 应用连接性： 应用应使用重试逻辑处理故障切换期间的暂态故障。

有关如何配置 Azure SQL 异地灾难恢复资源的信息，请参阅 活动异地复制 或 故障转移组概述和最佳做法。

重要说明

当你创建地理复制链路或故障转移组时，Azure SQL 会验证两台服务器都能访问所有必要的客户管理密钥。 如果任一服务器无法访问所需的密钥，创建操作就会失败。 例如，如果主服务器和次服务器分别使用密钥A和密钥B，则在创建地理复制链路或故障切换组之前，先将这两个密钥添加到两个服务器。

下图显示了在配对区域配置中，Azure SQL 通过故障转移组实现的异地复制以及 Azure 密钥保管库 的跨区域故障转移：

显示配对区域中 Azure 密钥保管库跨区域故障转移支持的示意图。

Azure 密钥保管库 在故障转移期间的行为

  • 故障转移由 Azure 密钥保管库 发起，而不是由你发起。
  • 当主要区域中的密钥保管库不可用时，密钥保管库将处于只读状态。
  • 只有在主区域的密钥库可用时，才能创建、导入和轮换密钥。 故障切换后，密钥轮换会被阻挡，直到主区域再次可访问。
  • 你无法选择或检查密钥库当前所在的区域，也无法手动连接到次要区域。

从无法访问的TDE保护器中恢复

如果处于活跃地理复制关系或故障切换组中的数据库变得不可访问，Azure SQL 控制平面会断开链接，将数据库转换为独立数据库。

恢复密钥权限后，通常可以重新启用主数据库。 你不能让二级数据库重新上线，因为Azure SQL不会对二级数据库进行完整备份。 丢弃二级数据库，然后重新建立地理复制链路或故障切换组。

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

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

重要说明

早期版本中针对客户管理的 TDE 且包含 AuditIfNotExists 效果的内置策略现已弃用。 使用已弃用策略的现有策略分配不会受到影响，并继续像以前一样工作。

相关内容

  • Last updated on