A SPETTIMETODOLOGICIPer ogni servizio da proteggere, l’amministrazione deve identificare l’insieme delle risorse(umane, tecnologiche, procedurali e gli spazi di lavoro) necessarie <strong>alla</strong> sua erogazione.Tale insieme viene, in alcune metodologie, definito “isola”. Nel seguito, per comodità,useremo ancora questa definizione, rappresentata graficamente <strong>nella</strong> figura seguente.Figura 4Un esempio di “isola” potrebbe essere l’insieme costituito da un sistema server, un apparatodi stampa, una porzione di LAN, alcune postazioni di lavoro, i dipendenti di una specificaunità organizzativa, i locali di un ufficio.Nell’identificare le risorse da proteggere, si deve tener conto anche di alcune tipologie dioggetti che non è intuitivo collegare direttamente a uno specifico servizio. Ad esempio:• documenti di tipo contrattuale (con fornitori, assicurazioni, partner, ecc.);• documentazione <strong>operativa</strong> (manuali, agende, guide, mappe, schemi tecnici, liste dipassword, configurazioni di sistema);• materiale minuto vario (carte di credito, contante, assegni, timbri e sigilli amministrativi).Da quali eventiNell’identificazione degli eventi da prendere in considerazione, va posta particolare attenzioneagli eventi “non pianificati”, perché sono generalmente la causa principale di interruzionedella continuità <strong>operativa</strong>.Può essere utile suddividere gli eventi non pianificati in due tipologie:• “eventi fisici”, cioè problemi su risorse infrastrutturali e tecnologiche; spaziano daimalfunzionamenti hardware (problematiche di componente) fino all’indisponibilitàprolungata della sede che ospita l’ambiente considerato;• “eventi logici”, cioè problemi causati dal software, quali errori applicativi, virusinformatici o attacchi da parte di hacker.Gli eventi del primo tipo ricadono propriamente nel tema della continuità <strong>operativa</strong>.Viceversa, gli eventi logici sono quasi sempre affrontati e risolti tramite soluzioni di altrotipo, quali, ad esempio, politiche di application management o di security management.Con quali livelli di servizioPer ogni servizio da proteggere, è necessario determinare in che misura esso deve esseremantenuto in operatività. Tale misura viene in genere data attraverso i due indicatori19N. 28 I QUADERNI - Centro Nazionale per l’Informatica <strong>nella</strong> <strong>Pubblica</strong> Amministrazione - GIUGNO 2006
L INEE GUIDA ALLA CONTINUITÀ OPERATIVANELLA P UBBLICA A MMINISTRAZIONERecovery Time Objective (RTO, massimo tempo di indisponibilità del servizio, ovverotempo entro il quale il servizio da proteggere deve essere ripristinato) e Recovery PointObjective (RPO, perdita dati sostenibile, in termini di distanza temporale tra il verificarsidell’emergenza e l’ultimo salvataggio utile e ripristinabile dei dati).La determinazione del RTO e del RPO dei servizi da proteggere viene in genere effettuatadurante la Business Impact Analysis (vedi paragrafo 1.1.2).I livelli di servizio sono normalmente diversi per i vari servizi da proteggere. Da ciò derivail fatto che le esigenze di continuità di un’amministrazione sono, in generale, soddisfatteda un insieme di soluzioni tecnico-organizzative, piuttosto che da una sola. Adesempio, possono essere realizzate soluzioni che assicurano una perdita dati prossima azero per tutti quei servizi per i quali non è possibile o difficilmente realizzabile la ricostruzioneo re-immissione dei dati, mentre per altri servizi (ad esempio il datawarehouse)possono essere attuate soluzioni meno impegnative e costose, perché i dati sono generalmentericostruibili a partire da altri archivi.Nella letteratura tecnica vi sono alcune proposte di classificazione dei servizi sulla base diRTO e RPO. Ad esempio, Gartner Group propone di classificare i servizi erogati in questomodo:• servizi di classe 1: con RTO e RPO prossimi a zero;• servizi di classe 2: con RTO dell’ordine delle 24 ore, e RPO prossimo a 4 ore;• servizi di classe 3: con RTO dell’ordine delle 72 ore, e RPO prossimo a 24 ore;• servizi di classe 4: con RTO misurabile in giorni, e RPO superiore a 24 ore.I servizi delle prime due classi sono, in generale, quelli definibili “critici”. Quelli appartenenti<strong>alla</strong> terza e quarta classe possono essere protetti anche con soluzioni non appartenentiall’area della continuità <strong>operativa</strong> (ad esempio semplicemente con un sistema dibackup).Nello studio del contesto vi sono altri aspetti che devono essere considerati: ad esempiosi dovrà stabilire in anticipo l’eventuale degrado di prestazioni o aumento dei tempi dirisposta nei servizi accettabili in caso di emergenza, così come i rischi residui verso i qualil’amministrazione potrebbe continuare ad essere esposta nonostante l’adozione di unasoluzione di continuità. Infatti non tutti i rischi sono eliminabili, sia perché non economicamenteconveniente sia perché si è disposti ad accettare gli effetti, dopo averli valutati,che ne potrebbero conseguire. Questa valutazione viene effettuata durante le fasi descrittenei prossimi due paragrafi.1.1.1 RISK ASSESSMENT20In questa fase (chiamata anche in letteratura tecnica “analisi del rischio”) vanno determinati,analizzati e classificati i rischi a cui è soggetta l’amministrazione, e vanno stimate levulnerabilità dell’amministrazione, in modo che quest’ultima sia poi capace di individuarele salvaguardie più adeguate ed efficaci.Prima di tutto, è indispensabile definire gli oggetti cardine della problematica, fornendo definizionisulle quali esiste, <strong>nella</strong> letteratura tecnica, un intendimento comune. Nel glossario allegatoal presente documento sono presenti le definizioni di “rischio”, “minaccia”, “vulnerabilità”e “salvaguardia”. Nel seguito si farà ampio riferimento a tali definizioni, eventualmenteN. 28 I QUADERNI - Centro Nazionale per l’Informatica <strong>nella</strong> <strong>Pubblica</strong> Amministrazione - GIUGNO 2006