Share via

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

  • Article

S’APPLIQUE À : Azure Database pour MySQL - Serveur flexible

Le chiffrement de données avec des clés gérées par le client pour le serveur flexible d’Azure Database pour MySQL, vous permet d’utiliser le service BYOK (Bring Your Own Key) en apportant votre propre clé pour la protection des données au repos, et d’implémenter une 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 est responsable de la gestion du cycle de vie de la clé (création, téléchargement, rotation, suppression), des autorisations d’utilisation de la clé et des opérations d’audit sur les clés, qu’il contrôle en dernier ressort.

Avantages

Le chiffrement des données de serveur flexible d’Azure Database pour MySQL à l’aide d’une clé gérée par le client offre les avantages suivants :

  • Vous contrôlez entièrement l’accès aux données sachant que vous avez 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é jusqu’à la mise en adéquation avec les stratégies d’entreprise
  • Gestion centralisée et organisation des clés dans Azure Key Vault
  • 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

Fonctionnement du chiffrement des données à l’aide d’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 provisionnant 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, tel que le service Azure Key Vault (AKV). Le serveur flexible Azure Database pour MySQL ne prend actuellement en charge que 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 CMK pour une Azure Database pour MySQL - Serveur flexible, vous devez lier l’UMI au serveur et spécifier l’Azure Key Vault et la clé à utiliser.

L’UMI doit avoir l’accès suivant au coffre de clés :

  • Get : pour récupérer la partie publique et les propriétés de la clé dans le coffre de clés.
  • List : pour répertorier les versions de la clé stockée dans un coffre de clés.
  • Wrap Key : pour pouvoir chiffrer la clé de chiffrement. La clé de chiffrement chiffrée est stockée dans l’instance de serveur flexible Azure Database pour MySQL.
  • Unwrap Key : pour pouvoir déchiffrer la clé de chiffrement. Le serveur flexible Azure Database pour MySQL a besoin de la clé de chiffrement déchiffrée pour chiffrer ou déchiffrer les données.

Terminologie et description

Clé de chiffrement de données (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 d’analyse du chiffrement plus difficiles. L’accès aux clés DEK 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 de données 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 de données. Une KEK qui ne quitte jamais Key Vault permet de chiffrer et de contrôler les KEK elles-mêmes. L'entité qui a accès à la clé de chiffrement de clé peut être différente de l'entité qui a besoin de la clé de chiffrement de données. 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 DEK, chiffrées avec les KEK, sont stockées séparément. Seule une entité ayant accès à la KEK peut déchiffrer ces DEK. Pour plus d’informations, consultez Sécurité du chiffrement au repos.

Fonctionnement

Le chiffrement des données avec CMK est défini au niveau du serveur. Pour un serveur donné, une CMK appelée clé de chiffrement de clé (KEK), sert à chiffrer la clé de chiffrement de données (DEK) du service. La KEK est une clé asymétrique stockée dans une instance d’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 soutenu par les modules de sécurité matériels (HSM) validés par la norme 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é aux entités autorisées. Le coffre de clés, importé, peut générer la clé, transféré vers le coffre de clés à partir d’un appareil HSM local.

Lorsque vous configurez un serveur flexible pour utiliser une CMK stockée dans le coffre de clés, le serveur envoie la clé de chiffrement au coffre de clés pour les chiffrements. 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 les clés de chiffrement protégées au coffre de clés pour le déchiffrement, le cas échéant.

Diagram of how data encryption with a customer-managed key work.

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.

Notes

Les modifications d’autorisation peuvent prendre jusqu’à 10 minutes pour 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. Du coup, les utilisateurs dans ce laps de temps peuvent toujours avoir des autorisations d’accès.

Exigences pour la configuration du chiffrement des données pour le serveur flexible Azure Database pour MySQL

Avant de tenter de configurer le Key Vault, assurez-vous de répondre aux exigences suivantes.

  • 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 Key Vault 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 Key Vault 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 avec une période de rétention définie sur 90 jours, afin de protéger contre la perte de données en cas de suppression accidentelle de clé (ou de 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. Par défaut, la fonctionnalité de suppression réversible est désactivée, mais vous pouvez l’activer via le portail Azure ou à l’aide de PowerShell ou d’Azure CLI.
  • Activez la fonctionnalité de 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 purger un coffre ou un objet à l’état supprimé avant la fin de la période de rétention de 90 jours. 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 CMK, assurez-vous de répondre aux exigences suivantes.

  • La clé gérée par le client pour chiffrer la clé de chiffrement de données ne peut être qu’asymétrique, RSA ou RSA-HSM (coffres avec 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. Cela a pour effet de définir implicitement l’attribut de clé requis recoveryLevel: « Recoverable ».
  • La clé doit avec la protection contre le vidage activée.
  • Si vous importez une clé existante dans le coffre de clés, veillez à la fournir dans les formats de fichiers pris en charge (.pfx, .byok, .backup).

Remarque

Pour obtenir des instructions détaillées sur la configuration du chiffrement de données pour le serveur flexible Azure Database pour MySQL via le portail Azure, consultez Configurer le chiffrement de données pour un serveur flexible Azure DB pour MySQL.

Recommandations pour la configuration du chiffrement de données

Lorsque vous configurez Key Vault pour utiliser le chiffrement de 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 d’activité 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 une sauvegarde de celle-ci avant sa première utilisation. La sauvegarde ne peut être restaurée que dans Key Vault. Pour plus d'informations sur la commande de sauvegarde, consultez Backup-AzKeyVaultKey.

Notes

  • Il est recommandé d’utiliser un coffre de clés de la même région. Toutefois, si cela est 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é ».
  • La clé RSA stockée dans un module HSM géré par Azure Key Vault n’est actuellement pas prise en charge.

Condition de clé managé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 plus 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é de votre coffre de clés, l’instance de serveur flexible Azure Database pour MySQL ne peut plus 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, elle devient non valide et l’instance de serveur flexible Azure Database pour MySQL passe à l’état Inaccessible. Étendez 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 get, list, wrap key et unwrap key 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 ;
  • Supprimer l’identité managée par l’utilisateur utilisé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 a déjà un ou plusieurs réplicas, nous vous recommandons de configurer les 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é à la 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 par l’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 restauré avec l’identité managée et la clé à la laquelle l’identité a accès et qui réside dans la région géo-appairée du serveur.

Pour éviter les problèmes 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 de lecture, il est essentiel de suivre les étapes ci-dessous sur le serveur source et les serveurs de restauration/réplication :

  • Initiez le processus de création de réplicas en lecture ou restauration à partir de l’instance de serveur flexible Azure Database pour MySQL source.
  • Sur le serveur restauré/réplica, revalidez la clé managée par le client dans les paramètres de chiffrement de données pour vous assurer que l’identité managée par l’utilisateur reçoit les autorisations Get, List, Wrap key et Unwrap key sur la clé stockée dans le Key Vault.

Notes

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.

Étapes suivantes