7 Was ist ein Disaster-Recovery-Plan für die Cloud? Ein Disaster-Recovery-Plan für die Cloud ist ein dokumentiertes Verfahren, um Anwendungen, Infrastruktur und Daten nach einem Ausfall oder einem anderen störenden Ereignis mithilfe von Cloud-Ressourcen wiederherzustellen. Je nach Architektur kann die Cloud dienen als: Primäre Produktivumgebung mit Wiederherstellung in einer anderen Region oder Cloud Umgebung für die Notfallwiederherstellung von On-Premises-Infrastruktur Sekundärstandort für replizierte Anwendungen und Daten Backup-Ziel für Daten, die bei der Wiederherstellung benötigt werden Teil einer hybriden Architektur für die Notfallwiederherstellung Das passende Design hängt vor allem von den geschäftlichen Anforderungen, den Abhängigkeiten der Anwendungen und zwei wichtigen Wiederherstellungszielen ab: Recovery Time Objective (RTO) und Recovery Point Objective (RPO). RTO definiert die maximal akzeptable Zeit, die nach einer Unterbrechung für die Wiederherstellung eines Dienstes benötigt wird. RPO definiert den maximal akzeptablen Datenverlust, ausgedrückt als Zeitraum. Eine Anwendung mit einem RTO von vier Stunden sollte beispielsweise innerhalb von vier Stunden nach der Ausrufung eines Notfalls wieder betriebsbereit sein. Ein RPO von 15 Minuten bedeutet, dass die Wiederherstellungsstrategie den möglichen Datenverlust auf rund 15 Minuten begrenzen sollte. Diese Ziele beeinflussen alles, von Backup-Häufigkeit und Replikation bis zu Infrastrukturkosten und Automatisierung. Beispiel für einen Disaster-Recovery-Plan in der Cloud Nehmen wir ein fiktives Unternehmen, das eine kundenorientierte Anwendung mit einer Kombination aus On-Premises-Infrastruktur und Cloud-Diensten betreibt. Seine Umgebung umfasst: Kundenorientierte Webanwendungen Anwendungsserver Produktivdatenbanken Datei- und Objektdaten Identitäts- und Zugriffsdienste DNS- und Netzwerkdienste Backup-Infrastruktur Rechen- und Speicherressourcen in der Cloud Das Unternehmen möchte den Zugang zu seinen wichtigsten Diensten aufrechterhalten, wenn seine primäre Infrastruktur nicht mehr verfügbar ist. Sein Disaster-Recovery-Plan könnte folgendermaßen aussehen. 1. Den Umfang festlegen Ziel des Plans: Kritische Kundendienste und zugehörige Daten nach einem schweren Infrastrukturausfall, einem Cyberangriff oder einer regionalen Dienststörung wiederherstellen. Abgedeckte Systeme: SystemPrioritätRTORPOIdentität und AuthentifizierungKritisch30 Minuten15 MinutenKundenanwendungKritisch1 Stunde15 MinutenProduktivdatenbankKritisch1 Stunde15 MinutenObjekt- und DateidatenKritisch2 Stunden1 StundeInternes ReportingMittel8 Stunden4 StundenEntwicklungssystemeNiedrig24 Stunden24 Stunden Diese Werte sind Beispiele und keine allgemeingültigen Empfehlungen. Organisationen sollten die Anforderungen an RTO und RPO über eine Business-Impact-Analyse und Gespräche mit den Anwendungsverantwortlichen ermitteln. 2. Abhängigkeiten identifizieren Anwendungen lassen sich selten unabhängig wiederherstellen. Die Kundenanwendung in diesem Beispiel hängt ab von: Netzwerkkonnektivität DNS Identitätsdiensten Datenbankdiensten Objekt- oder Dateispeicher Rechenressourcen für die Anwendung Sicherheitskontrollen Monitoring Der Wiederherstellungsplan sollte diese Beziehungen dokumentieren, damit Teams nicht versuchen, eine Anwendung wiederherzustellen, bevor die benötigten Dienste verfügbar sind. Eine Abhängigkeitskarte kann zudem Single Points of Failure aufdecken, die im normalen Betrieb sonst verborgen blieben. 3. Die Architektur für die Notfallwiederherstellung festlegen Das Unternehmen hält Wiederherstellungsressourcen in einer sekundären Cloud-Region vor. Kritische Daten werden durch eine Kombination aus Replikation und Backups geschützt. Infrastrukturkonfigurationen werden mit Infrastructure-as-Code-Vorlagen gepflegt, sodass benötigte Cloud-Ressourcen einheitlich neu erstellt werden können. Die Wiederherstellungsumgebung umfasst: Sekundäre Rechenkapazität Replizierte Datenbanken Geschützte Objekt- und Dateidaten Von der Produktion isolierte Backup-Kopien Netzwerk- und Sicherheitskonfigurationen DNS-Failover-Funktionen Vorlagen für die Infrastrukturbereitstellung Monitoring und Protokollierung Nicht jede Ressource muss dauerhaft laufen. Organisationen können je nach Bedeutung des jeweiligen Workloads unterschiedliche Wiederherstellungsansätze wählen. Backup und Wiederherstellung Anwendungen und Daten werden nach einem Notfall aus Backups wiederhergestellt. Dieser Ansatz kann die Kosten für Standby-Infrastruktur senken, erfordert in der Regel aber mehr Zeit für die Wiederherstellung. Pilot Light Kerndienste und Daten bleiben in der Wiederherstellungsumgebung verfügbar, während zusätzliche Infrastruktur erst gestartet wird, wenn eine Wiederherstellung nötig ist. Warm Standby Eine Version der Produktivumgebung mit reduzierter Kapazität läuft dauerhaft und kann beim Failover skalieren. Aktiv-aktiv Anwendungen laufen gleichzeitig an mehreren Standorten, sodass der Datenverkehr bei einem Ausfall zwischen den Umgebungen wechseln kann. Niedrigere RTO- und RPO-Ziele erfordern in der Regel höhere Investitionen in Infrastruktur, mehr Automatisierung und mehr betriebliche Komplexität. 4. Die Wiederherstellungsdaten schützen Ein Disaster-Recovery-Plan für die Cloud setzt nutzbare Wiederherstellungsdaten voraus. Backup-Kopien sollten daher nach Möglichkeit getrennt von den Produktivsystemen geschützt werden. Kann ein Angreifer Produktivdaten und deren Backups mit denselben Zugangsdaten oder über denselben administrativen Weg verändern oder löschen, hat die Organisation womöglich nur begrenzte Wiederherstellungsoptionen. Die Beispielorganisation nutzt mehrere Schutzebenen: Regelmäßige Backups Geografische Trennung Unveränderlichkeit von Objekten Eingeschränkter administrativer Zugriff Separate Zugangsdaten und Sicherheitsdomänen, wo sinnvoll Verschlüsselung Backup-Monitoring Regelmäßige Wiederherstellungstests Unveränderlicher Speicher kann für die Cyber-Resilienz besonders wichtig sein, weil geschützte Objekte während der konfigurierten Aufbewahrungsfrist weder verändert noch gelöscht werden können. Das bietet eine zusätzliche Wiederherstellungsoption, wenn Produktivdaten verschlüsselt, beschädigt oder absichtlich gelöscht wurden. 5. Kriterien für die Ausrufung eines Notfalls festlegen Teams müssen wissen, wann ein Vorfall zu einem Fall für die Notfallwiederherstellung wird. Beispiele für Aktivierungskriterien: Die primäre Infrastruktur bleibt voraussichtlich länger als das RTO nicht verfügbar Eine Cloud-Region hat einen erheblichen Ausfall Produktivdaten wurden beschädigt Ransomware betrifft kritische Systeme Backup- oder Speicherinfrastruktur wurde kompromittiert Ein schwerer Netzwerkausfall verhindert den Zugriff auf Produktivdienste Physische Infrastruktur ist nach einem Vorfall im Gebäude nicht verfügbar Der Plan sollte festlegen, wer befugt ist, einen Notfall auszurufen und das Failover einzuleiten. In diesem Beispiel bewertet die Einsatzleitung die Lage gemeinsam mit den Teams für Infrastruktur, Anwendungen und Sicherheit, bevor der DR-Prozess aktiviert wird. 6. Rollen für die Notfallwiederherstellung zuweisen Ein Wiederherstellungsplan sollte Zuständigkeiten festlegen, bevor ein Vorfall eintritt. RolleVerantwortungEinsatzleitungKoordiniert die Wiederherstellung und entscheidet über die AktivierungVerantwortliche für InfrastrukturStellt Rechenleistung, Netzwerk und Cloud-Infrastruktur wieder herVerantwortliche für Speicher/BackupValidiert geschützte Daten und stellt sie wieder herAnwendungsverantwortlicheÜberprüft die Funktionsfähigkeit der AnwendungVerantwortliche für SicherheitStellt fest, ob wiederhergestellte Systeme und Daten sicher sindVerantwortliche für KommunikationKoordiniert die interne und externe KommunikationExecutive SponsorTrifft Entscheidungen auf Geschäftsebene und übernimmt Eskalationen Für kritische Rollen sollten zudem Stellvertretungen benannt werden. Ein Notfall kann außerhalb der Geschäftszeiten, an Feiertagen oder dann eintreten, wenn einzelne Teammitglieder nicht verfügbar sind. 7. Der Wiederherstellungsreihenfolge folgen Sobald ein Notfall ausgerufen ist, beginnt die Organisation mit ihrem dokumentierten Runbook für die Wiederherstellung. Schritt 1: Den Vorfall bewerten Klären Sie: Welche Systeme sind betroffen? Ist das Problem betrieblicher Natur oder sicherheitsrelevant? Sind die Produktivdaten vertrauenswürdig? Sind Backup-Systeme betroffen? Lässt sich die primäre Umgebung innerhalb des geforderten RTO wiederherstellen? Bei Cybervorfällen müssen Teams kompromittierte Systeme womöglich isolieren, bevor die Wiederherstellung beginnt. Schritt 2: Einen Wiederherstellungspunkt wählen Ermitteln Sie den jüngsten verifizierten Wiederherstellungspunkt, der das geforderte RPO erfüllt. Bei einem gewöhnlichen Infrastrukturausfall ist das womöglich einfach die letzte synchronisierte Kopie. Nach Ransomware oder Datenbeschädigung wählt die Organisation womöglich bewusst einen früheren Wiederherstellungspunkt, der vor der Kompromittierung liegt. Schritt 3: Die Wiederherstellungsinfrastruktur aktivieren Stellen Sie die sekundäre Cloud-Umgebung bereit oder skalieren Sie sie. Automatisierung kann diese Phase beschleunigen, indem vordefinierte Rechen-, Netzwerk-, Speicher- und Sicherheitsressourcen angelegt werden, statt dass Administratoren sie während eines Vorfalls manuell konfigurieren müssen. Schritt 4: Die Daten wiederherstellen Stellen Sie die benötigten Datenbanken, Objektspeicher, Dateisysteme und Anwendungsdaten wieder her oder binden Sie sie an. Validieren Sie: Datenintegrität Erwartete Objekt- oder Dateizahlen Datenbankkonsistenz Berechtigungen Verschlüsselung Anwendungszugriff Schritt 5: Die Anwendungen wiederherstellen Anwendungen sollten gemäß ihren dokumentierten Abhängigkeiten und ihrer Wiederherstellungspriorität wiederhergestellt werden. Grundlegende Dienste wie Netzwerk, DNS, Identität und Speicher müssen womöglich betriebsbereit sein, bevor kundenorientierte Anwendungen korrekt funktionieren können. Schritt 6: Die wiederhergestellte Umgebung validieren Testen Sie die Umgebung, bevor Sie Benutzer umleiten. Die Validierung kann umfassen: Authentifizierung Datenbankkonnektivität Lese- und Schreibvorgänge Anwendungs-APIs Speicherzugriff Sicherheitskontrollen Monitoring Protokollierung Leistung Die Wiederherstellung sollte erst dann als abgeschlossen gelten, wenn der Dienst funktioniert und die wiederhergestellten Daten validiert wurden. Schritt 7: Den Produktivverkehr umleiten Aktualisieren Sie DNS, Load Balancer oder Routing-Richtlinien, um den Produktivverkehr an die Wiederherstellungsumgebung zu senden. Überwachen Sie die Umgebung weiter, während der Datenverkehr zurückkehrt. Schritt 8: Den Wiederherstellungsstatus kommunizieren Informieren Sie die Beteiligten über: Betroffene Dienste Aktuellen Wiederherstellungsstatus Erwartete Verfügbarkeit Mögliche Auswirkungen auf die Daten Sicherheitsaspekte Nächstes Update Kommunikationsverfahren sollten im Voraus dokumentiert und nicht erst während eines Vorfalls erstellt werden. 8. Das Failback planen Die Notfallwiederherstellung endet nicht, wenn die sekundäre Umgebung betriebsbereit ist. Irgendwann möchte die Organisation Workloads womöglich in die ursprüngliche Umgebung zurückverlagern oder eine neue primäre Umgebung einrichten. Der Failback-Prozess sollte umfassen: Neuaufbau oder Validierung der primären Umgebung Einrichtung der Replikation aus der Wiederherstellungsumgebung Synchronisierung geänderter Daten Tests der primären Umgebung Planung des Übergangs Umleitung des Datenverkehrs Überprüfung der Produktivdienste Wiederherstellung der regulären Backup- und Replikationsprozesse Das Failback sollte als kontrollierte Migration behandelt werden und nicht als automatische Umkehrung des Failover-Prozesses. Vorlage für einen Disaster-Recovery-Plan in der Cloud Organisationen können die folgende Struktur als Ausgangspunkt für ihren eigenen Plan nutzen. Informationen zum Plan Verantwortliche für den Plan:Zuletzt geprüft:Nächste Prüfung:Umfang:Primäre Umgebung:Wiederherstellungsumgebung: Wiederherstellungsziele Kritischer Dienst:Geschäftsverantwortliche:RTO:RPO:Wiederherstellungspriorität: Abhängigkeiten Abhängigkeiten der Anwendung:Abhängigkeiten beim Speicher:Abhängigkeiten im Netzwerk:Abhängigkeiten bei der Identität:Dienste von Drittanbietern: Datensicherung Backup-Häufigkeit:Backup-Standort:Replikationsverfahren:Aufbewahrungsfrist:Konfiguration der Unveränderlichkeit:Verschlüsselung:Letzter erfolgreicher Wiederherstellungstest: Aktivierung im Notfall Aktivierungskriterien:Zur Ausrufung des Notfalls befugte Person:Einsatzleitung:Eskalationskontakte: Wiederherstellungsverfahren Betroffene Systeme bewerten. Kompromittierte Infrastruktur bei Bedarf isolieren. Den passenden Wiederherstellungspunkt bestimmen. Wiederherstellungsinfrastruktur aktivieren. Geschützte Daten wiederherstellen oder anbinden. Anwendungen in der Reihenfolge ihrer Abhängigkeiten wiederherstellen. Sicherheit und Datenintegrität validieren. Funktionsfähigkeit der Anwendungen testen. Produktivverkehr umleiten. Wiederhergestellte Umgebung überwachen. Wiederherstellungsstatus kommunizieren. Maßnahmen und Ergebnisse dokumentieren. Failback-Verfahren Validierung der primären Umgebung:Prozess der Datensynchronisierung:Verantwortliche für das Failback:Verfahren zur Migration des Datenverkehrs:Validierung nach dem Failback: Tests Testhäufigkeit:Testszenario:Erwartetes RTO:Tatsächliche Wiederherstellungszeit:Erwartetes RPO:Tatsächlicher Wiederherstellungspunkt:Entdeckte Probleme:Verantwortliche für die Behebung: Wie oft sollte ein Disaster-Recovery-Plan für die Cloud getestet werden? Ein DR-Plan sollte regelmäßig und bei jeder wesentlichen Änderung der Umgebung getestet werden. Tests können mehrere Stufen umfassen. Ein Planspiel (Tabletop Exercise) führt Teams durch einen simulierten Vorfall, ohne die Produktivinfrastruktur zu verändern. Ein Wiederherstellungstest überprüft, ob geschützte Daten tatsächlich wiederhergestellt werden können. Ein Failover-Test aktiviert die Wiederherstellungsinfrastruktur und bestätigt, dass Anwendungen in der sekundären Umgebung funktionieren. Eine vollständige DR-Übung testet den gesamten Prozess, einschließlich technischer Wiederherstellung, Kommunikation, Entscheidungsfindung und Failback. Tests sollten die tatsächliche Wiederherstellungsleistung an den dokumentierten Anforderungen an RTO und RPO messen. Hat eine Anwendung ein RTO von zwei Stunden, benötigt im Test aber sechs Stunden für die Wiederherstellung, muss entweder die Wiederherstellungsarchitektur geändert werden oder das Unternehmen sein festgelegtes Ziel überdenken. Häufige Fehler bei der Planung der Notfallwiederherstellung in der Cloud Backup als gesamten DR-Plan betrachten Backups liefern Wiederherstellungsdaten. Sie definieren weder Anwendungsabhängigkeiten, Wiederherstellungsreihenfolge, Infrastrukturbereitstellung, Zuständigkeiten, Kommunikation noch Failover-Verfahren. Dasselbe RTO und RPO für jeden Workload festlegen Unterschiedliche Systeme haben unterschiedliche geschäftliche Auswirkungen. Eine Priorisierung von Workloads ermöglicht es Organisationen, Investitionen in die Wiederherstellung auf die Dienste zu lenken, die sie am meisten benötigen. Abhängigkeiten ignorieren Eine Anwendung ist womöglich technisch wiederhergestellt, aber unbrauchbar, weil DNS, Authentifizierung, Netzwerk oder ein anderer Dienst weiterhin nicht verfügbar ist. Wiederherstellungsdaten über Produktivzugangsdaten erreichbar lassen Cyberangriffe können die Backup-Infrastruktur gezielt angreifen, um eine Wiederherstellung zu verhindern. Wiederherstellungsdaten von den Zugangswegen der Produktion zu trennen, kann dieses Risiko verringern. Annehmen, dass Replikation das Backup ersetzt Replikation kann Änderungen schnell zwischen Umgebungen übertragen, auch unerwünschte. Beschädigungen oder böswillige Löschungen können sich daher auf das Replikat ausbreiten. Unabhängige Wiederherstellungspunkte bieten eine weitere Option, wenn der jüngsten Kopie nicht vertraut werden kann. Wiederherstellungen nicht testen Ein erfolgreicher Backup-Job bestätigt, dass Daten geschrieben wurden. Wiederherstellungstests zeigen, ob die Organisation die Daten tatsächlich wiederherstellen und im geforderten Zeitraum nutzen kann. Cyber-Resilienz in die Notfallwiederherstellung in der Cloud einbauen Die klassische Planung der Notfallwiederherstellung konzentrierte sich oft auf Infrastrukturausfälle. Heutige Pläne müssen auch Situationen berücksichtigen, in denen die Infrastruktur weiterläuft, die Daten selbst aber nicht verfügbar oder nicht vertrauenswürdig sind. Ransomware ist ein gutes Beispiel. Ein einfaches Failover in eine andere Umgebung löst das Problem womöglich nicht, wenn verschlüsselte oder beschädigte Daten bereits dorthin repliziert wurden. Eine cyber-resiliente Wiederherstellungsstrategie sollte daher Verfügbarkeit mit Kontrollen zur Datensicherung verbinden, etwa unveränderlichem Speicher, getrennten Zugriffswegen, mehreren Wiederherstellungspunkten und getesteten Wiederherstellungsverfahren. Insbesondere bei Objektdaten kann Unveränderlichkeit bekannte Wiederherstellungspunkte bewahren, indem sie verhindert, dass geschützte Objekte während ihrer Aufbewahrungsfrist verändert oder gelöscht werden. Scality ARTESCA bietet Objektspeicher für Backup und Cyber-Resilienz, einschließlich Funktionen für die Unveränderlichkeit von Daten, die Organisationen beim Aufbau geschützter Wiederherstellungs-Repositories unterstützen. Die Speicherschicht kann Teil einer umfassenderen Architektur für die Notfallwiederherstellung sein, zusammen mit Backup-Software, Cloud-Infrastruktur und dokumentierten Wiederherstellungsprozessen. Vom Beispiel für einen Disaster-Recovery-Plan zur betrieblichen Einsatzbereitschaft Ein Disaster-Recovery-Plan für die Cloud sollte letztlich eine Reihe praktischer Fragen beantworten: Welche Systeme müssen zuerst wiederhergestellt werden, wie schnell müssen sie zurück sein, wie viel Datenverlust ist akzeptabel, wo liegen vertrauenswürdige Wiederherstellungsdaten und wie genau stellen die Teams die Dienste wieder her? Das obige Beispiel bietet einen Ausgangsrahmen, doch der endgültige Plan sollte die Anwendungen, Abhängigkeiten, Sicherheitsanforderungen und geschäftlichen Prioritäten jeder Organisation widerspiegeln. Erst regelmäßige Tests machen aus dokumentierten Verfahren eine messbare Wiederherstellungsfähigkeit. Durch den Vergleich tatsächlicher Wiederherstellungsergebnisse mit den RTO- und RPO-Zielen können Organisationen Lücken erkennen und Infrastruktur, Datensicherungsstrategie und Wiederherstellungsprozesse im Lauf der Zeit anpassen.
