Disaster recovery: l'assicurazione che nessuno vuole pagare finché non ne ha bisogno

Esiste una categoria di investimento che ogni manager sa di dover fare e a cui quasi nessuno dà la priorità: quella il cui valore appare solo nel giorno peggiore. Il disaster recovery è l’esempio perfetto. Anche se tutto funziona, sembra che i soldi siano sprecati. Quando il server prende fuoco, il ransomware crittografa tutto o il data center si allaga, diventa la cosa più importante del mondo.

Il problema è che il momento di scoprire se hai un piano non può essere il momento del disastro. In quel momento, o il piano esiste e funziona, oppure l’organizzazione scopre, nel peggiore dei casi, di operare senza rete di sicurezza.

Questo articolo è un'introduzione al concetto per coloro che non lo trattano ancora con la serietà che richiede. Non è un manuale tecnico, è una spiegazione del motivo per cui il disaster recovery dovrebbe essere all'ordine del giorno di qualsiasi leader il cui funzionamento dipende dai sistemi. E oggi sono praticamente tutti.

Cos'è in realtà il ripristino di emergenza

Il disaster recovery è l'insieme di piani, processi e risorse che consentono a un'organizzazione di ripristinare le proprie operazioni dopo un evento che le ha gravemente interrotte. L'acronimo tecnico è DR, che sta per disaster recovery, e rientra in un concetto più ampio: la continuità aziendale.

La differenza tra le due cose conta. La continuità aziendale si chiede “come possiamo mantenere operative le operazioni durante una crisi?” Il disaster recovery si chiede “come possiamo tornare operativi dopo che qualcosa ci ha messo al tappeto?” Uno si occupa del durante, l'altro del dopo.

Il punto centrale è che un disastro, in questo contesto, non significa semplicemente una catastrofe naturale. Significa qualsiasi evento che renda i tuoi sistemi o i tuoi dati non disponibili: un guasto hardware, un errore umano che cancella la base produttiva, un attacco ransomware, il crollo di un cloud provider. La maggior parte dei veri “disastri” sono banali e quindi comuni.

La tesi: il disastro non è un'eccezione, è statistica

Il modo più pericoloso di pensare a questo problema è considerare il disastro come qualcosa che difficilmente accadrà ad altri. Io sostengo il contrario: il disastro è una certezza distribuita nel tempo. Non sai quando, ma sai che qualcosa andrà storto.

I dischi falliscono. Le persone commettono errori. Gli aggressori esistono e sono instancabili. I fornitori hanno interruzioni. Sommando tutto questo nel corso degli anni di attività di un'organizzazione, la domanda smette di essere "se" e diventa "quando" e "quanto saremo preparati".

Coloro che interiorizzano questa logica smettono di vedere il disaster recovery come pessimismo e iniziano a vederlo come una gestione del rischio di base. È lo stesso ragionamento dell'assicurazione auto o di un estintore: non lo compri sperando di usarlo, lo compri perché il costo di non averlo quando ti serve è troppo alto.

I due numeri che definiscono ogni piano

Il disaster recovery sembra astratto finché non si apprendono due concetti che lo rendono concreto e misurabile.

RTO, Tempo di recupero obiettivo. Per quanto tempo è possibile interrompere l'operazione prima che il danno diventi grave? Minuti? Ore? Giorni? Questo numero definisce la velocità con cui il tuo piano deve ripristinare i sistemi.

RPO, Recovery Objective Point. Quanti dati puoi permetterti di perdere? Se l'ultimo backup è stato effettuato ventiquattr'ore fa e il disastro si verifica ora, si perde un giorno di informazioni. L'RPO definisce la frequenza con cui è necessario salvare.

Questi due numeri traducono una decisione aziendale in requisiti tecnici. E sono rivelatori: molte organizzazioni scoprono, nel momento in cui li definiscono, che tollerano meno perdite e meno tempi di inattività di quanto immaginassero e che i backup di cui dispongono non sono altrettanto buoni.

Perché il backup non è la stessa cosa del ripristino

L'errore più comune e più pericoloso: confondere il backup con il disaster recovery. Sono cose diverse e la differenza costa.

Il backup è la copia dei dati. Il ripristino è la comprovata capacità di ripristinare il funzionamento da esso. Molte organizzazioni hanno effettuato religiosamente backup che non sono mai stati testati. Il giorno del disastro scoprono che il backup era danneggiato, incompleto o che nessuno sa come ripristinarlo oppure che il ripristino richiede molto più tempo di quanto l'operazione possa gestire.

Un backup che non è mai stato testato non è un piano. È una speranza. La differenza appare esattamente nel momento in cui non è più possibile correggerla.

Negli incidenti ransomware, questa distinzione è diventata esistenziale. Gli aggressori moderni prendono di mira i backup prima di crittografare la produzione, sapendo che senza di essi la vittima non avrebbe via d’uscita. Isolare e testare il backup non è più una buona pratica ed è diventata una questione di sopravvivenza.

Il lato umano e organizzativo

C’è una dimensione che i piani tecnici tendono a ignorare: il giorno del disastro, sono le persone sotto stress a eseguire il piano. Se esiste solo nella testa di una persona, o in un documento che nessuno ha letto, non funzionerà quando la pressione è al massimo.

Un vero piano deve essere chiaramente documentato, con ruoli definiti: chi decide, chi esegue, chi comunica. Ha bisogno di essere provato, come un’esercitazione antincendio, in modo che in un momento critico le persone sappiano cosa fare senza improvvisare. E devi considerare lo scenario in cui la persona chiave non sarà disponibile proprio quel giorno.

Nel settore pubblico ciò assume un peso aggiuntivo. Quando un sistema sanitario, di riscossione delle tasse o di servizi ai cittadini crolla, non è solo l’organizzazione a soffrire, è la popolazione che dipende da quel servizio. Nella continuità c'è una responsabilità pubblica, non una convenienza operativa.

La riflessione che cambia priorità

La trappola culturale è l’ottimismo. “Non ci è mai successo nulla” è la frase che precede la maggior parte dei disastri irrisolti. L’assenza di incidenti non è prova di sicurezza, è solo fortuna che non sia ancora finita.

Il disaster recovery è, in sostanza, una prova di maturità della leadership. I team immaturi investono solo in ciò che genera risultati visibili. Le squadre mature investono anche in ciò che impedisce perdite catastrofiche, anche senza applausi. È la differenza tra gestire la buona giornata e gestire la brutta giornata che inevitabilmente arriverà.

Quando arriva il disastro, e succede, l’organizzazione che si è preparata ha una storia di paura e ripresa. Coloro che non erano preparati hanno una storia di crisi, perdita e, talvolta, fine. La scelta tra queste due storie viene fatta oggi, nel giorno in cui sembra che nulla andrà storto.

Se la tua organizzazione non ha mai realmente testato cosa accadrebbe in caso di perdita totale dei dati, questo potrebbe essere un segno che è giunto il momento. Ci sono altri articoli sul blog su sicurezza, backup e continuità che approfondiscono l'argomento. Se questa è una preoccupazione reale nel tuo contesto, vale la pena parlarne prima che la questione diventi urgente.