Je stärker Geschäftsprozesse in Unternehmen von der IT abhängen, desto wichtiger wird auch eine Vorbereitung gegen mögliche Störungen und Ausfälle. Denn steht erst einmal die IT, so drohen massive Geschäftsunterbrechungen, Produktionsausfälle und in der Folge auch Reputationsschäden.
Einer Studie des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zufolge gehen insbesondere mittelständische Unternehmen nachlässig mit diesem Risiko um. Demnach befasst sich derzeit nur knapp die Hälfte der mit dem Notfall-Management.
Dabei scheint es sich keinesfalls um reine Ignoranz vor realen Szenarien zu handeln, sondern hier drückt sich die Angst vieler Entscheider vor enormen Investitionen in redundante Rechenzentrumskapazitäten aus, wie Udo Böhm, Senior Consultant bei der SHD System-Haus-Dresden GmbH, erläutert: "Viele Unternehmen befürchten enorme Kosten bei einer Notfallinfrastruktur und weichen dann lieber auf simple Backup-Verfahren aus. Dabei übersehen sie, dass man mit Backups den Betriebszustand keinesfalls schnell wiederherstellen kann und sich im schlimmsten Fall mehrere Wochen IT-Ausfälle einhandelt."
Dass Rechenzentren komplex und teuer sind, ist unbestritten, und daher lautet die zentrale Frage beim Thema Notfallschutz: Welchen Aufwand muss ein Unternehmen betreiben, um eine Lösung zu erhalten, bei der die Ausfallsicherheit in einem angemessenen Verhältnis zum potenziellen wirtschaftlichen Schaden steht. Bei der Suche nach einer entsprechenden Lösung sollte der Grundsatz gelten, dass ein optimaler Notfallschutz das Schadensrisiko unternehmerisch ausreichend abdeckt - zu angemessenen Kosten für die Notfallvorsorge.
Was umfasst ein vollständiger IT-Notfallschutz?
Wie IT-Notfallschutz rein formal aufgebaut sein sollte, beschreiben das Informationssicherheits-Managementsystem (ISMS) nach ISO 27001 oder das Notfall-Management-System nach BSI Standard 100-4. Darin werden Verfahren und Regeln sowie die erforderlichen IT-Ressourcen für den IT-Wiederanlauf nach einem Notfall skizziert. Zu diesen Ressourcen zählen beim vollständigen IT-Notfallschutz insbesondere ein RZ-Failover-Standort mit einer geeigneten Anbindung für den Regel- und Notfallbetrieb, Spiegel- oder Replikationsprozesse für Daten und Anwendungen sowie Standby -Ressourcen wie Server, Storage, Netzwerke und IT-Personal.
Primäres Ziel nach einem Notfall ist es, die Zugriffsfähigkeit von Nutzern und gegebenenfalls Produktionsanlagen auf IT-Services und Daten im Notfall- Rechenzentrum innerhalb einer vorgegebenen RZ-Wiederanlaufzeit zu ermöglichen.
Schaden durch Ausfall gegenüber Kosten für Notfallvorsorge
Foto: SHD Dresden
Zur Ermittlung des individuellen Unternehmensrisikos empfiehlt sich eine "Business Impact Analyse" (BIA). Damit lässt sich ausrechnen, wie hoch der Schaden für das Unternehmen ausfällt, abhängig von der Länge eines IT-Ausfalls. Aus dem daraus resultierenden Graphen können Entscheider ablesen, wie wichtig Notfallmaßnahmen sind und welche Notfallstrategie gewählt werden soll.
Sobald der konkrete Geschäftsschaden ermittelt ist, der bei einem Ausfall droht, kann auch mit der Entscheidungsfindung für die angemessene Notfall-Vorsorge begonnen werden. Dabei legt man beispielsweise einen rechnerischen Schaden über einen Zeitraum von fünf Jahren zugrunde und kalkuliert daraus einen durchschnittlichen monatlichen Schadensbetrag. Dieser lässt sich nun vergleichen mit den monatlich anfallenden Kosten, die mit einer jeweiligen Data-Center-Notfallarchitektur anfallen. Grob vereinfacht hängt die Höhe der Notfallkosten dabei von der Wiederanlaufzeit des Data Center (RTO, Recovery Time Objective) ab. Je kürzer die Unterbrechung, desto teurer sind die vorsorgenden, redundanten Maßnahmen.
Vier RZ-Typen mit unterschiedlichen Wiederanlaufzeiten
Die Entscheidung für eine geeignete Notfall-RZ-Architektur richtet sich ganz nach der maximal tolerierbaren RZ-Ausfallzeit. Nützlicher Nebeneffekt einer damit verbundenen Analyse ist für Entscheider übrigens, dass sie aus den einzelnen Werten die Abhängigkeit der jeweiligen Prozesse von der IT ablesen können. Folgende vier gängige Varianten für Notfall-RZ-Architekturen stehen zur Verfügung:
Foto: SHD Dresden
Active RZ: Kommt überwiegend in großen Banken und Versicherungen zum Einsatz, um maximale Ausfallsicherheit zu gewährleisten. Charakteristisch sind unter anderem fehlertolerante Anwendungs-Cluster, die Datenverlust ausschließen.
Hot Standby RZ: Verfügt meist über synchrone Datenspiegelung zwischen den RZ sowie eine breitbandige Layer 2-LAN-Verbindung. Der Zugriff von Clients auf beide RZ erfolgt bei einem Schwenk transparent - also vom Anwender unbemerkt. Sofern der Abstand zwischen beiden RZ größer als fünf Kilometer (BSI-Empfehlung) beträgt, lässt sich ein Hochverfügbarkeitsrechenzentrum (HA-RZ) gleichzeitig als Notfall-Rechenzentrum einstufen.
Warm Standby RZ: Per asynchroner Datenreplikation über IP-WAN-Verbindungen kann überregionaler Notfall-Schutz über hunderte von Kilometern gewährleistet werden. Die optimale Warm Standby-Anlaufzeit beträgt acht bis 12 Stunden. Sie ist aber nur erreichbar, wenn die Server-Umgebung des Unternehmens voll virtualisiert ist, die Wiederanlaufprozesse automatisiert und zyklisch getestet sind und die Server der DMZ-Umgebung sowie das Regelwerk der Firewall in das Notfall-RZ repliziert werden. Ohne Automatisierung sind oft Wiederherstellungszeiten von mehreren Tagen nötig.
Cold Standby: Hier steht bei einem Colocation-Provider für den Notfall lediglich eine vertraglich vereinbarte Ausweichrechenzentrumsfläche zur Verfügung (Rackspace, Klima, Strom, Internet-Anschluss).
Warm Stand-by und Automatisierung
Um ein Warm Standby-Rechenzentrum möglichst effizient zu nutzen, empfiehlt Böhm umfassende Automatisierungsschritte: "Wer hier die erforderlichen Abläufe automatisiert, kann sich zeitraubende Konfigurationsanpassungen beim Failover - also beim Umschalten auf den Notbetrieb in das Warm Standby-RZ, sparen. Das beschleunigt den Prozess und eliminiert mögliche Fehler beim Wiederanlauf." Die Automatisierung ist auch noch aus zwei anderen Gründen hilfreich: So wären ohne sie die regelmäßigen Tests der Notfalllösung aufwändig und somit unrentabel. Und sie ermöglicht auch eine optionale, zyklische Nutzung der Infrastruktur als Sandbox-Testumgebung, beispielsweise bei komplexen Softwareweiterentwicklungen.
Foto: SHD Dresden
Zu berücksichtigen ist bei der Option "Warm Standby" noch ein prinzipbedingtes Risiko von Datenverlusten. Dazu muss man die Funktionsweise kennen: Ähnlich wie beim klassischen Backup findet hier eine einmalige, nächtliche Replikation von Datenänderungen in das Notfall-RZ statt. Das spart Kosten, da man nächtliche Backupfenster und ungebrauchte Internet-Kapazitäten nutzt. Im schlimmsten Fall kann dabei aber ein maximaler Datenverlust von bis zu einen Arbeitstag entstehen. Abmildern lässt sich das, falls erforderlich, mit häufigeren Datenreplikationen pro Tag.
Outsourcing-Partner liefern fehlende Notfall-Bausteine
Für die Notfallvorsorge liefern inzwischen etliche IT-Anbieter fertige Lösungen, die Backup, Replikation und Wiederherstellung von virtuellen Servern abdecken. Anwenderunternehmen können damit in jedem Fall die Grundanforderungen abdecken, doch werden sie nicht alle höheren Sicherheitsanforderungen erfüllen können. Mit Soft- und Hardware alleine ist beispielsweise das Problem eines sicheren RZ-Standorts nicht zu lösen. Zudem dürfte der Aufwand für eine schnelle Bereitstellung kostengünstiger Ressourcen wie Server, Storage, Prozesse und Personal für Standby-RZ und den Betrieb im Notfall für ein einzelnes Unternehmen meist zu hoch sein.
Fazit
Dank der Virtualisierung von IT-Ressourcen wie Servern, Anwendungen und Netzwerken ist heute ein vergleichsweise kostengünstiger IT-Betrieb möglich. Gleichzeitig ermöglichen virtuelle Infrastrukturen die Umsetzung angemessener und vergleichsweise kostengünstiger IT-Notfall-Strategien. Ob ein Unternehmen solche sekundären RZ-Basis-Infrastruktur-Services für die Notfallvorsorge und die Notfallbewältigung selbst betreibt oder es einem spezialisierten Service-Provider überlässt, ist letztlich nicht nur eine Kosten-, sondern auch eine Vertrauens- und IT-Strategie-Entscheidung.