Dott. Giuseppe Mazzoli Presidente 3CiME Technology www.3cime.com

1. Dott. Giuseppe Mazzoli Presidente 3CiME Technology www.3cime.com Il DisasterRecovery: un obbligo per gli enti pubblici, una opportunità per le aziende. Aspetti legali e gestionali, ed il servizio di 3CiME Technology Srl

2. DisasterRecovery • Non cominciate a fare gesti scaramantici • Proviamo a dare una definizione • Da Wikipedia, l'enciclopedia libera.

3. DisasterRecovery • Per DisasterRecovery (brevemente DR) si intende l'insieme di misure tecnologiche e organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi di business a fronte di gravi emergenze. Si stima che la maggior parte delle grandi imprese spendano fra il 2% ed il 4% del proprio budget IT nella pianificazione della gestione dei disasterrecovery, allo scopo di evitare perdite maggiori nel caso che l'attività non possa continuare a seguito della perdita di dati ed infrastrutture IT. Delle imprese che hanno subito disastri con pesanti perdite di dati, circa il 43% non ha più ripreso l'attività, il 51% ha chiuso entro due anni e solo il 6% è riuscita a sopravvivere nel lungo termine. I disastri informatici con ingenti perdite di dati nella maggioranza dei casi provocano quindi il fallimento dell'impresa o dell'organizzazione, ragion per cui investire in opportune strategie di recupero diventa una scelta quasi obbligata.

4. DisasterRecovery • Il DisasterRecovery Plan (DRP) (in italiano, Piano di disasterrecovery) è il documento che esplicita tali misure. Esso fa parte del più ampio Business Continuity Plan (BCP). • Affinché una organizzazione possa rispondere in maniera efficiente ad una situazione di emergenza, devono essere analizzati: • I possibili livelli di disastro • La criticità dei sistemi/applicazioni.

5. DisasterRecovery • Per una corretta applicazione del piano, i sistemi devono essere classificati secondo le seguenti definizioni: • Critici - Le relative funzioni non possono essere eseguite senza essere sostituite da strumenti (mezzi) di caratteristiche identiche. Le applicazioni critiche non possono essere sostituite con metodi manuali. La tolleranza in caso di interruzione è molto bassa, di conseguenza il costo di una interruzione è molto alto.

6. DisasterRecovery • Vitali - Le relative funzioni possono essere svolte manualmente, ma solo per un breve periodo di tempo. Vi è una maggiore tolleranza all'interruzione rispetto a quella prevista per i sistemi critici, conseguentemente il costo di una interruzione è inferiore, anche perché queste funzioni possono essere riattivate entro un breve intervallo di tempo (generalmente entro cinque giorni). • Delicati - Queste funzioni possono essere svolte manualmente, a costi tollerabili, per un lungo periodo di tempo. Benché queste funzioni possano essere eseguite manualmente, il loro svolgimento risulta comunque difficoltoso e richiede l'impiego di un numero di persone superiore a quello normalmente previsto in condizioni normali. • Non-critici - Le relative funzioni possono rimanere interrotte per un lungo periodo di tempo, con un modesto, o nullo, costo per l'azienda, e si richiede un limitato (o nullo) sforzo di ripartenza quando il sistema viene ripristinato.

7. DisasterRecovery • Le procedure applicative, il software di sistema ed i file che sono stati classificati e documentati come critici, devono essere ripristinati prioritariamente. Applicazioni, software e file classificati come critici hanno una tolleranza molto bassa alle interruzioni. La criticità di applicazioni, software di sistema e dati, deve essere valutata in funzione del periodo dell'anno in cui il disastro può accadere. • Un piano d'emergenza deve prevedere il ripristino di tutte le funzioni aziendali e non solo il servizio ICT centrale. Per la definizione del DRP devono essere valutate le strategie di ripristino più opportune su: siti alternativi, metodi di back up, sostituzione degli equipaggiamenti e ruoli e responsabilità dei team. La prolungata indisponibilità del servizio elaborativo derivante in particolare situazione di disastro, e quindi dei servizi primari, rende necessario l'utilizzo di una strategia di ripristino in sito alternativo.

8. Tecniche di DisasterRecovery • Allo stato attuale, la tecnologia offre la possibilità di realizzare varie soluzioni di continuità e DisasterRecovery, fino alla garanzia di fatto di un’erogazione continua dei servizi IT, necessaria per i sistemi (es. finanziari o di monitoraggio) definiti missioncritical. • In pratica i sistemi e i dati considerati importanti vengono ridondati in un "sito secondario" o "sito di DisasterRecovery" per far sì che, in caso di disastro (terremoto, inondazione, attacco terroristico, ecc...) tale da rendere inutilizzabili i sistemi informativi del sito primario, sia possibile attivare le attività sul sito secondario al più presto e con la minima perdita di dati possibile

9. Tecniche di DisasterRecovery • Chiaramente quanto più stringenti saranno i livelli di continuità tanto più alti saranno i costi di implementazione della soluzione.

10. Tecniche di DisasterRecovery • Replica sincrona • La replica sincrona garantisce la specularità dei dati presenti sui due siti poiché considera ultimata una transazione solo se i dati sono stati scritti sia sulla postazione locale che su quella remota. In caso di evento disastroso sulla sede principale, le operazioni sul sito di DisasterRecovery possono essere riavviate molto rapidamente (basso Recovery Time Objective e Recovery Point Objective praticamente nullo). • La replica sincrona è limitata dalla incapacità dell'applicazione di gestire l'impatto del ritardo di propagazione (vincolo fisico quindi, e non tecnologico) sulle prestazioni. In funzione della sensibilità dell'applicazione e della tecnologia di comunicazione tra i due siti, l'efficacia della copia sincrona inizia a diminuire a una distanza variabile tra i 35 km e i 100 km.

11. Tecniche di DisasterRecovery • Replica asincrona • Per far fronte al limite di distanza tra i due siti imposto da tecniche sincrone, si ricorre spesso alla tecnica di copia asincrona. In questo caso il sito che si occuperà della replica può trovarsi anche a distanze notevoli (> 100 km). In questo modo è possibile affrontare anche disastri con ripercussioni su larga scala (come ad esempio forti scosse sismiche) che altrimenti potrebbero coinvolgere entrambi i siti (se questi si trovano nelle vicinanze). • Un ulteriore vantaggio della copia asincrona è la possibilità di essere implementata via software non dovendo necessariamente ricorrere a sofisticate e costose tecnologie di storage

12. Tecniche di DisasterRecovery • Tecnica mista • Per garantire la disponibilità dei servizi anche in caso di disastro esteso e al tempo stesso ridurre al minimo la perdita di dati vitali si può ricorrere ad una soluzione di tipo misto: effettuare una copia sincrona su un sito intermedio relativamente vicino al primario (distanza< 100 km) e una copia asincrona su un sito a grande distanza.

13. La parte legale • Interessa sia gli enti pubblici che i privati • Un obbligo sin dal dlgs 196/2003 – allegato B, limitatamente ai dati sensibili e giudiziari • Ma se i dati sono il patrimonio dell’azienda… • Un obbligo più stringente per gli enti pubblici dopo l’aggiornamento del Codice dell’Amministrazione Digitale

14. DisasterRecovery • Detto ciò • Dobbiamo pensare di partire con una proposta di start che ci consenta di avere una soluzione • La proposta di 3CiME Technology va in questo senso

15. CTERA Technologies • Una soluzione innovativa • Una soluzione semplice • Una soluzione funzionale • Adatta al DR di moli di dati da 1 a 5 TB

16. Come funziona Server di rete presso il cliente

17. Come funziona Server di rete presso il cliente Server di back-up

18. Come funziona Server di rete presso il cliente Server di back-up Appliance CTERA = lavora sui job di back-up del progetto DR, patrendo dalla deduplica e compressione del server di backup

19. Come funziona Server di rete presso il cliente Server di back-up Appliance CTERA = lavora sui job di back-up del progetto DR, facendone deduplica e compressione Cloud Server disaster presso nostro data center a Modena

20. Come funziona Server di rete presso il cliente Server di back-up Appliance CTERA = lavora sui job di back-up del progetto DR, facendone deduplica e compressione Cloud Server disaster presso nostro data center a Modena

21. SLA • Un servizio di questo genere deve avere delle garanzie • Non solo tecniche • Anche di privacy • E di correttezza

22. SLA • Il data center è quello di Logon Technologies http://www.logontec.it/ con cui abbiamo questa partnership • Alcuni elementi di SLA che caratterizzano il servizio ed il data center

23. SLA • Energia elettrica • 2 stazioni di energia • 4 UPS - 2 per ramo di energia - dotati di accumulatori, in corrente alternata • 1 Gruppo elettrogeno 800KVA - serbatorio 10.000 litri interrato • Condizionatori: 6 x 60KW per raffreddamento sala • Quadri elettrici di distribuzione ridondati • Disponibilità di tensione alternata (220V AC) e continua (-48V DC) • Ogni armadio è alimentato con due linee protette su diversi UPS • Sistema di commutazione automatico e sincronizzazione fra generatore, rete e batterie

24. SLA • Sicurezza e controllo • Condizionatori: 6 x 60KW per raffreddamento sala • Impianto a spegnimento Argon • Rilevamento fumi (sensori ambiente, controsoffitto, pavimento) • Predisposizione anti-intrusione, doppia tecnologia, contatto magnetico, infrarossi da interno, barriere IR esterno ed inerziali • Controllo accessi badge prossimità + tastiera esterna, senza tastiere su tutte le porte interne • Predisposizione telesorveglianza • Riporto allarmi tecnologici • Analisi rischi, dotazioni DPI ed estintori presenti

25. SLA • Gestione del sito tecnologico • Gestione della rete 24/7/365 • Gestione degli allarmi degli apparati tecnici • Risoluzioni dei guasti e ripristino del servizio • Rapporti tecnici sulla rete e sui servizi • Programmazione manutenzione preventiva • Manutenzione e controllo fisico degli apparati di infrastruttura

26. SLA • Ed altri elementi di servizio • Connettività • Sicurezza • Diagnostica

27. Da definire • Il servizio non è una commodity • Bisogna studiare insieme quali dati sono oggetto di disasterrecovery • È necessario programmare opportuni job di back-up • Bisogna analizzare la banda • Occorre schedulare bene le attività di copia DR

28. Grazie per l’attenzione giuseppe.mazzoli@3cime.com – www.3cime.com