Chiffrement côté client pour les files d’attente
La bibliothèque de client de Stockage File d'attente Azure pour .NET, Java et Python prend en charge le chiffrement des données dans les applications clientes avant chargement dans Stockage Azure, et le déchiffrement des données pendant leur téléchargement sur le client. Les bibliothèques client prend également en charge l’intégration à Azure Key Vault pour la gestion des clés de compte de stockage.
Important
Le Stockage Azure 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.
À propos du chiffrement côté client
La bibliothèque cliente du Stockage File d'attente Azure utilise 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 File d'attente Azure, 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. Mettez à jour votre code pour utiliser le chiffrement côté client v2. |
| 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 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 et Python prennent en charge quelles versions du chiffrement côté client :
| .NET | Python | |
|---|---|---|
| Chiffrement côté client v2 et v1 | Versions 12.11.0 et ultérieures | Versions 12.4.0 et ultérieures |
| Chiffrement côté client v1 uniquement | Versions 12.10.0 et antérieures | Versions 12.3.0 et antérieures |
Si votre application utilise un chiffrement côté client avec une version antérieure de la bibliothèque de client .NET 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.
Fonctionnement du chiffrement côté client
Les bibliothèques de client de Stockage File d'attente 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 File d'attente Azure 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 vers Stockage File d'attente Azure. La clé enveloppée avec certaines métadonnées de chiffrement supplémentaires est interpolée avec les données chiffrées.
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 des messages
Dans la mesure où les messages de la file d’attente peuvent avoir n’importe quel format, la bibliothèque cliente définit un format personnalisé qui inclut le vecteur d’initialisation (IV) et la clé de chiffrement de contenu (CEK) chiffrée dans le texte du message.
Au cours du chiffrement, la bibliothèque cliente génère un vecteur d’initialisation aléatoire de 16 octets avec une clé de chiffrement de contenu aléatoire de 32 octets, puis effectue le chiffrement d’enveloppe du texte du message de la file d’attente à l’aide de ces informations. La clé de chiffrement de contenu encapsulée et les métadonnées de chiffrement supplémentaires sont ensuite ajoutées au message chiffré de la file d’attente. Ce message modifié est stocké sur le service.
<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>
Au cours du déchiffrement, la clé encapsulée est extraite du message de la file d’attente et désencapsulée. Le vecteur d’initialisation est également extrait du message de la file d’attente et utilisé en combinaison avec la clé désencapsulée pour déchiffrer les données du message de la file d’attente. Comme les métadonnées de chiffrement sont petites (moins de 500 octets), même si elles entrent en compte dans la limite de 64 Ko du message de la file d’attente, leur impact reste facile à gérer. Le message chiffré est encodé en Base64, comme illustré dans l’extrait de code ci-dessus, ce qui augmente également la taille du message envoyé.
En raison de la nature éphémère des messages dans la file d’attente, il ne devrait pas être nécessaire de les déchiffrer et de les rechiffrer après la mise à jour vers le chiffrement côté client v2. Les messages moins sécurisés font l’objet d’une rotation au cours de la consommation normale de la file d’attente.
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.