I dati sovrani che non è possibile recuperare non sono in realtà sovrani

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 gestione 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.

Immaginate la situazione. L’attacco è già avvenuto. Il team di risposta agli incidenti si sta riunendo. Qualcuno deve decidere quali sistemi ripristinare per primi, in quale ordine, utilizzando i punti di Recovery corretti.

E poi qualcuno si rende conto che: il personale che ha accesso al sistema di ripristino ha sede in un altro Paese. Peggio ancora, lo stesso ambiente di ripristino (ospitato in un cloud, in un data center di un partner o in un sito secondario) non è mai stato sottoposto agli stessi controlli di sovranità dei dati primari. La pratica non era soggetta agli stessi controlli di sovranità dei dati primari. L’autorità di regolamentazione sta richiedendo informazioni sullo stato della situazione. Il tempo stringe.

Questo è lo scenario per cui la maggior parte delle architetture sovrane non è stata progettata – ed è proprio ciò che il Rapporto sulla preparazione alla sovranità digitale evidenzia chiaramente: la maggior parte delle applicazioni sovrane è progettata per gli audit, non per gli incidenti. La maggior parte delle applicazioni di sicurezza è progettata per gli audit, non per gli incidenti. La differenza emerge nel momento peggiore possibile.

Il punto cieco della ripresa nell’architettura sovrana

I programmi di sovranità sono costruiti attorno al controllo degli accessi: chi può accedere ai dati, con quale autorizzazione, attraverso quale percorso. Tale architettura è necessaria. Ma non è sufficiente. E si ricollega direttamente alle lacune operative in materia di sovranità esaminate nel terzo articolo di questa serie: se le persone che gestiscono il vostro ambiente operano al di fuori dei confini della vostra sovranità, quel problema non scompare durante un incidente. Diventa il problema.

Ciò che il controllo degli accessi lascia in sospeso è la domanda più complessa: cosa succede dopo un incidente, quando il ripristino non è solo un’operazione tecnica, ma è soggetto a vincoli legali?

Un attacco ransomware ai danni di un’organizzazione europea soggetta a regolamentazione non comporta semplicemente un problema di ripristino. Comporta un problema di ripristino che deve essere risolto nell’ambito di una giurisdizione specifica, avvalendosi di personale in possesso delle autorizzazioni appropriate e utilizzando punti di ripristino di cui sia possibile dimostrare che siano integri e non compromessi. L’architettura sovrana progettata per proteggere i dati può rendere più difficile il ripristino se la resilienza non è stata integrata nella progettazione originale.

Le modalità specifiche di guasto

I modi in cui le architetture di recupero sovrano falliscono sono prevedibili – e comuni:

• 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. Sotto pressione, ricorrere a loro rappresenta la via più facile. Si tratta inoltre di una violazione della sovranità proprio nel momento in cui è meno opportuno che ciò avvenga.
• Infrastruttura di backup priva di controlli adeguati. Gli ambienti primari soggetti a requisiti di sovranità sono attentamente controllati. L’infrastruttura di backup – in particolare gli ambienti più datati o secondari – spesso non è soggetta agli stessi requisiti di sovranità. Se i punti di ripristino vengono archiviati o elaborati al di fuori dei confini previsti, non è possibile effettuare un ripristino conforme a partire da un’infrastruttura conforme.
• Custodia delle chiavi in situazioni di crisi. Le modalità di gestione delle chiavi in cui ciascuno ne detiene una propria sono concepite per le operazioni di routine. In situazioni di crisi – con i sistemi primari compromessi e tempi estremamente ristretti – il modello di custodia delle chiavi che funziona durante una finestra di manutenzione ordinaria può diventare un ostacolo al ripristino. Se non è stato testato, si tratta di un’ipotesi, non di un controllo.
• Lacune nella governance tra ambienti diversi. Le organizzazioni che operano su più livelli sovrani – ovvero la maggior parte di esse – spesso dispongono di controlli rigorosi negli ambienti primari e di controlli meno rigorosi negli ambienti secondari, che fanno comunque parte del percorso di ripristino. La coerenza nell’intero parco sistemi è ciò che gli auditor verificheranno. Le lacune negli ambienti secondari diventano evidenti proprio quando la coerenza è più importante.

Perché i controlli sulla sovranità possono complicare il ripristino

Gli stessi controlli che rendono un ambiente sovrano difendibile di fronte a un revisore possono rendere più difficile il Recovery. Le restrizioni alla circolazione dei dati che impediscono l’esfiltrazione non autorizzata limitano anche l’orchestrazione del Recovery. Gli accordi chiave di custodia che garantiscono che nessun fornitore possa accedere ai dati senza autorizzazione aggiungono ulteriore attrito quando è necessario il Recovery rapido.

Ciò non significa affatto che questi controlli siano sbagliati. Significa piuttosto che devono essere progettati fin dall’inizio tenendo conto del ripristino, e non aggiunti a un’architettura in cui il ripristino è stato considerato solo in un secondo momento. Questo è il fulcro del principio della «sovranità minima praticabile»: calibrare i controlli in base alle esigenze effettive significa includere i requisiti di ripristino, non solo quelli relativi al controllo degli accessi.

Cosa richiede una resilienza orientata alla sovranità

• Convalida del ripristino pulito. Dimostrare che i punti di ripristino siano integri prima di ripristinare l’ambiente di produzione – non solo recenti, ma integri. In uno scenario di ransomware, anche un backup recente potrebbe essere compromesso. La capacità di identificare e ripristinare da un punto di ripristino notoriamente integro, convalidato prima che sia necessario, è un requisito di sovranità, non solo un requisito di disaster recovery.
• Governance trasversale agli ambienti. Controlli di sovranità e prove di audit coerenti in tutto il parco informatico, non solo nell’implementazione sovrana primaria. Ogni ambiente presente nel percorso di ripristino deve soddisfare gli stessi requisiti dell’ambiente primario.
• Testati in condizioni realistiche. Esercitazioni periodiche che verifichino la capacità di ripristino nelle condizioni che si verificheranno effettivamente durante un incidente: i vincoli normativi applicabili, il personale disponibile, i punti di ripristino funzionanti. Un test annuale di ripristino di emergenza che non tenga conto dei vincoli di sovranità non è un’esercitazione adeguata ai requisiti di sovranità.

La domanda da aggiungere alla tua analisi sulla sovranità

Esiste un modo diretto per verificare se la vostra architettura di ripristino soddisfa gli stessi requisiti di sovranità del vostro ambiente dati primario: ponete la domanda e pretendete una risposta sincera. Siete in grado di recuperare i vostri dati sovrani, in modo accurato, entro i limiti di tolleranza definiti, avvalendovi di personale che opera all’interno dei confini della vostra sovranità, proprio ora – in condizioni reali, non nell’ambito di un’esercitazione controllata?

Per la maggior parte delle organizzazioni, una risposta sincera mette in luce una lacuna. Le organizzazioni che la individuano ora – prima che si verifichi l’incidente – saranno meglio preparate a fornire le prove richieste dall’autorità di regolamentazione. Quelle che non lo faranno dovranno metterle insieme sotto pressione, di fronte alle persone che meno vorrebbero deludere. Il Rapporto sulla preparazione alla sovranità digitale include una domanda relativa alla valutazione dell’architettura di ripristino diretto.

Domande frequenti

D: Perché la resilienza è importante per la sovranità digitale?

R: 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 gli errori più comuni nel Recovery sovrano?

R: Tra gli errori 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 Recovery?

R: 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 ripristino 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à?

R: Dovrebbero condurre esercitazioni realistiche che tengano conto dei vincoli legali, della disponibilità operativa e dei punti di ripristino convalidati – senza limitarsi a semplici test standard di ripristino di emergenza.

Alex Zinin è vicepresidente e direttore generale della divisione Managed Service Providers presso Commvault.