IT atkūrimo plano pratybos: nuo atsarginės kopijos iki veikiančios paslaugos

Atsarginės kopijos sukūrimo pranešimas dar neparodo, ar organizacija gali atkurti paslaugą. Atkūrimui gali trūkti tapatybės sistemos, šifravimo rakto, veikiančio DNS įrašo, tinkamos programos versijos arba žmogaus, kuris patvirtintų duomenų teisingumą. Pratybų tikslas – patikrinti visą kelią iki darbuotojo atliekamos operacijos ir užregistruoti, kur jis nutrūksta.

Šis modelis padeda parengti vienos paslaugos pratybų užduotį, išmatuoti atkūrimo laiką ir priimti rezultatą. Pavyzdžiai yra hipotetiniai: jų valandos, duomenų kiekiai ir pasirinktos ribos nėra įstatymo reikalavimai. Prieš bandymą juos nustato paslaugos savininkas pagal veiklos poreikį ir tikėtiną žalą.

Atskirti veiklos tęstinumą ir techninį atkūrimą

Veiklos tęstinumo planas atsako, kaip organizacija vykdys svarbiausias funkcijas sutrikimo metu. IT atkūrimo planas nustato, kaip vėl veiks konkrečios technologinės paslaugos. Kol atkuriama užsakymų sistema, darbuotojai gali registruoti skubius užsakymus kontroliuojamame laikino darbo sąraše. Vėliau šį sąrašą reikia suderinti su atkurta sistema, kad užsakymai nebūtų prarasti ar įvykdyti du kartus.

Todėl pratybų ribas derinkite su veiklos tęstinumo planu. Techninė komanda negali viena nuspręsti, kad keturių valandų prastova priimtina, jeigu per tą laiką nutrūksta kritinė klientų paslauga. Veiklos vadovas savo ruožtu negali reikalauti penkių minučių atkūrimo, neįvertinęs turimų kopijų, priklausomybių ir išteklių.

BDAR 32 straipsnyje tarp taikytinų saugumo aspektų nurodytas gebėjimas laiku atkurti prieigą prie asmens duomenų ir naudojimąsi jais po fizinio ar techninio incidento, taip pat reguliariai tikrinti priemonių veiksmingumą. Straipsnis visoms organizacijoms nenustato vienodos pratybų datos ar vieno atsarginių kopijų modelio. BDAR 32 straipsnis.

Užpildytas vienos pratybos scenarijus

Tarkime, bendrovė tikrina užsakymų valdymo sistemą. Scenarijus: pagrindinė virtuali infrastruktūra neprieinama, o jos administravimo paskyromis kol kas nepasitikima. Atkūrimas vykdomas izoliuotoje aplinkoje, neišsiunčiant tikrų laiškų klientams ir neinicijuojant mokėjimų. Pratybų vadovas gali bet kada stabdyti bandymą, jeigu paveikiama įprasta veikla.

RTO pradžią apibrėžkite iš anksto. Jei laiką skaičiuosite tik nuo jau paruoštos kopijos importavimo, praleisite incidento patvirtinimą, sprendimo laukimą ir infrastruktūros parengimą. RPO taip pat matuojamas pagal realiai atkurtos informacijos laiką, o ne pagal atsarginių kopijų tvarkaraštyje numatytą dažnumą. Sėkmingai paleista vakarykštė kopija gali neatitikti vienos valandos tikslo.

Priklausomybių eilė svarbesnė už serverių sąrašą

Pirmiausia nustatykite, ko reikia administratoriui patekti į atkūrimo aplinką. Ar prisijungimas priklauso nuo neveikiančio katalogo? Kur laikomi avariniai prisijungimo duomenys? Ar jiems pasiekti nereikia tos pačios sistemos, kurią ketinama atkurti? Šiuos klausimus išspręskite prieš bandymą, tačiau pačiose pratybose patikrinkite realų prieigos gavimą.

Toliau surašykite tinklą, vardų paslaugas, laiką, sertifikatus, raktus, duomenų bazę, programą ir išorines sąsajas. Informacinių sistemų žemėlapis padeda pamatyti priklausomybę, kurios nėra vieno serverio inventoriuje. Pavyzdžiui, programa paleidžiama, bet vartotojas negali prisijungti, nes autentifikavimo paslaugos grįžtamojo adreso nustatymas liko susietas su neveikiančia aplinka.

Pratybų veiksmų seka turi turėti vykdytoją ir patikrinamą rezultatą. „Atkurti infrastruktūrą“ yra per platus žingsnis. „Sukurti izoliuotą tinklą, uždrausti išorinį laiškų siuntimą ir patikrinti, kad bandymo serveris nepasiekia mokėjimo sąsajos“ jau leidžia spręsti, ar galima pereiti prie duomenų atkūrimo.

Kopijos pasirinkimas po galimo saugumo incidento

Jei scenarijus susijęs su išpirkos reikalaujančia programa ar svetima administratoriaus prieiga, naujausia kopija nebūtinai tinkamiausia. Joje gali būti pažeista konfigūracija, neleistina paskyra arba kenkėjiškas komponentas. Pratybose numatykite, kas vertina kopijos tinkamumą, kokie faktai leidžia ją pasirinkti ir ką dar reikia patikrinti prieš prijungiant paslaugą.

Atkūrimo darbas nepakeičia incidento tyrimo. Išsaugokite reikalingus įrodymus ir atskirkite tyrimui skirtą paveiktą aplinką nuo švarios atkūrimo aplinkos. Asmens duomenų pažeidimo vertinimą ir galimus pranešimus vykdykite pagal pažeidimų valdymo procedūrą; vien prieinamumo atkūrimas neatsako, ar duomenys buvo atskleisti.

Šifruotai kopijai būtinas veikiantis iššifravimo kelias. Patikrinkite rakto pasiekiamumą, teises ir suderinamumą su pasirinkta kopija. Asmens duomenų šifravimo planas turi apimti atkūrimo situaciją: saugiai saugomas, tačiau incidento metu niekam nepasiekiamas raktas gali padaryti kopiją praktiškai nenaudojamą.

Kas registruojama pratybų metu

Vienas stebėtojas fiksuoja laiką, sprendimus ir kliūtis. Pavyzdžiui: 09.00 paskelbtas sutrikimas; 09.18 patvirtintas atkūrimas; 09.42 parengta izoliuota aplinka; 10.35 importuoti duomenys; 11.10 atkurtas prisijungimas; 11.28 veiklos savininkas užbaigė kontrolines operacijas. Rezultatas – dvi valandos ir dvidešimt aštuonios minutės pagal sutartą pradžią.

Kiekvienai kliūčiai užrašykite poveikį. Jei septyniolika minučių ieškota tinkamo rakto, to neužtenka pažymėti „smulki problema“. Reikia nustatyti, ar raktas buvo neteisingai aprašytas, ar neprieinamas pavaduojančiam darbuotojui, ar priklausė nuo vieno žmogaus atminties. Nuo priežasties priklauso pataisa.

Pratybų protokole nelaikykite slaptažodžių, raktų ar pilnų klientų išrašų. Naudokite užduoties identifikatorius ir nuorodas į tinkamai apsaugotus įrodymus. Techninių įvykių laikai turi būti palyginami; saugumo žurnalų politika padeda susitarti dėl šaltinių, prieigos ir saugojimo, kad vėliau būtų galima atkurti tikrą įvykių seką.

Veiklos priėmimas ir duomenų suderinimas

Paslaugos veikimą patvirtina konkretūs veiksmai. Pavyzdyje darbuotojas randa kontrolinį užsakymą, mato jo eilutes, pakeičia būseną, patikrina suteiktas teises ir įsitikina, kad išorinis pranešimas bandymo aplinkoje sulaikytas. Administratorius patvirtina infrastruktūros būklę, o veiklos savininkas – užsakymo duomenų ir proceso tinkamumą.

Atskirai palyginkite atkurtą laikotarpį su šaltinio įrodymais. Jei paskutinė patvirtinta operacija buvo 08.47, o atkurtas rinkinys baigiasi 08.05, praradimo langas turi būti apskaičiuotas ir įvertintas pagal scenarijų. Kopijos failo sukūrimo laikas nėra pakankamas įrodymas, kad jame yra visi iki to laiko įvykę sandoriai.

Laikinai rankiniu būdu registruoti užsakymai perkeliami per sutartą suderinimo procedūrą. Kiekvienas turi vieną atsakingą tikrintoją ir apsaugą nuo dubliavimo. Negalima vien paleisti automatinį pakartotinį siuntimą, jei tai gali dar kartą išrašyti sąskaitą, pranešti klientui ar rezervuoti prekę. Pratybų scenarijuje bent vieną tokį prieštaravimą verta pateikti sąmoningai.

Grįžimas į įprastą aplinką yra atskiras etapas

Pratybų pabaigoje numatykite, kas atsitinka atkurtoms kopijoms ir laikinoms teisėms. Bandymo aplinka neturi likti neprižiūrima alternatyvi klientų duomenų saugykla. Uždarymo žingsnyje patvirtinkite duomenų pašalinimą pagal nustatytą tvarką, laikinų paskyrų išjungimą ir įrodymų perkėlimą į pratybų bylą.

Tikro incidento atveju grįžimas į pagrindinę aplinką reikalauja duomenų suderinimo, pakeitimų lango ir atsitraukimo sąlygos. Nuspręskite, kuri sistema tuo metu laikoma pagrindine, kas gali joje rašyti ir kaip sustabdomas lygiagretus nesuderinamų versijų kūrimas. Šį sprendimą dokumentuokite dar plane, o ne pirmą kartą aptarkite atkūrimo naktį.

NIST 2010 metų SP 800-34 Rev. 1 pateikia sistemų atkūrimo planavimo, poveikio analizės ir pratybų struktūrą. Tai metodinis JAV federalinių sistemų šaltinis, kurio planavimo logiką galima pritaikyti; jis savaime nenustato Lietuvos organizacijos teisinių pareigų. Konkrečius sektorinius reikalavimus vertinkite atskirai. NIST atkūrimo planavimo vadovas.

Pataisų uždarymas ir kitos pratybos

Baigiamajame įraše nurodykite pasiektą laiką, atkurtų duomenų laikotarpį, nepavykusias kontrolines operacijas ir likusias rizikas. Užpildytas pataisos pavyzdys: „Avarinio prisijungimo instrukcija neprieinama neveikiant katalogui; infrastruktūros vadovas iki sutartos datos pateikia nepriklausomą saugią prieigą; pavaduojantis administratorius pakartoja prisijungimo bandymą.“ Pataisa uždaroma gavus pakartotinio bandymo įrodymą.

Kitas bandymas turi spręsti neišbandytą ar pasikeitusią riziką: nebuvusį pagrindinį administratorių, kitą kopijų saugyklą, dalinį duomenų sugadinimą arba tiekėjo neprieinamumą. Pratybų dažnumą siekite su paslaugos svarba ir pakeitimais. Dokumente užrašytas kalendorius naudingas tik tada, kai faktinis bandymas parodo, kad paslauga atkuriama per organizacijos priimtą laiką.

Jeigu paslaugą atkuria tiekėjas, pratybų užduotyje atskirkite jo pažadą nuo organizacijos patikrinto rezultato. Tiekėjas gali patvirtinti, kad duomenų bazė importuota, tačiau kliento integracija ar prisijungimas vis tiek neveikia. Susitarkite, kas pateikia laikų žurnalą, kas atlieka vartotojo operaciją ir kokie įrodymai perduodami užsakovui. Jeigu tiekėjas neleidžia išbandyti viso atkūrimo, dokumentuokite šią patikros ribą ir pasirinkite galimą dalinį bandymą. Ataskaitoje aiškiai įvardykite, kuri dalis patikrinta tiesiogiai, kuri paremta tiekėjo medžiaga ir kurios veiksmingumas dar nepatvirtintas. Tai leidžia vadovui priimti sprendimą remiantis tikra patikros apimtimi.