RPO, RTO vs. RPA und RTA in Disaster Recovery Planungen
Hochverfügbarkeit, Data and Application Resilience, Disaster Recovery Planung - alles ein alter Hut? Alles unter Kontrolle?
Egal ob bei eigenen Softwareprodukten oder im (Datenbank) Consulting, immer wieder wird Robotron als Spezialist zu Themen wie einer Disaster Recovery Planung oder nach einem Desaster zur Wiederherstellung hinzugezogen. Bei allen Planungen um "Verfügbarkeit" und "Wiederherstellung" von Systemen ist ein Diskussionspunkt immer RPO und RTO. Häufig wird die Disaster Recovery Planung an diesen beiden Begriffen ausgerichtet und in der IT kennt diese jeder.
Wir erinnern uns an die Definition der beiden Ziele:
- RPO: Recovery Point Objective, also die Anzahl Zeiteinheiten (und damit auch die Datenmenge), die (maximal) verloren gehen kann (bzw. sollte), wenn ein Disaster Recovery Fall eintritt. Mehr oder weniger folgt daraus häufig, wie eine Backup- und (Disaster) Recovery Strategie aussehen könnte.
- RTO: Recovery Target Objective, also die Anzahl Zeiteinheiten, bis wann ein System wiederhergestellt werden müsste, ohne dass ein signifikanter Schaden für das Unternehmen entsteht. Das entspricht also mehr oder weniger der Zeit, die für die Wiederherstellung der Anwendung und ihrer Daten benötigt wird.
Beide Ziele sind ein guter Einstiegspunkt in eine Disaster Recovery Planung, allerdings werden sie nahezu immer isoliert für einzelne Anwendungen betrachtet. Gerade bei älteren Disaster Recovery Planungen stammt die RTO und RPO Betrachtung auch noch aus der Zeit, in der der Ausfall einzelner Komponenten der Hauptgrund für Probleme war. Die IT-Welt kennt isolierte Systeme aber so gut wie gar nicht mehr (von ein paar hochkritischen Spezialfällen abgesehen). Applikationen tauschen Daten aus, sind über das Internet verfügbar, versenden oder empfangen Daten von Geschäftspartnern oder sind Grundlage für den Datenaustausch mit Dritten (z.B. Steuerdaten, Abrechnungen, etc.).
Entsprechend komplizierter wird auch die Betrachtung von RPO und RTO. Das beginnt von einer zeitlich differenten Wiederherstellung von Daten zweiter Applikationen (und dadurch nicht mehr konsistenten Schnittstellendaten) bis hin zu Firewall-Konfigurationen, Mail-Servern, FTP-Servern oder anderen, grundlegenden Hintergrunddiensten (oftmals Authentifizierung, Namensauflösung, Service Bus, Process Management Systeme, um nur einige zu nennen).
Die schlimmsten und auch häufigsten Schäden treten inzwischen nicht mehr durch Hard- oder Softwarefehler auf, sondern durch bewusste Angriffe von innen oder aussen. Die Anzahl der Hackerangriffe hat spätestens seit der Ukraine-Krise extrem zugenommen, so dass erste Versicherungsgesellschaften keine Versicherungspolicen mehr anbieten wollen - oder Hackerangriffe russischer Angreifer spätestens seit Februar 2022 als "Kriegsevent" einstufen, weil diese grundsätzlich nicht versicherbar sind.
Noch immer ist in der IT, bzw. in den Köpfen des Business, häufig die Rede von, die Firma könne 24 Stunden ohne Mail-Server problemlos überstehen. Also hat dieser Service ein RTO von 24h. Oder die Daten einer Applikation, die für 8 Stunden offline ist, können ohne Probleme durch genug Personal händisch wieder nachgetragen werden? Reicht also ein RPO von 3h aus (weil in der Downtime ein RTO von vielleicht 5h berücksichtigt werden muss)?
Auch wenn es etwas aus der Mode gekommen ist, einige Ableitungen aus Murphys Gesetz in Erinnerung zu rufen, kann nicht schaden:
- Dinge, die schiefgehen können, gehen schief.
- Nichts ist so leicht, wie es aussieht.
- Alles dauert länger, als man denkt.
Diese drei Ableitungen zu Herzen genommen zeigen auch das Dilemma von RPO und RTO auf - es sind isolierte Planzahlen. Deshalb sollte in einer Disaster Recovery Planung die Aufnahme von zwei zusätzlichen Kennzahlen Standard sein. Für IT Mitarbeiter aus Selbstschutz und für Business und Geschäftsleitung zur Risikoabschätzung. Die Rede ist von RPA und RTA.
- RPA: Recovery Point ACTUAL, also die Anzahl Zeiteinheiten (und damit die Datenmenge), die WIRKLICH im Desaster Fall verloren geht (also was wäre, wenn man jetzt ALLES wiederherstellen müsste).
- RTA: Recovery Target ACTUAL, also die Anzahl Zeiteinheiten, bis wann ein System, vom grösstmöglichen Incident in dieser Minute ausgegangen, wirklich wieder zu 100% arbeitet, wie zuvor! (Also auch alle Schnittstellen, Daten,...)
Warum sind diese Kennzahlen mindestens genauso wichtig wie RPO und RTO? Ganz einfach, sie berücksichtigen, dass auch mal etwas schief gehen kann und sie berücksichtigen parallel konkurrenzierende oder aufeinander aufbauende Prozesse.
Sicherlich kann niemand an 100% in einer Disaster Recovery Planung denken, aber wer den Schritt weg vom Silodenken einer Anwendung gemacht hat, ist schon ein gutes Stück weiter. Anhand konkreter Beispiele lässt sich dies relativ einfach nachvollziehen.
- Fall: Sicher selten, aber nicht unmöglich, ist der Ausfall eines Data Centers aufgrund eines Problems des zentralen Storages. Wie wahrscheinlich ist es, dass bei einer (a-)synchronen Replikation auch die DR-Seite betroffen ist? Ggfs. sind auch Snapshots korrupt oder die Backups sind (temporär) nicht verfügbar? Welche VMs lassen sich auf der DR-Seite wirklich noch starten? Welche Snapshots oder Backups können zurückgeholt werden, ggfs. old-school von Tapes oder neumodisch aus einer Cloud?
- Fall: Die berühmte und immer wahrscheinlichere Hacker- oder Ransomware-Attacke. Welche Systeme sind betroffen? Wie sieht die Wiederherstellungsstrategie aus?
Im Falle des Hacks des deutschen Bundestages 2015 wurde ein komplett neues Netzwerk mit neuen Servern und Clients aufgebaut. Wie lange es dauert, bis sämtliche IT-Systeme beschafft und neu installiert sind, lässt sich in vielen Unternehmen kaum abschätzen. Gibt es (physikalisch überhaupt) Platz und wie sind die Lieferzeiten für die einzelnen, neuen Komponenten, abhängig von der gewünschten Wiederherstellungsreihenfolge? Sind die Backups ok oder infiziert/gelöscht/verschlüsselt und falls ja, wie weit zurück? Sind alle Kommunikationsschnittstellen ausreichend beschrieben und wie werden Schnittstellen zwischen Applikationen fehlertolerant synchronisiert? Sind alle Ports in den Firewalls bekannt? Welche Umsysteme müssen verfügbar sein, welche Useraccounts angelegt oder welche Berechtigungen wann vergeben sein? Dürfen Betriebssysteme, IP-Adressen und Host-Namen getauscht werden oder müssen diese stringent beibehalten werden, damit die Applikation läuft? Welche Konfigurationen sind ggfs. anzupassen, muss Software neu installiert werden? Wer (rein technologisch, personell und fachlich) ist in der Lage, 20, 30 oder 1000 Applikationen gleichzeitig (?) aus Backups wiederherzustellen? Wie wird priorisiert (Nicht Kategorie "1-X", sondern "Reihenfolge" der Wiederherstellung)? Und nicht zuletzt: WO ist das alles notiert, damit es im Falle eines solchen Incidents überhaupt selbst verfügbar ist?
Man sieht an diesen beiden relativ kurzen Beispielen, dass die singuläre Betrachtung von Applikationen oder Datenbanken mit RPO oder RTO zwar ein guter Einstiegspunkt in eine Hochverfügbarkeits- und Disaster Recovery Planung darstellen, aber nicht der Weisheit letzter Schluss sind, denn die Realität ist deutlich komplexer.
Sich im Zuge einer Disaster Recovery Planung zusätzlich mit RPA und RTA zu beschäftigen, macht also mehr Sinn, als lediglich auf RPO und RTO einzelner Anwendungen zu schielen. Natürlich ist dies aufwändiger und, genauso sicher, ist es utopisch zu denken, man könnte sämtliche, auftretende Probleme in eine DR Planung mit aufnehmen - schon rein aus Zeit- und Kostengründen sind RPOs, RTOs, RPAs und RTAs gegen Null zwar Wunschdenken vermutlich aller Unternehmen und Institutionen, aber nicht umsetzbar.
Aufgrund der steigenden Bedrohungen durch Dritte werden große Incidents, in der eine Vielzahl von Systemen betroffen sind, immer wahrscheinlicher, kleine, singuläre Probleme sind leichter handelbar und werden technologisch immer unwahrscheinlicher. Sich darauf verstärkt vorzubereiten, kann definitiv kein Fehler sein.
Beim erwähnten Hackerangriff 2015 auf den deutschen Bundestag dauerte die Wiederherstellung aller Systeme und Clients übrigens etwa ein Jahr, d.h. es gab durchaus Systeme, die ein RTA von einem Jahr aufgewiesen haben (während der definierte RTO vermutlich deutlich kürzer gewesen sein dürfte). Als Unternehmen befindet man sich also in bester Gesellschaft, wenn man solche Kennzahlen in einer fundierten Disaster Recovery Planung mit aufnimmt. Die Erfahrung zeigt: ein einhundertprozentiger Schutz vor solchen Incidents ist selbst für kritischste Umgebungen unmöglich. Da sowohl die Systemlandschaften als auch die Gründe für Incidents ständig in Bewegung sind, ist darüber hinaus eine ständige Überarbeitung der Disaster Recovery Planung und den daraus folgenden Umsetzungsstrategien und -tests notwendig. Im Vergleich zu einfachen Hardwareproblemen früher ist das lästig, aber unabdingbar.
Kommentare
|
Guter Artikel! Ich werde mal versuchen, ein paar der Anregungen in der nächsten Überarbeitung des DRP-Planes unterzubringen.