Partager via

Résolution des problèmes de chiffrement des données avec clé gérée par le client (CMK) dans Azure DocumentDB

Ce guide est conçu pour vous aider à résoudre les problèmes courants lors de l’utilisation de la clé gérée par le client (CMK) pour le chiffrement des données au repos avec Azure DocumentDB. Il offre des solutions pratiques pour résoudre les problèmes liés à différents composants impliqués dans la configuration CMK.

Une identité managée, un coffre de clés, une clé de chiffrement dans le coffre de clés et des autorisations appropriées accordées à l’identité managée sont requises pour configurer CMK sur un cluster Azure DocumentDB.

Si l’identité managée, le coffre de clés, la clé ou les autorisations ne sont pas configurés conformément aux exigences, vous ne pourrez peut-être pas activer CMK pendant l’approvisionnement du cluster. Si une configuration appropriée n’est pas valide sur un cluster compatible CMK, les données de ce cluster ne sont plus disponibles en raison de l’exigence de sécurité principale du chiffrement avec la clé gérée par le client.

Suivez les étapes décrites dans cette section pour résoudre les problèmes de tous les composants requis pour la configuration appropriée de CMK.

Raisons de la révocation de l’accès à la clé à partir d’Azure Key Vault

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

  • En annulant l’attribution du rôle RBAC Utilisateur de chiffrement du service de 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.
  • Modification des règles de pare-feu Key Vault ou configuration incorrecte des paramètres réseau du coffre de clés.
  • Suppression de l’identité managée du cluster dans Microsoft Entra ID.

Ces actions entraînent l’accessibilité de la clé gérée par le client pour le chiffrement des données.

Résolution des problèmes liés à l’inaccessibilité de la clé gérée par le client

Quand vous configurez le chiffrement de données avec une clé gérée par le client stockée dans le coffre de clés, un accès continu à cette clé est requis pour que le cluster reste en ligne. Si ce n’est pas le cas, le cluster change d’état en inaccessible et commence à refuser toutes les connexions.

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

La cause Résolution
Toutes les clés de chiffrement pointées par le cluster ont une date et une heure d’expiration configurées, et cette date et heure sont atteintes. Vous devez étendre la date d’expiration de la clé. Ensuite, vous devez attendre que le service revalide la clé et passe automatiquement l’état du cluster à Prêt. Uniquement lorsque le cluster est de retour à l’état Prêt, vous pouvez faire pivoter la clé vers une version plus récente ou créer une nouvelle clé, puis mettre à jour le cluster afin qu’il fasse référence à cette nouvelle version de la même clé ou à la nouvelle clé.
Vous supprimez l’instance Key Vault, l’instance Azure DocumentDB ne peut pas accéder à la clé et passe à un état inaccessible . Récupérez l’instance Key Vault et attendez que le service exécute la revalidation périodique de la clé, puis passez automatiquement l’état du cluster à Prêt.
Vous supprimez, à partir de Microsoft Entra ID, une identité managée utilisée pour récupérer les clés de chiffrement stockées dans le coffre de clés. Récupérez l’identité et attendez que le service exécute la revalidation périodique de la clé, puis passez automatiquement l’état du cluster à Prêt.
Votre modèle d’autorisation du coffre de clés est configuré pour utiliser le contrôle d’accès en fonction du rôle. Vous supprimez l'attribution de rôle RBAC Key Vault Crypto Service Encryption User des identités managées qui sont configurées pour récupérer l’une des clés. Accordez le rôle RBAC à nouveau à l’identité managée et attendez que le service exécute la revalidation périodique de la clé, puis passez automatiquement l’état du cluster à Prêt. Vous pouvez également accorder le rôle sur le coffre de clés à une identité managée différente et mettre à jour le cluster afin qu’il utilise cette autre identité managée pour accéder à la clé.
Votre modèle d’autorisation du coffre de clés est configuré pour utiliser les stratégies d’accès. Vous révoquez les politiques d'accès list, get, wrapKey ou unwrapKey des identités managées configurées pour récupérer l'une des clés. Accordez le rôle RBAC à l’identité managée et attendez que le service exécute la revalidation périodique de la clé, puis passez automatiquement l’état du cluster à Prêt. Vous pouvez également accorder les stratégies d’accès requises sur le coffre de clés à une identité managée différente et mettre à jour le cluster afin qu’il utilise cette autre identité managée pour accéder à la clé.
Vous configurez des règles de pare-feu trop restrictives pour que votre cluster Azure DocumentDB ne puisse pas communiquer avec le coffre de clés pour récupérer vos clés. Lorsque vous configurez un pare-feu de coffre de clés, veillez à désactiver l’accès public et à sélectionner l’option permettant d’autoriser les services Microsoft approuvés ou d’autoriser l’accès public à partir de tous les réseaux. Avec l’accès public à partir de tous les réseaux, votre cluster Azure DocumentDB peut accéder au coffre de clés. Avec l’accès public désactivé et l’option permettant aux services Microsoft approuvés d’accéder à la valeur de clé, votre cluster peut contourner le pare-feu.

Note

Lorsqu’une clé est désactivée, supprimée, expirée ou inaccessible, un cluster dont les données sont chiffrées avec cette clé devient Inaccessible, comme indiqué précédemment. L’état du cluster ne passe pas à nouveau à Prêt tant qu’il ne peut pas revalider la clé de chiffrement.

En règle générale, un cluster 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 cluster peut prendre jusqu’à 60 minutes pour redevenir Prêt.

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 le coffre de clés 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 identité managée Entra ID.
  2. Si vous avez créé une identité, même si elle porte le même nom que celle qui a été supprimée, mettez à jour les propriétés du cluster 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 cluster 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.

Résolution des problèmes d’approvisionnement de cluster prenant en charge la CMK ayant échoué

Si l’une des exigences CMKn’est pas remplie, une tentative d’approvisionnement d’un cluster avec la CMK activée échoue. L’erreur suivante lors de l’approvisionnement du cluster indique que le coffre de clés, la clé de chiffrement ou les autorisations pour l’identité managée n’ont pas été correctement configurés : « Impossible d’accéder à la clé. Elle est peut-être manquante, l’identité utilisateur fournie ne dispose pas des autorisations GET pour y accéder ou le coffre de clés n’a pas activé l’accès à l’Internet public. »

Pour résoudre ce problème :

  1. Vérifiez toutes les exigences CMK.
  2. Approvisionnez le cluster avec l’identité managée et le coffre de clés que vous avez vérifiés.
  3. Supprimez l’entité de cluster ayant échoué. Le cluster ayant échoué a la propriété clusterStatus définie sur Failed. Dans le portail Microsoft Azure, vous trouverez l’état du cluster dans le panneau Vue d’ensemble des propriétés du cluster.

Contenu connexe

  • Last updated on