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

Avec 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 et implémenter la séparation des tâches pour la gestion des clés et des données. Avec les clés gérées par le client (CMK), le client a la responsabilité et finalement le contrôle de la gestion du cycle de vie des clés (création, chargement, rotation, suppression), des autorisations d’utilisation des clés et des opérations d’audit sur les clés.

Remarque

Azure Key Vault Managed HSM (module de sécurité matérielle) est actuellement pris en charge pour les clés gérées par le client pour Azure Database pour MySQL.

Avantages

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 avec la possibilité de supprimer la clé et de rendre la base de données inaccessible
• Contrôle total sur le cycle de vie de la clé, de la rotation de la clé à son alignement sur les stratégies d’entreprise
• Gestion centralisée et organisation des clés dans Azure Key Vault ou le HSM managé
• Possibilité de mettre en place une séparation des tâches entre les responsables de la sécurité, les administrateurs 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 fournissent aux services Azure une alternative au stockage des informations d’identification dans le code en approvisionnant une identité affectée automatiquement qui peut être utilisée pour s’authentifier auprès de n’importe quel service prenant en charge l’authentification Microsoft Entra comme Azure Key Vault (AKV). Azure Database pour MySQL prend actuellement en charge uniquement l’identité managée affectée par l’utilisateur (UMI). Pour plus d’informations, consultez Types d’identités managées dans Azure.

Pour configurer la clé CMK pour une base de données Azure pour MySQL, vous devez lier l’UMI au serveur et spécifier le coffre de clés Azure et la clé à utiliser.

L’UMI doit avoir 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.
• Lister : pour répertorier les versions de la clé stockée dans un coffre de clés.
• Inclure la clé : pour pouvoir chiffrer la clé de chiffrement (DEK). La clé DEK chiffrée est stockée dans l’instance de serveur flexible Azure Database pour MySQL.
• Ne pas inclure la clé : pour pouvoir déchiffrer la clé DEK. Azure Database pour MySQL a besoin du DEK déchiffré pour chiffrer/déchiffrer les données.

Si le contrôle d’accès en fonction du rôle (RBAC) est activé, le rôle suivant doit également être attribué à l’UMI :

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

Terminologie et description

Clé de chiffrement (DEK) : clé symétrique AES256 utilisée pour chiffrer une partition ou un bloc de données. Le chiffrement de chaque bloc de données avec une clé différente rend les attaques par cryptanalyse plus difficiles. L’accès aux clés de chiffrement est nécessaire au fournisseur de ressources ou à l’instance d’application qui chiffre et déchiffre un bloc spécifique. Lorsque vous remplacez une clé de chiffrement par une nouvelle clé, seules les données du bloc associé doivent être rechiffrées avec la nouvelle clé.

Clé de chiffrement de clé (KEK) : clé de chiffrement utilisée pour chiffrer les clés de chiffrement. Une clé KEK qui ne quitte jamais Key Vault permet de chiffrer et de contrôler les clés DEK elles-mêmes. L’entité qui a accès à la clé KEK peut être différente de l’entité qui a besoin de la clé DEK. Comme la clé KEK est nécessaire au déchiffrement des clés DEK, la clé KEK est en fait un point unique par lequel les DEK peuvent être effectivement supprimées par la suppression de la clé KEK. Les clés DEK, chiffrées avec les clés KEK, sont stockées séparément. Seule une entité ayant accès à la clé KEK peut déchiffrer ces clés DEK. Pour plus d’informations, consultez Sécurité du chiffrement au repos.

Fonctionnement

Le chiffrement des données avec des clés CMK est défini au niveau du serveur. Pour un serveur donné, une clé CMK, appelée clé de chiffrement de clé (KEK), sert à chiffrer la clé de chiffrement (DEK) du service. 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 des services de chiffrement/déchiffrement utilisant la clé des entités autorisées. Le coffre de clés est importé et peut générer la clé, ou est transféré 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 examiner les journaux d’événements d’audit de Key Vault. 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.

Remarque

Les changements d’autorisation peuvent prendre jusqu’à 10 minutes avant d’avoir un impact sur le coffre de clés. Cela inclut la révocation des autorisations d’accès dans le protecteur TDE dans AKV. Dans cet intervalle, les utilisateurs peuvent continuer à avoir des autorisations d’accès.

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 les ressources du coffre de clés 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é supprimée provisoirement sur le coffre de clés avec une période de rétention définie à 90 jours pour protéger contre la perte de données en cas de suppression accidentelle d'une clé ou du coffre de clés. 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é supprimée de manière réversible est désactivée par défaut, mais vous pouvez l’activer via le portail Azure ou à l’aide de PowerShell ou d’Azure CLI.
• Activez la fonctionnalité Protection contre le vidage sur le coffre de clés et définissez la période de rétention sur 90 jours. Lorsque la protection contre le vidage est activée, il n’est pas possible de vider un coffre ou un objet à l’état supprimé avant la fin de la période de rétention. Vous pouvez activer cette fonctionnalité à l’aide de PowerShell ou d’Azure CLI, et uniquement après avoir activé la suppression réversible.

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

• La clé gérée par le client pour chiffrer la clé DEK peut être uniquement asymétrique, RSA ou RSA-HSM (coffres avec référence SKU Premium) 2048, 3072 ou 4096.
• 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.
• L’état de la clé doit être 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. Cela permet de définir implicitement l’attribut de clé requis recoveryLevel: "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).

Remarque

Pour obtenir des instructions détaillées sur la configuration du chiffrement de date pour Azure Database pour MySQL via le portail Azure, consultez Le chiffrement des données pour Azure Database pour MySQL - Serveur flexible à l’aide du portail Azure.

Recommandations pour la configuration du chiffrement de données

Lorsque vous configurez le coffre de clés ou le HSM managé pour utiliser le chiffrement des données à l’aide d’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é. Azure Monitor Log Analytics est un exemple de service déjà intégré.
• 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.

Remarque

Il est recommandé qu’un coffre de clés soit utilisé à partir de la même région, mais si nécessaire, vous pouvez utiliser un coffre de clés d’une autre région en spécifiant les informations « Entrer l’identificateur de clé ». Le HSM géré par le coffre des clés doit se trouver dans la même région que le serveur flexible MySQL.

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

Lorsque vous configurez le chiffrement des données avec une CMK dans Key Vault, un accès continu à cette clé est requis pour que le serveur reste 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 de serveur flexible Azure Database pour MySQL ne peut pas accéder à la clé et passe à l’état Inaccessible . Récupérez le coffre de clés et revalidez le chiffrement des données pour rendre l’instance de serveur flexible Azure Database pour MySQL disponible.
• Si vous supprimez la clé du coffre de clés, l’instance de serveur flexible Azure Database pour MySQL ne peut pas accéder à la clé et passe à l’état inaccessible . Récupérez la clé et revalidez le chiffrement des données pour rendre l’instance de serveur flexible Azure Database pour MySQL disponible.
• Si la clé stockée dans Azure Key Vault expire, la clé devient non valide et l’instance de serveur flexible Azure Database pour MySQL passe à l’état inaccessible . Prolongez la date d’expiration de la clé à l’aide de CLI, puis revalidez le chiffrement de données pour rendre l’instance de serveur flexible Azure Database pour MySQL disponible.

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

Il peut arriver qu’une personne disposant de droits d’accès suffisants à Key Vault désactive accidentellement l’accès du 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 liées à la perte d'accès au protecteur TDE (Transparent Data Encryption), configurez les fonctionnalités 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

Une fois qu’une instance de serveur flexible Azure Database pour MySQL est chiffrée à l’aide d’une clé gérée par le 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 qui possède déjà un réplica, nous vous recommandons de configurer un ou plusieurs réplicas en ajoutant l’identité managée et la clé. Supposons que l’instance de serveur flexible Azure Database pour MySQL soit configurée avec une sauvegarde de géoredondance. Dans ce cas, le réplica doit être configuré avec l’identité managée et la clé à laquelle l’identité a accès et qui réside dans la région géo-appairée du serveur.

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

Lorsque vous tentez de restaurer une instance de serveur flexible Azure Database pour MySQL, vous pouvez sélectionner l’identité managée utilisateur et la clé pour chiffrer le serveur de restauration. Supposons que l’instance de serveur flexible Azure Database pour MySQL soit configurée avec une sauvegarde de géoredondance. Dans ce cas, vous devez configurer le serveur de restauration avec l’identité managée et la clé à laquelle l’identité a accès et qui réside dans la région géo-appairée du serveur.

Pour éviter tout problème lors de la configuration du chiffrement des données géré par le client pendant la restauration ou la création d’un réplica en lecture, il est essentiel de suivre les étapes ci-dessous sur le serveur source et le serveur restauré/réplica :

• 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é/réplica, revalidez la clé gérée par le client dans les paramètres de chiffrement de données pour vous assurer que l’identité managée utilisateur reçoit les autorisations Obtenir, Lister, Inclure la clé et Ne pas inclure la clé sur la clé stockée dans Key Vault.

Remarque

L’utilisation de la même identité et de la même clé que sur le serveur source n’est pas obligatoire lors de l’exécution d’une restauration.

Contenu connexe

• Chiffrement de données pour Azure Database pour MySQL – Serveur flexible avec Azure CLI
• Chiffrement de données Azure Database pour MySQL – Serveur flexible avec le portail Azure
• Sécurité du chiffrement au repos
• Authentification Microsoft Entra pour Azure Database pour MySQL – Serveur flexible