Un piano di disaster recovery descrive come ripristinare i servizi informatici dopo un’interruzione grave, in quale ordine e con quali verifiche prima del ritorno in produzione. La presenza di backup è un prerequisito possibile, ma non dimostra che applicazioni, identità, chiavi e collegamenti possano essere ricostruiti entro i tempi necessari all’attività.
Il piano deve produrre una sequenza eseguibile anche quando i sistemi ordinari non sono disponibili. Il riferimento NIST SP 800-34 sulla pianificazione della continuità dei sistemi offre un quadro tecnico per organizzare analisi, strategie, procedure e prove; è un riferimento statunitense, non una prescrizione italiana universale. Per i dati personali, l’articolo 32 del GDPR richiede misure adeguate al rischio, includendo ove appropriato capacità di ripristino e verifica dell’efficacia.
Distinguere ripristino informatico e continuità dell’attività
Il piano di continuità operativa stabilisce come mantenere o riprendere le attività prioritarie, anche con soluzioni organizzative alternative. Il disaster recovery riguarda il recupero dei sistemi che le sostengono. Devono essere collegati: un’applicazione ripristinata non rende operativo un reparto se mancano personale, accessi o dati aggiornati.
Individuare servizi prioritari, proprietari e dipendenze. Un portale può dipendere da identità, DNS, rete, database, archivio documentale e servizio di firma. Ripristinare il solo server applicativo non risolve l’indisponibilità se le credenziali o le chiavi restano irraggiungibili.
La mappatura dei sistemi e dei flussi deve quindi diventare una mappa di dipendenze di recupero. Inserire anche fornitori e contatti alternativi, verificando che siano accessibili senza la posta aziendale compromessa.
Definire RTO e RPO con il responsabile del servizio
L’RTO rappresenta il tempo obiettivo di ripristino; l’RPO descrive il punto di recupero dei dati e quindi la perdita temporale di aggiornamenti che si intende tollerare. Sono obiettivi da motivare rispetto all’attività e da verificare tecnicamente, non valori da scegliere perché comuni in un modello.
Un servizio può richiedere ripresa rapida ma tollerare una certa ricostruzione manuale; un altro può accettare più attesa ma non la perdita di operazioni. Esplicitare queste differenze. Il responsabile dell’attività deve comprendere l’effetto pratico: quali ordini, pagamenti o documenti potrebbero dover essere riconciliati?
Nel piano indicare quando parte la misurazione, quale evento segna il recupero e quali funzionalità devono essere disponibili. Un test che misura soltanto il tempo di copia dei file non prova il raggiungimento dell’RTO del servizio completo.
Scegliere una strategia di recupero coerente
Valutare ricostruzione da copie, ambiente alternativo, replica o combinazioni. La replica può ridurre alcuni tempi, ma può propagare cancellazioni, errori e cifratura malevola. Una copia separata e protetta risponde a un rischio diverso dalla disponibilità immediata di un secondo ambiente.
La regola tecnica comunemente indicata come 3-2-1 può essere un punto di discussione sulla diversificazione delle copie, non una prova sufficiente di recuperabilità né un requisito generale del GDPR. Verificare indipendenza, integrità, protezione delle credenziali e possibilità di recuperare le copie quando l’ambiente principale è compromesso.
La gestione della cifratura e delle chiavi deve includere il recupero. Un backup cifrato con una chiave disponibile soltanto nel sistema perduto può risultare inutilizzabile. Le procedure di emergenza per le chiavi devono essere protette e collaudate senza renderle accessibili a chiunque.
Scrivere una sequenza con condizioni di ingresso e uscita
Ogni fase dovrebbe indicare prerequisiti, azione, responsabile, risultato atteso e controllo. Evitare istruzioni come «ripristinare il database» senza specificare copia selezionata, dipendenze e verifica dell’integrità. Prevedere il punto in cui interrompere il percorso se una prova fallisce.
| Fase | Controllo prima di procedere |
|---|---|
| Attivazione | Incidente qualificato e autorità decisionale identificata |
| Ambiente di recupero | Accessi e rete protetti, assenza di collegamenti rischiosi |
| Identità e servizi di base | Credenziali, risoluzione nomi e tempo funzionanti |
| Dati | Copia scelta, integrità e punto di recupero verificati |
| Applicazione | Configurazione e dipendenze coerenti |
| Collaudo funzionale | Operazioni essenziali completate con esito atteso |
| Riapertura | Decisione del responsabile e monitoraggio rafforzato |
La sequenza deve essere disponibile anche fuori dagli strumenti ordinari. Una copia di emergenza controllata può essere necessaria, con gestione delle versioni e protezione dei dettagli sensibili. Verificare periodicamente che recapiti e istruzioni corrispondano alle configurazioni attuali.
Trattare il ransomware come un recupero in ambiente potenzialmente ostile
Quando l’incidente coinvolge una compromissione, ripristinare rapidamente sulla stessa infrastruttura può reintrodurre il problema. Coordinare indagine, contenimento e ricostruzione. Identificare il punto di recupero attendibile e verificare credenziali, persistenza e accessi del fornitore prima di riaprire.
I log di sicurezza aiutano a ricostruire tempi e attività, ma la loro assenza va dichiarata come limite. Non dedurre automaticamente che non vi sia stata esfiltrazione perché il ripristino è riuscito o perché nessun allarme l’ha segnalata.
La valutazione della violazione di dati personali deve proseguire in parallelo. La comunicazione del data breach agli interessati dipende dal rischio elevato e dalle condizioni dell’articolo 34, non dal solo stato di disponibilità del servizio dopo il recupero.
Un esempio ipotetico di prova di recupero
Una società definisce per il portale ordini un obiettivo di ripristino di otto ore e un punto di recupero massimo di un’ora. Questi valori appartengono all’esempio e devono essere giustificati dall’analisi dell’attività. Il test usa un ambiente isolato e una copia verificata, con ordini sintetici per il controllo funzionale.
L’IT recupera identità, database e applicazione in sei ore. Il responsabile commerciale scopre però che il collegamento al magazzino richiede una configurazione non inclusa nella procedura. Il servizio completo torna disponibile dopo nove ore: l’RTO non è raggiunto, anche se la copia tecnica è terminata prima.
Il verbale registra inoltre una differenza tra il punto di recupero del database e quello dei documenti allegati. Il piano correttivo introduce una verifica di coerenza tra i due archivi e aggiunge la dipendenza dal magazzino. La prova successiva riguarda questi passaggi, con un nuovo controllo delle operazioni essenziali.
Riconciliare ciò che è avvenuto durante l’interruzione
Durante il fermo possono essere raccolti ordini su moduli, registrate operazioni offline o usati canali alternativi. Stabilire come trasferire queste informazioni nel sistema ripristinato senza duplicare operazioni o perdere la tracciabilità. Assegnare chi verifica la completezza e chi risolve i conflitti.
La gestione dell’esattezza è rilevante anche nel recupero. Due versioni dello stesso recapito o stato di pagamento possono produrre errori dopo la riapertura. Il piano deve indicare quale fonte prevale e come registrare le correzioni.
Verificare inoltre che il ripristino non annulli cancellazioni, opposizioni o modifiche dei permessi avvenute dopo la copia recuperata. Le istruzioni di recupero devono applicare nuovamente questi eventi prima che i dati rientrino nell’uso ordinario.
Preparare il ritorno e la chiusura dell’emergenza
Il ritorno dall’ambiente alternativo richiede una decisione propria. Controllare sincronizzazione, integrità, prestazioni, accessi e possibilità di tornare indietro se il passaggio fallisce. Evitare due ambienti attivi che accettano contemporaneamente modifiche non riconciliate.
La politica di sicurezza informatica deve prevedere chi autorizza la chiusura dell’emergenza e il ripristino dei controlli temporaneamente modificati. Un privilegio aggiunto per il recupero non dovrebbe restare aperto indefinitamente perché nessuno ne ha registrato la scadenza.
Conservare tempi osservati, problemi, azioni e decisioni. La gestione del rischio residuo consente alla direzione di conoscere ciò che il piano non ha ancora dimostrato. Una prova fallita produce informazione utile se viene corretta; presentarla come successo per il solo fatto che i file sono leggibili rende il piano meno affidabile.