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.
Mediante el cifrado de datos con claves administradas por el cliente para Azure Database for MySQL, puede usar su propia clave (BYOK) para proteger los datos en reposo e implementar la separación de funciones en la administración de claves y datos. Al usar claves administradas por el cliente (CMK), puede controlar lo siguiente:
- Administración del ciclo de vida de las claves, incluida la creación, carga, rotación y eliminación de claves
- Permisos de uso de claves
- Operaciones de auditoría de las claves
Ventajas de las claves administradas por el cliente (CMK)
El cifrado de datos con claves administradas por el cliente para Azure Database for MySQL proporciona las siguientes ventajas:
- Para controlar completamente el acceso a los datos, quite la clave y haga que la base de datos sea inaccesible.
- Tienes control total sobre el ciclo de vida de las claves, incluida la rotación de las mismas para ajustarse a las directivas corporativas.
- Puede administrar y organizar claves de forma centralizada en Azure Key Vault o HSM administrado.
- Puede implementar la separación de tareas entre los responsables de seguridad, el DBA y los administradores del sistema.
¿Cómo funciona el cifrado de datos con una clave administrada por el cliente?
Las identidades administradas de Microsoft Entra ID proporcionan una manera más segura de autenticar a los clientes en los servicios. El cifrado de CMK usa la identidad administrada del servidor de Azure Database for MySQL para conectarse a Azure Key Vault que almacena la CMK. Azure Database for MySQL actualmente solo admite la identidad administrada asignada por el usuario (UAMI) para acceder al Key Vault. Para más información, consulte Tipos de identidad administrada en Azure.
Para configurar la CMK para una Azure Database for MySQL, vincule la UAMI al servidor y especifique el Azure Key Vault y la clave que se van a usar.
La UAMI necesita los siguientes accesos a la bóveda de claves:
- Get: para recuperar la parte pública y las propiedades de la clave en el almacén de claves.
- Lista: para enumerar las versiones de la clave almacenadas en un Key Vault.
- Clave de encapsulación: Para cifrar la DEK. La DEK cifrada se almacena en la instancia del servidor flexible de Azure Database for MySQL.
- Desencapsular clave: para descifrar la DEK. Azure Database for MySQL necesita la DEK descifrada para cifrar o descifrar los datos.
Si Azure RBAC está habilitado, asigne roles a UAMI en lugar de acceso individual.
-
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.
Establezca el cifrado de datos con CMK en el nivel de servidor. Para un servidor determinado, use 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 la clave para entidades autorizadas. El almacén de claves puede generar la clave o transferirla 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.
Después de habilitar el registro, los auditores pueden usar Azure Monitor para revisar Key Vault registros de eventos de auditoría. Para habilitar el registro de eventos de auditoría de Key Vault, consulte Supervisión del servicio key vault con Key Vault Insights.
Note
Los cambios de permisos pueden tardar hasta 10 minutos en afectar al almacén de claves.
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. Debe volver a configurar el cifrado de datos si mueve los 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.
- Habilita la función Eliminación suave en el almacén de claves.
- Habilite la protección de purga.
- Establezca el período de retención en 90 días.
- 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.
Antes de intentar configurar la CMK, asegúrese de satisfacer los siguientes requisitos.
- La clave administrada por el cliente para cifrar la DEK solo puede ser asimétrica, RSA\RSA-HSM(Vaults 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. No se ha establecido la fecha de expiración.
- El estado de la clave debe ser Habilitada.
- La clave debe tener eliminación suave cuyo período de retención esté establecido en 90 días. Esta configuración establece implícitamente el atributo clave necesario
recoveryLevelaRecoverable. - 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).
Note
Para obtener instrucciones detalladas y paso a paso sobre cómo configurar el cifrado de datos, consulte Cifrado de datos para Azure Database for MySQL con Azure Portal o Cifrado de datos para Azure Database for MySQL: servidor flexible con la CLI de Azure.
Recomendaciones para configurar el cifrado de datos
Al configurar Key Vault o HSM administrado para usar el cifrado de datos con 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.
- 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.
Note
El almacén de claves que use debe estar en la misma región que el servidor de bases de datos.
Condición de clave administrada por el cliente inaccesible
Al configurar el cifrado de datos con una CMK en Key Vault, el servidor requiere acceso continuo a esta clave para mantenerse 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 se elimina el almacén de claves, la instancia de servidor flexible de Azure Database for MySQL no puede acceder a la clave y pasa al estado Inaccessible. Para que la instancia Availabledel servidor sea :
- Recupere el almacén de claves.
- Vuelva a validar el cifrado de datos.
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 Inaccessible estado. Para que la instancia Availabledel servidor sea :
- Recupere la clave.
- Vuelva a validar el cifrado de datos.
Note
Incluso si la clave expira, el servidor permanece accesible por diseño para evitar el tiempo de inactividad.
Revocación accidental del acceso a la clave de Key Vault
Alguien con derechos de acceso suficientes para Key Vault podría deshabilitar accidentalmente el acceso flexible del servidor a la clave:
- 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 habilitar las alertas para la pérdida de acceso al protector de cifrado de datos transparente, 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
Al cifrar una instancia de servidor flexible Azure Database for MySQL con la clave administrada de un cliente almacenada en Key Vault, cualquier copia recién creada del servidor también se cifra. Al intentar cifrar una instancia de servidor flexible Azure Database for MySQL con una clave administrada por el cliente que ya tiene una réplica, configure una o varias réplicas agregando la identidad administrada y la clave. Si configura la instancia de servidor flexible Azure Database for MySQL con copia de seguridad de redundancia geográfica, debe configurar la réplica con la identidad administrada y la clave a la que tiene acceso la identidad y que reside en la región de emparejamiento geográfico del servidor.
Restauración con la clave administrada por el cliente en Key Vault
Al restaurar una instancia de servidor flexible Azure Database for MySQL, seleccione la identidad administrada por el usuario y la clave para cifrar el servidor de restauración. Si la instancia de servidor flexible de Azure Database for MySQL está configurada con copia de seguridad con redundancia geográfica, debe configurar el servidor de restauración con la identidad administrada y la clave a la que esta identidad tiene acceso y que reside en la región emparejada geográficamente del servidor.
Durante la restauración o la creación de una réplica de lectura, sigue estos pasos en el servidor de origen y en los servidores restaurados o réplicas:
- 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 CMK en la configuración de cifrado de datos para comprobar los permisos de la UAMI sobre la clave.
Note
No es necesario usar la misma identidad (UAMI) y la misma clave que en el servidor de origen al realizar una restauración.