Disaster recovery

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

Con disaster recovery (brevemente DR, in italiano: ripresa[1] dal disastro), in informatica ed in particolare nell'ambito della sicurezza informatica, si intende l'insieme delle misure tecnologiche e logistico/organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi di business per imprese, associazioni o enti, a fronte di gravi emergenze che ne intacchino la regolare attività. Il Disaster Recovery Plan (DRP) (in italiano, Piano di Recupero del Disastro) è il documento che esplicita tali misure, compreso all'interno del più ampio piano di continuità operativa (BCP).

Storia[modifica | modifica wikitesto]

Si è sviluppato nella seconda metà del XX secolo, quando i responsabili dei centri di calcolo hanno iniziato a riconoscere la dipendenza delle loro organizzazioni dai loro sistemi informatici. A quel tempo, la maggior parte dei sistemi erano mainframe orientati sulla programmazione batch che, in molti casi, potevano essere interrotti per un numero di giorni prima che si producessero danni significativi all'organizzazione.

Come consapevolezza della potenziale interruzione del business che avrebbe seguito un disastro correlato all'IT, l'industria del Disaster Recovery si è sviluppata per fornire centri per il backup dei dati, con Sun Information Systems (che in seguito divenne Sungard Availability Services) che divenne il primo importante fornitore di hot spot commerciali degli Stati Uniti, stabilito nel 1978 in Sri Lanka.

Durante gli anni '80 e '90, la consapevolezza del cliente e dell'industria sono cresciute rapidamente, guidate dall'avvento di sistemi aperti e di elaborazione sistema real-time che hanno aumentato la dipendenza delle organizzazioni dai loro sistemi IT. Le normative che impongono la continuità aziendale dei piani di Disaster Recovery per le organizzazioni in vari settori dell'economia, imposte dalle autorità e dai partner commerciali, hanno aumentato la richiesta e portato alla disponibilità di servizi di Disaster Recovery commerciali, compresi i data center mobili consegnati in un luogo di recupero idoneo (generalmente in camion).

In occidente una grossa spinta allo sviluppo dei Piani di Disaster Recovery è arrivata dopo l’attacco terroristico al World Trade Center di New York l’11 settembre 2001. In Italia le linee guida per il sistema finanziario sono state emesse da Banca d’Italia a maggio del 2004.

Questa crescente dipendenza dai sistemi IT, così come la maggiore consapevolezza da disastri su vasta scala come tsunami, terremoti, alluvioni ed eruzioni vulcaniche, hanno generato prodotti e servizi correlati al recupero dei dati e dei sistemi dopo i disastri, che vanno dalle soluzioni ad alta disponibilità fino alle strutture Backup site. Una rete migliorata significava che i servizi IT critici potevano essere serviti da remoto, quindi il recupero on-site (sul posto) è diventato meno importante.

L'ascesa del cloud computing dal 2010 continua questa tendenza: al giorno d'oggi, conta ancora meno dove i servizi di elaborazione sono fisicamente serviti, purché la rete stessa sia sufficientemente affidabile (un problema separato e meno preoccupante dal momento che le reti moderne sono altamente resilienti per costruzione). "Il recupero come servizio" (dall'inglese RaaS - "Recovery as a Service") è una delle caratteristiche o dei vantaggi di sicurezza del Cloud Computing promosso da Cloud Security Alliance.[2]

In ambito Cyber Security, l'Università Carnegie Mellon di Pittsburgh rilascia la certificazione internazionale di tipo Computer Emergency Response Team, e opera in collaborazione col Forum of Incident Response Teams (FIRST).

Classificazione[modifica | modifica wikitesto]

I disastri possono essere classificati in due grandi categorie.

  • La prima riguarda i disastri naturali come inondazioni, uragani, tornado o terremoti. Anche se è impossibile prevenire un disastro naturale, è possibile, però, avvalersi di strumenti per misure di gestione del rischio, come evitare situazioni di disastro e realizzare un buon piano per il recupero.
  • La seconda categoria è rappresentata da disastri provocati dall'uomo, come fuoriuscite di materiale pericoloso, guasti infrastrutturali, bioterrorismo, disastrosi bug informatici o mancate implementazioni dei cambiamenti. In questi casi, la sorveglianza, i test e la pianificazione della mitigazione sono inestimabili.

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.

Per una corretta applicazione del piano, i sistemi devono essere classificati secondo varie definizioni.

Critici[modifica | modifica wikitesto]

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.

Vitali[modifica | modifica wikitesto]

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[modifica | modifica wikitesto]

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[modifica | modifica wikitesto]

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.

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. Software può significare: sistemi operativi, applicazioni, configurazioni HD, policy di dominio, ecc. File può significare: database, documenti, sorgenti e setup, copie di backup, ecc.

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.

Caratteristiche[modifica | modifica wikitesto]

Misure di controllo[modifica | modifica wikitesto]

Le misure di controllo sono le azioni o i procedimenti che possono ridurre o eliminare varie minacce per le organizzazioni. Diversi tipi di misure possono essere inclusi nel Piano di Disaster Recovery (DRP). Qui "misura di controllo" non ha il significato di "verifica, valutazione, prova" ma "metodo operativo per tenere sotto controllo".

Il Piano di Disaster Recovery è un sottoinsieme di un processo più ampio noto come piano di continuità operativa e include la pianificazione per la ripresa di applicazioni, dati, hardware, comunicazioni elettroniche (come il networking) e altre infrastrutture IT. Un piano di continuità operativa (BCP) include la pianificazione di aspetti non correlati all'IT come strutture, crisi di comunicazione e protezione della reputazione e dovrebbe fare riferimento al Piano di Disaster Recovery (DRP) per il ripristino/continuità dell'infrastruttura IT.

Le misure di controllo del Disaster Recovery IT possono essere classificate nei seguenti tre tipi:

  • Misure preventive - Controlli mirati a prevenire un evento;
  • Misure investigative - Controlli volti a rilevare o scoprire eventi indesiderati;
  • Misure correttive - Controlli volti a correggere o ripristinare il sistema dopo un disastro o un evento.

Le buone misure del Piano di Disaster Recovery impongono che questi tre tipi di controlli siano documentati ed esercitati regolarmente utilizzando i cosiddetti "Test DR".

Nella continuità operativa l'interruzione viene detta disruption: quando l'interruzione è di tipo informatico o elettrico o il termine prevalente è outage; quando l'interruzione è di tipo telematico il termine prevalente è downtime cioè (tempo di) inattività).

Conseguenze e risvolti[modifica | modifica wikitesto]

L'impatto di tali emergenze è tale che 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 disaster recovery, 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.[3] I disastri informatici con ingenti perdite di dati nella maggioranza dei casi possono provocare il fallimento dell'impresa o dell'organizzazione, ragion per cui investire in opportune strategie di recupero diventa una scelta quasi obbligata.

Tecniche[modifica | modifica wikitesto]

Allo stato attuale, la tecnologia offre la possibilità di realizzare varie soluzioni di continuità e Disaster Recovery, fino alla garanzia di fatto di un'erogazione continua dei servizi IT, necessaria per i sistemi (es. finanziari o di monitoraggio) definiti mission critical.

In pratica i sistemi e i dati considerati importanti vengono ridondati in un "sito secondario" o "sito di Disaster Recovery" 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 nel più breve tempo e con la minima perdita di dati possibile.

Chiaramente quanto più stringenti saranno i livelli di continuità tanto più alti saranno i costi di implementazione della soluzione. In particolare, i livelli di servizio sono usualmente definiti dai due parametri Recovery Time Objective (RTO) e Recovery Point Objective (RPO).

Premessa[modifica | modifica wikitesto]

Attualmente le tecniche di sincronismo dei dati fra il datacenter primario e il datacenter secondario (Disaster Recovery) si basano su un continuo aggiornamento dei dati, con l’obiettivo di avere sempre a disposizione nel sito secondario una copia dei dati del sito primario.

Questa tecnica è utilizzabile per eseguire il ripristino in caso di incidenti hardware e software, ma non è utilizzabile in caso di incidenti Cyber. Negli incidenti cyber, i malware/virus o altro, sono inseriti nei database anche mesi prima della loro attivazione. Per risolvere gli incidenti Cyber è necessario utilizzare tecniche di backup che creino più copie dei database al fine di ritornare indietro nel tempo e ripristinare la copia priva del malware.

Replica sincrona[modifica | modifica wikitesto]

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 Disaster Recovery possono essere riavviate molto rapidamente (basso RTO e RPO 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.

Replica asincrona[modifica | modifica wikitesto]

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. 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.

Tecnica mista[modifica | modifica wikitesto]

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 e una copia asincrona su un sito a grande distanza.

Strategie[modifica | modifica wikitesto]

Prima di selezionare una strategia di Disaster Recovery (DR), un pianificatore per il DR fa riferimento innanzitutto al piano di continuità operativa aziendale che dovrebbe indicare le metriche chiave di Recovery Time Objective (RTO) e Recovery Point Objective (RPO) per vari processi aziendali (come il processo per gestire il libro paga, generare un ordine, ecc.). Le metriche specificate per i processi di business vengono quindi mappate ai sistemi IT e all'infrastruttura sottostanti che supportano tali processi.[4]

RTO e RPO incompleti possono far deragliare rapidamente un piano di Disaster Recovery. Ogni articolo nel piano DR richiede un punto di ripristino e un obiettivo temporale definiti, in quanto la mancata creazione di questi può portare a problemi significativi che possono estendere l'impatto del disastro.[5] Una volta che le metriche RTO e RPO sono state mappate sull'infrastruttura IT, il pianificatore del DR può determinare la strategia di ripristino più adatta per ciascun sistema. In definitiva, l'organizzazione definisce il budget IT e pertanto le metriche RTO e RPO devono adattarsi al budget disponibile. Mentre la maggior parte dei responsabili delle unità di business vorrebbe la perdite di dati e di tempo pari a zero, il costo associato a quel livello di protezione potrebbe rendere impraticabili le soluzioni ad alta disponibilità desiderate. Un'analisi costi-benefici spesso stabilisce quali misure di Disaster Recovery sono implementate.

Alcune delle strategie più comuni per la protezione dei dati includono:

  • backup eseguiti su nastro e inviati fuori sede a intervalli regolari;
  • backup fatti su disco sul posto e copiati automaticamente sul disco fuori sito o fatti direttamente sul disco fuori sito;
  • replica dei dati in una posizione fuori sito, che supera la necessità di ripristinare i dati (solo i sistemi devono quindi essere ripristinati o sincronizzati), spesso facendo uso della tecnologia SAN (Storage Area Network);
  • soluzioni su cloud privati che replicano i dati di gestione (VM, Modelli e dischi) nei domini di archiviazione che fanno parte dell'installazione del cloud privato. Questi dati di gestione sono configurati come una rappresentazione XML denominata OVF (Open Virtualization Format) e possono essere ripristinati una volta che si verifica un disastro;
  • soluzioni di cloud ibrido che replicano sia i data center in loco che quelli esterni al sito. Queste soluzioni offrono la possibilità di eseguire immediatamente il failover sull'hardware locale sempre in loco, ma nel caso di un disastro fisico, i server possono essere attivati anche nei data center cloud;
  • l'uso di sistemi ad alta disponibilità che mantengono sia i dati che il sistema replicati fuori sede, consentendo l'accesso continuo a sistemi e dati, anche dopo un disastro (spesso associato all'archiviazione in cloud)[6].

In molti casi, un'organizzazione può scegliere di utilizzare un fornitore di servizi di Disaster Recovery in outsourcing per fornire un sito e sistemi stand-by anziché utilizzare le proprie strutture remote, sempre tramite il cloud computing.

Oltre a prepararsi per la necessità di recuperare i sistemi, le organizzazioni attuano anche misure precauzionali con l'obiettivo di prevenire un disastro in primo luogo. Questi possono includere:

  • mirror locali di sistemi e/o dati e utilizzo di tecnologie di protezione del disco come RAID;
  • protezioni da sovratensione - per ridurre al minimo l'effetto degli sbalzi di tensione sulle delicate apparecchiature elettroniche;
  • utilizzo di un gruppo di continuità (UPS) e/o generatore di backup per mantenere in funzione i sistemi in caso di interruzione di corrente;
  • sistemi di prevenzione/attenuazione degli incendi come allarmi ed estintori;
  • software anti-virus e altre misure di sicurezza.

Note[modifica | modifica wikitesto]

  1. ^ Nell'italiano informatico recovery è tradotto anche "ripristino". Restore, anch'esso usato in informatica, è tradotto "recupero".
  2. ^ (EN) SecaaS Category 9 // BCDR Implementation Guidance - Cloud Security Alliance, in Cloud Security Alliance. URL consultato il 7 gennaio 2018.
  3. ^ Business continuity statistics: where myth meets fact. Continuity Central. 24 April 2009. Retrieved 3 August 2012.
  4. ^ Gregory, Peter H., CISA certified information systems auditor all-in-one exam guide, McGraw-Hill, 2010, ISBN 9780071487559, OCLC 506020199.
  5. ^ Five Mistakes That Can Kill a Disaster Recovery Plan | Dell, su content.dell.com, 16 gennaio 2013. URL consultato il 10 gennaio 2018 (archiviato dall'url originale il 16 gennaio 2013).
  6. ^ (EN) How to Use the Cloud as a Disaster Recovery Strategy, in Inc.com, 2011-06-23T01:5900-0400. URL consultato il 10 gennaio 2018.

Voci correlate[modifica | modifica wikitesto]

Altri progetti[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

La normativa italiana in tema di Disaster Recovery e continuità operativa. Decreto Legislativo 7 marzo 2005, n. 82 e s.m.i. – Art. 50-bis

Estratto da "https://it.wikipedia.org/w/index.php?title=Disaster_recovery&oldid=137326096"