Disaster recovery: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m →Replica sincrona: secondo me è da intendersi "copia" |
Annullata la modifica 146825835 di 95.255.184.48 (discussione) rb (spam) Etichetta: Annulla |
||
| (25 versioni intermedie di 19 utenti non mostrate) | |||
Riga 1:
Con '''disaster recovery''' (brevemente DR, in [[Lingua italiana|italiano]]: ''
== Storia ==
Riga 8:
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|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 [[Maremoto|tsunami]], [[Terremoto|terremoti]], [[Alluvione|alluvioni]] ed [[Eruzione vulcanica|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 [[:en:Backup_site|hot-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.▼
▲Questa crescente dipendenza dai sistemi IT, così come la maggiore consapevolezza da disastri su vasta scala come [[Maremoto|tsunami]], [[Terremoto|terremoti]], [[Alluvione|alluvioni]] ed [[Eruzione vulcanica|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
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 [[:en:Cloud_Security_Alliance|Cloud Security Alliance]].<ref>{{Cita news|lingua=en-US|url=https://cloudsecurityalliance.org/download/secaas-category-9-bcdr-implementation-guidance/|titolo=SecaaS Category 9 // BCDR Implementation Guidance - Cloud Security Alliance|pubblicazione=Cloud Security Alliance|accesso=2018-01-07}}</ref>▼
▲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
In ambito ''[[Sicurezza informatica|Ciber 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)''.▼
▲In ambito ''[[Sicurezza informatica|
== Classificazione ==
Riga 20 ⟶ 22:
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.
Riga 42 ⟶ 43:
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.
==
=== Misure di controllo ===
Le misure di controllo sono
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:
*
*
*
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 ==▼
▲=== Conseguenze e risvolti ===
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 [[Information Technology|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.<ref>[http://www.continuitycentral.com/feature0660.html ''Business continuity statistics: where myth meets fact.''] Continuity Central. 24 April 2009. Retrieved 3 August 2012.</ref> I disastri informatici con ingenti perdite di dati nella maggioranza dei casi possono provocare il [[fallimento (diritto)|fallimento]] dell'[[impresa]] o dell'organizzazione, ragion per cui investire in opportune strategie di recupero diventa una scelta quasi obbligata.
Riga 63 ⟶ 65:
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 ===
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 ===
Riga 100 ⟶ 105:
* sistemi di prevenzione/attenuazione degli incendi come allarmi ed estintori;
* software [[Antivirus|anti-virus]] e altre misure di sicurezza.
== Note ==
<references/>
== Voci correlate ==
Riga 111 ⟶ 119:
* [[Gestione delle emergenze]]
==Altri
{{interprogetto}}
<references/>La [https://web.archive.org/web/20160824223431/http://gotocloud.it/art-50-bis-disaster-recovery-continuita-operativa/ normativa italiana] in tema di Disaster Recovery e continuità operativa. [https://web.archive.org/web/20160914203738/http://www.agid.gov.it/sites/default/files/leggi_decreti_direttive/art._50-bis_cad_0.pdf Decreto Legislativo 7 marzo 2005, n. 82 e s.m.i. – Art. 50-bis]{{Portale|informatica|sicurezza informatica}}▼
==Collegamenti esterni==
▲
{{Portale|informatica|sicurezza informatica}}
[[Categoria:Tecniche di difesa informatica]]
| |||