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 afin d’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 contrôle :

• Gestion du cycle de vie des clés (création de clés, chargement, rotation, 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 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 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 coffre de clés. 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’UAMI au serveur et spécifier le coffre de clés Azure et la clé à utiliser.

L’UAMI 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 azure RBAC est activé, l’UAMI doit être affecté à des rôles 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é

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.

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.
• Activer la fonctionnalité de suppression temporaire 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 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 passées. 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 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é.
• 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 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. 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 de 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

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.

Lors de la restauration ou de la création d’un réplica en lecture, il est essentiel de suivre ces étapes sur les serveurs source et restaurés/réplicas :

• 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é CMK dans les paramètres de chiffrement des données pour confirmer les droits UAMI relatifs à la clé.

Contenu connexe

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