Punti di forza
- Le architetture sovrane spesso danno priorità agli audit e ai controlli di accesso rispetto alla prontezza al ripristino.
- Il personale addetto al ripristino, i sistemi di backup e i modelli di custodia delle chiavi possono creare lacune nella sovranità durante gli incidenti.
- È fondamentale garantire controlli coerenti sia nell’ambiente primario che in quello di ripristino.
- Una resilienza a prova di sovranità richiede procedure di ripristino collaudate in condizioni realistiche.
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 Rapporto sulla Readiness per la sovranità digitale 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.
Il punto cieco della ripresa nell’architettura sovrana
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 esaminate nel terzo articolo di questa serie: 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.
Le modalità specifiche di guasto
The ways sovereign recovery architectures fail are predictable – and common:
- Personale addetto al Recovery al di fuori dei confini della sovranità. Gli ingegneri che conoscono i sistemi di Recovery potrebbero operare in una giurisdizione diversa. In situazioni di pressione, ricorrere a loro rappresenta la soluzione più semplice. Si tratta inoltre di una violazione della sovranità proprio nel momento in cui sarebbe meno opportuno che ciò accadesse.
- 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.
Perché i controlli sulla sovranità possono complicare la ripresa
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.
Cosa richiede una resilienza orientata alla sovranità
- 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.
La domanda da aggiungere alla tua analisi sulla sovranità
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 Rapporto sulla Readiness per la sovranità digitaleinclude una domanda relativa alla valutazione dell’architettura di ripristino diretto.
Domande frequenti
D: Perché la resilienza è importante per la sovranità digitale?
A: La sovranità è incompleta se le organizzazioni non sono in grado di recuperare i dati all’interno degli stessi confini giuridici e operativi utilizzati per proteggerli.
D: Quali sono i più comuni casi di fallimento nella Recovery dei crediti sovrani?
A: Tra i guasti più comuni figurano l’intervento del personale addetto al ripristino al di fuori dei confini della sovranità, infrastrutture di backup prive di controlli adeguati e una governance non uniforme tra i vari ambienti.
D: In che modo la custodia delle chiavi può complicare la Recovery?
A: I modelli basati sulla gestione autonoma delle chiavi rafforzano la sicurezza durante il normale funzionamento, ma possono rallentare le operazioni di ripristino in caso di incidenti se non vengono testati adeguatamente.
D: Che cos’è la convalida del recupero pulito?
A: La convalida del ripristino pulito conferma che i punti di ripristino non siano stati compromessi prima del ripristino dei sistemi. Ciò è particolarmente importante in caso di attacchi ransomware.
D: In che modo le organizzazioni dovrebbero verificare la propria resilienza in vista della sovranità?
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 è vicepresidente e direttore generale della divisione Managed Service Providers presso Commvault.
