Gestione della continuità operativa

Da Wikipedia, l'enciclopedia libera.

Per Gestione della Continuità Operativa o Continuità Aziendale ("business continuity") si intende la capacità dell'azienda di continuare ad esercitare il proprio business a fronte di eventi avversi che possono colpirla.[1] È composta dall'insieme di attività rivolte a minimizzare gli effetti distruttivi, o comunque dannosi, a seguito di un evento che ha colpito un'organizzazione o parte di essa. [2]

La sfera di interesse della continuità operativa va oltre il solo ambito informatico, interessando l'intera funzionalità di un'organizzazione, e può quindi essere intesa come l'insieme di attività volte a ripristinare lo stato del sistema informatico o parte di esso, ma riguarda anche gli aspetti fisici ed organizzativi per il suo funzionamento, con l'obiettivo di riportare l'organizzazione alle condizioni antecedenti all'evento disastroso.

La pianificazione della continuità operativa e di servizio si chiama business continuity plan (BCP) (in italiano "piano di continuità aziendale"[3]) e viene comunemente considerata come un processo globale che identifica i pericoli potenziali che minacciano l'organizzazione e fornisce una struttura che consenta 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.

Pianificazione[modifica | modifica wikitesto]

La pianificazione, la prevenzione e la preparazione sono una parte fondamentale di qualsiasi sistema di gestione della continuità operativa. L'attività inizia con la comprensione del business, per poi identificare i potenziali rischi e le minacce per le attività di business, sia internamente che esternamente all'azienda. Si consiglia inoltre di esaminare la resilienza dei fornitori.

In corso di pianificazione a livello di gestione per garantire che le misure necessarie siano seguite regolarmente è necessario identificare i probabili incidenti, disastri, emergenze, e/o minacce. La pianificazione coinvolge anche la valutazione del probabile effetto distruttivo o dannoso di tali eventi, lo sviluppo di strategie e piani di recupero e il mantenimento della loro disponibilità attraverso la formazione del personale e la sperimentazione del Disaster Recovery Plan.

Il Disaster Recovery Plan, che è mirato ai servizi informatici, è quindi un sottoinsieme del business continuity plan e contiene le informazioni riguardo alle azioni da intraprendere in caso di incidente, chi è coinvolto nell'attività e come deve essere contattato. Il piano riflette la posizione dell'organizzazione e degli stakeholders.

Gli aspetti da considerare sono:

  • l'uso di ausili alla pianificazione, tool di sviluppo e manutenzione dei piani;
  • descrizione delle attività per le figure coinvolte;
  • i piani di azione e le checklist da utilizzare;
  • quali informazioni e quale documentazione di supporto deve essere utilizzata.

Occorre riporre attenzione nella terminologia; termini come "incidente" o "disastro" devono essere chiari e condivisi. In particolare, occorre distinguere tra una "interruzione di servizio" ed un "disastro"; nel secondo caso deve essere definita la procedura di "escalation" da applicare quando il disastro è avvenuto ed è stato dichiarato. Occorre definire quindi un glossario condiviso e documentato.

Tra i rischi da considerare vi sono quelli legati all'informazione e alla sua gestione. Nell'ambito del Rischio informatico il piano di Business Continuity fa parte del Piano di contingenza. La business continuity viene pianificata secondo il Ciclo di Deming.

Documentazione

In ambienti di grandi dimensioni, il turnover del personale è inevitabile e deve essere pianificato come parte della business continuity. La soluzione ai problemi associati al cambio o al totale rinnovamento del personale si ottiene con l'utilizzo di una documentazione completa ed aggiornata. Questo assicura che il nuovo personale abbia le informazioni necessarie per diventare rapidamente competente e produttivo rispetto alle funzioni aziendali. Ciò implica anche che la documentazione relativa alle funzioni di business sia in gran parte generata (anziché scritta) dai sistemi esistenti e gestito in modo automatico.

Business Impact Analysis (BIA)[modifica | modifica wikitesto]

L'intero concetto di continuità aziendale si basa sulla identificazione di tutte le funzioni aziendali all'interno di un'organizzazione e quindi sull'assegnazione di un livello di importanza per ogni funzione aziendale. Un'analisi di impatto sul business è lo strumento principale per la raccolta di queste informazioni e l'assegnazione di criticità, obiettivi, punti di ripristino ed obiettivi dei tempi di recupero; È quindi parte fondamentale della continuità aziendale.

La BIA può essere utilizzata per identificare entità e tempistiche dell'impatto del disastro sui diversi livelli di un'organizzazione. Per esempio si può esaminare l'effetto di interruzione delle attività operative, funzionali e strategiche di un'organizzazione. Non solo le attività in corso, ma l'effetto di perturbazioni sui principali cambiamenti di business e l'introduzione di nuovi prodotti o servizi, per esempio, possono essere determinati dalla BIA.

La maggior parte delle norme richiede che l'analisi dell'impatto sulle imprese debba essere riesaminato a intervalli definiti appropriati per ogni organizzazione e ogni volta che accade uno dei seguenti casi:

  • Cambiamenti significativi nel processo di business interni, della posizione o della tecnologia dell'azienda
  • Cambiamenti significativi del contesto economico esterno - come il mercato o di eventuali cambiamenti normativi [4]

Sicurezza e Valutazione d'Impresa[modifica | modifica wikitesto]

Nel contesto economico globale di oggi, la sicurezza deve essere la priorità assoluta nella gestione dell'Information Technology. Per la maggior parte delle organizzazioni, la sicurezza è d'obbligo e viene tenuta molto in considerazione all'interno della valutazione di un'impresa.

Regolamenti richiedono che le modifiche alle funzioni di business debbano essere documentati e monitorati a scopo di controllo e vengono indicati come "change control".

Questo porta ad un livello di stabilità delle funzioni aziendali richiedendo anche al personale di supporto di documentare e coordinare le proposte di modifica dei sistemi sottostanti. Poiché questo processo diventa sempre più automatizzato, l'accento futuro sarà minore sul controllo del personale, e maggiore sulla conformità alle normative vigenti.

La revisione e la pubblicazione dei documenti necessari alla gestione della continuità operativa sta diventando infatti uno degli aspetti più costosi e che richiede maggiore tempo.

Uno degli obiettivi di business continuity è l'automazione dei data center, che include la gestione delle revisioni. Tutte le funzioni aziendali moderne dovrebbero essere progettate con il concetto di generare automaticamente le informazioni sulla conformità di controllo e la documentazione necessaria. Questo ridurrebbe drasticamente i tempi ed i costi associati alla produzione manuale di queste informazioni.

L'automazione è spesso associata con l'idea di una gestione centralizzata - nella zona di memorizzazione dei dati e di gestione dei dati. Le soluzioni attuali sono basate su consolidamento dello storage in grado di garantire la sicurezza dei dati, l'efficienza, l'alta disponibilità, affidabilità e convenienza. [5]

Service level agreements (SLA)[modifica | modifica wikitesto]

L'interfaccia tra la gestione e le tecnologie è il Service Level Agreement (SLA): ciò fornisce un contratto scritto che prevede le aspettative della gestione per quanto riguarda la disponibilità di una funzione aziendale necessaria e le tecnologie necessarie a sostegno di tale funzione aziendale.

Sistemi di Comunicazione[modifica | modifica wikitesto]

Un altro componente della continuità aziendale è la comunicazione durante i tempi di recupero. I membri del team di disaster recovery devono essere in grado di comunicare efficacemente tra di loro, così come con i dirigenti, gli amministratori, i clienti, i partner e anche con i media. Al fine di evitare alcuni dei potenziali problemi connessi ai canali di comunicazione interrotti, il piano di continuità operativa dovrebbe includere un manager che si occupi di tutte le comunicazioni in quella zona, la collaborazione tra i dirigenti e le pubbliche relazioni, le persone e le aziende in modo da mettere in pratica il piano di disaster recovery.

Continuità Operativa in Outsourcing[modifica | modifica wikitesto]

L'importanza sempre maggiore delle informazioni raccolte e archiviate dalle aziende, correlate alla sempre più alta complessità dei sistemi informatici, ha recentemente portato al trasferimento della gestione di rischio ad aziende esterne (outsourcing). Vengono delegate le attività di pianificazione, aggiornamento e ripristino in caso di disastri.

Rimane essenziale verificare, in particolare, che il fornitore sia finanziariamente affidabile, che sia in grado di fornire le apparecchiature e i servizi di cui l'amministrazione necessita, che aggiornerà le apparecchiature adeguandosi a quelle dell'organizzazione, che il suo personale sia sufficientemente preparato e occorre specificare contrattualmente quale soluzione alternativa venga prospettata nel caso l'emergenza colpisca anche altri clienti (del fornitore) a priorità maggiore.

Ovviamente di principale importanza è che il fornitore garantisca la confidenzialità dei dati di cui ha a carico la gestione.[6]

Standard[modifica | modifica wikitesto]

Esistono standard internazionali che fanno riferimento alla continuità operativa.

In Italia è di particolare rilevanza lo standard UNI CEI ISO/IEC 27001:2014 “Tecnologia delle informazioni - Tecniche di sicurezza – Sistemi di gestione della sicurezza delle informazioni - Requisiti” che, pur trattando della sicurezza informatica, identifica nella continuità operativa un elemento essenziale.

In ambito internazionale sono da ricordare le due norme: ISO 22301:2012 "Societal security -- Business continuity management systems --- Requirements", che costituisce il riferimento per il percorso di certificazione, e ISO/IEC 27031:2011 "Information technology -- Security techniques -- Guidelines for information and communication technology readiness for business continuity".[7] Specifica un sistema di gestione della continuità operativa di un'organizzazione. Ha uno stile formale per la facilitazione della certificazione e del rispetto delle norme presenti. E supportato da ISO 22313: 2012 e viene fornita consulenza in materia di gestione della continuità operativa.

Regno Unito - British Standard BS 25999

È uno standard di gestione della continuità operativa diviso in due parti: "BS 25.999-1: 2006 Business Continuity Management. Code of Practice" che ha offerto indicazioni per l'applicazione pragmatica, ma è stata ritirata nel 2012, quando ISO 22313 l'ha efficacemente sostituita; E "BS 25999-2: 2007 Specifiche per Business Continuity Management" che specifica formalmente una serie di requisiti per un sistema di gestione della continuità operativa. Anch'essa è stata ritirata nel 2012, quando è stato (a tutti gli effetti) sostituito da ISO 22301.

Nord America - NFPA 1600: Standard on Disaster/Emergency Management and Business Continuity Programs pubblicato dalla National Fire Protection Association.

Nord America - ANSI/ASIS BSI BCM.01:2010 Business Continuity Standard

Per la sicurezza, la preparazione e la continuità di gestione dei sistemi: requisiti e guida per l'uso dello standard American National è stato preso in considerazione per l'inserimento nel DHS PS- Prep, un programma volontario progettato per migliorare la resilienza nazionale in un ambiente tutti i rischi, migliorando la preparazione del settore privato.

Australia - Pubblicato da Standards Australia HB 292-2006

Nel 2010, Standards Australia ha introdotto, dopo aver pubblicato lo standard HB 292-2006, il proprio standard AS / NZS 5050; che si collega più a stretto contatto con la gestione delle pratiche di rischio tradizionale. Questa interpretazione è progettata per essere utilizzata in combinazione con AS / NZS. [8]

Pubblica Amministrazione in Italia[modifica | modifica wikitesto]

La pubblica amministrazione è tenuta ad assicurare la continuità dei propri servizi per garantire il corretto svolgimento della vita nel Paese secondo l'Art. 97 della Costituzione ed il principio di buon andamento dell'amministrazione, da rispettare seguendo il Codice dell'Amministrazione Digitale (CAD) che agli articoli 50 e 50-bis esprime e dichiara le norme che ogni pubblica amministrazione deve seguire in caso di disastro.

Il Dlgs 30 dicembre 2010 introduce nel CAD l'articolo 50-bis (Continuità operativa) i seguenti punti:

  1. In relazione ai nuovi scenari di rischio, alla crescente complessità dell'attività istituzionale caratterizzata da un intenso utilizzo della tecnologia dell'informazione, le pubbliche amministrazioni predispongono i piani di emergenza in grado di assicurare la continuità delle operazioni indispensabili per il servizio e il ritorno alla normale operatività.
  2. Il Ministro per la pubblica amministrazione e l'innovazione assicura l'omogeneità delle soluzioni di continuità operativa definite dalle diverse Amministrazioni e ne informa con cadenza almeno annuale il Parlamento.[9]

Per la Pubblica Amministrazione la Continuità Operativa è un dovere perché:

  • E' tenuta ad assicurare la continuità dei propri servizi per garantire il corretto svolgimento delle funzioni pubbliche ed il diritto dei cittadini ad accedere ai servizi pubblici per via telematica (art. 3, D.lgs. 82/2005, “Codice dell'Amministrazione Digitale”);
  • L'Art. 97 della Costituzione ed il principio di buon andamento dell'amministrazione devono essere garantiti anche se si utilizzano tecnologie ICT a supporto dei procedimenti;
  • La normativa in merito alla Continuità Operativa per gli Enti della PA all'interno del nuovo CAD ( art. 50-bis del Dlgs 30 dicembre 2010 , n. 235 - Modifiche ed integrazioni al decreto legislativo 7 marzo 2005, n. 82 ), ed in particolare le “Linee guida per il Disaster Recovery della PA” emesse dall'Agenzia per l'Italia Digitale, impongono l'adozione da parte degli Enti di un Piano di Disaster Recovery in grado di salvaguardare i servizi erogati mediante specifiche infrastrutture ICT.[10]

All'interno del CAD sono presenti dall'articolo 50 in poi le maggiori norme che le PA devono rispettare a seguito di un disastro che ne infici la continuità operativa. Queste norme in molti casi sono state redatte a seguito di eventi disastrosi accaduti in Italia recentemente come il terremoto in Abruzzo e in Emilia.

L'Agenzia per l'Italia Digitale (AgID) ha recentemente pubblicato l'aggiornamento delle “Linee Guida per il Disaster Recovery (DR) delle Pubbliche Amministrazioni” ai sensi del comma 3, lettera b) dell'art. 50bis del d.lgs. 7 marzo 2005, n. 82(Codice dell'Amministrazione Digitale).

La nuova versione è il risultato di un lavoro congiunto fra AgID, Pubbliche Amministrazioni e rappresentanze dei fornitori. Gli interventi di razionalizzazione rispettano le evoluzioni delle funzioni dell'Agenzia e del quadro normativo vigente, le disposizioni in tema di sicurezza informatica e tutela della privacy, nonché i provvedimenti del Garante per la protezione di dati personali. [11]

Il Modello di Studio della Fattibilità tecnica (SFT) di un piano di disaster recovery, che deve essere necessariamente redatto da ogni PA ha il seguente modello generale:

  1. Introduzione
  2. Informazioni generali
  3. L'ambito dello studio di fattibilità tecnica
  4. Il risultato del percorso di autovalutazione
  5. La/e soluzione/i tecnologica e tecnica/e
  6. Tempi e modalità di realizzazione della/e soluzione/i
  7. Allegati

Altri componenti[modifica | modifica wikitesto]

La pianificazione di disaster recovery si presenta come un sottoinsieme di procedure, di seguito è riportato un elenco di entità fisiche e logiche all'interno di un ambiente di IT che richiedono l'applicazione di una metodologia di business continuity. Applicando la metodologia si dovrebbe includere la definizione delle cose quali politiche, linee guida, standard, procedure, ecc, per ogni elemento della lista:

  • Firmware e Microcode
  • Storage su dischi interni ed esterni
  • Nomi di Sistema e gestione
  • Partizioni
  • Nomi dei Nodi
  • Nomi degli Host
  • Alias DNS
  • Console di accesso all'hardware
  • Virtualizzazioni
  • Design del Network
  • VLAN's
  • Sottoreti TCP/IP
  • User names e UID
  • Group names e GID
  • Sicurezza
  • Installazione e Monitoraggio Sistema
  • Installazione e Monitoraggio Applicativi
  • Installazione e Monitoraggio Database
  • Gestione delle Patch

Note[modifica | modifica wikitesto]

  1. ^ IMQ, Certificazione Sistemi di Gestione per la Continuità Operativa Norma BS 25999-2.
  2. ^ annachiara.dipaolo, Continuità operativa, su www.agid.gov.it, 17 ottobre 2013. URL consultato il 14 giugno 2016.
  3. ^ Il termine "business" ovvero "affari" solitamente non è tradotto ovvero è implicito nel termine continuità (operativa).
  4. ^ BCI Good Practice Guidelines 2007
  5. ^ Open-E Inc., Solutions for data storage management and centralization, su www.open-e.com. URL consultato il 30 giugno 2016.
  6. ^ Ci sono particolari cautele da osservare quando si acquisisce la Continuità Operativa in outsourcing?, su www.agid.gov.it, 04 ottobre 2013. URL consultato il 14 giugno 2016.
  7. ^ Esistono standard per la Continuità Operativa?, su www.agid.gov.it, 04 ottobre 2013. URL consultato il 14 giugno 2016.
  8. ^ Standards Australia, su www.standards.org.au. URL consultato il 30 giugno 2016.
  9. ^ Codice dell'amministrazione digitale | AgID, su archivio.digitpa.gov.it. URL consultato il 30 giugno 2016.
  10. ^ monica, Strumenti e metodi per la Continuità Operativa ed il Disaster Recovery, su www.riuso-pa.piemonte.it. URL consultato il 30 giugno 2016.
  11. ^ Agenzia per l'Italia Digitale, agid.gov.it.

Voci correlate[modifica | modifica wikitesto]