Warum Azure Blob Storage eine Sicherung braucht: 5 Risiken, die Sie nicht ignorieren können

Objektspeicher haben sich weiterentwickelt. Er ist nicht mehr nur ein Ziel für archivierte Dateien, sondern dient jetzt als primärer Speicher für unternehmenskritische Daten in KI-Pipelines, Analysen und Cloud-nativen Anwendungen. Mit diesem Wandel war der Schutz dieser Daten noch nie so wichtig wie heute.

Azure Blob Storage ist heute eine der wichtigsten Plattformen für Cloud-Objektspeicher auf dem Markt und wird von Tausenden von Unternehmen weltweit genutzt. Teams nutzen ihn für die Speicherung von High-Performance Computing (HPC)-Workloads, Protokollen und Traces von Cloud-nativen Diensten, ETL- und Datenumwandlungs-Outputs, KI- und ML-Trainingsdatensätzen und Analysedatensätzen.

Warum native Funktionen keinen umfassenden Datenschutz gewährleisten

Azure Blob Storage bietet integrierte Haltbarkeit und betriebliche Sicherheitsvorkehrungen wie Redundanz, Soft Deletes und Versionierung. Diese Funktionen helfen, das Risiko von Hardwareausfällen zu bekämpfen und alltägliche Fehler zu reduzieren.

Was sie jedoch nicht bieten, ist echte Ausfallsicherheit, wenn die Steuerungsebene selbst betroffen ist, z. B. durch kompromittierte Anmeldeinformationen, übermäßige Automatisierung, falsch angewendete Richtlinien oder weitreichende Bedienerfehler. Da viele dieser Funktionen von vornherein den aktuellen Zustand spiegeln, können sie einen schlechten Zustand, wie z.B. Löschungen, Beschädigungen oder Richtlinienänderungen, genauso schnell replizieren wie einen sauberen Zustand. Das bedeutet, dass Ihre Daten auch bei aktivierten nativen Funktionen einer Reihe von Risiken ausgesetzt sind, von denen einige leicht zu übersehen sind, bis es zu spät ist.

Fünf Risiken, die Sie bei Azure Blob Storage nicht ignorieren können

Sicherheitsvorfälle

Azure Blob Storage speichert riesige Mengen an hochwertigen Daten, oft im Petabyte-Bereich. Ein gut dokumentierter programmatischer Zugriff auf solche Daten ist der Traum eines jeden Hackers. Gezielte Ransomware kann Terabytes von Daten verschlüsseln oder beschädigen, während kompromittierte Anmeldedaten oder Missbrauch durch Insider Löschungen, Schlüsselrotationen und Richtlinienänderungen auslösen können. Eine Kompromittierung auf Mieterebene kann auch Lebenszyklus- oder Unveränderbarkeitsrichtlinien ändern.

Dokumentierter Vorfall: Das Bedrohungsanalyse-Team von Microsoft meldete eine Kampagne, bei der ein als Storm-0501 bekannter Bedrohungsakteur gestohlene Anmeldedaten verwendete, um Azure-Mieter zu kompromittieren. Der Angreifer löschte Wiederherstellungssperren und Unveränderbarkeitsrichtlinien, erstellte einen neuen Verschlüsselungsbereich für Azure Blob Storage und verschlüsselte dann die Daten mit Schlüsseln, die in einem neu erstellten Key Vault gespeichert waren. Nachdem sie Hunderte von Terabyte an Daten verschlüsselt hatten, löschten sie den Verschlüsselungsschlüssel und verschickten Lösegeldforderungen über Microsoft Teams. [^1]

Dieser Vorfall veranschaulicht, wie kompromittierte Anmeldedaten und der Missbrauch von programmatischem Zugriff es Angreifern ermöglichen können, riesige Datensätze zu verschlüsseln oder zu löschen und Lebenszyklus- oder Unveränderbarkeitsrichtlinien zu manipulieren.

Administrative Fehlkonfigurationen

Fehlkonfigurationen durch Kunden sind eine häufige Ursache für Störungen und Datenverluste in Azure Blob Storage. Da Zugriffsrichtlinien, Lebenszyklusregeln, rechtliche Einschränkungen, Firewall- und Netzwerkeinstellungen sowie Tiering von Menschen konfiguriert werden, besteht ein ständiges Risiko durch menschliche Fehler. Durch versehentliches Löschen oder Überschreiben können wichtige Präfixe entfernt oder Objekte unerwartet ersetzt werden. Falsch konfigurierte Lebenszyklusrichtlinien können dazu führen, dass Daten zu früh ablaufen oder in kalte Tiers verschoben werden, was die Analyse beeinträchtigt. Deaktivierte Versionierung/Soft Delete oder eine falsche Schlüsselrotation können ebenfalls dazu führen, dass Daten unzugänglich oder nicht wiederherstellbar sind.

Dokumentierter Vorfall: Ein Benutzer löschte eine Ressourcengruppe, die ein Azure Data Lake Storage-Konto enthielt, und erstellte dann ein Speicherkonto mit demselben Namen neu. Er stellte fest, dass er die gelöschten Daten nicht wiederherstellen konnte, obwohl Azure ein 14-tägiges Wiederherstellungsfenster für Speicherkonten bietet. Der Microsoft-Support erklärte, dass die Wiederherstellung fehlschlägt, wenn ein Speicherkonto gelöscht und dann mit demselben Namen neu erstellt wird. [^2]

Das zugrundeliegende Problem bestand darin, dass der Benutzer kein Soft Delete, keine Versionierung und keine Ressourcensperren aktiviert hatte, die ein versehentliches Löschen hätten verhindern oder abschwächen können. Durch das Fehlen eines solchen Schutzes und die Neuerstellung des Kontos wurden die Wiederherstellungsoptionen effektiv zerstört. 

Durchsetzung von Compliance und Governance

Die zunehmende Kontrolle durch die Behörden führt zu einer strengeren Unveränderbarkeit und Aufbewahrung. Diese Kontrollen sind zwar gut gemeint, können aber Korrekturen verzögern, Datensätze fragmentieren und Arbeitsabläufe stören. WORM-Richtlinien (Write Once, Read Many) können beispielsweise die Behebung von Notfällen blockieren, indem sie das Löschen oder Bearbeiten von Daten verhindern, was wiederum die Eindämmung verzögert und unnötigen Speicherplatz verbraucht. Falsch konfigurierte Residency-Einstellungen können die grenzüberschreitende Replikation blockieren und damit die Wiederherstellungsziele zunichte machen.

Dokumentierter Vorfall: Ein Benutzer von Azure Blob Storage erstellte ein Speicherkonto in einer Testumgebung und als er mit dem, was er brauchte, fertig war, war das Löschen der Umgebung nicht möglich. Das lag an den Unveränderbarkeitsrichtlinien, und die einzige Abhilfe bestand darin, die Richtlinien für jeden Blob einzeln zu ändern. Der Benutzer erwähnt, dass die Unveränderbarkeitsrichtlinien zwar hervorragend geeignet sind, um die Einhaltung von Richtlinien in der Produktion zu gewährleisten, dass es aber keine Möglichkeit gibt, damit zu spielen und sie auf ephemere Weise oder in einer Testumgebung zu verstehen. [^3]

Betriebs- und Plattformausfälle

In Azure Blob Storage können kleine Fehler zu Unterbrechungen und manchmal auch zu einem vom Benutzer verursachten Datenverlust führen. Da viele Anwendungen und Pipelines rund um die Uhr mit Blob Storage interagieren, ist die Angriffsfläche für Fehler groß. Fehlgeschlagene Uploads oder Commits, ETL- und Pipeline-Fehler, nicht übereinstimmende SDK- oder Client-Versionen, fehlende Integritätsprüfungen, unsichere Wiederholungsversuche, die gute Daten überschreiben, und Tooling-Fehler in der Umgebung des Tenants können zu einer Beschädigung oder vorübergehenden Nichtverfügbarkeit führen.

Dokumentierter Vorfall: Ein Ausfall des Kühlsystems im Azure-Rechenzentrum in South Central US führte zu weitreichenden Hardwareabschaltungen, um Schäden zu vermeiden. Der Vorfall führte zu kaskadenartigen Ausfällen, die nicht nur die primären Arbeitslasten betrafen, sondern auch die in Blob Storage gespeicherten Backup- und Disaster-Recovery-Mechanismen. Unternehmen erlebten weitreichende Serviceunterbrechungen und Probleme bei speicherabhängigen Arbeitsabläufen während der Wiederherstellung, was deutlich macht, wie serviceübergreifende Abhängigkeiten die praktischen Failover-Optionen selbst bei geografischer Redundanz einschränken können. [^4] [^5]

Dieser Vorfall machte deutlich, wie wichtig regions- und cloudübergreifende Backups sind und wie wichtig es ist, die Portabilität von Backups über mehrere Clouds hinweg zu gewährleisten. 

Zwischenfälle in der Lieferkette durch den Cloud-Anbieter

Jedes Unternehmen ist einem Risiko in der Lieferkette ausgesetzt, und auch Cloud-Anbieter sind davon nicht ausgenommen. Probleme in der Lieferkette von Azure-Anbietern können auf andere Unternehmen übergreifen und dort zu Unterbrechungen führen. Abgesehen von Problemen in der Software-Lieferkette können vom Anbieter verursachte Probleme wie Servicefehler, fehlerhafte betriebliche Änderungen, IAM-Fehlkonfigurationen oder die falsche Handhabung von Verschlüsselungsschlüsseln auf die Kunden übergreifen und zu Datenverlusten oder Unterbrechungen führen, selbst wenn die Tenant-Konfigurationen korrekt sind.

Dokumentierter Vorfall: Storm-0558, ein in China ansässiger Bedrohungsakteur, verschaffte sich einen Microsoft-Konto-Signierschlüssel (MSA) für Kunden und fälschte Authentifizierungs-Tokens. Ab dem 15. Mai 2023 verschafften sie sich Zugang zu den E-Mail-Daten von etwa 25 Unternehmen, indem sie einen Validierungsfehler ausnutzten, durch den MSA-Schlüssel Azure AD-Token signieren konnten. Spätere Untersuchungen ergaben, dass der kompromittierte Schlüssel auch von anderen Anwendungen akzeptiert werden konnte, die "Login with Microsoft" verwenden, was auf mögliche Auswirkungen über E-Mail hinaus hinweist. [^6]

Unveränderliches, separat verwaltetes Backup sorgt für Ausfallsicherheit und Wiederherstellbarkeit

Wenn es eine Lösung gibt, die in all den oben genannten Situationen betriebliche Ausfallsicherheit gewährleisten kann, dann ist es ein unveränderliches, logisch verwaltetes Backup mit unabhängigen Richtlinien und zeitnaher Wiederherstellung.

Mit "logically air-gapped" meinen wir Backups, die unter separaten Anmeldeinformationen und Rollen verwaltet werden und durch Unveränderlichkeit oder zeitbasierte Aufbewahrung geschützt sind, so dass Änderungen im Produktionsmieter keine Sicherungskopien verändern oder löschen können. Wenn der Zugriff auf die Produktion oder die Konfiguration manipuliert wird, bleiben diese Kopien intakt, und Sie haben einen sauberen, bekannt guten Wiederherstellungspfad im großen Maßstab.

Mit einem manipulationssicheren Backup, das separat (in einer anderen Region) in Azure Blob Storage oder noch besser in einer anderen Cloud-Plattform wie Amazon S3 oder Google Cloud Storage gespeichert wird, können Sie sich in eine starke Position versetzen, um sich von Störungen und Datenverlusten zu erholen, die durch eine der oben genannten Situationen verursacht werden.

Genau hier hilft HYCU. Unsere gemeinsame Lösung mit Dell bietet kosteneffiziente, Ransomware-sichere Backups für Azure Blob Storage, so dass Sie sich selbst im schlimmsten Fall zuversichtlich erholen können.

Einfach zu implementieren und zu verwalten. Von Haus aus unveränderlich.

Werfen Sie einen Blick auf www.hycu.com, um zu sehen, wie HYCU + Dell kosteneffiziente und widerstandsfähige Backups für Azure Blob Storage liefert.

_________________________________________________________________________________

References:

1. Microsoft Threat Intelligence. (2025, 27. August). Storm-0501's evolving techniques lead to cloud-based ransomware. Microsoft Security Blog.
2. Nguyen, T. (2025, August 20). [DRINGEND] Versehentliches Löschen des Azure Data Lake Storage Gen2 Kontos - Können die Daten wiederhergestellt werden? Microsoft Q&A.
3. Lapointe, S. (2023, Dezember 8). Wie man ein Azure-Speicherkonto mit einer nicht gesperrten Unveränderlichkeitsrichtlinie löscht. Code ist ein Highway.
4. Moss, S. (2018, September 4). Microsoft Azure erleidet Ausfall nach Kühlungsproblem. DataCenterDynamics.
5. Azure DevOps SRE Team. (2018, September 10). Postmortem - VSTS-Ausfall - 4. September 2018. Microsoft DevBlogs.
6. Tamari, S. (2023, Juli 21). Kompromittierter Microsoft-Schlüssel: Folgenreicher als gedacht. Wiz Blog.