IL DISASTER RECOVERY DELLA PROVINCIA DI BRESCIA ESPERIENZA DEL C.I.T. Rovato, 23 febbraio 2012

Transcript

1 IL DISASTER RECOVERY DELLA PROVINCIA DI BRESCIA ESPERIENZA DEL C.I.T Rovato, 23 febbraio 2012

2 Agenda L esperienza della Provincia di Brescia. Il servizio DR e il C.I.T. (Centro Innovazione e Tecnologie) Riferimenti / Obblighi normativi (CAD art. 50 bis e richiamo alla circolare 58)

3 Schema DR

4 Obiettivo L obiettivo del progetto provinciale è l implementazione del backup e relativo Disaster Recovery sulla piattaforma BS Gov, identificata da un insieme di server/sistemi sotto elencati su cui operare: - Oracle AS (application server), su macchina fisica - Oracle RDBMS (database), su macchina fisica - 2 sistemi fisici Linux Red Hat + mysql - Oracle SOA su Red Hat, su macchina fisica - Oracle Grid (RDBMS + RMAN server ) su macchina fisica - 2 sistemi virtuali windows con Apache/Tomcat Per realizzare l obiettivo dopo analisi e valutazione è stato scelto il software Asigra

5 Struttura remota Per realizzare il progetto, il server Ds-System Asigra va installato e configurato presso il datacenter della struttura dove vengono salvati i dati (LineaCom) in configurazione standalone ( 1 sistema Asigra Dssystem + 1 istanza MSsql, entrambe sulla stessa Virtula Machine) con almeno 4 CPU e 8 GB Ram. Il Ds-System ha accesso ad una share NAS (Ctera) di 6 TB di cui tre utilizzati per i 3 TB licenziati di Asigra e gli altri 3 TB per mantenere eventuali storicizzazioni dei backup

6 Struttura locale Per utilizzare il software Asigra sulla infrastruttura locale (Provincia di Brescia) è necessario predisporre un License server (macchina fisica windows con porta usb o virtuale con un dispositivo anywhereusb) che gestisce l uso del software Asigra a seconda del licenziamento in TB. I server License, per avere l alta affidabilità saranno due, uno primario presso la Provincia di Brescia e l altro secondario presso la sede di LineaCom di Pavia. I sistemi/server License server e Ds-System hanno un indirizzo pubblico, utilizzando rispettivamente le porte 4417 e 4401.

7 Livello operativo Per il colloquio fra il sistema locale e quello remoto ci sono i server Ds-Client installati sia su una macchina virtuale presso la Provincia di Brescia che nella sede di LineaCom. Queste macchine, 2 server win2008 R2 64b e Linux RH presso ogni sede, gestiscono i backup propedeutici alle operazioni di eventuali DR. E inoltre attivo un accesso vpn fra i sistemi delle due sedi per le attività di supporto che possano svolgersi da remoto da entrambe le parti. Provincia di Brescia ( Datacenter Principale)

8 Replicabilità e riuso Questo sistema è replicabile con estrema facilità anche da altri enti clonando il sistema nel suo complesso copiandone la logica. Ulteriore possibilità per i comuni/enti che adotteranno questa soluzione è la possibilità di avere i dati oltre che salvati nel sito remoto anche salvati in uno spazio disco (storage/hd) presso la struttura locale (local copy). Questo servizio non ha costo (compreso nella licenza) e permette di avere nella propria rete il dato pronto senza dovere collegarsi al sito remoto dove risiedono i backup e la struttura di DR. E altresì vero che a fronte dell evolvere di SPC si potrebbe pensare ad un sistema di DR della Provincia di Brescia come centro a cui far afferire i DR dei comuni stessi.

9 Viaggio del dato 1/5 Come definire i dati/ambienti da salvare e portare in DR. Utilizzando l applicazione DS user di Asigra, installabile sul proprio pc o sul DS client Asigra, con uno wizard si decide cosa salvare (share), dove salvare e la tempistica di salvataggi; Tutte queste informazioni vengono depositate in un database sql; La struttura locale ha uno o più DS client per gestire la schedulazione dei salvataggi locali, mentre la struttura remota (quella che ospita i backup/dr) ha un DS server che gestisce e colletta tutto quanto arriva dalle sedi locali e collocandolo nello storage dedicato; una volta al giorno il DS client si sincronizza con il DB system del DS server comunicando le eventuali variazione che innescheranno il JOB (solitamente giornaliero) che gestisce gli avvii dei singoli backup; Nel frattempo ogni 30 minuti il DS system contatta il licenze server per controllare se la quantità di spazio licenziato richiesto per Asigra è disponibile.

10 Viaggio del dato 2/5 Premesso quanto detto all ora stabilita dalla schedulazione viene risvegliato il DS client che contatterà il DS system ed il server che deve essere backuppato, iniziando le elaborazioni di deduplica, cifratura e compressione. I dati di questa elaborazione posso essere trattati in due modalità: 1) lavorando on line, definendo il size del buffer o il numero di secondi, con l invio dei dati dalla struttura locale alla struttura di backup/dr. Tecnicamente i dati vengo inviati al DS system che li gestirà in base ai parametri indicati nella pianificazione. 2) Eseguendo una local copy dei dati deduplicati, cifrati e compressi su un dispositivo (NAS) locale. Dopo di che, definendo il size del buffer o il numero di secondi, con l invio dei dati salvati sulla NAS dalla struttura locale alla struttura di backup/dr. Cosi facendo si ha un secondo backup in casa. Il colloquio fra il DS client, DS system e NAS utilizza il protocollo tcp/ ip sulla porta 4401 in modalità sicura e criptata

11 Viaggio del dato 3/5 Per replicare gli ambienti virtuali presso la sede remota del DR si fanno le immagini delle singole macchine e trasferite telematicamente nel sito remoto del DR, che ha predisposto una farm virtuale (es.: VmWare) su cui restorare le immagini dei server virtuali, in modo che in caso di disastro siano on line nei tempi previsti dal piano di disastro. Anche per i server fisici presenti nelle sedi locali, ci si comporterà nello stesso modo, avendo solo l accortezza di eseguire (con tools appositi) la migrazione da phisical to virtual. Fatto ciò anche queste macchine potranno essere collocate in ambiente virtuale ed essere on line in caso di disastro. Nella nostra struttura abbiamo anche dislocato nella sede remota uno dei due load balancer (Radware) per avere la perfetta ridondanza della struttura anche nella sede remota in caso di disastro o in caso di necessità per un fault del nostro load balancer (Radware) locale.

12 Viaggio del dato 4/5 Per concludere il viaggio del dato sono da considerare anche i due ottimizzatori di banda, che sono stati posizionati fra la sede locale e quella remota. I due WAN optimization rendono più efficiente il colloquio fra i due sistemi (locale e remoto). Importantissimo è il collaudo che prevede la verifica teorico/pratica di tutti i restore, ovvero mettere in linea i dati e gli ambienti, testandone la piena funzionalità. Dopo il collaudo questa stessa operazione di verifica dovrà essere fatta almeno annualmente seguendo le linee del DRP.

13 Viaggio del dato 5/5 Per valorizzare e soprattutto rendere fruibile il grande lavoro svolto bisogna descrivere con i soggetti che partecipano al DR, il DRP in cui vengono descritti tutti i passi necessari da attuare in caso di disastro. In questo documento bisogna decidere l RPO (potrebbe essere 4 giorni), l RTO (potrebbe essere 7 giorni) e poi dettagliare tutti i passaggi da attuare in caso di disastro. Di seguito verranno illustrate le modalità tecnico/amministrative pubblicate da DigitPa nelle linee guida della CO/DR

14 Punti di forza Punti di forza Agentless Multipiattaforma e Multidevice Cloud

15 Il servizio DR e il CIT Provincia di Brescia ha trasformato il suo percorso in un servizio non solo per l ente provinciale ma anche per il Enti aderenti al CIT (Centro Innovazione e Tecnologie il Centro Servizi Territoriale della Provincia) o coinvolti in progettualità specifiche con la Provincia Nel contratto con Linea Com si è definito il contenuto di servizio e la tariffa a cui possono accedere gli enti aderenti/coinvolti nel CIT Inoltre il CIT affiancherà i propri enti nel percorso di attuazione delle norme di riferimento per il DR e la CO.

16 Riferimenti normativi e Documentazione DEFINIZIONI UTILI (Cfr. Linee Guida DigitPA) Piano di continuità operativa (PCO): il Piano che fissa gli obiettivi, e i principi da perseguire, che descrive i ruoli, le responsabilità, i sistemi di escalation e le procedure per la gestione della continuità operativa, tenuto conto delle potenziali criticità relative a risorse umane, strutturali, tecnologiche; in realtà particolarmente complesse il piano di continuità può essere solo un documento di primo livello, cui vanno associati, per esempio, documenti di secondo livello, quali procedure relative a servizi e/o sistemi specifici e finanche documenti di terzo livello (per esempio sotto la forma di istruzioni di lavoro che riportano le indicazioni operative specifiche) Piano di Disaster Recovery (PDR): il Piano che, costituisce parte integrante del Piano di continuità operativa e stabilisce le misure tecniche ed organizzative per garantire il funzionamento dei centri elaborazione dati e delle procedure informatiche rilevanti in siti alternativi a quelli di produzione.

17 Riferimenti normativi e Documentazione LE DISPOSIZIONI NORMATIVE Articolo 50-bis (Continuità operativa) Codice dell'amministrazione digitale (CAD) Decreto Legislativo 7 marzo 2005, n. 82 (con le modifiche ed integrazioni introdotte dal decreto legislativo 30 dicembre 2010, n. 235, e dal decreto legge 13 agosto 2011, n. 138) In sintesi, l articolo prevede: la predisposizione di un piano di continuità operativa (comma 3, punto a), inclusivo del piano di disaster recovery (comma 3, punto b), da parte di tutte le pubbliche amministrazioni, entro 15 mesi dalla data di entrata in vigore del D.Lgs. 235/2010 ( ), ovvero entro la stesura, preventiva al precedente adempimento, di un apposito Studio di Fattibilità Tecnica (SFT), sul quale deve essere obbligatoriamente richiesto parere di DigitPA (comma 4) LA DOCUMENAZIONE DI RIFERIMENTO (a cura di DigitPA) Linee guida DigitPA per il disaster recovery delle pubbliche amministrazioni (GU n. 295 del ) Ai sensi del comma 3, punto b), articolo 50-bis del CAD Le Linee Guida sono completate da: 1. Strumento di supporto all autovalutazione della criticità dei servizi. Ha finalità di ausilio nel processo di predisposizione dello Studio di Fattibilità Tecnica previsto al comma 4 dell art 50-bis del CAD. Il tool è costituito da un semplice foglio di calcolo, ma a breve sarà disponibile un applicativo web per verificare la Continuità Operativa 2. Note di accompagnamento al tool 3. Studio di Fattibilità Tecnica (Esempio di modello generale di SFT)

18 Gli strumenti da adottare sono in sintesi: 1. Lo Studio di Fattibilità Tecnica (obbligo di parere DigitPA) Sintesi della procedura 2. Il Piano di Continuità Operativa (entro e dopo parere DigitPA su SFT) 3. Il Piano di Disaster Recovery (fa parte del Piano CO) PROCEDURE PER INVIO SFT E ACQUISIZIONE PARERE DIGITPA La Circolare DigitPA n. 58 del 1 dicembre 2011 ha fissato le modalità per l'invio degli SFT ai fini dell'acquisizione del parere obbligatorio. Si tratta di uno dei passaggi della procedura amministrativa che tutti gli enti sono tenuti a svolgere al fine di dotarsi di un sistema di CO/DR. In particolare la circolare riporta: - le informazioni che le Amministrazioni devono inviare a DigitPA ai fini del rilascio del parere sugli SFT e le modalità di presentazione delle richieste di parere - le informazioni che le Amministrazioni devono inviare a DigitPA ai fini dell attività di verifica del costante aggiornamento dei Piani di DR, previste dal comma 3, lettera b), art. 50 bis, del CAD. IMPORTANTE: la richiesta di parere La richiesta di parere sullo SFT deve essere trasmessa mediante PEC all indirizzo PEC Digitpadir@pec.digitpa.gov.it dal Responsabile della Continuità Operativa (così come definito nelle Linee Guida per il Disaster Recovery). La richiesta di parere, deve essere inoltrata sia dalle Amministrazioni che non dispongono di Piani e soluzioni di CO/DR sia dalle Amministrazioni che già si sono dotate degli stessi.

19 Altri riferimenti utili in tema di CO/DR Privacy e misure minime Decreto legislativo 30 giugno 2003, n. 196 CODICE IN MATERIA DI PROTEZIONE DEI DATI PERSONALI Titolo V - Sicurezza dei dati e dei sistemi - Capo II - Misure minime di sicurezza Art. 34. Trattamenti con strumenti elettronici [vedi anche disciplinare tecnico contenuto nell'allegato B)] Decreto-legge 9 febbraio 2012 n. 5 Semplifica Italia (GU 9 febbraio 2012 n. 33) Art. 45. (Semplificazioni in materia di dati personali) In vigore dal L articolo 34 elenca le misure minime da adottare per il trattamento di dati personali effettuato con strumenti elettronici a) autenticazione informatica; b) adozione di procedure di gestione delle credenziali di autenticazione; c) utilizzazione di un sistema di autorizzazione; d) aggiornamento periodico dell'individuazione dell'ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici; e) protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici; f) adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi; h) adozione di tecniche di cifratura o di codici identificativi per determinati trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari. Il Decreto Semplifica Italia ha soppresso la lettera g) tenuta di un aggiornato documento programmatico sulla sicurezza (DPS), nonché i riferimenti al DPS contenuti nell allegato B) Pertanto, salvo che intervengano modifiche da parte del Parlamento, l'obbligo di redigere e aggiornare periodicamente il DPS è venuto meno.

20 Altri riferimenti utili in tema di CO/DR Privacy: proposta di nuova normativa UE Il la Commissione europea ha presentato ufficialmente le proposte relative al nuovo quadro giuridico europeo in materia di protezione dei dati. Si tratta di un Regolamento (sostituirà la direttiva 95/46/CE) e di una Direttiva che disciplinerà i trattamenti per finalità di giustizia e polizia. Mentre il regolamento UE, dopo l'approvazione definitiva, sarà immediatamente esecutivo, non necessitando di recepimento da parte degli Stati membri, la direttiva dovrà essere recepita nella normativa nazionale. Alcuni punti chiave del Regolamento (fonte Garante privacy): aggiunte alcune definizioni (dato genetico, dato biometrico) introdotto principio dell'applicazione del diritto UE anche ai trattamenti di dati personali non svolti in UE, se relativi all'offerta di beni o servizi a cittadini UE diritto degli interessati alla "portabilità del dato" ( es. se si intendesse trasferire i propri dati da un social network ad un altro) ma anche "diritto all oblio", ossia di decidere quali informazioni possano continuare a circolare (in particolare nel mondo online) dopo un determinato tempo, fatte salve specifiche esigenze (es. per rispettare obblighi di legge, per garantire l esercizio della libertà di espressione, per consentire la ricerca storica) scompare l'obbligo per i titolari di notificare i trattamenti di dati personali, sostituito da quello di nominare un "data protection officer" (incaricato della protezione dati) per tutti i soggetti pubblici e per quelli privati al di sopra di un certo numero di dipendenti introdotto il requisito del "privacy impact assessment" (valutazione dell'impatto-privacy) oltre al principio generale di "privacy by design" (previsione di misure a protezione dei dati già al momento della progettazione di un prodotto o di un software) obbligo per tutti i titolari di notificare all'autorità competente le violazioni dei dati personali ("personal data breaches") si fissano più specificamente poteri (anche sanzionatori) e requisiti di indipendenza delle autorità nazionali di controllo

21 Altri riferimenti utili in tema di CO/DR Cloud computing SCHEDE DI DOCUMENTAZIONE DEL GARANTE Cloud computing: indicazioni per l utilizzo consapevole dei servizi Il Garante ha elaborato una serie di riflessioni e indicazioni per il corretto e consapevole trattamento dei dati personali con riferimento all'erogazione di servizi informatici che comportano l'esternalizzazione di dati, documenti e procedure (cloud computing). Il documento è disponibile sul sito del Garante:

22 Ipotesi di piano di collaborazione con DigitPa OBIETTIVI GENERALI 1. ottimizzare e allineare la soluzione di DR della Provincia di Brescia agli standard definiti da DigitPA; completare il percorso integrando aspetti tecnologici e aspetti più strettamente organizzativi; impostare il piano di Continuità Operativa 2. definire le migliori modalità per supportare gli Enti (in particolare i piccoli Comuni) del territorio bresciano nell impostazione degli SFT e dei Piani DR e CO; proporre una soluzione DR/CO compatibile con le risorse degli Enti 3. condividere ed estendere l esperienza avviata con le Province di Lodi, Mantova, Bergamo e Pavia (con cui Brescia sta collaborando nell ambito di un progetto interprovinciale) e con ulteriori 40 Province (e relativi CST) coinvolte sul progetto Elistat (Terzo Avviso del Programma Elisa finanziato tramite fondi PORE), che vede la Provincia di Brescia capofila. Sito di progetto

23 Ipotesi di piano di collaborazione con DigitPa IPOTESI OPERATIVA 1. attivazione da parte del CST di Brescia di una unità di supporto dedicata agli Enti del territorio sul tema DR/CO che raccolga dubbi e criticità e li condivida in modo strutturato con DigitPA 2. definizione di un caso pilota per strutturare una soluzione provinciale che possa essere messa a Riuso nelle reti già esistenti (regionale e nazionale) 3. strutturazione di strumenti di supporto per la redazione dei Piani di DR e CO da parte dei piccoli Comuni (predisposizione di schemi di documenti e/ o tracce, guide con esempi per la compilazione/redazione del piano...) 4. organizzazione di seminari e momenti di incontro operativi rivolti agli Enti e finalizzati al confronto su documenti in fase di redazione e sulle problematiche emergenti

24 Ulteriori informazioni sono reperibili al sito Dove è possibile trovare: - Nell elenco servizi => la scheda del Disaster Recovery - Nell area Innovazione PA: Strumenti => la sezione dedicata a Continuità Operativa e Disaster Recovery GRAZIE