Was für ein Desaster! Konzepte zur Krisenbewältigung

Desaster Recovery: Ein Drama in vier Akten

Bild 2: Die Wiederherstallung aus Prozesssicht.

Wunsch und Wirklichkeit

Kommen wir zurück zur IT-Sicherheitsstrategie, die jedem datenverarbeitenden Unternehmen als Konzept vorliegen sollte. Ein Konzept, das sich wiederum an den unternehmensspezifischen Maximen für Datenverfügbarkeit, Datensicherheit und Wirtschaftlichkeit orientiert. Wie lange darf uns eine Katastrophe aus wirtschaftlicher Sicht ausknocken? Das ist die zentrale Frage, die sich die Geschäftsführung beantworten muss. Hier greift für Desaster Recovery der Begriff „Maximum Acceptable Outage“ (MAO) aus der Betriebswirtschaftslehre. Er bezeichnet die maximale Ausfallzeit für Geschäftsprozesse oder Servicefunktionen, die das Unternehmen akzeptieren kann, bevor geschäftskritische Konsequenzen drohen. So definiert ein Versicherungskonzern als fiktives Beispiel maximal 24 Stunden Datenverlust als Risiko und begrenzt die höchstmögliche Wiederherstellungszeit auf drei Tage. Damit MAO kein Hoffnungsszenario bleibt, sondern die Realität wiederspiegelt, muss das Konzept Umfang und Kosten aller Maßnahmen klar benennen.

Daten sichern und Daumen drücken

Im Rahmen von DR spielt der Begriff „Recovery Point Objective“ (RPO) eine große Rolle. Er meint die Zeitspanne zwischen dem letzten Backup und dem maximal entfernt liegenden Zeitpunkt, bis zu dem Daten aufgrund eines Ausfalls verloren sein dürfen. Auch RPO ist akzeptanzgetrieben und variiert: Je höher Datenverfügbarkeit und Datensicherheit im Unternehmen aufgehängt sind, desto schmaler ist die RPO. Ist gar kein Datenverlust bei einem Systemausfall tolerabel, beträgt die RPO demnach null Sekunden.

Basis bereiten

Ist eine Katastrophenmeldung beim Management angekommen, folgen laut Zeitstrahl Maßnahmen zur Wiederherstellung des Geschäftsbetriebs. Zum Startpunkt der Wiederherstellung (im Zeitstrahl gelb markiert) steht der Umfang des potenziellen Datenverlustes fest, der nach dem Ereignis aufgetreten ist. Nun wird aufgeräumt: Die Phase „Recovery Time Objective“ (RTO) meint nach Verständnis von Gronau IT exakt die Wiederherstellungszeit, in der Geschäftsfunktionen, Systeme und IT-Services so vorbereitet sind, dass die IT-Mitarbeiter ihr Wiederherstellungsverfahren einleiten können.

Neustart

In der nächsten und finalen Etappe folgt die „Work Backlog Recovery“ (WBL), also die aufwandreiche Zeit zur Wiederherstellung des Ursprungszustands. Dazu gehören alle Arbeiten, die Transaktionen und Daten aus der Pre-Desaster-Ära wiederherstellen. Eine Aufräumzeit, die unterschiedlich lange dauert und zu deren Ende alle Daten wieder aufgespielt sind und dem Business wieder zur Verfügung stehen.

Rechenzentrumswahl als Risikominimierung

Desaster Recovery ist eine Teildisziplin von Business Continuity Management (BCM), also eines Prozesses, der Konzepte zur Aufrechterhaltung des Geschäftsbetriebs entwirft und implementiert. Diese Konzepte sollen Unternehmen auf Störungen vorbereiten, diese minimieren und managen. Sie sind personenunabhängig, nicht aber rollenunabhängig. BC-Konzepte enthalten Ablaufpläne für eintretende Katastrophe, die auch greifen, wenn der zuständige IT-Mitarbeiter nicht anwesend oder nicht mehr im Unternehmen beschäftigt ist.

Bei der Reduzierung von Stör- und Katastrophenrisiken im Rahmen von BCM spielt die Wahl des passenden Rechenzentrums eine große Rolle. Dabei gilt zu beachten, dass ein singuläres Rechenzentrum zwar Hochverfügbarkeit von Daten durch zwei physisch getrennte Brandschutz-Bereiche bereitstellen kann, aber keine Desaster Recovery-Funktionen aufweist. Um diese Lücke zu schließen, bieten sich folgende, kombinierbare Optionen an:

• DR als Cloud Service, gekoppelt an leicht skalierbare und kostengünstige Standby-Komponenten
• DR an einem zweiten, eigenen geeigneten Rechenzentrumsstandort
• DR mit einem Colocation-Partner in kurzer Entfernung, so dass im Unterschied zu den anderen Optionen synchrone Datenreplikation möglich ist
• DR mit einem über 200 km georedundante Colocation-Partner

IT-Entscheider sollten Vor- und Nachteile der aufgeführten Wahlmöglichkeiten individuell abstimmen. Jedoch existieren Mindestanforderungen an digitale und physische Sicherheit sowie an Kommunikationswege eines Rechenzentrums, die erfüllt sein sollten, wenn es Desaster Recovery leisten soll:

• Mindestens Klasse Tier III
• EN 50600 Zertifizierung
• Überwachungs- und Alarmempfangszentrale gemäß EN 50518
• Minimale Bandbreitenkonnektivität von mindestens je 2 x 1 Gbit/s an jedem Standort für das Internet
• Mindestens 2 x 10 Gbit/s Konnektivität für die Wege Rechenzentrum zu DR Rechenzentrum mit einer Latenzzeit <= 30 ms
• Mindestens zwei verschiedene redundante Kommunikationswege
• Jeder Kommunikationspfad muss von einem anderen Carrier über verschiedene redundant ausgelegte Leitungen stammen
• Wenn ein Rechenzentrum auch als Desaster Recovery-Rechenzentrum eines weiteren Rechenzentrums verwendet wird, müssen die Kommunikationsleitungen physisch getrennt sein
• Kommunikationswege müssen nach höchsten Standards verschlüsselt werden, also zum Beispiel nicht nur MPLS
• Asynchrone, verschlüsselte Datenreplikation darf einen maximalen Versatz von einer Stunde aufweisen
• Automatische Umleitung für angeschlossene Rechenzentren und deren Partner (Routen)
• Ein Fernzugriff bei Desaster Recovery sollte über einen zusätzlichen separaten Kommunikationspfad eingerichtet werden. Alle Zugriffsmöglichkeiten müssen autonom von den Zugriffspfaden weiterer angeschlossener Rechenzentren sein

Kontrolle ist besser

Wenn Desaster Recovery als funktionierender Baustein von Betriebskontinuitätsmanagement funktionieren soll, müssen Unternehmen bei gewohntem Betrieb mindestens jährlich DR-Failover-Tests und Wiederherstellungstests durchführen. Mit diesen IT-Feuerwehrübungen zeigt sich, wie lange es zumindest ohne großen Stress dauert, das Rechenzentrum umzuschalten und den Betrieb wieder aufzunehmen. Sobald darüber hinaus größere Software-Upgrades im Zusammenhang mit der Datensicherung stattfinden, müssen diese Tests direkt nach dem Upgrade erfolgen. Dabei ist unerlässlich, dass alle CMDB -Informationen in jedem Rechenzentrum vorliegen, die in Desaster Recovery eingebunden sind.