Si parla spesso di resilienza delle aziende contro gli attacchi informatici, ma è bene precisare che riuscire a ripartire in un sito di disaster recovery, salvo che la soluzione adottata sia in realtà un active/active (due siti sempre attivi e costantemente allineati) o che il sistema informativo aziendale sia particolarmente semplice e poco interconnesso con altre organizzazioni, ha diversi rischi nascosti ed è particolarmente difficile e complesso.
Oltre al problema di riuscire a far ripartire i vari sistemi nella giusta sequenza, vi è il grosso ostacolo costituito dal corretto allineamento dei dati.
Un problema tutt’altro che semplice da gestire, in particolar modo nel caso in cui gli RPO (Recovery Point Objective) dei vari processi siano fra loro molto diversi e la vostra soluzione di DR sia basata solo su copie e non anche su repliche dei dati in tempo reale.
Comunque, anche se tutto è andato per il meglio non c’è molto da rallegrarsi.
Indice degli argomenti
Le azioni da mettere in atto dopo la ripartenza
Le azioni che è necessario mettere in atto dopo la ripartenza sono infatti molteplici ed i problemi sono solo all’inizio.
Il primo di questi deriva dal fatto che un sito di DR solitamente è sotto dimensionato per quanto attiene alla sua capacità elaborativa (tanto è vero che nella BIA, Business Impact Analysis, dovrebbero essere indicati non solo i tempi di ripartenza richiesti, ma anche la qualità che deve essere garantita al servizio ripristinato in termini di prestazioni o più in generale di SLA).
Anche la normativa e gli standard prevedono che, in caso di disastro, il ripristino dei processi possa avvenire con un livello di prestazioni inferiore rispetto a quello della normale operatività e che tale livello di degrado sia formalizzato[1].
Il secondo aspetto, ancor più preoccupante, è il fatto che solitamente un sito di DR è pensato per gestire un’emergenza che si spera non accada mai e che, se accade, duri il minor tempo possibile.
Infatti, il sito di DR molto spesso viene implementato non tanto per necessità o per lungimiranza dell’alta direzione, ma semplicemente per rispondere ad un requisito normativo.
Pertanto si è portati a ridurre al minimo i costi da sostenere.
Il risultato è che l’ambiente di produzione delle grandi organizzazioni è ampiamente ridondato (opera quindi in alta affidabilità/disponibilità) sia per quanto riguarda l’infrastruttura elaborativa, sia per quanto attiene le connessioni di rete e geografica, i supporti di archiviazione, l’alimentazione, il condizionamento ed anche la sicurezza fisica.
Nel sito di DR tali caratteristiche non sono solitamente presenti.
Il risultato: maggiore è la complessità del sistema informativo e maggiori sono le probabilità che un singolo componente si guasti. Se questo evento accade (e la frequenza di accadimento è ovviamente collegata al numero di componenti coinvolti) in un ambiente altamente ridondato le conseguenze sono minime o nulle. I servizi non si interrompono e solitamente nemmeno rallentano mentre il componente guasto viene sostituito.
Nel sito di DR ogni singolo guasto può invece portare ad un blocco più o meno significativo nella erogazione dei servizi. Più è alto il numero dei componenti e più frequente è il numero delle interruzioni.
Il sito DR è in realtà nella maggior parte dei casi un insieme di single point of failure capaci di bloccare l’erogazione di ogni servizio in men che non si dica.
Il guasto di alcuni componenti può infatti provocare con facilità l’interruzione anche di tutti i servizi (si pensi ad esempio al guasto del router che connetta il CED alla rete aziendale o ad un guasto alla rete geografica).
Il servizio che ne risulta può essere fortemente degradato e quindi sarebbe buona cosa chiedersi se gli investimenti fatti siano stati effettivamente correttamente indirizzati. Probabilmente sarebbe stato più opportuno investire qualcosa in più e ridondare quantomeno le componenti infrastrutturali che sono alla base di più processi e le componenti applicative che supportano i processi vitali.
Viceversa questa attività dovrà essere fatta in corsa, subito dopo aver attivato il sito di DR, ma dovrà essere fatta contemporaneamente a molte altre attività tutte conseguenti alla errata analisi e progettazione del sito di DR, alla scarsa attenzione delle reali esigenze aziendali, all’implementazione di soluzioni la cui unica finalità è il rispetto della normativa e dei budget, alla scarsa analisi critica di quanto prescrivono standard e normative.
Tutti elementi che porteranno quasi sicuramente al fallimento dell’organizzazione coinvolta.
Il tutto, solitamente, all’oscuro dell’alta direzione che approva i piani di business continuity e gli esiti, quasi sempre positivi, dei test, ma che ha poca visibilità sulla reale capacità di sopravvivenza dell’organizzazione se si trova ad operare dal sito di DR.
I rischi nascosti del disaster recovery: la gestione degli incidenti
Proprio in conseguenza della necessità di gestire continuamente i numerosi guasti che interesseranno il sito di DR, le risorse dell’IT difficilmente potranno dedicare la loro attenzione anche a progetti per nuove implementazioni, come quelle necessarie a garantire ex novo una alta affidabilità.
Quando si opera in DR dovrebbero cambiare anche le modalità con cui gestire i normali processi ICT, anche se tale eventualità raramente è contemplata nelle procedure aziendali e ci si trova quindi ad improvvisare.
Alcuni processi ICT subiscono semplicemente un arresto, come ad esempio lo sviluppo di nuove applicazioni, altri devono subire una importante ristrutturazione.
Si pensi ad esempio alla gestione degli incidenti.
Il livello di attenzione e la valutazione delle conseguenze di determinate categorie di incidenti devono cambiare radicalmente. Se infatti in precedenza taluni eventi avevano un impatto nullo sull’organizzazione (in virtù della già citata ridondanza dei componenti) ora il guasto di un componente può portare al blocco del sistema e quindi è da considerarsi grave ed urgente.
Ma chi solitamente gestisce gli incidenti è preparato a questo nuovo tipo di approccio?
O anch’essi devono improvvisare?
Rischi nascosti del disaster recovery: l’importanza dei test
Come si vede, quindi, non è sufficiente essere in grado di garantire il ripristino del proprio sistema informativo per essere a posto con la coscienza.
Sarebbe stato necessario progettare adeguatamente il sito di DR affinché potesse effettivamente sostituire il sito primario per un lungo periodo (come in effetti prescrivono le normative, quantomeno in ambito bancario) e definire le procedure da seguire quando si opera in emergenza.
Nulla di ciò viene di solito fatto e nulla di ciò è nemmeno documentato negli standard e nelle buone pratiche e nemmeno tale pratica rientra fra quelle oggetto di test o di verifica.
Ma perché questo accade e perché un’organizzazione che effettivamente opera dal proprio sito di DR potrebbe trovarsi in difficoltà?
Il problema di fondo è che nella realtà le normative e gli standard (che si fotocopiano a vicenda senza nessuna analisi critica o reale esperienza dei fatti) hanno la loro colpa.
Si pensa al sito di DR come ad un sito temporaneo e di breve durata, dal quale fuggire non appena si è ripristinato il sito primario.
Ci si dimentica che il sito primario di solito è concepito per evitare in tutti i modi possibili di attivare il sito di DR, e che se si va in DR è perché probabilmente il sito primario non c’è più (terremoto, incendio, alluvione, altro evento atmosferico estremo, atto terroristico); e quindi dove si torna?
A ciò va aggiunta la tradizionale modalità con cui sono svolti i test di DR.
Anche i test più seri ed effettuati effettivamente in produzione, come recita la Circolare 285 di Banca d’Italia, non sono di per sé significativi.
Il motivo è presto detto; i test sono costosi, ma soprattutto rischiosi.
È assolutamente fondamentale effettuarli per capire se in caso di emergenza effettivamente si è in grado di garantire la continuità del proprio sistema informativo, ma anche un test con esito positivo non garantisce il fatto che si è poi in grado di mantenere attivo efficacemente il proprio sito di DR.
Per quale motivo?
Semplice, perché i test di DR durano poche ore, mentre dovrebbero durare giorni, se non settimane.[2]
Ma questo sarebbe troppo costoso e, soprattutto, rischioso.
Rischioso per vari motivi:
- non si sa se effettivamente tutto funzionerà, se si riusciranno a ripristinare i vari servizi, se i dati ci saranno tutti, se i dati saranno allineati;
- non si sa se effettivamente il tutto avverrà nei tempi stabiliti;
- non si sa quanto il sito di DR possa effettivamente funzionare e quando qualche guasto interromperà l’erogazione dei servizi;
- non si possono erogare per un periodo troppo lungo servizi alla clientela con il basso livello di qualità garantito dal sito di DR.
Nessuno si accolla il rischio di provare effettivamente un sito di DR e di mantenerlo attivo, salvo il caso già prima citato, che il sito di DR sia in realtà già parte della produzione in una soluzione active/active.
Che confidenza si può dare, quindi, alla reale capacità di un’organizzazione di sopravvivere nel caso in cui abbia eseguito correttamente un test di DR di breve durata?
In realtà poca; è necessario capire come è stato fatto il test e se questo è durato poche ore cercare di capire com’è fatto il sito di DR.
Non date nulla per scontato; la maggior parte delle organizzazioni che vantano piani di DR e relativi test probabilmente non ha mai sperimentato un test protratto nel tempo e quindi la confidenza sulla sua reale capacità di sopravvivenza è molto bassa.
Business continuity e rischi nascosti del disaster recovery
Ma torniamo ora ai molteplici compiti dei nostri operatori, impegnati da un lato sul fronte della gestione dei sempre più frequenti incidenti che possono garantire la continuità del business e dall’altro nel tentativo di rendere resiliente il sito di DR.
Al riguardo non va dimenticato che un sito di DR è pur sempre un sito di emergenza e che un piano di business continuity prevede sempre una fase di rientro (anche se in realtà la definizione e progettazione di soluzioni di rientro dovrebbero prevedere un numero indefinito di casistiche, motivo per cui è più saggio definire delle linee guida su come comportarsi piuttosto che piani dettagliati che verrebbero vanificati di fronte a situazioni impreviste[3]).
I nostri dovrebbero quindi letteralmente farsi in quattro per gestire contemporaneamente tutti questi fronti, oltre ad aver un budget illimitato.
Nulla di tutto ciò avviene nella realtà.
Ovviamente molti penseranno che con una tale situazione il cloud sia la panacea.
In realtà i servizi in cloud non gestiscono di default ne la sicurezza, ne la continuità operativa, salvo ovviamente contrattualizzare i relativi servizi e prevedere opportune attività di audit per verificare che quanto affermato corrisponda al vero.
Conclusione
C’è dunque veramente molto da fare per garantire che una organizzazione sia effettivamente in grado di continuare il proprio business in caso di default del proprio sistema informativo ed è necessario un radicale cambiamento ed una presa di coscienza, in particolare di chi governa un’organizzazione che non può interrompere l’erogazione dei propri servizi.
Occorre quindi iniziare da subito a riprogettare il proprio sito di DR; ne va della sopravvivenza dell’organizzazione e della reputazione professionale.
NOTE
Circolare 285 Banca d’Italia – “…il processo è ripristinato a un livello di servizio predefinito”. ↑
Orientamenti dell’ABE sulla gestione dei rischi relativi alle tecnologie dell’informazione e della comunicazione (Information and Communication Technology – ICT) e di sicurezza
…
9. Le verifiche dei piani di continuità operativa degli istituti finanziari dovrebbero dimostrare che gli istituti sono in grado di sostenere la redditività delle loro attività fino a quando le operazioni critiche non vengono ristabilite. In particolare, esse dovrebbero: a) prevedere la verifica di una serie adeguata di scenari gravi ma plausibili, inclusi quelli presi in considerazione per l’elaborazione dei piani di continuità operativa (nonché la verifica dei servizi forniti da soggetti terzi, se possibile); ciò dovrebbe includere il trasferimento delle funzioni aziendali critiche, dei processi di supporto e delle risorse informatiche all’ambiente di «disaster recovery» e la dimostrazione che possono così essere gestiti per un periodo di tempo sufficientemente rappresentativo e che il normale funzionamento può essere successivamente ripristinato. ↑
Il valore della pianificazione diminuisce in conformità con la complessità dello stato delle cose.
Credetemi: questo è vero. Può sembrare paradossale.
Magari pensate che più sia complessa una situazione, più è necessario un piano per poter farne fronte.
Vi concedo la teoria. Ma la pratica è diversa.
Tratto da: Allen Massie, 1986 “Augustus: Memoirs of Emperor”. Bodley Head. ↑
