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

Se aplica a:Azure SQL DatabaseAzure SQL Managed InstanceAzure 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 a nivel de base de datos de 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 pools de SQL dedicados en espacios 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

Nota

En este artículo, los términos Clave administrada por el cliente (CMK) y Bring Your Own Key (BYOK) se usan indistintamente, pero representan algunas diferencias.

• clave administrada por el cliente (CMK): el cliente administra el ciclo de vida de la clave, incluida la creación, la rotación y la eliminación de claves. La clave se almacena en Azure Key Vault o en Azure Key Vault Managed HSM y se utiliza para el cifrado de la Clave de Cifrado de Base de Datos (DEK) en Azure SQL, SQL Server en Azure VM y SQL Server local.
• Traiga su propia clave (BYOK): El cliente importa de forma segura su propia clave desde un módulo de seguridad de hardware local (HSM) en Azure Key Vault o en un HSM gestionado de Azure Key Vault. Estas claves importadas se pueden usar como cualquier otra clave de Azure Key Vault, incluida como clave administrada por el cliente para el cifrado de la DEK. Para obtener más información, consulte Importar claves protegidas por HSM en HSM administrado (BYOK).

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 que quieren empezar a usar TDE administrado por el cliente, los datos permanecen cifrados durante el proceso de conmutación y no hay tiempo de inactividad ni volver a cifrar los archivos de 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

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 Key Vault Crypto Service Encryption User para poder utilizar la clave en las operaciones de cifrado y descifrado.

• Directiva de acceso del almacén: use 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 el menú de Azure Portal Configuración de acceso del almacén de claves, tiene 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 de 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 la bóveda de claves al configurar TDE administrado por el cliente en un nuevo o existente servidor o instancia administrada.

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

• Use un almacén de claves de una región de Azure que pueda replicar su contenido en una región emparejada para obtener la máxima disponibilidad. Para más información, consulte los procedimientos recomendados para usar Azure Key Vault y, así como la disponibilidad y redundancia de Azure Key Vault y.

Nota

Para permitir una mayor flexibilidad en la configuración gestionada por el cliente del TDE, Azure SQL Database y Azure SQL Managed Instance en una región ahora pueden vincularse a un Azure Key Vault en 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 esté habilitado, el servidor comprobará continuamente el almacén de claves para detectar cualquier nueva versión de la clave que se utiliza 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 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 la base de datos no es accesible debido a una interrupción intermitente de la red, no se requiere ninguna acción y las bases de datos volverán a estar en línea automáticamente. Para mitigar el impacto de errores de red o interrupciones al intentar acceder al protector de TDE en Azure Key Vault, se ha introducido un búfer de 24 horas antes de que el servicio intente mover la base de datos a un estado inaccesible. Si se produce una conmutación por error antes de alcanzar el estado inaccesible, la base de datos deja de estar disponible debido a la pérdida de la caché de cifrado.

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 todos los valores de nivel de servidor y 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.

Revocación accidental del acceso al protector de TDE

Podría suceder que alguien con derechos de acceso suficientes al 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

El bloqueo de conectividad de red entre Instancia Administrada de SQL y el almacén de claves ocurre principalmente cuando el recurso del almacén de claves existe, pero su punto de conexión no se puede alcanzar desde la Instancia Administrada de SQL. 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 de un endpoint privado y la dirección IP privada del servicio AKV no está permitida en las reglas de salida del grupo de seguridad de red (NSG) asociado con 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 falla el acceso al protector de TDE en el almacén de claves administrado por el cliente, se agregan entradas 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 te envíen notificaciones y alertas en función de tus preferencias, por ejemplo, Correo Electrónico/SMS/Push/Voz, Aplicación Lógica, Webhook, ITSM o Runbook de Automatización.

Bases de datos backup y restore con TDE gestionado 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 "Establecer la clave como el protector predeterminado de TDE" en el panel del portal de Azure. 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 se cifra 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>. 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:

• Replicación de datos
• Conmutación por error dentro de una región
• Conmutación por error entre regiones

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

En ambos escenarios de replicación geográfica activa y de grupos de conmutación por error , los servidores principales y secundarios implicados se pueden vincular al Azure Key Vault que se encuentra en cualquier región. El servidor y el almacén de claves no tienen que colocarse 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 clave podría estar desincronizado si se usan bóvedas de claves independientes para servidores ambos. 

Azure Key Vault tiene varias capas de redundancia para asegurarse de que las claves y los almacenes de claves permanecen disponibles en caso de errores de servicio o región. La redundancia es compatible con las regiones no emparejadas, así como las regiones emparejadas. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault.

Hay varias opciones para almacenar la clave de protector de TDE, en función de los requisitos de los clientes:

• Aproveche Azure Key Vault y la resistencia de región emparejada nativa o la resistencia de región no emparejada.

• Utilice el HSM del cliente y cargue las claves en Azure Key Vault en AKV independientes en todas las regiones.

• Aproveche HSM administrado y la opción de replicación entre regiones.

  • Esta opción permite al cliente seleccionar la región deseada donde se replicarán las claves.

En el diagrama siguiente se representa una configuración de la región emparejada (principal y secundaria) para una conmutación por error cruzada de AKV con la configuración de Azure SQL para la replicación geográfica mediante un grupo de conmutación por error:

Comentarios de Azure Key Vault para Geo-DR

• Tanto los servidores principales como los secundarios de Azure SQL acceden a AKV en la región primaria.

• El servicio de AKV inicia la conmutación por error de AKV y no el cliente.

• En caso de conmutación por error del Azure Key Vault (AKV) a la región secundaria, el servidor en Azure SQL todavía puede acceder al mismo Azure Key Vault. Aunque internamente, la conexión de AKV se redirige a AKV en la región secundaria.

• Las nuevas creaciones de claves, las importaciones y las rotaciones de claves solo son posibles mientras AKV de la región principal esté disponible.

• Una vez que se produce la conmutación por error, no se permite la rotación de claves hasta que se vuelva a acceder a AKV en la región primaria de la región emparejada.

• El cliente no se puede conectar manualmente a la región secundaria.

• AKV está en estado de solo lectura mientras que AKV de la región primaria no está disponible

• El cliente no puede elegir ni comprobar en qué región se encuentra actualmente AKV.

• En el caso de la región no emparejada, ambos servidores de Azure SQL server acceden a AKV en la primera región (como se indica en el gráfico) y AKV usa almacenamiento con redundancia de zona para replicar los datos dentro de la región, en zonas de disponibilidad independientes de la misma región.

Para más información, consulte disponibilidad y redundancia de Azure Key Vault, pares de regiones de Azure y regiones no emparejadasy contratos de nivel de servicio para Azure Key Vault.

Comentarios de Azure SQL para Geo-DR

• Use la opción con redundancia de zona de Azure SQL MI y Azure SQL DB para aumentar la resistencia. Para más información, consulte ¿Qué son las zonas de disponibilidad de Azure?.

• Use grupos de conmutación por error para Azure SQL MI y Azure SQL DB para la recuperación ante desastres en una región secundaria. Para obtener más información, consulte Información general y procedimientos recomendados sobre grupos de conmutación por error.

• La configuración puede requerir una zona DNS más compleja si se usan puntos de conexión privados en Azure SQL (por ejemplo, no puede crear dos puntos de conexión privados en el mismo recurso de la misma zona DNS).

• Asegúrese de que las aplicaciones aprovechan la lógica de reintento.

Hay varios escenarios en los que es posible que los clientes quieran elegir la solución Módulos de seguridad de hardware administrado (HSM) a través de AKV:

• Requisito de conexión manual al almacén secundario.

• Requisito de acceso de lectura al almacén incluso si se produce un error.

• Flexibilidad para elegir en qué región se replica su material clave

  • Requiere habilitar la replicación entre regiones que crea el segundo grupo de HSM administrado en la segunda región.

• El uso del HSM administrado permite a los clientes crear una réplica exacta para HSM si el original se pierde o no está disponible.

• Uso de HSM administrado para requisitos normativos o de seguridad.

• Tener la capacidad de realizar una copia de seguridad del almacén completo frente a la copia de seguridad de claves individuales.

Para más información, consulte Habilitar replicación en Azure Managed HSM y Recuperación ante desastres de HSM administrado.

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, consulte Qué es Azure Policy y la 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 gestionar yendo al 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, la creación de un servidor lógico de Azure SQL o una instancia administrada fallará. 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 ven afectadas y seguirán funcionando como antes.

Contenido relacionado

• Gire el Protector de cifrado de datos transparente para SQL Database
• Quitar un protector de cifrado de datos (TDE) transparente para SQL Database
• Administración del Cifrado de datos transparente en SQL Managed Instance con su propia clave mediante PowerShell
• Microsoft Defender para SQL