Partager via

Chiffrement avec les clés gérées par le client dans Microsoft Cloud for Sovereignty

  • Article

Les clients qui envisagent de mettre en œuvre Microsoft Cloud for Sovereignty pourront avoir besoin de fonctionnalités de chiffrement des données pour satisfaire aux exigences de souveraineté des données. Les clients ayant des exigences strictes en matière de souveraineté des données doivent élaborer des plans pour mettre en œuvre la gestion des clés dans le cloud. Cet article guide les architectes cloud, les propriétaires de systèmes cryptographiques et d’autres décideurs techniques dans l’élaboration d’un plan de mise en œuvre du chiffrement au niveau de la plateforme dans Azure. La planification du chiffrement au niveau de la plateforme implique généralement d’identifier les exigences de gestion des clés, de faire des choix technologiques et de sélectionner des conceptions et des choix de configuration pour les services Azure à utiliser. Ce processus implique de prendre des décisions techniques dans trois domaines :

  • Définir les exigences en matière de gestion des clés : Que doit faire votre organisation pour protéger les données clients sensibles et le matériel cryptographique sensible ?
  • Sélectionnez les fonctionnalités de chiffrement des données pour protéger les données des clients : comment, où et quand chiffrer les données client dans Azure ?
  • Sélectionnez des solutions de gestion des clés pour protéger les clés client : Quel magasin de clés devez-vous utiliser pour protéger les clés de chiffrement des données utilisées pour chiffrer les données client dans Azure ?

Définir la configuration requise pour la gestion des clé

Les exigences relatives à la gestion des clés peuvent inclure des exigences techniques concernant les services cryptographiques utilisés et des exigences opérationnelles liées aux performances, à la sécurité et à la souveraineté. Le point de départ recommandé pour prendre des décisions sur le moment et la manière de chiffrer les données dans les charges de travail Azure est le système de classification des données d’une organisation. En alignant les exigences de chiffrement sur les classifications des données, plutôt que sur des systèmes ou des solutions spécifiques, les organisations disposent de plus de flexibilité pour sélectionner le niveau de chiffrement optimal lors de la planification de la migration des charges de travail.

Baser les exigences de chiffrement sur la classification des données permet également une approche à plusieurs niveaux, dans laquelle les charges de travail moins critiques peuvent bénéficier de solutions plus simples tout en réservant les configurations les plus complexes aux charges de travail présentant un niveau de risque inhérent plus élevé. Un exemple de cette approche serait d’autoriser l’utilisation de clés gérées par Microsoft pour chiffrer les comptes de stockage pour les environnements de développement tout en exigeant que les comptes de stockage de production utilisent des clés de chiffrement gérées par le Client.

Une fois qu’une organisation a clairement compris le lien entre ses exigences de chiffrement et ses classifications de données, elle peut commencer le processus de sélection des fonctionnalités pour les services Azure qu’elle envisage d’utiliser. Certaines de ces fonctionnalités peuvent fonctionner différemment des systèmes local similaires. Les organisations sont donc encouragées à se familiariser avec le fonctionnement du chiffrement dans Azure et à consulter les recommandations et les meilleures pratiques pour concevoir des solutions de chiffrement. Les articles suivants fournissent des perspectives supplémentaires sur certains des choix techniques que les clients doivent faire et peuvent constituer un point de départ utile pour entamer une conversation sur les objectifs de gestion des clés cloud d’une organisation.

Sélectionnez les fonctionnalités de cryptage des données

De nombreux services Azure permettent le chiffrement à l’aide de clés générées, stockées et gérées entièrement par Azure, sans aucune interaction client. Ces clés gérées par la plateforme peuvent aider les organisations à mettre en œuvre le chiffrement avec peu de frais opérationnels. Toutefois, les clients ayant des exigences strictes en matière de souveraineté des données peuvent avoir besoin de sélectionner des fonctionnalités de chiffrement de plateforme spécifiques pour protéger les données sensibles au repos dans un service Azure donné.

Pour les données hautement sensibles, de nombreux services Azure couramment utilisés permettent aux clients de mettre en œuvre un double chiffrement à l’aide de clés gérées par le client (CMK). La mise en œuvre de clés gérées par le client dans les services Azure peut aider les clients à protéger les données stockées dans ces services contre tout accès non autorisé.

La mise en œuvre de clés gérées par le client dans Azure peut augmenter le coût et la complexité d’une charge de travail. Les organisations sont donc encouragées à évaluer la nécessité de cette fonctionnalité pour chaque charge de travail et niveau de classification des données. La mise en œuvre de clés gérées par le client uniquement pour les charges de travail et les types de données qui en ont besoin peut contribuer à réduire la surcharge opérationnelle pour les charges de travail qui ne gèrent pas de données sensibles.

Si des clés gérées par le client sont requises, elles doivent être configurées pour chaque service Azure respectif. Les organisations peuvent contribuer à rationaliser les efforts de planification de déploiement ou de migration en établissant des normes à l’échelle de l’organisation et des modèles de conception reproductibles pour la mise en œuvre de ces fonctionnalités. Les articles suivants fournissent plus d’informations sur la configuration du chiffrement des données au repos dans Azure :

Découvrez comment configurer les services Azure couramment utilisés pour chiffrer les données au repos à l’aide de clés gérées par le client :

Sélectionner des solutions de gestion de clés

Alors que des fonctionnalités telles que le double chiffrement avec des clés gérées par le client peuvent aider à protéger les données client conservées dans les services Azure, les solutions de gestion de clés basées sur le cloud aident à protéger les clés de chiffrement et autres éléments cryptographiques utilisés pour chiffrer les données sensibles. Les clients ayant des exigences strictes en matière de souveraineté des données doivent sélectionner une solution de gestion de clés adaptée en fonction de leurs besoins d’assurance et du profil de risque de leurs charges de travail.

Les charges de travail qui gèrent des données sensibles peuvent bénéficier de l’assurance supplémentaire fournie par des solutions telles que celles fournies par le module HSM managé d’Azure, notamment des modules de sécurité matérielle validés FIPS-140-2 niveau 3 qui comportent des contrôles de sécurité supplémentaires pour protéger le matériel cryptographique stocké.

Les articles suivants fournissent des conseils que les clients peuvent utiliser pour sélectionner un magasin de clés approprié pour les scénarios identifiés. Il fournit également des informations sur la manière dont Microsoft gère les services cryptographiques utilisés par les clients dans le cadre de leur solution de chiffrement.

Modèles opérationnels pour la gestion des clés

Azure Key Vault implémente le contrôle d’accès basé sur les rôles de différentes manières, selon que vous utilisez le niveau Standard/Premium d’Azure Key Vault ou le module HSM managé d’Azure Key Vault. Ces différences en matière de contrôle d’accès peuvent avoir un impact sur la manière dont une organisation utilise ces fonctionnalités. Cette section décrit ces différences et comment elles peuvent affecter la manière dont une organisation choisit de concevoir ses processus opérationnels pour la gestion des clés cloud.

Contraintes de conformité pour la validation FIPS-140 niveau 3

La validation FIPS-140 de niveau 3 nécessite une identification de l’opérateur basée sur l’identité. Ces protections sont déployées et validées dans le matériel HSM sous-jacent qui prend en charge les services Key Vault dans Azure. Par conséquent, les fonctionnalités RBAC dans Azure Key Vault dépendent des capacités RBAC du matériel sous-jacent.

Le module HSM managé d’Azure Key Vault tire parti des attributions RBAC locales qui sont implémentées au niveau matériel et autorisent les attributions de rôles au niveau du domaine de sécurité (par exemple, à l’échelle du module HSM) ou par clé. Cela signifie que la création de clé nécessite des autorisations administratives sur l’ensemble du domaine de sécurité, car les autorisations ne peuvent pas être attribuées pour une clé qui n’existe pas encore. L’impact de cette conception est que toute personne ayant besoin de stocker une clé dans une instance mHSM doit soit disposer des autorisations complètes pour toutes les clés stockées dans ce domaine de sécurité, soit demander les clés à une équipe centralisée disposant des autorisations requises sur le domaine de sécurité. Cela représente un changement par rapport aux conseils pour Azure Key Vault qui recommande de créer des coffres de clés distincts pour chaque application.

Opérations de gestion des clés dans le module HSM managé d’Azure Key Vault

Afin de développer des processus opérationnels pour la gestion des clés, les clients doivent déterminer s’ils nécessitent un HSM managé d’Azure Key Vault dans le cadre de leur architecture de solution. Les organisations qui envisagent d’utiliser un module HSM managé doivent d’abord se familiariser avec les modèles de contrôle d’accès utilisés pour les opérations d’administration et de chiffrement, et comprendre comment le contrôle d’accès basé sur les rôles est attribué.

En savoir plus sur le contrôle d’accès dans le module HSM managé :

Les organisations qui envisagent d’utiliser le module HSM d’Azure Key Vault doivent consulter la liste des rôles RBAC intégrés et des opérations autorisées pour le module HSM managé et planifier spécifiquement la prise en compte des scénarios d’opérations suivants :

  • Création d’une clé dans le module HSM managé
  • Opérations de gestion d’une clé existante à l’aide du plan de contrôle, telles que les mises à jour de clés ou la rotation des clés
  • Utilisation du plan de données d’une clé existante par une application ou un service

Actuellement, la seule façon d’attribuer des autorisations pour créer une nouvelle clé consiste à attribuer un rôle tel que Crypto User qui inclut également d’autres autorisations telles que la rotation et la suppression de clés. Par conséquent, accorder à un membre de l’équipe d’application les autorisations nécessaires pour créer ses propres clés dans le module HSM managé peut probablement enfreindre les principes du moindre privilège, puisque cet utilisateur disposerait également d’autorisations administratives pour toutes les clés du module HSM. Ce problème peut être résolu en introduisant une équipe centralisée dotée d’autorisations élevées qui peut faciliter les demandes de création de clés, ou en introduisant une automatisation qui peut faciliter les nouvelles demandes de création de clés via des processus de gestion des services informatiques qui exploitent l’API REST du module HSM managé.

Contenu associé