Back-Up, Disaster Recovery, Business Continuity

Introduzione
Obbiettivo della proposta è descrivere le basi della questione riguardo la “Business Continuity” ed il “Disaster Recovery”
I temi della continuità operativa e della capacità di risposta a situazioni di emergenza devono essere affrontati in modo globale coinvolgendo tutte le componenti dell'organizzazione aziendale.
Purtroppo gli ultimi eventi dell’Emilia Romagna ci fanno capire che siamo tutti vulnerabili e quindi necessitiamo di qualcosa o qualcuno che ci consenta una continuità operativa di accesso ai sistemi informatici.
La garanzia della continuità operativa e la capacità di rispondere, da parte del sistema informativo, in modo adeguato a situazioni di disastro sono due elementi vitali per le aziende.

Il business continuity planning
Secondo il Business Continuity Institute (http://www.thebci.org/), il Business Continuity Planning (Bcp) è “un termine omnicomprensivo che indica il processo di pianificazione per la ripresa delle attività di business in caso di interruzione”. Come mostra questa definizione, al centro del Bcp ci sono quindi i processi di business, e in particolare quelli critici per l’azienda, la cui interruzione può portare a significative riduzioni dell’operatività complessiva.
Il Bcp non si occupa quindi genericamente della disponibilità e della continuità operativa di tutti i singoli processi aziendali, né tantomeno dei diversi componenti dell’infrastruttura Ict, ma affronta il problema da un punto di vista più complessivo; in quest’ottica, la continuità operativa di alcuni sistemi può essere trascurabile.
Pensiamo per esempio a un server web pubblico aziendale: nonostante si possa ritenere opportuno utilizzare meccanismi di alta disponibilità (High Availability) per evitare interruzioni del servizio in caso di guasti, non è detto che si tratti di un servizio talmente critico da non poterne accettare l’interruzione, magari per diversi giorni, in caso di eventi particolarmente gravi.
Arriviamo quindi a un punto fondamentale: quali sono gli eventi dei quali si occupa la Business Continuity?
Quelli a cui si pensa immediatamente sono gli eventi naturali catastrofici o, soprattutto in tempi recenti, i terremoti, gli attentati terroristici e i blackout. Tuttavia, eventi molto più limitati possono causare riduzioni importanti dell’operatività, anche in funzione delle dimensioni dell’azienda; per una media impresa, per esempio, l’inagibilità prolungata di un edificio, per i motivi più disparati, può essere un problema importante.
In generale, una caratteristica che contraddistingue gli eventi affrontati dal piano di BC è che si tratta di eventi che causano una perdita dell’operatività, e tale operatività richiede un intervento attivo per essere ripristinata. L’attenzione è quindi più su come rimediare alla perdita di operatività, che sulle singole cause di questa perdita. È chiaro che alcune soluzioni tecnologiche (per esempio, nella realizzazione degli edifici) possono prevenire l’interruzione dell’operatività, e quindi prevengono l’insorgere della crisi; per quanto rilevante e legato alle problematiche di Business Continuity, l’utilizzo di queste tecnologie non è di per sé parte del Bcp.
Il caso delle catastrofi naturali è particolarmente interessante perché richiede che i processi critici sopravvivano non a problemi confinati a porzioni dell’azienda, ma a un contesto in cui anche molti servizi essenziali (telefoni, viabilità, energia elettrica) possono essere inutilizzabili anche per alcuni giorni, e in cui l’intera infrastruttura IT può diventare indisponibile.
La gestione della business continuity
In questa fase devono essere individuati processi e funzioni critici per l’azienda, nonché gli eventi che possono danneggiarli in modo rilevante.
Anche nel caso della business continuity è necessaria una valutazione dell’impatto e della probabilità dei diversi accadimenti, nonché una valutazione costi/benefici per quanto riguarda le contromisure. In questo caso, si tratta però di una valutazione particolarmente difficile, se si pensa che l’impatto può arrivare ad essere la cancellazione della capacità dell’azienda di fare business. Due metriche importanti in questa valutazione sono:
il Recovery point objective (Rpo): rappresenta la quantità di dati, misurata in termini di tempo, che si è disposti a perdere (in caso di disastro); ad esempio, l’uso di backup giornalieri comporta la perdita di (al più) una giornata di dati; questo può essere o meno accettabile a seconda del processo;
il Recovery time objective (Rto); dopo quanto tempo è al più accettabile il ripristino dell’operatività di un processo/funzione; alcuni processi possono rimanere fermi per giorni senza particolari danni, mentre altri possono provocare perdite ingenti anche in seguito a pochi minuti di fermo; si noti che la ripresa dell’operatività non è sempre un parametro tutto/niente: spesso la ripresa sarà graduale, inizialmente magari con una disponibilità ridotta di strumenti; in generale, meno sono stringenti i tempi per il ripristino, meno sarà costoso implementare delle soluzioni, e di questo si dovrà ovviamente tenere conto.
Questi parametri misurano quindi le principali esigenze dei processi di business. Essi costituiranno anche i requisiti che dovranno essere soddisfatti dal piano di business continuity (e dalle tecnologie adottate). È necessario individuare infine quali sono gli strumenti e le infrastrutture che sono di supporto per i processi individuati, in quanto saranno quelle interessate dall’effettiva implementazione del piano.
Dovranno quindi essere definite delle “strategie di recovery” che permettano di ripristinare l’operatività in termini e modi compatibili con le esigenze dei processi, particolarmente per quanto riguarda i tempi, e che guideranno la progettazione e l’implementazione del piano di business continuity.
Il Disaster Recovery Planning
In generale, l’attuazione di un piano di recovery può essere divisa in diverse fasi:

• la risposta all’emergenza: si tratta delle procedure da attuare immediatamente come risposta a un’emergenza, per esempio, i piani di evacuazione;
• l’attivazione del piano: comporta il riconoscimento della situazione di disastro e l’attivazione delle procedure di gestione;
• una fase di recovery;
• una fase di ricostruzione, di lungo termine, in cui le risorse perse durante il disastro vengono ricostituite.

Per quanto riguarda specificamente il sistema IT aziendale, un piano di Disaster Recovery prevede generalmente la possibilità di riattivare i processi critici in un sito remoto. Questo perché l’indisponibilità di un sito è conseguenza frequente di un disastro; grossolanamente, più il sito remoto è lontano, più è difficile che sia coinvolto nello stesso disastro in cui è coinvolto il sito principale.
Nell’approntare il sito remoto sarà necessario rendere disponibili:

• le infrastrutture di supporto (locali, energia elettrica, acqua, aria condizionata, connettività...);
• personale;
• dati/informazioni;
• software/applicazioni;
• risorse di calcolo.

Il sito remoto può essere ricondotto a una delle seguenti categorie, scelta in base alle esigenze dei processi di business e delle strategie di recovery:

• siti freddi (cold site), quelli in cui sono disponibili solo le infrastrutture di supporto, ma non sono disponibili né apparati né dati o software. L’attivazione di questi siti può richiedere anche alcune settimane;
• siti tiepidi (warm site), sono invece parzialmente attrezzati anche per quanto riguarda gli apparati.

Generalmente mancano gli apparati più costosi, nell’ipotesi di poterseli procurare in tempi brevi, ad esempio in virtù di accordi con i fornitori.
I dati possono essere disponibili sotto forma di backup, ma non immediatamente disponibili sui sistemi; 

• siti caldi (hot site), sono infine quelli completamente attrezzati e possono essere attivati anche in poche ore.

Questo comporta non solo la disponibilità di apparati, ma anche di software allineato con quello del sito principale in termini di versioni e configurazioni. Possono mancare alcuni programmi, dati e il personale, ma è possibile anche che il sito disponga già dei dati allineati con quelli del sito principale. Negli ultimi tempi, con la diffusione di tecnologie affidabili a larga banda e a costi sempre più contenuti, si sta infatti diffondendo l’uso di tecnologie di mirroring dei dati che mantengono presso il sito remoto una copia dei dati sostanzialmente allineata con quella del sito principale.

La Proposta
Definiamo il progetto
Ogni organizzazione è unica nella sua struttura, cultura, processi, prodotti, servizi e locazione fisica.
Per un piano di disaster recovery efficiente, ogni organizzazione necessita di creare documenti che si adattano in modo perfetto alla propria organizzazione sia tecnica che di processo, cercando di rispondere alle tipologie di disastro che s’intendono anticipare.
In poche parole un “buon abito di sartoria”, tagliato su misura.
E’ inutile copiare piani di altre strutture e adattarli alle esigenze, molti punti rimarrebbero scoperti creando una breccia nel piano o un cattivo indirizzamento del problema.
 
Ogni progetto di “disaster recovery” (comunemente indicato come “business continuità plan”) deve iniziare con un “assessment” per determinare i passi corretti.
Una volta che il processo di assessment è completato, si può passare alla fase successiva di documentazione, implementazione e test, per assicurarsi che il piano funzioni.
Il segreto di un buon piano: adottare I passi giusti prima che l’evento accada.
I due veri obiettivi sono:

1. creare un piano quanto più aderente alla realtà
2. mitigazione dei rischi e dei pericoli prima che accadano

Se il piano è correttamente impostato dovrebbe rispondere in modo efficace anche alle due fasi, successive al disastro:

• Risposta all’emergenza (emergency response)
• Ripristino dell’attività (business recovery)

Affrontiamo il progetto in tre fasi:
Fase 1 - Assessment
Questa fase determina lo scopo ed il disegno del progetto.
Determina anche, tutte le attività per documentare, implementare e poi testare il piano.
Questa fase include anche la valutazione delle funzioni più critiche e di cosa sia necessario per continuare l’attività, sul sistema corrente sia in termini di comunicazione che di capacità di ripristino successivamente ad un evento disastroso.
La valutazione del rischio (risk analysis) dei pericoli interni o esterni, deve essere inserita in questa fase.
Tutte le vulnerabilità del business devono essere individuate e quantificate per determinare quali possono essere attenuate o comunque minimizzate, se non addirittura eliminate durante la pianificazione.
Riepilogando:

• Classificazione dei rischi
• Correlazione tra rischi e processi IT
• Valutazione dei rischi ed individuazione della soglia di tolleranza
• Classificazione delle criticità e pianificazione degli interventi di rimozione/riduzione del rischio
• Pianificazione della gestione del rischio

Sicurezza
L’obiettivo è individuare e predisporre le misure necessarie a garantire il livello di sicurezza indicato dall’analisi del rischio. L’intervento può comprendere, a seconda delle esigenze, tutti o solo alcuni dei processi che influenzano l’integrità e la riservatezza delle informazioni.
Le informazioni devono essere protette, perché:

• La loro mancanza o manipolazione proditoria può procurare danni sensibili all’azienda, in termini d’immagine, di pregiudizio nell’operatività o di perdita di fatturato
• Normative di settore, standard internazionali ed obblighi legislativi pongono vincoli specifici in tal senso
• La tecnologia che sostiene i Sistemi, cui le informazioni sono affidate, è essa stessa un elemento che non si deve disperdere o deteriorare.

In particolare:

• Comprensione degli obiettivi di sicurezza generali e delle singole aree dell’IT
• Conoscenza e classificazione delle risorse e dei processi da analizzare, rilevazione della situazione esistente
• Creazione del modello di base delle misure di sicurezza e dei controlli
• Pianificazione ed attuazione delle misure organizzative, procedurali e tecnologiche necessarie all’applicazione del modello.

Fase 2 - Documentazione & Implementazione
Durante questa fase del progetto, tutti i documenti e i piani sono redatti, ogni apparato o apparecchiatura addizionale viene individuata e (se necessario) acquisita, per ridurre i rischi identificati durante la fase di assessment. In questa fase ha un grosso peso la formazione del personale al rispetto del loro ruolo e delle responsabilità
Fase 3 - Test
Una volta che i documenti sono stati predisposti e le persone formate, bisogna condurre dei test (esercitazioni e valutazioni) per assicurarsi che il piano abbia la funzionalità garantita da un continuo allineamento/aggiornamento delle informazioni contenute.