Pourquoi il est indispensable de sauvegarder Azure Blob Storage : 5 risques à ne pas négliger

Azure Blob Storage est l'une des principales plateformes de stockage objet dans le cloud actuellement disponibles sur le marché, utilisée par des milliers d'organisations à travers le monde. Les équipes l’utilisent pour stocker des charges de travail de calcul haute performance (HPC), des journaux et des traces provenant de services natifs du cloud, les résultats d’opérations ETL et de transformation des données, des ensembles de données d’entraînement pour l’IA et l’apprentissage automatique, ainsi que des ensembles de données analytiques.

Pourquoi les fonctionnalités natives ne garantissent-elles pas une protection complète des données ?

Azure Blob Storage offre une durabilité intégrée et des mesures de sécurité opérationnelles telles que la redondance, les suppressions temporaires et la gestion des versions. Ces fonctionnalités contribuent à lutter contre les risques de défaillance matérielle et à réduire les erreurs courantes.

Ce qu’elles n’apportent pas, c’est une véritable résilience lorsque le plan de contrôle lui-même est affecté, par exemple en cas d’identifiants compromis, d’automatisation trop permissive, de politiques mal appliquées ou d’erreur humaine à grande échelle. Comme bon nombre de ces fonctionnalités reflètent par conception l’état actuel, elles peuvent reproduire un état défectueux, tel que des suppressions, des corruptions ou des modifications de politique, aussi rapidement qu’un état correct. Cela signifie que même lorsque les fonctionnalités natives sont activées, vos données restent vulnérables à toute une série de risques concrets, dont certains sont faciles à négliger jusqu’à ce qu’il soit trop tard. 

Cinq risques à ne pas négliger concernant Azure Blob Storage

Incidents de sécurité

Azure Blob Storage héberge d’énormes quantités de données de grande valeur, souvent à l’échelle du pétaoctet. Un accès programmatique bien documenté à ces données est le rêve de tout pirate informatique. Un rançongiciel ciblé peut chiffrer ou corrompre des téraoctets de données, tandis que des identifiants compromis ou une utilisation abusive par un initié peuvent déclencher des suppressions, des rotations de clés et des modifications de politique. Une compromission au niveau du locataire peut également modifier les politiques de cycle de vie ou d’immuabilité.

Incident documenté : L’équipe de veille sur les menaces de Microsoft a signalé une campagne au cours de laquelle un acteur malveillant connu sous le nom de Storm‑0501 a utilisé des identifiants volés pour compromettre des locataires Azure. L’attaquant a supprimé les verrous de récupération et les politiques d’immuabilité, a créé une nouvelle portée de chiffrement pour Azure Blob Storage, puis a chiffré les données à l’aide de clés stockées dans un Key Vault nouvellement créé. Après avoir chiffré des centaines de téraoctets de données, il a supprimé la clé de chiffrement et des demandes de rançon ont été envoyées via Microsoft Teams. [^1]

Cet incident illustre comment des identifiants compromis et l’utilisation abusive de l’accès programmatique peuvent permettre à des attaquants de chiffrer ou de supprimer d’énormes ensembles de données et de manipuler les politiques de cycle de vie ou d’immuabilité.

Erreurs de configuration administrative

Les erreurs de configuration commises par les clients constituent une source courante de perturbations et de perte de données dans Azure Blob Storage. Étant donné que ce sont des personnes qui configurent les politiques d’accès, les règles de cycle de vie, les conservations légales, les paramètres de pare-feu et de réseau, ainsi que la hiérarchisation, il existe un risque permanent d’erreur humaine. Des suppressions ou des écrasements accidentels peuvent supprimer des préfixes critiques ou remplacer des objets de manière inattendue. Des politiques de cycle de vie mal configurées peuvent entraîner l’expiration prématurée des données ou leur déplacement vers des niveaux de stockage « froids », ce qui perturbe les analyses. La désactivation du versionnage ou de la suppression temporaire, ou encore une rotation incorrecte des clés, peut également rendre les données inaccessibles ou irrécupérables. 

Incident documenté : Un utilisateur a supprimé un groupe de ressources contenant un compte Azure Data Lake Storage, puis a recréé un compte de stockage portant le même nom. Il s’est alors rendu compte qu’il ne pouvait pas restaurer les données supprimées, bien qu’Azure offre une fenêtre de récupération de 14 jours pour les comptes de stockage. Le support technique de Microsoft a expliqué que si un compte de stockage est supprimé puis recréé avec le même nom, la récupération échoue. [^2]

Le problème sous-jacent était que l’utilisateur n’avait pas activé la suppression temporaire, la gestion des versions ni les verrous de ressources, ce qui aurait pu empêcher ou atténuer la suppression accidentelle. L’absence de telles protections et la recréation du compte ont de fait anéanti toute possibilité de récupération. 

Conformité et application de la gouvernance

Le renforcement de la surveillance réglementaire impose des exigences plus strictes en matière d’immuabilité et de conservation. Bien qu’elles partent d’une bonne intention, ces mesures de contrôle peuvent retarder les corrections, fragmenter les ensembles de données et perturber les flux de travail. Les politiques WORM (écriture unique, lectures multiples), par exemple, peuvent bloquer les mesures correctives d’urgence en empêchant les suppressions ou les modifications, ce qui retarde à son tour le confinement et consomme inutilement de l’espace de stockage. Des paramètres de résidence mal configurés peuvent bloquer la réplication transfrontalière, compromettant ainsi les objectifs de restauration.

Incident documenté : Un utilisateur d’Azure Blob Storage a créé un compte de stockage dans un environnement de test et, une fois ses opérations terminées, il s’est avéré impossible de supprimer cet environnement. Cela était dû aux politiques d’immuabilité, et la seule solution consistait à modifier individuellement la politique de chaque blob. L’utilisateur mentionne que, bien que les politiques d’immuabilité soient excellentes pour garantir la conformité en production, il n’existe aucun moyen de les tester et de les comprendre dans un environnement éphémère ou de test. [^3]

Défaillances opérationnelles et de la plateforme

Dans Azure Blob Storage, de petites défaillances peuvent entraîner des perturbations et, parfois, une perte de données due à une erreur de l’opérateur. Étant donné que de nombreuses applications et pipelines interagissent avec Blob Storage 24 heures sur 24, la surface d’exposition aux défaillances est importante. Les échecs de téléchargement ou de validation, les erreurs ETL et de pipeline, les incompatibilités de version entre le SDK et le client, l’absence de contrôles d’intégrité, les nouvelles tentatives non sécurisées qui écrasent des données valides, ainsi que les défauts des outils dans l’environnement du locataire peuvent tous entraîner une corruption des données ou une indisponibilité temporaire. 

Incident documenté : Une défaillance du système de refroidissement dans le centre de données Azure « South Central US » a entraîné des arrêts généralisés du matériel afin d’éviter tout dommage. Cet incident a provoqué des défaillances en cascade affectant non seulement les charges de travail principales, mais également les mécanismes de sauvegarde et de reprise après sinistre stockés dans Blob Storage. Les organisations ont subi des perturbations généralisées des services et rencontré des problèmes dans les flux de travail dépendants du stockage pendant la reprise, ce qui a mis en évidence la manière dont les dépendances entre services peuvent limiter les options pratiques de basculement, même en présence de redondance géographique. [^4] [^5]

Cet incident a mis en lumière l’importance des sauvegardes interrégionales et inter-cloud, ainsi que la nécessité de garantir la portabilité multi-cloud des sauvegardes. 

Compromission de la chaîne d’approvisionnement par le fournisseur de cloud

Toute entreprise est exposée aux risques liés à la chaîne d’approvisionnement, et les fournisseurs de cloud ne font pas exception. Les problèmes de chaîne d’approvisionnement provenant des fournisseurs d’Azure peuvent se répercuter et entraîner des perturbations pour de nombreuses entreprises. Au-delà des problèmes liés à la chaîne d’approvisionnement logicielle, les problèmes provenant des fournisseurs, tels que les bogues de service, les modifications opérationnelles défaillantes, les erreurs de configuration de l’IAM ou la mauvaise gestion des clés de chiffrement, peuvent se répercuter sur les clients et entraîner une perte de données ou des perturbations, même lorsque les configurations des locataires sont correctes. 

Incident documenté : Storm-0558, un acteur malveillant basé en Chine, s’est procuré une clé de signature de compte Microsoft (MSA) destinée aux particuliers et a falsifié des jetons d’authentification. À partir du 15 mai 2023, il a accédé aux données de messagerie d’environ 25 organisations en exploitant une erreur de validation qui permettait aux clés MSA de signer des jetons Azure AD. Des recherches ultérieures ont montré que la clé compromise aurait pu être acceptée par d’autres applications utilisant la fonctionnalité « Se connecter avec Microsoft », ce qui indique un impact potentiel allant au-delà de la messagerie. [^6]

Une sauvegarde immuable, distincte et régie par des règles spécifiques garantit la résilience et la récupérabilité

S’il existe une solution susceptible d’assurer la résilience opérationnelle dans toutes les situations susmentionnées, c’est bien une sauvegarde immuable, logiquement isolée (air-gapped), dotée de politiques indépendantes et permettant une restauration à un instant donné. 

Par « isolée logiquement », nous entendons des sauvegardes gérées selon des identifiants et des rôles distincts, et protégées par l’immuabilité ou une conservation limitée dans le temps, de sorte que les modifications apportées au tenant de production ne puissent ni modifier ni supprimer les copies de sauvegarde. Si l’accès ou la configuration de l’environnement de production est altéré, ces copies restent intactes, et vous disposez d’un chemin de restauration propre et dont la fiabilité est garantie, à grande échelle. 

Grâce à une sauvegarde inviolable, stockée séparément (dans une autre région) au sein d’Azure Blob Storage, ou mieux encore, sur une autre plateforme cloud telle qu’Amazon S3 ou Google Cloud Storage, vous vous placez en position de force pour vous remettre des perturbations et des pertes de données causées par l’une des situations susmentionnées.  

C’est précisément là qu’HYCU intervient. Notre solution conjointe avec Dell offre des sauvegardes économiques et à l’épreuve des ransomwares pour Azure Blob Storage, afin que vous puissiez effectuer une restauration en toute confiance, même dans les pires scénarios.

Facile à déployer et à gérer. Immuable de par sa conception.

Consultez www.hycu.com pour découvrir comment HYCU + Dell offre une solution de sauvegarde économique et résiliente pour Azure Blob Storage. 

_________________________________________________________________________________

Références :

1. Microsoft Threat Intelligence. (27 août 2025). L’évolution des techniques de Storm-0501 conduit à l’apparition de rançongiciels basés sur le cloud. Blog Microsoft Security.
2. Nguyen, T. (20 août 2025). [URGENT] Suppression accidentelle d’un compte Azure Data Lake Storage Gen2 – Les données peuvent-elles être restaurées ? Microsoft Q&A.
3. Lapointe, S. (8 décembre 2023). Comment supprimer un compte de stockage Azure dont la politique d’immuabilité est déverrouillée. Code is a Highway.
4. Moss, S. (4 septembre 2018). Microsoft Azure subit une panne suite à un problème de refroidissement. DataCenterDynamics.
5. Tamari, S. (21 juillet 2023). Clé Microsoft compromise : des répercussions plus importantes que prévu. Wiz Blog.