Azure Backup: Über die nativen Funktionen hinaus – auf dem Weg zu einer lückenlosen Abdeckung

Das Entra-ID-Problem, mit dem niemand rechnet

Ein Kunde wandte sich letztes Jahr wegen eines Problems an mich, das er nicht hatte kommen sehen. Ein Mitarbeiter seines Teams hatte eine Entra-ID-App-Registrierung gelöscht, von der 40 interne Dienste abhängig waren. Innerhalb weniger Minuten kam es zu Ausfällen bei diesen Diensten. Man versuchte, die App-Registrierung aus dem Azure-Backup wiederherzustellen. 

Das Azure-Backup deckt Entra ID nicht ab. Microsoft weist in seiner Dokumentation seit Jahren deutlich darauf hin. Der Kunde hatte dies nicht gelesen. Die meisten Teams haben dies nicht getan. Als ihnen schließlich klar wurde, was sie verloren hatten, hatten sie bereits zwei Tage damit verbracht, die App-Registrierung manuell aus Konfigurationsdateien wiederherzustellen, die über verschiedene Teams verstreut waren. 

Dieser Vorfall hat meine Sichtweise auf den Schutz in Azure geprägt. Die von Microsoft bereitgestellten nativen Dienste sind nützliche Grundbausteine. Sie bieten jedoch keinen vollständigen Schutz, und die Lücken befinden sich genau dort, wo die meisten Teams davon ausgehen, dass der Schutz standardmäßig gewährleistet ist. 

Wo die nativen Dienste von Azure an ihre Grenzen stoßen

Microsoft bietet mehrere native Schutzdienste an, die ihre Aufgaben gut erfüllen. Azure Backup übernimmt Snapshots auf VM-Ebene und die Wiederherstellung auf Dateiebene. Azure Site Recovery übernimmt die Failover-Koordination. Azure SQL verfügt über automatisierte Backups mit Point-in-Time-Wiederherstellung. Azure Blob Storage bietet Optionen für Versionierung und Unveränderlichkeit. Für viele Workloads sind dies der richtige Ausgangspunkt.

Die Lücken zeigen sich an fünf spezifischen Stellen, die am wichtigsten sind, wenn Sie tatsächlich eine Wiederherstellung benötigen.

Anwendungskonsistenz bei komplexen Workloads. Native VM-Snapshots sind in der Regel absturzsicher. Für anwendungsorientierte Backups von mehrschichtigen Workloads, SAP HANA oder Anwendungen mit benutzerdefinierten Anforderungen an die Systemruhe benötigen Sie ein Framework vor und nach der Anwendung, das sicherstellt, dass Dateisysteme und Anwendungen ordnungsgemäß in den Ruhezustand versetzt werden. Es reicht nicht aus, lediglich einen Snapshot des aktuellen Zustands des Kernels zu erstellen.

SaaS-Abdeckung. Das native Azure-Backup deckt weder Microsoft 365 noch Entra ID ab. Microsoft selbst erklärt ausdrücklich, dass die Aufbewahrung und Wiederherstellung dieser Objekte auf Mandantenebene in der Verantwortung des Kunden liegt. Wenn Sie eine Entra-ID-Anwendungsregistrierung verlieren oder eine SharePoint-Website löschen, führt Microsoft die Aktion durch, ohne dass es einen Wiederherstellungsweg seitens Microsoft selbst gibt. 

Tenant- und abonnementübergreifende Wiederherstellung. Native Dienste funktionieren innerhalb eines einzelnen Azure-Abonnements. Die Wiederherstellung in ein anderes Abonnement, einen anderen Tenant oder zurück in die lokale Umgebung ist betrieblich schwieriger, als es sein sollte – insbesondere während eines Vorfalls, bei dem die Quellumgebung nicht vertrauenswürdig ist. 

Richtlinienverwaltung in großem Maßstab. Sobald Hunderte von VMs mehrere Ressourcengruppen und Abonnements umfassen, führt die manuelle Zuweisung von Sicherungsrichtlinien zu Lücken in der Abdeckung durch schleichenden Verlust. Die Workloads, die dabei übersehen werden, sind genau diejenigen, die ein Angreifer oder ein unachtsamer Administrator letztendlich zerstören wird.

Kostenvorhersehbarkeit außerhalb erwarteter Szenarien. Ausgangsgebühren, Wechsel zwischen Aufbewahrungsstufen und versteckte Kosten für den Betrieb nativer Dienste über Regionen hinweg können Sie in einem ungünstigen Monat überraschen – genau dann, wenn Sie tatsächlich etwas Wichtiges wiederherstellen müssen.

Über native Funktionen hinauszugehen bedeutet nicht, diese aufzugeben. Es bedeutet, native Grundfunktionen als Fundament zu betrachten und darauf aufbauend Abdeckung, Konsistenz und operative Skalierbarkeit hinzuzufügen. 

Was ein umfassender Azure-Schutz abdecken muss

Was „speziell für Azure entwickelt“ tatsächlich bedeutet

Anbieter lieben diesen Ausdruck. Vier konkrete Tests unterscheiden das Marketing von der Architektur.

Native Azure-Snapshots auf VM-Ebene. Der Backup-Dienst sollte den nativen Snapshot-Mechanismus von Azure nutzen und keine zusätzlich aufgesetzten Snapshots des Anbieters, damit die Auswirkungen auf den Produktivbetrieb nahezu null bleiben.

Authentifizierung über Microsoft Entra ID. Die Authentifizierung erfolgt über Entra ID und übernimmt bestehende RBAC-Richtlinien. Eine separate Benutzerdatenbank erfordert eine parallele Infrastruktur, die synchronisiert werden muss.

Vertrieb über den Azure Marketplace und Abrechnung über Azure. Das Abonnement läuft über den Marketplace und wird über bestehende Azure-Verpflichtungen abgerechnet. Es handelt sich nicht um eine separate Beschaffungs- und Abrechnungsbeziehung.

Berücksichtigung von Ressourcengruppen für Mandantenfähigkeit. Verschiedene Teams und Geschäftsbereiche befinden sich in unterschiedlichen Ressourcengruppen. Der Dienst sollte diese Struktur automatisch erkennen und berücksichtigen, sodass jedes Team nur Einblick in seine eigenen Ressourcen erhält. 

Was unterscheidet ein einfaches Backup von einem operativen Backup?

Die Bereitstellung eines Backups ist der einfache Teil. Die Funktionen, die darüber entscheiden, ob der Schutz auch nach zwei Jahren, Dutzenden neuer VMs und mindestens einer Umstrukturierung des Unternehmens noch funktioniert, sind eher operativer als funktionaler Natur. Vier spezifische Funktionen sind entscheidend.

Ein Framework für die Konsistenz benutzerdefinierter Anwendungen. Standard-Azure-VM-Snapshots eignen sich für gängige Anwendungen. Für SAP HANA, benutzerdefinierte Anwendungen oder mehrschichtige Workloads ermöglicht ein Framework für die Vor- und Nachbereitung von Anwendungen die Festlegung, wie das Dateisystem oder die Anwendung für die Sicherung vorbereitet werden soll. Ohne dieses Framework existieren zwar Backups, doch die Wiederherstellung ist anfällig.

Tag-basierte automatische Richtlinienzuweisung. Definieren Sie Richtlinien einmalig, abgestimmt auf SLAs, und wenden Sie diese dann automatisch auf der Grundlage von Tags an, die während der Bereitstellung zugewiesen wurden. Eine mit „production-tier-1“ getaggte Workload erhält die Tier-1-Richtlinie. Eine mit „dev“ getaggte Workload erhält die Dev-Richtlinie. Nicht mit Tags versehene Workloads erhalten die standardmäßige „Safety-Net“-Richtlinie. Maximale Abdeckung bei minimalem Verwaltungsaufwand.

Granulare Wiederherstellung. Bei der Wiederherstellung sollten Sie wählen können, was auf Datei-, Ordner-, VM-, vDisk- oder vollständiger Anwendungsebene wiederhergestellt werden soll und wo dies geschehen soll: am ursprünglichen Speicherort, auf einer alternativen VM, in einer anderen Ressourcengruppe, in einem anderen Abonnement oder in einer anderen Region. Diese Granularität ist besonders wichtig in Sicherheitsvorfallszenarien, in denen Sie der ursprünglichen Umgebung nicht mehr vertrauen können.

Webhook-gesteuerte Benachrichtigungen in Ihren bestehenden Betriebs-Stack. Kritische Backup-Ereignisse werden in den Tools angezeigt, die Ihr Team bereits nutzt: Slack, Microsoft Teams, ServiceNow. Nicht in einer separaten Konsole, die niemand überwacht. Echtzeit-Warnmeldungen bei Schutzfehlern entscheiden darüber, ob ein Problem frühzeitig erkannt oder erst während der Wiederherstellung entdeckt wird.

Azure Government und regulierte Workloads

Bundesbehörden, Rüstungsunternehmen und regulierte Branchen haben Anforderungen, die über das Standard-Azure-Backup hinausgehen. Drei Funktionen sind dabei besonders wichtig.

Unterstützung für die Azure Government Cloud. Der Schutz muss innerhalb von Azure Government funktionieren, nicht nur im kommerziellen Azure. Für US-Bundesbehörden umfasst dies die Sicherung lokaler Daten in Azure Government Blob Storage als Archiv oder primäres Backup – aus zentralen Rechenzentren, Edge-Standorten, entfernten Standorten und mobiler Infrastruktur. 

WORM-basierter Ransomware-Schutz mit cloud-effizienter Deduplizierung. WORM-Speicher verhindert, dass Ransomware Backup-Kopien verschlüsselt. Die kostenseitige Herausforderung besteht darin, dass herkömmliche Deduplizierungsgeräte erhebliche Rechenleistung und Arbeitsspeicher benötigen, was in der Cloud teuer ist. Wir speichern nur eindeutige Blöcke in der Cloud, was Netzwerk-, Speicher- und Rechenressourcen einspart. Da für den Abruf keine Rehydrierung erforderlich ist, wird die Wiederherstellungsleistung ausschließlich durch die Netzwerkbandbreite begrenzt.

FIPS-140-Zertifizierung und vom Kunden kontrollierte Datenhoheit. HYCU hat im Jahr 2025 die FIPS 140-3-Zertifizierung erhalten und erfüllt damit die Standards für kryptografische Module der US-Bundesbehörden. In Verbindung mit dem architektonischen Grundsatz, dass Kundendaten niemals die Kontrolle des Kunden verlassen, ist dies für jedes Unternehmen von Bedeutung, das den FedRAMP-, ITAR-, CMMC- oder ähnlichen regulatorischen Rahmenbedingungen unterliegt. 

Häufige Fragen zur Azure-Sicherung

Ist in Azure bereits eine Sicherungsfunktion enthalten, oder benötige ich eine separate Lösung?

Azure umfasst native Schutzdienste, die VM-Snapshots, Dateiwiederherstellung und DR-Orchestrierung für viele Szenarien abdecken. Diese decken jedoch weder Microsoft 365 noch Entra ID ab und erfüllen auch nicht viele Konsistenzanforderungen von Unternehmensanwendungen; zudem weisen sie Einschränkungen hinsichtlich der mandantenübergreifenden Wiederherstellung und der Richtlinienverwaltung in großem Maßstab auf. Die meisten Unternehmensumgebungen benötigen einen mehrschichtigen Ansatz: native Funktionen plus eine Plattform eines Drittanbieters für eine lückenlose Abdeckung. 

Wie geht die Azure-Sicherung mit Microsoft 365 und Entra ID um?

Gar nicht. Das Modell der geteilten Verantwortung von Microsoft überträgt die Aufbewahrung und Wiederherstellung von Microsoft 365-Daten und Entra ID-Objekten auf den Kunden. Eine granulare Wiederherstellung von Exchange-Postfächern, SharePoint-Websites, OneDrive-Inhalten, Teams-Daten sowie Entra ID-App-Registrierungen oder -Benutzern erfordert eine Drittanbieterplattform, die speziell für diese Workloads entwickelt wurde.

Kann ich Azure als DR-Ziel nutzen, ohne für eine ständig aktive Infrastruktur zu zahlen?

Ja. Mit cloud-nativem BaaS werden Sicherungskopien kontinuierlich und kostengünstig im Azure Blob Storage gespeichert. Rechenleistung und Hochleistungsspeicher werden nur dann in Anspruch genommen, wenn ein DR-Szenario ausgelöst wird. Den größten Teil des Jahres zahlen Sie für den Speicher. An den seltenen Tagen, an denen eine Katastrophe eintritt, zahlen Sie für die Rechenleistung. Ein Bruchteil der Kosten für eine vollständig bereitgestellte Standby-Lösung.

Was ist der Unterschied zwischen Azure Backup und einer dedizierten BaaS-Plattform?

Azure Backup ist der native Dienst von Microsoft zum Schutz von Azure-VMs, Azure Files und SQL-Workloads innerhalb von Azure. Eine dedizierte BaaS-Plattform baut darauf auf und bietet zusätzlich anwendungskonsistente Backups für Unternehmensanwendungen, SaaS-Abdeckung (Microsoft 365, Entra ID), zentralisierte Richtlinienverwaltung über Abonnements und Mandanten hinweg, Webhook-Integration sowie cloudübergreifende Notfallwiederherstellung. Beide Lösungen ergänzen sich. 

Wenn Sie nur eine Maßnahme ergreifen

Überprüfen Sie noch heute Ihre Microsoft 365- und Entra ID-Abdeckung. Erstellen Sie eine Liste darüber, was mit welchem Tool gesichert wird und was erforderlich wäre, um eine versehentlich gelöschte App-Registrierung, eine SharePoint-Website oder einen kritischen Benutzer wiederherzustellen. Sollte die Antwort auf eine dieser Fragen lauten: „Wir würden alles von Grund auf neu aufbauen“, haben Sie eine Lücke, die es zu schließen gilt, bevor jemand denselben Fehler begeht wie der Kunde in meinem einleitenden Beispiel.