在数据库级别使用客户管理的密钥进行透明数据加密 (TDE)

适用于：Azure SQL 数据库

本文介绍了在 Azure SQL 数据库的数据库级别使用客户管理的密钥进行透明数据加密 (TDE)。

概述

Azure SQL 通过透明数据加密 (TDE) 为客户提供静态加密功能。 使用客户管理的密钥 (CMK) 扩展 TDE 可实现静态数据保护，其中 TDE 保护程序（加密密钥）存储在对数据库加密密钥进行加密的 Azure Key Vault 中。 目前，带有 CMK 的 TDE 在服务器级别设置，并由与该服务器关联的所有加密数据库继承。 此新功能允许为服务器内每个数据库将 TDE 保护程序单独设置为客户管理的密钥。 任何具有有效的非空 encryptionProtector 属性的 Microsoft.Sql/servers/databases 资源都使用数据库级别客户管理的密钥进行配置。

在此方案中，存储在客户拥有的和客户管理的 Azure Key Vault (AKV) 中的非对称密钥可单独在服务器中的每个数据库中使用，用于加密称为 TDE 保护程序的数据库加密密钥 (DEK)。 可以选择为每个数据库添加密钥、删除密钥以及更改用户分配的托管标识 (UMI)。 有关标识的详细信息，请参阅 Azure 中的托管标识类型。

以下功能可用：

• 用户分配的托管标识：可以将单个用户分配的托管标识分配给数据库。 此标识可用于访问 Azure Key Vault 和管理加密密钥。
• 加密密钥管理：可以允许在数据库级别添加一个或多个加密密钥，并将其中一个添加的密钥设置为 TDE 保护程序。 要添加的加密密钥使用已分配给数据库的用户分配的托管标识来访问 Azure Key Vault。
• 联合客户端标识：还可以利用 Azure SQL 数据库上设置的联合客户端标识，在不同的 Azure Active Directory (Azure AD) 租户中启用来自 Azure Key Vault 的客户管理的密钥 (CMK)，以便在数据库级别将其设置为 TDE 保护程序。 这样，你就可以使用存储在不同租户的 Azure Key Vault 中的密钥来管理 TDE。

客户管理的 TDE 在数据库级别的好处

随着越来越多的服务提供商（也称为独立软件供应商 [ISV]）使用 Azure SQL 数据库来构建他们的服务，许多服务提供商正在转向使用弹性池作为跨多个数据库高效分配计算资源的一种方式。 通过将其每位客户的数据库放在一个共享的弹性池中，ISV 可以利用该池的功能来优化资源利用率，同时仍可确保每个数据库都拥有足够的资源。

但此方法存在明显的局限性。 如果多个数据库托管在同一 Azure SQL 逻辑服务器上，则它们共享服务器级别 TDE 保护程序。 ISV 无法为其客户提供真正的客户管理的密钥 (CMK) 功能。 如果客户无法管理自己的加密密钥，则他们可能会犹豫是否将敏感数据委托给 ISV 的服务，尤其是在合规性法规要求他们保持对其加密密钥的完全控制的情况下。

借助数据库级别的 TDE CMK，ISV 可以为其客户提供 CMK 功能并实现安全隔离，因为每个数据库的 TDE 保护程序可能由其拥有的密钥保管库中的相应 ISV 客户拥有。 为 ISV 的客户实现的安全隔离体现在密钥和用于访问密钥的标识这两方面。

下图总结了上述新功能。 它提供了两个独立的 Microsoft Entra 租户。 Best Services 租户，它包含具有两个数据库（DB 1 和 DB 2）的 Azure SQL 逻辑服务器，以及具有使用 UMI 1 访问数据库 DB 1 的 Key 1 的 Azure Key Vault 1。 UMI 1 和 Key 1 都代表服务器级别设置。 默认情况下，最初在此服务器上创建的所有数据库都将继承此设置，以便使用 CMK 进行 TDE。 Contoso 租户表示客户端租户，其中包含具有 Key 2 的 Azure Key Vault 2，该密钥用于作为数据库级别 CMK 跨租户支持的一部分，使用此数据库的 Key 2 和 UMI 2 设置跨租户评估数据库 DB 2。

有关跨租户标识配置的详细信息，请参阅服务器级别文档使用透明数据加密的跨租户客户管理的密钥。

受支持的密钥管理方案

对于下一部分，我们假设有一个服务器包含三个数据库（例如 Database1、Database2 和 Database3）。

现有方案

Key1 在逻辑服务器级别配置为客户管理的密钥。 此服务器下的所有数据库都继承相同的密钥。

• 服务器 - Key1 设置为 CMK
• Database1 - Key1 用作 CMK
• Database2 - Key1 用作 CMK
• Database3 - Key1 用作 CMK

受支持的新方案：使用客户管理的密钥配置的逻辑服务器

Key1 在逻辑服务器级别配置为客户管理的密钥。 可以在数据库级别配置不同的客户管理的密钥 (Key2)。

• 服务器 - Key1 设置为 CMK
• Database1 - Key2 用作 CMK
• Database2 - Key1 用作 CMK
• Database3 - Key1 用作 CMK

受支持的新方案：使用服务管理的密钥配置的逻辑服务器

为逻辑服务器配置了用于 TDE 的服务管理的密钥 (SMK)。 可以在数据库级别配置不同的客户管理的密钥 (Key2)。

• 服务器 - 服务管理的密钥设置为 TDE 保护程序
• Database1 - Key2 设置为 CMK
• Database2 - 服务管理的密钥设置为 TDE 保护程序
• Database3 - 服务管理的密钥设置为 TDE 保护程序

还原到服务器级别加密

Database1 配置了用于 TDE 的数据库级别客户管理的密钥，而逻辑服务器配置了服务管理的密钥。 Database1 可以还原到使用逻辑服务器级别服务管理的密钥。

Key Vault 和托管标识的要求

配置 Azure Key Vault (AKV) 密钥和托管标识的要求相同，包括授予适用于服务器级别客户管理的密钥 (CMK) 功能和数据库级别 CMK 的标识的密钥设置和权限。 有关详细信息，请参阅使用 CMK 进行透明数据加密 (TDE) 和使用 CMK 的托管标识。

密钥管理

轮换数据库的 TDE 保护程序意味着切换到保护数据库的新非对称密钥。 密钥轮换是一种联机操作，应该只需数秒即可完成， 因为此操作只在解密数据库的加密密钥后重新将其加密，而不是对整个数据库进行操作。 将有效的用户分配的托管标识分配给数据库后，则在数据库级别轮换密钥是一项数据库 CRUD 操作，它涉及更新数据库的加密保护程序属性。 Set-AzSqlDatabase 和 -EncryptionProtector 属性可用于轮换密钥。 要创建使用数据库级别 CMK 配置的新数据库，可以将 New-AzSqlDatabase 与 -EncryptionProtector、-AssignIdentity 以及 -UserAssignedIdentityId 参数结合使用。

可以使用类似的请求并修改数据库资源的密钥属性，来添加新密钥并从数据库中删除现有密钥。 可使用带有 -KeyList 和 -KeysToRemove 参数的 Set-AzSqlDatabase 执行这些操作。 要检索加密保护程序、标识和密钥设置，可以使用 Get-AzSqlDatabase。 默认情况下，Azure 资源管理器资源 Microsoft.Sql/servers/databases 仅显示在数据库上配置的 TDE 保护程序和托管标识。 要展开完整的密钥列表，需要 -ExpandKeyList 等其他参数。 此外，-KeysFilter "current" 和时间点值（例如 2023-01-01）可用于检索当前使用的密钥和过去在特定时间点使用的密钥。

自动密钥轮换

自动密钥轮换在数据库级别可用，可与 Azure Key Vault 密钥一起使用。 检测到新版本的密钥时，将触发轮换，并在 24 小时内自动轮换。 有关如何使用 Azure 门户、PowerShell 或 Azure CLI 配置自动密钥轮换的信息，请参阅数据库级别的自动密钥轮换。

密钥管理的权限

根据密钥保管库（访问策略或 Azure RBAC）的权限模型，可以通过在密钥保管库上创建访问策略或创建新的 Azure RBAC 角色分配来授予密钥保管库访问权限。

访问策略权限模型

要使数据库能够使用 AKV 中存储的 TDE 保护程序来加密 DEK，密钥保管库管理员需要使用其唯一的 Microsoft Entra 标识向数据库用户分配的托管标识授予以下访问权限：

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

Azure RBAC 权限模型

为了使数据库使用 AKV 中存储的 TDE 保护程序进行 DEK 加密，必须使用其唯一的 Microsoft Entra 标识为数据库用户分配的托管标识添加一个新的 Azure RBAC 角色分配，该角色为密钥保管库加密服务加密用户。

跨租户客户管理的密钥

具有透明数据加密的跨租户客户管理密钥介绍了如何为服务器级别 CMK 设置联合客户端 ID。 需要对数据库级别 CMK 进行类似的设置，并且必须将联合客户端 ID 作为 Set-AzSqlDatabase 或 New-AzSqlDatabase API 请求的一部分添加。

如果逻辑服务器是通过服务管理的密钥配置的，则可以使用 Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert 将通过数据库级别 CMK 配置的数据库还原到服务器级别加密。

如果如使用 CMK 进行透明数据加密 (TDE) 中所述无法访问 TDE 保护程序，则在更正密钥访问权限后，就可以使用 Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation 使数据库可访问。

其他注意事项

• 如果已在服务器级别启用使用 CMK 进行 TDE，则为特定数据库设置 CMK 会替代服务器级别的 CMK 设置（数据库的 DEK 使用数据库级别的 TDE 保护程序重新加密）。
• 任何逻辑服务器级别的密钥更改或轮换都不会影响数据库级别的 CMK 设置，并且数据库会继续使用自己的 CMK 设置。
• Transact-SQL (T-SQL) 不支持数据库级别 CMK。
• 可以在数据库级别使用逻辑服务器用户分配的托管标识 (UMI)。 但是，建议为数据库级别 CMK 使用指定的 UMI。
• 服务器级别跨租户 CMK 设置不会影响使用数据库级别 CMK 配置的单个数据库，它们会继续使用自己的单租户或跨租户配置。
• 只能在数据库级别设置单个用户分配的托管标识。

将现有数据库迁移到数据库级别 CMK

在创建过程中，可以使用数据库级别 CMK 配置新数据库，并且可以使用使用数据库级别客户管理的密钥进行 TDE 标识和密钥管理中描述的操作将服务器中通过服务管理的密钥配置的现有数据库迁移到数据库级别 CMK。 要迁移使用服务器级别 CMK 配置的或异地复制的数据库，需要执行以下部分中所述的其他步骤。

使用服务器级别 CMK 配置的数据无需进行异地复制

1. 使用数据库的 sys.dm_db_log_info (Transact-SQL) - SQL Server 并查找处于活动状态的虚拟日志文件 (VLF)。
2. 对于所有活动的 VLF，记录 sys.dm_db_log_info 结果中的 vlf_encryptor_thumbprint。
3. 使用数据库的 sys.dm_database_encryption_keys (Transact-SQL) - SQL Server 视图来检查 encryptor_thumbprint。 记录 encryptor_thumbprint。
4. 使用 Get-AzSqlServerKeyVaultKey cmdlet 获取在逻辑服务器上配置的所有服务器级别密钥。 从上述结果中选择具有与列表匹配的相同指纹的结果。
5. 对要迁移的数据库以及标识和加密保护程序进行更新数据库 API 调用。 使用 Set-AzSqlDatabase 以及 -UserAssignedIdentityId、-AssignIdentity、-KeyList 和 -EncryptionProtector 参数（如有必要，还包括 -FederatedClientId）将上述密钥作为数据库级别密钥传递。

使用服务器级别 CMK 配置的数据库需要进行异地复制

1. 按照上一部分中提到的步骤 (1) 到 (4) 检索迁移所需的密钥列表。
2. 使用 Set-AzSqlDatabase 和 -KeyList 参数对要迁移的主数据库和辅助数据库以及标识和作为数据库级别密钥的上述密钥进行更新数据库 API 调用。 暂时不要设置加密保护程序。
3. 必须先将要用作数据库上的主要保护程序的数据库级别密钥添加到辅助数据库。 将 Set-AzSqlDatabase 与 -KeyList 结合使用，以将此密钥添加到辅助数据库。
4. 将加密保护程序密钥添加到辅助数据库后，请使用 Set-AzSqlDatabase 通过 -EncryptionProtector 参数将其设置为主数据库上的加密保护程序。
5. 按照 (4) 中所述，将密钥设置为辅助数据库上的加密保护程序，以完成迁移。

异地复制和高可用性

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

要为已使用数据库级别 CMK 配置的数据库建立活动异地复制，必须使用有效的用户分配的托管标识和主数据库当前使用的密钥列表创建次要副本。 可使用必要的筛选器和查询参数或使用 PowerShell 和 Azure CLI 从主数据库中检索当前密钥列表。 设置此类数据库的异地副本所需的步骤包括：

1. 使用 Get-AzSqlDatabase 命令以及 -ExpandKeyList 和 -KeysFilter "current" 参数预填充主数据库使用的密钥列表。 如果要检索所有密钥，请排除 -KeysFilter。
2. 选择用户分配的托管标识（如果配置跨租户访问，还包括联合客户端 ID）。
3. 使用 New-AzSqlDatabaseSecondary 创建一个新数据库作为辅助数据库，并使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector 参数（如有必要，还包括 -FederatedClientId）在 API 调用中提供从源数据库和上述标识（如果配置跨租户访问，还包括联合客户端 ID）获取的预填充密钥列表。
4. 使用上一步中具有相同参数的 New-AzSqlDatabaseCopy 创建数据库的副本。

有关详细信息，使用数据库级别客户管理的密钥为透明数据加密配置异地复制和备份还原介绍了如何使用 REST API、PowerShell 和 Azure CLI 设置异地复制和故障转移组。

在数据库级别结合使用 TDE 和客户管理的密钥来备份和还原数据库

使用 Azure Key Vault 中的密钥通过 TDE 加密数据库后，也会使用相同的 TDE 保护程序加密所有新生成的备份。 更改 TDE 保护程序后，数据库的旧备份不会更新为使用最新的 TDE 保护程序。 要从在数据库级别配置的 Azure Key Vault 还原使用 TDE 保护程序加密的备份，请确保将密钥材料提供给目标数据库。 建议在 Key Vault 中保留所有旧版 TDE 保护程序，以便可以还原数据库备份。

时间点还原

对使用数据库级别客户管理的密钥配置的数据库进行时间点还原，需要执行以下步骤：

1. 使用 Get-AzSqlDatabase 命令以及 -ExpandKeyList 和 -KeysFilter "2023-01-01" 参数预填充主数据库使用的密钥列表。 2023-01-01 是要将数据库还原到的时间点的示例。 如果要检索所有密钥，请排除 -KeysFilter。
2. 选择用户分配的托管标识（如果配置跨租户访问，还包括联合客户端 ID）。
3. 使用具有 -FromPointInTimeBackup 参数的 Restore-AzSqlDatabase，并使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector 参数（如有必要，还包括 -FederatedClientId）在 API 调用中提供从上述步骤和上述标识（如果配置跨租户访问，还包括联合客户端 ID）获取的预填充密钥列表。

已删除的数据库还原

对使用数据库级别客户管理的密钥配置的数据库进行已删除的数据库还原，需要执行以下步骤：

1. 使用 Get-AzSqlDeletedDatabaseBackup 和 -ExpandKeyList 参数预填充主数据库使用的密钥列表。 建议传递源数据库正在使用的所有密钥，但也可以尝试使用删除时间提供的密钥作为 -KeysFilter 进行还原。
2. 选择用户分配的托管标识（如果配置跨租户访问，还包括联合客户端 ID）。
3. 使用具有 -FromDeletedDatabaseBackup 参数的 Restore-AzSqlDatabase，并使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector 参数（如有必要，还包括 -FederatedClientId）在 API 调用中提供从上述步骤和上述标识（如果配置跨租户访问，还包括联合客户端 ID）获取的预填充密钥列表。

异地还原

对使用数据库级别客户管理的密钥配置的数据库进行异地还原，需要执行以下步骤：

• 使用 Get-AzSqlDatabaseGeoBackup 和 -ExpandKeyList 预填充主数据库使用的密钥列表，以检索所有密钥。
• 选择用户分配的托管标识（如果配置跨租户访问，还包括联合客户端 ID）。
• 使用具有 -FromGeoBackup 参数的 Restore-AzSqlDatabase，并使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector 参数（如有必要，还包括 -FederatedClientId）在 API 调用中提供从上述步骤和上述标识（如果配置跨租户访问，还包括联合客户端 ID）获取的预填充密钥列表。

限制

如果数据库虚拟日志文件是使用与数据库当前主保护程序不同的旧密钥加密的，则数据库级别客户管理的密钥功能不支持密钥轮换。 在这种情况下，引发的错误为：

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse：如果活动事务保留使用旧密钥加密的日志，则将阻止数据库级别 TDE 保护程序的密钥轮换。

为了进一步了解此情况，请考虑以下时间线：

• 时间 t0 = 创建了一个未加密的数据库
• 时间 t1 = 此数据库由 Thumbprint A 保护，Thumbprint A 是数据库级别客户管理的密钥。
• 时间 t2 = 数据库保护程序轮换为新的数据库级别客户管理的密钥 Thumbprint B。
• 时间 t3 = 请求将保护程序更改为 Thumbprint C。
• 如果活动 VLF 使用 Thumbprint A，则不允许轮换。
• 如果活动 VLF 未使用 Thumbprint A，则允许轮换。

可以使用数据库的 sys.dm_db_log_info (Transact-SQL) - SQL Server 视图并查找处于活动状态的虚拟日志文件。 应会看到使用第一个密钥（例如 Thumbprint A）加密的活动 VLF。 通过数据插入生成足够的日志后，就会刷新此旧 VLF，你应该能够执行另一个密钥轮换。

如果你认为某些故障使日志停留的时间比预期要长，请参阅以下文档以进行进一步的故障排除：

• 通过 sys.dm_db_log_stats (Transact-SQL) 获取可能的 log_truncation_holdup_reason 值。
• 排查事务日志已满错误 9002 的问题。

后续步骤

查看以下有关各种数据库级别 CMK 操作的文档：

• 使用数据库级别客户管理的密钥进行 TDE 标识和密钥管理

• 使用数据库级别客户管理的密钥为透明数据加密配置异地复制和备份还原