Cifrado de datos transparente (TDE) con claves administradas por el cliente en el nivel de base de datos

Se aplica a:Azure SQL Database

En este artículo se describe el cifrado de datos transparente (TDE) con claves administradas por el cliente en el nivel de base de datos de Azure SQL Database.

Información general

Azure SQL ofrece la funcionalidad de cifrado en reposo a los clientes a través del cifrado de datos transparente (TDE). La extensión de TDE con clave administrada por el cliente (CMK) permite la protección de datos en reposo donde el protector de TDE (la clave de cifrado) se almacena en una instancia de Azure Key Vault o HSM administrado de Azure que cifra las claves de cifrado de base de datos. El TDE con CMK se puede establecer en el nivel de servidor y se hereda por todas las bases de datos cifradas asociadas a ese servidor. También puede establecer el protector de TDE como una clave administrada por el cliente individualmente para cada base de datos del servidor. Cualquier recurso Microsoft.Sql/servers/databases con una propiedad válida y no vacía encryptionProtector se configura con claves administradas por el cliente en el nivel de base de datos. Las claves administradas por el cliente admiten claves asimétricas (RSA) y simétricas (AES), en función del almacén de claves seleccionado.

En este escenario, se puede usar individualmente para cada base de datos de un servidor una clave asimétrica o simétrica almacenada en un Azure Key Vault propiedad del cliente y administrado por este, o en Azure Managed HSM, para cifrar la clave de cifrado de la base de datos (DEK), denominada protector de TDE. Hay una opción para agregar claves, quitar claves y cambiar la identidad administrada asignada por el usuario (UMI) para cada base de datos. Para más información sobre identidades, vea Tipos de identidad administrada en Azure.

La siguiente funcionalidad está disponible:

• Identidad administrada asignada por el usuario: puede asignar una única identidad administrada asignada por el usuario a la base de datos. Esta identidad se puede usar para acceder a Azure Key Vault o Azure Managed HSM y administrar claves de cifrado.
• Administración de claves de cifrado: puede habilitar una o varias claves de cifrado que se van a agregar en el nivel de base de datos y establecer una de las claves agregadas como protector de TDE. Las claves de cifrado que se agregan usan la identidad administrada asignada por el usuario ya asignada a la base de datos para acceder a Azure Key Vault o Azure Managed HSM.
• Identidad de cliente federada: también puede habilitar una clave administrada por el cliente (CMK) desde Azure Key Vault o Azure Managed HSM en otro inquilino de Microsoft Entra para establecerse como protector de TDE en el nivel de base de datos, mediante el uso de la identidad de cliente federada establecida en Azure SQL Database. Esto le permite administrar TDE con claves almacenadas en Azure Key Vault de otro inquilino o HSM administrado por Azure.

Ventajas del TDE administrado por el cliente en el nivel de base de datos

A medida que más proveedores de servicios, también conocidos como proveedores de software independientes (ISV), usan Azure SQL Database para crear sus servicios, muchos recurren a grupos elásticos como una manera de distribuir eficazmente los recursos de proceso entre varias bases de datos. Al tener cada una de las bases de datos de sus clientes en un grupo elástico compartido, los ISV pueden aprovechar la capacidad del grupo para optimizar el uso de recursos, a la vez que garantizan que cada base de datos tenga los recursos adecuados.

Sin embargo, hay una limitación significativa para este enfoque. Cuando varias bases de datos se hospedan en el mismo servidor lógico de Azure SQL, comparten el protector de TDE de nivel de servidor. Los ISV no pueden ofrecer verdaderas funcionalidades de claves administradas por el cliente (CMK) a sus clientes. Sin la capacidad de gestionar sus propias claves de cifrado, los clientes podrían mostrarse reacios a confiar datos sensibles al servicio del ISV, especialmente si las normativas de cumplimiento les obligan a mantener el control total sobre sus claves de cifrado.

Con CMK de TDE en el nivel de base de datos, los ISV pueden ofrecer la funcionalidad de CMK a sus clientes y lograr el aislamiento de seguridad, ya que el protector de TDE de cada base de datos puede ser propiedad del cliente de ISV correspondiente en un almacén de claves o HSM administrado de su propiedad. El aislamiento de seguridad logrado para los clientes de ISV es tanto en términos de la clave como de la identidad que se usa para acceder a la clave.

En el diagrama siguiente se resume la nueva funcionalidad indicada anteriormente. Presenta dos inquilinos independientes de Microsoft Entra. El inquilino Best Services que contiene el servidor lógico de Azure SQL con dos bases de datos, DB 1 y DB 2, y Azure Key Vault 1 con Key 1 que accede a la base de datos DB 1 mediante UMI 1. Tanto UMI 1 como Key 1 representan la configuración de nivel de servidor. De forma predeterminada, todas las bases de datos creadas inicialmente en este servidor heredan esta configuración para TDE con CMK. El inquilino Contoso representa un inquilino de cliente que contiene Azure Key Vault 2 con una Key 2 que evalúa la base de datos DB 2 en todo el inquilino como parte de la compatibilidad entre inquilinos de CMK en el nivel de base de datos mediante la configuración de Key 2 y UMI 2 para esta base de datos.

Para más información sobre la configuración de identidad entre inquilinos, consulte el documento de nivel de servidor Claves administradas por el cliente entre inquilinos con cifrado de datos transparente.

Escenarios admitidos de administración de claves

En la sección siguiente, supongamos que hay un servidor que consta de tres bases de datos (por ejemplo Database1, Database2y Database3).

Escenario existente

Key1 se configura como la clave administrada por el cliente en el nivel de servidor lógico. Todas las bases de datos de este servidor heredan la misma clave.

• Servidor: Key1 se establece como CMK
• Database1: Key1 se usa como CMK
• Database2: Key1 se usa como CMK
• Database3: Key1 se usa como CMK

Nuevo escenario admitido: servidor lógico configurado con clave administrada por el cliente

Key1 se configura como la clave administrada por el cliente en el nivel de servidor lógico. Se puede configurar una clave administrada por el cliente (Key2) diferente en el nivel de base de datos.

• Servidor: Key1 se establece como CMK
• Database1: Key2 se usa como CMK
• Database2: Key1 se usa como CMK
• Database3: Key1 se usa como CMK

Nuevo escenario admitido: servidor lógico configurado con clave administrada por el servicio

El servidor lógico se configura con la clave administrada por el servicio (SMK) para TDE. Se puede configurar una clave administrada por el cliente (Key2) diferente en el nivel de base de datos.

• Servidor: clave administrada por el servicio establecida como protector de TDE
• Database1: Key2 se establece como CMK
• Database2: clave administrada por el servicio establecida como protector de TDE
• Database3: clave administrada por el servicio establecida como protector de TDE

Reversión al cifrado de nivel de servidor

Database1 se configura con una clave administrada por el cliente en el nivel de base de datos para TDE, mientras que el servidor lógico se configura con clave administrada por el servicio. Database1 se puede revertir para usar la clave administrada por el servicio en el nivel de servidor lógico.

Cifrado de datos transparente con claves gestionadas por el cliente utiliza una clave externa, denominada protector TDE, almacenada en Azure Key Vault o Azure Managed HSM para proteger la clave de cifrado de la base de datos (DEK).

Tamaños y tipos de clave admitidos

Según la oferta de Azure SQL y la configuración de TDE, el protector de TDE puede estar respaldado por claves asimétricas o simétricas almacenadas en Azure Key Vault o Azure Key Vault HSM administrado.

• Claves asimétricas (RSA o RSA HSM)

  • Compatible con Azure Key Vault y Azure Key Vault Managed HSM
  • Tamaños de clave soportados: 2048 bits y 3072 bits
  • Compatible con Azure SQL Database, Azure SQL Managed Instance y Azure Synapse Analytics

• Claves simétricas (AES)

  • Compatible con Azure Key Vault Premium (previsualización) y Azure Key Vault Managed HSM
  • Tamaños de clave soportados: 128 bits, 192 bits y 256 bits
  • Solo se admite para Azure SQL Database, actualmente en versión preliminar pública. Es posible que vea que esta funcionalidad aparece con el tiempo en función del estado de implementación del servicio y la región.

Limitaciones de las claves simétricas (AES)

Cuando se utilizan claves simétricas (AES) como protector TDE, solo se soportan las claves almacenadas en Azure Key Vault Premium (previsualización) o Azure Key Vault Managed HSM para operaciones continuas del ciclo de vida de las claves. Los clientes pueden importar una clave de un módulo de seguridad de hardware (HSM) local una sola vez a Azure Key Vault Premium (vista previa) o Azure Key Vault Managed HSM. Tras la importación inicial, todas las operaciones posteriores del ciclo de vida de claves, incluyendo recuperación puntual, recuperación geo-desastre y revalidación de claves, deben depender de la infraestructura Azure Key Vault Premium (preview) o Azure Key Vault Managed HSM. Los clientes son responsables de mantener copias de seguridad locales de claves importadas para admitir escenarios de recuperación y revalidación. Estas limitaciones solo se aplican a las claves simétricas (AES) y no se aplican a las claves asimétricas (RSA).

Requisitos principales de estado y validez

• Si se especifica una fecha de activación de clave, debe establecerse en una fecha y hora en el pasado.
• Si se especifica una fecha de expiración de clave, debe establecerse en una fecha y hora en el futuro.
• El estado de la clave debe ser Habilitada.

Requisitos de importación de claves

Si importa una clave existente en Azure Key Vault, la clave debe proporcionarse en uno de los siguientes formatos admitidos:

• .pfx
• .byok
• .backup

Para importar claves protegidas con HSM en Azure Managed HSM, consulte Importación de claves protegidas por HSM en HSM administrado (BYOK).

Azure Key Vault y Azure Managed HSM - requisitos de identidad gestionada

Los mismos requisitos para configurar Azure Key Vault, las claves de Azure Managed HSM y las identidades administradas, incluyendo la configuración de claves y los permisos otorgados a la identidad que se aplican a la función de clave administrada por el cliente (CMK) a nivel de servidor, también se aplican a la CMK a nivel de base de datos. Para más información, consulte Cifrado de datos transparente (TDE) con CMK e identidades administradas con CMK.

Administración de claves

La rotación del protector de TDE para una base de datos significa cambiar a una nueva clave asimétrica que protege la base de datos. La rotación de claves es una operación en línea y solo debería tardar unos segundos en completarse. La operación solo descifra y vuelve a cifrar la clave de cifrado de la base de datos, no toda la base de datos.

Puede rotar el protector de TDE cambiando la configuración para usar una nueva clave almacenada en Azure Key Vault o Azure Key Vault HSM administrado. En función de la oferta de Azure SQL y la configuración admitida, esto puede incluir:

• Cambiar a una nueva versión de la misma clave
• Cambiar a otra clave
• Cambio entre tipos de clave admitidos, como claves asimétricas (RSA) y simétricas (AES)

Una vez que una identidad administrada asignada por el usuario válida se ha asignado a una base de datos, la rotación de la clave en el nivel de base de datos es una operación CRUD de base de datos que implica actualizar la propiedad de protector de cifrado de la base de datos. Set-AzSqlDatabase y la propiedad -EncryptionProtector se pueden usar para rotar las claves. Para crear una base de datos configurada con CMK en el nivel de base de datos, New-AzSqlDatabase se puede usar con los parámetros -EncryptionProtector, -AssignIdentity y -UserAssignedIdentityId.

Se pueden agregar nuevas claves y se pueden quitar claves existentes de la base de datos mediante solicitudes similares, así como modificar la propiedad keys para el recurso de base de datos. Set-AzSqlDatabase con los parámetros -KeyList y -KeysToRemove se pueden usar para estas operaciones. Para recuperar el protector de cifrado, la identidad y la configuración de claves, se puede usar Get-AzSqlDatabase. El recurso Microsoft.Sql/servers/databases de Azure Resource Manager solo muestra de forma predeterminada el protector de TDE y la identidad administrada configurada en la base de datos. Para expandir la lista completa de claves, se necesitan otros parámetros, como -ExpandKeyList. Además, se pueden usar -KeysFilter "current" y un valor de un momento dado (por ejemplo, 2023-01-01) para recuperar las claves actuales usadas y las claves usadas en el pasado en un momento dado específico.

Rotación automática de claves

La rotación automática de claves está disponible en el nivel de base de datos y se puede usar con claves de Azure Key Vault o HSM administrado de Azure. La rotación se activa cuando se detecta una nueva versión de la tecla, y el protector TDE gira automáticamente en 24 horas. Para información sobre cómo configurar la rotación automática de claves usando PowerShell o la CLI de Azure, véase Rotación automática de claves a nivel de base de datos.

Permiso para la administración de claves

Seleccione el tipo de almacén de claves que desea usar.

Claves administradas por el cliente entre inquilinos

En Claves administradas por el cliente entre inquilinos con cifrado de datos transparente se describe cómo configurar un id. de cliente federado para CMK de nivel de servidor. Es necesario realizar una configuración similar para CMK en el nivel de base de datos y el id. de cliente federado debe agregarse como parte de las solicitudes de API set-AzSqlDatabase o New-AzSqlDatabase.

Una base de datos configurada con CMK de nivel de base de datos se puede revertir al cifrado de nivel de servidor si el servidor lógico está configurado con una clave administrada por el servicio mediante Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

En caso de un protector de TDE inaccesible, tal como se describe en Cifrado de datos transparente (TDE) con CMK, una vez corregido el acceso a la clave, se puede usar Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation para hacer que la base de datos sea accesible.

Consideraciones adicionales

• Si TDE con CMK ya está habilitado en el nivel de servidor, el establecimiento de CMK para una base de datos determinada invalida la configuración de CMK en el nivel de servidor (la DEK de la base de datos se vuelve a cifrar con el protector de TDE de nivel de base de datos).
• Los cambios o rotaciones de clave en el nivel de servidor lógico no afectan a la configuración de CMK en el nivel de base de datos y la base de datos sigue usando su propia configuración de CMK.
• CMK en el nivel de base de datos no se admite a través de Transact-SQL (T-SQL).
• La identidad administrada asignada por el usuario (UMI) del servidor lógico se puede usar en el nivel de base de datos. Sin embargo, se recomienda usar una UMI designada para la CMK en el nivel de base de datos.
• La configuración de CMK entre inquilinos en el nivel de servidor no afecta a las bases de datos individuales configuradas con CMK en el nivel de base de datos y siguen usando su propia configuración de inquilino único o entre inquilinos.
• Solo se puede establecer una única identidad administrada asignada por el usuario en el nivel de base de datos.

Migración de bases de datos existentes a CMK en el nivel de base de datos

Las nuevas bases de datos se pueden configurar con CMK en el nivel de base de datos durante la creación y las bases de datos existentes en servidores configurados con claves administradas por el servicio se pueden migrar a CMK en el nivel de base de datos mediante las operaciones descritas en Administración de identidades y claves para TDE con claves administradas por el cliente en el nivel de base de datos. Para migrar bases de datos configuradas con CMK en el nivel de servidor o replicación geográfica, se necesitan otros pasos, como se describe en las secciones siguientes.

Base de datos configurada con una CMK en el nivel de servidor sin replicación geográfica

1. Use sys.dm_db_log_info (Transact-SQL): SQL Server para la base de datos y busque los archivos de registro virtuales (VLF) que están activos.
2. Para todos los VLF activos, registre vlf_encryptor_thumbprint partir del resultado de sys.dm_db_log_info.
3. Use la vista sys.dm_database_encryption_keys (Transact-SQL): SQL Server de la base de datos para comprobar encryptor_thumbprint. Registre encryptor_thumbprint.
4. Use el cmdlet Get-AzSqlServerKeyVaultKey para obtener todas las claves de nivel de servidor configuradas en el servidor lógico. De los resultados, elige aquellos que tengan la misma huella digital que coincida con tu lista del paso anterior.
5. Realice una llamada de API de actualización de base de datos a la base de datos que desea migrar, junto con el protector de identidad y cifrado. Pase las claves anteriores como claves de nivel de base de datos mediante Set-AzSqlDatabase con los parámetros -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (y, si es necesario, -FederatedClientId).

Base de datos configurada con CMK en el nivel de servidor con replicación geográfica

1. Sigue los pasos 1 a 4 mencionados en la sección anterior para recuperar la lista de claves necesarias para la migración.
2. Haz una llamada a la API de actualización de la base de datos a la base de datos primaria y secundaria que quieras migrar, junto con la identidad y las claves anteriores como claves a nivel de base de datos usando Set-AzSqlDatabase y el -KeyList parámetro. No establezca todavía el protector de cifrado.
3. Añade la clave a nivel de base de datos que quieres usar como protector principal en las bases de datos a la base de datos secundaria. Use Set-AzSqlDatabase con -KeyList para agregar esta clave en la base de datos secundaria.
4. Después de añadir la clave protectora de cifrado a la base de datos secundaria, usa Set-AzSqlDatabase para configurarla como protector de cifrado en la base de datos principal usando el -EncryptionProtector parámetro.
5. Establezca la clave como protector de cifrado en la base de datos secundaria como se describe en el paso 4 para completar la migración.

Replicación geográfica y alta disponibilidad

Tanto en el escenario de replicación geográfica activa como en el de grupos de conmutación por error, las bases de datos principales y secundarias implicadas se pueden vincular al mismo almacén de claves o HSM administrado (en cualquier región) o a almacenes de claves o HSM administrado independientes. Si los almacenes de claves independientes o los HSM administrados están vinculados a los servidores principales y secundarios, el cliente es responsable de mantener el material de clave entre los almacenes de claves o los HSM administrados, de modo que la base de datos geográfica secundaria esté sincronizada y pueda asumir el uso de la misma clave desde su almacén de claves vinculado o HSM administrado si la principal deja de estar accesible debido a una interrupción en la región y se desencadena una conmutación por error. Se pueden configurar hasta cuatro segundos y el encadenamiento (secundarias de los segundos) no es compatible.

Para establecer la replicación geográfica activa para una base de datos que se ha configurado con CMK en el nivel de base de datos, se debe crear una réplica secundaria con una identidad administrada asignada por el usuario válida y una lista de las claves actuales que la base de datos principal usa. La lista de claves actuales se puede recuperar de la base de datos principal mediante filtros y parámetros de consulta necesarios, o mediante PowerShell y la CLI de Azure. Los pasos necesarios para configurar una réplica geográfica de dicha base de datos son:

1. Rellene previamente la lista de claves que la base de datos principal usa mediante el comando Get-AzSqlDatabase y los parámetros -ExpandKeyList y -KeysFilter "current". Excluya -KeysFilter si desea recuperar todas las claves.
2. Seleccione la identidad administrada asignada por el usuario (y el id. de cliente federado si configura el acceso entre inquilinos).
3. Cree una base de datos como secundaria mediante New-AzSqlDatabaseSecondary y proporcione la lista de claves rellenada previamente obtenidas de la base de datos de origen y la identidad anterior (y el id. de cliente federado si configura el acceso entre inquilinos) en la llamada API mediante los parámetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (y si es necesario -FederatedClientId).
4. Use New-AzSqlDatabaseCopy para crear una copia de la base de datos con los mismos parámetros del paso anterior.

Para más información, Configurar la replicación geográfica y la restauración de copia de seguridad para el cifrado de datos transparente con claves administradas por el cliente a nivel de base de datos describe cómo configurar la replicación geográfica y los grupos de conmutación por error mediante las API REST, PowerShell y la Interfaz de Línea de Comandos de Azure.

Copia de seguridad y restauración de bases de datos mediante TDE con clave administrada por el cliente en el nivel de base de datos

Una vez que una base de datos se cifra con TDE mediante una clave de Azure Key Vault o HSM administrado de Azure, las copias de seguridad recién generadas también se cifran con el mismo protector de TDE. Cuando se cambia el protector de TDE, las copias de seguridad antiguas de la base de datos no se actualizan para usar el protector de TDE más reciente. Para restaurar una copia de seguridad cifrada con un protector de TDE desde Azure Key Vault o Azure Managed HSM configurado en el nivel de base de datos, asegúrese de que el material de clave se proporciona a la base de datos de destino. Se recomienda mantener todas las versiones anteriores del protector de TDE en el almacén de claves o HSM administrado, para que se puedan restaurar las copias de seguridad de la base de datos.

Restauración a un momento dado

Los pasos siguientes son necesarios para una restauración a un momento dado de una base de datos configurada con claves administradas por el cliente en el nivel de base de datos:

1. Rellene previamente la lista de claves que la base de datos principal usa mediante el comando Get-AzSqlDatabase y los parámetros -ExpandKeyList y -KeysFilter "2023-01-01". 2023-01-01 es un ejemplo del momento dado al que desea restaurar la base de datos. Excluya -KeysFilter si desea recuperar todas las claves.
2. Seleccione la identidad administrada asignada por el usuario (y el id. de cliente federado si configura el acceso entre inquilinos).
3. Use Restore-AzSqlDatabase con el parámetro -FromPointInTimeBackup y proporcione la lista de claves rellenada previamente obtenidas de los pasos anteriores y la identidad anterior (y el id. de cliente federado si configura el acceso entre inquilinos) en la llamada API mediante los parámetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (y, si es necesario, -FederatedClientId).

Restauración de bases de datos eliminadas

Los pasos siguientes son necesarios para una restauración de una base de datos eliminada configurada con claves administradas por el cliente en el nivel de base de datos:

1. Pre-completa la lista de claves usadas por la base de datos principal ejecutando Get-AzSqlDeletedDatabaseBackup con el -ExpandKeyList parámetro. Pasa todas las claves que usó la base de datos de origen. Alternativamente, puedes intentar restaurar usando las claves proporcionadas en el momento de la eliminación como -KeysFilter.
2. Seleccione la identidad administrada asignada por el usuario (y el id. de cliente federado si configura el acceso entre inquilinos).
3. Use Restore-AzSqlDatabase con el parámetro -FromDeletedDatabaseBackup y proporcione la lista de claves rellenada previamente obtenidas de los pasos anteriores y la identidad anterior (y el id. de cliente federado si configura el acceso entre inquilinos) en la llamada API mediante los parámetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (y, si es necesario, -FederatedClientId).

Restauración geográfica

Los pasos siguientes son necesarios para una restauración geográfica de una base de datos configurada con claves administradas por el cliente en el nivel de base de datos:

• Rellene previamente la lista de claves que la base de datos principal usa mediante Get-AzSqlDatabaseGeoBackup y -ExpandKeyList para recuperar todas las claves.
• Seleccione la identidad administrada asignada por el usuario (y el id. de cliente federado si configura el acceso entre inquilinos).
• Use Restore-AzSqlDatabase con el parámetro -FromGeoBackup y proporcione la lista de claves rellenada previamente obtenidas de los pasos anteriores y la identidad anterior (y el id. de cliente federado si configura el acceso entre inquilinos) en la llamada API mediante los parámetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (y, si es necesario, -FederatedClientId).

Limitaciones

La característica de claves administradas por el cliente en el nivel de base de datos no admite rotaciones de claves cuando los archivos de registro virtual de la base de datos se cifran con una clave antigua diferente del protector principal actual de la base de datos. El error que se produce en este caso es:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: la rotación de claves del protector de TDE en el nivel de base de datos se bloquea cuando las transacciones activas mantienen el registro cifrado con claves antiguas.

Para profundizar aún más este escenario, vamos a considerar la siguiente escala de tiempo:

• Hora t0 = Se crea una base de datos sin cifrado
• Hora t1 = Esta base de datos se protege mediante Thumbprint A, que es una clave administrada por el cliente en el nivel de base de datos.
• Hora t2 = El protector de base de datos rota a una nueva clave administrada por el cliente en el nivel de base de datos, Thumbprint B.
• Hora t3 = Se solicita que un cambio de protector a Thumbprint C.
• Si los VLF activos usan Thumbprint A, la rotación no se permite.
• Si los VLF activos no usan Thumbprint A, la rotación se permite.

Puede usar la vista sys.dm_db_log_info (Transact-SQL): SQL Server para la base de datos y busque los archivos de registro virtuales que están activos. Debería ver un VLF activo cifrado con la primera clave (por ejemplo, Thumbprint A). Una vez que se ha generado un registro suficiente mediante la inserción de datos, este VLF antiguo se vacía y debería poder realizar otra rotación de claves.

Si cree que algo está retrasando el registro por más tiempo del esperado, consulte la siguiente documentación para obtener más información sobre la solución de problemas:

• sys.dm_db_log_stats (Transact-SQL) para los posibles valores de log_truncation_holdup_reason.
• Solución de problemas de un registro de transacciones lleno 9002.

Contenido relacionado

Consulte la siguiente documentación sobre varias operaciones de CMK en el nivel de base de datos:

• Administración de identidades y claves para TDE con claves administradas por el cliente en el nivel de base de datos
• Configuración de la replicación geográfica y la restauración de copias de seguridad para el cifrado de datos transparente con claves administradas por el cliente en el nivel de base de datos