Cloud oder zweites Rechenzentrum? Damit ein IT-Notfall nicht zur Katastrophe wird.

"Weiter, immer weiter", hat Torwart-Legende Oliver Kahn 2001 wenige Tage nach der Last-Minute-Meisterschaft seines Vereins und noch vor dem Gewinn der Champions League seine Einstellung zusammengefasst. "Weiter, immer weiter", könnte aber auch das Motto für IT-Verantwortliche lauten, wenn sie sich mit der Planung von Szenarien für Business Continuity & Disaster Recovery beschäftigen. Beide Aufgaben sind nicht so glamourös wie Titelgewinne im Fußball. Angesichts der zunehmenden Bedeutung von IT für alle Geschäftsprozesse sind solide Notfallpläne jedoch eine unabdingbare Voraussetzung, damit es wenigstens irgendwie weiter geht.

Allerdings herrscht hier erheblicher Nachholbedarf. Laut den Ergebnissen einer aktuellen Bitkom-Umfrage hat nur rund jedes zweite Unternehmen in Deutschland einen Notfallplan mit schriftlich geregelten Abläufen und Ad-hoc-Maßnahmen für den Fall von Datendiebstahl, Spionage oder Sabotage. Solche Abläufe schriftlich zu regeln, ist unabdingbar. Aber um verifizieren zu können, ob der Notfallplan auch wirkt, sollte man ihn regelmäßig in festgelegten Intervallen testen.

Tendenziell sind kleine Unternehmen hierbei schlechter aufgestellt als große. So hat von den Firmen mit bis zu 99 Beschäftigten gerade etwas mehr als die Hälfte einen Notfallplan, bei Firmen mit mehr als 500 Beschäftigten sind es immerhin 78 Prozent. Fragt man aber nach, wann der Notfallplan zuletzt erfolgreich getestet wurde und welche Maßnahmen bzw. Verbesserungen festgelegt wurden, kommen in vielen Fällen keine detaillierten Ablaufpläne oder Protokolle zum Vorschein.

Dabei empfiehlt auch das BSI ein Notfallhandbuch, das zumindest Geschäftsfortführungs- und Wiederanlaufpläne, die "Handlungsschritte für die Wiederherstellung oder den Wiederanlauf wichtiger Ressourcen" umfassen. Mit dem BSI-Standard 100-4 erteilt das Bundesamt zudem Empfehlungen für ein systematischeS Notfallmanagement. Soweit die organisatorischen Ratschläge. Wie sieht es aber mit der technischen Umsetzung in der Praxis aus? Und welche Kosten kommen auf Unternehmen zu? Können sie sich die empfohlene Absicherung überhaupt leisten?

Der Katastrophenfall muss eingeplant werden

Wer früher Disaster Recovery ernst genommen hat, kam nicht umhin, eine identische Infrastruktur für den Fall der Fälle vorzuhalten. Mit zusätzlichem Aufwand, entsprechender Expertise und der erforderlichen Software ließ sich aus einem "Cold Standby" ein "Hot Standby" machen. Bei ersterem blieben die Ressourcen für den Notfall bis zu dessen Eintritt ungenutzt und es war eine längere Anlaufzeit einzurechnen. Beim Hot Standby wurde die Notfallreserve bereits im laufenden Betrieb mitgenutzt und Verantwortliche konnten gegebenenfalls schnell auf sie umschalteten. Allerdings sind beide Varianten sehr kapitalintensiv.

Die Hoffnung, auf Infrastruktur für den Notfall verzichten zu können, weil der nie eintritt, ist heute vergeblich. Expert*innen sind sich einig, dass es trotz guter Vorbereitung und umfassender Sicherheitsmaßnahmen nicht mehr die Frage ist ob, sondern nur noch, wann ein Unternehmen einem Angriff zum Opfer fällt.

Eine zusätzliche Dimension haben diese Angriffe durch die Zunahme von Ransomware-Attacken bekommen: Sie legen nicht nur Teilbereiche des Unternehmens lahm, sondern die gesamte Organisation, wie zahlreiche Beispiele aus der jüngeren Vergangenheit dramatisch verdeutlichen. Notfallplanung ist damit nicht ein "Nice-to-have", sondern absolute Pflicht.

Zeit und Daten sind Geld

Eine seriöse Notfallplanung setzt allerdings voraus, dass nicht nur definiert wird, was zu tun ist, sondern auch, wie lange es dauern darf, bis bestimmte Dienste wieder verfügbar sind. Dazu müssen sich Unternehmen überlegen, was "Business Continuity" für sie bedeutet. In manchen Firmen verursacht eine Unterbrechung bestimmter Geschäftsprozess für wenige Minuten schon großen Schaden, andere können ihren Geschäftsbetrieb aus Sicht der Kunden auch dann noch durchgängig anbieten, wenn bestimmte Services für mehrere Stunden ausfallen.

Hierfür haben sich die Begriffe RTO (Recovery Time Objective) und Recovery Point Objective (RPO) etabliert. RTO beschreibt, wie lange eine Anwendung, ein System oder ein Prozess ausfallen darf, ohne dass ein signifikanter Schaden für das Unternehmen entsteht und wie lange es dauert, bis die Anwendung und deren Daten wird hergestellt sein müssen. RPO gibt dagegen die Menge an Daten an, die bei einem Schadensereignis verloren gehen darf. Sie hängt in der Regel davon ab, wie lange das letzte Backup zurück liegt, das für die Wiederherstellung herangezogen werden kann.

BCDR mit Microsoft Azure?

Cloud-Technologie ermöglicht schnelle Wiederherstellung und kurze Backup-Intervalle - und bietet damit die Möglichkeit, die entscheidenden Werte für RTO und RPO zu senken, weil Infrastruktur nicht mühsam beschafft, implementiert und betrieben werden muss, sondern bedarfsgerecht hinzugebucht werden kann. Speziell in Microsoft Azure kommt hinzu, dass viele weitere zentrale Aspekte von Business Continuity und Disaster Recovery mit abgedeckt sind. Zum Beispiel hilft Microsoft Azure Active Directory dabei, dass nach dem Notfall alle Berechtigungen und Zugriffsrechte wieder wie gewohnt zur Verfügung stehen. Ein weiteres Beispiel ist Azure Migrate, ein kostenloses Tool für Unternehmen, um Server, Anwendungen und Abhängigkeiten zwischen Anwendungen zu identifizieren und zu analysieren. Sie verstehen so, welche Applikationen für ein Disaster Recovery bereit sind und bei welchen nachgebessert werden muss.

Eine Einführung in wichtige Aspekte bei der Planung von Business Continuity und Disaster Recovery sowie Empfehlungen zum Aufbau einer Strategie dafür bietet folgendes Whitepaper.

Sorgen Sie für mehr Resilienz