Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Con el cifrado de datos con claves administradas por el cliente para Azure Database for MySQL, puede traer 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
Azure Key Vault Managed HSM (módulo de seguridad de hardware) se admite actualmente para claves administradas por el cliente para Azure Database for MySQL.
Ventajas
El cifrado de datos con claves administradas por el cliente para 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). Actualmente, Azure Database for MySQL solo admite la identidad administrada asignada por el usuario (UMI). Para más información, consulte Tipos de identidad administrada en Azure.
Para configurar la CMK para una instancia de Azure Database for MySQL, debe vincular el 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.
- Lista: enumere las versiones de la clave almacenadas en un almacén de claves.
- Clave de envoltura: para poder cifrar el DEK. La DEK cifrada se almacena en la instancia del servidor flexible de Azure Database for MySQL.
- Desencapsular clave: para poder descifrar la DEK. 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 Managed HSM, asigne el rol Usuario de cifrado del servicio criptográfico de Managed HSM.
Terminología y descripción
Clave de cifrado de datos (DEK): clave AES256 simétrica que se usa 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): clave de cifrado que se usa para cifrar los 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 propiedad del cliente. Key Vault es un almacenamiento seguro escalable y de alta disponibilidad para claves criptográficas RSA, respaldado opcionalmente por módulos de seguridad de hardware validados (HSM) 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 envía la DEK protegida al almacén de claves para el descifrado cuando sea necesario.
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 eventos de auditoría de Key Vault, consulte Supervisión del servicio key vault con Key Vault Insights.
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 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.
- Los 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 suave en el Key Vault con un período de retención establecido en 90 días para protegerse contra la pérdida de datos en caso de que se produzca una eliminación accidental de una clave (o del propio Key Vault). Las acciones recover y purge tienen sus propios permisos na directiva de acceso a Key Vault. La característica eliminada temporalmente está desactivada de forma predeterminada, pero puede habilitarla a través de 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.
- La clave debe estar en estado Habilitado .
- La clave debe tener eliminación suave cuyo período de retención esté establecido en 90 días. Esto establece implícitamente el atributo de clave necesario recoveryLevel: "Recuperable".
- La clave debe tener habilitada la protección de purga.
- Si va a importar una clave existente en el almacén de claves, asegúrese de proporcionarla en los formatos de archivo admitidos (
.pfx
,.byok
,.backup
).
Nota
Para obtener instrucciones detalladas y paso a paso sobre cómo configurar el cifrado de fechas para Azure Database for MySQL a través de Azure Portal, consulte Cifrado de datos para Azure Database for MySQL: servidor flexible mediante Azure Portal.
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 obtener más información sobre el comando de copia de seguridad, vea 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 de servidor flexible de Azure Database for MySQL no puede acceder a la clave y se mueve al estado Inaccesible . Recupere el almacén de claves y vuelva a validar el cifrado de datos para que la instancia de servidor flexible de Azure Database for MySQL esté disponible.
- Si elimina la clave del almacén de claves, la instancia de servidor flexible de Azure Database for MySQL no puede acceder a la clave y se mueve al estado Inaccesible . Recupere la clave y vuelva a validar el cifrado de datos para que la instancia de servidor flexible de Azure Database for MySQL esté disponible.
- Si la clave almacenada en Azure Key Vault expira, la clave deja de ser válida y la instancia de servidor flexible de Azure Database for MySQL pasa 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 de 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 unwrapping 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 en el acceso a la clave de cliente en key Vault administrado por el cliente, se agregan entradas 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 enviar 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 de servidor flexible de Azure Database for MySQL con una clave administrada por el cliente que ya tiene una réplica, se recomienda configurar una o varias réplicas agregando la identidad administrada y la clave. Supongamos que la instancia de 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 de 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 de la instancia del servidor flexible de Azure Database for MySQL.
- En el servidor restaurado o de 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 recibe permisos Get, List, Wrap key y Unwrap key en la clave almacenada en Key Vault.
Nota
El uso de la misma identidad y clave que en el servidor de origen no es obligatorio al realizar una restauración.