Single Point of Failure Standort: Warum ein Rechenzentrum für KRITIS nicht reicht

In der Welt der kritischen Infrastrukturen (KRITIS) ist “Hochverfügbarkeit” kein bloßes Schlagwort, sondern eine gesetzliche und gesellschaftliche Verpflichtung. Wer Steuerungssysteme für Strom-, Gas- oder Wärmenetze betreibt, agiert in einem Umfeld, in dem Ausfälle unmittelbare Auswirkungen auf die öffentliche Versorgungssicherheit haben können.

Viele Unternehmen wiegen sich in Sicherheit, weil ihre Plattform innerhalb eines Rechenzentrums (RZ) redundant aufgebaut ist: Mehrere Server-Racks, redundante Netzteile, gespiegelte Datenbanken und ein lokaler Kubernetes-Cluster mit mehreren Control-Plane-Nodes. Doch diese Architektur hat eine Achillesferse: Sie schützt vor dem Ausfall einer Komponente, aber nicht vor dem Ausfall des Standorts.

1. Das Illusions-Problem: Lokal redundant ist nicht georedundant

Solange ein Rechenzentrum in Betrieb ist, funktioniert die interne Redundanz hervorragend. Doch die Risikoanalyse für KRITIS-relevante Systeme muss weiter gehen. Was passiert bei:

• Großflächigen Stromausfällen, die auch die Notstromkapazitäten übersteigen?
• Physischen Vorfällen wie Bränden, Überflutungen oder massiven Leitungsschäden im Glasfasernetz des Standorts?
• Geopolitischen oder regionalen Katastrophen, die den Zugang zum Standort unmöglich machen?

Ein System, das nur an einem Ort existiert, ist - egal wie redundant es intern gebaut ist - ein Single Point of Failure (SPOF) auf Standortebene. Für Regulierer und Auditoren (BSI, NIS-2, Bundesnetzagentur) ist dieses Klumpenrisiko zunehmend inakzeptabel.

2. Der regulatorische Druck: NIS-2 und KRITIS-Vorgaben

Die regulatorischen Anforderungen haben sich verschärft. Es reicht nicht mehr aus, ein Backup zu haben, das man im Notfall “irgendwann” wieder einspielen kann.

• Business Continuity Management (BCM): Gefordert wird ein nachweisbarer Plan, wie der Betrieb bei einem Standortausfall ohne massive Unterbrechung fortgeführt wird.
• RTO (Recovery Time Objective): Die Zeitspanne bis zur Wiederherstellung der Dienstleistung muss definiert und - vor allem - technisch belegbar sein. In kritischen Sektoren bewegen wir uns hier oft im Bereich von Minuten, nicht Stunden.
• Nachweispflicht: Auditoren verlangen heute technische Belege und Testprotokolle für den Ernstfall. Ein bloßes Runbook auf Papier wird als “Mangel” eingestuft.

3. Die technologische Hürde: DNS-Trägheit und manuelle Prozesse

In vielen historisch gewachsenen IT-Landschaften existiert zwar ein zweites Rechenzentrum (“Standort B”), aber der Failover-Prozess ist eine manuelle Herkulesaufgabe:

1. Dienste an Standort B händisch hochfahren.
2. Datenbank-Backups einspielen oder Replikas manuell promoten.
3. DNS-Einträge umschalten und warten, bis die weltweite TTL (Time to Live) abgelaufen ist.
4. Kunden informieren, dass sich IPs geändert haben könnten.

Für eine KRITIS-Plattform, die Echtzeitdaten verarbeitet, ist dieser Prozess viel zu langsam und fehleranfällig. Wer auf manuelle Koordination angewiesen ist, hat keinen Disaster-Recovery-Plan, sondern ein Risiko.

Fazit: Georedundanz als Architektur-Fundament

Echte Ausfallsicherheit beginnt dort, wo man den Standort als austauschbare Ressource betrachtet. Für KRITIS-Betreiber bedeutet das den Wechsel von einer Einzelstandort-Logik zu einem Aktiv/Aktiv-Multi-Region-Modell. Hierbei laufen die Workloads an mindestens zwei geografisch getrennten Orten gleichzeitig. Fällt ein Standort aus, übernimmt der andere nahtlos - idealerweise ohne dass der Endnutzer oder die angeschlossenen Systeme (wie SCADA-Gateways) den Wechsel überhaupt bemerken.

Im nächsten Teil dieser Serie schauen wir uns an, wie man dieses Problem auf Netzwerkebene löst, damit ein Failover ohne die Trägheit von DNS-Umschaltungen gelingt.

FAQ

Reichen zwei Verfügbarkeitszonen (Availability Zones) innerhalb eines Cloud-Anbieters aus? Oft liegen Availability Zones in derselben Stadt oder Region (z. B. Frankfurt). Bei einem großflächigen Ereignis (Hochwasser, Stromnetz-Kollaps) könnten alle Zonen gleichzeitig betroffen sein. Für KRITIS wird daher oft eine echte geografische Distanz (z. B. > 100 km) gefordert.

Ist Georedundanz nicht viel zu teuer für mittelständische Plattformen? Die Kosten für die Infrastruktur verdoppeln sich zwar annähernd, aber durch den Einsatz von Kubernetes und Automatisierung sinkt der operative Aufwand für Disaster-Recovery-Tests und Wartung. Das größte Kostenrisiko ist ohnehin die Pönale bei einem längeren Ausfall oder der Entzug der Betriebserlaubnis durch Auditoren.

Was ist der Unterschied zwischen Disaster Recovery und Business Continuity? Disaster Recovery (DR) fokussiert sich auf das Wiederherstellen nach einem Ausfall (oft mit Datenverlust/Downtime). Business Continuity (BC) zielt darauf ab, den Betrieb trotz des Ausfalls ohne spürbare Unterbrechung aufrechtzuerhalten. KRITIS verlangt zunehmend nach BC.

Können wir unsere bestehende Applikation einfach “doppelt” hosten? Technisch ja, aber die Herausforderung liegt in der Synchronisation der Daten und dem Routing des Traffics. Eine Applikation muss “Cloud-Native” entworfen oder angepasst sein, um in einem Multi-Region-Verbund konsistent zu funktionieren.

Wie unterstützt ayedo bei der Risikoanalyse? Wir führen ein technisches Audit Ihrer aktuellen Infrastruktur durch, identifizieren Single Points of Failure und erarbeiten eine Roadmap für eine georedundante Zielarchitektur, die sowohl technisch stabil als auch audit-konform ist.