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 Cifrado de datos transparente (TDE) es una clave gestionada por el cliente que protege la Clave de Cifrado de la Base de Datos (DEK). Almacenas el protector TDE en Azure Key Vault o Azure Key Vault Managed HSM, que son servicios seguros de gestión de claves en la nube diseñados para alta disponibilidad y escalabilidad. Ambos servicios soportan claves criptográficas protegidas por hardware validado FIPS 140-2: Azure Key Vault soporta FIPS 140-2 Nivel 2, y Azure Key Vault Managed HSM soporta FIPS 140-2 Nivel 3. Ambos servicios también soportan tipos de clave asimétrica y simétrica, y los algoritmos y el uso soportados dependen del modelo de despliegue TDE. Puedes generar la clave en el servicio, importarla o transferirla de forma segura desde HSMs locales. El acceso directo a las claves está restringido, por lo que los servicios autorizados realizan operaciones criptográficas sin exponer el material de la 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.

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.

Permisos para configurar TDE administrado por el cliente

Seleccione el tipo de Azure Key Vault que desea usar.

Requisitos para configurar TDE administrado por el cliente

Requisitos clave para configurar el protector de TDE

Cifrado de datos transparente con claves gestionadas por el cliente utiliza una clave externa, denominada protector TDE, almacenada en Azure Key Vault o Azure Managed HSM para proteger la clave de cifrado de la base de datos (DEK).

Se aplican los siguientes requisitos.

Tamaños y tipos de clave admitidos

Según la oferta de Azure SQL y la configuración de TDE, el protector de TDE puede estar respaldado por claves asimétricas o simétricas almacenadas en Azure Key Vault o Azure Key Vault HSM administrado.

• Claves asimétricas (RSA o RSA HSM)

  • Compatible con Azure Key Vault y Azure Key Vault Managed HSM
  • Tamaños de clave soportados: 2.048 bits y 3.072 bits
  • Compatible con Azure SQL Database, Azure SQL Managed Instance y Azure Synapse Analytics

• Claves simétricas (AES)

  • Compatible con Azure Key Vault Premium (previsualización) y Azure Key Vault Managed HSM
  • Tamaños de clave soportados: 128 bits, 192 bits y 256 bits
  • Compatible solo con Azure SQL Database, actualmente en vista previa pública

Comportamiento de gestión de claves para claves simétricas (AES)

Puedes usar claves simétricas (AES) almacenadas en Azure Key Vault Premium (vista previa) o Azure Key Vault Managed HSM como protector de TDE. Para empezar con una clave de un módulo de seguridad de hardware (HSM) local, importa la clave en cualquiera de los dos servicios. Tras la importación inicial, todas las operaciones del ciclo de vida de las claves en curso se realizan en Azure Key Vault Premium (vista previa) o en Azure Key Vault Managed HSM. La recuperación a un momento dado, la recuperación ante desastres geográficos y la revalidación de claves dependen de que la clave siga estando disponible allí. Mantener copias de seguridad locales de claves importadas para apoyar escenarios de recuperación y revalidación. Este comportamiento solo se aplica a claves simétricas (AES), no a claves asimétricas (RSA).

Requisitos principales de estado y validez

• Si se especifica una fecha de activación de clave, debe establecerse en una fecha y hora en el pasado.
• Si se especifica una fecha de expiración de clave, debe establecerse en una fecha y hora en el futuro.
• El estado de la clave debe ser Habilitada.

Requisitos de importación de claves

Si importas una clave existente en Azure Key Vault, proporciona la clave en uno de los siguientes formatos compatibles:

• .pfx
• .byok
• .backup

Para importar claves protegidas con HSM en Azure Managed HSM, consulte Importación de claves protegidas por HSM en HSM administrado (BYOK).

Recomendaciones para configurar TDE administrado por el cliente

Recomendaciones para configurar el 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).

• Guarda versiones anteriores de la clave en el Key Vault o en HSM gestionado al rotar claves, para poder restaurar copias de seguridad antiguas de bases de datos. Cuando el protector TDE cambia para una base de datos, las copias de seguridad antiguas de la base de datos no se actualizan para usar el último protector TDE. 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. Para rotar claves, sigue las instrucciones del artículo Rotar el protector de cifrado de datos transparentes (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. Gire siempre a un nuevo protector de TDE y compruebe que todas las bases de datos usan la nueva clave antes de eliminar o deshabilitar la clave en peligro. Eliminar o desactivar la clave sin rotarla primero hace que todas las bases de datos cifradas queden inaccesibles y no invalida ninguna copia de la clave que se haya copiado de seguridad y restaurado previamente en otra bóveda.

Rotación del protector de TDE

La rotación del protector de TDE permite reemplazar la clave utilizada para proteger la clave de cifrado de base de datos (DEK). 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.

Puede rotar el protector de TDE cambiando la configuración para usar una nueva clave almacenada en Azure Key Vault o Azure Key Vault HSM administrado. En función de la oferta de Azure SQL y la configuración admitida, esto puede incluir:

• Cambiar a una nueva versión de la misma clave
• Cambiar a otra clave
• Cambio entre tipos de clave admitidos, como claves asimétricas (RSA) y simétricas (AES)

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 o HSM administrado para ver las nuevas versiones de la clave que se usan 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.

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 soportan escenarios de geo-replicación que utilizan claves gestionadas 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.

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.

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:

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

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 geográficos con TDE administrado por el cliente

La georreplicación activa y los grupos de conmutación por error admiten la TDE administrada por el cliente. Los servidores principal y secundario pueden utilizar un Azure Key Vault o un HSM gestionado por Azure en cualquier región soportada. Los servidores y la tienda de claves no tienen por qué estar en la misma región.

Para que una conmutación por error se realice correctamente, ambos servidores deben tener acceso a cada Azure Key Vault o Azure Managed HSM que contenga alguna clave necesaria.

Consideraciones de configuración

Deben tenerse en cuenta las siguientes consideraciones al configurar la replicación geográfica activa o un grupo de conmutación por error en el portal de Azure:

• Ubicación del protector TDE: Los servidores principal y secundario pueden usar el mismo Azure Key Vault o Azure Managed HSM. Usar el mismo almacenamiento de claves reduce el riesgo de que el material de clave se desincronize. Si usas bóvedas de llave separadas en varias regiones, debes mantener sincronizado el material de clave requerido. Para información sobre la resiliencia del almacenamiento de claves, consulte Azure Key Vault availability and redundancy y Multi-region replication in Managed HSM.

• Redundancia de zonas: Cuando está disponible, la redundancia de zonas para Azure SQL Database o Azure SQL Managed Instance proporciona una resiliencia adicional dentro de una región. Para más información, consulte ¿Qué son las zonas de disponibilidad de Azure?.

• Permisos clave: Tanto el servidor principal como el secundario deben tener los permisos requeridos en cada Azure Key Vault o Azure Managed HSM que contenga un protector TDE requerido.

• Disponibilidad de claves: Asegúrate de que las claves requeridas estén disponibles tanto en el servidor principal como en el secundario. Los servidores no necesitan usar protectores TDE idénticos, pero cada servidor debe tener el mismo material de clave. Puedes añadir claves a un servidor usando el portal de Azure, PowerShell, CLI de Azure o la API REST de Azure SQL. Si las claves requeridas no están disponibles en el momento de la conmutación por error, la base de datos podría volverse inaccesible.

• Puntos finales privados: La configuración podría requerir una zona DNS más compleja si usas puntos finales privados en Azure SQL (por ejemplo, no puede crear dos puntos finales privados para el mismo recurso en la misma zona DNS).

• Conectividad de aplicaciones: Las aplicaciones deben utilizar lógica de reintentos para gestionar fallos transitorios durante la conmutación por error.

Para obtener información sobre cómo configurar el recurso de recuperación geográfica ante desastres de Azure SQL, consulte Replicación geográfica activa o Descripción general y procedimientos recomendados de los grupos de conmutación por error.

El siguiente diagrama muestra la replicación geográfica de Azure SQL con un grupo de conmutación por error y la conmutación por error entre regiones de Azure Key Vault en una configuración de regiones emparejadas:

Comportamiento de Azure Key Vault durante el failover

• Azure Key Vault inicia la conmutación por error, no el usuario.
• Mientras el almacén de claves de la región primaria no esté disponible, el almacén de claves estará en modo de solo lectura.
• Solo puedes crear, importar y rotar claves mientras el refugio de claves en la región principal esté disponible. Tras una conmutación por error, la rotación de claves permanece bloqueada hasta que la región primaria vuelva a ser accesible.
• No puedes elegir ni consultar en qué región se encuentra actualmente el almacén de claves, ni conectarte manualmente a la región secundaria.

Recuperarse de un protector TDE inaccesible

Si una base de datos de una relación activa de georreplicación o de un grupo de conmutación por error se vuelve inaccesible, el plano de control de Azure SQL interrumpe el vínculo y la convierte en una base de datos independiente.

Después de restaurar los permisos clave, normalmente puedes volver a poner la base de datos principal en línea. No puedes volver a poner la base de datos secundaria en línea porque Azure SQL no acepta copias de seguridad completas de bases de datos secundarias. Elimine la base de datos secundaria y, a continuación, vuelva a establecer el vínculo de replicación geográfica o el grupo de conmutación por error.

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.

Contenido relacionado

• Rotación del protector de cifrado de datos transparente (TDE)
• Eliminación de un protector de cifrado de datos transparente (TDE) mediante PowerShell
• Administración del Cifrado de datos transparente en SQL Managed Instance con su propia clave mediante PowerShell
• Microsoft Defender para SQL
• Referencia de configuración modificable para Azure SQL Database