Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Die wichtigsten Erkenntnisse

• Bei souveränen Architekturen wird häufig der Schwerpunkt eher auf Audits und Zugriffskontrollen als auf die Wiederherstellungsbereitschaft gelegt.
• Personal für die Wiederherstellung, Backup-Systeme und Modelle zur Verwahrung von Schlüsseln 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 den Moment 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 einem sekundären Standort gehostet wird) unterlag nie denselben hoheitsrechtlichen Kontrollen wie die Primärdaten.

Die Praxis unterliegt 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 hoheitsbezogenen Architekturen nicht konzipiert wurden – und dasjenige, das die „Digital Sovereignty Readiness Report“Â macht direkt darauf aufmerksam: Die meisten Sicherheitsanwendungen sind auf das Audit ausgelegt, nicht auf den Vorfall. Der Unterschied wird im ungünstigsten Moment deutlich.

Der blinde Fleck der Erholung in der Architektur der Staatsfinanzen

Souveränitätsprogramme basieren auf Zugriffskontrolle – wer kann auf die Daten zugreifen, mit welcher Berechtigung und über welchen 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 Zugangskontrolle 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-Kräfte außerhalb der Hoheitsgrenze. Die Ingenieure, die sich mit den Recovery-Systemen auskennen, sind möglicherweise in einem anderen Hoheitsgebiet tätig. Unter Druck ist der Einsatz dieser Kräfte der Weg des geringsten Widerstands. Es handelt sich dabei zudem um eine Verletzung der Hoheitsrechte – und zwar genau in dem Moment, in dem dies am wenigsten gelegen kommt.
• Backup-Infrastruktur ohne entsprechende Kontrollmechanismen. Primäre, hoheitsrechtlich regulierte Umgebungen unterliegen einer sorgfältigen Kontrolle. Die Backup-Infrastruktur – insbesondere ältere oder sekundäre Umgebungen – unterliegt häufig nicht denselben hoheitsrechtlichen Anforderungen. Werden Wiederherstellungspunkte außerhalb der Grenzen gespeichert oder verarbeitet, ist eine konforme Recovery ü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 Hoheitsgebieten 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 Erholung erschweren können

Dieselben Kontrollen, die eine souveräne Umgebung gegenüber einem Prüfer vertretbar machen, können die Recovery erschweren. Beschränkungen der Datenbewegung, 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

• Saubere Validierung der Wiederherstellung. Der Nachweis, dass Wiederherstellungspunkte vor der Wiederherstellung in der Produktionsumgebung frei von Kompromittierungen sind – nicht nur aktuell, sondern auch unbeeinträchtigt. In einem Ransomware-Szenario kann ein aktuelles Backup selbst kompromittiert sein. Die Fähigkeit, einen als sauber bekannten Wiederherstellungspunkt zu identifizieren und von diesem aus wiederherzustellen – der bereits vor seinem Einsatz validiert wurde –, ist eine Anforderung an die Souveränität und 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 Ursachen für das Scheitern der Recovery staatlicher Schulden?

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 Verwahrung von Schlüsseln die Recovery erschweren?

A: Modelle mit eigenem Schlüssel 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 versteht man unter der Validierung einer 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 Organisationen ihre „souveränitätsfähige“ Resilienz testen?

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

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