In vielen Azure-Projekten wird Blob Storage als Ziel für Ransomware und Datenlöschung stark unterschätzt. In Tenants begegnen mir immer wieder Storage-Accounts, deren „Data Protection“-Funktionen nie jemand angefasst hat, obwohl dort produktive Daten liegen: Backups, Logfiles, KI-Trainingsdaten oder Compliance-Archive. Angreifer kommen auf ganz unterschiedlichen Wegen herein, sei es über kompromittierte Entwicklerzugänge, fehlerhafte Automatisierung oder gezielt mit gestohlenen Shared Keys. Fehlt ein durchdachter Ransomware-Schutz für Blob Storage, kann ein erfolgreicher Angriff sämtliche Snapshots und Backups in Sekunden vernichten oder Dateien überschreiben, ohne dass es jemand bemerkt.

Soft Delete, Versionierung und Point-in-Time-Restore bilden den Basisschutz

In den „Data Protection“-Einstellungen eines Storage-Accounts finden sich etliche Funktionen, die gezielt vor versehentlichen oder böswilligen Aktionen schützen. Soft Delete für Blobs und Container ist mittlerweile Standard. Gelöschte Objekte wandern in eine Art Papierkorb und können innerhalb der eingestellten Frist (häufig 7–30 Tage) wiederhergestellt werden. Mit aktivierter Versionierung legt Azure außerdem jede Änderung als eigene Version ab, sodass sich auch Überschreibungen nachvollziehen und zurückdrehen lassen. Besonders praktisch finde ich Point-in-Time-Restore. Damit holt man einen ganzen Container auf den Stand zu einem beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums zurück, gewissermaßen per Zeitsprung. Ich rate dazu, alle drei Mechanismen gemeinsam zu nutzen, denn sie ergänzen sich: Soft Delete fängt Löschungen ab, die Versionierung schützt vor dem Überschreiben, und Point-in-Time-Restore macht die Wiederherstellung schneller. Mindestens einmal im Jahr sollten die Einstellungen aller produktiven Storage-Accounts geprüft werden, weil sie bei Migrationen oder in Automatisierungsszenarien gern unter den Tisch fallen.

Unveränderlicher Speicher hält Verschlüsselung und gezieltes Löschen auf

Ohne Immutable Storage gibt es keine echte Ransomware-Resilienz. Microsoft hat das Angebot in den letzten Jahren spürbar ausgebaut. Zu den Containern mit zeitbasierter Aufbewahrung und Legal Hold ist vor einiger Zeit die Version-Level Immutability hinzugekommen. Ein einmal geschriebener Blob oder eine Version lässt sich dann für einen festgelegten Zeitraum weder löschen noch verändern. Das gilt auch für Konten mit Owner-Rechten und für kompromittierte Accounts. Bei besonders schützenswerten Daten wie Audit-Logs, regulatorischen Archiven oder Backup-Containern führt heute kein Weg mehr an dieser Funktion vorbei. Die Aktivierung selbst macht wenig Arbeit, allerdings gibt es kein Zurück. Wer Immutability einschaltet, sollte sich das also gut überlegen. Wie man sie einrichtet und welche Optionen es gibt, beschreibt Microsoft in der Übersicht zu Immutable Storage.

Das folgende Diagramm zeigt die wichtigsten Schutzschichten in einem typischen Storage-Account und wie sie zusammenspielen:

flowchart TD
    UserApp["User/App"] --> SoftDelete["Soft Delete"]
    SoftDelete --> Versioning["Versionierung"]
    Versioning --> PITR["Point-in-Time Restore"]
    PITR --> Immutability["Immutabler Speicher"]
    Immutability --> Backup["Azure Backup (Vault)"]
    Backup --> Restore["Wiederherstellung"]
    Admin["Admin oder Angreifer"] --> Lock["Resource Lock"]
    Lock --> StorageAccount["Storage-Account"]

Abbildung: Schutzebenen gegen Löschen und Verschlüsseln im Blob Storage

Resource Locks und Azure Backup verhindern den Totalverlust

Ein Punkt kommt nach wie vor zu kurz. Die beste Konfiguration für den Ransomware-Schutz von Blob Storage hilft nichts, wenn der Angreifer einfach den kompletten Storage-Account löscht. Dagegen schützen Resource Locks auf Subscription- oder Resource-Group-Ebene. Sie blockieren Löschvorgänge, und zwar auch bei Owner- oder Systemzugriffen. Jeder produktive Storage-Account sollte deshalb mindestens einen „CanNotDelete“-Lock bekommen.

Als zweites Standbein dient Azure Backup für Blobs („vaulted backup“). Der Dienst sichert Snapshots und Versionen außerhalb des Storage-Accounts, sodass sie auch dann erhalten bleiben, wenn Account oder Container gelöscht werden. Bei kritischen Daten ist das der letzte Rettungsanker, falls die übrigen Schutzmechanismen versagen. Wie sich Backup und Restore passend zur jeweiligen Anwendung einrichten lassen, erklärt die Microsoft-Dokumentation zur Datenwiederherstellung. Bevor Azure Backup funktioniert, müssen allerdings die nötigen Ressourcen (Backup Vault), Berechtigungen (Backup Contributor) und Richtlinien eingerichtet sein.

Der Shared Key bleibt ein oft vergessenes Einfallstor

Bei fast jedem Security-Review der letzten Monate finde ich Accounts, auf denen der Shared Access Key noch aktiv ist. Meist hat das historische Gründe, oder irgendeine Automatisierung hängt mit einem „Workaround“ daran. Ausgerechnet über den Shared Key laufen aber die meisten Massenlöschungen und unbemerkten Verschlüsselungsangriffe. Seit 2024 kann man den Shared-Key-Zugriff pro Account abschalten und die Authentifizierung auf Entra ID umstellen. Die einzelnen Schritte habe ich ausführlich in meinem Beitrag zum Abschalten des Shared Key zugunsten von Entra ID beschrieben. Wer noch mit Shared Key arbeitet, sollte jetzt umstellen und dabei gleich einen „CanNotDelete“-Lock setzen.

Praktischer Tipp: Ob Container oder Accounts noch ungeschützt sind, sieht man im Azure Portal unter „Storage Account → Data management → Data protection“ auf einen Blick. Diese Kontrolle gehört regelmäßig in jeden Security-Check.

Ransomware-Schutz lässt sich nicht mit einem Häkchen erledigen

Azure Blob Storage lässt sich heute deutlich besser absichern als noch vor einigen Jahren, vorausgesetzt, man schaltet die Funktionen auch ein. Aus der Praxis habe ich mir eine Faustregel angewöhnt. Soft Delete und Versionierung sind immer aktiv, Point-in-Time-Restore überall dort, wo es geht, Immutable Storage bei besonders kritischen Daten und Azure Backup für Vaulted Snapshots. Ohne Resource Locks bleibt trotzdem eine Lücke, und Shared Key hat in einer sauberen Umgebung nichts verloren. Wer schon einmal miterlebt hat, was nach der Kompromittierung eines Storage-Accounts passiert, weiß, dass nur gestaffelte Schutzmechanismen Blob Storage tatsächlich vor Ransomware bewahren. Wie man Shared Key sicher ablöst, lest ihr im verlinkten Beitrag. Und auch hier gilt wieder, einmal im Jahr alle Einstellungen zu prüfen, statt sich blind auf die Standardwerte zu verlassen. Sonst stellt man erst im Ernstfall fest, was fehlt.