Warum Azure Blob Storage eine Datensicherung benötigt: 5 Risiken, die Sie nicht ignorieren dürfen

Azure Blob Storage ist derzeit eine der wichtigsten Cloud-Objektspeicherplattformen auf dem Markt und wird von Tausenden von Unternehmen weltweit genutzt. Teams nutzen es zur Speicherung von High-Performance-Computing-Workloads (HPC), Protokollen und Trace-Daten aus Cloud-nativen Diensten, ETL- und Datentransformationsergebnissen, Trainingsdatensätzen für KI und ML sowie Analysedatensätzen.

Warum native Funktionen keinen umfassenden Datenschutz gewährleisten

Azure Blob Storage bietet integrierte Dauerhaftigkeit und betriebliche Sicherheitsvorkehrungen wie Redundanz, Soft-Löschungen und Versionierung. Diese Funktionen tragen dazu bei, Risiken durch Hardwareausfälle zu mindern und alltägliche Fehler zu reduzieren.

Was sie jedoch nicht bieten, ist echte Ausfallsicherheit, wenn die Steuerungsebene selbst betroffen ist – beispielsweise durch kompromittierte Anmeldedaten, zu großzügig konfigurierte Automatisierung, falsch angewandte Richtlinien oder groß angelegte Bedienerfehler. Da viele dieser Funktionen von ihrer Konzeption her den aktuellen Zustand widerspiegeln, können sie einen fehlerhaften Zustand – wie Löschungen, Beschädigungen oder Richtlinienänderungen – genauso schnell replizieren wie einen fehlerfreien. Das bedeutet, dass Ihre Daten selbst bei aktivierten nativen Funktionen weiterhin einer Reihe von realen Risiken ausgesetzt sind, von denen einige leicht übersehen werden, bis es zu spät ist. 

Fünf Risiken, die Sie bei Azure Blob Storage nicht ignorieren dürfen

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 an Daten verschlüsseln oder beschädigen, während kompromittierte Anmeldedaten oder Missbrauch durch Insider zu Löschungen, Schlüsselrotationen und Richtlinienänderungen führen können. Eine Kompromittierung auf Mandantenebene kann zudem Richtlinien zum Lebenszyklus oder zur Unveränderlichkeit verändern.

Dokumentierter Vorfall: Das Threat-Intelligence-Team von Microsoft berichtete von einer Kampagne, bei der ein als „Storm-0501“ bekannter Angreifer gestohlene Anmeldedaten nutzte, um Azure-Mandanten zu kompromittieren. Der Angreifer löschte Wiederherstellungssperren und Richtlinien zur Unveränderlichkeit, erstellte einen neuen Verschlüsselungsbereich für Azure Blob Storage und verschlüsselte die Daten anschließend mit Schlüsseln, die in einem neu erstellten Key Vault gespeichert waren. Nachdem Hunderte Terabyte an Daten verschlüsselt worden waren, löschte der Angreifer den Verschlüsselungsschlüssel, und Lösegeldforderungen wurden über Microsoft Teams versendet. [^1]

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

Fehlerhafte administrative Konfigurationen

Fehlerhafte Konfigurationen durch Kunden sind eine häufige Ursache für Störungen und Datenverluste in Azure Blob Storage. Da Menschen Zugriffsrichtlinien, Lebenszyklusregeln, rechtliche Aufbewahrungspflichten, Firewall- und Netzwerkeinstellungen sowie die Tiering-Konfiguration vornehmen, besteht ein ständiges Risiko durch menschliches Versagen. Versehentliches Löschen oder Überschreiben kann dazu führen, dass kritische Präfixe entfernt oder Objekte unerwartet ersetzt werden. Falsch konfigurierte Lebenszyklusrichtlinien können dazu führen, dass Daten zu früh ablaufen oder in „Cold“-Tiers verschoben werden, was die Analyse unmöglich macht. Deaktivierte Versionierung/Soft-Delete oder eine fehlerhafte Schlüsselrotation können ebenfalls dazu führen, dass Daten unzugänglich oder nicht wiederherstellbar werden. 

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

Das zugrunde liegende Problem bestand darin, dass der Benutzer weder „Soft Delete“ noch Versionierung oder Ressourcensperren aktiviert hatte, was eine versehentliche Löschung hätte verhindern oder abmildern können. Das Fehlen solcher Schutzmaßnahmen und die Neuerstellung des Kontos machten die Wiederherstellungsmöglichkeiten praktisch zunichte. 

Durchsetzung von Compliance und Governance

Die zunehmende behördliche Kontrolle führt zu strengeren Anforderungen an Unveränderlichkeit und Aufbewahrungsfristen. Obwohl gut gemeint, können diese Kontrollen Fehlerbehebungen verzögern, Datensätze fragmentieren und Arbeitsabläufe stören. WORM-Richtlinien (Write Once, Read Many) können beispielsweise Notfallmaßnahmen blockieren, indem sie Löschungen oder Bearbeitungen verhindern, was wiederum die Eindämmung verzögert und unnötigen Speicherplatz beansprucht. Falsch konfigurierte Residenz-Einstellungen können die grenzüberschreitende Replikation blockieren und damit Wiederherstellungsziele vereiteln.

Dokumentierter Vorfall: Ein Nutzer von Azure Blob Storage erstellte ein Speicherkonto in einer Testumgebung; als er seine Aufgaben erledigt hatte, war es nicht möglich, die Umgebung zu löschen. Dies lag an den Unveränderlichkeitsrichtlinien, und die einzige Abhilfe bestand darin, die Richtlinie jedes einzelnen Blobs individuell zu ändern. Der Nutzer merkt an, dass die Unveränderlichkeitsrichtlinien zwar hervorragend geeignet seien, um die Compliance in der Produktionsumgebung sicherzustellen, es jedoch keine Möglichkeit gebe, damit zu experimentieren und sie in einer temporären oder Testumgebung zu verstehen. [^3]

Betriebs- und Plattformausfälle

In Azure Blob Storage können bereits kleine Fehler zu Störungen und mitunter zu durch den Betreiber verursachten Datenverlusten führen. Da viele Anwendungen und Pipelines rund um die Uhr mit Blob Storage interagieren, ist die Fehleranfälligkeit groß. Fehlgeschlagene Uploads oder Commits, ETL- und Pipeline-Fehler, Inkompatibilitäten bei SDK- oder Client-Versionen, fehlende Integritätsprüfungen, unsichere Wiederholungsversuche, die intakte Daten überschreiben, sowie Tool-Fehler in der Umgebung des Mandanten können allesamt zu Datenbeschädigungen oder vorübergehender Nichtverfügbarkeit führen. 

Dokumentierter Vorfall: Ein Ausfall des Kühlsystems im Azure-Rechenzentrum „South Central US“ führte zu weitreichenden Hardware-Abschaltungen, um Schäden zu verhindern. Der Vorfall hatte eine Kettenreaktion von Ausfällen zur Folge, von denen nicht nur primäre Workloads, sondern auch in Blob Storage gespeicherte Backup- und Disaster-Recovery-Mechanismen betroffen waren. Unternehmen waren während der Wiederherstellung mit weitreichenden Dienstunterbrechungen und Problemen in speicherabhängigen Arbeitsabläufen konfrontiert, was verdeutlichte, wie dienstübergreifende Abhängigkeiten die praktischen Failover-Optionen selbst bei Georedundanz einschränken können. [^4] [^5]

Dieser Vorfall verdeutlichte die Bedeutung von regionen- und cloudübergreifenden Backups sowie die Notwendigkeit, die Multi-Cloud-Portabilität von Backups sicherzustellen. 

Beeinträchtigung der Lieferkette durch den Cloud-Anbieter

Jedes Unternehmen ist Lieferkettenrisiken ausgesetzt, und Cloud-Anbieter bilden hier keine Ausnahme. Probleme in der Lieferkette bei Azure-Anbietern können sich ausbreiten und bei vielen Unternehmen zu Störungen führen. Über Probleme in der Software-Lieferkette hinaus können vom Anbieter ausgehende Probleme wie Servicefehler, fehlerhafte betriebliche Änderungen, Fehlkonfigurationen der Identitäts- und Zugriffsverwaltung (IAM) oder der unsachgemäße Umgang mit Verschlüsselungsschlüsseln auf Kunden übergreifen und zu Datenverlusten oder Betriebsstörungen führen, selbst wenn die Konfigurationen der Mandanten korrekt sind. 

Dokumentierter Vorfall: „Storm-0558“, ein in China ansässiger Angreifer, erlangte einen Signaturschlüssel für Microsoft-Konten (MSA) von Privatkunden und fälschte Authentifizierungstoken. Ab dem 15. Mai 2023 erlangte er Zugriff auf E-Mail-Daten von etwa 25 Organisationen, indem er einen Validierungsfehler ausnutzte, der es ermöglichte, Azure-AD-Token mit MSA-Schlüsseln zu signieren. Nachfolgende Untersuchungen ergaben, dass der kompromittierte Schlüssel möglicherweise auch von anderen Apps akzeptiert worden wäre, die „Anmelden mit Microsoft“ verwenden, was auf potenzielle Auswirkungen über den E-Mail-Bereich hinaus hindeutet. [^6]

Unveränderliche, separat verwaltete Backups gewährleisten Ausfallsicherheit und Wiederherstellbarkeit

Gibt es eine Lösung, die in allen oben genannten Situationen die betriebliche Ausfallsicherheit gewährleisten könnte, dann ist es ein unveränderliches, logisch isoliertes Backup mit unabhängigen Richtlinien und einer zeitpunktbezogenen Wiederherstellung. 

Mit „logisch isoliert“ meinen wir Backups, die unter separaten Anmeldeinformationen und Rollen verwaltet und durch Unveränderlichkeit oder zeitbasierte Aufbewahrungsfristen geschützt sind, sodass Änderungen im Produktions-Tenant die Backup-Kopien weder verändern noch löschen können. Sollte der Zugriff auf die Produktionsumgebung oder deren Konfiguration manipuliert werden, bleiben diese Kopien unversehrt, und Sie verfügen über einen sauberen, als fehlerfrei bekannten Wiederherstellungspfad in großem Maßstab. 

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

Genau hier setzt HYCU an. Unsere gemeinsame Lösung mit Dell bietet kosteneffiziente, ransomware-sichere Backups für Azure Blob Storage, sodass Sie selbst in Worst-Case-Szenarien sicher wiederherstellen können.

Einfach zu implementieren und zu verwalten. Von Grund auf unveränderlich.

Besuchen Sie www.hycu.com, um zu erfahren, wie HYCU + Dell kosteneffiziente und ausfallsichere Backups für Azure Blob Storage bereitstellen. 

_________________________________________________________________________________

Quellenangaben:

1. Microsoft Threat Intelligence. (27. August 2025). Die sich weiterentwickelnden Techniken von Storm-0501 führen zu cloudbasierter Ransomware. Microsoft Security Blog.
2. Nguyen, T. (20. August 2025). [DRINGEND] Versehentliches Löschen eines Azure Data Lake Storage Gen2-Kontos – Können die Daten wiederhergestellt werden? Microsoft Q&A.
3. Lapointe, S. (8. Dezember 2023). So löschen Sie ein Azure-Speicherkonto mit einer entsperrten Unveränderlichkeitsrichtlinie. Code is a Highway.
4. Moss, S. (4. September 2018). Microsoft Azure erleidet Ausfall nach Kühlungsproblem. DataCenterDynamics.
5. Tamari, S. (21. Juli 2023). Kompromittierter Microsoft-Schlüssel: Weitreichendere Auswirkungen als angenommen. Wiz Blog.