Fare un disaster recovery plan richiede precise procedure e linee guida che i reparti IT delle aziende devono seguire scrupolosamente. Sempre più spesso, infatti, le organizzazioni si trovano a dover affrontare problemi legati alla protezione di dati e applicazioni in caso di attacchi esterni, eventi che comportano danni ai sistemi e downtime imprevisti. La comparsa inattesa di criticità necessita per l'appunto di essere affrontata con un corretto piano di disaster recovery. Questo perché, senza un’adeguata risposta da parte di tutti i sistemi, le conseguenze possono essere estremamente spiacevoli per il business. Come affrontare la situazione? Un disaster recovery plan deve portare a una soluzione adatta alle dimensioni, alle esigenze e alla tipologia di business. Una serie di operazioni ben definite, che siano in altre parole chiare, versatili e altamente riproducibili.
Prima di studiare le procedure: le linee guida per un disaster recovery plan efficace
Tuttavia, prima di sviluppare un disaster recovery plan dettagliato, che includa quindi anche le procedure da seguire, è necessario eseguire una serie di operazioni propedeutiche. Si parte con una valutazione del rischio (risk assessment) o un'analisi dell'impatto aziendale (business impact analysis), con cui identificare i servizi IT che supportano le attività critiche dell'organizzazione e l’impatto che una possibile interruzione può portare ai processi di business.
Successivamente, si stabiliscono il recovery point objective, che identifica l’ampiezza della finestra temporale di dati che una compagnia è disponibile a perdere a seguito di un disastro senza impattare i processi di business, e il recovery time objective, che indica la tempistica massima entro la quale i sistemi compromessi devono tornare operativi insieme ai processi bloccati. Effettuata una stima di entrambi gli indicatori, si passa a considerare i costi potenziali per il business, sia in caso di assenza di piano (perdita dei clienti, inefficienze lavorative, slittamento degli ordini) sia di implementazione dello stesso (dipendenti responsabili, struttura tecnica, backup, piattaforme on-premise o in cloud).
Le priorità per delineare le procedure di un disaster recovery plan
L’articolazione di un corretto piano di recupero si fonda su procedure validate e codificate in procedure internazionali come la ISO/IEC 22301. Se l’implementazione di ogni strategia vive una storia a sé, per le differenze peculiari di ogni soggetto, ogni disaster recovery plan dovrebbe contemplare una serie di priorità oggettive, che non cambiano nella loro definizione contestuale e dalle quali possono scaturirne delle altre, specifiche e importanti a seconda dell’ambito di riferimento.
Un esempio di disaster recovery plan concreto
È senz’altro possibile fornire un esempio di disaster recovery plan, che come anticipato si articola in un insieme di istruzioni finalizzate a standardizzare la risposta ad eventi potenzialmente dannosi e disruptive.
Come esempio di disaster recovery plan si dovrebbe partire dall’assegnazione dei ruoli. Ciascun dipendente deve essere responsabile di una specifica azione richiesta a seguito di un possibile guasto o disservizio. Basta infatti un solo segnale, inviato in tempo, per allertare i reparti più alti, contenere le perdite e ridurre la crisi.
Bisogna poi stabilire cosa significa reagire alla crisi. Quali azioni vanno intraprese durante l’emergenza? Anche qui, a ogni lavoratore deve corrispondere un ruolo ben specifico mentre è in corso il blackout. A titolo d’esempio di disaster recovery plan, occorre dunque predisporre una procedura d’azione in caso di emergenza che permetta ai tecnici di analizzare l’evento con tutti gli elementi a corredo, così da definire i passi non solo per mitigare la criticità ma anche per muoversi rapidamente verso la soluzione totale del problema.
Non è affatto detto, però, che la situazione ipotizzata nel piano di recupero si realizzi nella sua esattezza durante un’eventuale crisi. I piani attuativi generali di disaster recovery devono essere applicati secondo le direttive dei team addetti, con la giusta dose di flessibilità anche in funzione delle esperienze maturate negli incidenti pregressi.
Se è importante rispondere celermente a un downtime, dunque è forse ancora più fondamentale documentare l’evento, per evitarlo in futuro o comunque capire come affrontarlo meglio. I dettagli del guasto, così come i singoli interventi intrapresi, vanno descritti in maniera puntuale e salvati in repository dedicati. Questo è essenziale anche perché, qualora dovesse essere richiesto l’intervento di un’azienda specializzata, una descrizione precisa dell’accaduto velocizzerà il processo di recupero. E in ogni caso, l'analisi dei dati che ricostruiscono le dinamiche dell'emergenza servirà a perfezionare le procedure del disaster recovery plan.
Un esempio di piano di disaster recovery: la checklist
Nel paragrafo precedente è stata ipotizzata una procedura da adottare in caso di evento disruptive. Nel nostro esempio di piano di disaster recovery, andrebbe anche creata una checklist di elementi che non dovrebbero mai mancare all’interno di una strategia efficace.
La checklist dovrebbe partire da un inventario degli asset IT. Ognuno degli elementi del nostro esempio di piano di disaster recovery andrebbe classificato in funzione del suo livello di criticità nei confronti del business e della compliance. In altri termini, bisogna capire quanto il downtime di ognuno di essi possa impattare la competitività dell’impresa.
Nel piano di disaster recovery efficace non può mancare un elenco di ruoli e del personale coinvolto, perché ognuno deve avere una posizione precisa e sapere come muoversi nel caso di evento disruptive. Basilare è poi definire RPO e RTO per ogni asset IT.
Come affermato precedentemente, l’elemento cardine è la definizione delle procedure, ma anche la corretta identificazione dei recovery sites: l’azienda deve sapere dove sono posizionati i dati e le applicazioni funzionali alle procedure di disaster recovery. Anche in questo caso, bisogna scendere il più possibile nel dettaglio, poiché c’è molta differenza tra un backup periodico e un mirroring di dati in tempo reale tra due data center in grado di sostenere tutto il carico di lavoro richiesto dal business.
Nell’esempio di piano di disaster recovery non può mancare, infine, la procedura di comunicazione. Come gestire i rapporti con tutti gli stakeholder interni ed esterni in caso di evento disruptive? Come modellare la comunicazione a seconda che il destinatario sia un cliente, un dipendente o un organo di vigilanza? Come agire per rimanere compliant con le policy interne e la normativa vigente?
Disaster recovery plan, un percorso in divenire
Cosa ha generato il guasto? Che tipo di attacco è stato subito? Quale infrastruttura è stata lesa? Rispondere a queste e ad altre domande durante il processo di analisi è possibile solo se si ha un inventario aggiornato delle attrezzature utilizzate, sia hardware che software. Ciò aiuta a comprendere meglio l’ecosistema in cui è inserita l'architettura IT e a rafforzarlo dove necessario. Per completare un modello di disaster recovery plan è fondamentale, infine, tenere traccia delle copie di backup, utili a ripristinare uno stato recente del sistema.
Infine, ma non per importanza, bisogna considerare che un disaster recovery deve essere adattato a ogni cambiamento infrastrutturale dell’azienda. Il motivo è semplice: quanto più cresce l’organizzazione, più aumenta la complessità. Tale complessità deve essere vagliata, nella sua interezza, all’interno di un piano di recupero che, altrimenti, coprirebbe solo parte del business, mettendo a rischio tutto il resto.
