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 que cifra las claves de cifrado de base de datos. Actualmente, TDE con CMK se establece en el nivel de servidor y todas las bases de datos cifradas asociadas con dicho servidor lo heredan. Esta nueva característica permite establecer el protector de TDE como una clave administrada por el cliente individualmente para cada base de datos dentro 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.

En este escenario, una clave asimétrica que se almacena en una instancia de Azure Key Vault (AKV) propiedad del cliente y administrada por este se puede usar individualmente para cada base de datos dentro de un servidor para cifrar la clave de cifrado de base de datos (DEK), que se denomina 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 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.
• Identidad de cliente federada: también puede habilitar una clave administrada por el cliente (CMK) desde Azure Key Vault en otro inquilino de Microsoft Entra para que se establezca 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 la instancia de Azure Key Vault de otro inquilino.

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 administrar sus propias claves de cifrado, los clientes pueden dudar en confiar datos confidenciales al servicio del ISV, especialmente si las normas de cumplimiento les exigen mantener un 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 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.

Requisitos del almacén de claves y de la identidad administrada

Los mismos requisitos para configurar las claves e identidades administradas de Azure Key Vault (AKV), incluida la configuración de clave y los permisos concedidos a la identidad que se aplican a la característica de clave administrada por el cliente (CMK) en el nivel de servidor, también se aplican a la CMK de 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. 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. La rotación se desencadena cuando se detecta una nueva versión de la clave y se rotará automáticamente en un plazo de 24 horas. Para obtener información sobre cómo configurar la rotación automática de claves mediante Azure Portal, PowerShell o la CLI de Azure, vea Rotación automática de claves en el nivel de base de datos.

Permiso para la administración de claves

En función del modelo de permisos del almacén de claves (directiva de acceso o RBAC de Azure), se puede conceder acceso al almacén de claves mediante la creación de una directiva de acceso en el almacén de claves, o bien de una asignación de roles RBAC de Azure.

Modelo de permisos de directiva de acceso

Para que la base de datos use el protector de TDE almacenado en AKV para el cifrado de DEK, el administrador del almacén de claves debe proporcionar los siguientes derechos de acceso a la identidad administrada asignada por el usuario de la base de datos mediante su identidad única de Microsoft Entra:

• get: para recuperar la parte pública y las propiedades de la clave en Azure Key Vault.
• wrapKey: para poder proteger (cifrar) la DEK.
• unwrapKey: para poder desproteger (descifrar) la DEK.

Modelo de permisos de RBAC de Azure

Para que la base de datos use el protector de TDE almacenado en AKV para el cifrado de DEK, se debe agregar una nueva asignación de roles de RBAC de Azure con el rol Key Vault Crypto Service Encryption User para la identidad administrada asignada por el usuario de la base de datos mediante su identidad única de Microsoft Entra.

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. En los resultados, elija los que tengan la misma huella digital que coincida con la lista del resultado 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 en el nivel de base de datos mediante Set-AzSqlDatabase, utilizando para ello los parámetros -UserAssignedIdentityId, -AssignIdentity, -KeyList y -EncryptionProtector (y, si es necesario, -FederatedClientId).

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

1. Siga los pasos (1) a (4) mencionados en la sección anterior para recuperar la lista de claves que se necesitarán para la migración.
2. Realice una llamada de API de actualización de base de datos a la base de datos principal y secundaria que desea migrar, junto con la identidad y las claves anteriores como claves en el nivel de base de datos mediante Set-AzSqlDatabase y el parámetro -KeyList. No establezca todavía el protector de cifrado.
3. La clave en el nivel de base de datos que desea usar como protector principal en las bases de datos debe agregarse primero a la base de datos secundaria. Use Set-AzSqlDatabase con -KeyList para agregar esta clave en la base de datos secundaria.
4. Una vez agregada la clave del protector de cifrado a la base de datos secundaria, use Set-AzSqlDatabase para establecerla como protector de cifrado en la base de datos principal mediante el parámetro -EncryptionProtector.
5. Establezca la clave como protector de cifrado en la base de datos secundaria como se describe en (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 (en cualquier región) o a almacenes de claves independientes. Si los almacenes de claves independientes están vinculados a los servidores principales y secundarios, el cliente es responsable de mantener el material de clave en los almacenes de claves coherente, de modo que la instancia geográfica secundaria esté sincronizada y pueda tomar el control con la misma clave de su almacén de claves vinculado si el principal se vuelve inaccesible por una interrupción de 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, en 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 se describe cómo configurar la replicación geográfica y los grupos de conmutación por error mediante las API REST, PowerShell y la CLI 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 haya cifrado con TDE mediante una clave de Azure Key Vault, las copias de seguridad generadas recientemente 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 a partir de una instancia de Azure Key Vault configurada en el nivel de base de datos, asegúrese de que el material de clave se proporciona en el servidor de destino. Se recomienda mantener todas las versiones antiguas del protector de TDE en un almacén de claves, de manera 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. Rellene previamente la lista de claves que la base de datos principal usa mediante Get-AzSqlDeletedDatabaseBackup y el parámetro -ExpandKeyList. Se recomienda pasar todas las claves que usaba la base de datos de origen, pero, como alternativa, la restauración también se puede intentar con las claves proporcionadas por la hora de 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.

Pasos siguientes

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