Compartir a través de


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

Se aplica a: Azure SQL Database Azure SQL Managed Instance Azure 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.

Vaya a Azure Portal.

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í.

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.

Captura de pantalla de la configuración de la clave de rotación automática para el cifrado de datos transparente.

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.

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.

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.

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.

    Captura de pantalla de la configuración de clave de rotación automática para el cifrado de datos transparente en un escenario de replicación geográfica en el servidor principal.

  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.

    Captura de pantalla de la configuración de clave de rotación automática para el cifrado de datos transparente en un escenario de replicación geográfica en el servidor secundario.

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

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.

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.

Captura de pantalla de la configuración de la clave de rotación manualmente para el cifrado de datos transparente.

Cambio de modo del protector de TDE

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.