Disaster Recovery Seminar at UNIMORE University in Modena ITALY 27/11/2013 By Enrico Parisini

1. Dipartimento di Ingegneria “Enzo Ferrari
Disaster Recovery
La dura disciplina della sicurezza
informatica per la preservazione dei
dati aziendali
27 novembre 2013

2. Disaster recovery: programma del seminario
Contesto attuale, sicurezza informatica
Definizioni e standard di riferimento
La sicurezza
La sicurezza
informatica senza
informatica senza
una misurazione
una misurazione
continua e puntuale
continua e puntuale
dei rischi e una
dei rischi e una
valutazione dei
valutazione dei
danni è più materia
danni è più materia
di psicologi che non
di psicologi che non
di ingegneri
di ingegneri ..
I processi ICT , le metodologie
L'analisi dei rischi
La Valutazione dei danni
Le infrastrutture informatiche resilienti
I processi ICT per la sicurezza
Il piano di disaster recovery
Test e Istruzioni Operative

3. La continuità operativa
6% è la
6% è la
percentuale di
percentuale di
sopravvivenza di
sopravvivenza di
aziende che hanno
aziende che hanno
subito una forma di
subito una forma di
disastro il 43%
disastro --il 43%
non ha mai riaperto
non ha mai riaperto
e il 51% ha
e il 51% ha
continuato l'attività
continuato l'attività
ma ha chiuso entro
ma ha chiuso entro
2 anni successivi
ii2 anni successivi
Le aziende moderne hanno necessità di
continuità operativa. Non possono fermare
se non in modo pianificato, le loro attività.
L'interdipendenza dei sistemi genera una
complessità non visibile quando tutto
funziona. Una discontinuità operativa può
produrre danni anche dove non si pensa.
Oggi la continuità operativa è principalmente
assicurata dalle procedure informatiche.
Fermare i servizi informatici significa
interrompere la continuità operativa.
La gravità di una discontinuità non è
proporzionale ma esponenziale rispetto al
tempo, il valore dell'esponente è una
variabile tipica del tipo di business e
dell'azienda.

4. Minacce alla continuità operativa
Fonte : IBM 2012

5. Minacce alla continuità operativa

6. Alcune Definizioni
Business Continuity
Si intende la capacità dell'azienda di continuare ad esercitare il proprio business a fronte di
eventi avversi che possono colpirla. Viene comunemente considerata come un processo
globale che identifica i pericoli potenziali che minacciano l'organizzazione, fornisce una
struttura che consente di aumentare la resilienza e la capacità di risposta in maniera da
salvaguardare gli interessi degli stakeholders, le attività produttive, l'immagine, riducendo i
rischi e le conseguenze sul piano gestionale, amministrativo, legale.
Disaster Recovery
In informatica, nell'ambito della di sicurezza informatica, per disaster recovery si intende
l'insieme delle misure tecnologiche e logistico/organizzative atte a ripristinare sistemi, dati
e infrastrutture necessarie all'erogazione di servizi di business per imprese, associazioni o
enti, a fronte di gravi emergenze che ne intacchino la regolare attività. Il disaster Recovery
plan è parte della Business Continuity
Riferimenti normativi
ISO/IEC 27001 "Information Security Management System"
BS 25999 "Business Continuity Management System"
LEGGE 196/2003 Privacy

7. Alcune Definizioni
Recovery Point Objective (RPO):
è uno dei parametri usati nell'ambito delle politiche di disaster recovery per descrivere la
tolleranza ai guasti di un sistema informatico. Esso rappresenta il massimo tempo che
intercorre tra la produzione di un dato e la sua messa in sicurezza (ad esempio attraverso
backup) e, conseguentemente, fornisce la misura della massima quantità di dati che il
sistema può perdere a causa di guasto improvviso. Al diminuire dell'RPO richiesto si
rendono necessarie politiche di sicurezza sempre più stringenti e dispendiose, che possono
andare dal salvataggio dei dati su supporti ridondanti tolleranti ai guasti fino alla loro
pressoché immediata replicazione su un sistema informatico secondario d'emergenza
(soluzione in grado di garantire, in linea teorica, valori di RPO prossimi allo zero)
Recovery Time Objective (RTO):
è il tempo necessario per il pieno recupero dell'operatività di un sistema o di un processo
organizzativo in un sistema di analisi Business Critical System (ad esempio implementazioni
di politiche di Disaster Recovery nei Sistemi Informativi).
È in pratica la massima durata, prevista o tollerata, del downtime occorso.

8. Alcune Definizioni
Risk Assestement
E' il processo attraverso il quale le aziende determinano i rischi, le vulnerabilità, l'analisi dei
danni possibili e formulano i diversi scenari possibili di disastro. Si definiscono i processi
prioritari , si identificano le interdipendenze tra i processi critici, l'organizzazione e le
persone e i servizi. Si identificano i danni potenziali derivanti da accadimenti accidentali
non prevedibili.
Probable Maximum Business Interruption Loss (PML):
Perdite, basate su un worst-case scenario, che possono risultare da una interruzione della
continuità operativa secondo gravità della interruzione e della durata della stessa. Serve
molto per una valutazione assicurativa.
Rischio Operativo
Il rischio operativo è la valutazione delle cause e relative probabilità di una interruzione di
servizio e del tempo di detta interruzione . Tale valutazione è entrata a far parte dell'analisi
de rischi a partire dal mondo bancario e dagli accordi definiti Basilea 2.

9. I processi IT e le metodologie, l'esempio ITIL

10. ITIL service operation

11. I processi fondamentali per la gestione della sicurezza
 Service level management
 Availability management
Disegno dei servizi
 ICT Service continuity mgm
 Information security mgm
 Backup dei dati, delle applicazioni
 Restore dei dati, delle applicazioni
Gestione delle Operazioni
 Monitoraggio
 Incident management
 Procedure per il disaster recovery

12. Organizzare le attività : CMBD
configuration management database
Le applicazione per gestire l'informazione sui processi ICT
Servizi Erogati
Incident
SLA
Sistemi Eroganti
Change
Client dei servizi
Piccola dimostrazione pratica

13. L'analisi dei rischi – Risk assestement
L'analisi dei
L'analisi dei
rischi
rischi ,,
l'individuazione
l'individuazione
delle minacce, la
delle minacce, la
gestione delle
gestione delle
relative
relative
contromidure è il
contromidure è il
punto di
punto di
partenza per la
partenza per la
definizione di un
definizione di un
corretto
corretto
processo di
processo di
Disaster
Disaster
Recovery
Recovery

14. L'analisi dei rischi – Un esercitazione pratica
Ogni anno deve essere presentato il
Documento programmatico per la sicurezza
DPS
In questo documento, nella sezione Risk Analisys, vengono
analizzati tutti i rischi e le relative azioni mitiganti
Il documento di Conserve Italia

15. Una valutazione dei danni : una esercizio vero
Tabella Valutazione Danni derivanti da disservizi informatici
solo sistemi Mission Critical

16. Una Infrastruttura adeguata: la ridondanza
Una varietà di soluzioni per la copertura dei rischi di una varietà di servizi

17. Una infrastruttura adeguata : NO Single point of failure
I componenti delle architetture server
devono essere a loro volta resilienti al
guasto di un singolo componente:
ventola, alimentatore, scheda di rete ,
dischi interni.
Dove questo non è possibile occorre
ridondare i componenti
Dall'offerta RAID in poi , la
componente storage è normalmente
ridondata allo scopo di reggere al
guasto del singolo componente
La progettazione anche di un piccolo datacenter deve sempre prevedere
la resilienza al guasto del singolo componente.

18. Una infrastruttura adeguata : il monitoraggio automatico

19. TIER La classificazione dei Data Center
Livello
Uptime %
Hours
Downtime per
Year
Redundancy
Hour power &
cooling outage
protection
TIER 1
99,671 %
28,8
NO
-
TIER 2
99,749 %
22
Partial power
and cooling
-
TIER 3
99,982 %
1,6
N+1 Fault
tolerant
72
TIER 4
99,995 %
2,4 min
2N+1 Fully
redundant
96
The Data Center Tier Classification system: I, II, III and IV was introduced by the Uptime Institute. Tier IV
represents the highest level of availability, reliability and security for corporations. Large companies
worldwide contract with Uptime Institute to achieve a Tier certification of their choice.

20. Le Tecnologie “ SINCRONIZZAZIONE “
Cluster Applicativo
Si definiscono 2 istanze A e B che gestiscono le
stesse applicazioni e gli stessi dati, vengono però
popolati su 2 istanze diverse in 2 tempi diversi. Se
A cade occorre eseguire lo switch verso B.
Esempi: domino cluster (posta), oracle standby
database .
-
+




Indipendente
dall'hardware
Tollerante verso le
distanze
Sfrutta l'infrastruttura
esistente
Consente di gestire
ripristini in forme
diverse




Complesso da
implementare
Lento nello switch
Gestione pesante
per il controllo di
funzionamento
Gestione molto
pesante per gli
aggiornamenti
A
Distanza
B

21. Le Tecnologie “ SINCRONIZZAZIONE “
Cluster con journaling
Si definiscono 2 istanze A e A1 , una sola è
l'istanza attiva, l'istanza A1 è aggiornata attraverso
transazioni non applicative ma di variazione di
blocchi del sistema storage. Al cadere dell'istanza
A occorre comandare uno switch




Discretamente
tollerante verso le
distanze
Supporta più livelli di
sicurezza
Consente di gestire
ripristini in forme
diverse
Facile da controllare
Macchina del tempo
A1
-
+

A
Distanza



Dipende dallo
storage
Architetture
proprietarie
Switch da
comandare
J
J

22. Le Tecnologie “ SINCRONIZZAZIONE “
Sistema Cluster remotizzabile
Si definisce una sola istanza A che è distribuita in
2 siti diversi i meccanismi di sincronia sono in
carico allo storage. Si può perdere un sito,
l'applicazione continua a funzionare .
-
+




Non c'è switch
Si comporta come un
solo sistema
Molto semplice da
gestire
Molto semplice da
implementare



Specifica soluzione
dipende
dall'hardware
Distanze brevi ,
quelle del fiber
channel (300 mt)
Non gestisce le
asincronie
Distanza
A

23. Distribuzione capacità elaborativa : Rischio “SITO”

24. Distribuzione capacità elaborativa: Rischio territorio
Ogni luogo è sottoposto a diverse
tipologie di rischio
Luoghi vicini comportano una
omogeneità di richio
Segliere Luoghi con bassi rischi o
quantomeno complementari

25. Pratica di base: Backup e Restore
Le operazioni di backup-restore sono la
pratica basilare per il salvataggio dei dati e
la garanzia del loro eventuale ripristino
E' necessario che le copie di backup siano
conservate su supporti mobili in luoghi
diversi da quelli dove sono conservati i dati
L'affidabilità del processo di backup-restore
si misura solo attraverso i test di restore
Il tempo di backup-restore e lo spazio
occupato sono le variabili critiche rispetto
alla efficienza del processo di backup-restore
e alla copertura di un incident o di un
disastro.

26. Pratica di base: Backup e Restore definizioni
Backup on-line , a caldo
Si tratta di modalità di backup che prevedono l'esecuzione con le
applicazioni attive .
Finsestra di backup
Periodo in cui un sistema è disponibile per il backup. Le procedure di
backup possono avere effetti di rallentamento sui sistemi e sulla rete;
alcune operazioni richiedono che l'uso primario del sistema sia
sospeso. Questi effetti possono essere mitigati concordando una
finestra di backup con il proprietario del sistema.
Tape library
un sistema che contiene dei nastri per il backup, un lettore di barcode per
identificare i nastri e un automatismo per movimentare i nastri
all'interno della library. Una tape library può contenere delle enormi
quantità di dati. Tecnologie DLT
Schema di rotazione del backup
per effettuare un backup giornaliero vengono di solito fatti ruotare gli
stessi media (es. i nastri). Lo schema di rotazione stabilisce appunto il
metodo di rotazione e di ritenzione (data retention) dei dati. Vengono
utilizzati diversi schemi quali: Incrementale; Nonno, padre e figlio; la
torre di Hanoi, ecc.
Retention time – tempo di retention
tempo in cui un certo set di dati rimane disponibile per il restore. Il tempo
di retention viene generalmente misurato in giorni. In alcuni casi viene
misurata una 'retention' sulla base del numero di copie dei dati di
backup, indipendentemente dal tempo a cui esse si riferiscono.

27. Backup e Restore , variabili critiche: Tempo e Spazio
Backup Completo
un backup di tutti i file del sistema. A differenza della disk image, un full backup
non include le tavole di allocazione, le partizioni ed i settori di boot.
Backup incrementale
backup che contiene tutti i file cambiati dall'ultimo backup (completo e
incrementale). Il backup incrementale è più rapido di quello differenziale ma
richiede tempi di restore più lunghi poiché è necessario partire dall'ultimo
backup completo e poi aggiungere in sequenza tutti i backup incrementali.
Backup differenziale
backup cumulativo di tutti i cambiamenti effettuati a partire dall'ultimo backup
completo (o full backup). Il vantaggio è il minor tempo necessario rispetto ad
un backup completo. Lo svantaggio è che i dati da salvare aumentano per
ogni giorno trascorso dall'ultimo backup.
Compressione
la compressione è ottenuta tramite algoritmi di compressione dei dati (come
quelli usati dai programmi più famosi come Winzip, WinRar, WinAce) prima
che vengano registrati sul supporto di backup, oppure attraverso la
deduplicazione
Deduplica
è ottenuta tramite algoritmi di deduplicazione (che significa eliminazione dei
duplicati) che possono agire a livello di singolo file o di blocco . La
deduplicazione può essere eseguita prima, durante o dopo la copia di backup,
in contemporanea o in differita rispetto alla normale operatività dei sistemi
informatici.La deduplicazione è utile, in particolare, per i gruppi di file o le
cartelle di file che necessitano di un backup completo e quotidiano.

28. Il piano di Disaster Recovery
DRP manutenzione
Piano dei test
Addestramento e
consapevolezza
Verifiche delle
interdipendenze
8
1
7
6
Analisi del business
2
5
Analisi dei rischi e
delle conseguenze
3
Comitato di crisi
4
Analisi dell'incident, Piano di
ripristino, Steps e Checklist

29. Analisi dell'incident, Piano di ripristino, Steps e Checklist
2 Riscontro
incident
1 incident
3 Analisi
della situazione
Reperibile
Responsabile
Monitoraggio
Lieve
4 Avvio del
ripristino
5 OK
6 Fine
7 No Ok
Operazioni
Semplici
codificate
Grave
Tecnico
Sistemista
Esperto
Sistemista
esperto e
Consulenti
8 Convocazione
comitato
10 Operazioni
di ripristino
14 Restore
Escalation
9 Suddivisione
dei compiti
11 OK
Operazioni
Complesse
Non codificate
12 Fine
Operazioni
molto
complesse
13 No Ok
15 Operazioni
di ripristino
16 Fine

30. Operazioni di rispristino: Le istruzioni operative, Le check List
Archivio delle istruzioni check list
Occorre un archivio elettronico sempre raggiungibile possibilmente replicato anche sugli strumenti
di lavoro dei tecnici dove archiviare le istruzioni.
Ricerca delle istruzioni
La riccera delle istruzioni deve essere più veloce possibile, sia ricerca testo libero, sia ricerca per
classificazione, sia ricerca per autore.
I documenti relative alle istruzioni operative devono riportare
Contesto operativo
Il documento deve essere senza fronzoli descrittivi, per prima cosa deve illustrare il
contesto operativo e se è una bugfix una definizione del BUG
Sequenze
Dopo una minima definizione del contesto, occorre illustrare bene la sequenza delle
operazioni , nel casso di un riprisdtino è fondamentale !!
Comandi
All'internbo delle sequenze ci saranno comandi da impartire, con i nuovi oggetti visual i
comandi devono essere descritti con gli screen shot delle esecuzioni
Esiti e test di funzionamento
Dovranno essere descritti con dovizia di aprticolari, gli esiti attesi dalle operazioni e i
metodi per controllare detti esiti - TEST

31. Operazioni di ripristino: Archivio delle Istruzioni Operative
Es: Attività possibili sul sistema DBCID11

32. Operazioni di ripristino : esempio check list
Verifica su supporto specifico

33. Conclusioni : DR una importante attività tecnico organizzativa
Il Disaster recovery è un programma di lavoro che comprende
– la progettazione della sicurezza informatica
– L'analisi dei rischi a cui è sottoposta
– La messa a punto delle contromisure ai rischi
– L'organizzazione in grado di realizzare le contromisure
– I processi di test e di controllo
Il Disaster recovery è parte del piano di Business Continuity che si
occupa della gestione complessiva del rischio, non solo di quello
informatico.
L'attenzione alla progettazione tecnica è importante, ma inutile se
non combianata con una altrettanto importante progettazione
organizzativa.
Qualsiasi progettazione è inutile se le attività previste non vengono
periodicamente testate, specie dopo le attività di change .