Știți vechea glumă: există două tipuri de companii, cele care au fost lovite de un dezastru IT și cele care încă nu își dau seama că au fost lovite de un dezastru IT.

Dar ceea ce au toți în comun este că mai sunt încă multe dezastre. Deci, întreabă-te dacă ești pregătit pentru următorul.

Acest articol, care se bazează pe Curs Pluralsight, Întreținerea și depanarea sistemului Linux, este destinat să vă înceapă să vă gândiți la ce va dura construirea unui protocol eficient.

Ce trebuie să aveți în loc

Totul începe cu plan de continuitate a afacerii (BCP). Acesta este un plan formal menit să definească procedurile pe care o organizație le-ar folosi pentru a asigura supraviețuirea în caz de urgență.

BCP-urile vor include, în general, sub-planuri pentru a asigura siguranța imediată a angajaților și clienților, vor lucra pentru a restabili operațiunile critice desemnate anterior cât mai curând posibil și, în cele din urmă, pentru a restabili operațiunile normale.

În plus, un BCP eficient va include, de asemenea, două sub-planuri specifice operațiunilor IT: protocolul de gestionare a incidentelor și planul de recuperare în caz de dezastru.

recuperare în caz de dezastru plan (DRP) își propune să protejeze infrastructura IT a unei organizații în caz de dezastru. Obiectivele sale principale sunt de a minimiza daunele și de a restabili funcționalitatea cât mai repede posibil.

Motivul pentru care numim acest lucru „plan” este că pur și simplu nu va funcționa fără o pregătire prealabilă serioasă. Protecția infrastructurii, detectarea amenințărilor și protocoalele corective sunt părți critice ale planului.

Un Planul de gestionare a incidentelor (IMP) este menit să abordeze amenințarea specifică a atacurilor cibernetice împotriva infrastructurii IT. Obiectivele sale sunt de a minimiza daunele și de a elimina amenințarea.

După cum puteți spune cu ușurință, vor exista unele suprapuneri între DRP și IMP. Dar obiectivul cheie al recuperării în caz de dezastru este de a vă pune infrastructura pe picioare, în timp ce gestionarea incidentelor este mult mai strâns aliniată cu lumea securității IT.

Pentru restul acestui scurt articol vom analiza ce se întâmplă în crearea planurilor de gestionare a incidentelor și de recuperare în caz de dezastru și cum să ne asigurăm că planul dvs. este solid și că, atunci când este executat, ar trebui să funcționeze efectiv.

Elaborarea unui protocol de gestionare a incidentelor

Deoarece gestionarea incidentelor va fi primul dvs. răspuns la probleme, vom începe acolo.

Primul indiciu că există probleme poate veni de la un utilizator care observă că ceva nu este în regulă cu sistemul. Sau, dacă ați făcut o treabă deosebit de bună configurându-vă infrastructura, aceasta ar putea apărea și sub forma unei alerte automate declanșate de software-ul de monitorizare.

Când va apărea alerta, va fi sarcina tehnicianului sau a administratorului de gardă să decidă cum va fi tratată și cine trebuie să o gestioneze.

Escalarea poate avea loc printr-un apel telefonic direct sau prin e-mail, un bilet trimis printr-un instrument de colaborare precum Jira sau prin utilizarea unui instrument de informare de securitate și de gestionare a evenimentelor (SIEM).

Din nou, însă, cu cât automatizarea este mai inteligentă în proces, cu atât este mai rapidă și mai eficientă.

Oricine va ajunge cu responsabilitatea finală va coordona eforturile pentru a diagnostica și rezolva definitiv problema. În mod ideal, acolo unde este necesar, o astfel de coordonare va include administratori, dezvoltatori și alte părți interesate cheie pentru a vă asigura că aveți toate resursele de care aveți nevoie pentru a rezolva problema.

Când totul s-a terminat, odată ce ați confirmat că problema este rezolvată, veți dori să închideți incidentul evaluând ce a mers greșit și ce a mers bine, cum răspunsul dvs. ar fi putut fi mai bun și cum puteți reface lucrurile pentru a reduce riscul repetării incidentului.

Dar ce legătură au toate acestea cu administrarea IT? Ei bine, managerii IT responsabili trebuie să poată construi reziliența în infrastructura lor.

Aceasta va însemna să petreceți un timp serios ajustându-vă sistemele de monitorizare a software-ului, astfel încât să vă prindă și să vă alerteze la probleme reale, în timp ce emit alerte pentru cât mai puține falsuri posibile.

Și, probabil, va implica, de asemenea, automatizarea inteligentă a sistemelor de înregistrare și detectare a intruziunilor și, în general, a avea o idee bună despre cum ar trebui să arate lucrurile.

Dezvoltarea unui plan de recuperare în caz de dezastru

Planificarea recuperării în caz de dezastru necesită:

  • Definiți exact ce înseamnă recuperare
  • Identificați resursele pe care le va necesita recuperarea
  • Convertiți aceste observații într-un format formal de plan
  • Comunicați planul jucătorilor care într-o zi vor trebui să-l execute

Ce face recuperare Rău? Este momentul în care infrastructura dvs. săracă, afectată, a revenit la forma pe care o avea în momentul dinaintea dezastrului.

Ceea ce veți avea nevoie pentru a vă întoarce la acel punct poate fi definit prin stabilirea unui Obiectivul timpului de recuperare (RTO) și Obiectivul punctului de recuperare (RPO) care se potrivește nevoilor organizației dvs.

A Obiectivul timpului de recuperare reprezintă numărul maxim de minute, ore sau zile în care organizația dvs. ar putea supraviețui unei întreruperi a serviciului IT. Așadar, planul dvs. de recuperare va trebui să includă acel termen limită în protocoalele sale.

Desigur, asta înseamnă că va trebui să ai membri ai echipei disponibili pentru a intra în birou chiar și în micile ore ale nopții, suficient de repede pentru a face diferența.

Dar, de asemenea, înseamnă, de exemplu, că dacă RTO-ul dvs. este de șase ore, dar restaurarea datelor critice din copiile de rezervă ar dura cel puțin opt ore doar pentru a gestiona transferul, atunci va trebui să vă regândiți aceste numere înainte de a vă conecta la plan .

A Obiectivul punctului de recuperare este cantitatea de date despre tranzacții pe care organizația dvs. și-ar putea permite să le piardă în timpul unei întreruperi și să supraviețuiască.

Pentru a ilustra, un site web de comerț electronic care procesează în mod normal 25 de tranzacții în fiecare minut și-ar putea permite să emită scuze și rambursări în valoare de 30 de minute clienților supărați care se întreabă de ce au fost facturate cardurile de credit, dar nu au fost livrate seturile de trenuri electrice. Cu toate acestea, rambursarea în valoare de peste 30 de minute ar putea să vă epuizeze rezervele financiare până la punctul în care nu mai sunteți viabil.

În orice caz, calcularea RTO-urilor și RPO-urilor exacte și fiabile este modul în care stabiliți limitele în care planul dvs. de recuperare va trebui să funcționeze. Sau, cu alte cuvinte, veți fi definit ce înseamnă recuperare.

Acum ce zici de resurse? Prin aceasta mă refer la copiile de siguranță ale datelor și, atunci când este necesar, la echipamentul fizic de care veți avea nevoie pentru a vă pune aplicația pe picioare.

Pentru ca acest lucru să funcționeze, va trebui să decideți asupra unui sistem de copiere de rezervă a infrastructurii. Indiferent dacă alegeți să mergeți cu tipuri incrementale sau diferențiale, la fața locului sau în afara site-ului și cu tipuri de suport unic sau multiple, va trebui să identificați exact cum va merge recuperarea și dacă va satisface sau nu RTO și RPO limite.

Bineînțeles că nu se pot întâmpla lucruri cu adevărat rele care să facă aceste planuri cu totul inutile. Ce se întâmplă dacă facilitatea serverului dvs. local arde? Ce se întâmplă dacă este pierdut de un fel de răsturnare politică sau de întrerupere generalizată a puterii?

Chiar dacă ați menținut în mod conștiincios copiile de siguranță actualizate ale datelor în afara site-ului, la ce vă vor ajuta dacă hardware-ul dvs. nu mai există?

Gândirea la toate acele orori poate face ca pregătirea unui protocol de backup bazat pe cloud folosind platforme precum AWS și Azure să pară foarte atractivă. Nori mari publici au resursele necesare pentru a-și distribui infrastructura suficient de larg încât este practic imposibil ca întregul lucru să coboare vreodată.

Așadar, puteți, de exemplu, să mențineți un magazin de date replicat în mod fiabil pe o platformă publică de cloud care reflectă implementarea dvs. principală. De asemenea, ați putea proiecta un șablon de infrastructură care ar putea fi încărcat cu datele dvs. de rezervă și apoi lansat la cerere pentru a prelua în caz de întrerupere. Deoarece nimic nu rămâne în funcțiune până când nu este de fapt necesar, poate dura câteva minute bune pentru a-l aduce la viteză.

Un design cald de recuperare în așteptare ar putea menține datele dvs. rulând 24/7 pe un număr minim de servere virtuale. În caz de urgență, puteți apăsa comutatorul și scalarea automată a platformei va declanșa toate cazurile de care aveți nevoie.

Puteți seta scalarea pentru a începe atunci când este declanșată de o alertă din sistemul dvs. principal. Norul public prezintă posibilități infinite, dar toate necesită planificare și pregătire.

Un dezastru solid plan de recuperare trebuie comunicat în mod eficient cu mult înainte de momentul crizei. Practic vorbind, asta înseamnă că totul va fi scris, tipărit și distribuit fiecăruia dintre jucătorii cheie care vor realiza planul.

Asta nu înseamnă că se termină acolo: acei jucători vor fi desigur că au citit lucrul și, în mod ideal, se vor angaja în simulări realiste până când vor avea încredere că pot face să funcționeze sub presiune.

Ce se întâmplă în această carte?

  • O enumerare a tuturor lucrurilor care ar putea merge greșit și ar putea să doboare sistemul
  • Un inventar al exact ceea ce ați rulat în camera serverului și ce ar fi necesar pentru a-l înlocui
  • Informațiile de care veți avea nevoie pentru a accesa și restabili datele copiate
  • O listă de contact actualizată a persoanelor care vor fi responsabile pentru fiecare aspect al planului
  • Secvența exactă a sarcinilor și evenimentelor care vor alcătui recuperarea

Sunt multe detalii. Dar este abia o scădere în găleată, în comparație cu cantitatea totală de pregătire și munca grea și veche care creează un plan de recuperare din lumea reală.

Dar, deocamdată, soluția cheie de la acest modul este pur și simplu să țineți cont de toate acestea. De ce? Deoarece data viitoare când vă așezați pentru a configura un pachet de monitorizare sau un cadru de administrare, vă veți gândi la protocoale de gestionare a incidentelor și planuri de recuperare în caz de dezastru și vă veți întreba cum ar trebui să le includeți în configurația dvs.

Există mult mai multă bunătate administrativă sub formă de cărți, cursuri și articole disponibile la adresa mea bootstrap-it.com.