jump to navigation

Il nuovo CAD e la continuità operativa: un nuovo DPS? giovedì 21 febbraio 2013

Posted by andy in Business Continuity, Pubblica Amministrazione.
trackback

Il 22 Dicembre 2010 è stato definitivamente approvato il nuovo CAD (Codice per l’Amministrazione Digitale).

Oltre ai tanti obiettivi di qualità, efficienza e riduzione dei costi, all’art. 50 bis il testo prevede l’obbligo per tutti gli enti e le strutture della PA di dotarsi. entro 15 mesi, di un piano di continuità operativa e di uno per il disaster recovery.

I 15 mesi stanno per scadere, e ci si viene a trovare in una situazione analoga a quella in cui scattò l’obbligo della redazione del DPS (Documento Programmatico sulla Sicurezza), previsto dal D.Lgs. 196/2003, e obbligatorio a decorrere dal 31 Marzo 2006.

Seppur con meno fibrillazione della precedente scadenza per il DPS, qualcosa inizia a muoversi; proverò a fare il punto su quali siano realmente le implicazioni dell’art. 50 bis ed a scattare una fotografia sui diversi approcci emergenti, così da consentire a chi non avesse provato ad analizzare la situazione da vari punti di vista possa collocare l’approccio adottato e valutare le alternative.

Focalizziamoci in primo luogo su quali siano realmente gli obblighi: le pubbliche amministrazioni devono definire:

a) il piano di continuità operativa, che fissa gli obiettivi e i principi da perseguire, descrive le procedure per la gestione della continuità operativa, anche affidate a soggetti esterni. Il piano tiene conto delle potenziali criticità relative a risorse umane, strutturali, tecnologiche e contiene idonee misure preventive. Le amministrazioni pubbliche verificano la funzionalità del piano di continuità operativa con cadenza biennale;

b) il piano di disaster recovery, che costituisce parte integrante di quello di continuità operativa di cui alla lettera a) e stabilisce le misure tecniche e organizzative per garantire il funzionamento dei centri di elaborazione dati e delle procedure informatiche rilevanti in siti alternativi a quelli di produzione. DigitPA, sentito il Garante per la protezione dei dati personali, definisce le linee guida per le soluzioni tecniche idonee a garantire la salvaguardia dei dati e delle applicazioni informatiche, verifica annualmente il costante aggiornamento dei piani di disaster recovery delle amministrazioni interessate e ne informa annualmente il Ministro per la pubblica amministrazione e l’innovazione.

Venendo ora ai principali approcci che riscontro, i più rilevanti appaiono essere i seguenti:

  1. l’ufficio non fa nulla, per la mancanza di risorse;
  2. l’ufficio prova ad analizzare realmente quali siano i punti su cui può intervenire.
  3. l’ufficio si affida ai fornitori, che garantiscono la compliance normativa attraverso la semplice adozione di soluzioni commerciali hardware e/o software.

L’approccio 1. può essere comprensibile: in effetti con i continui tagli alle risorse degli ultimi anni, e con quelli che prevedibilmente continueranno ad arrivare, gli uffici si trovano spesso talmente oberati di lavoro che non risulta fattibile distogliere risorse dai propri incarichi per affrontare, gestire e portare a compimento un progetto di questo tipo. In effetti, qualsiasi progetto non può ragionevolmente essere avviato senza la preventiva assegnazione di adeguate risorse.

Approccio 2: è l’ideale; si affronta oggettivamente il problema, si effettua una spassionata analisi dei rischi, e sulla base delle priorità e delle disponibilità si definisce un piano per gli interventi possibili;

L’approccio 3 è il più pericoloso: l’obiettivo passa dall’interesse della PA all’interesse del fornitore, che tende a massimizzare il proprio ritorno riducendo i costi e massimizzare i margini; a seconda dei casi, al cliente verranno proposte soluzioni che saranno un mix di consulenze, hardware e software.

Ovviamente niente è mai così semplice e definito, e le situazioni reali fanno spesso un mix dei vari approcci, fondendo i vari approcci, in base alle capacità e disponibilità dei referenti degli uffici, e dalla capacità ed insistenza dei fornitori.

Dopo tutto questo preambolo, doveroso per scattare una foto di quella che appare essere la realtà, desidero dedicare qualche parola anche alla sostanza.

Per farlo, focalizziamoci sugli obiettivi imposti dal CAD: un piano di continuità operativa, ed un piano di disaster recovery.

L’IT al giorno d’oggi è di fatto il fondamento di ogni processo operativo, e viene quindi naturale pensare che i termini ‘continuità’ e ‘disaster recovery’ vengano immediatamente associate ai sistemi informativi.

Questo è un grave errore, perché ci porta a dimenticare che l’IT non è il fine, ma il mezzo.

I sistemi, il software, la connettività non sono ciò che dobbiamo proteggere, ma strumenti a supporto dei processi che dobbiamo proteggere.

Prendendo ad esempio un qualunque edificio pubblico, come il palazzo del Comune, o quello di Giustizia, cosa accadrebbe se un terremoto che occorresse la Domenica notte ne compromettesse gravemente la struttura?

Ci si troverebbe alle 8 del Lunedì mattina con tutti gli utenti che si assiepano fuori dal palazzo, con le proprie esigenze, i propri certificati da richiedere, i propri atti da registrare, e nessun ufficio aperto, nessun sistema accessibile.

Certamente i sistemi informativi saranno stati realizzati a regola d’arte; i computer continueranno a funzionare, nel palazzo o in un’altra sede predisposta per il disaster recovery.

Ma i dipendenti dell’ufficio non sapranno cosa fare, dove sedersi, su quale tastiera mettere le mani.

È inverno, e fà piuttosto freddo; la folla all’esterno inizia a rumoreggiare; gli anziani sono già in coda dalla primissima mattina.

Inizia ad arrivare qualche vigile urbano, che non sa cosa fare, o cosa dire, se non che non è possibile accedere ai locali dell’edificio per motivi di sicurezza.

Qualcuno si è preso una giornata di permesso dal lavoro per richiedere un certificato, e senza una tempestiva ordinanza qualche condannato verrà rimesso in libertà per decorrenza dei termini di custodia cautelare.

Passa mezza giornata, e nulla è cambiato; qualche dirigente cerca di organizzarsi come può, ma non sà dove e come allestire le decine o centinaia di postazioni di lavoro per i propri dipendenti, per poter continuare a fornire il servizio dovuto ai cittadini.

Eppure i server e le applicazioni funzionano e i dati ci sono: una perfetta configurazione di disaster recovery, costata tanto hardware, software, consulenze, tempo uomo per l’installazione, le prove ed i collaudi …

E la morale qual’è? Che la continuità operativa, così come la sicurezza, non è uno ‘stato’, ma un processo, ed un processo, per essere tale, deve esistere nel tempo.

Probabilmente per l’emissione di molti certificati sarebbe stato sufficiente predisporre un piano per trasferire temporaneamente il personale presso gli uffici periferici, attivando una connessione ad hoc verso i server, ed informare i vigili urbani sulle informazioni da dare ai cittadini che si fosser presentati agli ingressi del palazzo; anche un comunicato stampa via Internet ed alle televisioni locali e regionali avrebbero potuto essere d’aiuto.

Il numero degli scenari che si possono verificare è naturalmente limitato soltanto dalla fantasia.

Tuttavia, per quanto si possa spendere in tecnologia, il giorno che accade qualcosa di anomalo, è estremamente improbabile che questa consenta di affrontare i problemi, se non è parte di un piano coordinato in cui tutte le persone coinvolte sanno come comportarsi.

Dedico anche qualche riga a tutti quei software progettati per aiutare le organizzazioni ad effettuare le proprie analisi dei rischi e a definire i propri piani di continuità e di recovery.

Si tratta di software veramente notevoli, che più sono completi ed evoluti e più costano.

Tali software hanno tuttavia alcuni difetti:

  • per essere utilizzati correttamente necessitano di specialisti ben preparati;
  • per fornire risultati realistici ed attendibili devono essere compilati in modo puntuale ed esaustivo;
  • devono essere tenuti continuamente aggiornati a fronte di qualsiasi variazione;

Purtroppo gli specialisti sono in generale molto bravi ad utilizzare il software, ma non hanno la minima idea di quali siano i reali rischi che l’organizzazione corre, ed i risultati che emergono sono spesso in conflitto con ciò che il buon senso e l’esperienza indica come prioritario.

In pratica, il miglior compromesso per le PMI e per le organizzazioni anche grandi ma poco mature nella gestione dei propri rischi è quello di avere il supporto di uno specialista che faciliti il percorso di maturazione del processo della gestione della continuità operativa, da cui poi, con il tempo, può derivare naturalmente l’acquisto di software di supporto e di tecnologia per ridurre i costi di ripristino in caso di eventi anomali.

Annunci

Commenti»

No comments yet — be the first.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: