Chiffrement côté client des blobs
La bibliothèque de client de Stockage Blob Azure pour .NET prend en charge le chiffrement des données au sein des applications clientes avant le chargement vers Stockage Azure, ainsi que le déchiffrement des données pendant leur téléchargement vers le client. La bibliothèque prend également en charge l’intégration au coffre de clés Azure pour la gestion des clés de compte de stockage.
Important
Le Stockage Blob prend en charge les chiffrements côté service et côté client. Pour la plupart des scénarios, Microsoft recommande d’utiliser des fonctionnalités de chiffrement côté service pour faciliter l’utilisation de vos données. Pour plus d’informations sur le chiffrement côté service, consultez Chiffrement du Stockage Azure pour les données au repos.
Pour obtenir une procédure pas à pas sur le processus de chiffrement des objets Blob à l’aide du chiffrement côté client et d’Azure Key Vault, consultez Chiffrement et déchiffrement d’objets blob dans Microsoft Azure Storage à l'aide d'Azure Key Vault.
À propos du chiffrement côté client
La bibliothèque de client Stockage Blob Azure utilise Advanced Encryption Standard (AES) pour chiffrer les données utilisateur. Deux versions du chiffrement côté client sont disponibles dans la bibliothèque de client :
- La version 2 utilise le mode Galois/Counter Mode (GCM) avec AES.
- La version 1 utilise le mode Cipher Block Chaining (CBC) avec AES.
Avertissement
L’utilisation de la version 1 du chiffrement côté client n’est plus recommandée en raison d’une vulnérabilité de sécurité dans l’implémentation du mode CBC de la bibliothèque de client. Pour plus d’informations à ce sujet, consultez Stockage Azure mettant à jour le chiffrement côté client dans le Kit de développement logiciel (SDK) pour résoudre la vulnérabilité de sécurité. Si vous utilisez actuellement la version 1, nous vous recommandons de mettre à jour votre application afin d’utiliser la version 2, et de migrer vos données. Consultez la section Atténuer la vulnérabilité de sécurité dans vos applications pour obtenir des conseils supplémentaires.
Atténuer la vulnérabilité de sécurité dans vos applications
En raison d’une vulnérabilité de sécurité découverte dans l’implémentation du mode CBC de la bibliothèque de client de Stockage Blob, Microsoft recommande d’effectuer immédiatement une ou plusieurs des actions suivantes :
Envisagez d’utiliser des fonctionnalités de chiffrement côté service au lieu d’un chiffrement côté client. Pour plus d’informations sur les fonctionnalités de chiffrement côté service, consultez Chiffrement du Stockage Azure pour les données au repos.
Si vous devez utiliser un chiffrement côté client, migrez vos applications du chiffrement côté client v1 vers le chiffrement côté client v2.
Le tableau suivant récapitule les étapes à suivre si vous choisissez de migrer vos applications vers le chiffrement côté client v2 :
| État du chiffrement côté client | Actions recommandées |
|---|---|
| L’application utilise un chiffrement côté client avec une version de la bibliothèque de client qui prend en charge uniquement le chiffrement côté client v1. | Mettez à jour votre application pour utiliser une version de la bibliothèque de client prenant en charge le chiffrement côté client v2. Pour obtenir la liste des versions prises en charge, consultez Matrice de prise en charge du Kit de développement logiciel (SDK) pour le chiffrement côté client. En savoir plus… Mettez à jour votre code pour utiliser le chiffrement côté client v2. En savoir plus… Téléchargez les données chiffrées pour les déchiffrer, puis rechiffrez-les avec le chiffrement côté client v2. En savoir plus… |
| L’application utilise un chiffrement côté client avec une version de la bibliothèque de client qui prend en charge le chiffrement côté client v2. | Mettez à jour votre code pour utiliser le chiffrement côté client v2. En savoir plus… Téléchargez les données chiffrées pour les déchiffrer, puis rechiffrez-les avec le chiffrement côté client v2. En savoir plus… |
En outre, Microsoft recommande d’effectuer les étapes suivantes pour sécuriser les données :
- Configurer vos comptes de stockage pour utiliser des points de terminaison privés afin de sécuriser tout le trafic entre votre réseau virtuel (VNet) et votre compte de stockage via une liaison privée. Pour plus d’informations, consultez Utiliser des points de terminaison privés pour le stockage Azure.
- Limiter l’accès réseau à des réseaux spécifiques.
Matrice de prise en charge du Kit de développement logiciel (SDK) pour le chiffrement côté client
Le tableau suivant montre quelles versions des bibliothèques de client pour .NET, Java et Python prennent en charge les différentes versions du chiffrement côté client :
| .NET | Java | Python | |
|---|---|---|---|
| Chiffrement côté client v2 et v1 | Versions 12.13.0 et ultérieures | Versions 12.18.0 et ultérieures | Versions 12.13.0 et ultérieures |
| Chiffrement côté client v1 uniquement | Versions 12.12.0 et antérieures | Versions 12.17.0 et antérieures | Versions 12.12.0 et antérieures |
Remarque
Le chiffrement côté client v2.1 est disponible dans le Kit de développement logiciel (SDK) Java pour les versions 12.27.0 et ultérieures. Cette version vous permet de configurer la longueur de la région pour le chiffrement authentifié, de 16 octets à 1 Gio. Pour plus d’informations, consultez Exemple : Chiffrement et déchiffrement d’un blob avec le chiffrement côté client v2.
Si votre application utilise un chiffrement côté client avec une version antérieure de la bibliothèque de client .NET, Java ou Python, vous devez commencer par mettre à niveau votre code vers une version prenant en charge le chiffrement côté client v2. Ensuite, vous devez déchiffrer, puis re-chiffrer vos données avec le chiffrement côté client v2. Si nécessaire, vous pouvez utiliser une version de la bibliothèque cliente qui prend en charge le chiffrement côté client v2 côte à côte avec une version antérieure de la bibliothèque cliente pendant la migration de votre code. Pour obtenir des exemples de code, consultez Exemple : Chiffrement et déchiffrement d’un blob avec le chiffrement côté client v2.
Fonctionnement du chiffrement côté client
Les bibliothèques de client de Stockage Blob Azure utilisent un chiffrement d’enveloppe pour chiffrer et déchiffrer vos données côté client. Un chiffrement d’enveloppe chiffre une clé avec une ou plusieurs clés supplémentaires.
Les bibliothèques de client de Stockage Blob s’appuient sur Azure Key Vault pour protéger les clés utilisées pour le chiffrement côté client. Pour plus d’informations sur Azure Key Vault, consultez Qu’est-ce qu’Azure Key Vault ?.
Chiffrement et déchiffrement via la technique d’enveloppe
Le chiffrement via la technique d’enveloppe fonctionne comme suit :
La bibliothèque de client de stockage Azure génère une clé de chiffrement de contenu (CEK) qui est une clé symétrique à usage unique.
Les données utilisateur sont chiffrées à l’aide de cette clé de chiffrement de contenu.
La clé de chiffrement de contenu est ensuite encapsulée (chiffrée) à l’aide de la clé de chiffrement de clés (KEK). La clé de chiffrement de clés (KEK) est identifiée par un identificateur de clé et peut être une paire de clés asymétriques ou une clé symétrique. Vous pouvez la gérer localement ou la stocker dans un coffre de clés Azure.
La bibliothèque de client du Stockage Azure n’a jamais accès à la clé de chiffrement de clés. Elle appelle l’algorithme d’encapsulage de clés fourni par Key Vault. Si besoin est, les utilisateurs peuvent choisir d'utiliser des fournisseurs personnalisés pour l’encapsulage/le désencapsulage de clés.
Les données chiffrées sont ensuite chargées dans le Stockage Blob Azure. La clé enveloppée avec certaines métadonnées de chiffrement supplémentaires est stockée sous la forme de métadonnées sur le blob.
Le déchiffrement via la technique d’enveloppe fonctionne comme suit :
- La bibliothèque de client de Stockage Azure part du principe que l’utilisateur gère la KEK localement ou dans un coffre de clés Azure. L’utilisateur n’a pas besoin de connaître la clé spécifique qui a été utilisée pour le chiffrement. Au lieu de cela, il est en effet possible de configurer et d’utiliser un programme de résolution de clés qui résout les différents identificateurs de clés.
- La bibliothèque de client télécharge les données chiffrées ainsi que tout matériel de chiffrement stocké dans le Stockage Azure.
- La clé CEK enveloppée est ensuite désenveloppée (déchiffrée) à l’aide de la clé KEK. La bibliothèque de client n’a pas accès à la clé KEK pendant ce processus, mais appelle uniquement l’algorithme de désenveloppement du coffre de clés Azure ou d’autres magasins de clés.
- La bibliothèque de client utilise la clé CEK pour déchiffrer les données utilisateur chiffrées.
Chiffrement/déchiffrement sur chargement/téléchargement de blob
La bibliothèque de client de Stockage Blob ne prend en charge le chiffrement de blobs entiers que lors du chargement. Les téléchargements complets et de plages sont tous deux pris en charge. Le chiffrement côté client v2 segmente les données en blocs de chiffrement authentifiés mis en mémoire tampon de 4 Mo qui peuvent seulement être transformés comme un tout. Pour ajuster la taille de bloc, vérifiez que vous utilisez la version la plus récente du Kit de développement logiciel (SDK) qui prend en charge le chiffrement côté client v2.1. La longueur de région est configurable entre 16 octets jusqu’à 1 Gio.
Durant le chiffrement, la bibliothèque de client génère un vecteur d’initialisation aléatoire de 16 octets avec une clé CEK aléatoire de 32 octets, puis effectue un chiffrement d’enveloppe des données du blob en utilisant ces informations. La clé CEK enveloppée ainsi que des métadonnées de chiffrement supplémentaires sont ensuite stockées en tant que métadonnées de blob en même temps que le blob chiffré.
Quand un client télécharge un blob entier, la clé CEK enveloppée est désenveloppée et utilisée en combinaison avec le vecteur d’initialisation pour retourner les données déchiffrées au client.
Le téléchargement d’une plage arbitraire dans le blob chiffré implique d’ajuster la plage fournie par les utilisateurs pour obtenir une petite quantité de données supplémentaires qui peuvent être utilisées pour déchiffrer la plage demandée.
Tous les types d’objets blob (objets blob de blocs, objets blob de pages et objets blob d’ajouts) peuvent être chiffrés/déchiffrés à l’aide de ce schéma.
Avertissement
Si vous modifiez ou chargez vos propres métadonnées pour le blob, vous devez vous assurer que les métadonnées de chiffrement sont conservées. Si vous chargez de nouvelles métadonnées sans conserver les métadonnées de chiffrement, la clé CEK enveloppée, le vecteur d’initialisation et d’autres métadonnées seront perdus et vous ne pourrez pas récupérer le contenu du blob. L’appel de l’opération Définir les métadonnées du blob remplace toujours toutes les métadonnées de blob.
Pendant la lecture à partir d’un blob chiffré ou l’écriture dans un blob chiffré, utilisez des commandes de chargement de blob entier, telles que Put Blob, et des commandes de téléchargement de plage ou de blob entier, telles que Get Blob. Évitez d’écrire dans un blob chiffré à l’aide d’opérations de protocole telles que Put Block, Put Block List, Put Page ou Append Block. L’appel de ces opérations sur un blob chiffré peut endommager celui-ci et le rendre illisible.
Exemple : Chiffrement et déchiffrement d’un blob avec le chiffrement côté client v2
L’exemple de code présenté dans cette section montre comment utiliser le chiffrement côté client v2 pour chiffrer et déchiffrer un blob.
Important
Si vous avez des données qui ont déjà été chiffrées avec le chiffrement côté client v1, vous devez les déchiffrer, puis les rechiffrer avec le chiffrement côté client v2. Consultez les conseils et l’exemple pour votre bibliothèque de client ci-dessous.
Pour utiliser un chiffrement côté client à partir de votre code .NET, reportez-vous à la bibliothèque de client de Stockage Blob. Vérifiez que vous utilisez la version 12.13.0 ou ultérieure. Si vous devez opérer une migration d’une version 11.x vers la version 12.13.0, consultez le Guide de migration.
Deux packages supplémentaires sont requis pour l’intégration d’Azure Key Vault pour le chiffrement côté client :
Le package Azure.Core fournit les interfaces
IKeyEncryptionKeyetIKeyEncryptionKeyResolver. La bibliothèque de client de Stockage Blob pour .NET définit déjà cet assembly comme une dépendance.Le package Azure.Security.KeyVault.Keys (versions 4.x et ultérieures) fournit le client REST Key Vault et les clients de chiffrement utilisés avec le chiffrement côté client. Vérifiez que ce package est référencé dans votre projet si vous utilisez Azure Key Vault comme magasin de clés.
Azure Key Vault est conçu pour les clés principales de valeur élevée et les seuils de limitation par coffre de clés reflètent cette conception. Depuis la version 4.1.0 d’Azure.Security.KeyVault.Keys, l’interface
IKeyEncryptionKeyResolverne prend plus en charge la mise en cache des clés. Si une mise en cache est nécessaire en raison d’une limitation, vous pouvez utiliser l’approche présentée dans cet exemple pour injecter une couche de mise en cache dans une instanceAzure.Security.KeyVault.Keys.Cryptography.KeyResolver.
Les développeurs peuvent fournir une clé, un programme de résolution de clés ou les deux. Les clés sont identifiées à l’aide d’un identificateur de clé qui fournit la logique d’enveloppement et de désenveloppement de la clé CEK. Un programme de résolution de clés est utilisé pour résoudre une clé pendant le processus de déchiffrement. Il définit une méthode de résolution qui retourne une clé à partir d’un identificateur de clé. Il offre aux utilisateurs la possibilité de choisir entre plusieurs clés gérées dans plusieurs emplacements.
Pour le chiffrement, la clé est toujours utilisée et l’absence de clé entraîne une erreur.
Pour le déchiffrement, si la clé est spécifiée et que son identificateur correspond à l’identificateur de clé requis, la clé est utilisée. Sinon, la bibliothèque de client tente d’appeler le programme de résolution. S’il n’y a pas de programme de résolution spécifié, la bibliothèque de client lève une erreur. Si un programme de résolution est spécifié, il est appelé pour obtenir la clé. Si le programme de résolution est spécifié, mais n’a pas de mappage pour l’identificateur de clé, la bibliothèque de client lève une erreur.
Pour utiliser un chiffrement côté client, créez un objet ClientSideEncryptionOptions et définissez-le sur la création de client avec SpecializedBlobClientOptions. Vous ne pouvez pas définir d’options de chiffrement par API. Tout le reste est géré en interne par la bibliothèque de client.
// Your key and key resolver instances, either through Azure Key Vault SDK or an external implementation.
IKeyEncryptionKey key;
IKeyEncryptionKeyResolver keyResolver;
// Create the encryption options to be used for upload and download.
ClientSideEncryptionOptions encryptionOptions = new ClientSideEncryptionOptions(ClientSideEncryptionVersion.V2_0)
{
KeyEncryptionKey = key,
KeyResolver = keyResolver,
// String value that the client library will use when calling IKeyEncryptionKey.WrapKey()
KeyWrapAlgorithm = "some algorithm name"
};
// Set the encryption options on the client options.
BlobClientOptions options = new SpecializedBlobClientOptions() { ClientSideEncryption = encryptionOptions };
// Create blob client with client-side encryption enabled.
// Client-side encryption options are passed from service clients to container clients,
// and from container clients to blob clients.
// Attempting to construct a BlockBlobClient, PageBlobClient, or AppendBlobClient from a BlobContainerClient
// with client-side encryption options present will throw, as this functionality is only supported with BlobClient.
BlobClient blob = new BlobServiceClient
(new Uri($"https://{accountName}.blob.core.windows.net"), new DefaultAzureCredential(), options).GetBlobContainerClient("my-container").GetBlobClient("myBlob");
// Upload the encrypted contents to the blob.
blob.Upload(stream);
// Download and decrypt the encrypted contents from the blob.
MemoryStream outputStream = new MemoryStream();
blob.DownloadTo(outputStream);
Vous pouvez appliquer des options de chiffrement à un constructeur BlobServiceClient, BlobContainerClient ou BlobClient qui accepte des objets BlobClientOptions .
Si un objet BlobClient existe déjà dans votre code mais est dépourvu d’options de chiffrement côté client, vous pouvez utiliser une méthode d’extension pour créer une copie de cet objet avec les options ClientSideEncryptionOptions données. Cette méthode d’extension évite la surcharge liée à la construction d’un nouvel objet BlobClient à partir de zéro.
using Azure.Storage.Blobs.Specialized;
// An existing BlobClient instance and encryption options.
BlobClient plaintextBlob;
ClientSideEncryptionOptions encryptionOptions;
// Get a copy of the blob that uses client-side encryption.
BlobClient clientSideEncryptionBlob = plaintextBlob.WithClientSideEncryptionOptions(encryptionOptions);
Après avoir mis à jour votre code pour utiliser le chiffrement côté client v2, veillez à déchiffrer puis à rechiffrer les données chiffrées existantes, comme décrit dans Rechiffrer des données précédemment chiffrées avec le chiffrement côté client v2.
Rechiffrer des données précédemment chiffrées avec le chiffrement côté client v2
Les données précédemment chiffrées avec le chiffrement côté client v1 doivent être déchiffrées, puis rechiffrées avec le chiffrement côté client v2 pour atténuer la faille de sécurité. Le déchiffrement nécessite le téléchargement des données, et le re-chiffrement nécessite leur rechargement dans Stockage Blob.
Pour obtenir un exemple de projet montrant comment migrer des données du chiffrement côté client v1 vers le chiffrement côté client v2, et comment chiffrer des données avec le chiffrement côté client v2 dans .NET, consultez l’exemple de projet de migration de chiffrement.
Chiffrement côté client et performances
Gardez à l’esprit que le chiffrement de vos données de stockage affecte les performances. Lorsque vous utilisez un chiffrement côté client dans votre application, la bibliothèque de client doit générer en toute sécurité la clé CEK et un vecteur d’initialisation, chiffrer le contenu proprement dit, communiquer avec le magasin de clés choisi pour l’enveloppement des clés, puis mettre en forme et charger des métadonnées supplémentaires. Cette surcharge varie selon la quantité de données chiffrées. Nous recommandons de tester systématiquement les performances des applications au cours du développement.