Chiffrement des données avec des clés gérées par le client pour Azure Database pour MySQL

En utilisant le chiffrement des données avec des clés gérées par le client pour Azure Database pour MySQL, vous pouvez apporter votre propre clé (BYOK) pour la protection des données au repos afin d’implémenter la séparation des tâches de gestion des clés et des données. Lorsque vous utilisez des clés gérées par le client (CMK), vous contrôlez :

• Gestion du cycle de vie des clés, y compris la création de clés, le chargement, la rotation et la suppression
• Autorisations d’utilisation des clés
• Opérations d’audit sur les clés

Avantages des clés gérées par le client (CMK)

Le chiffrement des données d’Azure Database pour MySQL en utilisant des clés gérées par le client offre les avantages suivants :

• Vous contrôlez entièrement l’accès aux données en supprimant la clé et en rendant la base de données inaccessible.
• Vous avez un contrôle total sur le cycle de vie des clés, y compris le renouvellement de la clé afin de respecter les politiques de l’entreprise.
• Vous pouvez gérer et organiser de manière centralisée les clés dans Azure Key Vault ou le HSM managé.
• Vous pouvez implémenter la séparation des tâches entre les agents de sécurité, l’administrateur de base de données et les administrateurs système.

Comment fonctionne le chiffrement des données avec une clé gérée par le client ?

Les identités managées dans Microsoft Entra ID offrent un moyen plus sécurisé d’authentifier les clients auprès des services. Le chiffrement CMK utilise l’identité managée du serveur Azure Database pour MySQL pour se connecter à Azure Key Vault qui stocke la clé CMK. Azure Database pour MySQL prend actuellement en charge uniquement l’identité managée affectée par l’utilisateur (UAMI) pour l’accès au Key Vault. Pour plus d’informations, consultez Types d’identités managées dans Azure.

Pour configurer la clé CMK pour un Azure Database pour MySQL, liez l’UAMI au serveur et spécifiez la Azure Key Vault et la clé à utiliser.

L’UAMI a besoin de l’accès suivant au coffre de clés :

• Obtenir : pour récupérer la partie publique et les propriétés de la clé dans le coffre de clés.
• Liste : Pour répertorier les versions de la clé stockée dans un Key Vault.
• Clé d’encapsulation : pour chiffrer le DEK. La clé DEK chiffrée est stockée dans l’instance de serveur flexible Azure Database pour MySQL.
• Déballer la clé : pour déchiffrer la DEK. Azure Database pour MySQL a besoin de la clé DEK déchiffrée pour chiffrer ou déchiffrer les données.

Si Azure RBAC est activé, attribuez des rôles à l’UAMI au lieu d’un accès individuel.

• Utilisateur du chiffrement du service cryptographique du coffre de clés ou le rôle disposant des autorisations suivantes :
  • Microsoft.KeyVault/vaults/keys/wrap/action
  • Microsoft.KeyVault/vaults/keys/unwrap/action
  • Microsoft.KeyVault/vaults/keys/read like « Key Vault Crypto Service Encryption User »
• Pour le HSM managé, attribuez le rôle Utilisateur du chiffrement du service cryptographique du HSM managé

Définissez le chiffrement des données avec des clés CMK au niveau du serveur. Pour un serveur donné, utilisez une clé CMK, appelée clé de chiffrement de clé (KEK), pour chiffrer la clé de chiffrement des données du service (DEK). La clé KEK est une clé asymétrique stockée dans une instance Azure Key Vault détenue et gérée par le client. Key Vault fournit un stockage sécurisé hautement disponible et évolutif pour les clés de chiffrement RSA, éventuellement doté de modules de sécurité matériels (HSM) validés par les normes FIPS 140. Key Vault n'autorise pas l'accès direct à une clé stockée, mais fournit plutôt des services de chiffrement et de déchiffrement à l'aide de la clé pour les entités autorisées. Le coffre de clés peut générer la clé ou la transférer vers le coffre de clés à partir d’un appareil HSM local.

Lorsque vous configurez un serveur flexible pour utiliser une clé CMK stockée dans le coffre de clés, le serveur envoie la clé DEK au coffre de clés pour le chiffrement. Key Vault retourne la clé DEK chiffrée qui est stockée dans la base de données utilisateur. De même, le serveur flexible envoie la clé DEK protégée au coffre de clés pour le déchiffrement si nécessaire.

Une fois la journalisation activée, les auditeurs peuvent utiliser Azure Monitor pour passer en revue Key Vault journaux des événements d’audit. Pour activer la journalisation des événements d’audit de Key Vault, consultez Surveillance de votre service de coffre de clé avec les insights de Key Vault.

Conditions requises de la configuration du chiffrement des données pour Azure Database pour MySQL

Avant d’essayer de configurer le coffre de clés ou le HSM managé, vérifiez que les conditions suivantes sont remplies.

• Key Vault et l’instance de serveur flexible Azure Database pour MySQL doivent appartenir au même locataire Microsoft Entra. Les interactions entre un serveur flexible et un coffre de clés multilocataire doivent être prises en charge. Vous devez reconfigurer le chiffrement des données si vous déplacez Key Vault ressources après avoir effectué la configuration.
• Le coffre de clés et l’instance de serveur flexible Azure Database pour MySQL doivent résider dans la même région.
• Activez la fonctionnalité Soft Delete sur le coffre de clés.
• Activez la protection contre la purge.
• Définissez la période de rétention sur 90 jours.
  • Les actions de récupération et de vidage ont leurs propres autorisations dans une stratégie d’accès au coffre de clés.
  • La fonctionnalité de suppression réversible est désactivée par défaut.

Avant de tenter de configurer la clé CMK, veillez à remplir les conditions suivantes.

• La clé gérée par le client pour chiffrer la DEK ne peut être qu’asymétrique : RSA/RSA-HSM (coffres de clés avec SKU Premium) de 2048, 3072 ou 4096 bits.
• La date d’activation de la clé (si définie) doit être une date et une heure dans le passé. La date d’expiration n’est pas définie.
• La clé doit être dans l’état activé.
• La fonctionnalité de suppression réversible doit être activée pour la clé, avec une période de rétention définie sur 90 jours. Ce paramètre définit implicitement l’attribut recoveryLevel de clé requis sur Recoverable.
• La protection contre le vidage doit être activée sur la clé.
• Si vous importez une clé existante dans le coffre de clés, veillez à ce qu’elle soit dans l’un des formats de fichiers pris en charge (.pfx, .byok, .backup).

Recommandations pour la configuration du chiffrement de données

Lorsque vous configurez Key Vault ou managed HSM pour utiliser le chiffrement des données avec une clé gérée par le client, gardez à l’esprit les recommandations suivantes :

• Définissez un verrou de ressource sur le coffre de clés pour déterminer qui peut supprimer cette ressource critique et pour empêcher toute suppression accidentelle ou non autorisée.
• Activez l'audit et la création de rapports sur toutes les clés de chiffrement. Key Vault fournit des journaux faciles à injecter dans d’autres outils de gestion d’événements et d’informations de sécurité.
• Conservez une copie de la clé gérée par le client à un emplacement sécurisé ou déposez-la au service de dépôt.
• Si Key Vault génère la clé, créez-en une sauvegarde avant de l’utiliser pour la première fois. La sauvegarde ne peut être restaurée que dans Key Vault. Pour plus d'informations sur la commande de sauvegarde, consultez Backup-AzKeyVaultKey.

Condition de clé gérée par le client inaccessible

Lorsque vous configurez le chiffrement des données avec une clé CMK dans Key Vault, le serveur nécessite un accès continu à cette clé pour rester en ligne. Si le serveur flexible perd l’accès à la clé gérée par le client dans Key Vault, il commence à refuser toutes les connexions dans un délai de 10 minutes. Le serveur flexible émet un message d’erreur correspondant et affiche l’état Inaccessible. Le serveur peut atteindre cet état pour diverses raisons.

Si vous supprimez le coffre de clés, l’instance Azure Database pour MySQL - Serveur flexible ne peut plus accéder à la clé et passe à l’état Inaccessible. Pour rendre l’instance de serveur Available:

• Récupérez le coffre de clés.
• Revalidez le chiffrement des données.

Si vous supprimez la clé du coffre de clés, l’instance du serveur flexible Azure Database pour MySQL ne peut pas accéder à la clé et passe à l’état Inaccessible. Pour rendre l’instance de serveur Available:

• Récupérez la clé.
• Revalidez le chiffrement des données.

Révocation accidentelle de l'accès aux clés de Key Vault

Une personne disposant de droits d’accès suffisants pour Key Vault peut désactiver accidentellement l’accès serveur flexible à la clé en :

• révoquant les autorisations obtenir, lister, inclure la clé, ne pas inclure la clé du coffre de clés à partir du serveur ;
• supprimant la clé ;
• supprimant le Key Vault ;
• modifiant les règles de pare-feu du coffre de clés ;
• en supprimant l’identité managée utilisateur employée pour le chiffrement sur le serveur flexible avec une clé gérée par le client dans Microsoft Entra ID.

Surveiller la clé gérée par le client dans Key Vault

Pour surveiller l’état de la base de données et activer les alertes pour la perte d’accès transparent du protecteur de chiffrement des données, configurez les fonctionnalités de Azure suivantes :

• Journal d’activité : lorsque l’accès à la clé client dans le Key Vault géré par le client échoue, des entrées sont ajoutées au Journal d’activité. La création d’alertes pour ces événements vous permettra de rétablir l’accès dès que possible.
• Groupes d'actions : définissez ces groupes pour envoyer des notifications et des alertes basées sur vos préférences.

Réplica avec une clé gérée par le client dans Key Vault

Lorsque vous chiffrez une instance de serveur flexible Azure Database pour MySQL avec la clé managée d'un client stockée dans Key Vault, toute copie nouvellement créée du serveur est également chiffrée. Lorsque vous essayez de chiffrer une instance de serveur flexible Azure Database pour MySQL avec une clé gérée par le client pour laquelle un réplica existe déjà, configurez un ou plusieurs réplicas en y ajoutant l’identité managée et la clé. Si vous configurez l’instance de serveur flexible Azure Database pour MySQL avec une sauvegarde géoredondante, vous devez configurer la réplique à l’aide de l’identité managée et de la clé auxquelles cette identité a accès, et cette clé doit se trouver dans la région géographiquement jumelée du serveur.

Restaurer avec une clé gérée par le client dans Key Vault

Lorsque vous restaurez une instance de serveur flexible Azure Database pour MySQL, sélectionnez l’identité et la clé gérées par l’utilisateur pour chiffrer le serveur de restauration. Si l'instance de serveur flexible Azure Database pour MySQL est configurée avec une sauvegarde de géoredondance, vous devez configurer le serveur de restauration avec l'identité managée et la clé auxquelles l'identité a accès et qui réside dans la région géo-jumelée du serveur.

Lors d’une restauration ou de la création d’une réplique en lecture, procédez comme suit sur le serveur source et sur le serveur restauré ou répliqué :

• Lancez le processus de création de réplicas en lecture ou de restauration à partir de l’instance de serveur flexible Azure Database pour MySQL source.
• Sur le serveur restauré ou le serveur répliqué, revalidez la CMK dans les paramètres de chiffrement des données afin de vérifier les autorisations de l’UAMI sur la clé.

Contenu connexe

• Chiffrement des données pour Azure Database pour MySQL - Serveur flexible avec Azure CLI
• Chiffrement des données pour Azure Database pour MySQL - Serveur flexible à l’aide du portail Azure
• Sécurité du chiffrement au repos
• Authentification Microsoft Entra pour Azure Database pour MySQL : Serveur flexible