So erstellst du einen effektiven Disaster-Recovery-Plan für SaaS-Daten

Warum ist ein Disaster-Recovery-Plan für SaaS-Daten notwendig?

Diese Frage bekommen wir mindestens einmal am Tag von Kollegen gestellt: „Warum sollte ich einen Disaster-Recovery-Plan für die Cloud benötigen, insbesondere für SaaS?"

Hier ist der Grund: Wenn Unternehmen ihre eigene Software entwickeln, haben sie die Kontrolle über Datenschutz, Sicherheit und Zuverlässigkeit. Cloud-Anwendungen nehmen dir zwar einen Großteil der Verantwortung ab, die mit dem Hosting der Lösungen verbunden ist, aber nicht alles.

Die Rede ist vom Shared Responsibility Model. Es wird oft mit AWS in Verbindung gebracht, aber das Konzept der geteilten Verantwortung gilt für das gesamte Cloud Computing – einschließlich Atlassian. Im Wesentlichen teilen sich der Cloud-Anbieter und -Nutzer die Verantwortung für den Schutz der Daten. SaaS-Unternehmen garantieren alles, außer Benutzerzugriff und Benutzerdaten. Für die Sicherung dieser Dinge bist du verantwortlich.

Einige SaaS-Produkte bieten zwar Sicherungs- und Wiederherstellungsfunktionen, doch manchen fehlt es an fein abgestuften Wiederherstellungskontrollen, umfassender Datentransparenz durch detaillierte Audit Logs oder Garantien für die Datensicherheit. Daher ist ein Disaster-Recovery-Plan für jedes SaaS-Produkt, auf das du angewiesen bist, unerlässlich.

Schritt eins: Definiere dein RTO und RPO
Die beiden wichtigsten Kennzahlen für deine Recovery-Strategie lauten Recovery Point Objective (RPO), die deine Toleranz gegenüber Datenverlusten bestimmt, und Recovery Time Objective (RTO), die den Maßstab für das Minimieren von Ausfallzeiten setzt.
Die RPO-Metrik dreht sich um eine grundlegende Frage: „Wie viele Daten kannst du dir leisten, zu verlieren". Wir formulieren es oft folgendermaßen: Wenn du deine Daten einmal alle 24 Stunden um Mitternacht sicherst und es um 23:59 Uhr zu einem Ausfall kommt, würdest du die Daten eines ganzen Tages verlieren.

Dieses Risiko ist für einige Unternehmen akzeptabel, für andere jedoch nicht. Die Festlegung deiner Risikotoleranz in Bezug auf Datenverluste dient als Richtschnur für technische Entscheidungen, um diese Anforderungen effektiv zu erfüllen.

Um dein RPO zu bestimmen, solltest du die Wichtigkeit deiner Daten und die Auswirkungen eines möglichen Datenverlusts auf dein Unternehmen berücksichtigen. Verschiedene Dienste oder Anwendungen können unterschiedliche RPO-Schwellenwerte haben. So kann es sein, dass geschäftskritische Systeme eine Echtzeitreplikation mit keinem oder nahezu keinem Datenverlust erfordern, während nicht kritische Systeme möglicherweise ein längeres Intervall zwischen den Backups tolerieren.

Bei der RTO-Metrik geht es darum, wie schnell du dich von einem Ausfall erholen und den normalen Betrieb wieder aufnehmen kannst. Stell dir ein Szenario vor, in dem dein Rechenzentrum von einem Meteoriten getroffen wird. Wie lange würde es dauern, bis du deine Systeme wieder in Betrieb nehmen kannst? Dazu gehören Faktoren wie die Beschaffung einer alternativen Infrastruktur oder die Wiederherstellung aus Backups. Die für die Wiederherstellung benötigte Zeit variiert je nach Dienst.

Bei einigen Diensten ist eine schnelle Wiederherstellung möglich, möglicherweise innerhalb von Minuten, während es bei anderen wesentlich länger dauern kann, vielleicht einen ganzen Tag oder länger. Das Verständnis darüber, dass jeder Dienst oder jede

Anwendung mit eigenen Wiederherstellungszeiten einhergeht, ist für eine effektive Planung der Wiederherstellung im Katastrophenfall unerlässlich.

Ein wichtiger Ansatzpunkt ist die Zusammenarbeit mit allen Beteiligten in deinem Unternehmen, um sicherzustellen, dass sie die definierten RPO- und RTO-Ziele akzeptieren und ihnen zustimmen. Diese Zusammenarbeit fördert ein gemeinsames Verständnis für die potenziellen Auswirkungen eines Ausfalls und die erforderlichen Wiederherstellungszeiträume.

Schritt zwei: Wähle eine Recovery-Strategie aus
Die Wahl der richtigen Strategie läuft auf einen Kompromiss zwischen Robustheit und Kosten hinaus. Hier gibt es ein Spektrum an Auswahlmöglichkeiten.

Beginnen wir mit der Lösung Backup & Restore. Das ist die einfachste und günstigste Option. Allerdings kann die Wiederherstellungszeit hier Stunden oder sogar länger dauern. Im Wesentlichen stellst du deine letzte(n) Sicherung(en) an deinem Wiederherstellungsort wieder her.

Weiter geht es mit der Option Pilot Light. Bei diesem Ansatz lässt du einige wichtige Dienste mit reduzierter Kapazität laufen. Die meisten Dienste laufen weiter, werden aber auf ein "Scale to Zero"-Niveau heruntergefahren. Code- oder Anwendungsaktualisierungen werden an den Disaster-Recovery-Standort übertragen, genauso wie du deine primären Standort aktualisieren würdest.

Als nächstes kommt die Standby-Strategie. Hier ist alles in Betrieb, wenn auch mit einer geringeren Kapazität im Vergleich zu deiner primären Umgebung. Sie ähnelt der Pilot-Light-Option, aber alle Dienste sind zumindest mit einer gewissen Kapazität in Betrieb –  nichts wird auf Null skaliert.

Schließlich haben wir noch die Active/Active-Lösung. Hierbei handelt es sich um den umfassendsten Ansatz, bei dem du vollständige Dienste in zwei parallelen Streams laufen lässt, zwischen denen du nahezu in Echtzeit wechseln kannst. Allerdings ist diese Option mit doppelten Kosten verbunden, so dass sie für viele Unternehmen weniger praktikabel ist.

Die Wahl der Recovery-Strategie hängt von deiner Risikotoleranz ab und davon, wie viel du bereit bist zu investieren, um dieses Risiko zu mindern. Je nach Branche verfügen Unternehmen über Kernsysteme, die die Grundlage für den Betrieb bilden, sowie über Peripheriesysteme. Während ein eintägiger Ausfall eines Kernsystems für die meisten Unternehmen schmerzhaft sein kann, sind die Auswirkungen möglicherweise weniger gravierend, wenn es sich um ein Tool für die Durchführung von Marketingprogrammen, die Erfassung von Statistiken oder einen anderen sekundären Dienst handelt.

Das bedeutet, dass du für die verschiedenen Systeme in deinem Unternehmen unterschiedliche Disaster-Recovery-Pläne benötigst. Auch wenn es Überschneidungen zwischen den DR-Plänen der einzelnen Dienste geben kann, ist es wichtig, den Plan jedes einzelnen Dienstes zu berücksichtigen, da die RPOs und RTOs variieren können.

Dritter Schritt: Teste deinen Disaster-Recovery-Plan

Um deinen SaaS Disaster-Recovery-Plan effektiv zu testen, ist hier eine hilfreiche Checkliste als Unterstützung:

• Organisiere einen Tabletop-Test deines DR-Plans: Ein Tabletop-Test ist ein guter Anfang, um Ideen und Methoden vorzustellen. So können alle Stakeholders mitbestimmen, wie mit dem Disaster-Recovery-Plan verfahren werden soll.
  Gehe alle internen und externen Abhängigkeiten durch, die die Wirksamkeit deines Disaster-Recovery-Plans beeinträchtigen oder sogar verhindern könnten. Es ist wichtig, diese Abhängigkeiten vor der Umsetzung des Plans zu klären und zu beseitigen.
  Diese Besprechung bildet die Grundlage für deinen Disaster-Recovery-Plan, daher muss alles gründlich dokumentiert werden. Es ist ratsam, die Teilnehmer die Dokumentation abzeichnen zu lassen, um spätere Unklarheiten zu vermeiden.
• Erstelle Verantwortlichkeitslisten: Hier wird festgelegt, wer im Falle einer Unterbrechung des Geschäftsbetriebs durch einen Ausfall auf Abruf bereitsteht; die Personen, die für die Ausführung der verschiedenen Phasen des DR-Plans verantwortlich sind. Die Liste sollte klar umrissen und aktualisiert werden, damit neue Teammitglieder wissen, wer im Notfall welche Aufgaben übernimmt.
• Plane für verschiedene Arten von Ausfällen: Du kannst zwar nicht für jede mögliche Katastrophe planen, aber es ist wichtig, die Risiken, denen du ausgesetzt bist, zu bewerten und zu priorisieren. Ob Malware-Angriffe, Ausfälle im Rechenzentrum oder bei Drittanbietern – bestimme, auf welche Risiken du dich vorbereiten willst.
• Verstehe die Kosten von Ausfallzeiten und Datenverlusten: Wenn SaaS-Tools für Prozesse und Arbeitsabläufe unerlässlich sind, können Ausfälle die Produktivität und das Budget belasten. Ein Beispiel dafür ist der vierzehntägige Ausfall von Atlassian im April 2022, von dem über 50.000 Nutzer betroffen waren. Die Ausfallzeit führte dazu, dass der Zugriff auf wichtige SaaS-Produkte wie Jira, Confluence und Opsgenie gesperrt wurde. Außerdem kam es zum Verlust von Daten. Nach eigenen Berechnungen von Atlassian belaufen sich die durchschnittlichen Kosten der Ausfallzeit für die Kunden auf 5.600 US-Dollar, aber die tatsächlichen Kosten variieren von Unternehmen zu Unternehmen.
  Natürlich verursacht die Vorbereitung auf ein solches Ereignis Kosten auf mehreren Ebenen, daher solltest du sorgfältig abwägen, in welche Ausfallsicherungen du in welchem Umfang investieren willst. Ein guter Anfang ist eine Backup und Recovery Software, mit der kritische Vorgänge aufrechterhalten werden können, auch wenn ein Teil der Anwendung nicht funktioniert.

Zusammenfassung

Deine Checkliste zum Testen deine Disaster-Recovery-Plans sollte in etwa so aussehen:

• Verstehe die Notwendigkeit eines SaaS Disaster-Recovery-Plans.
• Lege dein RPO und RTO fest.
  Kläre mit den relevanten Interessengruppen ab, welche Geschäftsfunktionen geschützt und gesichert werden sollen.
• Entscheide über die internen und externen Werkzeuge, die für die Durchführung eines Disaster-Recovery-Plans erforderlich sind, und berücksichtige dabei die Sicherheit und den Datenschutz deiner SaaS-Daten.
• Erstelle klare und relevante Zuständigkeitslisten, aus denen hervorgeht, wer in welchen Situationen für was zuständig ist.
• Lege die Arten von Katastrophen fest, für die du planst, denn für alle planen kannst du nicht.
• Dokumentiere den Plan, mach ihn leicht zugänglich und lass ihn von den richtigen Beteiligten abzeichnen.