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.
Picture the moment. The attack has already happened. The incident response team is assembling. Someone must decide which systems come back first, in what order, using the correct recovery points.
And then someone realizes: The personnel with recovery system access are based in a different country. Worse, the recovery environment itself (hosted in a cloud region, a partner datacenter, or a secondary site) was never subject to the same sovereignty controls as the primary data.
The practice wasn’t subject to the same sovereignty controls as the primary data. The regulator is asking for status. The clock is running.
This is the scenario most sovereign architectures were not designed for – and the one the „„Digital Sovereignty Readiness Report““ calls out directly: most sovereign applications are designed for the audit, not the incident.
Most sovereign applications are designed for the audit, not the incident. The difference becomes visible at the worst possible moment.
Der blinde Fleck der Erholung in der Architektur der Staatsfinanzen
Sovereignty programs are built around access control – who can reach the data, under what authority, through what pathway. That architecture is necessary. It is not sufficient. And it connects directly to the operational sovereignty gaps die im dritten Beitrag dieser Reihe beleuchtet wurden: If the people who run your environment operate outside your sovereignty boundary, that problem doesn’t disappear during an incident. It becomes the problem.
What access control leaves unanswered is the harder question: What happens after an incident, when recovery is not just a technical operation but a legally constrained one?
A ransomware attack on a regulated European organization doesn’t simply create a recovery problem. It creates a recovery problem that must be solved within a jurisdiction, using personnel with appropriate authorizations, against recovery points that can be demonstrated to be clean and uncompromised.
The sovereign architecture designed to protect the data can make recovery harder if resilience wasn’t built into the original design.
Die spezifischen Ausfallarten
The ways sovereign recovery architectures fail are predictable – and common:
- 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 infrastructure without matching controls. Primary sovereign environments are carefully controlled. Backup infrastructure – particularly older or secondary environments – is frequently not subject to the same sovereignty requirements. If recovery points are stored or processed outside the boundary, compliant recovery is not available from compliant infrastructure.
- Key custody under crisis conditions. Hold-your-own-key arrangements are designed for normal operations. Under crisis conditions – with primary systems compromised and time pressure acute – the key custody model that works in a routine maintenance window may become an obstacle to recovery. If this hasn’t been tested, it’s an assumption, not a control.
- Cross-environment governance gaps. Organizations operating across multiple sovereign tiers – which is most of them – often have strong controls in primary environments and weaker controls in secondary environments that are also part of the recovery path. Consistency across the full estate is what auditors will look for. Gaps in secondary environments become visible exactly when consistency matters most.
Warum staatliche Kontrollen die Erholung erschweren können
The same controls that make a sovereign environment defensible to an auditor can make it harder to recover from. Data movement restrictions that prevent unauthorized exfiltration also constrain recovery orchestration. Key custody arrangements that ensure no provider can access your data without authorization also add friction when you need to restore quickly.
None of this means these controls are wrong. It means they have to be designed with recovery in mind from the start – not added to an architecture where recovery was an afterthought. This is the core of the minimum viable sovereignty principle: Calibrating controls to actual requirements includes recovery requirements, not just access control requirements.
Was „Sovereignty-Ready Resilience“ erfordert
- Clean recovery validation. Proving that recovery points are free from compromise before restoring to production – not just recent, but uncompromised. In a ransomware scenario, a recent backup may itself be compromised. The ability to identify and restore from a known-clean recovery point, validated before it’s needed, is a sovereignty requirement, not just a disaster recovery requirement.
- Cross-environment governance. Consistent sovereignty controls and audit evidence across the full estate – not just the primary sovereign deployment. Every environment in the recovery path must meet the same requirements as the primary environment.
- Tested under realistic conditions. Regular exercises that validate recovery under the conditions that will actually exist during an incident: the legal constraints that apply, the personnel who are available, the recovery points that are clean. An annual disaster recovery test that doesn’t account for sovereignty constraints is not a sovereignty-ready exercise.
Die Frage, die Sie Ihrer „Sovereignty Review“ hinzufügen sollten
There is a direct way to assess whether your recovery architecture meets the same sovereignty requirements as your primary data environment: Ask it as a question and require an honest answer.
Can you recover your sovereign data, cleanly, within defined tolerances, using personnel operating within your sovereignty boundary, right now – under real conditions, not a controlled exercise?
For most organizations, the honest answer reveals a gap. The organizations that find it now – before the incident – will be best prepared with evidence when the regulator asks for it. The ones that don’t will be building it under pressure, in front of the people they least want to disappoint.
The „„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: They should conduct realistic exercises that account for legal constraints, operational availability, and validated recovery points – not just standard disaster recovery testing.
Alex Zinin ist Vice President und General Manager für den Bereich Managed Service Providers bei Commvault.
