Azure Backup Immutable Vault schützt Backups vor Ransomware und Admins

Wer derzeit Azure-Backups verantwortet, kommt am „Azure Backup Immutable Vault“ kaum noch vorbei. In vielen Tenants, die ich betreue, wollen die Verantwortlichen ihre Backups gegen gezielte Angriffe absichern, aber eben auch gegen versehentliche oder böswillige Aktionen der eigenen Admins. Soft Delete allein genügt dafür längst nicht mehr, wenn Backups Ransomware, kompromittierten Konten oder schlichter Fehlbedienung wirklich standhalten sollen. Die neuen Einstellungen im Recovery-Services-Tresor gibt es inzwischen in fast allen Regionen. Man sollte sie nutzen, vorher aber genau verstehen, was sie bewirken.

Nach dem Vault Lock gibt es kein Zurück mehr

Die wichtigste Neuerung heißt „Azure Backup Immutable Vault“. Im Recovery-Services-Tresor lässt sich unter Eigenschaften → Immutability ein Zustand aktivieren, in dem Backups gar nicht mehr gelöscht oder verändert werden können, auch nicht von Konten mit Owner-Rechten. Mit dem Aktivieren ist es allerdings nicht getan. Erst wenn „Vault Lock“ gesetzt ist, wird die Immutability endgültig und lässt sich nicht mehr zurücknehmen. Gegen Ransomware und kompromittierte Admin-Konten hilft das sehr zuverlässig. Der Haken liegt woanders, denn ab diesem Moment sind die Aufbewahrungszeiten der Backups dauerhaft festgeschrieben und mit ihnen die Kosten. Wer den Lock setzt, ohne die Retention-Policies vorher realistisch durchzurechnen, erlebt bei der nächsten Monatsrechnung schnell eine böse Überraschung.

Das folgende vereinfachte Ablaufdiagramm zeigt die wichtigsten Schutzmechanismen und wie sie ineinandergreifen:

flowchart TD
    Admin["Admin"] -->|"Backup löschen"| Vault["Recovery Services-Tresor"]
    Vault -->|"Soft Delete aktiv"| SoftDelete["Soft Delete"]
    Vault -->|"Immutable Vault aktiviert"| Immutable["Immutability"]
    Admin -->|"MUA erforderlich"| ResourceGuard["Resource Guard"]
    ResourceGuard -->|"Genehmigung"| Vault
    Vault -->|"Monitor Alert"| Alert["Azure Monitor"]

Abbildung: Schutzmechanismen beim Löschen von Azure-Backups (Soft Delete, Immutable Vault, MUA, Alerts)

Erst Enhanced Soft Delete mit Always-On hält einem kompromittierten Admin stand

Lange Zeit war Soft Delete der Standard. Löscht jemand ein Backup, bleibt es je nach Workload noch 14 oder 30 Tage im Tresor und kann in dieser Frist wiederhergestellt werden. Ein kompromittierter Admin kann Soft Delete jedoch einfach deaktivieren und die Backups anschließend endgültig entfernen. Aus diesem Grund gibt es inzwischen „Enhanced Soft Delete“ mit einer Always-On-Option. Ist sie gesetzt, lässt sich Soft Delete nicht mehr abschalten, und die Aufbewahrung kann nicht unter die Mindestdauer gesenkt werden. Weitere Details hat Microsoft in der Dokumentation zusammengestellt.

In der Praxis stoße ich oft auf Tresore, in denen Enhanced Soft Delete gar nicht aktiv ist, vor allem bei älteren Recovery-Services-Tresoren. Ein kurzer Blick unter Portal → Tresor → Eigenschaften → Soft Delete schafft Klarheit. Wer auf Nummer sicher gehen will, schaltet Always-On ein und hält das sauber in der Dokumentation fest. Spätestens nach dem Aktivieren und Sperren des Immutable Vault lässt sich die Aufbewahrung nur noch mit Hilfe des Microsoft-Supports verkürzen.

Multi-User Authorization verlangt für heikle Aktionen eine zweite Freigabe

Gegen böswillige oder kompromittierte Admins gehört Multi-User Authorization (MUA) zu den wirksamsten Maßnahmen. Ist MUA aktiv, muss ein zweiter Benutzer sensible Aktionen gegenzeichnen, etwa das Löschen von Backups, Änderungen am Vault oder das Setzen der Immutability. Technisch steckt dahinter ein Resource Guard, der idealerweise in einer separaten Subscription liegt, noch besser in einem eigenen Entra-ID-Tenant. In meinen Projekten statte ich den Resource Guard meist mit dedizierten Global-Reader- oder Approver-Konten aus, für die ein eigenes Genehmigungsverfahren gilt. So hängt keine sensible Backup-Aktion mehr an einem einzigen Konto, und ein „Single Point of Compromise“ ist ausgeschlossen.

Der Backup Operator braucht weniger Rechte als der Contributor

Gern übersehen wird eine saubere Rollentrennung. Der klassische „Contributor“ darf im Recovery-Services-Tresor zu viel und kann unter anderem Backups löschen oder Einstellungen ändern. Die Rolle „Backup Operator“ erlaubt es, Backups zu verwalten und wiederherzustellen, löschen oder Tresor-Eigenschaften ändern kann sie dagegen nicht. Für den Betriebsalltag reicht diese Aufteilung in vielen Fällen. Zusätzlich lasse ich mir bei kritischen Aktionen grundsätzlich Alerts über Azure Monitor schicken, zum Beispiel wenn jemand ein Backup löscht oder Soft Delete deaktiviert. Eingerichtet ist das direkt im Tresor unter „Alerts“. Wer gründlich sein will, leitet die Alerts an ein zentrales SIEM oder an eine Azure-Monitor-Action-Group weiter.

Hinweis aus der Praxis: Bevor Sie Immutable Vault aktivieren und den Lock setzen, sollten Sie Aufbewahrungshistorie und tatsächliches Datenwachstum für mindestens ein Jahr durchspielen. Andernfalls wird es schnell teuer.

Ein gesetztes Häkchen ersetzt beim Cross Region Restore keinen Restore-Test

Neben dem Löschschutz verdient „Cross Region Restore“ Aufmerksamkeit. Im Katastrophenfall lassen sich Backups damit in einer anderen Azure-Region wiederherstellen. Das klappt allerdings nur, wenn beim ersten Einrichten des Tresors „georedundanter Speicher“ ausgewählt wurde. Mehr als einmal habe ich erlebt, dass das Kontrollkästchen zwar aktiviert war, aber niemand genau wusste, wie ein Restore im Ernstfall abläuft. Abhilfe schaffen eine ordentliche Dokumentation und mindestens ein Restore-Test im Jahr.

Stärkerer Schutz verlangt mehr Verantwortung für Aufbewahrung und Kosten

Für mich sind der „Azure Backup Immutable Vault“ und die zugehörigen Schutzmechanismen heute Pflicht, wenn Backups wirklich sicher sein sollen, und zwar gegen Angreifer genauso wie gegen eigene Fehler. Je stärker man den Tresor allerdings abschottet, desto mehr Verantwortung trägt man dafür, Aufbewahrungszeiten und Kosten im Blick zu behalten. Wer Soft Delete, Enhanced Soft Delete mit Always-On, Multi-User Authorization und Immutable Vault durchdacht konfiguriert, kann nachts ruhig schlafen. Wer dagegen ungeprüft alles einschaltet und dann den Lock setzt, hat zwar ein Backup, aber keinen kontrollierten Kostenrahmen mehr. Mehr zu Kosten und sinnvollen Tags findet ihr im Beitrag Azure-Kosten im Griff: Budgets, Tags, Advisor.