Compartir a través de

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, el protector de Cifrado de datos transparente (TDE), una clave asimétrica administrada por el cliente que se usa para proteger la clave de cifrado de base de datos (DEK), se almacena en Azure Key Vault o en HSM administrado por Azure Key Vault. Estos son servicios de administración de claves seguros y basados en la nube diseñados para alta disponibilidad y escalabilidad. Azure Key Vault admite claves RSA y puede estar respaldada por HSM validados por FIPS 140-2 nivel 2. Para los clientes que requieren una mayor garantía, HSM administrado de Azure Key Vault ofrece hardware validado fiPS 140-2 de nivel 3. La clave se puede generar en el servicio, importar o transferir de forma segura desde HSM locales. El acceso directo a las claves está restringido: los servicios autorizados realizan operaciones criptográficas sin exponer el material de clave.

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. El término servidor hace referencia tanto a un servidor de SQL Database como a Azure Synapse y a una instancia administrada de SQL Managed Instance en este artículo, a menos que se indique lo contrario.

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 más información sobre el cifrado de datos transparente para pools de SQL dedicados dentro de áreas de trabajo de Synapse, consulte Cifrado de Azure Synapse Analytics.

Nota

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

Clave administrada por el cliente (CMK) y Bring Your Own Key (BYOK)

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 Azure Managed HSM y se usa para el cifrado de la clave de cifrado de base de datos (DEK) en Azure SQL, SQL Server en máquinas virtuales de Azure y SQL Server local.

  • Bring Your Own Key (BYOK): el cliente aporta o importa de forma segura su propia clave desde un módulo de seguridad de hardware local (HSM) en Azure Key Vault o HSM administrado de Azure. 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).

Ventajas del TDE administrado por el cliente

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

  • Control total y pormenorizado sobre el uso y la administración del protector TDE.

  • Transparencia del uso del protector de TDE.

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

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

  • Administración central de claves en Azure Key Vault.

  • Mayor confianza de los clientes finales, ya que Azure Key Vault está diseñado para que Microsoft no pueda 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.

Permisos para configurar TDE administrado por el cliente

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

Seleccione el tipo de Azure Key Vault que desea usar.

Para que el servidor lógico de Azure use el protector de TDE almacenado en Azure Key Vault para el cifrado de la DEK, el administrador de Key Vault debe conceder derechos de acceso al servidor mediante su identidad única 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. 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 Azure 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 un servidor está configurado para usar un protector de TDE desde Azure Key Vault, el servidor envía la DEK de cada base de datos habilitada para TDE al almacén de claves para el 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 para configurar TDE administrado por el cliente

  • Las características de eliminación temporal y protección de purga deben estar habilitadas en Azure Key Vault. 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.

  • Al usar un firewall con Azure Key Vault, 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 Azure Key Vault. Para más información, vea Configuración de firewalls y redes virtuales de Azure Key Vault.

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 de 2048 bits 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 una clave existente en el almacén de claves, asegúrese de que se proporciona en uno de los formatos de archivo admitidos: .pfx, .byoko .backup. Para importar claves protegidas con HSM en Azure Managed HSM, consulte Importación de claves protegidas por HSM en HSM administrado (BYOK).

Nota

Un problema con las versiones de Thales CipherTrust Manager anteriores a v2.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 Azure Key Vault para empezar a usarlo como protector de TDE para el servidor o la instancia administrada. Este problema se resuelve en Thales CipherTrust Manager v2.8.0.

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

  • Para garantizar un rendimiento y una confiabilidad óptimos, se recomienda encarecidamente usar una instancia dedicada de Azure Key Vault para Azure SQL. Este almacén de claves no debe compartirse con otros servicios. Si el almacén de claves está bajo mucha carga, debido al uso compartido o a las operaciones de clave excesivas, puede afectar negativamente al rendimiento de la base de datos, especialmente durante el acceso a la clave de cifrado. Azure Key Vault aplica límites de regulación. Cuando se superan estos límites, es posible que las operaciones se retrasen o produzcan errores. Esto es fundamental en las conmutaciones por error de un servidor, que desencadenan las operaciones clave para cada base de datos en el servidor.

    Para obtener más información sobre el comportamiento de limitación, consulte la Guía de limitación de Azure Key Vault.

    Para mantener la alta disponibilidad y evitar problemas de limitación, siga estas instrucciones por suscripción:

    • Utilice una instancia dedicada de Azure Key Vault para los recursos de Azure SQL.

    • No asocie más de 500 bases de datos de uso general con una sola instancia de Azure Key Vault.

    • No asocie más de 200 bases de datos críticas para la empresa con una sola instancia de Azure Key Vault.

    • El número de bases de datos de Hiperescala que se pueden asociar a una instancia única de Azure Key Vault viene determinada por el número de servidores de páginas. Cada servidor de páginas está vinculado a un archivo de datos lógico. Para buscar el número de servidores de página, ejecute la consulta siguiente.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      No asocie más de 500 servidores de página a una sola instancia de Azure Key Vault. A medida que crece la base de datos, el número de servidores de página aumenta automáticamente, por lo que es importante supervisar el tamaño de la base de datos con regularidad. Si el número de servidores de página supera los 500, use una instancia dedicada de Azure Key Vault para cada base de datos de Hiperescala que no se comparta con otros recursos de Azure SQL.

    • Supervise y configure las alertas de Azure Key Vault. Para más información sobre la supervisión y las alertas, consulte Supervisión de Azure Key Vault y Configuración de alertas de Azure Key Vault.

  • 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 los informes en todas las claves de cifrado: Azure Key Vault 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 de TDE administrado por el cliente, Azure SQL Database y Azure SQL Managed Instance en una región ahora se pueden vincular a 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 claves antes de usar la clave en Azure Key Vault 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. Azure Managed HSM admite la creación de una copia de seguridad completa del contenido completo del HSM, incluidas todas las claves, versiones, atributos, etiquetas y asignaciones de roles. Para obtener más información, consulte Copia de seguridad completa y restauración y restauración selectiva de claves.

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

  • Mantenga las versiones anteriores de la clave en el almacén de claves o HSM administrado al rotar las claves, por lo que se pueden restaurar las copias de seguridad de base de datos anteriores. 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 siguiendo las instrucciones del artículo Rotación del protector de cifrado de datos transparente (TDE).

  • Mantenga todas las claves usadas anteriormente en Azure Key Vault o Azure Managed HSM incluso después de cambiar a claves administradas por el servicio. Garantiza que las copias de seguridad de base de datos se pueden restaurar con los protectores de TDE almacenados en Azure Key Vault o HSM administrado por Azure. Los protectores de TDE creados con Azure Key Vault o Azure Managed HSM deben mantenerse 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 comprometida durante un incidente de seguridad sin el riesgo de pérdida de datos, siga los pasos descritos en el artículo Eliminación de un protector de Cifrado de datos transparente (TDE) mediante PowerShell.

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 comprueba continuamente el almacén de claves o el HSM Gestionado para identificar nuevas versiones de la clave que se utiliza como protector de TDE. Si se detecta una nueva versión de la clave, el protector de TDE en el servidor o la base de datos se rota automáticamente a la versión de clave más reciente en un plazo de 24 horas.

Cuando se usa con la rotación automatizada de claves en Azure Key Vault o la autorrotación en Azure Managed HSM, esta característica permite la rotación completa automatizada sin intervención para el protector de TDE en Azure SQL Database y Azure SQL Managed Instance.

Nota

Al establecer TDE con CMK mediante la rotación manual o automatizada de las claves, siempre se usa la versión más reciente de la clave que es 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 o HSM administrado 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) tiene permisos necesarios en el almacén de claves del servidor principal o HSM administrado, y el sistema intenta 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 o HSM administrado 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) tiene permisos necesarios en el almacén de claves del servidor principal y el sistema intenta 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 Azure Key Vault o Azure Managed HSM, en hasta 10 minutos, una base de datos comienza 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.

Estado inaccesible

Si la base de datos no es accesible debido a una interrupción intermitente de la red (por ejemplo, un error 5XX), no se requiere ninguna acción, ya que las bases de datos vuelven a estar en línea automáticamente. Para reducir el efecto de los errores de red o interrupciones al acceder al protector de TDE en Azure Key Vault o HSM administrado de Azure, se introduce 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.

Si el servidor pierde el acceso al protector de TDE administrado por el cliente en Azure Key Vault o Azure Managed HSM debido a cualquier error de Azure Key Vault (por ejemplo, un error 4XX), la base de datos se mueve a un estado inaccesible después de 30 minutos.

Restauración del acceso a la base de datos después de un error de Azure Key Vault o HSM administrado de Azure

Después de restaurar el acceso a la clave, volver a poner la base de datos en línea requiere tiempo adicional y pasos, que pueden variar en función de la duración de la falta de disponibilidad de la clave y el tamaño de los datos dentro de la base de datos.

Si se restaura el acceso a claves en un plazo de 30 minutos, la base de datos se cura automáticamente en la hora posterior. Sin embargo, 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. En tales casos, la restauración de la base de datos implica procedimientos adicionales a través de Azure Portal y puede llevar mucho tiempo, en función del tamaño de la base de datos.

Una vez que la base de datos vuelve a estar en línea, la configuración de nivel de servidor establecida previamente, incluidas las configuraciones de grupo de conmutación por error, etiquetas, y configuraciones a nivel de base de datos, como las configuraciones de grupo elástico, escalabilidad de lectura, pausa automática, historial de restauración a un punto en el tiempo, políticas de retención a largo plazo, entre otros, se pierden. Por lo tanto, se recomienda que los clientes implementen un sistema de notificaciones para detectar la pérdida de acceso a la clave de cifrado en un plazo de 30 minutos. Una vez expirada 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 una base de datos inaccesible en línea.

Captura de pantalla de una base de datos BYOK de TDE inaccesible.

Revocación accidental del acceso al protector de TDE

Es posible que alguien con los derechos de acceso suficientes al almacén de claves o HSM administrado deshabilite accidentalmente el acceso del servidor a la clave al realizar alguna de las siguientes acciones:

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

  • Eliminar la clave.

  • borrando el almacén de claves o el HSM administrado

  • cambiar las reglas del firewall del almacén de claves o del HSM administrado

  • 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 Azure Key Vault o Azure Managed HSM

El bloque de conectividad de red entre SQL Managed Instance y key vault o HSM administrado se produce principalmente cuando existe el almacén de claves o el recurso HSM administrado, pero su punto de conexión no se puede acceder desde la instancia administrada. Todos los escenarios en los que se puede acceder al almacén de claves o al punto de conexión HSM administrado, pero se deniega la conexión, faltan permisos, etc., hace que las bases de datos cambien su estado a Inaccesible.

Las causas más comunes de la falta de conectividad de red con Azure Key Vault o Azure Managed HSM son:

  • Azure Key Vault o Azure Managed HSM se exponen a través de un punto de conexión privado y la dirección IP privada del servicio Azure Key Vault o Azure Managed HSM no se permite en las reglas de salida del grupo de seguridad de red (NSG) asociado a la subred de la instancia administrada.

  • Mala resolución DNS, como cuando el FQDN del almacén de claves o del HSM administrado no se resuelve o se resuelve a una dirección IP no válida.

Pruebe la conectividad de SQL Managed Instance con Azure Key Vault o HSM administrado de Azure 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 en la instancia administrada tenga una regla de salida que cubra 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 o del HSM administrado.

    • 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 ha perdido el acceso al protector de TDE se muestra como "No disponible" después de denegar 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 cifra con TDE mediante una clave de Azure Key Vault o HSM administrado de Azure, las copias de seguridad recién 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 desde Azure Key Vault o Azure Managed HSM, asegúrese de que el material de clave está disponible para el servidor de destino. Por lo tanto, se recomienda mantener todas las versiones anteriores del protector de TDE en el almacén de claves o HSM administrado, por lo que se pueden restaurar las copias de seguridad de la base de datos.

Importante

No puede haber más de un protector TDE establecido para un servidor en cualquier momento. La clave marcada con Convertir la clave en el protector TDE predeterminado en el panel del portal de Azure es el protector TDE. Sin embargo, se pueden vincular varias claves 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 más información sobre la recuperación de copias de seguridad para SQL Database, consulte Restauración de una base de datos a partir de una copia de seguridad en Azure 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 la copia de seguridad o restauración nativas de SQL Server con SQL Managed Instance, consulte Inicio rápido: Restauración de una base de datos a Azure SQL Managed Instance con SSMS.

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 usa un protector de TDE almacenado en Azure Key Vault o Azure Managed HSM, esta clave es necesaria en el momento de la restauración, incluso si la base de datos se cambió para usar el TDE administrado por el servicio mientras tanto.

Alta disponibilidad con TDE administrado por el cliente

Con Azure Key Vault o HSM administrado de Azure que proporciona varias capas de redundancia, los TDEs que usan una clave administrada por el cliente pueden aprovechar la disponibilidad y resistencia de Azure Key Vault o HSM administrado de Azure, y confiar completamente en la solución de redundancia de Azure Key Vault o HSM administrado de Azure.

Varias capas de redundancia de Azure Key Vault garantizan el acceso a claves incluso si los componentes de servicio individuales producen un error o las regiones de Azure o las zonas de disponibilidad están inactivos. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault.

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

Nota

Para todas las regiones emparejadas, las claves de Azure Key Vault se replican en ambas regiones y hay módulos de seguridad de hardware (HSM) en ambas regiones que pueden operar con 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.

La replicación de varias regiones de Azure Managed HSM permite ampliar un grupo de HSM administrado de Azure desde una región de Azure (denominada región primaria) a otra región de Azure (denominada región extendida). Una vez configurada, ambas regiones están activas, pueden atender solicitudes y, con la replicación automatizada, compartir el mismo material clave, roles y permisos. Para más información, consulte Habilitación de la replicación en varias regiones en HSM administrado de Azure.

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 grupos de conmutación por error, los servidores principales y secundarios implicados se pueden vincular a Azure Key Vault o Azure Managed HSM ubicados en cualquier región. El servidor y el almacén de claves o HSM administrado no tienen que colocarse en la misma región. Con esto, por motivos de simplicidad, los servidores principales y secundarios se pueden conectar al mismo almacén de claves o HSM administrado (en cualquier región). Esto ayuda a evitar escenarios en los que el material criptográfico podría estar fuera de sincronización si se usan almacenes de claves independientes o HSM gestionados para ambos servidores.

Azure Key Vault y Azure Managed HSM tienen 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 está respaldada por las regiones no emparejadas y 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:

  • Usar Azure Key Vault y la resiliencia de la región emparejada nativa o la resiliencia de la región no emparejada.

  • Utilice un HSM del cliente y cargue claves en Azure Key Vault usando almacenes independientes de Azure Key Vault en varias regiones.

  • Usar HSM administrado de Azure y opción de replicación entre regiones.

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

El siguiente diagrama representa una configuración para una región emparejada (primaria y secundaria) para una conmutación por error cruzada de Azure Key Vault con la configuración de Azure SQL para la georreplicación mediante un grupo de conmutación por error:

Diagrama que muestra la compatibilidad con la conmutación por error entre regiones de Azure Key Vault para una región emparejada.

Comentarios de Azure Key Vault para Geo-DR

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

  • La conmutación por error de Azure Key Vault es iniciada por el servicio Azure Key Vault y no por el cliente.

  • Si Azure Key Vault conmuta por error a la región secundaria, el servidor de Azure SQL todavía puede acceder a la misma instancia de Azure Key Vault. Aunque internamente, la conexión de Azure Key Vault se redirige al Azure Key Vault de la región secundaria.

  • Las nuevas creaciones de claves, las importaciones y las rotaciones de claves solo son posibles cuando el Azure Key Vault en el servidor principal está disponible.

  • Una vez que se produce la conmutación por error, no se permite la rotación de claves hasta que se pueda acceder de nuevo al Azure Key Vault de la región primaria de la región emparejada.

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

  • Azure Key Vault está en estado de solo lectura mientras Azure Key Vault en la región primaria no está disponible

  • El cliente no puede elegir ni comprobar en qué región está actualmente azure Key Vault.

  • En el caso de la región no emparejada, ambos servidores de Azure SQL tienen acceso a Azure Key Vault en la primera región (como se indica en el gráfico) y Azure Key Vault 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

  • Utiliza la opción de redundancia de zona de Azure SQL Managed Instance y Azure SQL Database para aumentar la resiliencia. Para más información, consulte ¿Qué son las zonas de disponibilidad de Azure?.

  • Utilice grupos de conmutación por error para Azure SQL Managed Instance y Azure SQL Database para 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.

  • Cuando una base de datos forma parte de la replicación geográfica activa o de los grupos de conmutación por error y deja de estar accesible, el plano de control de SQL interrumpe el vínculo y convierte la base de datos en una base de datos independiente. Después de corregir los permisos de clave, la base de datos principal normalmente se puede volver a poner en línea. La base de datos secundaria no se puede volver a poner en línea porque Azure SQL no realiza copias de seguridad completas para las bases de datos secundarias por diseño. La recomendación es quitar las bases de datos secundarias y volver a establecer el vínculo.

  • 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 usan lógica de reintento.

Hay varios escenarios en los que es posible que los clientes quieran elegir la solución HSM administrada de Azure a través de Azure Key Vault:

  • 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 de Azure en la segunda región.

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

  • Uso de HSM administrado de Azure para los 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 vigor, se produce un error en los intentos de crear o actualizar un servidor lógico en Azure o instancia administrada 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:

  • Auditoría : la configuración predeterminada y solo captura un informe de auditoría en 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 : deshabilita la directiva y no impide que los usuarios creen o actualicen un servidor lógico o una instancia administrada sin TDE administrado por el cliente habilitado

Si la Policy de Azure para TDE administrado por el cliente se establece en Denegar, se produce un error en la creación del servidor lógico de Azure SQL o de la instancia administrada. Los detalles de este error se registran en el registro de actividad del grupo de recursos.

Importante

Las versiones anteriores de directivas integradas para el TDE gestionado por el cliente que contienen el efecto AuditIfNotExists quedan en desuso. Las asignaciones de políticas existentes que utilizan políticas en desuso no se ven afectadas y continúan funcionando como antes.

Contenido relacionado

  • Last updated on