Comprendre le chiffrement des données dans le stockage Azure

Azure Storage est l'épine dorsale d'innombrables applications cloud-natives, lacs de données, solutions de sauvegarde et charges de travail d'entreprise. Avec ce rôle central vient une responsabilité indéniable: protéger les données où qu'elles résident. Le chiffrement est la base de cette protection, en assurant que les informations sensibles restent confidentielles même si les attaquants contournent les contrôles du réseau ou la sécurité physique. Microsoft Azure fournit un cadre de chiffrement stratifié qui couvre les données à la fois au repos et en transit, avec des options allant du chiffrement entièrement géré, fourni par plate-forme à des hiérarchies de clés contrôlées par le client.

Cet article développe les capacités de chiffrement de base dans Azure Storage, y compris Azure Blob Storage, Azure Files, Queue Storage et Table Storage. Nous traversons chaque couche de chiffrement, comment la configurer, et les décisions qui comptent pour la conformité, les performances et le contrôle opérationnel.

Chiffrement au repos

Le chiffrement au repos protège les données lorsqu'il est écrit sur des supports physiques à l'intérieur des datacenters d'Azure. Cela inclut tout ce qui va des blocs de disque bruts utilisés par les machines virtuelles aux niveaux de stockage d'objets dans Blob Storage. Azure implémente le chiffrement au repos en combinant un cryptage transparent côté stockage, un cryptage au niveau de l'infrastructure et un cryptage au niveau du client optionnel.

Chiffrement du service de stockage d'azur (SSE)

SSE est le mécanisme de chiffrement par défaut pour tous les nouveaux comptes Azure Storage existants. Il crypte les données à la couche de service de stockage avant de les écrire sur disque et les déchiffre lorsqu'elles sont lues. Ce processus est entièrement transparent pour les applications; aucun changement de code, aucun drapeau de configuration et aucun réglage de performance sont requis. SSE utilise 256-bit Advanced Encryption Standard (AES-256), l'un des algorithmes de chiffrement symétrique les plus puissants disponibles. Les clés de chiffrement sont gérées par Microsoft et pivotées en interne sur une base régulière.

SSE couvre tous les services de stockage Azure : Blob Storage (blob blobs, append blobs et page blobs), Azure Files (y compris les partages de fichiers), Queue Storage et Table Storage. Pour Azure Managed Disks, qui soutient le stockage de la machine virtuelle, le chiffrement est géré séparément par Azure Disk Encryption ou cryptage côté serveur (SSE + touches gérées par la plate-forme).

Chiffrement des infrastructures

Au-delà de SSE, Azure Storage offre le cryptage des infrastructures, qui ajoute une deuxième couche de cryptage au niveau de l'infrastructure de stockage. SSE protège les données sur les disques physiques, le cryptage des infrastructures crypte à nouveau les données avant qu'elles ne soient écrites au cluster de stockage.

Le chiffrement de l'infrastructure est activé au niveau du compte de stockage et utilise des clés gérées par la plate-forme. Il n'exige pas de changement d'applications ou de code client. L'échange est un petit frais généraux de saisie-écriture (généralement négligeable pour la plupart des charges de travail) et ne peut être désactivé une fois activé.

Clés gérées par le client (CMK)

Pour les organisations qui doivent contrôler leurs propres clés de chiffrement – soit pour respecter les mandats de conformité, mettre en œuvre des calendriers de rotation des clés, soit s'intégrer aux systèmes de gestion des clés existants – Azure Storage prend en charge Les clés managées par les clients (CMK) stockées dans Azure Key Vault. Lorsque CMK est activé, la clé racine utilisée pour envelopper les clés de chiffrement est stockée dans votre propre instance de clé Vault. Cela signifie que Microsoft ne peut pas décoder les données sans avoir accès à votre clé, et vous pouvez révoquer l'accès à tout moment en désactivant ou en supprimant la clé.

Le service de stockage crypte toujours les données à l'aide de AES-256, mais la clé de chiffrement (KEK) qui protège les clés de chiffrement des données (DEKs) est gérée par vous. Vous pouvez choisir entre une clé de chiffrement par défaut clé (protégée par logiciel ou soutenue par HSM) ou une clé de chiffrement par défaut pour la conformité au niveau 3 de la norme FIPS 140-2. La rotation des clés peut être manuelle ou automatisée en utilisant la politique de rotation des clés de chiffrement par défaut clé.

Considérations importantes pour le CMK :

  • Si vous désactivez ou supprimez la clé dans Key Vault, Azure Storage ne pourra pas accéder aux données. Cela rend le compte de stockage inaccessible et peut entraîner une perte permanente de données si elle n'est pas gérée avec soin.
  • CMK est disponible pour le stockage de Blob, les fichiers Azure, le stockage de files, le stockage de table et le stockage de Data Lake d'Azure Gen2.
  • CMK ne supporte pas directement les disques Azure Managed ; ce scénario utilise le chiffrement côté serveur avec des clés gérées par le client (SSE + CMK).
  • La surveillance des opérations clés par l'intermédiaire des registres d'audit de Key Vault et Azure Monitor est essentielle pour détecter les tentatives d'accès non autorisées ou l'expiration de la clé.

Clés fournies par le client (CPK)

Pour Blob Storage, il existe une troisième option de clé appelée Clefs fournis par le client (CPK). CPK permet à un client de fournir une clé de chiffrement au moment de chaque requête, plutôt que de stocker la clé dans Key Vault. La clé est utilisée pour cette seule opération de lecture ou d'écriture et n'est pas conservée par Azure. Ceci est utile pour les scénarios où vous voulez éviter la gestion de clé entièrement au niveau de la plate-forme – par exemple, lors du traitement de données hautement sensibles qui ne peuvent pas partager une voûte clé avec d'autres charges de travail. CPK est supporté pour les blocs blobs et les blobs de page et fonctionne avec Azure PowerShell, .NET SDK, Java SDK et REST API appels.

Chiffrement en transit

Le chiffrement dans le transit permet de sécuriser les données en les protégeant de l'interception, des attaques de l'homme dans le milieu et des écoutes. Azure Storage fournit de multiples mécanismes – de l'application HTTPS obligatoire au chiffrement SMB pour les actions de fichiers – pour s'assurer que les données ne sont jamais transmises en texte clair.

Exécution HTTPS

Tous les paramètres Azure Storage supportent HTTPS (HTTP sur TLS 1.2 ou plus). Par défaut, HTTP et HTTPS sont acceptés, mais la meilleure pratique est de renforcer le transfert sécurisé au niveau du compte de stockage. Ce paramètre rejette toute requête faite sur HTTP, bloquant les connexions à partir de clients mal configurés ou d'applications existantes qui ne supportent pas TLS.

Pour le développement et les tests, assurez-vous qu'aucun paramètre HTTP n'est utilisé dans les pipelines de production. Les SDK Azure font appliquer HTTPS par défaut lorsqu'ils utilisent des chaînes de connexion qui incluent le suffixe de paramètre par défaut.

Exigences de la version TLS

Azure Storage prend en charge les TLS 1.0, 1.1 et 1.2 du côté client. Cependant, Microsoft conseille fortement de désactiver les TLS 1.0 et 1.1 pour répondre aux normes de sécurité modernes. À partir de l'API Azure Storage REST version 2021-06-08, vous pouvez définir une version TLS minimale au niveau du compte de stockage. Ceci est imposé côté serveur: tout client tentant de se connecter avec une version TLS plus ancienne reçoit une réponse 403 Interdite.

Pour configurer la version minimale TLS :

  • Allez sur le compte de stockage dans le portail Azure.
  • Sélectionnez Configuration sous la section Sécurité + réseautage.
  • Réglez la version TLS minimale[ à 1.2.

Ce paramètre s'applique à tous les paramètres, y compris le stockage Blob, File, Queue et Table. Vérification pour toutes les applications existantes qui peuvent se fier à TLS 1.0 ou 1.1 avant d'appliquer la mise à niveau.

Cryption SMB pour les fichiers Azure

Azure Files utilise le protocole Serveur Message Block (SMB) pour l'accès au partage de fichiers. SMB 3.0 et plus tard inclut le cryptage intégré qui protège les données en transit entre le client et le partage de fichiers. Lorsque vous accédez à un partage de fichiers Azure d'un client pris en charge (Windows 8/Server 2012 ou plus, Linux avec le client du noyau CIFS 4.0+), la connexion est automatiquement chiffrée sur le réseau. Azure Files nécessite SMB 3.0 ou plus avec le cryptage pour toutes les connexions externes; les versions antérieures de SMB sont bloquées.

Pour les clients sur site se connectant via VPN ou ExpressRoute, le cryptage SMB garantit que les données traversant l'internet public (le cas échéant) restent confidentielles. Sur les réseaux internes Azure, le cryptage est toujours recommandé pour protéger contre les attaques latérales potentielles de mouvements au sein du datacenter.

Points de service et de fin de service privés

Alors que le cryptage protège les données en transit, les contrôles au niveau du réseau réduisent encore l'exposition. Azure Private Endpoints attribue une adresse IP privée au compte de stockage de votre réseau virtuel, apportant efficacement le service de stockage dans votre VNet. Le trafic entre votre réseau virtuel et le compte de stockage circule sur le réseau de base Microsoft, et non sur Internet public.

Les paramètres de service offrent un avantage similaire au niveau du sous-réseau, mais sans IP privée. Les deux options s'intègrent parfaitement aux paramètres SSE et cryptage en transit.

Gestion et rotation des clés

Même avec SSE utilisant des clés gérées par plate-forme, votre organisation conserve la propriété des données et la responsabilité légale de leur protection. Les clés doivent être périodiquement tournées pour limiter l'impact d'un compromis clé potentiel ou pour satisfaire aux exigences de conformité telles que PCI DSS, HIPAA ou SOC 2.

Pour les comptes de stockage utilisant CMK, la rotation est gérée par Azure Key Vault. Vous pouvez configurer la rotation automatique en définissant une politique de rotation sur la clé – par exemple, tous les 90 jours. Azure Storage reprend la nouvelle version de la clé et re-crypte les clés de chiffrement de données avec la dernière clé. Aucune intervention manuelle ou de temps d'arrêt n'est nécessaire.

L'audit de l'utilisation de la clé est simple avec les journaux de diagnostic de Key Vault. Exporter les journaux vers un espace de travail Log Analytics ou Azure Storage et configurer des alertes pour des opérations comme , ou . Tout schéma d'accès inattendu à la clé pourrait indiquer une tentative de déchiffrement non autorisé.

Apportez votre propre clé (BYOK) avec HSM

Pour les organisations des industries hautement réglementées, Azure Key Vault Managed HSM propose un module de sécurité matérielle validé FIPS 140-2 de niveau 3 (HSM) pour stocker les clés de chiffrement. Vous pouvez générer la clé sur site et la transférer en toute sécurité au HSM en utilisant un processus appelé Apportez votre propre clé (BYOK). Cela garantit que Microsoft n'a jamais accès à la matière première. BYOK est pris en charge pour les scénarios CMK et CPK.

Conformité et harmonisation réglementaire

Le chiffrement de l'infrastructure s'harmonise avec les exigences de cryptage à double couche observées dans des normes fédérales spécifiques. CMK fournit la séparation de clé nécessaire pour les données CJIS (Criminal Justice Information Services) et IRS 1075, où le CSP ne doit pas avoir accès à des clés de déchiffrement indépendantes.

Il vous incombe de vérifier que la configuration de cryptage choisie répond aux contrôles spécifiques de votre champ de conformité. Azure fournit des documents de conformité et des rapports de vérification par l'intermédiaire de la page Microsoft Compliance Offers. Utilisez la Politique Azure pour appliquer les paramètres de cryptage dans votre organisation, comme exiger CMK pour tous les comptes de stockage contenant des données de production ou exiger une version minimale de TLS de 1.2.

Considérations relatives aux performances

Le chiffrement en Azure Storage introduit des frais généraux minimes. SSE fonctionne au niveau du nœud de stockage et est optimisé pour le débit. Dans la plupart des points de repère, le coût du chiffrement en CPU d'AES-256 est bien inférieur à la latence du réseau I/O. Le chiffrement en infrastructure ajoute un petit coût d'amplification par écriture, mais pour les charges de travail typiques (comptes de stockage GPv2, blocs de blobs à usage général), l'impact est bien inférieur à 5% pour les charges de travail successives.

CMK ajoute la latence réseau pour les opérations de décomptage de clés parce que le service de stockage doit appeler Key Vault pour déchiffrer le DEK sur chaque montage ou récupération. Cette latence est généralement inférieure à 10 ms par appel, et le résultat est mis en cache, de sorte que les requêtes subséquentes au sein de la même session n'entraînent pas les frais généraux.

Résumé des pratiques exemplaires

La mise en œuvre du chiffrement dans Azure Storage nécessite une planification mais pas de complexité. Les pratiques suivantes vous aideront à construire une posture de chiffrement robuste:

  • Vérifier SSE est activé. Il est activé par défaut, mais auditer les comptes existants créés avec les anciennes versions de l'API de stockage d'azure ou des outils de gestion pour s'assurer qu'aucun compte n'est désactivé.
  • Activer l'application de transfert sécurisée sur chaque compte de stockage pour garantir une communication HTTPS seulement.
  • Filtre la version minimale TLS à 1.2 dans tous les comptes de stockage de production.
  • Utiliser des clés gérées par le client[ pour les charges de travail assujetties aux exigences de conformité qui exigent le contrôle des clés ou la séparation des fonctions.
  • Cryptage de l'infrastructure d'exécution si votre cadre de conformité exige explicitement un cryptage double couche.
  • Roter les clés régulièrement–automatiser la rotation en utilisant les politiques de la faille clé pour éviter les erreurs manuelles.
  • Opérations de cryptage de moniteur par le biais du diagnostic Azure Monitor et Key Vault. Définir des alertes pour les suppressions de clés, les désactivations ou les tentatives de défaillances d'accès.
  • Utilisez la politique d'azure pour faire respecter les exigences de chiffrement, comme exiger que CMK soit utilisé pour certains groupes de ressources ou bloquer l'accès HTTP.
  • Considérez le cryptage côté client pour les données ultrasensibles qui doivent être chiffrées avant qu'elles ne atteignent Azure Storage. Les bibliothèques clientes Azure Storage supportent cela, mais il ajoute de la complexité et devrait être réservé à des scénarios exceptionnels.
  • Testez votre plan de reprise après sinistre avec les touches CMK. Si votre Vault Key est dans une région différente et échoue, votre compte de stockage peut-il encore être accessible ? Utilisez la réplication de clé multi-régions ou une Vault Key de sauvegarde.

En superposant le chiffrement au repos, le chiffrement en transit et une gestion forte des clés, vous pouvez atteindre une posture de sécurité qui répond aux exigences de la conformité moderne sans sacrifier les performances ou la simplicité opérationnelle. Pour plus de détails, reportez-vous à la documentation du Service de stockage d'Azure et au Guide de transfert de sécurité sur Microsoft Learn.