Sécuriser votre compte de stockage Azure

stockage Azure offre un stockage cloud évolutif et durable pour les blobs, fichiers, files d’attente et tables dans un seul compte de stockage. Comme un compte de stockage peut contenir des données de niveaux de sensibilité très différents et est souvent la cible d’attaques d’exfiltration et de ransomware, prenez des mesures délibérées pour protéger le compte, les données qu’il détient et les identités qui y accèdent.

Cet article fournit des recommandations de sécurité pour aider à protéger votre compte stockage Azure. Ces recommandations s’appliquent à tous les services de données du compte (blobs, fichiers, files d’attente et tableaux). Pour des conseils spécifiques à chaque service de données, consultez les articles sur la sécurité associés à la fin de cet article.

Les recommandations de sécurité de cet article implémentent des principes de confiance zéro : « Vérifier explicitement », « Utiliser l’accès au privilège minimum » et « Supposer une violation ». Pour obtenir des conseils complets sur la confiance zéro, consultez le Centre d’aide sur la confiance Zéro.

Sécurité spécifique au service

stockage Azure possède des caractéristiques architecturales qui influencent la manière dont vous le déployez en toute sécurité. Les choix que vous faites lors de la création d’un compte – modèle de déploiement, type, redondance et configuration des points de terminaison – sont difficiles à modifier plus tard et affectent la posture de sécurité de chaque charge de travail qui utilise le compte.

Architecture des comptes de stockage

  • Utilisez le modèle de déploiement Azure Resource Manager : Créez de nouveaux comptes de stockage en utilisant le modèle de déploiement Azure Resource Manager. Les comptes Resource Manager prennent en charge le contrôle d’accès basé sur le rôle (RBAC) Azure, les identités gérées, l’autorisation Microsoft Entra ID pour les données, les verrous de ressources, les tags et les politiques – aucun de ces éléments n’étant disponible avec le modèle de déploiement classique. Migrez tous les comptes classiques restants. Pour plus d’informations, voir Migrer un compte de stockage classique vers Azure Resource Manager.

  • Séparez les comptes de stockage par charge de travail, environnement et sensibilité : créez des comptes séparés pour le développement, la préproduction et la production, ainsi que des comptes séparés pour les données de différentes classifications de sensibilité. Un compte de stockage constitue une limite de confiance reposant sur une clé partagée et une limite de définition des stratégies ; mélanger des charges de travail dans un même compte augmente le périmètre d’impact d’une compromission et rend plus difficile la modélisation des accès selon le principe du moindre privilège.

  • Utilisez un compte par région pour l’isolement régional : placer des comptes dans la région où fonctionnent leurs charges de travail consommatrices réduit le transfert de données entre régions et simplifie les frontières de conformité. Pour les conceptions multirégionales, associez des comptes régionaux à un stockage géo-redondant ou à la réplication d’objets plutôt que de servir toutes les régions depuis un seul compte. Pour plus d’informations, consultez redondance de stockage Azure.

Utilisation appropriée d’stockage Azure

  • N’utilisez pas les clés de compte de stockage Azure comme informations d’identification d’application à long terme : les clés de compte de stockage accordent un contrôle total sur le compte et ne peuvent pas être restreintes à une portée spécifique. Les applications devraient utiliser Microsoft Entra ID avec des identités gérées ou, lorsque Entra ID n'est pas une option, des jetons d'accès partagé (SAS) à signature partagée de délégation utilisateur éphémère. Pour plus d’informations, consultez Autoriser l’accès aux données dans stockage Azure.

  • N'utilisez pas stockage Azure comme un magasin de secrets polyvalent : les secrets, chaînes de connexion et certificats appartiennent à Azure Key Vault, qui fournit la rotation, les politiques d'accès, la protection des modules de sécurité matérielle (HSM) et les traces d'audit. Pour plus d’informations, consultez la vue d’ensemble d’Azure Key Vault.

Sécurité du réseau

Les comptes de stockage sont accessibles par défaut via Internet. Réduire la surface d’attaque réseau est le changement le plus efficace que vous puissiez opérer pour protéger un compte contre les accès non autorisés, l’exfiltration de données et la reconnaissance.

  • Désactivez l'accès au réseau public au compte de stockage : Lorsque vos clients sont entièrement sur Azure ou accessibles via Private Link, réglez l'accès public du compte sur Désactivé afin que seules les requêtes via des points de terminaison privés soient acceptées. Pour plus d’informations, consultez Configurer Pare-feu et réseaux virtuels dans Stockage Azure.

  • Utilisez des points de terminaison privés pour accéder depuis des réseaux virtuels : Un point de terminaison privé attribue une adresse IP privée de votre réseau virtuel au compte de stockage et aroute le trafic via la dorsale Microsoft. Combiné à un accès public au réseau désactivé, les points de terminaison privés éliminent l’exposition à Internet. Pour plus d’informations, consultez Utiliser des points de terminaison privés pour stockage Azure.

  • Restreignez l’accès public avec le pare-feu de stockage lorsque les points de terminaison privés ne sont pas pratiques : Si les clients doivent atteindre le compte via un réseau public, réglez l’action par défaut du pare-feu sur Refuser et n’autorisez que les plages IP spécifiques, les sous-réseaux réseau virtuels (via les points de terminaison de service) ou les instances de ressources nécessitant un accès. Pour plus d’informations, consultez Configurer Pare-feu et réseaux virtuels dans Stockage Azure.

    • Autoriser les services Microsoft de confiance lorsqu’ils ont besoin d’accéder au compte : les règles de pare-feu de refus par défaut bloquent les requêtes provenant d’autres services Azure (par exemple, Sauvegarde Azure, Log Analytics et Microsoft Defender for Storage), ainsi que du portail Azure et des pipelines de diagnostic. Ajoutez la mention Autoriser les services Azure dans la liste des services de confiance pour accéder à cette exception de compte de stockage afin que les services propriétaires sur lesquels vous comptez puissent accéder au compte sans l’ouvrir à l’internet public. Pour plus d’informations, consultez Accéder à des services de Azure approuvés.

    • Accorder l’accès à des instances de ressources spécifiques plutôt qu’à des services de confiance de manière générale : Privilégiez les règles d’instance de ressource, qui autorisent une ressource Azure nommée et son identité gérée, plutôt que l’exception générale « Autoriser les services services Microsoft fiables ». Les règles d’instance de ressource produisent une surface de confiance plus petite. Pour plus d’informations, voir Permettre l'accès à partir des instances de ressources Azure.

  • Associer les comptes de stockage à un périmètre de sécurité réseau : Un périmètre de sécurité réseau définit des limites logiques entre les ressources de la plateforme en tant que service et bloque le trafic extérieur par défaut, offrant une défense approfondie au-delà des règles de pare-feu par compte. Pour plus d’informations, voir Périmètre de sécurité réseau pour stockage Azure.

  • Imposez une version TLS minimale de la 1.2 ou ultérieure : Configurez la version TLS minimale du compte de stockage pour rejeter les clients négociant des versions plus anciennes et obsolètes. Pour plus d’informations, voir Configurer la version minimale requise de Transport Layer Security (TLS) pour un compte de stockage.

  • Exiger un transfert sécurisé (HTTPS) : Activez la propriété requise pour le transfert sécurisé afin de rejeter toute requête effectuée via HTTP. Cette exigence s’applique aux points de terminaison REST ainsi qu’à l’accès SMB à Azure Files. Pour plus d’informations, voir Exiger un transfert sécurisé pour un compte de stockage.

    • Certains scénarios, comme les anciens clients PME ou les outils hérités, nécessitent de l’HTTP. Dans de tels cas, isoler ces clients dans un segment réseau contrôlé et les migrer hors HTTP dès que possible.

  • Restreignez les opérations de réplication et de copie d’objets entre locataires : Configurez le compte de stockage pour autoriser les opérations de copie et de réplication d’objet uniquement depuis les comptes sources du même locataire, ou uniquement depuis les comptes sources autorisés. Cette configuration empêche le déplacement des données entre les locataires par des utilisateurs disposant d’autorisations du plan de données. Pour plus d’informations, voir Portée autorisée pour les opérations de copie et Empêcher la réplication d’objets entre les locataires Microsoft Entra.

  • Utilisez les balises de service VNet pour les règles sortantes vers stockage Azure : Lorsque vous restreignez le trafic sortant d’un réseau virtuel vers stockage Azure, utilisez l’étiquette Storage de service (ou une variante régionale) plutôt que des plages IP codées en dur. Microsoft maintient le service tag à mesure que l’espace IP évolue. Pour plus d’informations, consultez la vue d’ensemble des balises de service Azure.

  • Privilégiez le réseau global Microsoft pour le routage entrant : Configurez la préférence de routage réseau du compte de stockage par rapport au routage réseau Microsoft afin que le trafic entrant entre dans le réseau Microsoft au point de présence le plus proche du client et reste de bout en bout sur le réseau Microsoft. Le routage Internet quitte le réseau Microsoft plus tôt et accroît l’exposition au trafic transitant par l’Internet public. Pour plus d’informations, consultez Configurer une préférence de routage réseau pour le service Stockage Azure.

Gestion de l’identité et de l’accès

Les comptes de stockage prennent en charge deux modèles d’autorisation : Microsoft Entra ID (basé sur l’identité, auditable, révocable) et Shared Key (un secret symétrique avec accès complet au compte). Transférez les charges de travail vers Microsoft Entra ID autant que possible et traitez la clé partagée comme un plan de secours hérité.

  • Utilisez Microsoft Entra ID pour autoriser l’accès aux données : l’autorisation Microsoft Entra ID utilise des jetons OAuth 2.0 et s’intègre avec l’accès conditionnel, les identités gérées et les traces d’audit RBAC. Il est supérieur à tous égards à Shared Key pour l’accès au plan de données. Pour plus d’informations, consultez Autoriser l’accès aux données dans stockage Azure.

  • Désactiver l’autorisation par clé partagée : définissez la propriété allowSharedKeyAccess sur false afin que le compte rejette toute demande signée avec les clés du compte. Seules les requêtes Microsoft Entra ID et, le cas échéant, les requêtes SAS de délégation utilisateur sont acceptées. Pour plus d’informations, consultez Empêcher l'autorisation par clé partagée pour un compte de stockage Azure.

  • Attribuer des rôles RBAC dans la portée la plus courte et raisonnable possible : Attribuer les rôles intégrés du plan de données de stockage (par exemple, lecteur de données de blocs de stockage, contributeur de données de file d’attente de stockage) au niveau du conteneur, du partage, de la file d’attente ou de la table lorsque possible, plutôt qu’au niveau du compte ou de l’abonnement. Pour plus d’informations, voir Autoriser l’accès aux blobs en utilisant le contrôle d’accès basé sur les rôles Azure.

  • Utilisez un SAS de délégation d’utilisateur au lieu d’un SAS de service ou de compte lorsqu’un SAS est nécessaire : un SAS de délégation d’utilisateur est signé à l’aide d’informations d’identification Microsoft Entra plutôt qu’avec la clé du compte, de sorte que la révocation de la clé de délégation d’utilisateur invalide immédiatement tous les SAS émis à partir de cette clé. Les jetons SAS de service et de compte signés avec des clés de compte ne peuvent pas être révoqués individuellement. Pour plus d’informations, consultez Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAS).

  • Si vous devez utiliser des clés de compte, protégez-les et faites-les pivoter : stockez les clés de compte dans Azure Key Vault, récupérez-les à l’exécution plutôt que de les intégrer dans la configuration, puis faites-les pivoter selon une cadence définie. Ayez une procédure de rotation documentée qui évite les interruptions en utilisant les deux touches lors du rollover. Pour plus d’informations, consultez Gérer les clés d’accès au compte de stockage.

  • Attribuez des rôles de stockage privilégiés juste à temps avec Microsoft Entra Privileged Identity Management (PIM) : pour les rôles qui accordent des modifications dans le plan de gestion du stockage (tels que Storage Account Contributor ou Owner), exigez une activation via PIM avec approbation et authentification multifacteur plutôt que des attributions permanentes. Pour plus d’informations, consultez Qu’est-ce que Microsoft Entra Privileged Identity Management ?.

Protection de données

stockage Azure chiffre toutes les données au repos par défaut avec des clés gérées par Microsoft. Les recommandations de cette section ajoutent le contrôle client, protègent contre les modifications accidentelles ou malveillantes, et réduisent l’exposition des données en transit et au repos.

  • Configurez les clés gérées par le client (CMK) pour le chiffrement au repos : utilisez une clé que vous gérez dans Azure Key Vault ou Managed HSM comme clé de chiffrement du compte. CMK vous permet de faire tourner, auditer et révoquer la clé de chiffrement indépendamment des clés gérées par Microsoft. Il soutient les exigences de conformité qui imposent le contrôle des clés du client. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement Stockage Azure.

  • Activez le chiffrement de l’infrastructure pour un double chiffrement en profondeur : le chiffrement d’infrastructure applique une seconde couche de chiffrement géré par service au-dessus de la couche principale de chiffrement. Vous devez l’activer lors de la création du compte. Pour plus d’informations, voir Activer le chiffrement de l’infrastructure pour le double chiffrement des données.

  • Utilisez des oscillations de chiffrement pour isoler le chiffrement pour des conteneurs ou des blobs spécifiques : les oscillations de chiffrement permettent d’appliquer différentes clés ou politiques de rotation de clés au niveau du conteneur ou du blob, au sein d’un seul compte. Cette fonctionnalité est utile pour les charges de travail multi-locataires qui partagent un compte mais nécessitent un contrôle de clé par locataire. Pour plus d’informations, voir Encryption scopes for Stockage Blob.

  • Activez le chiffrement stockage Azure pour toutes les données en transit : combinez Secure transfer required = enabled (voir sécurité réseau) avec une version TLS minimale 1.2 ou ultérieure. Ensemble, ils s’assurent que le compte rejette à la fois les connexions non chiffrées et faiblement chiffrées.

  • Utilisez le chiffrement côté client pour les données les plus sensibles : pour les données dont le texte en clair ne doit jamais apparaître sur le serveur, chiffrez le client avant le téléchargement. Le chiffrement côté client est complémentaire au chiffrement côté service et peut être utilisé conjointement avec CMK pour une protection en couches. Pour la prise en charge du SDK propre à chaque service et les modèles correspondants, voir les articles de sécurité associés.

  • Protégez le compte de stockage avec un verrouillage de ressource : Appliquer un verrouillage CanNotDelete ou ReadOnly pour éviter la suppression ou la reconfiguration accidentelle ou malveillante du compte lui-même. Les blocages s’appliquent à la ressource du compte, pas aux données qu’elle contient, donc ils complètent – et non remplacent – la suppression douce et l’immuabilité. Pour plus d’informations, consultez Appliquer un verrou Azure Resource Manager sur un compte de stockage.

Pour les fonctionnalités de protection des données spécifiques aux services de données (immutabilité des blobs et politiques WORM, périmètres de chiffrement des blobs), voir le sous-article correspondant dans Articles de sécurité connexes.

Enregistrement et surveillance

Les comptes de stockage sont souvent victimes de vol d’identifiants, de tentatives d’exfiltration et de mauvaise configuration. Vous avez besoin d’une journalisation continue et d’une détection de menaces pour détecter et réagir rapidement aux attaques.

  • Activez Microsoft Defender pour le stockage : Defender pour le stockage permet la détection des menaces, le scan des malwares lors de l’upload pour détecter des blobs, ainsi que la découverte de données sensibles. Il signale des schémas d’accès anormaux, des adresses IP malveillantes connues et des sorties Tor malveillantes, ainsi que des activités d’authentification inhabituelles. Activez-le au niveau de l’abonnement ou du compte de stockage. Pour plus d’informations, consultez la section Aperçu de Microsoft Defender for Storage.

    • Activez le balayage de malwares pour les téléchargements de blobs sur les comptes acceptant du contenu non fiable : Le balayage antimalware inspecte les blobs téléchargés et marque ou supprime le contenu malveillant avant qu’il ne puisse être servi aux consommateurs en aval. Pour plus d’informations, voir Analyse de logiciels malveillants dans Defender pour le stockage.

    • Activez la détection des menaces des données sensibles : La découverte de données sensibles classe les données du compte et priorise les alertes sur les conteneurs contenant des informations sensibles. Pour plus d’informations, voir Découverte de données sensibles dans Defender for Storage.

  • Envoyer les paramètres de diagnostic à un espace de travail Log Analytics : Configurez les paramètres de diagnostic sur le compte et chaque service de données (blobs, fichiers, files d’attente, tables) pour envoyer StorageRead, StorageWrite, , et StorageDelete les logs ainsi que toutes les métriques vers Log Analytics. Conservez les journaux pour la période requise par vos obligations de conformité. Pour plus d’informations, consultez Superviser le stockage Azure.

  • Auditez la manière dont chaque requête est autorisée : Les journaux de stockage indiquent si chaque requête a été autorisée avec Microsoft Entra ID, Clé partagée, SAS ou de manière anonyme. Interrogez régulièrement les journaux pour détecter des méthodes d’autorisation inattendues, notamment l’utilisation de la clé partagée après l’avoir désactivée ou l’accès anonyme après l’avoir désactivée. Pour plus d’informations, voir Surveiller les requêtes contre stockage Azure.

  • Alerte lors d’événements de sécurité à haute visibilité : Configurez les alertes Azure Monitor pour des événements tels que la régénération de clés, les modifications des règles du pare-feu, les modifications de l’accès public au réseau, l’utilisation de clés partagées sur les comptes où elles devraient être désactivées, et les alertes Defender for Storage. Pour plus d’informations, consultez Alertes de journal dans Azure Monitor.

  • Transférez les journaux vers un SIEM central : Pour une réponse à l’échelle de l’entreprise, transférez les journaux de stockage de Log Analytics vers Microsoft Sentinel ou un autre SIEM afin que les événements de stockage corréléent avec l’identité, le réseau et les signaux de terminaison. Pour plus d’informations, voir Connect stockage Azure à Microsoft Sentinel.

Gouvernance et conformité

Les contrôles de gouvernance font des configurations sécurisées par défaut et détectent automatiquement les dérives. Pour tout patrimoine de stockage plus grand que quelques comptes, l’application basée sur les politiques est la seule manière durable de maintenir la base cohérente.

  • Appliquer Azure Policy pour faire respecter la sécurité de base du stockage : Assignez des politiques intégrées qui bloquent les configurations non sécurisées au moment du déploiement et auditez les comptes existants. Les éléments intégrés de grande valeur incluent : exiger un transfert sécurisé, exiger un TLS 1.2 minimum, refuser l’accès au réseau public, refuser l’accès au blob public, exiger le chiffrement de l’infrastructure et exiger la CMK. Pour une liste complète, voir les définitions intégrées d’Azure Policy pour stockage Azure et Azure Policy Regulatory Compliance controls pour stockage Azure.

  • Utilisez le benchmark de sécurité cloud Microsoft (MCSB) comme référence : alignez les contrôles de stockage avec les domaines MCSB v2 pour une posture de sécurité cohérente entre les services. Pour plus d’informations, consultez la section Aperçu du benchmark de sécurité cloud Microsoft.

  • Comptes de stockage des étiquettes avec propriétaire, classification des données et environnement : les politiques de gouvernance, la gestion des coûts et la réponse aux incidents dépendent toutes d’un étiquetage cohérent. Appliquez les tags via Azure Policy pour qu'ils ne puissent pas être omis au moment de la création.

  • Examinez les offres de conformité avant de stocker des données réglementées : stockage Azure détient des certifications pour des cadres réglementaires courants (HIPAA, PCI DSS, FedRAMP, ISO 27001, et d’autres). Confirmez la couverture de votre charge de travail avant le déploiement. Pour plus d’informations, consultez les offres de conformité stockage Azure.

Sauvegarde et récupération

La redondance inter-régions combinée aux procédures de basculement validées assure la résilience régionale du compte de stockage lui-même. Pour la protection contre la suppression propre aux services de données (suppression réversible des blobs, gestion des versions des blobs, flux de modifications, limite de restauration dans le temps, suppression réversible des partages de fichiers et instantanés), consultez le sous-article correspondant dans Articles connexes sur la sécurité.

  • Choisissez une option de redondance appropriée pour vos exigences de récupération : le stockage géoredondant (GRS/RA-GRS/GZRS/RA-GZRS) réplique les données vers une région jumelée et prend en charge le basculement initié par le client pour assurer la résilience régionale. Le stockage redondant interzone (ZRS/GZRS) protège contre les défaillances au niveau de la zone au sein d’une région. Pour plus d’informations, consultez redondance de stockage Azure.

  • Ne comptez pas sur la géo-redondance pour la protection contre les ransomwares : la réplication géo-redondante reflète les données – ainsi que toute corruption ou suppression malveillante – dans la région associée. Associez GRS à des politiques d’immuabilité, à la suppression réversible et au versionnement afin de renforcer la résistance aux ransomwares et aux falsifications. Pour plus d’informations, consultez Fonctionnalités de protection des données dans stockage Azure.

  • Entraînez-vous au basculement et au basculement de retour initiés par le client : pour les comptes avec RA-GRS ou RA-GZRS, effectuez un exercice de basculement planifié afin de valider votre procédure de récupération avant d’en avoir besoin. Pour plus d’informations, consultez Récupération d’urgence et basculement de compte de stockage.

Pour des conseils de sécurité spécifiques à chaque service de données stockage Azure, voir :

Étapes suivantes

  • Dernière mise à jour :