Modèles de chiffrement des données

Pour comprendre comment les fournisseurs de ressources Azure implémentent le chiffrement au repos, vous devez comprendre les différents modèles de chiffrement et leurs avantages et inconvénients. Pour garantir un langage et une taxonomie courants, les fournisseurs de ressources Azure partagent ces définitions.

Azure chiffre automatiquement les données au repos par défaut à l’aide de clés gérées par la plateforme. Vous pouvez éventuellement choisir d’autres approches de gestion de clés en fonction de vos exigences de sécurité et de conformité. Le chiffrement côté serveur comprend trois scénarios :

• Chiffrement côté serveur en utilisant des clés gérées par la plateforme (par défaut).

  • Les fournisseurs de ressources Azure effectuent les opérations de chiffrement et de déchiffrement.
  • Microsoft gère automatiquement les clés.
  • Activé par défaut sans configuration requise.
  • Fonctionnalités cloud complètes.

• Chiffrement côté serveur en utilisant des clés gérées par le client dans Azure Key Vault (optionnel).

  • Les fournisseurs de ressources Azure effectuent les opérations de chiffrement et de déchiffrement.
  • Vous contrôlez les clés via Azure Key Vault.
  • Nécessite la configuration et la gestion des clients.
  • Fonctionnalités cloud complètes.

• Chiffrement côté serveur en utilisant des clés gérées par le client sur du matériel contrôlé par le client (option avancée).

  • Les fournisseurs de ressources Azure effectuent les opérations de chiffrement et de déchiffrement.
  • Vous avez le contrôle des clés sur le dispositif contrôlé par le client.
  • Configuration complexe et prise en charge limitée du service Azure.
  • Fonctionnalités cloud complètes.

Les modèles de chiffrement côté serveur font référence au chiffrement effectué par le service Azure. Dans ce modèle, le fournisseur de ressources effectue les opérations de chiffrement et de déchiffrement. Par exemple, le stockage Azure peut recevoir des données dans des opérations en texte brut, et effectue le chiffrement et le déchiffrement en interne. Le fournisseur de ressources peut utiliser des clés de chiffrement gérées par Microsoft ou le client, selon votre configuration.

Chacun des modèles de chiffrement côté serveur au repos présente des caractéristiques distinctives de la gestion des clés. Ces caractéristiques incluent l’emplacement et la façon dont vous créez et stockez des clés de chiffrement, ainsi que les modèles d’accès et les procédures de rotation des clés.

Pour le chiffrement côté client, envisagez les points suivants :

• Les services Azure ne peuvent pas voir les données déchiffrées.
• Les clients gèrent et stockent les clés localement (ou dans d’autres magasins sécurisés). Les services Azure n’ont pas accès aux clés.
• Fonctionnalités cloud réduites.

Les modèles de chiffrement pris en charge dans Azure se sont divisés en deux grands groupes : le chiffrement client et le chiffrement côté serveur. Quel que soit le modèle de chiffrement au repos que vous utilisez, les services Azure recommandent toujours l’utilisation d’un transport sécurisé tel que TLS ou HTTPS. Par conséquent, traitez le chiffrement pendant le transport au moyen du protocole de transport. Cela ne devrait pas être un facteur majeur pour déterminer quel modèle de chiffrement au repos utiliser.

Modèle de chiffrement client

Le modèle de chiffrement client fait référence au chiffrement que le service ou l’application appelante effectue en dehors du fournisseur de ressources ou d’Azure. L’application de service dans Azure ou une application s’exécutant dans le centre de données client peut effectuer le chiffrement. Dans tous les cas, lorsque vous utilisez ce modèle de chiffrement, le fournisseur de ressources Azure reçoit un blob de données chiffré sans possibilité de déchiffrer les données d’aucune manière ni d’accéder aux clés de chiffrement. Dans ce modèle, le service appelant ou l’application gère la gestion des clés et la conserve opaque au service Azure.

Chiffrement côté serveur en utilisant des clés gérées par la plateforme (par défaut)

Pour la plupart des organisations, l’exigence essentielle est de s’assurer que les données sont chiffrées chaque fois qu’elles sont au repos. Le chiffrement côté serveur en utilisant des clés gérées par la plateforme (anciennement appelées clés gérées par le service) répond à cette exigence en fournissant un chiffrement automatique par défaut. Cette approche permet le chiffrement au repos sans avoir à configurer ou gérer les clés de chiffrement. Microsoft gère les tâches de gestion des clés telles que l’émission, la rotation et la sauvegarde des clés.

La plupart des services Azure implémentent ce modèle comme comportement par défaut, chiffreant automatiquement les données au repos en utilisant des clés gérées par la plateforme sans nécessiter d’action client. Le fournisseur de ressources Azure crée les clés, les place dans un stockage sécurisé et les récupère quand c’est nécessaire. Le service a un accès complet aux clés et contrôle entièrement la gestion du cycle de vie des accréditations. Ce contrôle offre une forte protection contre le chiffrement sans aucune charge de gestion.

Le chiffrement côté serveur grâce à l’utilisation de clés gérées par la plateforme répond au besoin de chiffrement au repos sans aucune surcharge. Azure permet ce chiffrement par défaut sur l’ensemble des services Azure, assurant une protection automatique des données sans nécessiter de configuration ni de gestion. Vous bénéficiez immédiatement d’une protection solide contre le chiffrement dès le stockage des données dans les services Azure, sans étapes supplémentaires, coûts ou gestion continue.

Le chiffrement côté serveur grâce à l’utilisation de clés gérées par la plateforme signifie que le service a un accès complet pour stocker et gérer les clés. Bien que certaines organisations puissent vouloir gérer les clés car elles exigent une plus grande sécurité, il faut prendre en compte le coût et le risque associés à une solution de stockage personnalisée lors de l’évaluation de ce modèle. Dans de nombreux cas, une organisation peut déterminer que les contraintes de ressources ou les risques d’une solution locale sont supérieurs au risque de gestion cloud du chiffrement des données au repos. Cependant, ce modèle peut ne pas suffire aux organisations qui ont des obligations de contrôler la création ou le cycle de vie des clés de chiffrement, ou pour que des personnels différents gèrent les clés de chiffrement d’un service par rapport à ceux qui le gèrent (séparation de la gestion des clés du modèle global de gestion du service).

Accès aux clés

Lorsque vous utilisez le chiffrement côté serveur avec des clés gérées par la plateforme, le service gère la création, le stockage et l’accès aux clés. En général, les fournisseurs fondamentaux de ressources Azure stockent les clés de chiffrement des données dans un magasin proche des données et rapidement accessible, tandis que les clés de chiffrement des clés résident dans un stockage interne sécurisé.

Avantages

• Configuration simple.
• Microsoft gère la rotation des clés, la sauvegarde et la redondance.
• Vous n’entraînez pas de coûts ou de risques associés à l’implémentation d’un schéma de gestion de clés personnalisé.

Considérations

• Aucun contrôle sur les clés de chiffrement (spécification des clés, cycle de vie, révocation, etc.). Cette option convient à la plupart des cas d’usage, mais peut ne pas répondre aux exigences de conformité spécialisées.
• Aucune possibilité de séparer la gestion des clés du modèle de gestion global du service. Les organisations nécessitant une séparation des tâches peuvent nécessiter des clés gérées par le client.

Chiffrement côté serveur en utilisant des clés gérées par le client dans Azure Key Vault et Azure Key Vault Managed HSM (optionnel)

Dans les situations où les organisations ont des exigences spécifiques pour contrôler leurs clés de chiffrement au-delà du chiffrement géré par la plateforme par défaut, vous pouvez choisir en option le chiffrement côté serveur en utilisant des clés gérées par le client dans Key Vault ou Azure Key Vault Managed HSM. Cette approche repose sur le chiffrement par défaut au repos, vous permettant d’utiliser vos propres clés pendant qu’Azure continue de gérer les opérations de chiffrement et de déchiffrement.

Certains services peuvent stocker uniquement la clé de chiffrement de la clé racine (KEK) dans Azure Key Vault et stocker la clé de chiffrement des données chiffrées (DEK) dans un emplacement interne plus proche des données. Dans ce scénario, vous pouvez utiliser le modèle bring your own key (BYOK) pour importer des clés dans Key Vault ou générer de nouvelles clés dans Key Vault, puis les utiliser pour chiffrer les ressources souhaitées. Pendant que le fournisseur de ressources effectue les opérations de chiffrement et de déchiffrement, il utilise votre KEK configuré comme clé racine pour toutes les opérations de chiffrement.

La perte de clés de chiffrement de clé signifie la perte de données. Pour cette raison, ne supprimez pas les clés. Sauvegardez toujours les clés lorsque vous les créez ou les faites tourner. Lorsqu’un KEK est tourné, le service enveloppe les clés de chiffrement des données avec la nouvelle version de clé – les données sous-jacentes ne sont pas re-chiffrées. Les anciennes et nouvelles versions de clé doivent rester activées jusqu’à ce que toutes les clés de chiffrement des données soient enveloppées avec la nouvelle version de clé. Pour vous protéger contre tout effacement cryptographique accidentel ou malveillant, la suppression réversible et la protection contre le vidage doivent être activées sur tous les coffres stockant des clés de chiffrement de clés. Au lieu de supprimer une clé, désactivez la clé de chiffrement de clés en la mettant sur false. Utilisez des contrôles d’accès pour révoquer l’accès à des utilisateurs ou services individuels dans Azure Key Vault ou un HSM managé.

Pour les scénarios de clés gérés par le client, utilisez Azure Key Vault Premium tier (HSM-supported) comme minimum pour les exigences de conformité qui imposent des clés protégées par HSM. Utilisez Azure Key Vault Managed HSM pour les charges de travail nécessitant la souveraineté des clés ou une capacité dédiée HSM. Pour les organisations ayant des exigences réglementaires ou contractuelles imposant que les matériaux clés résident physiquement en dehors de l’infrastructure Microsoft, Azure Key Vault Managed HSM prend également en charge la gestion externe des clés (preview), ce qui maintient le KEK dans un HSM exploité par le client entièrement en dehors d’Azure.

Accès aux clés

Dans le modèle de chiffrement côté serveur qui utilise des clés gérées par le client dans Azure Key Vault, le service accède aux clés pour chiffrer et déchiffrer selon les besoins. Vous rendez les clés de chiffrement au repos accessibles à un service via une politique de contrôle d'accès. Cette stratégie accorde à cette identité de service un accès pour recevoir la clé. Vous pouvez configurer un service Azure s’exécutant pour le compte d’un abonnement associé avec une identité dans cet abonnement. Le service peut effectuer l’authentification Microsoft Entra et recevoir un jeton d’authentification en s’identifiant lui-même comme étant ce service agissant pour le compte de l’abonnement. Le service présente ensuite le jeton à Key Vault pour obtenir une clé à laquelle il peut accéder.

Pour les opérations qui utilisent des clés de chiffrement, vous pouvez accorder à une identité de service l’accès à l’une des opérations suivantes : decrypt, encrypt, unwrapKey, wrapKey, verify, sign, get, list, update, create, import, delete, backup et restore.

Pour obtenir une clé destinée au chiffrement ou au déchiffrement de données au repos, l’identité de service que l’instance de service du Resource Manager exécute doit avoir UnwrapKey (pour obtenir la clé de déchiffrement) et WrapKey (pour insérer une clé dans Key Vault lors de la création d’une nouvelle clé).

Avantages

• Contrôle total des touches utilisées. Les clés de chiffrement sont gérées dans votre Key Vault sous votre contrôle.
• Vous pouvez chiffrer plusieurs services en utilisant une seule clé racine.
• Vous pouvez séparer la gestion des clés du modèle global de gestion du service.
• Vous pouvez définir le service et l’emplacement clé selon les régions.

Inconvénients

• Vous êtes entièrement responsable de la gestion des accès clés.
• Vous avez entièrement la responsabilité de la gestion du cycle de vie des clés.
• Surcharge supplémentaire de configuration et d’installation.

Chiffrement côté serveur en utilisant des clés gérées par le client dans du matériel contrôlé par le client (option spécialisée)

Certains services Azure activent le modèle de gestion des clés HYOK (Host Your Own Key) pour les organisations avec des exigences de sécurité spécialisées. Ce mode de gestion est utile dans des situations très réglementées nécessitant le chiffrement des données au repos et la gestion des clés dans un dépôt propriétaire totalement hors du contrôle de Microsoft. Cela va au-delà du chiffrement géré par la plateforme par défaut et des clés optionnelles gérées par le client dans Azure Key Vault.

Dans ce modèle, le service doit utiliser la clé d’un site externe pour déchiffrer le DEK. Les garanties de performances et de disponibilité sont affectées, et la configuration est beaucoup plus complexe. De plus, comme le service n'a pas accès au DEK lors des opérations de chiffrement et de déchiffrement, les garanties globales de sécurité de ce modèle sont similaires à celles que les clés sont gérées par le client dans Azure Key Vault. Par conséquent, ce modèle n’est pas approprié pour la plupart des organisations, sauf s’ils ont des exigences réglementaires ou de sécurité très spécifiques qui ne peuvent pas être satisfaites avec des clés gérées par la plateforme ou des clés gérées par le client dans Azure Key Vault. En raison de ces limitations, la plupart des services Azure ne prennent pas en charge le chiffrement côté serveur en utilisant des clés gérées par le client dans du matériel contrôlé par le client. L’une des deux clés du chiffrement à double clé suit ce modèle.

Accès aux clés

Lorsque vous utilisez le chiffrement côté serveur avec des clés gérées par le client dans du matériel contrôlé par le client, vous conservez les clés de chiffrement des clés sur un système que vous configurez. Les services Azure qui prennent en charge ce modèle permettent d’établir une connexion sécurisée à un magasin de clés fourni par le client.

Avantages

• Vous avez un contrôle total sur la clé racine car un magasin fourni par le client gère les clés de chiffrement.
• Vous pouvez chiffrer plusieurs services en utilisant une seule clé racine.
• Vous pouvez séparer la gestion des clés du modèle global de gestion du service.
• Vous pouvez définir le service et l’emplacement clé selon les régions.

Inconvénients

• Vous avez entièrement la responsabilité du stockage, de la sécurité, des performances et de la disponibilité des clés.
• Vous êtes entièrement responsable de la gestion des accès clés.
• Vous avez entièrement la responsabilité de la gestion du cycle de vie des clés.
• Vous entraînez des coûts importants d’installation, de configuration et de maintenance en cours.
• Le modèle augmente la dépendance à la disponibilité du réseau entre le centre de données client et les centres de données Azure.

Contenu connexe

• Services qui prennent en charge les CMKs dans Azure Key Vault et Azure Key Vault Managed HSM
• Utilisation du chiffrement dans Azure
• Double chiffrement