Tabletop Tuesday

Brand im Datacenter

Wenn die IT in Flammen steht

Willkommen zu einer neuen Ausgabe von "Tabletop Tuesday"! Heute konfrontieren wir Sie mit einem Szenario, das jede IT-Abteilung fürchtet: einem physischen Desaster. Ein Brand bricht in dem externen Rechenzentrum aus, in dem Ihr Unternehmen mehrere Racks für seine Kerninfrastruktur eingemietet hat. Systeme fallen aus, Informationen sind spärlich und die Frage ist nicht, ob Sie ein Problem haben, sondern wie groß es ist.

Diese Übung testet nicht die Abwehr eines Cyberangriffs, sondern die fundamentalen Säulen Ihrer IT-Resilienz: Ihr Wissen über Ihre eigene Infrastruktur, Ihre Notfallpläne (Business Continuity / Disaster Recovery) und Ihre Fähigkeit, unter extremem Druck aus dem Nichts wieder aufzubauen.

Phase 1: Der Anruf "Es gibt einen Vorfall..." 🔥

Szenariobeschreibung (Teil 1):

Es ist Sonntagabend, 22:30 Uhr. Der diensthabende Administrator der IT-Infrastruktur erhält einen Anruf von einer unbekannten Nummer. Es ist der Schichtleiter des Rechenzentrumsanbieters "ProSecure Datacenter GmbH". Er klingt gestresst und informiert hastig: "Es gab einen Brand in Trakt B, Brandabschnitt 4. Das Feuerlöschsystem wurde ausgelöst. Aus Sicherheitsgründen ist der gesamte Trakt B stromlos geschaltet. Wir haben derzeit keinen Zugang und keine weiteren Informationen über den Zustand der Hardware. Wir melden uns, sobald wir mehr wissen." Kurz darauf fallen die ersten Monitoring-Alarme für eine Reihe von internen Systemen aus.

Diskussionspunkte und Kernfragen für Ihr Team:

Alarmierung und Eskalation:
- Wer steht auf der Notfallkontaktliste für einen solchen Vorfall? Wie wird sichergestellt, dass diese Person am späten Sonntagabend erreichbar ist?
- Wie wird diese vage, aber hochkritische Information verifiziert und intern eskaliert? Wer muss sofort aus dem Bett geklingelt werden (IT-Leitung, Krisenstab, Geschäftsführung)?
Erste Reaktion:
- Was sind die ersten Gedanken und Annahmen? Wartet man auf mehr Informationen oder geht man sofort vom Schlimmsten aus – dem Totalverlust der Systeme in diesem Brandabschnitt?
Informationsmanagement:
- Wer übernimmt die zentrale Koordination und Kommunikation, um zu verhindern, dass verschiedene Personen beim Rechenzentrumsanbieter anrufen und für mehr Verwirrung sorgen?

Mögliche Sofortmaßnahmen:

Aktivierung des IT-Krisenstabs über die vordefinierten Notfall-Kanäle.
Einrichtung einer zentralen (virtuellen) Kommandozentrale zur Koordination aller Maßnahmen.
Benennung eines einzigen Ansprechpartners für die gesamte Kommunikation mit dem Rechenzentrumsanbieter.

Phase 2: Lagebild – Was genau ist ausgefallen?

Szenariobeschreibung (Teil 2):

Der Krisenstab hat sich virtuell versammelt. Die Informationen vom Rechenzentrumsanbieter bleiben spärlich. Er kann nicht bestätigen, welche Racks genau betroffen oder beschädigt sind. Die Monitoring-Systeme zeigen, dass eine ganze Reihe von Servern nicht mehr erreichbar ist. Die dringendste Aufgabe für das Team ist nun, eine präzise Antwort auf eine scheinbar einfache Frage zu finden: Welche Systeme, Anwendungen und Daten waren in Trakt B, Brandabschnitt 4 untergebracht?

Diskussionspunkte und Kernfragen für Ihr Team:

Inventar und Dokumentation – Die Stunde der Wahrheit:
- Sind alle Dienste und Systeme bekannt, die dort laufen? Gibt es eine aktuelle und detaillierte Dokumentation (CMDB, DCIM, Wiki, Excel-Tabelle), die jeden Server und jede Anwendung einem physischen Standort (Rechenzentrum, Trakt, Rack) zuordnet?
- Was passiert, wenn diese Dokumentation unvollständig oder veraltet ist? Wie finden Sie die "vergessenen" Systeme oder Schatten-IT, die ebenfalls dort liefen?
Analyse der Geschäftsauswirkungen:
- Welche konkreten Geschäftsprozesse sind durch den Ausfall der identifizierten Systeme betroffen? (z.B. "Server FS-01 ist down" bedeutet "Die Konstruktionsabteilung hat keinen Zugriff mehr auf CAD-Zeichnungen der letzten 10 Jahre").
- Welche Abhängigkeiten gibt es? Funktionieren andere Systeme nicht mehr, weil sie auf eine Datenbank oder eine API zugreifen müssen, die im betroffenen Bereich lief?
Informationslücke:
- Wie gehen Sie damit um, dass Sie nicht wissen, ob die Hardware nur ohne Strom oder physisch zerstört ist? Beeinflusst das die nächsten Schritte?

Mögliche Sofortmaßnahmen:

Zusammentragen aller verfügbaren Dokumentationen, um eine Liste der betroffenen Systeme zu erstellen.
Kontaktaufnahme mit den Anwendungsverantwortlichen, um die Geschäftsauswirkungen für jedes ausgefallene System zu bewerten.
Erstellung einer ersten, priorisierten Liste der ausgefallenen Dienste basierend auf ihrer Kritikalität für das Unternehmen.

Phase 3: Aktivierung der Notfallpläne

Szenariobeschreibung (Teil 3):

Nach einer Stunde hat das Team eine grobe Liste der Hauptbetroffenen: die zentrale Virtualisierungsplattform (VMware/Hyper-V) mit Dutzenden von VMs, der alte, aber geschäftskritische Warenwirtschafts-Server und die zentralen Datenbankserver. Der Rechenzentrumsanbieter teilt nun mit, dass der Zugang zu Trakt B aufgrund von Löscharbeiten und Sicherheitsprüfungen mindestens 48-72 Stunden gesperrt bleiben wird. Ein Totalverlust der Hardware ist wahrscheinlich. Warten ist keine Option mehr. Die Disaster-Recovery-Pläne müssen aktiviert werden.

Diskussionspunkte und Kernfragen für Ihr Team:

Geo-Redundanz und Failover:
- Gibt es für die kritischsten Systeme eine Geo-Redundanz? Existiert ein Standby-Rechenzentrum oder eine Cloud-Umgebung, auf die aktiv umgeschaltet (Failover) werden kann?
- Ist dieser Failover-Prozess dokumentiert, erprobt und automatisiert? Wer hat die Berechtigung, ihn auszulösen?
Backups – Die letzte Verteidigungslinie:
- Wo liegen die Backups der Systeme, die keine Geo-Redundanz haben? Sind sie sicher an einem anderen physischen Ort (anderes Rechenzentrum, Cloud-Speicher, ausgelagerte Bänder)?
- Die kritischste Frage: War der Backup-Server oder die Backup-Appliance zufällig im selben Brandabschnitt?
- Wie aktuell sind die Backups (Recovery Point Objective - RPO)? Wie lange würde eine vollständige Wiederherstellung dauern (Recovery Time Objective - RTO)? Wurde dies jemals getestet?
Wiederherstellungsumgebung:
- Haben Sie die notwendige "nackte" Hardware oder Cloud-Kapazität verfügbar, um die Backups darauf wiederherzustellen? Wer kann diese Ressourcen kurzfristig bereitstellen?
Priorisierung der Wiederherstellung:
- Welches System wird zuerst wiederhergestellt? Die VMs der Entwicklungsabteilung oder der Datenbankserver für die Produktion? Wer trifft diese strategische Entscheidung?

Mögliche Sofortmaßnahmen:

Formelle Aktivierung des Disaster-Recovery-Plans.
Entscheidung über die Wiederherstellungsstrategie: Failover für redundante Systeme, Wiederherstellung aus dem Backup für nicht-redundante Systeme.
Zuweisung von technischen Teams zur Durchführung der Wiederherstellung.
Kommunikation an die Geschäftsführung und die Fachbereiche über die erwartete Ausfallzeit und den Wiederherstellungsplan.

Phase 4: Der lange Weg zurück aus der Asche

Szenariobeschreibung (Teil 4):

Nach 48 Stunden intensiver Arbeit laufen die kritischsten Systeme behelfsmäßig in einer Cloud-Umgebung, wiederhergestellt aus den Offsite-Backups. Das Unternehmen ist wieder handlungsfähig, aber die Performance ist langsam und die Konfiguration ist fragil. Der Rechenzentrumsanbieter bestätigt den Totalverlust der Hardware. Der unmittelbare Notfall ist vorbei, aber der Marathon des Wiederaufbaus und der strategischen Neuausrichtung hat gerade erst begonnen.

Diskussionspunkte und Kernfragen für Ihr Team:

Vollständige Wiederherstellung:
- Wie sieht die langfristige Strategie aus? Werden die Systeme dauerhaft in die Cloud migriert? Sucht man sich einen neuen Rechenzentrumsanbieter?
Lessons Learned – Dokumentation und Prozesse:
- Was war der größte Schmerzpunkt während der Krise? (Wahrscheinlich die lückenhafte oder veraltete Dokumentation der Systemlandschaft).
- Wie wird sichergestellt, dass die CMDB oder das Infrastruktur-Inventar zukünftig lückenlos und immer aktuell ist?
Lessons Learned – Business Continuity & Disaster Recovery:
- War der DR-Plan realistisch? Haben die Backup-Strategien funktioniert? Waren die RTOs und RPOs angemessen?
- Wie oft müssen DR-Übungen in Zukunft durchgeführt werden, um sicherzustellen, dass die Pläne auch in der Praxis funktionieren?
Lieferantenmanagement:
- Wie werden Rechenzentrumsanbieter in Zukunft bewertet? Welche Rolle spielen Brandschutzkonzepte, Zertifizierungen und die geografische Trennung von Brandabschnitten bei der Auswahl?
- Was sagen die Verträge über Haftung und Entschädigung bei einem solchen Ereignis aus?

Mögliche Maßnahmen (Entscheidungen, die im Rahmen der TTX getroffen werden müssen):

Entwicklung eines Projektplans für den langfristigen, resilienten Wiederaufbau der IT-Infrastruktur.
Durchführung eines schonungslosen "Lessons Learned"-Workshops.
Initiierung eines Projekts zur Verbesserung der IT-Dokumentation und zur Einführung regelmäßiger DR-Tests.
Neubewertung aller kritischen IT-Dienstleister und Verträge.
Transparente Kommunikation der Ergebnisse und der neuen strategischen Ausrichtung an die Geschäftsführung und das gesamte Unternehmen.

Fazit

Ein Brand im Rechenzentrum ist der ultimative Realitätscheck für jede IT-Strategie. Er zeigt, dass selbst die sicherste Festung eine Achillesferse haben kann. Die Hoffnung, dass ein Desaster schon nicht eintreten wird, ist keine Strategie. Nur eine lückenlose, aktuelle Dokumentation Ihrer Systeme, eine durchdachte Backup- und Redundanzstrategie und ein regelmäßig getesteter Notfallplan verwandeln eine potenziell unternehmensgefährdende Katastrophe in einen beherrschbaren, wenn auch schmerzhaften, Zwischenfall.

Nutzen Sie dieses Szenario, um Ihre eigenen Notfallpläne zu hinterfragen. Wissen Sie wirklich, wo Ihre Kronjuwelen liegen, und haben Sie einen Plan B für den Tag, an dem ihr Zuhause abbrennt?

Wir unterstützen Sie gerne dabei. Ob Awareness-Schulungen, Incident-Response-Pläne oder technische Schutzmaßnahmen – mit unseren Services helfen wir Ihnen, Sicherheitsvorfälle nicht nur besser zu bewältigen, sondern im besten Fall ganz zu vermeiden.