Pourquoi le stockage Azure Blob doit être sauvegardé : 5 risques que vous ne pouvez ignorer

Le stockage d'objets a évolué. Il n'est plus seulement une destination pour les fichiers archivés, il sert désormais de stockage principal pour les données critiques dans les pipelines d'IA, l'analytique et les apps cloud-natives. Avec cette évolution, les enjeux de protection de ces données n'ont jamais été aussi importants.

Azure Blob Storage est l'une des principales plateformes de stockage d'objets dans le cloud sur le marché à ce jour, utilisée par des milliers d'organisations dans le monde entier. Les équipes l'utilisent pour stocker des charges de travail de calcul haute performance (HPC), des journaux et des traces provenant de services cloud-natifs, des sorties ETL et de transformation de données, des ensembles d'entraînement AI et ML, et des ensembles de données analytiques.

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

Azure Blob Storage offre une durabilité intégrée et des garanties opérationnelles telles que la redondance, les suppressions en douceur et le versionnage. Ces fonctionnalités permettent de lutter contre les risques de défaillance matérielle et de réduire les erreurs quotidiennes.

Ce qu'elles n'offrent pas, c'est une véritable résilience lorsque le plan de contrôle lui-même est affecté, par exemple, par des identifiants compromis, une automatisation trop permissive, des politiques mal appliquées ou une erreur d'opérateur à grande échelle. Étant donné que bon nombre de ces fonctionnalités reflètent l'état actuel par conception, elles peuvent reproduire un mauvais état, tel que des suppressions, des corruptions ou des changements de politique, tout aussi rapidement qu'un état propre. Cela signifie que même si les fonctions natives sont activées, vos données restent vulnérables à une série de risques réels, dont certains sont faciles à ignorer jusqu'à ce qu'il soit trop tard.

Cinq risques que vous ne pouvez pas ignorer pour Azure Blob Storage

Incidents de sécurité

Azure Blob Storage contient de grandes quantités de données de grande valeur, souvent à l'échelle du pétaoctet. L'accès programmatique bien documenté à ces données est un rêve pour les pirates. Un ransomware ciblé peut chiffrer ou corrompre des téraoctets de données, tandis que des informations d'identification compromises ou une mauvaise utilisation par un initié peuvent déclencher des suppressions, des rotations de clés et des changements de politique. La compromission au niveau du locataire peut également modifier les politiques de cycle de vie ou d'immuabilité.

Incident documenté:L'équipe de renseignement sur les menaces de Microsoft a signalé une campagne dans laquelle un acteur de la menace connu sous le nom de Storm-0501 a utilisé des informations d'identification volées pour compromettre les 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 et a ensuite chiffré les données à l'aide de clés stockées dans un coffre-fort de clés nouvellement créé. Après avoir chiffré des centaines de téraoctets de données, il a supprimé la clé de chiffrement et des notes de rançon ont été envoyées par l'intermédiaire de Microsoft Teams.[^1]

Cet incident illustre la façon dont des informations d'identification compromises et une mauvaise utilisation de l'accès programmatique peuvent permettre aux attaquants de chiffrer ou de supprimer des ensembles de données massifs et de manipuler les politiques de cycle de vie ou d'immuabilité.

Mauvaises configurations administratives

Les mauvaises configurations des clients sont une source courante de perturbation et de perte de données dans Azure Blob Storage. Étant donné que les personnes configurent les politiques d'accès, les règles de cycle de vie, les retenues 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. Les suppressions ou é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 faire expirer des données trop tôt ou les déplacer vers des niveaux froids qui perturbent l'analyse. Une version désactivée, une suppression douce ou une rotation incorrecte des clés peuvent é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 a découvert 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. L'assistance Microsoft a expliqué que si un compte de stockage est supprimé puis recréé sous le même nom, la restauration échoue. [^2]

Le problème sous-jacent était que l'utilisateur n'avait pas activé la suppression progressive, le versionnage ou les verrous de ressources, qui auraient pu empêcher ou atténuer la suppression accidentelle. L'absence d'une telle protection et la recréation du compte ont effectivement détruit les options de récupération. 

Conformité et application de la gouvernance

La surveillance réglementaire croissante entraîne une immuabilité et une conservation plus strictes. Bien que bien intentionnés, ces contrôles peuvent retarder les corrections, fragmenter les ensembles de données et perturber les flux de travail. Les politiques WORM (write once, read many), par exemple, peuvent bloquer la remédiation d'urgence en empêchant les suppressions ou les modifications, ce qui retarde le confinement et consomme un espace de stockage inutile. Des paramètres de résidence mal configurés peuvent bloquer la réplication transfrontalière, ce qui compromet les objectifs de reprise.

Incident documenté : Un utilisateur d'Azure Blob Storage a créé un compte de stockage dans un environnement de test et lorsqu'il a terminé ce qu'il avait à faire, la suppression de l'environnement n'a pas été possible. C'était à cause des politiques d'immuabilité, et la seule solution était de changer la politique de chaque blob individuellement. L'utilisateur mentionne que, bien que les politiques d'immuabilité soient excellentes pour assurer la conformité en production, il n'y a pas de moyen de jouer avec elles et de les comprendre de manière éphémère ou dans un environnement de test. [^3]

Défaillances opérationnelles et de plateforme

Dans Azure Blob Storage, de petites défaillances peuvent provoquer des interruptions et, parfois, des pertes de données induites par l'opérateur. Étant donné que de nombreuses applications et pipelines interagissent avec le stockage Blob 24 heures sur 24, la surface de défaillance est importante. Les téléchargements ou les validations qui échouent, les erreurs d'ETL et de pipeline, les inadéquations de version du SDK ou du client, les contrôles d'intégrité manquants, les tentatives non sécurisées qui écrasent les bonnes données et les défauts d'outillage dans l'environnement du locataire peuvent tous conduire à une corruption ou à une indisponibilité temporaire.

Incident documenté : Une panne du système de refroidissement du centre de données d'Azure dans le centre-sud des États-Unis a entraîné des arrêts généralisés du matériel afin de prévenir les dommages. L'incident a entraîné des pannes en cascade qui ont affecté non seulement les charges de travail primaires, mais aussi les mécanismes de sauvegarde et de reprise après sinistre stockés dans le Blob Storage. Les organisations ont été confrontées à des interruptions de service généralisées et à des problèmes dans les flux de travail dépendant du stockage au cours de la reprise, ce qui montre à quel point les dépendances entre services peuvent limiter les options de basculement pratiques, même avec la géo-redondance. [^4] [^5]

Cet incident a mis en lumière l'importance des sauvegardes interrégionales et inter-cloud, et de la portabilité multi-cloud des sauvegardes. 

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

Toute entreprise est exposée au risque de la chaîne d'approvisionnement, et les fournisseurs de cloud n'en sont pas exempts. Les problèmes liés à la chaîne d'approvisionnement des fournisseurs d'Azure peuvent se propager et perturber de nombreuses entreprises. Au-delà des problèmes liés à la chaîne d'approvisionnement des logiciels, les problèmes provenant des fournisseurs, tels que les bogues de service, les changements opérationnels erronés, les mauvaises configurations IAM ou la mauvaise manipulation des clés de chiffrement, peuvent se propager aux clients et entraîner des pertes de données ou des interruptions, même lorsque les configurations des locataires sont correctes.

Incident documenté: Storm-0558, un acteur de menace basé en Chine, a obtenu une clé de signature de consommateur de compte Microsoft (MSA) et des jetons d'authentification falsifiés. À partir du 15 mai 2023, ils ont 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 qui utilisent la fonction "Login with Microsoft", ce qui indique un impact potentiel au-delà de la messagerie électronique. [

Une sauvegarde immuable et gouvernée séparément garantit la résilience et la capacité de récupération

S'il existe une solution qui pourrait garantir la résilience opérationnelle dans toutes les situations susmentionnées, c'est bien une sauvegarde immuable, gouvernée de manière logique, avec des politiques indépendantes et une récupération à un moment donné.

Avec une sauvegarde inviolable, stockée séparément (dans une autre région) dans Azure Blob Storage ou, mieux encore, dans une autre plateforme en nuage comme Amazon S3 ou Google Cloud Storage, vous pouvez vous placer en position de force pour récupérer les perturbations et les pertes de données causées par l'une ou l'autre des situations ci-dessus.

C'est exactement là que HYCU vous aide. Notre solution commune avec Dell fournit des sauvegardes rentables et à l'épreuve des ransomwares pour Azure Blob Storage, afin que vous puissiez récupérer en toute confiance, même dans les pires scénarios.

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

Consultez le site www.hycu.com pour découvrir comment HYCU + Dell offre une sauvegarde rentable et résiliente pour Azure Blob Storage.

_________________________________________________________________________________

References:

1. Microsoft Threat Intelligence. (2025, 27 août). Storm-0501's evolving techniques lead to cloud-based ransomware (Les techniques évolutives de Storm-0501 conduisent à un ransomware basé sur le cloud). Microsoft Security Blog.
2. Nguyen, T. (2025, August 20). [URGENT] Suppression accidentelle du compte Azure Data Lake Storage Gen2 - Les données peuvent-elles être restaurées ? Microsoft Q&A.
3. Lapointe, S. (2023, 8 décembre). Comment supprimer un compte de stockage Azure avec une politique d'immutabilité déverrouillée. Code is a Highway.
4. Moss, S. (2018, September 4). Microsoft Azure subit une panne après un problème de refroidissement. DataCenterDynamics.
5. Azure DevOps SRE Team. (2018, 10 septembre). Postmortem - panne de VSTS - 4 septembre 2018. Microsoft DevBlogs.
6. Tamari, S. (2023, July 21). Clé Microsoft compromise : Un impact plus important qu'on ne le pensait. Wiz Blog.