Recuperare în caz de dezastru

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Prin recuperarea în caz de dezastru (pe scurt DR, în italiană : Recovery [1] from Disaster ), în tehnologia informației și în special în domeniul securității informațiilor , ne referim la setul de măsuri tehnologice și logistice / organizaționale care vizează restaurarea sistemelor , datelor și infrastructurilor necesare pentru furnizarea de servicii de afaceri pentru companii , asociații sau entități, în fața unor urgențe grave care afectează activitatea lor regulată. Planul de recuperare în caz de dezastru (DRP) (în italiană, Planul de recuperare în caz de dezastru ) este documentul care stabilește aceste măsuri, incluse în planul mai larg de continuitate a activității (BCP).

Istorie

S-a dezvoltat în a doua jumătate a secolului al XX-lea, când managerii centrelor de calculatoare au început să recunoască dependența organizațiilor lor de sistemele lor de calculatoare. La vremea respectivă, majoritatea sistemelor erau mainframe-uri orientate spre programare în lot care, în multe cazuri, puteau fi întrerupte pentru câteva zile înainte de a se produce daune semnificative organizației.

Ca o conștientizare a potențialelor întreruperi ale afacerii care ar urma în urma unui dezastru IT, industria de recuperare în caz de dezastru s-a dezvoltat pentru a oferi centre de backup de date, Sun Information Systems (care ulterior a devenit Sungard Availability Services) a devenit primul furnizor comercial de puncte fierbinți din SUA, înființată în 1978 în Sri Lanka .

În anii 1980 și 1990, conștientizarea clienților și a industriei a crescut rapid, determinată de apariția sistemelor deschise și a procesării sistemelor în timp real care au sporit dependența organizațiilor de sistemele lor IT. Reglementările care impun continuitatea activității planurilor de recuperare în caz de dezastru pentru organizații din diverse sectoare ale economiei, impuse de autorități și parteneri de afaceri, au crescut cererea și au condus la disponibilitatea serviciilor comerciale de recuperare în caz de dezastru, inclusiv a centrelor de date mobile livrate într-o locație adecvată de recuperare ( de obicei cu camionul).

Această dependență tot mai mare de sistemele IT, precum și conștientizarea crescută a dezastrelor pe scară largă, cum ar fi tsunami , cutremure , inundații și erupții vulcanice , au generat produse și servicii legate de recuperarea datelor și sistemelor după dezastre, variind de la rezoluție înaltă soluții. disponibilitate până la facilități hot-site . O rețea îmbunătățită a însemnat că serviciile IT critice ar putea fi deservite de la distanță, astfel recuperarea la fața locului (la fața locului) a devenit mai puțin importantă.

Creșterea cloud computingului din 2010 continuă această tendință: în zilele noastre, contează și mai puțin în cazul în care serviciile de calcul sunt deservite fizic, atâta timp cât rețeaua în sine este suficient de fiabilă (o problemă separată și mai puțin îngrijorătoare, deoarece rețelele moderne sunt extrem de rezistente prin construcție). „Recuperare ca serviciu” (RaaS - „Recuperare ca serviciu”) este una dintre caracteristicile sau beneficiile de securitate ale Cloud Computing promovate de Cloud Security Alliance . [2]

În domeniul securității cibernetice , Universitatea Carnegie Mellon din Pittsburgh emite certificarea internațională a echipei de intervenție în caz de urgență a computerului și lucrează în colaborare cu Forumul echipelor de răspuns la incidente (FIRST) .

Clasificare

Dezastrele pot fi clasificate în două mari categorii.

  • Primul se referă la dezastre naturale, cum ar fi inundații , uragane , tornade sau cutremure . Deși este imposibil să se prevină un dezastru natural, este posibil să se utilizeze instrumente pentru măsuri de gestionare a riscurilor, cum ar fi evitarea situațiilor de dezastru și elaborarea unui plan de recuperare bun.
  • A doua categorie este dezastrele provocate de om, cum ar fi deversările de materiale periculoase, defecțiunile infrastructurii, bioterorismul , erori de computer dezastruoase sau eșecul implementării modificărilor. În aceste cazuri, supravegherea, testarea și planificarea atenuării sunt de neprețuit.

Pentru ca o organizație să răspundă eficient la o situație de urgență, trebuie analizate următoarele:

  • Nivelurile posibile de dezastru;
  • Criticitatea sistemelor / aplicațiilor.

Pentru o aplicare corectă a planului, sistemele trebuie clasificate conform diferitelor definiții.

Critici

Funcțiile conexe nu pot fi îndeplinite fără a fi înlocuite cu instrumente (mijloace) cu caracteristici identice. Aplicațiile critice nu pot fi înlocuite cu metode manuale. Toleranța în cazul unei întreruperi este foarte mică, prin urmare costul unei întreruperi este foarte mare.

Vitali

Funcțiile sale pot fi executate manual, dar numai pentru o perioadă scurtă de timp. Există o toleranță mai mare la întrerupere decât se așteaptă pentru sistemele critice, astfel încât costul unei întreruperi este mai mic, nu în ultimul rând deoarece aceste caracteristici pot fi reactivate într-o perioadă scurtă de timp (de obicei în termen de cinci zile).

Delicate

Aceste funcții pot fi executate manual, la un cost tolerabil, pe o perioadă lungă de timp. Deși aceste funcții pot fi executate manual, performanța lor este încă dificilă și necesită utilizarea unui număr mai mare de oameni decât se așteaptă în mod normal în condiții normale.

Care nu e critic

Funcțiile sale pot rămâne întrerupte pentru o perioadă lungă de timp, cu un cost redus sau deloc pentru companie, iar efortul de repornire este necesar sau redus la restabilirea sistemului.

Procedurile de aplicare, software-ul de sistem și fișierele care au fost clasificate și documentate drept critice trebuie restaurate cu prioritate. Aplicațiile, software-ul și fișierele clasificate drept critice au o toleranță foarte mică la întreruperi. Criticitatea aplicațiilor, a software-ului de sistem și a datelor trebuie evaluată în funcție de perioada anului în care poate apărea dezastrul. Software-ul poate însemna: sisteme de operare , aplicații , configurații HD, politici de domeniu etc. Fișierul poate însemna: baze de date , documente, surse și configurări, copii de rezervă etc.

Un plan de urgență trebuie să prevadă restabilirea tuturor funcțiilor companiei și nu doar a serviciului central TIC. Pentru definirea DRP, trebuie evaluate cele mai adecvate strategii de restaurare pe: site-uri alternative, metode de rezervă, înlocuirea echipamentului și rolurile și responsabilitățile echipelor. Indisponibilitatea prelungită a serviciului de procesare care duce la o anumită situație de dezastru și, prin urmare, a serviciilor primare, face necesară utilizarea unei strategii alternative de recuperare a site-ului.

Caracteristici

Măsuri de control

Măsurile de control sunt acțiunile sau procesele care pot reduce sau elimina diverse amenințări la adresa organizațiilor. Diferite tipuri de măsuri pot fi incluse în Planul de recuperare în caz de dezastru (DRP). Aici „măsură de control” nu înseamnă „verificare, evaluare, testare”, ci „metodă operațională de menținut sub control”.

Planul de recuperare în caz de dezastru este un subset al unui proces mai larg cunoscut sub numele de Plan de continuitate a activității și include planificarea recuperării aplicațiilor, datelor, hardware-ului, comunicațiilor electronice (cum ar fi rețeaua ) și alte infrastructuri IT. Un plan de continuitate a activității (BCP) include planificarea aspectelor care nu sunt legate de IT, cum ar fi facilitățile, crizele de comunicare și protecția reputației și ar trebui să se refere la Planul de recuperare în caz de dezastru (DRP) pentru recuperarea / continuitatea infrastructurii IT.

Măsurile de control pentru recuperarea dezastrelor IT pot fi clasificate în următoarele trei tipuri:

  • Măsuri preventive - Controale care vizează prevenirea unui eveniment;
  • Măsuri de investigație - Controale care vizează detectarea sau descoperirea evenimentelor nedorite;
  • Măsuri corective - Verifică corectarea sau restaurarea sistemului după un dezastru sau eveniment.

Măsurile bune ale Planului de recuperare în caz de dezastru dictează faptul că aceste trei tipuri de controale sunt documentate și exercitate în mod regulat folosind așa-numitul „Test DR”.

Consecințe și implicații

Impactul acestor situații de urgență este de așa natură încât se estimează că majoritatea întreprinderilor mari cheltuiesc între 2% și 4% din bugetul IT în planificarea gestionării recuperării în caz de dezastru, pentru a evita pierderi mai mari în cazul în care activitatea nu poate continua după pierderea infrastructurilor de date și IT. Dintre companiile care au suferit dezastre cu pierderi mari de date, aproximativ 43% nu și-au reluat niciodată activitatea, 51% au închis în doi ani și doar 6% au reușit să supraviețuiască pe termen lung. [3] Dezastrele informatice cu pierderi uriașe de date în cele mai multe cazuri pot provoca falimentul companiei sau al organizației, motiv pentru care investiția în strategii adecvate de recuperare devine o alegere aproape obligatorie.

Tehnici

În prezent, tehnologia oferă posibilitatea de a crea diverse soluții de continuitate și recuperare în caz de dezastru, până la garanția de facto a unei aprovizionări continue de servicii IT, necesare pentru sisteme (de exemplu, financiare sau de monitorizare) definite ca misiune critică .

În practică, sistemele și datele considerate importante sunt redundante într-un „site secundar” sau „site de recuperare în caz de dezastru” pentru a se asigura că, în caz de dezastru (cutremur, inundație, atac terorist etc.), astfel încât să furnizeze informațiile sisteme inutilizabile ale site-ului primar, este posibilă activarea activităților pe site-ul secundar în cel mai scurt timp și cu cea mai mică pierdere de date posibilă.

În mod clar, cu cât nivelurile de continuitate sunt mai stricte, cu atât costul implementării soluției este mai mare. În special, nivelurile de serviciu sunt de obicei definite de cei doi parametri Obiectiv de timp de recuperare (RTO) și Obiectivul de punct de recuperare (RPO).

Replicare sincronă

Replicarea sincronă garantează oglindirea datelor prezente pe cele două site-uri, deoarece consideră o tranzacție finalizată numai dacă datele au fost scrise atât pe stația locală, cât și pe stația de la distanță. În caz de dezastru la biroul principal, operațiunile de la locul de recuperare în caz de dezastru pot fi repornite foarte repede ( RTO scăzut și RPO practic zero).

Replicarea sincronă este limitată de incapacitatea aplicației de a gestiona impactul întârzierii propagării (deci constrângere fizică, nu tehnologică) asupra performanței. În funcție de sensibilitatea aplicației și de tehnologia de comunicare dintre cele două site-uri, eficiența copierii sincrone începe să scadă la o distanță cuprinsă între 35km și 100km.

Replicare asincronă

Pentru a face față limitei de distanță dintre cele două site-uri impuse de tehnicile sincrone, este adesea folosită tehnica de copiere asincronă. În acest caz, site-ul care se va ocupa de replicare poate fi, de asemenea, situat la distanțe considerabile. În acest fel, este de asemenea posibil să se facă față dezastrelor cu repercusiuni pe scară largă (cum ar fi cutremure puternice) care altfel ar putea afecta ambele situri (dacă acestea sunt în apropiere).

Un alt avantaj al copierii asincrone este posibilitatea de a fi implementat prin software fără a fi necesar să recurgă la tehnologii de stocare sofisticate și costisitoare.

Tehnica mixta

Pentru a asigura disponibilitatea serviciilor chiar și în cazul unui dezastru extins și, în același timp, pentru a minimiza pierderea de date vitale, poate fi utilizată o soluție mixtă: realizarea unei copii sincrone pe un site intermediar relativ aproape de copia primară și o copie asincronă pe un site îndepărtat.

Strategii

Înainte de a selecta o strategie de recuperare în caz de dezastru (DR), un planificator DR se referă mai întâi la planul de continuitate a activității, care ar trebui să indice valorile cheie ale valorilor timpului de recuperare (RTO) și valorilor obiectivului punctului de recuperare (RPO) pentru diferite procese de afaceri (cum ar fi procesul de gestionare salarizare, generarea unei comenzi etc.). Valorile specificate pentru procesele de afaceri sunt apoi mapate la sistemele IT și infrastructura care stau la baza acelor procese. [4]

RTO-urile și RPO-urile incomplete pot deraia rapid un plan de recuperare în caz de dezastru. Fiecare articol din planul DR necesită un punct de recuperare definit și un obiectiv de timp, deoarece eșecul creării acestora poate duce la probleme semnificative care pot extinde impactul dezastrului. [5] Odată ce valorile RTO și RPO au fost mapate la infrastructura IT, planificatorul DR poate determina cea mai potrivită strategie de recuperare pentru fiecare sistem. În cele din urmă, organizația definește bugetul IT și, prin urmare, valorile RTO și RPO trebuie să se încadreze în bugetul disponibil. În timp ce majoritatea managerilor de unități de afaceri ar dori pierderea zero a timpului și a datelor, costul asociat cu acel nivel de protecție ar putea face ca soluțiile de înaltă disponibilitate dorite să nu fie practice. O analiză cost-beneficiu stabilește adesea ce măsuri de recuperare în caz de dezastru sunt implementate.

Unele dintre cele mai comune strategii de protecție a datelor includ:

  • copii de siguranță efectuate pe bandă și trimise în afara regimului la intervale regulate;
  • copii de siguranță făcute pe disc pe site și copiate automat pe discul off-site sau făcute direct pe discul off-site;
  • replicarea datelor într-o locație în afara site-ului, care depășește necesitatea restaurării datelor (prin urmare, numai sistemele trebuie restaurate sau sincronizate), folosind adesea tehnologia SAN ( Storage Area Network );
  • soluții cloud private care replică date de gestionare ( VM-uri , șabloane și discuri) în domeniile de stocare care fac parte din instalarea cloud privat. Aceste date de gestionare sunt configurate ca o reprezentare XML numită Open Virtualization Format (OVF) și pot fi restaurate odată cu apariția unui dezastru;
  • soluții cloud hibride care reproduc atât centre de date on-site cât și off-site. Aceste soluții oferă posibilitatea de a trece imediat la hardware-ul local întotdeauna la fața locului, dar în caz de dezastru fizic, serverele pot fi activate și în centrele de date cloud;
  • utilizarea sistemelor extrem de disponibile care păstrează atât datele cât și sistemul replicat în afara site-ului, permițând accesul continuu la sisteme și date, chiar și după un dezastru (adesea asociat cu stocarea în cloud) [6] .

În multe cazuri, o organizație poate alege să utilizeze un furnizor de servicii de recuperare în caz de dezastru externalizat pentru a furniza un site și sisteme stand-by, mai degrabă decât să utilizeze propriile facilități de la distanță, din nou prin cloud computing .

Pe lângă pregătirea pentru necesitatea recuperării sistemelor, organizațiile pun în aplicare și măsuri de precauție cu scopul de a preveni un dezastru, în primul rând. Acestea pot include:

  • oglinzi locale de sisteme și / sau date și utilizarea tehnologiilor de protecție a discului, cum ar fi RAID ;
  • protecții la supratensiune - pentru a minimiza efectul supratensiunilor de tensiune asupra echipamentelor electronice delicate;
  • utilizarea unei surse de alimentare neîntreruptibile (UPS) și / sau a unui generator de rezervă pentru a menține funcționarea în cazul unei întreruperi a energiei;
  • sisteme de prevenire / atenuare a incendiilor precum alarme și stingătoare;
  • software anti-virus și alte măsuri de securitate.

Elemente conexe

Notă

  1. ^ În limba italiană, recuperarea informaticii este tradusă și prin „recuperare”. Restaurare , utilizată și în informatică, se traduce prin „recuperare” sau „restaurare”.
  2. ^ (RO) SecaaS Categoria 9 // Ghid de implementare BCDR - Cloud Security Alliance în Cloud Security Alliance. Adus pe 7 ianuarie 2018 .
  3. ^ Statistici privind continuitatea activității: unde mitul întâlnește faptul. Continuitate centrală. 24 aprilie 2009. Accesat la 3 august 2012.
  4. ^ Gregory, Peter H., auditor de sisteme de informații certificate CISA ghid de examinare all-in-one , McGraw-Hill, 2010, ISBN 9780071487559 ,OCLC 506020199 .
  5. ^ Cinci greșeli care pot ucide un plan de recuperare în caz de dezastru | Dell , pe content.dell.com , 16 ianuarie 2013. Accesat la 10 ianuarie 2018 (arhivat din original la 16 ianuarie 2013) .
  6. ^ (RO) Cum se utilizează Cloudul ca strategie de recuperare în caz de dezastru , în Inc.com, 2011-06-23T01: 5900-0400. Adus pe 10 ianuarie 2018 .

Legislația italiană privind recuperarea în caz de dezastru și continuitatea activității. Decretul legislativ 7 martie 2005, nr. 82 și modificările ulterioare - Art. 50-bis