Partager via

Chiffrement des données

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Toutes les données gérées par une instance d’Azure Database pour PostgreSQL flexible sont toujours chiffrées au repos. Ces données incluent toutes les bases de données système et utilisateur, les fichiers temporaires, les journaux du serveur, les segments du journal WAL (write-ahead log) et les sauvegardes.

Pour effectuer le chiffrement de vos données, Azure Database pour PostgreSQL – Serveur flexible utilise le chiffrement Stockage Azure pour les données au repos, en fournissant des clés pour chiffrer et déchiffrer les données dans les services Stockage Blob et Azure Files. Ces clés doivent être stockées dans Azure Key Vault ou dans un module de sécurité matériel (HSM) géré par Azure Key Vault. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement Stockage Azure.

Azure Database pour PostgreSQL – Serveur flexible prend en charge la configuration du chiffrement des données dans deux modes différents : clé gérée par le service et clé gérée par le client. Le mode de configuration peut être sélectionné seulement lors de la création du serveur. Il ne peut être changé d’un mode à l’autre pendant toute la durée de vie du serveur.

Avec une clé de chiffrement gérée par le service, Azure Database pour PostgreSQL – Serveur flexible s’occupe de l’approvisionnement du coffre Azure Key Vault où les clés sont conservées, et il assume toute la responsabilité de la fourniture de la clé avec laquelle les données sont chiffrées et déchiffrées. Le service s’occupe également du stockage, de la protection, de l’audit des accès, de la configuration de la mise en réseau et de la rotation automatique de la clé.

Avec une clé de chiffrement gérée par le client, vous assumez toutes les responsabilités. Par conséquent, vous devez déployer votre propre coffre Azure Key Vault ou votre propre module de sécurité matériel (HSM) Azure Key Vault. Vous devez générer ou importer votre propre clé. Vous devez accorder des autorisations requises sur le coffre de clés pour que votre serveur flexible Azure Database pour PostgreSQL puisse effectuer les actions nécessaires sur la clé. Vous devez vous occuper de la configuration de tous les aspects réseau du coffre Azure Key Vault où la clé est conservée pour que votre serveur flexible Azure Database pour PostgreSQL puisse accéder à la clé. L’audit des accès à la clé est également votre responsabilité. Enfin, vous êtes responsable de la rotation de la clé et, quand c’est nécessaire, de la mise à jour de la configuration de votre serveur flexible Azure Database pour PostgreSQL pour qu’il référence la version de la clé ayant fait l’objet d’une rotation.

Quand vous configurez des clés gérées par le client pour un compte de stockage, Stockage Azure encapsule la clé de chiffrement des données (DEK) racine pour le compte avec la clé gérée par le client dans le coffre de clés ou le HSM managé associé. La protection de la clé de chiffrement racine change, mais les données de votre compte de stockage Azure restent toujours chiffrées. Aucune action supplémentaire n’est requise de votre part pour faire en sorte que vos données soient protégées. La protection par des clés gérées par le client prend effet immédiatement.

Azure Key Vault est un système de gestion de clés externe basé sur le cloud. Il fournit un stockage sécurisé hautement disponible et évolutif pour les clés de chiffrement RSA, éventuellement sauvegardé par les modules de sécurité matériels (HSM) certifiés FIPS 140. Il ne permet pas l’accès direct à une clé stockée, mais fournit des services de chiffrement et de déchiffrement aux entités autorisées. Key Vault peut générer la clé, l’importer ou la recevoir par transfert depuis un appareil HSM local.

Avantages de chacun des modes

Le chiffrement des données avec des clés gérées par le service pour Azure Database pour PostgreSQL– Serveur flexible offre les avantages suivants :

  • Le service contrôle automatiquement et entièrement l’accès aux données.
  • Le service contrôle automatiquement et entièrement le cycle de vie de votre clé, y compris la rotation de la clé.
  • Vous n’avez pas besoin de vous soucier de la gestion des clés de chiffrement de données.
  • Le chiffrement de données basé sur des clés gérées par le service n’a pas d’impact négatif sur les performances de vos charges de travail.
  • Il simplifie la gestion de

Le chiffrement de données avec des clés gérées par le client pour Azure Database pour PostgreSQL– Serveur flexible offre les avantages suivants :

  • Vous contrôlez entièrement l’accès aux données. Vous pouvez supprimer une clé pour rendre une base de données inaccessible.
  • Vous contrôlez entièrement le cycle de vie d’une clé, y compris la rotation de la clé, pour vous aligner sur les stratégies de l’entreprise.
  • Vous pouvez gérer et organiser de façon centralisée toutes vos clés de chiffrement dans vos propres instances d’Azure Key Vault.
  • Le chiffrement de données basé sur des clés gérées par le client n’a pas d’impact négatif sur les performances de vos charges de travail.
  • Vous pouvez implémenter une séparation des tâches entre les responsables sécurité, les administrateurs de base de données et les administrateurs système.

Spécifications

Voici la liste des exigences pour configurer le chiffrement de données pour Azure Database pour PostgreSQL– Serveur flexible :

  • Key Vault et le serveur flexible Azure Database pour PostgreSQL doivent appartenir au même locataire Microsoft Entra. Les interactions entre un serveur et une instance inter-locataires de Key Vault ne sont pas prises en charge. Pour déplacer par la suite la ressource Key Vault, vous devez reconfigurer le chiffrement des données.
  • Il est recommandé de définir la configuration de Jours de conservation des coffres supprimés pour Key Vault sur 90 jours. Si vous avez configuré une instance Key Vault existante avec un nombre inférieur, elle devrait néanmoins être valide. Cependant, si vous souhaitez modifier ce paramètre et augmenter la valeur, il est nécessaire de créer une nouvelle instance Key Vault. Une fois qu’une instance est créée, il n’est pas possible de modifier ce paramètre.
  • Activez la fonctionnalité de suppression réversible dans Key Vault pour vous protéger contre la perte de données si une clé ou une instance Key Vault est supprimée accidentellement. Key Vault conserve les ressources supprimées de manière réversible pendant 90 jours, sauf si l'utilisateur les récupère ou les supprime définitivement dans l'intervalle. Les actions de récupération et de vidage ont leurs propres autorisations associées à un coffre de clés, un rôle RBAC ou à une autorisation de stratégie d’accès. La fonctionnalité de suppression réversible est activée par défaut. Si vous avez un coffre de clés qui a été déployé il y a longtemps, il se peut que la suppression réversible soit désactivée. Dans ce cas, vous pouvez l’activer en utilisant Azure CLI.
  • Activez la protection contre la suppression définitive pour appliquer une période de rétention obligatoire pour les coffres et les objets de coffre supprimés.
  • Accordez à l’identité managée affectée par l’utilisateur d’Azure Database pour PostgreSQL– Serveur flexible l’accès à la clé en :
  • La clé utilisée pour chiffrer la clé de chiffrement de données peut être seulement asymétrique, RSA ou RSA-HSM. Les tailles de clé 2 048, 3 072 et 4 096 sont prises en charge. Nous vous recommandons d’utiliser une clé de 4 096 bits pour une meilleure sécurité.
  • La date et l’heure de l’activation de clé (si définies) doivent être passées. La date et l’heure d’expiration (si définies) doivent être dans le futur.
  • La clé doit être dans l’état Activé.
  • Si vous importez une clé existante dans Key Vault, fournissez-la dans l’un des formats de fichier pris en charge (.pfx, .byok ou .backup).

Recommandations

Quand vous utilisez une clé gérée par le client pour le chiffrement de données, suivez ces recommandations pour configurer Key Vault :

  • Définissez un verrou de ressource sur Key Vault pour empêcher la suppression accidentelle ou non autorisée de cette ressource critique.
  • 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é (SIEM). Azure Monitor Logs est un exemple de service déjà intégré.
  • Verrouillez Key Vault en sélectionnant Désactiver l’accès public et Autoriser les services Microsoft approuvés à contourner ce pare-feu.

Remarque

Après avoir sélectionné Désactiver l’accès public et Autoriser les services Microsoft approuvés à contourner ce pare-feu, vous pouvez obtenir une erreur similaire à ce qui suit lorsque vous essayez d’utiliser l’accès public pour administrer Key Vault via le portail : « Vous avez activé le contrôle d’accès réseau. Seuls les réseaux autorisés auront accès à ce coffre de clés. » Cette erreur n’empêche pas de fournir des clés lors de la configuration de la clé gérée par le client ou d’extraire des clés de Key Vault pendant les opérations du serveur.

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

Considérations spéciales

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

Une personne disposant de droits d’accès suffisants à Key Vault pourrait désactiver accidentellement l’accès du serveur à la clé :

  • En annulant l’attribution du rôle RBAC Utilisateur de chiffrement Service chiffrement Key Vault ou en révoquant les autorisations de l’identité utilisée pour récupérer la clé dans Key Vault.
  • supprimant la clé ;
  • En supprimant l’instance Key Vault.
  • En modifiant les règles de pare-feu Key Vault.
  • Suppression de l’identité managée du serveur dans Microsoft Entra ID.

Surveillance des clés conservées dans Azure Key Vault

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

  • Intégrité des ressources : une base de données qui a perdu l’accès à la clé CMK apparaît comme Inaccessible après la première connexion à la base de données.
  • Journal d’activité : lorsque l’accès à la clé CMK dans l’instance Key Vault gérée par le client échoue, des entrées sont ajoutées au journal d’activité. Vous pouvez rétablir l’accès en créant des alertes pour ces événements dès que possible.
  • Groupes d'actions : définissez ces groupes pour recevoir des notifications et des alertes basées sur vos préférences.

Restauration des sauvegardes d’un serveur configuré avec une clé gérée par le client

Une fois le serveur flexible Azure Database pour PostgreSQL chiffré avec une clé gérée par le client stockée dans Key Vault, les copies nouvellement créées du serveur sont également chiffrées. Vous pouvez créer cette copie par l’intermédiaire d’une opération de restauration à un instant dans le passé ou de réplicas en lecture.

Quand vous configurez le chiffrement de données avec une clé gérée par le client, pendant une opération comme la restauration d’une sauvegarde ou la création d’un réplica en lecture, vous pouvez éviter les problèmes en suivant ces étapes sur les serveurs principaux et restaurés ou les serveurs réplicas :

  • Lancez le processus de restauration ou de création de réplica en lecture à partir de l’instance principale de serveur flexible Azure Database pour PostgreSQL.
  • Sur le serveur restauré ou réplica, vous pouvez changer la clé gérée par le client et l’identité managée affectée par l’utilisateur utilisée pour accéder à Key Vault. Vérifiez que l’identité affectée dans le serveur nouvellement créé dispose des autorisations requises sur le coffre de clés.
  • Ne révoquez pas la clé d’origine après la restauration. À ce stade, nous ne prenons pas en charge la révocation de clé après la restauration d’un serveur avec une clé gérée par le client sur un autre serveur.

Modules HSM managés

Les modules de sécurité matériels (HSM) sont des appareils matériels inviolables qui aident à sécuriser les processus de chiffrement en générant, en protégeant et en gérant les clés utilisées pour chiffrer les données, déchiffrer des données, créer des signatures numériques et créer des certificats numériques. Les HSM sont testés, validés et certifiés selon les normes de sécurité les plus élevées, notamment FIPS 140 et les critères communs.

Azure Key Vault Managed HSM est un service cloud complètement managé, hautement disponible, à locataire unique et conforme aux normes. Vous pouvez l’utiliser pour protéger les clés de chiffrement pour vos applications cloud via des HSM validés FIPS 140-3.

Quand vous créez des instances Azure Database pour PostgreSQL – Serveur flexible dans le portail Azure avec la clé gérée par le client, vous pouvez choisir HSM géré par Azure Key Vault en tant que magasin de clés comme alternative à Azure Key Vault. Les prérequis, en termes d’identité et d’autorisations définies par l’utilisateur, sont identiques à celles d’Azure Key Vault (comme indiqué plus haut dans cet article). Pour plus d’informations sur la création d’une instance HSM managée, ses avantages et ses différences par rapport à un magasin de certificats basé sur Key Vault partagé et comment importer des clés dans un HSM managé, consultez Qu’est-ce que HSM managé Azure Key Vault ?.

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

Quand vous configurez le chiffrement de données avec une clé gérée par le client stockée dans Key Vault, un accès continu à cette clé est requis pour que le serveur reste en ligne. Si le serveur perd l’accès à la clé conservée dans Key Vault, il commence à refuser toutes les connexions dans un délai de 10 minutes. Le serveur émet un message d'erreur et affiche l'état Inaccessible.

Voici les raisons possibles pour lesquelles l’état du serveur peut devenir Inaccessible :

  • Si vous faites pivoter la clé et que vous oubliez de mettre à jour l’instance Azure Database pour PostgreSQL – Serveur flexible pour qu’elle pointe vers la nouvelle version de la clé. L’ancienne clé vers laquelle l’instance pointait finit par expirer et fait passer l’état du serveur à Inaccessible. Pour éviter cela, chaque fois que vous faites pivoter la clé, veillez également à mettre à jour l’instance de votre serveur pour qu’elle pointe vers la nouvelle version. Pour ce faire, vous pouvez utiliser la commande az postgres flexible-server update, en suivant l’exemple qui décrit « Modifier la clé/l’identité pour le chiffrement des données. Le chiffrement de données ne peut pas être activé après la création du serveur. Ceci ne met à jour que la clé/l’identité. » En guise d’alternative, vous pouvez appeler l’API REST Serveurs – Mettre à jour du service.
  • Si vous supprimez l’instance Key Vault, l’instance de serveur flexible Azure Database pour PostgreSQL ne peut pas accéder à la clé et passe à un état Inaccessible. Pour rendre le serveur Disponible, récupérez l’instance Key Vault et revalidez le chiffrement des données.
  • Si vous supprimez la clé du Key Vault, l’instance de serveur flexible Azure Database pour PostgreSQL ne peut plus accéder à la clé et passe à l’état Inaccessible. Pour rendre le serveur Disponible, récupérez la clé et revalidez le chiffrement des données.
  • Si vous supprimez, à partir de Microsoft Entra ID, une identité managée utilisée pour récupérer une clé à partir de Key Vault ou en supprimant l’attribution de rôle RBAC Azure avec le rôle utilisateur du service de chiffrement de Key Vault. L’instance de serveur flexible Azure Database pour PostgreSQL ne peut plus accéder à la clé et passe à un état Inaccessible. Pour rendre le serveur Disponible, récupérez l’identité et revalidez le chiffrement des données.
  • Si vous révoquez les stratégies d’accès list, get, wrapKey et unwrapKey de Key Vault de l’identité managée utilisée pour récupérer une clé à partir de Key Vault, l’instance de serveur flexible Azure Database pour PostgreSQL ne peut pas accéder à la clé et passe à un état Inaccessible. Ajoutez les stratégies d’accès requises à l’identité dans Key Vault.
  • Si vous configurez des règles de pare-feu Key Vault trop restrictives, le serveur flexible Azure Database pour PostgreSQL ne peut pas communiquer avec Key Vault pour récupérer les clés. Lorsque vous configurez un pare-feu Key Vault, veillez à sélectionner l’option permettant d’autoriser les services Microsoft approuvés à contourner le pare-feu.

Remarque

Lorsqu’une clé est désactivée, supprimée, expirée ou inaccessible, un serveur dont les données sont chiffrées via cette clé devient Inaccessible, comme indiqué précédemment. Le serveur n’est pas disponible tant que vous ne réactivez pas la clé ou que vous n’affectez pas une nouvelle clé.

En règle générale, un serveur devient Inaccessible dans les 60 minutes suivant la désactivation, la suppression, l’expiration ou l’inaccessibilité d’une clé. Une fois la clé disponible, le serveur peut prendre jusqu’à 60 minutes pour redevenir Accessible.

Récupération suite à la suppression de l’identité managée

Si l’identité managée affectée par l’utilisateur utilisée pour accéder à la clé de chiffrement stockée dans Key Vault est supprimée dans Microsoft Entra ID, procédez comme suit pour récupérer :

  1. Récupérez l’identité ou créez une nouvelle identité managée Entra ID.
  2. Si vous avez créé une nouvelle identité, même si elle porte le même nom qu’avant sa suppression, mettez à jour les propriétés du serveur flexible Azure Database pour lui indiquer qu’il doit utiliser cette nouvelle identité pour accéder à la clé de chiffrement.
  3. Assurez-vous que cette identité dispose des autorisations appropriées pour les opérations sur la clé dans Azure Key Vault (AKV).
  4. Attendez environ une heure jusqu’à ce que le serveur revalide la clé.

Important

Le fait de créer une identité Entra ID du même nom que l’identité supprimée ne permet pas de la récupérer.

Utilisation du chiffrement de données avec des clés gérées par le client et des fonctionnalités de continuité d’activité géoredondante

Le serveur flexible Azure Database pour PostgreSQL prend en charge les fonctionnalités avancées de récupération de données, telles que les réplicas et la sauvegarde géoredondante. Voici les conditions requises pour configurer le chiffrement des données avec une clé CMK et ces fonctionnalités, en plus des exigences de base pour le chiffrement des données avec des CMK :

  • La clé de chiffrement de sauvegarde géoredondante doit être créée dans une instance Key Vault qui se trouve dans la région où la sauvegarde géoredondante est stockée.
  • La version de l’API REST Azure Resource Manager pour la prise en charge des serveurs de CMK avec sauvegarde géoredondante est « 2022-11-01-preview ». Si vous souhaitez utiliser des modèles Azure Resource Manager pour automatiser la création de serveurs qui utilisent à la fois le chiffrement avec les clés CMK et les fonctionnalités de sauvegarde géoredondantes, utilisez cette version de l’API.
  • Vous ne pouvez pas utiliser la même identité managée par l’utilisateur pour vous authentifier pour l’instance Key Vault de la base de données primaire et l’instance Key Vault qui contient la clé de chiffrement pour la sauvegarde géoredondante. Pour maintenir la résilience régionale, nous vous recommandons de créer l’identité managée par l’utilisateur dans la même région que les sauvegardes géoredondantes.
  • Si vous configurez une base de données de réplica en lecture à chiffrer avec des clés CMK lors de la création, sa clé de chiffrement doit se trouver dans une instance Key Vault dans la région où réside la base de données de réplica en lecture. L’identité attribuée par l’utilisateur pour s’authentifier auprès de cette instance Key Vault doit être créée dans la même région.

Rotation des clés gérées par le client et clés sans version (préversion)

À titre de mesure de précaution, nous vous recommandons de faire pivoter la clé régulièrement ou chaque fois que la clé est compromise.

Remarque

La plupart des entreprises ont des exigences externes ou internes pour faire pivoter leurs clés régulièrement, par exemple toutes les 90 jours. Pour les clés générées par Key Vault, vous pouvez configurer la rotation automatique des clés de chiffrement dans Azure Key Vault. Si vous activez la rotation automatique, vous devez utiliser une clé gérée par le client sans version (préversion) pour le chiffrement de données dans Azure Database pour PostgreSQL – Serveur flexible pour tirer parti de cette fonctionnalité.

La rotation manuelle de la clé permet de protéger vos données en cas de compromission de la clé. Pour faire pivoter la clé, créez ou importez une génération de nouvelle clé pour la clé compromise.

  • Si vous utilisez des clés gérées par le client sans version (préversion), le serveur sélectionne automatiquement la nouvelle clé.
  • Si vous utilisez des clés avec version, vous devez mettre à jour l’instance Azure Database pour PostgreSQL – Serveur flexible pour qu’elle utilise la nouvelle version de la clé. Ce n’est qu’ensuite que le serveur commence à utiliser la nouvelle clé pour chiffrer et déchiffrer les données.

Clés gérées par le client sans version (préversion)

Les clés sans version sont recommandées pour le chiffrement de données dans Azure Database pour PostgreSQL – Serveur flexible. Il couvre correctement tous les scénarios de rotation de clé décrits précédemment. Une fois qu’une nouvelle version de la clé est disponible, le serveur utilise automatiquement la nouvelle version de la clé pour chiffrer et déchiffrer les données.

L’API ne change pas pour les clés sans version. Au lieu de fournir l’URI complet de l’identificateur de clé, omettez la partie « version » de l’identificateur de clé. Ceci s’applique à l’API, à Azure CLI, aux modèles ARM et aux modèles Bicep. Le portail Azure a une case à cocher pour activer les clés sans version, que vous pouvez utiliser pour sélectionner seulement l’identificateur de clé sans version.

Limites

Voici les limitations actuelles de la configuration de la clé gérée par le client dans Azure Database pour PostgreSQL – Serveur flexible :

Contenu connexe