Chiffrement des données à l’aide d’une clé gérée par le client dans Azure Database pour PostgreSQL – Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Par défaut, le serveur flexible Azure Database pour PostgreSQL se sert du chiffrement de Stockage Azure pour chiffrer les données au repos à l’aide de clés gérées par Microsoft. Pour les utilisateurs du serveur flexible d’Azure Database pour PostgreSQL, il est comparable au chiffrement de données transparent d’autres bases de données comme SQL Server.

De nombreuses organisations exigent un contrôle total de l’accès aux données avec une clé gérée par le client (CMK). Le chiffrement des données à l’aide de CMK pour un serveur flexible Azure Database pour PostgreSQL vous permet d’utiliser le service BYOK (Bring Your Own Key) pour la protection des données au repos. Il permet également aux organisations d'implémenter la séparation des tâches dans la gestion des clés et des données. Avec le chiffrement CMK, vous êtes responsable et en contrôle total du cycle de vie d’une clé, des autorisations d’utilisation des clés et de l'audit des opérations sur les clés.

Le chiffrement des données à l’aide de CMK pour le serveur flexible Azure Database pour PostgreSQL est défini au niveau du serveur. Pour un serveur donné, un type de CMK appelé 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. Les clés KEK et DEK sont décrites plus en détail plus loin dans cet article.

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 n’autorise 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 faire transférer à partir d'un appareil HSM local.

Avantages

Le chiffrement des données avec des clés CMK pour le serveur flexible Azure Database pour PostgreSQL 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 s’aligner sur les stratégies d’entreprise.

  • Vous pouvez gérer les clés et les organiser de manière centralisée dans Key Vault.

  • L’activation du chiffrement n’affecte pas les performances avec ou sans clés CMK, car PostgreSQL s’appuie sur la couche Stockage Azure pour le chiffrement des données dans les deux scénarios. La seule différence est que lorsque vous utilisez une clé CMK, la clé de chiffrement Stockage Azure (qui effectue le chiffrement des données) est chiffrée.

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

Terminologie

Clé de chiffrement des données (DEK) : clé symétrique AES 256 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. Le fournisseur de ressources ou l’instance d’application qui chiffre et déchiffre un bloc spécifique a besoin d’un accès aux clés DEK. 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 DEK. 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é KEK peut être différente de l'entité qui a besoin de la clé DEK. Étant donné que la clé KEK est nécessaire pour déchiffrer les clés DEK, la clé KEK est effectivement un point unique par lequel vous pouvez supprimer des clés DEK (en supprimant la clé KEK).

Les clés DEK, chiffrées avec une clé 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 des données au repos.

Fonctionnement du chiffrement des données avec une clé CMK

Diagramme illustrant le scénario Bring Your Own Key (BYOK).

Une identité managée affectée par l’utilisateur Microsoft Entra est utilisée pour se connecter et récupérer une clé CMK. Pour créer une identité, suivez ce tutoriel.

Pour qu’un serveur PostgreSQL utilise des clés CMK stockées dans Key Vault pour le chiffrement de la clé DEK, un administrateur Key Vault accorde les droits d’accès suivants à l’identité managée que vous avez créée :

  • get : pour récupérer la partie publique et les propriétés de la clé dans Key Vault.

  • list : pour lister et itérer au sein des clés du Key Vault.

  • wrapKey: pour chiffrer la clé DEK. La clé DEK chiffrée est stockée dans Azure Database pour PostgreSQL.

  • unwrapKey: pour déchiffrer la clé DEK. Azure Database pour PostgreSQL a besoin de la clé DEK déchiffrée pour chiffrer et déchiffrer les données.

L'administrateur Key Vault peut également activer la journalisation des événements d'audit Key Vault afin qu'ils puissent être audités ultérieurement.

Important

Le fait de ne pas fournir les droits d’accès précédents à une identité managée pour l’accès à Key Vault peut entraîner l’échec de l’extraction d’une clé de chiffrement et l’échec de la configuration de la fonctionnalité CMK.

Lorsque vous configurez le serveur pour utiliser la clé CMK stockée dans Key Vault, le serveur envoie la clé DEK au Key Vault pour le chiffrement. Key Vault retourne la clé DEK chiffrée qui est stockée dans la base de données utilisateur. Le cas échéant, le serveur envoie les clés DEK protégées au Key Vault pour le déchiffrement. Les auditeurs peuvent utiliser Azure Monitor pour consulter les journaux d'événements d'audit Key Vault, si la journalisation est activée.

Conditions requises pour configurer le chiffrement des données pour le serveur flexible Azure Database pour PostgreSQL

Voici les conditions requises pour configurer Key Vault :

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

  • Le paramètre Jours de conservation des coffres supprimés pour Key Vault doit avoir la valeur 90. Si vous avez configuré l’instance Key Vault existante avec un nombre inférieur, vous devez créer une instance Key Vault, car vous ne pouvez pas modifier une instance après sa création.

  • 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 autorisations propres aux actions de récupération et de vidage sont associées à une stratégie d’accès Key Vault.

    La fonctionnalité de suppression réversible est désactivée par défaut, mais vous pouvez l’activer via PowerShell ou Azure CLI. Vous ne pouvez pas l’activer via le Portail Azure.

  • 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’instance de serveur flexible Azure Database pour PostgreSQL l’accès à Key Vault avec les autorisations get, list, wrapKeyet unwrapKey à l’aide de son identité managée unique.

Voici les conditions requises pour configurer la clé CMK dans le serveur flexible Azure Database pour PostgreSQL :

  • La clé CMK à utiliser pour chiffrer la clé DEK peut être seulement asymétrique, RSA ou RSA-HSM. Les tailles de clé 2 048, 3 072 et 4 096 sont prises en charge.

  • 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 à l’état *Enabled-.

  • 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

Lorsque vous utilisez une clé CMK pour le chiffrement des données, voici des recommandations pour la configuration de Key Vault :

  • Définissez un verrou de ressource sur Key Vault 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é (SIEM). Azure Monitor Logs est un exemple de service déjà intégré.

  • Veillez à ce que Key Vault et le serveur flexible Azure Database pour PostgreSQL résident dans la même région pour assurer un accès plus rapide aux opérations wrap et unwrap de la clé DEK.

  • Verrouillez Key Vault en sélectionnant Désactiver l’accès public et Autoriser les services Microsoft approuvés à contourner ce pare-feu.

    Capture d’écran des options réseau pour désactiver l’accès public et autoriser uniquement les services Microsoft approuvés.

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 la possibilité de fournir des clés lors de l’installation de la clé CMK ou d’extraire des clés à partir de Key Vault pendant les opérations du serveur.

Suivez les recommandations ci-dessous pour configurer une clé CMK :

  • Conservez une copie de la clé CMK à 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.

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 :

  • Révoquant les autorisations list, get, wrapKey et unwrapKey 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.

Supervision de la clé CMK dans Key Vault

Pour superviser l’état de la base de données et activer les alertes pour la perte d’accès au protecteur de chiffrement des données transparent, 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 avec une clé gérée par le client dans Key Vault

Une fois le serveur flexible Azure Database pour PostgreSQL chiffré avec une clé gérée par le client stockée dans Key Vault, toute copie nouvellement créée du serveur est également chiffrée. 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.

Lorsque vous configurez le chiffrement des données managées par le client lors de la restauration ou de 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/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 modifier la clé CMK et/ou l’identité Microsoft Entra utilisée pour accéder à Key Vault dans les paramètres de chiffrement des données. Vérifiez que le serveur nouvellement créé dispose des autorisations list, wrap et unwrap sur la clé stockée dans Key Vault.

  • 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és après la restauration d’un serveur compatible CMK 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.

Lorsque vous créez des instances de serveur flexible Azure Database pour PostgreSQL dans le Portail Azure avec la fonctionnalité CMK, 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 CMK 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 perd l'accès à la clé CMK 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 quelques-unes des raisons pour lesquelles l’état du serveur devient Inaccessible :

  • 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, 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’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 ne sera pas disponible tant que vous ne réactivez pas la clé ou que vous n’attribuez 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.

Utilisation du chiffrement des données avec des clés CMK 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 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.

Limites

Voici les limitations actuelles de la configuration de la clé CMK dans le serveur flexible Azure Database pour PostgreSQL :

Étapes suivantes