Compartir a través de

Cifrado de datos con clave administrada por el cliente para Azure Database for MySQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for MySQL: servidor flexible

Con el cifrado de datos con claves administradas por el cliente para Servidor flexible de Azure Database for MySQL, puede aportar su propia clave (BYOK) para la protección de datos en reposo e implementar la separación de tareas para administrar claves y datos. Con las claves administradas por el cliente, (CMK), este es responsable y tiene el control 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.

Nota:

HSM administrado (módulo de seguridad de hardware) de Azure Key Vault se admite actualmente para las claves administradas por el cliente para el servidor flexible de Azure Database for MySQL.

Ventajas

El cifrado de datos con claves administradas por el cliente para el Servidor flexible de Azure Database for MySQL proporciona las siguientes ventajas:

  • Controla por completo el acceso a los datos mediante la posibilidad de eliminar la clave y hacer que la base de datos sea inaccesible
  • Control total sobre el ciclo de vida de la clave, incluida la rotación de esta para cumplir con las directivas corporativas
  • Organización y administración central de las claves en Azure Key Vault o HSM administrado
  • Posibilidad de implementar la separación de tareas entre los responsables de seguridad y los administradores del sistema y de las bases de datos

¿Cómo funciona el cifrado de datos con una clave administrada por el cliente?

Las identidades administradas en Microsoft Entra ID proporcionan a los servicios de Azure una alternativa al almacenamiento de credenciales en el código mediante el aprovisionamiento de una identidad asignada automáticamente que se puede usar para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra, como Azure Key Vault (AKV). El Servidor flexible de Azure Database for MySQL actualmente solo admite identidades administradas asignadas por el usuario (UMI). Para más información, vea Tipos de identidad administrada en Azure.

Para configurar la CMK para un Servidor flexible de Azure Database for MySQL, debe vincular la UMI al servidor y especificar el almacén de claves de Azure y la clave que se va a usar.

El UMI debe tener el siguiente acceso al almacén de claves:

  • Get: para recuperar la parte pública y las propiedades de la clave en el almacén de claves.
  • List: para enumerar las versiones de una clave almacenadas en un almacén de claves.
  • Wrap Key: para poder cifrar la DEK. La DEK cifrada se almacena en la instancia del Servidor flexible de Azure Database for MySQL.
  • Unwrap Key: para poder descifrar la DEK. El Servidor flexible de Azure Database for MySQL necesita la DEK descifrada para cifrar o descifrar los datos.

Si RBAC está habilitado, el UMI también debe tener asignado el rol siguiente:

  • Usuario de cifrado del servicio criptográfico de Key Vault o el rol con los permisos:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/unwrap/action
    • Microsoft.KeyVault/vaults/keys/read como "Usuario de cifrado del servicio criptográfico de Key Vault"
  • Para HSM administrado, asigne el rol de usuario de cifrado del servicio criptográfico de HSM administrado

Terminología y descripción

Clave de cifrado de datos (DEK) : una clave simétrica AES256 que se emplea para cifrar una partición o un bloque de datos. Cifrar cada bloque de datos con una clave diferente dificulta los ataques de análisis criptográficos. El proveedor de recursos o la instancia de la aplicación necesita acceso a las DEK que cifran y descifran un bloque específico. Cuando se reemplaza una DEK por una nueva clave, solo se deben volver a cifrar los datos de su bloque asociado con la nueva clave.

Clave de cifrado de claves (KEK) : una clave de cifrado usada para cifrar las DEK. Una KEK que nunca abandona Key Vault permite el cifrado y control de las DEK. La entidad que tiene acceso a la KEK puede ser diferente de aquella que necesita la DEK. Puesto que la KEK es necesaria para descifrar la DEK, la KEK es de manera eficaz un punto único por el que se pueden eliminar de forma eficaz las DEK mediante la eliminación de la KEK. Las DEK, cifradas con las KEK, se almacenan por separado. Solo una entidad con acceso a la KEK puede descifrar estas DEK. Para más información, consulte Seguridad del cifrado en reposo.

Funcionamiento

El cifrado de datos con CMK se establece en el nivel de servidor. En un servidor determinado, se usa una CMK, denominada clave de cifrado de claves (KEK), para cifrar la clave de cifrado de datos (DEK) del servicio. KEK es una clave asimétrica almacenada en una instancia de Azure Key Vault administrada por el cliente y de su propiedad. Key Vault ofrece un almacenamiento seguro de alta disponibilidad y escalabilidad para claves criptográficas RSA respaldado opcionalmente por módulos de seguridad de hardware (HSM) validados con certificación FIPS 140. Key Vault no permite el acceso directo a una clave almacenada, sino que proporciona servicios de cifrado y descifrado mediante el uso de la clave en las entidades autorizadas. El almacén de claves importado puede generar la clave o puede transferirse al almacén de claves desde un dispositivo HSM local.

Cuando configura un servidor flexible para usar la CMK que se almacena en el almacén de claves, el servidor envía la DEK al almacén de claves para que la cifre. Key Vault devuelve las DEK cifradas que se almacenan en la base de datos del usuario. Del mismo modo, el servidor flexible enviará la DEK protegida al almacén de claves para el descifrado cuando sea necesario.

Diagrama de cómo funciona el cifrado de datos con una clave administrada por el cliente.

Los auditores pueden usar Azure Monitor para revisar los registros de eventos de auditoría de Key Vault, si está habilitado el registro. Para habilitar el registro de Key Vault eventos de auditoría, consulte Supervisión del servicio del almacén de claves con Key Vault información.

Nota

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

Requisitos de configuración del cifrado de datos para el Servidor flexible de Azure Database for MySQL

Antes de intentar configurar Key Vault o HSM administrado, asegúrese de abordar los siguientes requisitos.

  • Key Vault y la instancia del Servidor flexible de Azure Database for MySQL deben pertenecer al mismo inquilino de Microsoft Entra. Las interacciones de servidor flexible y Key Vault entre suscriptores deben ser compatibles. Deberá volver a configurar el cifrado de datos si mueve recursos de Key Vault después de realizar la configuración.
  • Key Vault y la instancia del Servidor flexible de Azure Database for MySQL deben residir en la misma región.
  • Habilite la característica de eliminación temporal en el almacén de claves con un período de retención establecido en 90 días, para contar con protección frente a la pérdida de datos en caso de que se produzca una eliminación accidental de claves (o de Key Vault). Las acciones recover y purge tienen sus propios permisos na directiva de acceso a Key Vault. La característica de eliminación temporal está desactivada de forma predeterminada, pero puede habilitarla a través de la Azure Portal o mediante PowerShell o la CLI de Azure.
  • Habilite la característica Protección de purga en el almacén de claves y establezca el período de retención en 90 días. Cuando la protección de purgas está activada, un almacén o un objeto en estado eliminado no se puede purgar hasta que haya transcurrido el período de retención. Puede habilitar esta característica mediante PowerShell o la CLI de Azure, y solo después de habilitar la eliminación temporal.

Antes de intentar configurar la CMK, asegúrese de satisfacer los siguientes requisitos.

  • La clave administrada por el cliente para cifrar las DEK solo puede ser asimétrica, RSA o RSA-HSM(almacenes con SKU Premium) 2048,3072 o 4096.
  • La fecha de activación de la clave (si se establece) debe ser una fecha y hora del pasado. La fecha de expiración no está establecida.
  • El estado de la clave debe ser Habilitada.
  • La clave debe tener habilitada la eliminación temporal con un período de retención establecido en 90 días. Esto establece implícitamente el atributo de clave necesario recoveryLevel: "recuperable".
  • La clave debe tener la protección de purgas habilitada.
  • Si va a importar una clave existente en el almacén de claves, asegúrese de proporcionarla en uno de los formatos de archivo compatibles (.pfx, .byok, .backup).

Nota:

Para obtener instrucciones detalladas paso a paso sobre cómo configurar el cifrado de fecha para un Servidor flexible de Azure Database for MySQL a través de Azure Portal, consulte Configuración del cifrado de datos para el Servidor flexible de Azure Database for MySQL.

Recomendaciones para configurar el cifrado de datos

A medida que configure Key Vault o HSM administrado para usar el cifrado de datos mediante una clave administrada por el cliente, tenga en cuenta las siguientes recomendaciones.

  • Establezca un bloqueo de recursos en Key Vault para controlar quién puede eliminar este recurso crítico e impedir la eliminación accidental o no autorizada.
  • Habilite la auditoría y la generación de informes en todas las claves de cifrado. 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 Azure Monitor es un ejemplo de un servicio que ya está integrado.
  • Almacene una copia de la clave administrada por el cliente en un lugar seguro o en el servicio de custodia.
  • Si Key Vault genera la clave, cree una copia de seguridad de ella antes de usarla por primera vez. Solo se puede restaurar la copia de seguridad en Key Vault. Para más información sobre del comando backup, consulte Backup-AzKeyVaultKey.

Nota

  • Se recomienda usar un almacén de claves de la misma región, pero, si fuera necesario, puede usar un almacén de claves de otra región especificando la información de "escribir identificador de clave". El almacén de claves o el HSM administrado deben estar en la misma región que el servidor flexible de MySQL.

Condición de clave administrada por el cliente inaccesible

Cuando se configura el cifrado de datos con una clave administrada por el cliente en Key Vault, es necesario el acceso continuo a esta clave para que el servidor permanezca en línea. Si el servidor flexible pierde el acceso a la clave administrada por el cliente en Key Vault, comienza a denegar todas las conexiones al cabo de 10 minutos. El servidor flexible emite un mensaje de error correspondiente y cambia su estado a Inaccesible. El servidor puede llegar a este estado por varios motivos.

  • Si elimina el almacén de claves, la instancia del Servidor flexible de Azure Database for MySQL no podrá tener acceso a la clave y se moverá al estado Inaccesible. Recupere el almacén de claves y vuelva a validar el cifrado de datos para que la instancia del Servidor flexible de Azure Database for MySQL esté Disponible.
  • Si elimina la clave del almacén de claves, la instancia del Servidor flexible de Azure Database for MySQL no podrá tener acceso a la clave y se moverá al estado Inaccesible. Recupere la clave y vuelva a validar el cifrado de datos para que la instancia del Servidor flexible de Azure Database for MySQL esté Disponible.
  • Si expira la clave almacenada en Azure KeyVault, dejará de ser válida y la instancia del Servidor flexible de Azure Database for MySQL pasará al estado Inaccesible. Amplíe la fecha de expiración de la clave mediante la CLI y vuelva a validar el cifrado de datos para que la instancia del Servidor flexible de Azure Database for MySQL esté Disponible.

Revocación accidental del acceso a la clave de Key Vault

Podría suceder que alguien con derechos de acceso suficientes a Key Vault deshabilitara por accidente el acceso del servidor flexible a la clave de la siguiente forma:

  • Mediante la revocación de los permisos get, list, wrap key y unwrap key del servidor
  • Con la eliminación de la clave.
  • A través de la eliminación del almacén de claves.
  • Mediante el cambio de las reglas de firewall del almacén de claves.
  • Con la eliminación de la identidad administrada por el usuario usada para el cifrado en el servidor flexible con una clave administrada por el cliente en Microsoft Entra ID.

Supervisión de la clave administrada por el cliente en Key Vault

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

  • Registro de actividad: cuando se produce un error de acceso a la clave de cliente en Key Vault administrado por el cliente, las entradas se agregan al registro de actividad. Puede restablecer el acceso tan pronto como sea posible si crea alertas para estos eventos.
  • Grupos de acciones: defina estos grupos para enviarle notificaciones y alertas en función de sus preferencias.

Réplica con una clave administrada por el cliente en Key Vault

Después de cifrar la instancia del Servidor flexible de Azure Database for MySQL con la clave administrada de un cliente almacenada en Key Vault, también se cifra cualquier copia recién creada del servidor. Al intentar cifrar una instancia del Servidor flexible de Azure Database for MySQL con una clave administrada por el cliente que ya tenga réplicas, se recomienda configurar estas últimas al agregar la identidad administrada y la clave. Supongamos que la instancia del Servidor flexible de Azure Database for MySQL está configurada con copia de seguridad de redundancia geográfica. En ese caso, la réplica debe configurarse con la identidad administrada y la clave a la que tiene acceso la identidad y que reside en la región emparejada geográficamente del servidor.

Restauración con la clave administrada por el cliente en Key Vault

Al intentar restaurar una instancia del Servidor flexible de Azure Database for MySQL, puede seleccionar la identidad administrada por el usuario y la clave para cifrar el servidor de restauración. Supongamos que la instancia del Servidor flexible de Azure Database for MySQL está configurada con copia de seguridad de redundancia geográfica. En ese caso, debe configurar el servidor de restauración con la identidad administrada y la clave a la que tiene acceso la identidad y que reside en la región emparejada geográficamente del servidor.

Para evitar incidencias al configurar el cifrado de datos administrado por el cliente durante la restauración o la creación de réplicas de lectura, es importante seguir estos pasos en el servidor de origen o en el servidor de réplica o restaurado:

  • Inicie el proceso de restauración o creación de la réplica de lectura desde la instancia de origen del Servidor flexible de Azure Database for MySQL.
  • En el servidor restaurado/réplica, vuelva a validar la clave administrada por el cliente en la configuración de cifrado de datos para asegurarse de que la identidad administrada por el usuario tenga los permisos Get, List, Wrap key y Unwrap key para la clave almacenada en Key Vault.

Nota

Al efectuar una restauración, no es obligatorio usar la misma identidad y clave que en el servidor de origen.

Pasos siguientes