Por qué Azure Blob Storage necesita copias de seguridad: 5 riesgos que no puede ignorar

El almacenamiento de objetos ha evolucionado. Ya no es solo un destino para archivos archivados, ahora sirve como almacenamiento primario para datos de misión crítica en canalizaciones de IA, análisis y aplicaciones nativas de la nube. Con este cambio, lo que está en juego para proteger esos datos nunca ha sido tan importante.

Azure Blob Storage es una de las principales plataformas de almacenamiento de objetos en la nube del mercado a día de hoy, utilizada por miles de organizaciones en todo el mundo. Los equipos la utilizan para almacenar cargas de trabajo de computación de alto rendimiento (HPC), registros y trazas de servicios nativos de la nube, salidas de ETL y transformación de datos, conjuntos de entrenamiento de IA y ML y conjuntos de datos de análisis.

Por qué las funciones nativas no garantizan una protección completa de los datos

Azure Blob Storage ofrece durabilidad integrada y salvaguardas operativas como redundancia, borrado suave y control de versiones. Estas características ayudan a combatir los riesgos de fallo del hardware y a reducir los errores cotidianos.

Lo que no proporcionan es una verdadera capacidad de recuperación cuando el propio plano de control se ve afectado, por ejemplo, por credenciales comprometidas, una automatización excesivamente permisiva, políticas mal aplicadas o un error del operador a gran escala. Dado que muchas de estas características reflejan el estado actual por diseño, pueden replicar un mal estado, como borrados, corrupciones o cambios de políticas, tan rápido como uno limpio. Esto significa que incluso con las funciones nativas activadas, sus datos siguen siendo vulnerables a una serie de riesgos del mundo real, algunos de los cuales son fáciles de pasar por alto hasta que es demasiado tarde.

Cinco riesgos que no puede ignorar para Azure Blob Storage

Incidentes de seguridad

Azure Blob Storage alberga grandes cantidades de datos de gran valor, a menudo a escala de petabytes. Un acceso programático bien documentado a dichos datos es el sueño de cualquier hacker. El ransomware dirigido puede cifrar o corromper terabytes de datos, mientras que las credenciales comprometidas o el uso indebido de información privilegiada pueden desencadenar eliminaciones, rotaciones de claves y cambios de políticas. El compromiso a nivel de inquilino también puede alterar el ciclo de vida o las políticas de inmutabilidad.

Incidente documentado: El equipo de inteligencia de amenazas de Microsoft informó de una campaña en la que un actor de amenazas conocido como Storm-0501 utilizó credenciales robadas para comprometer a los inquilinos de Azure. El atacante eliminó los bloqueos de recuperación y las políticas de inmutabilidad, creó un nuevo ámbito de cifrado para Azure Blob Storage y, a continuación, cifró los datos utilizando claves almacenadas en una Bóveda de claves recién creada. Tras cifrar cientos de terabytes de datos, eliminaron la clave de cifrado y se enviaron notas de rescate a través de Microsoft Teams.[^1]

Este incidente ilustra cómo las credenciales comprometidas y el uso indebido del acceso programático pueden permitir a los atacantes cifrar o eliminar conjuntos de datos masivos y manipular las políticas de ciclo de vida o inmutabilidad.

Malas configuraciones administrativas

Las malas configuraciones de los clientes son una fuente común de interrupciones y pérdida de datos en Azure Blob Storage. Dado que las personas configuran las políticas de acceso, las reglas del ciclo de vida, las retenciones legales, los ajustes del cortafuegos y de la red, y la organización en niveles, existe un riesgo continuo derivado de los errores humanos. Los borrados o sobrescrituras accidentales pueden eliminar prefijos críticos o sustituir objetos de forma inesperada. Las políticas de ciclo de vida mal configuradas pueden hacer caducar los datos demasiado pronto o moverlos a niveles fríos que rompen la analítica. Un versionado/borrado suave desactivado o una rotación de claves incorrecta también pueden hacer que los datos sean inaccesibles o irrecuperables.

Incidente documentado: Un usuario eliminó un grupo de recursos que contenía una cuenta Azure Data Lake Storage y, a continuación, volvió a crear una cuenta de almacenamiento con el mismo nombre. Descubrieron que no podían restaurar los datos eliminados a pesar de que Azure ofrece una ventana de recuperación de 14 días para las cuentas de almacenamiento. El soporte de Microsoft explicó que si se elimina una cuenta de almacenamiento y luego se vuelve a crear con el mismo nombre, la recuperación falla. [^2]

El problema subyacente era que el usuario no había habilitado el borrado suave, el control de versiones o los bloqueos de recursos, que podrían haber evitado o mitigado el borrado accidental. La ausencia de dicha protección y la recreación de la cuenta destruyeron efectivamente las opciones de recuperación. 

Cumplimiento y aplicación de la gobernanza

El creciente escrutinio normativo impulsa una inmutabilidad y retención más estrictas. Aunque bienintencionados, estos controles pueden retrasar las correcciones, fragmentar los conjuntos de datos e interrumpir los flujos de trabajo. Las políticas WORM (escribir una vez, leer muchas), por ejemplo, pueden bloquear la reparación de emergencia al impedir los borrados o las ediciones, lo que a su vez retrasa la contención y consume almacenamiento innecesario. Los ajustes de residencia mal configurados pueden bloquear la replicación transfronteriza, rompiendo los objetivos de recuperación.

Incidente documentado: Un usuario de Azure Blob Storage creó una cuenta de almacenamiento en un entorno de pruebas y, cuando terminó con lo que necesitaba, no fue posible eliminar el entorno. Esto se debía a las políticas de inmutabilidad, y la única solución era cambiar la política de cada blob individualmente. El usuario menciona que, aunque las políticas de inmutabilidad eran excelentes para garantizar el cumplimiento en producción, no hay forma de jugar con ellas y entenderlas de forma efímera o en un entorno de pruebas. [^3]

Fallos operativos y de la plataforma

En Azure Blob Storage, los pequeños fallos pueden causar interrupciones y, en ocasiones, pérdidas de datos inducidas por el operador. Dado que muchas aplicaciones y pipelines interactúan con el Blob Storage las 24 horas del día, la superficie de fallo es grande. Las subidas o confirmaciones fallidas, los errores de ETL y pipeline, los desajustes de versión del SDK o del cliente, la falta de comprobaciones de integridad, los reintentos inseguros que sobrescriben datos buenos y los defectos de las herramientas en el entorno del inquilino pueden provocar daños o indisponibilidades temporales.

Incidente documentado: Un fallo en el sistema de refrigeración del centro de datos de Azure en el centro sur de EE.UU. provocó paradas generalizadas del hardware para evitar daños. El incidente provocó fallos en cascada que afectaron no sólo a las cargas de trabajo primarias, sino también a los mecanismos de copia de seguridad y recuperación ante desastres almacenados en Blob Storage. Las organizaciones experimentaron una interrupción generalizada del servicio y problemas en los flujos de trabajo dependientes del almacenamiento durante la recuperación, lo que pone de relieve cómo las dependencias entre servicios pueden limitar las opciones prácticas de conmutación por error incluso con georredundancia. [^4] [^5]

Este incidente arrojó luz sobre la importancia de las copias de seguridad entre regiones y entre nubes, y de garantizar la portabilidad multi-nube de las copias de seguridad. 

Compromiso de la cadena de suministro por parte del proveedor de la nube

Todas las empresas están expuestas al riesgo de la cadena de suministro, y los proveedores de la nube no están exentos. Los problemas en la cadena de suministro de los proveedores de Azure pueden extenderse y causar trastornos a muchas empresas. Más allá de los problemas de la cadena de suministro de software, los problemas originados por los proveedores, como los errores en el servicio, los cambios operativos defectuosos, las malas configuraciones de IAM o la mala gestión de las claves de cifrado, pueden propagarse a los clientes y causar pérdidas de datos o interrupciones incluso cuando las configuraciones de los inquilinos son correctas.

Incidente documentado: Storm-0558, un actor de amenazas con sede en China, obtuvo una clave de firma de consumidor de Microsoft Account (MSA) y tokens de autenticación falsificados. A partir del 15 de mayo de 2023, accedieron a los datos de correo electrónico de unas 25 organizaciones aprovechando un error de validación que permitía a las claves MSA firmar tokens de Azure AD. Investigaciones posteriores argumentaron que la clave comprometida podría haber sido aceptada por otras aplicaciones que utilizan "Iniciar sesión con Microsoft", lo que indica un impacto potencial más allá del correo electrónico. [^6]

Una copia de seguridad inmutable y gobernada por separado garantiza la resiliencia y la capacidad de recuperación

Si hay una solución que podría garantizar la resiliencia operativa durante todas las situaciones mencionadas anteriormente, es una copia de seguridad inmutable y gobernada por separado, con políticas independientes y recuperación puntual.

Con "lógicamente air-gapped" nos referimos a copias de seguridad gobernadas bajo credenciales y roles independientes y protegidas por la inmutabilidad o la retención basada en el tiempo, de modo que los cambios en el inquilino de producción no puedan modificar o borrar las copias de seguridad. Si se manipula el acceso o la configuración de producción, esas copias permanecen intactas y usted dispone de una ruta de restauración limpia y conocida a escala.

Con una copia de seguridad a prueba de manipulaciones, almacenada por separado (en otra región) dentro de Azure Blob Storage, o incluso mejor, en otra plataforma en la nube como Amazon S3 o Google Cloud Storage, puede colocarse en una posición fuerte para recuperarse de la interrupción y la pérdida de datos causada por cualquiera de las situaciones anteriores.

Ahí es exactamente donde HYCU le ayuda. Nuestra solución conjunta con Dell proporciona copias de seguridad rentables y a prueba de ransomware para Azure Blob Storage, para que pueda recuperarse con confianza, incluso en los peores escenarios.

Fácil de desplegar y gestionar. Inmutable por diseño.

Visite www.hycu.com para ver cómo HYCU + Dell ofrecen copias de seguridad rentables y resistentes para Azure Blob Storage.

_________________________________________________________________________________

References:

1. Inteligencia sobre amenazas de Microsoft. (2025, 27 de agosto). La evolución de las técnicas de Storm-0501 conduce al ransomware basado en la nube. Microsoft Security Blog.
2. Nguyen, T. (2025, 20 de agosto). [URGENTE] Eliminación accidental de la cuenta Azure Data Lake Storage Gen2 - ¿Se pueden restaurar los datos? Microsoft Q&A.
3. Lapointe, S. (2023, 8 de diciembre). Cómo eliminar una cuenta de almacenamiento Azure con una política de inmutabilidad desbloqueada. El código es una autopista.
4. Moss, S. (2018, 4 de septiembre). Microsoft Azure sufre una interrupción tras un problema de refrigeración. DataCenterDynamics.
5. Equipo Azure DevOps SRE. (2018, 10 de septiembre). Postmortem - Interrupción de VSTS - 4 de septiembre de 2018. Microsoft DevBlogs.
6. Tamari, S. (2023, 21 de julio). Clave de Microsoft comprometida: Más impactante de lo que pensábamos. Wiz Blog.