Compartir por

Cifrado de datos transparente de Azure SQL con una clave administrada por el cliente

  • Artigo

Se aplica a: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics (solo grupos de SQL dedicados)

El cifrado de datos transparente (TDE) de Azure SQL con una clave administrada por el cliente (CMK) habilita el escenario Bring Your Own Key (BYOK) para la protección de datos en reposo y permite a las organizaciones implementar la separación de tareas en la administración de claves y datos. Con TDE administrado por el cliente, este es responsable y tiene el control total de la administración del ciclo de vida de las claves (creación de claves, carga, rotación, eliminación), de los permisos de uso de claves y de la auditoría de operaciones sobre las claves.

En este escenario, la clave que se usa para el cifrado de la clave de cifrado de base de datos (DEK), denominada protector de TDE, es una clave asimétrica administrada por el cliente que se almacena en una instancia propiedad del cliente y administrada por él de Azure Key Vault (AKV), un sistema de administración de claves externas basado en la nube. Key Vault ofrece un almacenamiento seguro de alta disponibilidad y escalabilidad para claves criptográficas RSA respaldado opcionalmente por módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 nivel 2. No permite el acceso directo a una clave almacenada, sino que proporciona servicios de cifrado y descifrado mediante el uso de la clave en las entidades autorizadas. La clave se puede generar mediante el almacén de claves, importar o transferir al almacen de claves desde un dispositivo HSM local.

En Azure SQL Database y Azure Synapse Analytics, el protector de TDE se establece en el nivel de servidor y todas las bases de datos cifradas asociadas a dicho servidor lo heredan. En el caso de la Instancia administrada de Azure SQL Database, el protector de TDE se establece en el nivel de instancia y lo heredan todas las bases de datos cifradas que se encuentren en dicha instancia. A menos que se indique lo contrario, a lo largo de este documento el término servidor hace referencia tanto a un servidor en SQL Database y Azure Synapse, como a una instancia administrada en Instancia administrada de SQL.

La administración del protector de TDE en el nivel de base de datos en Azure SQL Database está disponible. Para más información, consulte Cifrado de datos transparente (TDE) con claves administradas por el cliente en el nivel de base de datos.

Nota

  • 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 para grupos de SQL dedicados en áreas de trabajo de Synapse, consulte Cifrado de Azure Synapse Analytics.
  • Para proporcionar a los clientes de Azure SQL dos capas de cifrado de datos en reposo, se está implementando el cifrado de infraestructura (mediante el algoritmo de cifrado AES-256) con claves administradas por la plataforma. Esto proporciona una capa adicional de cifrado en reposo junto con TDE con claves administradas por el cliente, que ya está disponible. En Azure SQL Database y Azure SQL Managed Instance, todas las bases de datos, incluida la base de datos master y otras bases de datos del sistema, se cifrarán cuando se active el cifrado de infraestructura. En este momento, los clientes deben solicitar el acceso a esta funcionalidad. Si está interesado en esta funcionalidad, póngase en contacto con AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Nota:

Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).

Ventajas del TDE administrado por el cliente

El Cifrado de datos transparente (TDE) administrado por el cliente le proporciona las siguientes ventajas:

  • Control completo y pormenorizado del uso y de la administración del protector de TDE.

  • Transparencia del uso del protector de TDE.

  • Capacidad de implementar la separación de tareas para la administración de claves y datos en la organización.

  • El administrador de Key Vault puede revocar los permisos de acceso de las claves para hacer que la base de datos cifrada sea inaccesible.

  • Administración central de claves en AKV.

  • Mayor confianza de los clientes finales, ya que AKV está diseñado de forma que Microsoft no puede ver ni extraer claves de cifrado;

Importante

Para aquellos que usan TDE administrado por el servicio y que quieren empezar a usar TDE administrado por el cliente, los datos permanecen cifrados durante el proceso de cambio y no hay tiempo de inactividad ni se vuelven a cifrar los archivos de la base de datos. El cambio de una clave administrada por el servicio a una clave administrada por el cliente solo requiere el nuevo cifrado de la DEK, que es una operación rápida y en línea.

Funcionamiento del TDE administrado por el cliente

Diagrama que muestra la configuración y funcionamiento del TDE administrado por el cliente.

Para que el servidor lógico de Azure usa el protector TDE almacenado en AKV para el cifrado de la DEK, el administrador del almacén de claves debe asignar derechos de acceso al servidor con su identidad única de Microsoft Entra. Hay dos modelos de acceso para conceder al servidor acceso al almacén de claves:

  • Control de acceso basado en rol (RBAC) de Azure: usa RBAC de Azure para conceder acceso de usuario, grupo o aplicación al almacén de claves. Este método se recomienda por su flexibilidad y granularidad. La identidad del servidor necesita el rol de usuario de cifrado de servicio criptográfico de Key Vault a fin de poder usar la clave para las operaciones de cifrado y descifrado.

  • Directiva de acceso del almacén: usa la directiva de acceso del almacén de claves para conceder al servidor acceso al almacén de claves. Este método es más sencillo y directo, pero menos flexible. La identidad del servidor debe tener los permisos siguientes en el almacén de claves:

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

En la pestaña Configuración de acceso del menú de Azure Portal, tienes la opción de seleccionar el control de acceso basado en roles de Azure o la directiva de acceso del almacén. Para obtener instrucciones paso a paso sobre cómo configurar una configuración de acceso de Azure Key Vault para TDE, consulta Configuración de Administración extensible de claves de TDE de SQL Server mediante Azure Key Vault. Para obtener más información sobre los modelos de acceso, consulta Seguridad de Azure Key Vault.

Un administrador de Key Vault también puede habilitar el registro de eventos de auditoría, por lo que se pueden auditar más adelante.

Cuando se configura el servidor para usar un protector de TDE de AKV, el servidor envía la DEK de cada base de datos habilitada para TDE al almacén de claves para su cifrado. Key Vault devuelve la DEK cifrada, la cual se almacena en la base de datos del usuario.

Cuando es necesario, el servidor envía la DEK protegida al almacén de claves para que se descifre.

Los auditores pueden usar Azure Monitor para revisar los registros de los objetos AuditEvent del almacén de claves, si está habilitado el registro.

Nota:

Los cambios de permisos pueden tardar unos 10 minutos en surtir efecto en el almacén de claves. Esto incluye revocar los permisos de acceso al protector de TDE en AKV; los usuarios dentro de este período de tiempo pueden seguir teniendo permisos de acceso.

Requisitos de configuración de TDE administrado por el cliente

Requisitos de configuración de AKV

  • Las características de eliminación temporal y protección contra purga deben estar habilitadas en el almacén de claves para obtener protección contra la pérdida de datos en caso de que se eliminen las claves (o el almacén de claves) de manera involuntaria.

  • Conceda al servidor o a la instancia administrada acceso al almacén de claves (get, wrapKey, unwrapKey) con su identidad de Microsoft Entra. La identidad del servidor puede ser una identidad administrada asignada por el sistema o una identidad administrada asignada por el usuario asignada al servidor. Al usar Azure Portal, la identidad de Microsoft Entra se crea automáticamente cuando se crea el servidor. Al usar PowerShell o la CLI de Azure, se debe crear explícitamente la identidad de Microsoft Entra y se debe comprobar. Consulte Configuración de TDE con BYOK y Configuración de TDE con BYOK para SQL Managed Instance para obtener instrucciones detalladas paso a paso cuando se usa PowerShell.

    • 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 creando una directiva de acceso en el almacén de claves o creando una nueva asignación de roles RBAC de Azure con el rol Usuario de cifrado de servicio criptográfico de Key Vault.

  • Al usar un firewall con AKV, debe habilitar la opción Permitir que los servicios Microsoft de confianza omitan el firewall, a menos que use puntos de conexión privados para AKV. Para más información, vea Configuración de firewalls y redes virtuales de Azure Key Vault.

Habilitación de la eliminación temporal y la protección contra purga para AKV

Importante

Tanto la eliminación temporal como la protección contra purga deben estar habilitadas en el almacén de claves al configurar TDE administrado por el cliente en un servidor o una instancia administrada nuevos o existentes.

La eliminación temporal y la protección contra purga son características importantes de Azure Key Vault que permiten la recuperación de almacenes eliminados y objetos eliminados del almacén de claves, lo que reduce el riesgo de que un usuario elimine accidental o malintencionadamente una clave o un almacén de claves.

  • Los recursos eliminados temporalmente se conservan durante 90 días, a menos que el cliente los recupere o los purgue. Las acciones de recuperación y purga tienen permisos propios asociados a una directiva de acceso al almacén de claves. La característica de eliminación temporal está activada de manera predeterminada para los nuevos almacenes de claves y también se puede habilitar mediante Azure Portal, PowerShell o la CLI de Azure.

  • La protección de purga se puede activar mediante la CLI de Azure o con PowerShell. Cuando la protección de purgas está activada, un almacén o un objeto en estado eliminado no se pueden purgar hasta que haya transcurrido el período de retención. El período de retención predeterminado es de 90 días, pero se puede configurar de 7 a 90 días en Azure Portal.

  • Azure SQL requiere que la eliminación temporal y la protección contra purga estén habilitadas en el almacén de claves que contiene la clave de cifrado que se usa como protector de TDE para el servidor o la instancia administrada. Esto ayuda a evitar el escenario de eliminación accidental o malintencionada de claves, que puede llevar a que la base de datos entre en estado Inaccesible.

  • Al configurar el protector de TDE en un servidor existente o durante la creación del servidor, Azure SQL valida que el almacén de claves que se usa tenga activada la eliminación temporal y la protección contra purga. Si la eliminación temporal y la protección contra purga no están habilitadas en el almacén de claves, se produce un error en la configuración del protector de TDE. En este caso, primero se deben habilitar la eliminación temporal y la protección contra purga en el almacén de claves y, después, se debe realizar la configuración del protector de TDE.

Requisitos para configurar el protector de TDE

  • El protector TDE solo puede ser una clave asimétrica, RSA o RSA HSM. Las longitudes de clave admitidas son 2048 y 3072 bits.

  • La fecha de activación de la clave (si se establece) debe ser una fecha y hora del pasado. La fecha de expiración (si se establece) debe ser una fecha y hora del futuro.

  • El estado de la clave debe ser Habilitada.

  • Si va a importar la clave existente al almacén de claves, asegúrese de proporcionarla en los formatos de archivo admitidos (.pfx, .byok o .backup).

Nota:

Azure SQL y SQL Server en una máquina virtual de Azure admite el uso de una clave RSA almacenada en un HSM administrado como protector de TDE. HSM administrado de Azure Key Vault es un servicio en la nube totalmente administrado, de alta disponibilidad y de un solo inquilino que cumple los estándares y que le permite proteger las claves criptográficas de las aplicaciones en la nube mediante HSM validados de FIPS 140-2, nivel 3. Obtenga más información sobre los HSM administrados y la configuración o los permisos de RBAC necesarios para SQL Server mediante el artículo Configuración de la administración extensible de claves de TDE de SQL Server mediante Azure Key Vault.

Un problema con las versiones de Thales CipherTrust Manager anteriores a la versión 2.8.0 impide que las claves recién importadas en Azure Key Vault se usen con Azure SQL Database o Azure SQL Managed Instance para escenarios de TDE administrados por el cliente. Aquí puede encontrar más detalles sobre este problema. En estos casos, espere 24 horas después de importar la clave en el almacén de claves para empezar a usarla como protector de TDE para el servidor o la instancia administrada. Este problema se ha resuelto en Thales CipherTrust Manager 2.8.0.

Recomendaciones para la configuración de TDE administrado por el cliente

Recomendaciones para la configuración de AKV

  • Asocie como máximo un total de 500 bases de datos de uso general o 200 bases de datos críticas para la empresa mediante un almacén de claves y en una sola suscripción; de este modo, garantizará una alta disponibilidad cuando el servidor acceda al protector de TDE en el almacén de claves. Estas cifras se basan en la experiencia y están documentadas en los límites de servicio para Azure Key Vault. El objetivo es evitar problemas después de la conmutación por error del servidor, ya que desencadenará tantas operaciones de clave en el almacén como bases de datos haya en ese servidor.

  • Configure un bloqueo de recursos en el almacén de claves para controlar quién puede eliminar este recurso crítico y para evitar la eliminación accidental o no autorizada. Obtenga más información acerca de los bloqueos de recursos.

  • Habilite la auditoría y la generación de informes en todas las claves de cifrado: El almacén de claves proporciona registros que son fáciles de insertar en otras herramientas de administración de eventos e información de seguridad. Log Analytics de Operations Management Suite es un ejemplo de un servicio que ya está integrado.

  • Vincule cada servidor con dos almacenes de claves que residan en regiones diferentes y que conserven el mismo material de clave para garantizar una alta disponibilidad de bases de datos cifradas. Marque la clave de uno de los almacenes de claves como protector de TDE. El sistema cambia automáticamente al almacén de claves de la segunda región con el mismo material de clave, si hay una interrupción que afecta al almacén de claves de la primera región.

Nota:

Para permitir una mayor flexibilidad en la configuración del TDE administrado por el cliente, Azure SQL Database Azure SQL Managed Instance en una región ahora se pueden vincular al almacén de claves de cualquier otra región. El servidor y el almacén de claves no tienen que estar ubicados en la misma región.

Recomendaciones para la configuración del protector de TDE

  • Almacene una copia del protector de TDE en un lugar seguro o en el servicio de custodia.

  • Si la clave se genera en el almacén de claves, cree una copia de seguridad de esta antes de usarla en AKV por primera vez. La copia de seguridad solo se puede restaurar en Azure Key Vault. Obtenga más información sobre el comando Backup-AzKeyVaultKey.

  • Cree una nueva copia de seguridad cada vez que se realicen cambios en la clave (por ejemplo, atributos de clave, etiquetas o ACL).

  • Mantenga versiones anteriores de la clave en el almacén de claves al rotar las claves, de manera que se puedan restaurar las copias de seguridad de bases de datos más antiguas. Cuando se cambia el protector de TDE para una base de datos, las copias de seguridad antiguas de la base de datos no se actualizan para usar el protector de TDE más reciente. En el momento de la restauración, cada copia de seguridad necesita el protector de TDE con el que se cifró durante su creación. Las rotaciones de claves se pueden realizar según las instrucciones de Rotate the Transparent Data Encryption Protector Using PowerShell (Rotación del protector de cifrado de datos transparente mediante PowerShell).

  • Guarde todas las claves usadas previamente en AKV incluso después de cambiar a claves administradas por el servicio. Esto garantiza que las copias de seguridad de las bases de datos se puedan restaurar con los protectores de TDE almacenados en AKV. Los protectores de TDE creados con Azure Key Vault deben conservarse hasta que se hayan creado todas las copias de seguridad almacenadas restantes con claves administradas por el servicio. Realice copias de seguridad recuperables de estas claves mediante Backup-AzKeyVaultKey.

  • Para quitar una clave potencialmente en peligro durante un incidente de seguridad sin el riesgo de pérdida de datos, siga los pasos descritos en Eliminación de una clave potencialmente en peligro.

Rotación del protector de TDE

La rotación del protector de TDE 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. La operación solo descifra y vuelve a cifrar la clave de cifrado de la base de datos, no toda la base de datos.

La rotación del protector de TDE se puede realizar manualmente o mediante la característica de rotación automatizada.

La rotación automatizada del protector de TDE se puede habilitar al configurar el protector de TDE para el servidor. La rotación automática está desactivada de manera predeterminada. 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.

Cuando se usa con la rotación automática de claves en Azure Key Vault, esta característica permite la rotación de cero toques de un extremo a otro para el protector de TDE en Azure SQL Database y Azure SQL Managed Instance.

Nota:

Establecer TDE con CMK mediante la rotación manual o automatizada de claves siempre usará la versión más reciente de la clave compatible. La configuración no permite usar una versión anterior o inferior de las claves. El uso de la versión de clave más reciente cumple con la directiva de seguridad de Azure SQL que no permite versiones de clave anteriores que puedan verse en peligro. Las versiones anteriores de la clave pueden ser necesarias para fines de backup o restauración de base de datos, especialmente en caso de copias de seguridad de retención a largo plazo, donde se deben conservar las versiones de clave anteriores. Para las configuraciones de replicación geográfica, todas las claves necesarias para el servidor de origen deben estar presentes en el servidor de destino.

Consideraciones de replicación geográfica al configurar la rotación automatizada del protector de TDE

Para evitar problemas al establecer o durante la replicación geográfica, cuando la rotación automática del protector de TDE está habilitada en el servidor principal o secundario, es importante seguir estas reglas al configurar la replicación geográfica:

  • Tanto los servidores primarios como los secundarios deben tener permisos Get, wrapKey y unwrapKey en el almacén de claves del servidor principal (almacén de claves que contiene la clave de protector de TDE del servidor principal).

  • Para un servidor con la rotación automatizada de claves habilitada, antes de iniciar la replicación geográfica, agregue la clave de cifrado que se usa como protector de TDE en el servidor principal al servidor secundario. El servidor secundario requiere acceso a la clave del mismo almacén de claves que se usa con el servidor principal (y no a otra clave con el mismo material de clave). Como alternativa, antes de iniciar la replicación geográfica, asegúrese de que la identidad administrada del servidor secundario (asignada por el usuario o asignada por el sistema) tenga permisos necesarios en el almacén de claves del servidor principal y el sistema intentará agregar la clave al servidor secundario.

  • Para una configuración de replicación geográfica existente, antes de habilitar la rotación automatizada de claves en el servidor principal, agregue la clave de cifrado que se usa como protector de TDE en el servidor principal al servidor secundario. El servidor secundario requiere acceso a la clave del mismo almacén de claves que se usa con el servidor principal (y no a otra clave con el mismo material de clave). Como alternativa, antes de habilitar la clave automatizada, asegúrese de que la identidad administrada del servidor secundario (asignada por el usuario o asignada por el sistema) tenga permisos necesarios en el almacén de claves del servidor principal y el sistema intentará agregar la clave al servidor secundario.

  • Se admiten escenarios de replicación geográfica utilizando claves administradas por el cliente (CMK) para TDE. TDE con rotación automática de claves debe configurarse en todos los servidores si está configurando TDE en Azure Portal. Para obtener más información sobre cómo configurar la rotación automática de claves para configuraciones de replicación geográfica con TDE, consulte Rotación automática de claves para configuraciones de replicación geográfica.

Protector de TDE inaccesible

Cuando TDE está configurado para usar una clave administrada por el cliente, se requiere acceso continuo al protector TDE para que la base de datos permanezca en línea. Si el servidor pierde el acceso al protector de TDE administrado por el cliente en AKV, pasados máximo 10 minutos, una base de datos empieza a denegar todas las conexiones con el mensaje de error correspondiente y cambia su estado a Inaccesible. La única acción que se puede realizar en una base de datos con el estado Inaccesible es eliminarla.

Nota:

Si no se puede acceder a la base de datos debido a una interrupción intermitente de la red, no se requiere ninguna acción y las bases de datos se volverán a conectar automáticamente.

Una vez restaurado el acceso a la clave, se necesita tiempo para volver a poner en línea la base de datos y se deben realizar pasos adicionales, los cuales pueden variar en función del tiempo transcurrido sin tener acceso a la clave y según el tamaño de los datos de la base de datos:

Nota:

  • Si se restaura el acceso a la clave en un plazo de 30 minutos, la base de datos se recuperará automáticamente durante la próxima hora.
  • Si el acceso a la clave se restaura después de más de 30 minutos, no es posible la recuperación automática de la base de datos. Recuperar la base de datos requiere realizar pasos adicionales en Azure Portal y puede llevar una cantidad considerable de tiempo en función del tamaño de la base de datos.
  • Una vez que la base de datos vuelva a estar en línea, las opciones de nivel de servidor configuradas previamente que pueden incluir la configuración del grupo de conmutación por error, las etiquetas y la configuración de nivel de base de datos, como la configuración de grupos elásticos, la escala de lectura, la pausa automática, el historial de restauración a un momento dado, la directiva de retención a largo plazo y otras se perderán. Por lo tanto, se recomienda que los clientes implementen un sistema de notificaciones que identifique la pérdida de acceso a la clave de cifrado en un plazo de 30 minutos. Una vez que haya expirado la ventana de 30 minutos, se recomienda validar toda la configuración de nivel de servidor y de base de datos en la base de datos recuperada.

A continuación se muestra una vista de los pasos adicionales necesarios en el portal para volver a poner en línea una base de datos que no está accesible.

Base de datos de TDE BYOK que no está accesible.

Revocación accidental del acceso al protector de TDE

Podría suceder que alguien con derechos de acceso suficientes para el almacén de claves deshabilitara por accidente el acceso del servidor a la clave de la siguiente forma:

  • Revocación de los permisos get, wrapKey o unwrapKey del almacén de claves desde el servidor.

  • Eliminar la clave.

  • Eliminar el almacén de claves.

  • Cambio de las reglas de firewall del almacén de claves.

  • Eliminar la identidad administrada del servidor en Microsoft Entra ID

Obtenga más información sobre los errores comunes que hacen que las bases de datos dejen de estar accesibles.

Conectividad bloqueada entre SQL Managed Instance y Key Vault

En SQL Managed Instance, es posible que los errores de red al intentar acceder al protector de TDE en Azure Key Vault no provoquen que las bases de datos cambien su estado a Inaccesible, pero la instancia dejará de estar disponible posteriormente. Esto sucede principalmente cuando existe el recurso del almacén de claves, pero no se puede acceder al punto de conexión desde la instancia administrada. Todos los escenarios en los que se puede alcanzar el punto de conexión del almacén de claves, pero se deniega la conexión, faltan permisos, etc., hará que las bases de datos cambien su estado a Inaccesible.

Las causas más comunes de la falta de conectividad de red a Key Vault son:

  • Key Vault se expone a través del punto de conexión privado y la dirección IP privada del servicio AKV no se permite en las reglas de salida del grupo de seguridad de red (NSG) asociado a la subred de la instancia administrada.
  • Resolución DNS incorrecta, como cuando el FQDN del almacén de claves no se resuelve o se resuelve en una dirección IP no válida.

Pruebe la conectividad de SQL Managed Instance a la Key Vault que hospeda el protector de TDE.

  • El punto de conexión es el FQDN del almacén, como <vault_name.vault.azure.net> (sin el https://).
  • El puerto que se va a probar es 443.
  • El resultado de RemoteAddress debe existir y ser la dirección IP correcta.
  • El resultado de la prueba TCP debe ser TcpTestSucceeded: True.

En caso de que la prueba devuelva TcpTestSucceeded: False, revise la configuración de red:

  • Compruebe la dirección IP resuelta y confirme que es válida. Un valor que falta significa que hay problemas con la resolución DNS.
    • Confirme que el grupo de seguridad de red de la instancia administrada tiene una regla de salida que cubre la dirección IP resuelta en el puerto 443, especialmente cuando la dirección resuelta pertenece al punto de conexión privado del almacén de claves.
    • Compruebe otras configuraciones de red, como la tabla de rutas, la existencia de la aplicación virtual y su configuración, etc.

Supervisión del TDE administrado por el cliente

Para supervisar el estado de la base de datos y habilitar las alertas para la pérdida de acceso al protector de TDE, configure las siguientes características de Azure:

  • Azure Resource Health. Una base de datos inaccesible que haya perdido el acceso al protector de TDE aparecerá como "No disponible" después de que se haya denegado la primera conexión a la base de datos.
  • Registro de actividad cuando se produce un error de acceso al protector de TDE en el almacén de claves administrado por el cliente, las entradas se agregan al registro de actividad. La creación de alertas para estos eventos permite restablecer el acceso lo antes posible.
  • Los grupos de acciones se pueden definir para que envíen notificaciones y alertas en función de las preferencias, por ejemplo, Correo electrónico/SMS/Inserción/Voz, aplicación lógica, webhook, ITSM o Runbook de Automation.

Realización de copias de seguridad y restauración de bases de datos con TDE administrado por el cliente

Una vez que una base de datos se haya cifrado con TDE mediante una clave de Key Vault, las nuevas copias de seguridad 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 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 almacén de claves, de manera que se puedan restaurar las copias de seguridad de la base de datos.

Importante

Nunca puede haber más de un protector de TDE establecido para un servidor. Es la clave marcada con "Hacer que la clave seleccionada sea el protector de TDE predeterminado" en el panel de Azure Portal. Sin embargo, se pueden vincular varias claves adicionales a un servidor sin marcarlas como protector de TDE. Estas claves no se usan para proteger la DEK, pero se pueden usar durante la restauración desde una copia de seguridad si el archivo de copia de seguridad está cifrado con la clave con la huella digital correspondiente.

Si la clave necesaria para restaurar una copia de seguridad ya no está disponible para el servidor de destino, el siguiente mensaje de error se devuelve en el intento de restauración: "Servidor de destino <Servername> no tiene acceso a todos los URI de AKV creados entre <Marca de tiempo #1> y <Marca de tiempo #2>. Please retry operation after restoring all AKV URIs" (El servidor destino no tiene acceso a todos los URI de AKV creados entre y . Vuelva a intentar la operación después de restaurar a todos los URI de AKV).

Para mitigarlo, ejecute el cmdlet Get-AzSqlServerKeyVaultKey para el servidor de destino o Get-AzSqlInstanceKeyVaultKey para la instancia administrada de destino para devolver la lista de claves disponibles e identificar las que faltan. Para asegurarse de que se pueden restaurar las copias de seguridad, asegúrese de que el servidor de destino para la restauración tiene acceso a todas las claves necesarias. No es necesario que estas claves estén marcadas como protector de TDE.

Para obtener más información sobre la recuperación de copia de seguridad de SQL Database, consulte Recuperación de una base de datos de SQL Database. Para obtener más información sobre la recuperación de copia de seguridad de un grupo de SQL dedicado en Azure Synapse Analytics, consulte Recuperación de un grupo de SQL dedicado. Para realizar una copia de seguridad o una restauración nativa de SQL Server con una instancia de SQL Managed Instance, consulte Inicio rápido: Restauración de una base de datos a SQL Managed Instance.

Otra consideración para los archivos de registro: los archivos de registro de copia de seguridad permanecen cifrados con el protector TDE original, incluso si se giraron y la base de datos ahora usa un nuevo protector TDE. Durante la restauración, se necesitarán ambas claves para restaurar la base de datos. Si el archivo de registro está usando un protector de TDE almacenado en Azure Key Vault, se necesitará esta clave durante la restauración, incluso si la base de datos se ha cambiado para usar TDE administrado por el servicio durante el proceso.

Alta disponibilidad con TDE administrado por el cliente

Con AKV que proporciona varias capas de redundancia, los TDE que usan una clave administrada por el cliente pueden aprovechar la disponibilidad y la resistencia de AKV, y confiar completamente en la solución de redundancia de AKV.

Las varias capas de redundancia de AKV garantizan el acceso clave incluso si se produce un error en los componentes de servicio individuales o las regiones de Azure o las zonas de disponibilidad. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault.

AKV ofrece los siguientes componentes de disponibilidad y resistencia que se proporcionan automáticamente sin intervención del usuario:

Nota:

En todas las regiones de par, las claves de AKV se replican en ambas regiones y hay módulos de seguridad de hardware (HSM) en ambas regiones que pueden funcionar en esas claves. Para obtener más información, consulte Replicación de datos. Esto se aplica a los niveles de servicio Estándar y Premium de Azure Key Vault, así como a las claves de software o hardware.

Recuperación ante desastres con localización geográfica y TDE administrado por el cliente

Tanto en escenarios de replicación geográfica activa como en grupos de conmutación por error, los servidores principales y secundarios implicados 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 primarios y secundarios, el cliente es responsable de mantener el material de clave en los almacenes de claves coherente, de modo que el geo secundario esté sincronizado y pueda tomar el control con la misma clave de su almacén de claves vinculado si el principal se vuelve inaccesible debido a 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 evitar problemas al establecer o durante la replicación geográfica debido a material de clave incompleto, es importante que siga estas reglas al configurar TDE administrado por el cliente (si se usan almacenes de claves independientes para los servidores primarios y secundarios):

  • Todos los almacenes de claves implicados deben tener las mismas propiedades y los mismos derechos de acceso para los servidores respectivos.

  • Todos los almacenes de claves implicados deben contener el mismo material de clave. Esto no solo se aplica al protector de TDE actual, sino a todos los protectores de TDE anteriores que se pueden usar en los archivos de copia de seguridad.

  • Tanto la configuración inicial como la rotación del protector de TDE se deben realizar primero en el servidor secundario y, a continuación, en el principal.

Diagrama en el que se muestran los grupos de migración tras error y la recuperación ante desastres geográfica.

Para probar una conmutación por error, siga los pasos descritos en la información general sobre la replicación geográfica activa. La prueba de la conmutación por error se debe realizar de forma periódica para validar que SQL Database ha mantenido el permiso de acceso a ambos almacenes de claves.

El servidor de Azure SQL Database y SQL Managed Instance en una región ahora se pueden vincular al almacén de claves en cualquier otra región. El servidor y el almacén de claves no tienen que estar ubicados en la misma región. Con esto, por motivos de simplicidad, los servidores principal y secundario se pueden conectar al mismo almacén de claves (en cualquier región). Esto ayuda a evitar escenarios en los que el material de clave podría estar sin sincronizar si se usan almacenes de claves independientes para ambos servidores. Azure Key Vault dispone de varias capas de redundancia para asegurarse de que las claves y los almacenes de claves siguen estando disponibles en caso de errores de servicio o región. Redundancia y disponibilidad de Azure Key Vault

Directiva de Azure para TDE administrado por el cliente

La directiva de Azure se puede usar para exigir el TDE administrado por el cliente durante la creación o actualización de un servidor Azure SQL Database o Azure SQL Managed Instance. Con esta directiva en su lugar, cualquier intento de crear o actualizar un servidor lógico en Azure o instancia administrada producirá un error si no está configurado con una clave administrada por el cliente. La instancia de Azure Policy se puede aplicar a toda la suscripción de Azure o solo dentro de un grupo de recursos.

Para obtener más información sobre Azure Policy, vea ¿Qué es Azure Policy? y Estructura de definición de Azure Policy.

Las dos directivas integradas siguientes son compatibles con TDE administrado por el cliente en Azure Policy:

  • Los servidores SQL deben usar claves administradas por el cliente para cifrar los datos en reposo
  • Las instancias administradas deben usar claves administradas por el cliente para cifrar los datos en reposo

La directiva TDE administrada por el cliente se puede administrar en Portal de Azure y buscando el servicio de directivas. En Definiciones, busque la clave administrada por el cliente.

Estas directivas tienen tres efectos:

  • Auditar: es el valor predeterminado, y solo captura un informe de auditoría de los registros de actividad de Azure Policy
  • Denegar: impide la creación o actualización de instancias administradas o del servidor lógico sin una clave administrada por el cliente configurada
  • Deshabilitado: deshabilitará la directiva y no restringirá a los usuarios la creación o actualización de un servidor lógico o una instancia administrada sin la TDE administrada por el cliente habilitada

Si la directiva de Azure para TDE administrada por el cliente se establece en Denegar, servidor lógico de Azure SQL o creación de instancias administradas producirá un error. Los detalles de este error se registran en el registro de actividad del grupo de recursos.

Importante

Las versiones anteriores de directivas integradas para TDE administradas por el cliente que contienen el efecto AuditIfNotExist han quedado en desuso. Las asignaciones de directivas existentes que usan las directivas en desuso no se verán afectadas y seguirán funcionando como antes.

Contenido relacionado