Sécurisez votre stockage Blob Azure

Stockage Blob Azure stocke d’énormes quantités de données d’objets non structurées dans des conteneurs. Il est souvent la cible d’exfiltrations, de ransomwares et d’incidents d’exposition publique. Cet article fournit des recommandations de sécurité spécifiques aux conteneurs d’objets blob, aux objets blob et aux espaces de noms hiérarchiques d’Azure Data Lake Storage.

Note

Cet article traite des pratiques de sécurité spécifiques à Stockage Blob Azure. Pour des conseils de sécurité au niveau du compte, consultez Sécuriser votre compte stockage Azure.

Sécurité du réseau

  • Domaines personnalisés frontaux, sites web statiques et tout contenu d’objet blob servi publiquement avec Azure Front Door : terminez TLS au niveau d’Azure Front Door avec un certificat géré, activez le WAF et restreignez l’accès au réseau public du compte de stockage afin que seul Front Door puisse accéder à l’origine. La fonctionnalité de domaine personnalisé d’stockage Azure ne prend pas en charge les certificats TLS gérés, et Front Door ajoute une protection WAF, la limitation du débit et la journalisation, dont l’accès anonyme aux conteneurs ne dispose pas. Pour plus d’informations, voir Use Azure Front Door with stockage Azure blobs.

  • Désactivez le point de terminaison statique du site web lorsqu’il n’est pas utilisé : Le $web conteneur reste lisible au public tant que la fonction du site statique est activée, même si allowBlobPublicAccess est false. Désactivez la fonction de site statique sur les comptes qui n’en ont pas besoin. Pour plus d’informations, consultez hébergement de site web statique dans stockage Azure.

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

Accès public anonyme

SAS et ABAC au niveau du blob

  • Privilégiez un SAS de délégation d’utilisateur plutôt qu’un SAS de service pour l’accès aux objets blob : une signature d’accès partagé (SAS) de délégation d’utilisateur est signée à l’aide d’informations d’identification Microsoft Entra. La révocation de la clé de délégation utilisateur invalide immédiatement tous les jetons SAS émis à partir de celle-ci, offrant ainsi un mécanisme de révocation dont les SAS de service et les SAS de compte ne disposent pas. Pour en savoir plus, consultez Créer une SAS de délégation d’utilisateur.

  • Limiter la portée du SAS de service à l’aide de stratégies d’accès stockées afin de permettre la révocation : si vous devez utiliser un SAS de service, associez-le à une stratégie d’accès stockée pour le conteneur. Vous pouvez alors modifier ou supprimer la politique pour révoquer tous les SAS qui y font référence. En l’absence de stratégie, un SAS de service ne peut être révoqué qu’en régénérant les clés de compte, ce qui affecte tous les autres SAS associés au compte. Pour plus d’informations, consultez Mise en place d’une stratégie d’accès stockée.

  • Utilisez des tags d’index blob pour conditionner l’accès via ABAC : Combinez les tags d’index blob avec des conditions de contrôle d’accès basé sur attributs (ABAC) pour accorder un accès en lecture uniquement aux blobs avec des valeurs spécifiques de tag - par exemple, Classification=Public. Cette approche permet à une seule attribution de rôle de servir de nombreux appelants sans accorder l’accès à des données sensibles taguées. Pour plus d’informations, voir Autoriser l’accès aux blobs en utilisant les conditions ABAC.

Protection de données

  • Utilisez des champs de chiffrement blob pour isoler le chiffrement pour des conteneurs ou blobs spécifiques : les champs 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.

  • Utilisez le chiffrement côté client pour les données de blob qui ne doivent jamais apparaître sur le serveur en texte clair : chiffrer le contenu blob du client avant le téléchargement. Le SDK s’intègre avec Azure Key Vault ou Managed HSM pour la gestion des clés. Combinez avec le CMK côté service pour une protection en couches. Pour plus d’informations, voir Chiffrement côté client pour les blobs.

Immutabilité et WORM

  • Configurez les politiques de rétention temporelle pour les données régulées : Appliquer une conservation temporelle au niveau du conteneur ou de la version afin d’éviter la modification ou la suppression des blobs pendant une période fixe. L’immutabilité au niveau des versions offre un contrôle plus fin et vous pouvez l’activer ou l’étendre sur des versions individuelles. Pour plus d’informations, consultez Stocker des données blob critiques pour l’entreprise avec un stockage immuable.

  • Utilisez des blocages juridiques pour une conservation indéfinie motivée par des besoins juridiques ou d’enquête : les blocages juridiques empêchent la suppression tant qu’un utilisateur autorisé n’a pas explicitement levé le blocage, sans durée fixe. Pour plus d’informations, consultez Stocker des données blob critiques pour l’entreprise avec un stockage immuable.

  • Verrouillez les politiques de rétention pour les rendre non modifiables : Les utilisateurs disposant des permissions appropriées peuvent raccourcir ou supprimer une politique de rétention non déverrouillée. Le verrouillage de la stratégie rend la période de conservation irréversible. Ne verrouillez qu’après avoir validé la durée de validité de la stratégie. Pour plus d’informations, voir Configurer les politiques d’immuabilité pour les conteneurs.

Opérations de réplication et de copie d’objets

  • Restreignez la réplication des objets aux comptes source que vous contrôlez : Configurez la liste source-compte autorisée du compte de destination afin que seuls les comptes source connus et de confiance puissent envoyer les données. Pour plus d’informations, consultez Configurer la réplication d’objets.

  • Empêcher la réplication d’objets entre locataires : Interdire les stratégies de réplication dont les comptes source et destination appartiennent à différents locataires Microsoft Entra. Cette restriction empêche un utilisateur autorisé de configurer la réplication vers un locataire externe. Pour plus d’informations, consultez Empêcher la réplication d’objet entre les locataires Microsoft Entra.

  • Limitez la portée autorisée pour les opérations de copie : configurez le compte pour autoriser les opérations de copie uniquement depuis les comptes sources du même locataire ou du même abonnement. Cette configuration bloque un chemin d’exfiltration courant : la copie d’un compte privé vers un compte contrôlé par l’attaquant. Pour plus d’informations, voir Portée autorisée pour les opérations de copie.

Sauvegarde et récupération

  • Activez la version des blobs pour préserver les versions précédentes lors de l’écriture et de la suppression : Lorsque vous activez la version des versions, chaque opération d’écriture ou de suppression crée une nouvelle version et conserve l’état précédent. Vous pouvez adresser et restaurer les versions. Pour plus d’informations, consultez Contrôle de version des objets blob.

  • Activez la suppression douce pour les blobs et les conteneurs : la suppression douce conserve les blobs et conteneurs supprimés pendant une période de conservation définie, afin de pouvoir les restaurer pendant ce temps. Configurez séparément la suppression logicielle au niveau conteneur et au niveau blob, et activez les deux. Pour plus d’informations, voir Suppression douce pour les blobs et Suppression douce pour les conteneurs.

  • Activer la restauration à un instant dans le passé pour les comptes d’objets blob de blocs : la restauration à un instant dans le passé fonctionne avec le contrôle de version et la suppression réversible pour restaurer une plage d’objets blob de blocs à un horodatage précis antérieur. Cette fonctionnalité est utile pour la récupération en cas de ransomware. La restauration à un instant donné nécessite d’activer la gestion des versions, la suppression réversible des blobs et le flux de modifications. Pour plus d’informations, consultez Restauration à un instant dans le passé pour les blobs de bloc.

  • Activez le flux de modifications pour l’audit et la criminalistique : Le flux de modifications est un journal ordonné et inchangé de chaque modification des blobs du compte. Outre la possibilité de restaurer au moment opportun, il offre un enregistrement d’audit durable pour les enquêtes. Pour plus d’informations, consultez Prise en charge des flux de modification dans Stockage Blob Azure.

Azure Data Lake Storage

Data Lake Storage ajoute un espace de noms hiérarchique et des listes de contrôle d’accès (ACL) de type POSIX à Stockage Blob. Les ACL et le RBAC fonctionnent ensemble : ils permettent d’accorder des droits d’accès généraux via le RBAC et de les affiner dans le système de fichiers à l’aide des ACL.

  • Utilisez RBAC pour un accès grossier et les ACL pour un accès détaillé : attribuez des rôles RBAC intégrés au niveau du conteneur ou du compte afin d’accorder un accès large. Ensuite, utilisez des ACL sur les répertoires et fichiers pour restreindre l’accès dans le conteneur. N’utilisez pas uniquement les ACL pour les autorisations dont un utilisateur a besoin sur tout un conteneur. Le RBAC est plus efficace à évaluer et à auditer. Pour plus d’informations, consultez le modèle de contrôle d’accès dans Azure Data Lake Storage.

  • Appliquer les ACL par défaut sur les répertoires pour hériter des permissions sur les nouveaux éléments enfants : Les ACL par défaut s’appliquent aux fichiers et répertoires créés après avoir défini la LCA. Régle-les au niveau du répertoire pour éviter de gérer les ACL sur des fichiers individuels. Pour plus d’informations, consultez les listes de contrôle d’accès dans Azure Data Lake Storage.

  • Activez l’espace de noms hiérarchique lors de la création du compte : Vous ne pouvez pas activer l’espace de noms hiérarchique sur un compte existant sans migration. Si vous savez qu’une charge de travail utilise la sémantique de Data Lake Storage, activez-la dès le départ plutôt que de la migrer plus tard. Pour plus d’informations, voir Azure Data Lake Storage hierarchical namespace.

Enregistrement et surveillance

  • Alerte sur les accès anonymes après avoir désactivé l’accès anonyme : Lorsque vous définissez allowBlobPublicAccess sur false, filtrez les journaux du stockage pour AuthenticationType == "Anonymous" et déclenchez une alerte en cas de détection. Ces résultats indiquent soit un client mal configuré, soit une tentative de sondage. Pour plus d’informations, consultez Superviser le stockage Azure.

  • Activez et agissez sur les verdicts de balayage des malwares Defender for Storage : Lorsque vous activez l'analyse des malwares, configurez la réponse automatisée (suppression de blobs, balisage de quarantaine ou suppression du flux de travail en aval) sur MalwareScanningResult les verdicts afin que les blobs malveillants identifiés ne puissent pas être diffusés aux consommateurs. Pour plus d’informations, voir Répondre aux résultats de balayage de logiciels malveillants dans Defender for Storage.

  • Suivre les modifications des balises d’index d’objet blob afin de détecter les dérives de classification : Si vous utilisez des balises d’index d’objet blob pour définir des conditions d’accès ABAC, les modifications apportées à ces balises modifient directement les personnes autorisées à lire l’objet blob. Enregistrez et alertez les opérations SetBlobTags contre des conteneurs sensibles. Pour plus d’informations, voir Gérer et trouver les données sur Stockage Blob Azure avec des tags d’index blob.

Étapes suivantes

  • Dernière mise à jour :