Daten, die man nicht wiederherstellen kann, sind eigentlich gar nicht souverän

Die wichtigsten Erkenntnisse

• Bei souveränen Architekturen liegt der Schwerpunkt häufig eher auf Audits und Zugriffskontrollen als auf der Wiederherstellungsbereitschaft.
• Personal für die Wiederherstellung, Backup-Systeme und Modelle zur Schlüsselverwahrung können bei Vorfällen zu Lücken in der Souveränität führen.
• Einheitliche Kontrollmaßnahmen in Primär- und Wiederherstellungsumgebungen sind unerlässlich.
• Eine auf staatliche Anforderungen ausgerichtete Widerstandsfähigkeit erfordert erprobte Wiederherstellungsverfahren unter realistischen Bedingungen.

Stellen Sie sich folgende Situation vor: Der Angriff hat bereits stattgefunden. Das Incident-Response-Team versammelt sich. Jemand muss entscheiden, welche Systeme als Erstes wieder in Betrieb genommen werden sollen – in welcher Reihenfolge und unter Verwendung der richtigen Recovery-Punkte.

Und dann wird jemandem klar: Die Mitarbeiter, die Zugriff auf das Wiederherstellungssystem haben, sind in einem anderen Land stationiert. Schlimmer noch: Die Wiederherstellungsumgebung selbst (die in einer Cloud, einem Partner-Rechenzentrum oder an einem sekundären Standort gehostet wird) unterlag nie denselben staatlichen Kontrollen wie die Primärdaten. Die Praxis unterlag nicht denselben hoheitlichen Kontrollen wie die Primärdaten. Die Aufsichtsbehörde bittet um eine Statusmeldung. Die Zeit läuft.

Dies ist das Szenario, für das die meisten souveränen Architekturen nicht konzipiert wurden – und genau das, worauf sich der „Digital Sovereignty Readiness Report“ direkt bezieht: Die meisten souveränen Anwendungen sind auf die Prüfung ausgelegt, nicht auf den Vorfall. Die meisten souveränen Anwendungen sind auf die Prüfung ausgelegt, nicht auf den Vorfall. Der Unterschied wird im ungünstigsten Moment deutlich.

Der blinde Fleck der Wiederherstellung in der Architektur der Staatsfinanzen

Souveränitätsprogramme basieren auf Zugriffskontrolle – wer kann auf die Daten zugreifen, mit welcher Berechtigung und auf welchem Weg. Diese Architektur ist notwendig. Sie reicht jedoch nicht aus. Und sie steht in direktem Zusammenhang mit den operativen Souveränitätslücken, die im dritten Beitrag dieser Reihe beleuchtet wurden: Wenn die Personen, die Ihre Umgebung betreiben, außerhalb Ihrer Souveränitätsgrenze agieren, verschwindet dieses Problem während eines Vorfalls nicht. Es wird zum Problem.

Was die Zugriffskontrolle offen lässt, ist die schwierigere Frage: Was geschieht nach einem Vorfall, wenn die Wiederherstellung nicht nur eine technische, sondern auch eine rechtlich geregelte Maßnahme ist?

Ein Ransomware-Angriff auf eine regulierte europäische Organisation führt nicht einfach nur zu einem Problem bei der Wiederherstellung. Er führt zu einem Problem bei der Wiederherstellung, das innerhalb einer bestimmten Rechtsordnung unter Einsatz von Personal mit entsprechenden Berechtigungen und anhand von Wiederherstellungspunkten gelöst werden muss, deren Unversehrtheit und Unbeeinträchtigtheit nachweisbar sind. Die zum Schutz der Daten konzipierte souveräne Architektur kann die Wiederherstellung erschweren, wenn die Ausfallsicherheit nicht bereits in das ursprüngliche Design integriert wurde.

Die spezifischen Ausfallarten

Die Gründe, warum Architekturen zur Wiederherstellung der Souveränität versagen, sind vorhersehbar – und häufig:

• Recovery-Personal außerhalb der Hoheitsgrenze. Die Techniker, die sich mit den Recovery-Systemen auskennen, sind möglicherweise in einer anderen Rechtsordnung tätig. Unter Druck ist der Einsatz dieser Mitarbeiter der Weg des geringsten Widerstands. Dabei handelt es sich zudem um einen Verstoß gegen die Hoheitsvorschriften – und zwar genau in dem Moment, in dem ein solcher Verstoß am wenigsten gelegen kommt.
• Backup-Infrastruktur ohne entsprechende Kontrollmechanismen. Primäre, der staatlichen Hoheitsgewalt unterliegende Umgebungen werden sorgfältig kontrolliert. Die Backup-Infrastruktur – insbesondere ältere oder sekundäre Umgebungen – unterliegt häufig nicht denselben Anforderungen an die staatliche Hoheitsgewalt. Werden Wiederherstellungspunkte außerhalb dieser Grenzen gespeichert oder verarbeitet, ist eine konforme Wiederherstellung über eine konforme Infrastruktur nicht möglich.
• Schlüsselverwaltung unter Krisenbedingungen. Regelungen zur eigenverantwortlichen Schlüsselverwaltung sind für den Normalbetrieb ausgelegt. Unter Krisenbedingungen – wenn primäre Systeme ausgefallen sind und der Zeitdruck groß ist – kann das Modell der Schlüsselverwaltung, das im Rahmen eines routinemäßigen Wartungsfensters funktioniert, zu einem Hindernis für die Wiederherstellung werden. Wenn dies nicht getestet wurde, handelt es sich um eine Annahme und nicht um eine Kontrollmaßnahme.
• Lücken in der umgebungsübergreifenden Governance. Unternehmen, die in mehreren Rechtsräumen tätig sind – was auf die meisten von ihnen zutrifft –, verfügen häufig über strenge Kontrollmechanismen in primären Umgebungen und schwächere Kontrollmechanismen in sekundären Umgebungen, die ebenfalls Teil des Wiederherstellungspfads sind. Die Prüfer achten vor allem auf Konsistenz über die gesamte Infrastruktur hinweg. Lücken in sekundären Umgebungen werden genau dann sichtbar, wenn Konsistenz am wichtigsten ist.

Warum staatliche Kontrollen die Wiederherstellung erschweren können

Genau jene Kontrollen, die eine souveräne Umgebung gegenüber einem Prüfer vertretbar machen, können die Recovery erschweren. Beschränkungen des Datenverkehrs, die eine unbefugte Exfiltration verhindern, schränken auch die Koordination der Recovery ein. Wichtige Verwahrungsvereinbarungen, die sicherstellen, dass kein Anbieter ohne Genehmigung auf Ihre Daten zugreifen kann, verursachen ebenfalls Reibungsverluste, wenn eine schnelle Recovery erforderlich ist.

Das bedeutet keineswegs, dass diese Kontrollmaßnahmen falsch sind. Es bedeutet vielmehr, dass sie von Anfang an unter Berücksichtigung der Wiederherstellung konzipiert werden müssen – und nicht erst nachträglich in eine Architektur integriert werden dürfen, bei der die Wiederherstellung erst im Nachhinein berücksichtigt wurde. Das ist der Kern des Prinzips der „Minimum Viable Sovereignty“: Die Abstimmung der Kontrollmaßnahmen auf die tatsächlichen Anforderungen umfasst auch die Anforderungen an die Wiederherstellung, nicht nur die Anforderungen an die Zugriffskontrolle.

Was „Sovereignty-Ready Resilience“ erfordert

• Eindeutige Validierung der Wiederherstellung. Der Nachweis, dass Wiederherstellungspunkte vor der Wiederherstellung in der Produktionsumgebung nicht kompromittiert sind – nicht nur aktuell, sondern auch zuvor. In einem Ransomware-Szenario kann ein aktuelles Backup selbst kompromittiert sein. Die Fähigkeit, einen als sicher bekannten Wiederherstellungspunkt zu identifizieren und von diesem aus wiederherzustellen – der validiert wurde, bevor er benötigt wird –, ist eine Souveränitätsanforderung, nicht nur eine Anforderung an die Notfallwiederherstellung.
• Umgebungsübergreifende Governance. Einheitliche Souveränitätskontrollen und Prüfnachweise über die gesamte Infrastruktur hinweg – nicht nur für die primäre souveräne Bereitstellung. Jede Umgebung im Wiederherstellungspfad muss dieselben Anforderungen erfüllen wie die primäre Umgebung.
• Unter realistischen Bedingungen getestet. Regelmäßige Übungen, die die Wiederherstellung unter den Bedingungen validieren, die bei einem Vorfall tatsächlich herrschen werden: die geltenden rechtlichen Auflagen, das verfügbare Personal, die sauberen Wiederherstellungspunkte. Ein jährlicher Disaster-Recovery-Test, der souveränitätsrechtliche Auflagen nicht berücksichtigt, ist keine souveränitätsgerechte Übung.

Die Frage, die Sie Ihrer „Sovereignty Review“ hinzufügen sollten

Es gibt einen direkten Weg, um zu prüfen, ob Ihre Wiederherstellungsarchitektur dieselben Souveränitätsanforderungen erfüllt wie Ihre primäre Datenumgebung: Stellen Sie diese Frage und verlangen Sie eine ehrliche Antwort. Können Sie Ihre hoheitlichen Daten sauber und innerhalb festgelegter Toleranzen wiederherstellen – und zwar mit Personal, das innerhalb Ihrer Hoheitsgrenzen tätig ist – und zwar sofort, unter realen Bedingungen und nicht im Rahmen einer kontrollierten Übung?

Für die meisten Organisationen offenbart die ehrliche Antwort eine Lücke. Die Organisationen, die diese Lücke jetzt – noch vor dem Vorfall – entdecken, werden am besten vorbereitet sein und entsprechende Nachweise vorlegen können, wenn die Aufsichtsbehörde danach fragt. Diejenigen, die dies nicht tun, werden unter Druck und vor den Augen der Menschen, die sie am wenigsten enttäuschen wollen, entsprechende Nachweise zusammenstellen müssen. Der „Digital Sovereignty Readiness Report“ enthält eine Frage zur Bewertung der Architektur für die direkte Wiederherstellung.

FAQs

F: Warum ist die Wiederherstellung für die digitale Souveränität wichtig?

A: Souveränität ist unvollständig, wenn Organisationen Daten nicht innerhalb derselben rechtlichen und betrieblichen Grenzen wiederherstellen können, die zu deren Schutz dienen.

F: Was sind häufige Fehler bei der souveränen Recovery?

A: Zu den häufigsten Fehlern zählen unter anderem, dass das Wiederherstellungspersonal außerhalb der Hoheitsgrenzen tätig ist, dass die Backup-Infrastruktur nicht über entsprechende Kontrollmechanismen verfügt und dass die Governance in den verschiedenen Umgebungen uneinheitlich ist.

F: Inwiefern kann die Schlüsselverwahrung die Recovery erschweren?

A: Modelle mit eigenen Schlüsseln erhöhen die Sicherheit im Normalbetrieb, können jedoch die Wiederherstellungsmaßnahmen im Falle eines Vorfalls verlangsamen, wenn sie nicht ordnungsgemäß getestet wurden.

F: Was ist eine Validierung der sauberen Recovery?

A: Eine Validierung der „sauberen“ Wiederherstellung stellt sicher, dass die Wiederherstellungspunkte nicht kompromittiert sind, bevor die Systeme wiederhergestellt werden. Dies ist insbesondere bei Ransomware-Angriffen von großer Bedeutung.

F: Wie sollten Unternehmen ihre „souveränitätsfähige“ Resilienz testen?

A: Sie sollten realistische Übungen durchführen, die gesetzliche Vorgaben, die Betriebsbereitschaft und validierte Wiederherstellungspunkte berücksichtigen – und nicht nur Standardtests zur Notfallwiederherstellung.

Alex Zinin ist Vice President und General Manager für Managed Service Provider bei Commvault.