Rotación del protector de Cifrado de datos transparente (TDE)

Se aplica a:Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (solo grupos de SQL dedicados)

En este artículo se describe la rotación de claves para un servidor mediante un protector de TDE de Azure Key Vault. La rotación del protector de TDE lógico para un servidor significa cambiar a una nueva clave asimétrica que protege las bases de datos en el servidor. La rotación de claves es una operación en línea y solo debería tardar unos segundos en completarse, ya que únicamente descifra y vuelve a cifrar la clave de cifrado de los datos de la base de datos, no toda la base de datos.

En este artículo se describen los métodos automatizados y manuales para rotar el protector de TDE en el servidor.

Consideraciones importantes al rotar el protector de TDE

• Cuando se cambia o rota el protector de TDE, las copias de seguridad antiguas de la base de datos, incluidas las de los archivos de registro, no se actualizan para usar el protector de TDE más reciente. Para restaurar una copia de seguridad cifrada con un protector de TDE de Key Vault, asegúrese de que el material de clave está disponible en el servidor de destino. Por lo tanto, se recomienda mantener todas las versiones antiguas del protector de TDE en el Azure Key Vault (AKV), de manera que se puedan restaurar las copias de seguridad de la base de datos.
• Incluso al cambiar de clave administrada por el cliente (CMK) a clave administrada por el servicio, mantenga todas las claves usadas anteriormente en AKV. Esto garantiza que las copias de seguridad de las bases de datos, incluidas las de los archivos de registro, se puedan restaurar con los protectores de TDE almacenados en AKV.
• Además de las copias de seguridad antiguas, los archivos de registro de transacciones también pueden requerir acceso al protector de TDE anterior. Para determinar si hay registros restantes que aún requieran la clave anterior, después de realizar la rotación de claves, use la vista de administración dinámica (DMV) sys.dm_db_log_info. Esta DMV devuelve información sobre el archivo de registro virtual (VLF) del registro de transacción junto con su huella digital de clave de cifrado del VLF.
• Las claves anteriores deben mantenerse en AKV y estar disponibles para el servidor en función del período de retención de copia de seguridad configurado como respaldo de las directivas de retención de copia de seguridad en la base de datos. Esto ayuda a garantizar que las copias de seguridad de retención a largo plazo (LTR) en el servidor todavía se puedan restaurar con las claves anteriores.

Nota:

Un grupo de SQL dedicado en pausa en Azure Synapse Analytics se debe reanudar antes de la rotación de las claves.

Este artículo se aplica a Azure SQL Database, Azure SQL Managed Instance y Azure Synapse Analytics grupos de SQL dedicados (antes conocidos como SQL DW). Para obtener documentación sobre el Cifrado de datos transparente (TDE) para grupos de SQL dedicados en áreas de trabajo de Synapse, consulte Cifrado de Azure Synapse Analytics.

Importante

No elimine las versiones anteriores de la clave después de una sustitución. Cuando las claves se sustituyen, algunos datos siguen cifrados con las claves anteriores como, por ejemplo, las copias de seguridad de base de datos más antiguas, las copias de seguridad de los archivos de registro y los archivos de registro de transacciones.

Requisitos previos

• En esta guía de procedimientos se asume que ya utiliza una clave de Azure Key Vault como protector de TDE para Azure SQL Database o Azure Synapse Analytics. Consulte Cifrado de datos transparente con compatibilidad con BYOK.
• Es preciso tener instalado y en ejecución Azure PowerShell.

Sugerencia

[Recomendado pero opcional] Cree primero el material de clave para el protector de TDE en un módulo de seguridad de hardware (HSM) o en un almacén local de claves e importe el material de clave a Azure Key Vault. Siga las instrucciones para usar un módulo de seguridad de hardware (HSM) y Key Vault para más información.

Portal

Vaya a Azure Portal.

PowerShell

Para obtener instrucciones sobre la instalación del módulo Azure PowerShell, consulte Instalación de Azure PowerShell. Para los cmdlets concretos, consulte AzureRM.Sql. Utilice el nuevo módulo Az de Azure PowerShell.

La CLI de Azure

Para la instalación, consulte Instalación de la CLI de Azure.

Rotación automática de claves

La rotación automática del protector de TDE se puede habilitar al configurar el protector de TDE para el servidor, desde Azure Portal, o bien mediante los siguientes comandos de PowerShell o la de CLI de Azure. Cuando se habilita, el servidor comprobará continuamente el almacén de claves para ver las nuevas versiones de la clave que se usan como protector de TDE. Si se detecta una versión nueva de la clave, el protector de TDE del servidor o la base de datos se rotará automáticamente a la versión de clave más reciente en un plazo de 24 horas.

La rotación automática en un servidor, una base de datos o una instancia administrada se puede usar con la rotación automática de claves en Azure Key Vault para habilitar la rotación táctil de un extremo a otro para las claves TDE.

Nota:

Si el servidor o la instancia administrada tiene configurada la replicación geográfica, antes de habilitar la rotación automática, es necesario seguir instrucciones adicionales como se describe aquí.

Portal

Mediante Azure Portal:

1. Vaya a la sección Cifrado de datos transparente para una instancia gestionada o un servidor existente.
2. Seleccione la opción Clave administrada por el cliente y seleccione el almacén de claves y la clave que se usará como protector de TDE.
3. Active la casilla Rotación automática de la clave.
4. Seleccione Guardar.

PowerShell

Para obtener instrucciones sobre la instalación del módulo Azure PowerShell, consulte Instalación de Azure PowerShell. Para los cmdlets concretos, consulte AzureRM.Sql.

Para habilitar la rotación automática para el protector de TDE mediante PowerShell, consulte el siguiente script. <keyVaultKeyId> se puede recuperar de Key Vault.

Azure SQL Database

Use el comando Set-AzSqlServerTransparentDataEncryptionProtector.

Set-AzSqlServerTransparentDataEncryptionProtector -Type AzureKeyVault -KeyId <keyVaultKeyId> `
   -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName> `
    -AutoRotationEnabled <boolean>

Instancia administrada de Azure SQL

Use el comando Set-AzSqlInstanceTransparentDataEncryptionProtector.

Set-AzSqlInstanceTransparentDataEncryptionProtector -Type AzureKeyVault -KeyId <keyVaultKeyId> `
   -InstanceName <ManagedInstanceName> -ResourceGroup <ManagedInstanceResourceGroupName> `
    -AutoRotationEnabled <boolean>

La CLI de Azure

Para obtener información sobre cómo instalar la versión actual de la CLI de Azure, vea Instalación de la CLI de Azure.

Para habilitar la rotación automática para el protector de TDE mediante la CLI de Azure, consulte el siguiente script.

Azure SQL Database

Use el comando az sql server tde-key set.

az sql server tde-key set --server-key-type AzureKeyVault
                          --auto-rotation-enabled true
                          [--kid] <keyVaultKeyId>
                          [--resource-group] <SQLDatabaseResourceGroupName> 
                          [--server] <logicalServerName>

Instancia administrada de Azure SQL

Use el comando az sql mi tde-key set.

az sql mi tde-key set --server-key-type AzureKeyVault
                      --auto-rotation-enabled true
                      [--kid] <keyVaultKeyId>
                      [--resource-group] <ManagedInstanceGroupName> 
                      [--managed-instance] <ManagedInstanceName>

Rotación automática de claves en el nivel de base de datos

La rotación automática de claves también se puede habilitar en el nivel de base de datos de Azure SQL Database. Esto resulta útil cuando se quiere habilitar la rotación automática de claves para una sola base de datos, o un subconjunto de ellas, en un servidor. Para más información, consulte Administración de identidades y claves para TDE con claves administradas por el cliente en el nivel de base de datos.

Portal

Para obtener información sobre cómo configurar la rotación automática de claves en el nivel de base de datos en Azure Portal, vea Actualización de una instancia de Azure SQL Database existente con claves administradas por el cliente en el nivel de base de datos.

PowerShell

A fin de habilitar la rotación automática para el protector de TDE en el nivel de base de datos mediante PowerShell, vea el comando siguiente. Use el parámetro -EncryptionProtectorAutoRotation y establézcalo en $true para habilitar la rotación automática de claves, o bien en $false para deshabilitarla.

Set-AzSqlDatabase -ResourceGroupName <resource_group_name> -ServerName <server_name> -DatabaseName <database_name> -EncryptionProtectorAutoRotation:$true

La CLI de Azure

A fin de habilitar la rotación automática para el protector de TDE en el nivel de base de datos mediante la CLI de Azure, vea el comando siguiente. Use el parámetro --encryption-protector-auto-rotation y establézcalo en True para habilitar la rotación automática de claves, o bien en False para deshabilitarla.

az sql db update --resource-group <resource_group_name> --server <server_name> --name <database_name> --encryption-protector-auto-rotation True

Rotación automática de claves para configuraciones de replicación geográfica

En una configuración de replicación geográfica de Azure SQL Database donde el servidor principal está establecido para usar TDE con CMK, el servidor secundario también debe configurarse para habilitar TDE con CMK con la misma clave usada en el principal.

Portal

Mediante Azure Portal:

1. Vaya a la sección Cifrado de datos transparente para el servidor principal.

2. Seleccione la opción Clave administrada por el cliente y seleccione el almacén de claves y la clave que se usará como protector de TDE.

3. Active la casilla Rotación automática de la clave.

4. Seleccione Guardar.

   

5. Vaya a la sección Cifrado de datos transparente para el servidor secundario.

6. Seleccione la opción Clave administrada por el cliente y seleccione el almacén de claves y la clave que se usará como protector de TDE. Use la misma clave que usó para el servidor principal.

7. Desactive Hacer que esta clave sea el protector de TDE predeterminado.

8. Seleccione Guardar.

   

Cuando se ejecuta la rotación de clave en el servidor principal, se transfiere automáticamente al servidor secundario.

PowerShell

<keyVaultKeyId> se puede recuperar de Key Vault.

1. Use el comando Add-AzSqlServerKeyVaultKey para agregar una nueva clave al servidor secundario.

   # add the key from Key Vault to the secondary server
   Add-AzSqlServerKeyVaultKey -KeyId <keyVaultKeyId> -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName>
   

2. Agregue la misma clave que agregó en el primer paso al servidor principal.

   # add the key from Key Vault to the primary server
   Add-AzSqlServerKeyVaultKey -KeyId <keyVaultKeyId> -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName>
   

3. Use Set-AzSqlInstanceTransparentDataEncryptionProtector para establecer la clave como el protector principal en el servidor principal con la rotación de clave automática establecida en true.

   Set-AzSqlServerTransparentDataEncryptionProtector -Type AzureKeyVault -KeyId <keyVaultKeyId> `
    -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName> `
    -AutoRotationEnabled $true
   

4. Rote la clave de almacén de claves en Key Vault con el comando Get-AzKeyVaultKey y Set-AzKeyVaultKeyRotationPolicy.

   Get-AzKeyVaultKey -VaultName <keyVaultName> -Name <keyVaultKeyName> | Set-AzKeyVaultKeyRotationPolicy -KeyRotationLifetimeAction @{Action = "Rotate"; TimeBeforeExpiry = "P18M"} 
   

5. Compruebe si el SQL Server (principal y secundario) tiene la nueva clave o la versión de la clave:

   Nota:

   La rotación de claves puede tardar hasta una hora en aplicarse en el servidor. Espere al menos una hora antes de ejecutar este comando.

   Get-AzSqlServerKeyVaultKey -KeyId <keyVaultKeyId> -ServerName <logicalServerName> -ResourceGroupName <SQLDatabaseResourceGroupName> 
   

Use claves diferentes para cada servidor

Es posible configurar los servidores principales y secundarios con una clave de almacén de claves diferente cuando se configura TDE con CMK en Azure Portal. No es evidente en Azure Portal que la clave usada para proteger el servidor principal también es la misma clave que protege la base de datos principal que se ha replicado en el servidor secundario. Sin embargo, puede usar PowerShell, la CLI de Azure o las API REST para obtener detalles sobre las claves que se usan en el servidor. De esta forma, puede ver que las claves rotadas automáticamente se transfieren del servidor principal al servidor secundario.

Este es un ejemplo del uso de comandos de PowerShell para comprobar las claves que se transfieren desde el servidor principal al servidor secundario después de la rotación de claves.

1. Ejecute el siguiente comando en el servidor principal para mostrar los detalles de clave de un servidor:

   Get-AzSqlServerKeyVaultKey -ServerName <logicalServerName> -ResourceGroupName <SQLDatabaseResourceGroupName> 
   

2. Se mostrarán resultados similares a los siguientes:

   ResourceGroupName : <SQLDatabaseResourceGroupName> 
   ServerName        : <logicalServerName> 
   ServerKeyName     : <keyVaultKeyName> 
   Type              : AzureKeyVault 
   Uri               : https://<keyvaultname>.vault.azure.net/keys/<keyName>/<GUID> 
   Thumbprint        : <thumbprint> 
   CreationDate      : 12/13/2022 8:56:32 PM
   

3. Ejecute el mismo comando Get-AzSqlServerKeyVaultKey en el servidor secundario:

   Get-AzSqlServerKeyVaultKey -ServerName <logicalServerName> -ResourceGroupName <SQLDatabaseResourceGroupName> 
   

4. Si el servidor secundario tiene un protector de TDE predeterminado que usa una clave distinta del servidor principal, debería ver dos claves (o más). La primera clave es el protector de TDE predeterminado y la segunda es la clave que se usa en el servidor principal para proteger la base de datos replicada.

5. Cuando se ejecuta la rotación de clave en el servidor principal, se transfiere automáticamente al servidor secundario. Si vuelve a ejecutar Get-AzSqlServerKeyVaultKey en el servidor principal, debería ver dos claves. La primera es la clave original y la segunda es la clave actual que se ha generado como parte de la rotación de claves.

6. La ejecución del comando Get-AzSqlServerKeyVaultKey en el servidor secundario también debe mostrar las mismas claves que están presentes en el servidor principal. Esto confirma que las claves rotadas en el servidor principal se transfieren automáticamente al servidor secundario y se usan para proteger la réplica de base de datos.

Rotación manual de claves

La rotación de claves manual usa los siguientes comandos para agregar una clave nueva, que podría estar en un nuevo nombre de clave o incluso en otro almacén de claves. Usar este enfoque permite agregar la misma clave a distintos almacenes de claves para admitir escenarios de alta disponibilidad y recuperación ante desastres geográfica. También se puede realizar la rotación manual de claves mediante el Azure Portal.

Con la rotación manual de claves, cuando se genera una nueva versión de clave en el almacén de claves (ya sea manualmente o a través de la directiva de rotación automática de claves en el almacén de claves), se debe establecer manualmente la misma como protector TDE en el servidor.

Nota:

La longitud combinada para el nombre del almacén de claves y el nombre de la clave no puede superar los 94 caracteres.

Portal

Con Azure Portal:

1. Vaya al menú Cifrado de datos transparente para una instancia gestionada o un servidor existente.
2. Seleccione la opción Clave administrada por el cliente y seleccione el almacén de claves y la clave que se usará como nuevo protector de TDE.
3. Seleccione Guardar.

PowerShell

Use el comando Add-AzKeyVaultKey para agregar una nueva clave al almacén de claves.

# add a new key to Key Vault
Add-AzKeyVaultKey -VaultName <keyVaultName> -Name <keyVaultKeyName> -Destination <hardwareOrSoftware>

Para Azure SQL Database, use:

• Add-AzSqlServerKeyVaultKey
• Set-AzSqlServerTransparentDataEncryptionProtector

# add the new key from Key Vault to the server
Add-AzSqlServerKeyVaultKey -KeyId <keyVaultKeyId> -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName>
  
# set the key as the TDE protector for all resources under the server
Set-AzSqlServerTransparentDataEncryptionProtector -Type AzureKeyVault -KeyId <keyVaultKeyId> `
   -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName>

Para Azure SQL Managed Instance, use:

• Add-AzSqlInstanceKeyVaultKey
• Set-AzSqlInstanceTransparentDataEncryptionProtector

# add the new key from Key Vault to the managed instance
Add-AzSqlInstanceKeyVaultKey -KeyId <keyVaultKeyId> -InstanceName <ManagedInstanceName> -ResourceGroup <ManagedInstanceResourceGroupName>
  
# set the key as the TDE protector for all resources under the managed instance
Set-AzSqlInstanceTransparentDataEncryptionProtector -Type AzureKeyVault -KeyId <keyVaultKeyId> `
   -InstanceName <ManagedInstanceName> -ResourceGroup <ManagedInstanceResourceGroupName>

La CLI de Azure

Use el comando az keyvault key create para agregar una nueva clave al almacén de claves.

# add a new key to Key Vault
az keyvault key create --name <keyVaultKeyName> --vault-name <keyVaultName> --protection <hsmOrSoftware>

Para Azure SQL Database, use:

• az sql server key create
• az sql server tde-key set

# add the new key from Key Vault to the server
az sql server key create --kid <keyVaultKeyId> --resource-group <SQLDatabaseResourceGroupName> --server <logicalServerName>

# set the key as the TDE protector for all resources under the server
az sql server tde-key set --server-key-type AzureKeyVault --kid <keyVaultKeyId> --resource-group <SQLDatabaseResourceGroupName> --server <logicalServerName>

Para Azure SQL Managed Instance, use:

• az sql mi key create
• az sql mi tde-key set

# add the new key from Key Vault to the managed instance
az sql mi key create --kid <keyVaultKeyId> --resource-group <Managed InstanceResourceGroupName> --managed-instance <ManagedInstanceName>

# set the key as the TDE protector for all resources under the managed instance
az sql mi tde-key set --server-key-type AzureKeyVault --kid <keyVaultKeyId> --resource-group <ManagedInstanceResourceGroupName> --managed-instance <ManagedInstanceName>

Cambio de modo del protector de TDE

Portal

Uso del Azure Portal para cambiar el protector de TDE del modo administrado de Microsoft a BYOK:

1. Vaya al menú Cifrado de datos transparente para una instancia gestionada o un servidor existente.
2. Seleccione la opción Claves administradas de cliente.
3. Seleccione el almacén de claves y la clave que se van a usar como protector de TDE.
4. Seleccione Guardar.

PowerShell

Azure SQL Database

• Para cambiar el protector de TDE del modo administrado por Microsoft a BYOK, use el comando Set-AzSqlServerTransparentDataEncryptionProtector.

  Set-AzSqlServerTransparentDataEncryptionProtector -Type AzureKeyVault `
       -KeyId <keyVaultKeyId> -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName>
  

• Para cambiar el protector de TDE del modo BYOK al administrado por Microsoft, use el comando Set-AzSqlServerTransparentDataEncryptionProtector.

  Set-AzSqlServerTransparentDataEncryptionProtector -Type ServiceManaged `
       -ServerName <logicalServerName> -ResourceGroup <SQLDatabaseResourceGroupName>
  

Instancia administrada de Azure SQL

• Para cambiar el protector de TDE del modo administrado por Microsoft a BYOK, use el comando Set-AzSqlInstanceTransparentDataEncryptionProtector.

  Set-AzSqlServerTransparentDataEncryptionProtector -Type AzureKeyVault `
       -KeyId <keyVaultKeyId> <ManagedInstanceName> -ResourceGroup <ManagedInstanceResourceGroupName>
  

• Para cambiar el protector de TDE del modo BYOK al administrado por Microsoft, use el comando Set-AzSqlInstanceTransparentDataEncryptionProtector.

  Set-AzSqlServerTransparentDataEncryptionProtector -Type ServiceManaged `
       -InstanceName <ManagedInstanceName> -ResourceGroup <ManagedInstanceResourceGroupName>e>
  

La CLI de Azure

Azure SQL Database

En los ejemplos siguientes se usa az sql server tde-key set.

• Para cambiar el protector de TDE del modo administrado de Microsoft a BYOK:

  az sql server tde-key set --server-key-type AzureKeyVault --kid <keyVaultKeyId> --resource-group <SQLDatabaseResourceGroupName> --server <logicalServerName>
  

• Para cambiar el protector de TDE del modo BYOK a administrado por Microsoft:

  az sql server tde-key set --server-key-type ServiceManaged --resource-group <SQLDatabaseResourceGroupName> --server <logicalServerName>
  

Instancia administrada de Azure SQL

En los ejemplos siguientes se usa az sql mi tde-key set.

• Para cambiar el protector de TDE del modo administrado de Microsoft a BYOK:

  az sql mi tde-key set --server-key-type AzureKeyVault --kid <keyVaultKeyId> --resource-group <ManagedInstanceResourceGroupName> --managed-instance <ManagedInstanceName>
  

• Para cambiar el protector de TDE del modo BYOK a administrado por Microsoft:

  az sql mi tde-key set --server-key-type ServiceManaged --resource-group <ManagedInstanceResourceGroupName> --managed-instance <ManagedInstanceName>
  

Contenido relacionado

• Si hay un riesgo de seguridad, aprenda a quitar un protector de TDE potencialmente comprometido: Eliminación de una clave potencialmente comprometida.

• Introducción a la integración de Azure Key Vault y compatibilidad con Bring Your Own Key para TDE: Habilitación de TDE con su propia clave de Key Vault mediante PowerShell.