Customer-managed TDE for Azure Synapse Analytics

Se aplica a: grupos de SQL dedicados de Azure Synapse Analytics (anteriormente SQL DW)

Tip

Microsoft Fabric Data Warehouse es un almacenamiento relacional de escala empresarial en una base de lago de datos, con una arquitectura lista para el futuro, inteligencia artificial integrada y nuevas características. Si no está familiarizado con el almacenamiento de datos, comience con Fabric Data Warehouse. Las cargas de trabajo del grupo dedicado de SQL pueden actualizarse a Fabric para acceder a funcionalidades avanzadas en ciencia de datos, análisis en tiempo real e informes.

El cifrado transparente de datos (TDE) con clave gestionada por el cliente (CMK) permite el escenario de Traer tu propia clave (BYOK) para la protección de datos en reposo, y permite a las organizaciones implementar la separación de funciones en la gestión de claves y datos. Al utilizar TDE administrado por el cliente, asumes la responsabilidad y tienes el control total de la gestión del ciclo de vida de las claves (creación, carga, rotación y eliminación), de los permisos de uso de las claves y de la auditoría de las operaciones realizadas con 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.

Note

Este artículo trata sobre pools SQL dedicados independientes (anteriormente SQL DW).

  • Para los pools SQL dedicados de Azure Synapse Analytics (anteriormente SQL DW), configura el protector TDE a nivel de servidor. Todas las bases de datos cifradas asociadas a ese servidor heredan el protector TDE.
  • Cifra los datos en pools SQL dedicados y pools SQL serverless en un espacio de trabajo Synapse usando la clave gestionada por el cliente configurada a nivel de espacio de trabajo. 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.

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) - Administras el ciclo de vida de la clave, incluida la creación, rotación y eliminación de la clave. Guarde la clave en Azure Key Vault o Azure Managed HSM y úsela para cifrar la Clave de cifrado de base de datos (DEK).

  • Traiga su propia clave (BYOK): traiga o importe de forma segura su propia clave desde un módulo de seguridad de hardware (HSM) local a 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).

Ventajas del TDE administrado por el cliente

El TDE administrado por el cliente ofrece 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 quienes usan TDE gestionado por servicios y quieren empezar a usar TDE gestionado por el cliente, los datos permanecen cifrados durante el proceso de cambio y no hay tiempo de inactividad ni re-cifrado de los archivos de la base de datos. El cambio de una clave administrada por el servicio a una clave administrada por el cliente solo requiere el nuevo cifrado de la DEK, que es una operación rápida y en línea.

Permisos para configurar el TDE administrado por el cliente en Azure Key Vault

Seleccione el tipo de Azure Key Vault que desea usar.

Para que el servidor lógico SQL de Azure use el protector de TDE almacenado en Azure Key Vault para cifrar el DEK, el Key Vault Administrator 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 tener asignado el rol Key Vault Crypto Service Encryption User para usar la clave en 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 necesita los siguientes permisos en la bóveda 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 instrucciones paso a paso sobre cómo configurar una configuración de acceso a Azure Key Vault para TDE, consulta Configurar SQL Server TDE Extensible Key Management usando 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 configuras un servidor para usar un protector TDE de Azure Key Vault, el servidor envía el DEK de cada base de datos habilitada por TDE al Key Vault para su cifrado. El almacén de claves devuelve la DEK cifrada, que el servidor almacena en la base de datos de usuario.

Cuando es necesario, el servidor envía el DEK protegido a la bóveda de claves para su descifrado.

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

Note

Puede que los cambios de permisos en el almacén de claves tarden unos 10 minutos en hacer efecto. Este tiempo incluye la revocación de los permisos de acceso al protector de TDE en AKV, y es posible que los usuarios aún tengan permisos de acceso.

Requisitos para configurar TDE gestionado por el cliente en Azure Key Vault

  • Activa las funciones de eliminación temporal y de protección contra purga en Azure Key Vault. Esta configuración ayuda a evitar la eliminación accidental o malintencionada del almacén de claves o de la clave, lo que puede dejar la base de datos en estado Inaccesible. Cuando configuras el protector TDE en un servidor existente o durante la creación del servidor, Azure SQL valida que la bóveda de claves que estás usando tiene activada la protección contra eliminación suave y 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, habilite la eliminación temporal y la protección de purga en el almacén de claves y, a continuación, realice 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 clave para configurar el protector de TDE

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

Se aplican los siguientes requisitos.

Tamaños y tipos de clave admitidos

El protector TDE puede estar respaldado por claves asimétricas almacenadas en Azure Key Vault. Los tamaños de clave admitidos son de 2048 bits y 3072 bits.

Requisitos principales de estado y validez

  • Si especificas una fecha de activación de clave, establécela en una fecha y hora pasadas.
  • Si especificas una fecha de caducidad de la clave, ponla en una fecha y hora futuras.
  • 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

Recomendaciones para configurar TDE gestionado por clientes en Azure Key Vault

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

  • Para garantizar un rendimiento y fiabilidad óptimos, utiliza un Azure Key Vault dedicado para Azure SQL. No compartas esta bóveda de llaves con otros servicios. Si la bóveda de claves está sometida a una carga elevada debido al uso compartido o a un número excesivo de operaciones con claves, puede afectar negativamente al rendimiento de la base de datos, especialmente al acceder a las claves 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. Este riesgo es mayor durante los conmutamientos por error del servidor, que activan operaciones clave para todas las bases de datos del servidor.

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

    • El número de bases de datos Hyperscale que puedes asociar con un solo Azure Key Vault depende del número de servidores de páginas. Cada servidor de páginas está vinculado a un archivo de datos lógico. Para encontrar el número de servidores de páginas, ejecuta la siguiente consulta.

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

      No asocies más de 500 servidores de páginas con un único 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áginas supera los 500, usa un Azure Key Vault dedicado para cada base de datos Hyperscale y no compartas ese Key Vault con otros recursos de Azure SQL.

    • Supervise y configure las alertas de Azure Key Vault. Para más información sobre monitorización y alertas, consulte Supervisión de Azure Key Vault y Configurar 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. Para aprender más sobre 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.

Recomendaciones para configurar el protector de TDE

  • Conserve una copia del protector de TDE en una ubicación segura o deposítela en un servicio de custodia.

  • Si generas la clave en el Key Vault, crea una copia de seguridad de la clave antes de usar la clave en Azure Key Vault por primera vez. Solo puedes restaurar la copia de seguridad únicamente en un Azure Key Vault. Para saber más, consulta el comando Backup-AzKeyVaultKey . Azure Managed HSM permite crear una copia de seguridad completa de todo el contenido del HSM, incluyendo 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.

  • Crea una nueva copia de seguridad cada vez que hagas algún cambio en la clave (por ejemplo, atributos de clave, etiquetas, ACLs).

  • 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).

  • Conserva todas las claves utilizadas previamente en Azure Key Vault incluso después de cambiar a claves administradas por el servicio. Garantiza que las copias de seguridad de la base de datos puedan restaurarse con los protectores TDE almacenados en Azure Key Vault. Los protectores TDE creados con Azure Key Vault deben mantenerse hasta que todas las copias de seguridad almacenadas restantes hayan sido creadas con claves gestionadas por servicios. Haz copias de seguridad recuperables de estas claves usando 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

Cuando rotas el protector TDE, reemplazas la clave que protege la clave de cifrado de la base de datos (DEK). La rotación de claves es una operación online y dura solo unos segundos. Esta operación descifra y vuelve a cifrar solo la clave de cifrado de la base de datos, no toda la base de datos.

Puedes rotar el protector TDE cambiando la configuración para usar una nueva clave almacenada en Azure Key Vault. Dependiendo de la oferta y la configuración soportada, esta clave puede ser:

  • Cambiar a una nueva versión de la misma clave
  • Cambiar a otra clave

La rotación del protector TDE puede realizarse manualmente o mediante la función de rotación automática.

Puedes activar la rotación automática del protector TDE cuando configuras el protector TDE para el servidor. La rotación automática está desactivada de manera predeterminada. Cuando esta opción está habilitada, el servidor comprueba continuamente la bóveda de claves en busca de nuevas versiones de la clave utilizada como protector de TDE. Si el servidor detecta una nueva versión de la clave, rota automáticamente el protector TDE del servidor o base de datos a la última versión de clave en un plazo de 24 horas.

Note

Cuando configuras TDE con CMK usando la rotación manual o automatizada de las claves, siempre usas la última versión de la clave que soporta el sistema. La configuración no permite usar una versión anterior o inferior de las claves. El uso de la versión de clave más reciente cumple con la directiva de seguridad de Azure SQL que no permite versiones de clave anteriores que puedan verse en peligro.

Protector de TDE inaccesible

Cuando configuras TDE para usar una clave gestionada por el cliente, la base de datos necesita acceso continuo al protector TDE para mantenerse en línea. Si el servidor pierde el acceso al protector TDE gestionado por el cliente en Azure Key Vault, la base de datos empieza a denegar todas las conexiones en un plazo de 10 minutos, muestra un mensaje de error 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 errores de red o interrupciones al acceder al protector TDE en Azure Key Vault, el servicio introduce un buffer de 24 horas antes de intentar 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 TDE gestionado por el cliente en Azure Key Vault debido a cualquier error de Azure Key Vault (como un error 4XX), la base de datos pasa a un estado inaccesible tras 30 minutos.

Restaurar el acceso a la base de datos tras un error en Azure Key Vault

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

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 son:

  • Azure Key Vault se expone a través de un endpoint privado y la dirección IP privada del servicio Azure Key Vault no está permitida en las reglas salientes del Network Security Group (NSG) asociadas a la subred de instancias gestionadas.

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

Prueba la conectividad desde SQL Managed Instance hasta Azure Key Vault que aloja el protector 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 perdió el acceso al protector TDE aparece como "No disponible" después de que se deniegue 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. Creando alertas para estos eventos, puedes restablecer el acceso lo antes posible.

  • Se pueden definir grupos de acciones para enviarte notificaciones y alertas según tus preferencias, por ejemplo, Correo electrónico, SMS, Push, Voz, Logic App, Webhook, ITSM o runbook de automatización.

Copia de seguridad y restauración de bases de datos con TDE gestionado por el cliente

Una vez que una base de datos está cifrada con TDE usando una clave de Azure Key Vault, cualquier copia de seguridad recién generada también se cifra con el mismo protector 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 TDE de Azure Key Vault, asegúrate de que el material de la clave esté disponible para el servidor objetivo. Por lo tanto, mantén todas las versiones antiguas del protector TDE en Key Vault o HSM gestionado, para que se puedan 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 el DEK, pero pueden usarse durante la restauración desde una copia de seguridad si el archivo de copia de seguridad está cifrado con la clave con la huella 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 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 un grupo de SQL dedicado en Azure Synapse Analytics, consulte Recuperación de un grupo de SQL dedicado.

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 utiliza un protector TDE almacenado en Azure Key Vault, esta clave es necesaria en el momento de restauración, incluso si la base de datos se ha cambiado para usar TDE gestionado por servicios mientras tanto.

Alta disponibilidad con TDE administrado por el cliente

Al utilizar las múltiples capas de redundancia de Azure Key Vault, los TDEs que utilizan una clave gestionada por el cliente pueden beneficiarse de la disponibilidad y resiliencia de Azure Key Vault. Pueden confiar plenamente en la solución de redundancia de Azure Key Vault.

Las múltiples capas de redundancia de Azure Key Vault garantizan el acceso a claves incluso si los componentes individuales del servicio fallan o las regiones o zonas de disponibilidad de Azure están caídas. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault.

Azure Key Vault ofrece los siguientes componentes de disponibilidad y resiliencia de forma automática sin intervención del usuario:

Contenido relacionado

  • Se actualizó por última vez el