使用客户管理的密钥进行 Azure SQL 透明数据加密Azure SQL Transparent Data Encryption with customer-managed key

Azure SQL 透明数据加密 (TDE) 与客户管理的密钥共同实现了“创建自己的密钥”(BYOK) 方案,凭此可以实现静态数据保护,并使组织能够在密钥和数据管理方面实现职责分离。Azure SQL Transparent Data Encryption (TDE) with customer-managed key enables Bring Your Own Key (BYOK) scenario for data protection at rest, and allows organizations to implement separation of duties in the management of keys and data. 使用客户管理的透明数据加密时,客户需要负责并可全面控制密钥生命周期管理(密钥创建、上传、轮换、删除)、密钥使用权限,以及密钥操作的审核。With customer-managed transparent data encryption, customer is responsible for and in a full control of a key lifecycle management (key creation, upload, rotation, deletion), key usage permissions, and auditing of operations on keys.

在此方案中,用于加密数据库加密密钥 (DEK) 的密钥(称作 TDE 保护器)是客户管理的非对称密钥,该密钥存储在客户自有的且由其管理的 Azure Key Vault (AKV)(一个基于云的外部密钥管理系统)中。In this scenario, the key used for encryption of the Database Encryption Key (DEK), called TDE protector, is a customer-managed asymmetric key stored in a customer-owned and customer-managed Azure Key Vault (AKV), a cloud-based external key management system. Key Vault 是用于存储 RSA 加密密钥的高度可用且可缩放的安全存储。Key Vault is highly available and scalable secure storage for RSA cryptographic keys. 它不允许直接访问存储的密钥,但会向已获授权的实体提供使用该密钥进行加密/解密的服务。It doesn't allow direct access to a stored key, but provides services of encryption/decryption using the key to the authorized entities. 密钥可由 Key Vault 生成,并可以导入。The key can be generated by the key vault, imported.

对于 Azure SQL 数据库和 Azure SQL 数据仓库,TDE 保护器在逻辑服务器级别设置,并由该服务器关联的所有已加密数据库继承。For Azure SQL Database and Azure SQL Data Warehouse, the TDE protector is set at the logical server level and is inherited by all encrypted databases associated with that server. 对于 Azure SQL 托管实例,TDE 保护器是在实例级别设置的,并由该实例上所有加密的数据库继承。For Azure SQL Managed Instance, the TDE protector is set at the instance level and is inherited by all encrypted databases on that instance. 除非另有说明,否则术语“服务器”在整个文档中指的是 SQL 数据库逻辑服务器和托管实例。 The term server refers both to SQL Database logical server and managed instance throughout this document, unless stated differently.

Important

对于当前正在使用服务托管的 TDE 并想要开始使用客户管理的 TDE 的用户,在切换过程中数据将保持加密状态,且不会造成停机,也不需要重新加密数据库文件。For those using service-managed TDE who would like to start using customer-managed TDE, data remains encrypted during the process of switching over, and there is no downtime nor re-encryption of the database files. 从服务托管的密钥切换到客户管理的密钥只需重新加密 DEK,此操作非常快捷且可在线完成。Switching from a service-managed key to a customer-managed key only requires re-encryption of the DEK, which is a fast and online operation.

客户管理的 TDE 的优势Benefits of the customer-managed TDE

客户管理的 TDE 为客户提供以下优势:Customer-managed TDE provides the following benefits to the customer:

  • 全面精细控制 TDE 保护器的使用和管理;Full and granular control over usage and management of the TDE protector;

  • TDE 保护器的使用透明性;Transparency of the TDE protector usage;

  • 可以在组织中密钥和数据的管理方面实现职责分离;Ability to implement separation of duties in the management of keys and data within the organization;

  • Key Vault 管理员可以撤消密钥访问权限,使加密的数据库不可访问;Key Vault administrator can revoke key access permissions to make encrypted database inaccessible;

  • 集中管理 AKV 中的密钥;Central management of keys in AKV;

  • 获得最终客户的更大信任,因为 AKV 的设计可以避免 Azure 看到或提取加密密钥;Greater trust from your end customers, since AKV is designed such that Azure cannot see nor extract encryption keys;

客户管理的 TDE 的工作原理How customer-managed TDE works

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

要使服务器能够使用 AKV 中存储的 TDE 保护器来加密 DEK,Key Vault 管理员需要使用该服务器的唯一 AAD 标识向其授予以下访问权限:For server to be able to use TDE protector stored in AKV for encryption of the DEK, key vault administrator needs to give the following access rights to the server using its unique AAD identity:

  • get - 用于检索 Key Vault 中密钥的公共部分和属性get - for retrieving the public part and properties of the key in the Key Vault

  • wrapKey - 用于保护(加密)DEKwrapKey - to be able to protect (encrypt) DEK

  • unwrapKey - 用于取消保护(解密)DEKunwrapKey - to be able to unprotect (decrypt) DEK

Key Vault 管理员还可以启用 Key Vault 审核事件的日志记录,以便以后可以审核这些事件。Key vault administrator can also enable logging of key vault audit events, so they can be audited later.

将服务器配置为使用 AKV 中的 TDE 保护器后,该服务器会将每个启用了 TDE 的数据库的 DEK 发送到 Key Vault 用于加密。When server is configured to use a TDE protector from AKV, the server sends the DEK of each TDE-enabled database to the key vault for encryption. Key Vault 返回已加密的 DEK,该 DEK 随后将存储在用户数据库中。Key vault returns the encrypted DEK, which is then stored in the user database.

如果需要,服务器会将受保护的 DEK 发送到 Key Vault 用于解密。When needed, server sends protected DEK to the key vault for decryption.

如果已启用日志记录,审核员可以使用 Azure Monitor 查看 Key Vault 审核事件日志。Auditors can use Azure Monitor to review key vault AuditEvent logs, if logging is enabled.

配置客户管理的 TDE 的要求Requirements for configuring customer-managed TDE

配置 AKV 的要求Requirements for configuring AKV

  • Key Vault 和 SQL 数据库/托管实例必须属于同一个 Azure Active Directory 租户。Key vault and SQL Database/managed instance must belong to the same Azure Active Directory tenant. 不支持 Key Vault 与服务器进行跨租户的交互。Cross-tenant key vault and server interactions are not supported. 以后若要移动资源,必须重新配置 TDE 和 AKV。To move resources afterwards, TDE with AKV will have to be reconfigured. 详细了解如何移动资源Learn more about moving resources.

  • 必须对 Key Vault 启用软删除功能,以防止意外删除密钥(或 Key Vault)时发生数据丢失。Soft-delete feature must be enabled on the key vault, to protect from data loss accidental key (or key vault) deletion happens. 软删除的资源将保留 90 天,除非客户在此期间恢复或清除这些资源。Soft-deleted resources are retained for 90 days, unless recovered or purged by the customer in the meantime. “恢复”和“清除”操作在 Key Vault 访问策略中各自具有相关联的权限 。The recover and purge actions have their own permissions associated in a key vault access policy. 软删除功能默认已禁用,可通过 PowershellCLI 将其启用。Soft-delete feature is off by default and can be enabled via Powershell or CLI. 无法通过 Azure 门户启用此功能。It cannot be enabled via Azure portal.

  • 使用 SQL 数据库服务器或托管实例的 Azure Active Directory 标识向其授予对 Key Vault 的访问权限(get、wrapKey、unwrapKey)。Grant the SQL Database server or managed instance access to the key vault (get, wrapKey, unwrapKey) using its Azure Active Directory identity. 使用 Azure 门户时,会自动创建 Azure AD 标识。When using Azure portal, the Azure AD identity gets automatically created. 使用 PowerShell 或 CLI 时,必须显式创建 Azure AD 标识,并且应验证创建是否完成。When using PowerShell or CLI, the Azure AD identity must be explicitly created and completion should be verified. 有关使用 PowerShell 进行配置的详细分步说明,请参阅配置支持 BYOK 的 TDE配置支持托管实例 BYOK 的 TDESee Configure TDE with BYOK and Configure TDE with BYOK for Managed Instance for detailed step-by-step instructions when using PowerShell.

  • 将防火墙与 AKV 配合使用时,必须启用“允许信任的 Microsoft 服务绕过防火墙”选项。 When using firewall with AKV, you must enable option Allow trusted Microsoft services to bypass the firewall.

配置 TDE 保护器的要求Requirements for configuring TDE protector

  • TDE 保护器只能是非对称的 RSA 2048 密钥。TDE protector can be only asymmetric, RSA 2048 key.

  • 密钥激活日期(如果已设置)必须是过去的日期和时间。The key activation date (if set) must be a date and time in the past. 过期日期(如果已设置)必须是将来的日期和时间。Expiration date (if set) must be a future date and time.

  • 密钥必须处于“已启用”状态。 The key must be in the Enabled state.

  • 如果将现有的密钥导入 Key Vault,请确保以支持的文件格式(.pfx、.byok 或 .backup)提供该密钥。If you are importing existing key into the key vault, make sure to provide it in the supported file formats (.pfx, .byok, or .backup).

有关配置客户管理的 TDE 的建议Recommendations when configuring customer-managed TDE

配置 AKV 时的建议Recommendations when configuring AKV

  • 将最多 500 个“常规用途”或 200 个“业务关键”数据库关联到单个订阅中的一个 Key Vault,以确保在服务器访问 Key Vault 中的 TDE 保护器时实现高可用性。Associate at most 500 General Purpose or 200 Business Critical databases in total with a key vault in a single subscription to ensure high availability when server accesses the TDE protector in the key vault. 这些数字是根据经验以及 Key Vault 服务限制中的描述得出的。These figures are based on the experience and documented in the key vault service limits. 此项建议旨在防止服务器故障转移后出现问题,因为故障转移过程对保管库触发的密钥操作数目与该服务器中的数据库数目相同。The intention here is to prevent issues after server failover, as it will trigger as many key operations against the vault as there are databases in that server.

  • 在 Key Vault 中设置资源锁可以控制谁能删除此关键资源,并防止意外或未经授权的删除。Set a resource lock on the key vault to control who can delete this critical resource and prevent accidental or unauthorized deletion. 详细了解资源锁Learn more about resource locks.

  • 对所有加密密钥启用审核和报告:Key Vault 提供可以轻松注入到其他安全信息和事件管理工具的日志。Enable auditing and reporting on all encryption keys: Key vault provides logs that are easy to inject into other security information and event management tools. Operations Management Suite Log Analytics 是已集成的服务的一个示例。Operations Management Suite Log Analytics is one example of a service that is already integrated.

  • 将每个服务器链接到位于不同区域中包含相同密钥材料的两个 Key Vault,以确保已加密数据库的高可用性。Link each server with two key vaults that reside in different regions and hold the same key material, to ensure high availability of encrypted databases. 仅将同一区域的 Key Vault 中的密钥标记为 TDE 保护器。Mark only the key from the key vault in the same region as a TDE protector. 系统将使用System will use

配置 TDE 保护器时的建议Recommendations when configuring TDE protector

  • 将 TDE 保护器的副本保存在安全位置,或将其托管到托管服务。Keep a copy of the TDE protector on a secure place or escrow it to the escrow service.

  • 如果密钥是在 Key Vault 中生成的,请在首次使用 AKV 中的密钥之前创建密钥备份。If the key is generated in the key vault, create a key backup before using the key in AKV for the first time. 备份只能还原到 Azure Key Vault。Backup can be restored to an Azure Key Vault only. 详细了解 Backup-AzKeyVaultKey 命令。Learn more about the Backup-AzKeyVaultKey command.

  • 每次对密钥进行了任何更改(例如,密钥属性、标记、ACL)后,都创建新的备份。Create a new backup whenever any changes are made to the key (e.g. key attributes, tags, ACLs).

  • 轮换密钥时保留 Key Vault 中密钥的先前版本,以便可以还原旧数据库备份。Keep previous versions of the key in the key vault when rotating keys, so older database backups can be restored. 更改数据库的 TDE 保护器后,数据库的旧备份不会更新为使用最新的 TDE 保护器。When the TDE protector is changed for a database, old backups of the database are not updated to use the latest TDE protector. 在还原时,每个备份需要包含创建该备份时用于加密该备份的 TDE 保护器。At restore time, each backup needs the TDE protector it was encrypted with at creation time. 可以遵照使用 PowerShell 轮换透明数据加密保护器中的说明执行密钥轮换。Key rotations can be performed following the instructions at Rotate the Transparent Data Encryption Protector Using PowerShell.

  • 即使是在切换到服务管理的密钥之后,也应该保留 AKV 中以前使用的所有密钥。Keep all previously used keys in AKV even after switching to service-managed keys. 这可以确保能够使用 AKV 中存储的 TDE 保护器还原数据库备份。It ensures database backups can be restored with the TDE protectors stored in AKV. 通过 Azure Key Vault 创建的 TDE 保护器必须一直保留到使用服务托管的密钥创建所有剩余存储的备份为止。TDE protectors created with Azure Key Vault have to be maintained until all remaining stored backups have been created with service-managed keys. 使用 Backup-AzKeyVaultKey 创建这些密钥的可恢复备份副本。Make recoverable backup copies of these keys using Backup-AzKeyVaultKey.

  • 若要在出现安全事件期间删除可能已泄露的密钥并避免数据丢失的风险,请遵循删除可能已泄露的密钥中所述的步骤。To remove a potentially compromised key during a security incident without the risk of data loss, follow the steps from the Remove a potentially compromised key.

不可访问的 TDE 保护器Inaccessible TDE protector

如果将透明数据加密配置为使用客户管理的密钥,必须持续访问 TDE 保护器才能使数据库保持联机状态。When transparent data encryption is configured to use a customer-managed key, continuous access to the TDE protector is required for the database to stay online. 如果服务器失去了对 AKV 中客户管理的 TDE 保护器的访问权限,则在最长 10 分钟后,数据库将开始拒绝所有连接,同时显示相应的错误消息,并将其状态更改为“不可访问”。 If the server loses access to the customer-managed TDE protector in AKV, in up to 10 minutes a database will start denying all connections with the corresponding error message and change its state to Inaccessible. 对于处于“不可访问”状态的数据库,唯一允许的操作是将其删除。The only action allowed on a database in the Inaccessible state is deleting it.

Note

如果数据库由于间歇性网络中断而不可访问,则无需采取任何措施,数据库即可自动恢复联机状态。If the database is inaccessible due to an intermittent networking outage, there is no action required and the databases will come back online automatically.

还原对密钥的访问权限后,使数据库重新联机需要额外的时间并执行其他步骤,具体取决于无法访问密钥的持续间和数据库中的数据大小:After access to the key is restored, taking database back online requires additional time and steps, which may vary based on the time elapsed without access to the key and the size of the data in the database:

  • 如果在 8 小时内还原了密钥访问权限,数据库将在下一小时自动修复。If key access is restored within 8 hours, the database will auto-heal within next hour.

  • 如果在 8 小时后还原了密钥访问权限,数据库将无法自动修复,并且需要大量时间才能予以恢复,具体时间取决于数据库的大小,而且需要开具支持票证。If key access is restored after more than 8 hours, auto-heal is not possible and bringing the database back can take a significant amount of time depending on the size of the database and requires opening a support ticket. 数据库恢复联机后,先前配置的服务器级别设置(例如故障转移组配置、时间点还原历史记录和标记)将会丢失。Once the database is back online, previously configured server-level settings such as failover group configuration, point-in-time-restore history, and tags will be lost. 因此,我们建议实施一个通知系统,用于在 8 小时内识别和解决基础密钥访问问题。Therefore, it's recommended implementing a notification system that allows you to identify and address the underlying key access issues within 8 hours.

意外的 TDE 保护器访问权限吊销Accidental TDE protector access revocation

对 Key Vault 拥有足够访问权限的某人可能会意外地通过以下方式禁用服务器对密钥的访问权限:It may happen that someone with sufficient access rights to the key vault accidentally disables server access to the key by:

  • 在服务器中撤消 Key Vault 的 getwrapKeyunwrapKey 权限revoking key vault's get, wrapKey, unwrapKey permissions from the server

  • 删除密钥deleting the key

  • 删除 Key Vaultdeleting the key vault

  • 更改 Key Vault 的防火墙规则changing key vault's firewall rules

  • 在 Azure Active Directory 中删除服务器的托管标识deleting the managed identity of the server in Azure Active Directory

详细了解数据库不可访问的常见原因Learn more about the common causes for database to become inaccessible.

监视客户管理的 TDEMonitoring of the customer-managed TDE

若要监视数据库的状态并针对 TDE 保护器访问权限的丢失启用警报,请配置以下 Azure 功能:To monitor database state and to enable alerting for loss of TDE protector access, configure the following Azure features:

  • Azure 资源运行状况Azure Resource Health. 首次与失去 TDE 保护器访问权限的不可访问的数据库建立连接遭到拒绝后,该数据库将显示为“不可用”。An inaccessible database that has lost access to the TDE protector will show as "Unavailable" after the first connection to the database has been denied.
  • 活动日志。访问客户管理的 Key Vault 中的 TDE 保护器失败时,会将相应的条目添加到活动日志。Activity Log when access to the TDE protector in the customer-managed key vault fails, entries are added to the activity log. 为这些事件创建警报可以尽快恢复访问权限。Creating alerts for these events will enable you to reinstate access as soon as possible.
  • 可以定义操作组,以根据自己的偏好(例如电子邮件/短信、逻辑应用、Webhook、ITSM 或自动化 Runbook)发送通知和警报。Action Groups can be defined to send you notifications and alerts based on your preferences, e.g. Email/SMS, Logic App, Webhook, ITSM, or Automation Runbook.

使用客户管理的 TDE 进行数据库备份和还原Database backup and restore with customer-managed TDE

使用 Key Vault 中的密钥通过 TDE 加密数据库后,所有新生成的备份也会使用同一个 TDE 保护器进行加密。Once a database is encrypted with TDE using a key from Key Vault, any newly generated backups are also encrypted with the same TDE protector. 更改 TDE 保护器后,数据库的旧备份不会更新为使用最新的 TDE 保护器。When the TDE protector is changed, old backups of the database are not updated to use the latest TDE protector.

若要还原使用 Key Vault 中的 TDE 保护器加密的备份,请确保密钥材料可供目标服务器使用。To restore a backup encrypted with a TDE protector from Key Vault, make sure that the key material is available to the target server. 因此,我们建议在 Key Vault 中保留所有旧版 TDE 保护器,以便可以还原数据库备份。Therefore, we recommend that you keep all the old versions of the TDE protector in key vault, so database backups can be restored.

Important

无论何时,为服务器设置的 TDE 保护器都不能超过一个。At any moment there can be not more than one TDE protector set for a server. 此保护器在 Azure 门户边栏选项卡中标记为“使该密钥成为默认的 TDE 保护器”。It's the key marked with "Make the key the default TDE protector" in the Azure portal blade. 但是,可将其他多个密钥链接到服务器,而无需将其标记为 TDE 保护器。However, multiple additional keys can be linked to a server without marking them as a TDE protector. 这些密钥不是用于保护 DEK,而是在从备份还原期间使用(如果备份文件是使用具有相应指纹的密钥加密的)。These keys are not used for protecting DEK, but can be used during restore from a backup, if backup file is encrypted with the key with the corresponding thumbprint.

如果还原备份所需的密钥不再可供目标服务器使用,则尝试还原时会返回以下错误消息:“目标服务器 <Servername> 无权访问在 <时间戳 #1> 与 <时间戳 #2> 之间创建的所有 AKV URI。If the key that is needed for restoring a backup is no longer available to the target server, the following error message is returned on the restore try: "Target server <Servername> does not have access to all AKV URIs created between <Timestamp #1> and <Timestamp #2>. 请在还原所有 AKV URI 之后重试操作。”Please retry operation after restoring all AKV URIs."

若要缓解此问题,请对目标 SQL 数据库逻辑服务器运行 Get-AzSqlServerKeyVaultKey cmdlet,或对目标托管实例运行 Get-AzSqlInstanceKeyVaultKey,以返回可用密钥的列表并标识缺少的密钥。To mitigate it, run the Get-AzSqlServerKeyVaultKey cmdlet for target SQL Database logical server or Get-AzSqlInstanceKeyVaultKey for target managed instance to return the list of available keys and identify the missing ones. 为了确保可以还原所有备份,请确保要还原的目标服务器有权访问全部所需的密钥。To ensure all backups can be restored, make sure the target server for the restore has access to all of keys needed. 这些密钥无需标记为 TDE 保护器。These keys don't need to be marked as TDE protector.

若要详细了解 SQL 数据库的备份恢复,请参阅恢复 Azure SQL 数据库To learn more about backup recovery for SQL Database, see Recover an Azure SQL database. 若要详细了解 SQL 数据仓库的备份恢复,请参阅恢复 Azure SQL 数据仓库To learn more about backup recovery for SQL Data Warehouse, see Recover an Azure SQL Data Warehouse. 有关 SQL Server 托管实例的本机备份/还原,请参阅快速入门:将数据库还原到托管实例For SQL Server's native backup/restore with managed instance, see Quickstart: Restore a database to a Managed Instance

有关日志文件的其他注意事项:备份的日志文件仍会使用原始 TDE 保护器保持加密,即使 TDE 保护器已轮换,并且数据库正在使用新的 TDE 保护器。Additional consideration for log files: Backed up log files remain encrypted with the original TDE protector, even if it was rotated and the database is now using a new TDE protector. 还原时,需要使用这两个密钥来还原数据库。At restore time, both keys will be needed to restore the database. 如果日志文件使用 Azure Key Vault 中存储的 TDE 保护器,则还原时需要此密钥,即使数据库同时已改用服务托管的 TDE。If the log file is using a TDE protector stored in Azure Key Vault, this key will be needed at restore time, even if the database has been changed to use service-managed TDE in the meantime.

使用客户管理的 TDE 实现高可用性High availability with customer-managed TDE

即使没有为服务器配置异地冗余,我们也强烈建议将服务器配置为使用两个不同区域中的包含相同密钥材料的两个不同 Key Vault。Even in cases when there is no configured geo-redundancy for server, it is highly recommended to configure the server to use two different key vaults in two different regions with the same key material. 若要实现此目的,可以使用与服务器共置在同一区域中的主要 Key Vault 来创建一个 TDE 保护器,并将密钥克隆到位于不同 Azure 区域中的 Key Vault,以便在主要 Key Vault 遇到服务中断时,服务器能够访问另一个 Key Vault,同时让数据库保持正常运行。It can be accomplished by creating a TDE protector using the primary key vault co-located in the same region as the server and cloning the key into a key vault in a different Azure region, so that the server has access to a second key vault should the primary key vault experience an outage while the database is up and running.

使用 Backup-AzKeyVaultKey cmdlet 从主要 Key Vault 检索加密格式的密钥,然后使用 Restore-AzKeyVaultKey cmdlet 并指定第二个区域中的 Key Vault 来克隆密钥。Use the Backup-AzKeyVaultKey cmdlet to retrieve the key in encrypted format from the primary key vault and then use the Restore-AzKeyVaultKey cmdlet and specify a key vault in the second region to clone the key. 或者,使用 Azure 门户来备份和还原密钥。Alternatively, use Azure portal to backup and restore key. 不应将另一区域的辅助 Key Vault 中的密钥标记为 TDE 保护器,甚至不允许这样做。The key in the secondary key vault in se other region should not be marked as TDE protector, and it's not even allowed.

如果发生了影响主要 Key Vault 的服务中断,只有在满足上述条件时,系统才会自动切换到辅助 Key Vault 中具有相同指纹的另一个已链接密钥(如果存在)。If there is an outage affecting primary key vault, and only then, system will automatically switch to the other linked key with the same thumbprint in the secondary key vault, if it exists. 请注意,如果由于撤销了访问权限或者由于删除了密钥或 Key Vault 而无法访问 TDE 保护器,则不会发生这种切换,因为这可能意味着客户有意地想要限制服务器访问密钥。Note though that switch will not happen if TDE protector is inaccessible because of revoked access rights, or because key or key vault is deleted, as it may indicate that customer intentionally wanted to restrict server from accessing the key.

单服务器高可用性

异地灾难恢复和客户管理的 TDEGeo-DR and customer-managed TDE

活动异地复制故障转移组方案中,涉及的每个服务器都需要一个单独的 Key Vault,该 Key Vault 必须与服务器共置在同一个 Azure 区域中。In both active geo-replication and failover groups scenarios, each server involved requires a separate key vault, that must be co-located with the server in the same Azure region. 客户负责使各个 Key Vault 中的密钥材料保持一致,使异地辅助节点保持同步,并在主要节点由于区域发生服务中断或者触发故障转移而不可访问时,辅助节点可以使用客户本地 Key Vault 中的同一密钥接管工作。Customer is responsible for keeping the key material across the key vaults consistent, so that geo-secondary is in sync and can take over using the same key from its local key vault if primary becomes inaccessible due to an outage in the region and a failover is triggered. 最多可以配置四个辅助节点,不支持链接(辅助节点的辅助节点)。Up to four secondaries can be configured, and chaining (secondaries of secondaries) is not supported.

为了避免由于密钥材料不完整而在建立异地复制或者在异地复制期间出现问题,请务必在配置客户管理的 TDE 时遵循以下规则:To avoid issues while establishing or during geo-replication due to incomplete key material, it's important to follow these rules when configuring customer-managed TDE:

  • 涉及的所有 Key Vault 必须具有相同的属性,并为相应的服务器提供相同的访问权限。All key vaults involved must have same properties, and same access rights for respective servers.

  • 涉及的所有 Key Vault 必须包含相同的密钥材料。All key vaults involved must contain identical key material. 这不仅适用于当前的 TDE 保护器,而且还适用于以前在备份文件中使用的所有 TDE 保护器。It applies not just to the current TDE protector, but to the all previous TDE protectors that may be used in the backup files.

  • TDE 保护器的初始设置和轮换必须先在辅助节点上执行,然后在主要节点上执行。Both initial setup and rotation of the TDE protector must be done on the secondary first, and then on primary.

故障转移组和异地灾难恢复

若要测试故障转移,请遵循活动异地复制概述中的步骤。To test a failover, follow the steps in Active geo-replication overview. 应定期执行此操作,以确认 SQL 对两个 Key Vault 保持访问权限。It should be done on a regular basis to confirm the access permissions for SQL to both key vaults have been maintained.

后续步骤Next steps

建议查看以下 PowerShell 示例脚本,以了解可对客户管理的 TDE 执行的常见操作:You may also want to check the following PowerShell sample scripts for the common operations with customer-managed TDE: