Disaster recovery-seminar

675 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
675
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Disaster recovery-seminar

  1. 1. Dipartimento di Ingegneria “Enzo Ferrari Disaster Recovery La dura disciplina della sicurezza informatica per la preservazione dei dati aziendali 27 novembre 2013
  2. 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. 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. 4. Minacce alla continuità operativa Fonte : IBM 2012
  5. 5. Minacce alla continuità operativa
  6. 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. 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. 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. 9. I processi IT e le metodologie, l'esempio ITIL
  10. 10. ITIL service operation
  11. 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. 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. 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. 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. 15. Una valutazione dei danni : una esercizio vero Tabella Valutazione Danni derivanti da disservizi informatici solo sistemi Mission Critical
  16. 16. Una Infrastruttura adeguata: la ridondanza Una varietà di soluzioni per la copertura dei rischi di una varietà di servizi
  17. 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. 18. Una infrastruttura adeguata : il monitoraggio automatico
  19. 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. 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. 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. 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. 23. Distribuzione capacità elaborativa : Rischio “SITO”
  24. 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. 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. 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. 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. 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. 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. 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. 31. Operazioni di ripristino: Archivio delle Istruzioni Operative Es: Attività possibili sul sistema DBCID11
  32. 32. Operazioni di ripristino : esempio check list Verifica su supporto specifico
  33. 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 .

×