Ein Blick in die Medien genügt, um zu begreifen, dass das Thema der sogenannten "IT Desaster Recovery" eine neue Dimension erreicht hat. Bisher war dies ein vorwiegend technischer Aspekt, der mit der Anschaffung von USV-Anlagen und der Einführung einiger Prozesse rasch zu den Akten gelegt wurde. Bei diversen Einsparungsprogrammen wurden sicherlich auch mal Tests nicht durchgeführt, bei Wartungen gespart und empfohlene Batterie-Lebensleistungen künstlich verlängert. Mittlerweile sind die Gefahren vielschichtiger geworden und die Auswirkungen existenzbedrohend. Das gilt gerade für mittelständische Unternehmen.
Es herrscht immer das Bestreben, sich vor einer Naturkatastrophe, vor IT-Security-Vorfällen und einem technischem Ausfall bestmöglich zu schützen. Die Schlagworte "Resilienz und Redundanz" sind allgegenwärtig und Stand der Technik, auch wenn es öfter vorkommt, dass dieser Zustand nur theoretisch vorherrscht. Die zentrale Frage ist aber, welcher Budgetanteil in die Krisenprävention und wie viel in das tatsächliche Katastrophenmanagement investiert wird. Implizit wird angenommen, dass USV-Geräte, redundante Leitungen und treibstoffbetriebene Systeme dafür sorgen, dass ein Ausfall nicht stattfinden kann oder die Notsituation in einem überschaubaren Zeitraum behoben ist. Womöglich ist das ein spekulativer Trugschluss, wie die Realität gelehrt hat.
Die Werkzeuge im Krisenfall
Bisher war Stand der Technik, dass verschiedene Hersteller ihre Lösungen mit Analyse- und Managementfähigkeiten ausgestattet haben. Die USV-Lieferanten überwachen die Batteriesysteme, die Serverfarmen und Netzwerke werden genauso im Auge behalten wie virtuelle Umgebungen. Nun ist es aber im Krisenfall notwendig, automatisierte Prozesse ablaufen zu lassen, die eine ganzheitliche Sicht und nicht nur ein Monitoring erlauben, sondern zudem ein konkretes Eingreifen ermöglichen.
Das bedeutet nichts anderes, als auf Knopfdruck ein Rechenzentrum herunterzufahren oder aus bestimmten Brandabschnitten Daten zu evakuieren. In Zukunft wird es notwendig sein, flexibel agieren zu können, Fehler zu vermeiden und ruhigen Gewissens auch einen Desaster-Recovery-Test durchführen zu können, wenn die Auditoren dies verlangen.
Krisenmanagement - von A wie Alarmierung…
Viele Unternehmen und Organisationen haben sich mit ausgetüftelten Notfallhandbüchern und entsprechenden Prozessen auf die Stunde X vorbereitet, aber mit einem tagelangen Ausfall wird dennoch kaum gerechnet. Im Trockentraining werden unter theoretischen Annahmen und kaum realen Bedingungen Desaster-Tests durchgeführt, um auch die Auditoren der Revisionsabteilung und die Wirtschaftstreuhänder zufriedenzustellen. Außerdem gibt es vertragliche Werkzeuge, von der gesicherten Treibstoffversorgung bis hin zur Personalbereitstellung, an die gedacht wurde. Im nächsten Schritt beginnen bereits die ersten Unwägbarkeiten wie Vereinbarungen mit Stromlieferanten, die sich gerne schadlos halten und Haftungen genauso ausklammern wie Versicherungen. Und wer denkt an Feldbetten und Nahrungsversorgung für die IT-Mannschaften nach den ersten acht oder zehn Stunden?
Zudem befindet man sich rechtlich bereits im kreativen Raum, denkt man an Begriffe wie "Höhere Gewalt" und an die Definition von Fahrlässigkeit in allen Facetten. Tritt nun ein Elementarereignis oder technischer Schadensfall ein - oft genügt dafür schon ein Fehlalarm eines Sensors -, sollte eine Alarmierungskette in Gang gesetzt werden, die automatisiert abläuft und die Vorgänge dokumentiert. Sprich: Es bedarf einer Applikation. Diese sammelt Alarme aus vorhandenen Monitoring-Lösungen, verarbeitet diese und informiert abgesichert die Verantwortlichen via E-Mail, SMS und Voice, also über das Mobilfunknetz oder andere redundante Wege.
… bis Z wie zentrales Power-Management
Eine Applikation, die physikalische Kontakte und Sensoren genauso im Griff hat wie USV-Geräte und virtualisierte Anwendungen, ist das einzig sinnvolle Werkzeug, das in der Krise operative Maßnahmen durchführen sollte. Diese Software muss selbst abgesichert sein, als letzte Anwendung herunter-, aber auch als erste wieder hochfahren, um dann die Logik ausführen zu können, die vor dem Krisenfall definiert wurde. Gerade der geregelte Wiederanlauf ist für viele Spezialisten die eigentliche Herausforderung, weil die IT-Infrastruktur ein mehrmaliges Hochfahren nicht tolerieren und mit Sicherheit Schaden nehmen würde. Somit kann es auch in verschiedenen Szenarien möglich sein, die Infrastruktur davon "abzuhalten, sich wieder zu aktivieren". Kurz hintereinander auftretende Stromausfälle, aus welchen Gründen auch immer, können tödlich sein - und dann wäre womöglich das tatsächliche Ende des Unternehmens besiegelt.
Ein zentrales Power-Management kann für Wartungsfenster genauso genutzt werden wie für Desaster-Recovery-Tests und zur Abbildung von Katastrophenszenarien, die auch von internationalen Standards eingefordert werden. Neue Hardware oder Änderungen in wichtigen Konfigurationen sollten erkannt und eine Meldung generiert werden, damit eine Klassifizierung oder Gruppenzuteilung erfolgen kann. Natürlich müssen auch virtuelle Anwendungen, die physikalisch oft schwer zu lokalisieren sind, der richtigen Hardware zugeordnet werden können, wenn es um die Frage geht, ob dieser oder jener Server heruntergefahren oder "live-migriert" werden sollte, weil Gefahr drohen könnte.
Typische Fehler bei Desaster-Recovery-Szenarien
Die klassischen Fehler bei Desaster-Recovery-Tests sind leider oft anzutreffen. Ein ungutes Gefühl ist häufig ausschlaggebend, dass diese gar nicht durchgeführt oder an einem ruhigen Sonntag geplant werden: Natürlich stimmt dann auch die Last der USV-Geräte nicht mit der Realität überein, die Tests sind oft zu kurz angesetzt oder werden einzeln durchgeführt, wobei sich auch Fehler einschleichen können. Unterschiedliche Hardware kann dazu führen, dass manche Geräte schneller herunter- oder hochfahren als andere und sich somit der Ablauf ad absurdum führt, sodass Anmeldeprozesse fehlschlagen und Zeit verschwendet wird.
In der Realität ist es aber oft so, dass die IT-Landschaften dermaßen rasch wachsen und sich verändern, dass ein Status nicht erhoben werden kann und das "operative Managementwerkzeug" nicht vorhanden ist, um nach einer erfolgreichen Simulation mit einigen Klicks das ganze Unternehmen vom Netz zu nehmen oder Teile davon "zu verschieben". Natürlich gibt es auch immer wieder Tüftler, die eigene Programme schreiben. Diese übersehen dabei jedoch, dass die Programme permanent gewartet werden müssen und sich auch besser kein Denk- oder Skriptfehler einschleichen sollte. Spätestens nach dem Jobwechsel des Mitarbeiters steht das Unternehmen wieder ohne standardisierte Ablaufplanung am Anfang der Überlegungen.
Manche Aspekte wie Sabotage oder Diebstahl werden sowieso ausgeblendet, auch wenn Treibstoff- und Kabeldiebe längst zur Gewohnheit geworden sind. Auch sollen Fehler bei Lizenzierungen schon vorgekommen sein, die dafür verantwortlich sind, dass ein Zugriff nicht möglich ist oder dass auch Passwörter gelegentlich geändert werden - wie es die IT-Security-Mitarbeiter stets einfordern. Das Thema ist sehr komplex und von vielen Unwägbarkeiten bestimmt, sodass die Prozesse und Abläufe unbedingt automatisiert ablaufen sollten. Im Notfall muss die IT-Abteilung binnen weniger Minuten die richtigen Entscheidungen treffen können und somit auch das Tool dafür in der Hand haben, es auch tatsächlich schaffen zu können.
Umfassende IT-Security ist Pflicht
Die gängigen Überlegungen, die Sicherheitslöcher und Virenausbrüche verursachen können, umfassen natürlich hohe finanzielle Schäden, Imageverluste und hohen Aufwand für Reparaturarbeiten bis hin zur Industriespionage. Somit sind Datendiebstahl, Erpressungsversuche und mögliche Veröffentlichungen der PR-Super-Gau jeder Geschäftsführung und IT-Verantwortlichen. In Wahrheit ist das aber erst der Beginn der möglichen Schmerzen, die Eindringlinge verursachen können: Von der unbemerkten Datenmanipulation über Stromabschaltungen bis hin zu unzähligen Fehlalarmen können die Maßnahmen reichen, die Ex-Mitarbeiter oder ideologische Gegner im Schilde führen.
Darum ist es nicht nur wichtig, bei Sicherheitslösungen auf dem Stand der Technik zu sein, sondern auch, die Tools zu haben, um mit unorthodoxen Mitteln dagegenzuhalten. Dies sollten HoneyPot-Systeme genauso sein wie integrierte Log- und Event-Management-Lösungen oder File-Integrity-Monitoring-Tools, die Änderungen in Systemen feststellen können. Im Idealfall sind diese untereinander vernetzt und agieren als Module in einer IT-Crisis-Plattform - inklusive Alarmierung und der vorgestellten zentralen Power-Management-Lösung. (hal)