Veiklos tęstinumas: įrodykite atkūrimo kelią

Atkūrimo planas tampa patikimas, kai komanda gali parodyti, kaip kritinė paslauga bus atkurta, kokia tvarka ir kokiais ištekliais. Atsarginė kopija yra viena šio plano sudedamųjų dalių; ji neužtikrina viso atkūrimo gebėjimo.

Technologijų vadovui (CTO) praktinis klausimas yra tai, ar atkūrimas vis dar veikia, kai įprastos veiklos prielaidos nepasiteisina. Ar procedūrą gali atlikti kitas inžinierius? Ar komanda gali gauti prisijungimo duomenis be gamybinės tapatybių paslaugos? Ar verslo naudotojai gali užbaigti operaciją po infrastruktūros atkūrimo?

Tęstinumą traktuokite kaip inžinerinį gebėjimą: apibrėžkite priimtinus rezultatus, nustatykite priklausomybes, sukurkite atkūrimo procedūras, išbandykite jas pratybose ir išsaugokite įrodymus apie tai, kas įvyko. Rezultatas yra įrodytas atkūrimo kelias, kurio apribojimai suprantami, o trūkumai priskirti taisyti.

Nustatykite įpareigojimą ir veiklos ribą

NIS2 direktyvos 21 straipsnis tarp kibernetinio saugumo rizikos valdymo priemonių nurodo veiklos tęstinumą, pavyzdžiui, atsarginių kopijų valdymą ir atkūrimą po nelaimių, bei krizių valdymą. Jame taip pat reglamentuojamos politikos ir procedūros, skirtos šių priemonių veiksmingumui vertinti. 20 straipsnis apima vadovybės patvirtinimą ir priežiūrą.

NIS2 yra direktyva, įgyvendinama nacionaline teise. Jos taikymas priklauso nuo sektoriaus, dydžio, paslaugos ir įtraukimo taisyklių; konkrečius įpareigojimus nustato taikomi nacionaliniai ir sektoriniai reikalavimai. Nelaikykite bendro tęstinumo šablono išsamiu teisiniu vertinimu.

Veiklos požiūriu atskirkite keturias susijusias veiklas:

• Veiklos tęstinumas: svarbių verslo funkcijų palaikymas, galbūt sumažintu pajėgumu.
• Atsarginių kopijų valdymas: apsaugotų, atkuriamų duomenų ir būtinos konfigūracijos kopijų palaikymas.
• Atkūrimas po nelaimių: techninių sistemų atkūrimas ir jų palaikomos paslaugos patikrinimas.
• Krizių valdymas: sprendimų, išteklių, komunikacijos ir eskalavimo koordinavimas.

Paslauga gali tęstis rankiniu darbu, kol jos sistemos lieka nepasiekiamos. Ir atvirkščiai, serveriai gali veikti, o verslo funkcija lieka netinkama naudoti. Apibrėžkite ir techninius, ir verslo priėmimo kriterijus.

Pradėkite nuo vienos kritinės paslaugos ir nurodytos scenarijaus ribos. Atkūrimas po atsitiktinio ištrynimo skiriasi nuo atkūrimo po administratoriaus prisijungimo duomenų kompromitavimo. Užfiksuokite, kurias situacijas planas apima, kurioms reikia atskirų procedūrų ir kas prisiima bet kokią likusią spragą.

Dirbkite atgaline kryptimi nuo verslo paslaugos

Poveikio verslui analizė (BIA) nustato, ką reiškia sutrikimas, prieš inžinerijai pasirenkant atkūrimo projektą. Pakalbinkite paslaugos atsakingą asmenį ir žmones, kurie iš tikrųjų atlieka darbą. Paklauskite, kas nutinka po valandos, darbo dienos ir ilgesnio pertrūkio: praleistos operacijos, nesaugi veikla, sutartinių įsipareigojimų nevykdymas, žala klientams ar besikaupiantis neatliktų darbų sąrašas.

Dokumentuokite minimalų priimtiną veiklos lygį. Klientų portalui gali reikėti užsakymų pateikimo ir prieigos prie užsakymo būsenos, kol bus atkurtos ataskaitų funkcijos. Gamybinei veiklai gali reikėti planavimo ir saugos informacijos anksčiau nei administracinių funkcijų.

Projektą formuoja trys rodikliai:

Jie susiję, bet skirtingi. RTO turėtų palikti laiko toleruotino sutrikimo ribose verslo patikrinimui ir veiklos atkūrimui. RPO apibūdina priimtiną duomenų praradimą; tai nėra dar vienas prastovos tikslas.

Aiškiai susitarkite, nuo kada skaičiuojamas laikas. Jei viena komanda RTO matuoja nuo incidento paskelbimo, o kita nuo paslaugos pertrūkio, pateikiami rezultatai bus klaidinantys. Aptikimo ir aktyvavimo laiką fiksuokite atskirai, net jei suderintas atkūrimo rodiklis pradedamas skaičiuoti vėliau.

Verslo atsakingi asmenys patvirtina reikalaujamą rezultatą; inžinerija parodo, ar projektas gali jį pasiekti. Kai dėl išlaidų, personalo ar tiekėjų apribojimų tikslas tampa nerealus, pateikite galimybes: investuoti į spartesnį atkūrimą, įvesti sumažintą veiklą, pakeisti tikslą gavus atsakingo asmens patvirtinimą arba prisiimti riziką. Tyliai nepakeiskite verslo reikalavimo tuo, ką atsitiktinai pasiekia dabartinė atsarginių kopijų sistema.

Nubrėžkite priklausomybes, galinčias sutrukdyti atkūrimui

Klientų portalo atveju, atkūrus duomenų bazę, paslauga vis tiek gali likti netinkama naudoti, jei nepasiekiami tapatybių, DNS ar diegimo prisijungimo duomenys. Priklausomybių žemėlapį kurkite nuo verslo operacijos į išorę, o ne nuo serverių inventoriaus į vidų.

Įtraukite programas ir duomenų bazes, taip pat tinklus, tapatybių teikėjus, sertifikatų paslaugas, paslaptis, šifravimo raktus, diegimo artefaktus, stebėseną, išorines integracijas, žmones ir tiekėjų pagalbą. Užfiksuokite, kur kiekviena priklausomybė eksploatuojama, kas gali ją atkurti ir kas turi egzistuoti prieš pradedant atkūrimą.

Ypač ieškokite ciklinių priklausomybių. Slaptažodžių saugykla gali reikalauti tapatybių platformos, o tai platformai atkurti reikia saugykloje laikomų prisijungimo duomenų. Atkūrimo vadovas gali būti bendradarbiavimo paslaugoje, kuri pati yra nepasiekiama. Šias kilpas išspręskite kontroliuojama avarine prieiga ir nepriklausomai pasiekiamomis instrukcijomis; išbandykite abu sprendimus, o ne darykite prielaidą, kad jie veikia.

Atkūrimo tvarka yra priklausomybių grafas, o nebūtinai universali seka: tinklas, duomenų bazė, programa. Kai kurias užduotis galima vykdyti lygiagrečiai. Kitos turi kontrolinius taškus, pavyzdžiui, švarios administravimo aplinkos patvirtinimą prieš atkurtiems darbo krūviams ją pasiekiant.

Tiekėjų atveju atskirkite pažadus nuo veiklos susitarimų. Nustatykite pagalbos kontaktus, eskalavimo kelius, kliento pusės atsakomybes, eksporto galimybes, atkūrimo įsipareigojimus ir kaip gausite naujienas sutrikimo metu. Tiekėjo atkūrimo tikslas automatiškai nenustato jūsų visos paslaugos tikslo. Sumodeliuokite, kas nutinka, jei jis nepasiekiamas ilgiau nei tikėtasi.

Projektuokite atsargines kopijas atkūrimui, o ne užduoties įvykdymui

Sėkminga atsarginės kopijos užduotis rodo, kad procesas baigtas. Ji neįrodo, kad buvo užfiksuoti tinkami duomenys, kad raktai tebėra prieinami ar kad programa gali naudoti atkurtą būseną.

Kiekvienai kritinei sistemai sudarykite atsarginių kopijų specifikaciją:

• Įtraukti duomenų rinkiniai, konfigūracija, artefaktai ir aiškiai nurodytos išimtys.
• Atsarginių kopijų metodas, tvarkaraštis, tikėtinas atkūrimo taško amžius ir saugojimas.
• Saugojimo vietos ir priklausomybės nuo paskyrų, regionų ar patalpų.
• Administracinė prieiga, šifravimas, raktų atkūrimas ir ištrynimo kontrolės.
• Stebėsenos atsakomybės, nesėkmių eskalavimas ir atkūrimo instrukcijos.
• Atkūrimo testo apimtis, priėmimo kriterijai ir išsaugoti rezultatai.

Dažnai naudojamas 3-2-1 metodas, kartais papildomas neprisijungusia ar nekeičiama kopija ir patikrinimu, yra praktinė projektavimo euristika, o ne universali NIS2 formulė. Įvertinkite, ar kopijos iš tikrųjų turi skirtingus gedimų būdus. Kelios kopijos, valdomos per vieną kompromituotą administratoriaus paskyrą, gali suteikti mažai apsaugos nuo tyčinio ištrynimo.

Neprisijungusios ir nekeičiamos kopijos taip pat skiriasi. Neprisijungusi saugykla yra atjungta; nekeičiama saugykla apibrėžtomis kontrolėmis riboja keitimą ar ištrynimą. Išnagrinėkite, kas gali pakeisti saugojimo nustatymus, sunaikinti raktus, uždaryti paskyrą ar pakeisti prieigos politikas. Nelaikykite vien etiketės apsaugos įrodymu.

Pritaikykite mechanizmą duomenims

Operacijų duomenų bazei vien momentinių kopijų dažnumo gali nepakakti RPO pasiekti. Gali prireikti žurnalų fiksavimo, programos požiūriu nuoseklių atsarginių kopijų ir atkūrimo į konkretų laiko momentą. Patikrinkite, ar per kelias sistemas paskirstytas operacijas galima atkurti į nuoseklią būseną.

Replikacija gali sutrumpinti pertrūkį, tačiau ji gali replikuoti ir sugadintus duomenis ar kenkėjiškus pakeitimus. Ji nepakeičia išsaugotų atkūrimo taškų. Panašiai SaaS prieinamumo įsipareigojimas gali neapimti atkūrimo po kliento atlikto ištrynimo ar paskyros kompromitavimo; patikrinkite faktinę atkūrimo ir eksporto tvarką.

Įtraukite šifravimo raktus ir konfigūraciją, reikalingą atkurtiems duomenims interpretuoti. Kai tinkama, atkūrimo medžiagą saugokite atskirai, su kontroliuojama prieiga ir išbandytu gavimo keliu. Šifravimas ir raktų valdymas turėtų apimti ne tik įprastą veiklą, bet ir atkūrimą.

Saugojimas turi atsižvelgti į pavėluotą aptikimą: naujausioje kopijoje problema jau gali būti. Pasirinkus senesnį švarų tašką, duomenų praradimas gali viršyti RPO. Dokumentuokite šį kompromisą ir reikalingą suderinimo darbą, o ne vadinkite bet kokį užbaigtą atkūrimą sėkme.

Rašykite vadovus, kuriuos gali įvykdyti kitas inžinierius

Naudingame atkūrimo vadove nurodomos išankstinės sąlygos, veiksmai, tikėtini rezultatai, nesėkmės šakos ir priėmimo patikrinimai. Jis turėtų būti pakankamai konkretus, kad įgaliotas pavaduotojas galėtų juo vadovautis, spaudimo sąlygomis neatkurinėdamas architektūros.

Pradėkite nuo aktyvavimo sąlygų ir saugos ribų. Kas leidžia atkūrimą? Kur jis bus vykdomas? Kurie tinklai turi likti izoliuoti? Kokie gamybiniai pakeitimai draudžiami pratybų metu? Jei įtariama kenkėjiška veikla, išsaugokite susijusius įrodymus ir koordinuokite suvaldymą prieš vėl prijungdami atkurtas sistemas.

Kiekviename žingsnyje turėtų būti:

Aplinkai specifinėms komandoms nurodykite kontroliuojamas procedūras. Paslapčių nelaikykite pačiame vadove, bet paaiškinkite, kaip įgalioti reaguojantys asmenys jas gauna sutrikimo metu.

Paruošimą, perdavimą, atkūrimą, konfigūravimą, patikrinimą ir perdavimą naudoti matuokite atskirai. Greitas duomenų atkūrimas vis tiek gali neatitikti RTO, nes infrastruktūros parengimas ar verslo patikrinimai trunka ilgiau nei tikėtasi.

Atkūrimui po kibernetinės atakos perkūrimas iš patikimų artefaktų gali būti saugesnis nei visų mašinų atkūrimas. Patikrinkite privilegijuotas paskyras, kai tinkama, pakeiskite atskleistus prisijungimo duomenis ir prieš išleisdami patikrinkite, ar neliko įsitvirtinimo mechanizmų. Šie sprendimai turėtų būti aiškios procedūros šakos.

Užbaikite paslaugos lygio patikrinimais: autentifikavimu, reprezentatyvia operacija, integracijų elgsena, stebėsena ir suderinimu. Techninis vadovas užfiksuoja užbaigimą; verslo atsakingas asmuo priima suderintą veiklos lygį. Įtraukite kontroliuojamą grįžimą iš laikinų sprendimų, su atsakomybe už eilėje laukiančio darbo ir dubliuotų įrašų sutvarkymą.

Palaikykite verslo veiklą, kol vyksta atkūrimas

Alternatyviai veiklai reikia savų pajėgumų ir saugos ribų. „Naudokite skaičiuoklę“ nėra planas, nebent kas nors nustatė prieigą, laukus, leidimus, saugojimo apsaugą ir vėlesnį suderinimą.

Sutrikus užsakymų paslaugai, laikinas procesas galėtų priimti ribotos klasės užsakymus per patvirtintą kanalą, išduoti unikalius numerius ir atidėti mokėjimų apdorojimą. Užfiksuokite, kas tvirtina užsakymus, kaip išvengiama dublikatų, kaip apsaugoma klientų informacija ir kada laikinas sprendimas turi būti nutrauktas.

Įvertinkite, ar sumažinta veikla iš tikrųjų suteikia pakankamai laiko. Rankinis apdorojimas gali atlaikyti nedidelį kiekį, bet žlugti esant įprastam darbo krūviui. Išbandykite reprezentatyvią paklausą ir pagal suderintus verslo kriterijus nustatykite prioritetinius klientus ar operacijas.

Taip pat planuokite žmones ir darbo vietas. Atkūrimas gali nepavykti, nes vienintelis kvalifikuotas operatorius nepasiekiamas, alternatyvioje vietoje nėra ryšio arba reaguojantys asmenys negali saugiai dirbti per užsitęsusį incidentą. Paskirkite pavaduotojus, perdavimo reikalavimus ir personalo tvarką, o ne pasikliaukite individualia ištverme.

Suteikite krizių komandai aiškias sprendimų teises

Atskirkite incidento koordinavimą nuo praktinio atkūrimo, kad techninis vadovas tuo pačiu metu neatkurinėtų sistemų, netvirtintų išlaidų ir neatsakinėtų kiekvienam suinteresuotajam asmeniui.

Paskirkite pagrindinius ir pavaduojančius vaidmenis krizių koordinavimui, techniniam atkūrimui, verslo veiklai, vadovybės sprendimams, komunikacijai ir teisiniam ar atitikties vertinimui. Užfiksuokite aktyvavimo ribas, kontaktų būdus, sprendimų įgaliojimus ir eskalavimo sąlygas. Praktiniai išankstiniai leidimai gali apimti skubios pagalbos pirkimus, alternatyvią infrastruktūrą ir nesaugių paslaugų sustabdymą, neviršijant vadovybės patvirtintų ribų.

Parenkite komunikacijos šablonus darbuotojams, klientams, tiekėjams ir institucijoms. Kiekviename turėtų būti atskirti žinomi faktai nuo įverčių, aprašytos paveiktos paslaugos, pateiktos dabartinės instrukcijos ir nurodytas kito atnaujinimo laikas. Išbandykite alternatyvų kanalą, kai įmonės el. paštas ir pokalbių sistemos nepasiekiami. Užtikrinkite, kad reaguojantys asmenys galėtų saugiai pasiekti kontaktinę informaciją už įprastų sistemų ribų.

Pranešimų vertinimas turi vykti kartu su atkūrimu. Reikšmingiems incidentams taikymo srityje NIS2 direktyvos 23 straipsnis nustato ankstyvąjį įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas ir paprastai galutinę ataskaitą per vieną mėnesį nuo pranešimo. Patikrinkite taikomas nacionalines ir sektorines taisykles, ribas, gavėjus ir procedūras. Ne apie kiekvieną sutrikimą automatiškai reikia pranešti.

Paskirkite asmenį, kuris sektų sužinojimo laiką ir sprendimus dėl pranešimų; nelaukite visiško atkūrimo prieš vertindami įpareigojimus. Kai susiję asmens duomenys, atskirai įvertinkite BDAR pranešimo apie pažeidimus reikalavimus pagal organizacijos vaidmenį ir pavojų asmenims.

Skirtingus teiginius tikrinkite skirtingais testais

Pratybų tipą rinkitės pagal tai, ką reikia įrodyti:

Dažnumą nustatykite kaip praktinį, rizika grindžiamą sprendimą, atsižvelgdami į taikomus reikalavimus, paslaugos kritiškumą, pokyčių tempą ir ankstesnes išvadas. Neprisiimkite, kad universalus ketvirtinis ar metinis intervalas atitinka kiekvieną įpareigojimą. Inicijuokite papildomus testus po reikšmingų architektūros, tiekėjų, prieigos ar personalo pokyčių.

Prieš testuodami patvirtinkite scenarijų, tikslus, saugos kontroles, dalyvius, sustabdymo sąlygas ir sėkmės kriterijus. Kai įmanoma, rinkitės izoliuotas aplinkas. Neleiskite testiniams pranešimams, mokėjimams ar klientų informavimui patekti į realią veiklą.

Naudokite realistiškus apribojimus: nesantį specialistą, nepasiekiamas tapatybių paslaugas, senesnę švarią atsarginę kopiją ar vėluojančią tiekėjo pagalbą. Tyliai neteikite prisijungimo duomenų ir infrastruktūros, kurių incidento metu nebūtų.

Užfiksuokite scenarijų, dalyvius, pradžios ir pabaigos laiką, žingsnių trukmes, faktinius rezultatus ir nukrypimus. Užfiksuokite suteiktą pagalbą ir sutrumpinimus. Jei testas neapėmė DNS pakeitimų, gamybinės apimties duomenų ar išorinių integracijų, tai nurodykite. Apibrėžtas rezultatas naudingesnis nei perdėtas „išlaikyta“.

Išnagrinėtas pavyzdys: klientų portalo atkūrimo kelio įrodymas

Panagrinėkime iliustracinį portalą, palaikantį užsakymų pateikimą. Toliau pateikti tikslai ir trukmės yra prielaidos, o ne pramonės etalonai ar produkto pažadai.

Verslas susitaria dėl keturių valandų RTO ir 15 minučių RPO. Atkūrimas reiškia, kad klientai gali autentifikuotis, pateikti užsakymą ir matyti jo būseną; ataskaitos gali būti atkurtos vėliau. Scenarijuje daroma prielaida, kad gamybinė infrastruktūra ir įprasti administratoriaus prisijungimo duomenys nepasiekiami, tačiau atskirai kontroliuojama atsarginė kopija lieka prieinama.

Komanda kelio laiką planuoja taip:

Tai palieka tik 20 minučių atsargą iki keturių valandų tikslo. Kadangi kelias užduotis atlieka vienas atkūrimo inžinierius, komanda nedaro prielaidos, kad jas galima vykdyti vienu metu.

Pratybų metu diegimo prisijungimo duomenims gauti prireikia papildomų 55 minučių: dokumentuotas prieigos kelias priklauso nuo nepasiekiamo tapatybių teikėjo. Paslauga funkcinius patikrinimus išlaiko po 275 minučių ir RTO neatitinka. Paskutinė atkuriama operacija yra 12 minučių iki pertrūkio, todėl šiame scenarijuje numatytas RPO pasiekiamas.

Rezultatas nėra bendras „išlaikyta“. Prieigos atsakingas asmuo nustato kontroliuojamą nepriklausomą gavimo kelią, vadovas atnaujinamas, o pavaduojantis inžinierius jį pakartotinai išbando. Kitose integruotose pratybose reikia vėl patikrinti visą trukmę. Verslo atsakingas asmuo taip pat peržiūri, ar likusi laiko atsarga pakankama mažiau palankioms sąlygoms.

Išsaugokite įrodymus ir pašalinkite trūkumus

Saugokite nuoseklų įrodymų rinkinį: patvirtintą BIA, paslaugos ribą ir priklausomybes, atsarginių kopijų specifikaciją, atkūrimo vadovus, krizių vaidmenis ir kontaktus, alternatyvios veiklos procedūras ir pratybų įrašus. Išsaugokite versijas, kad tikrintojai matytų, kuris planas iš tikrųjų buvo išbandytas.

Kiekvienam reikšmingam trūkumui užfiksuokite paveiktą paslaugą, stebėtą rezultatą, verslo pasekmę, atsakingą asmenį, terminą, taisymą ir patikrinimo metodą. Užduoties įvykdymas nėra tas pats, kas pataisymo įrodymas. Pakartotinai išbandykite paveiktą žingsnį ir, jei pasikeitė priklausomybės, platesnį atkūrimo kelią. Vėluojančius veiksmus ir tikslų spragas eskaluokite atsakingam sprendimų priėmėjui.

„Secani“ sumodeliuokite kritinę paslaugą ir ją palaikančias sistemas bei paslaugų teikėjus, susiekite pratybų įrodymus su reikalavimais ar kontrolėmis, kurias jie pagrindžia, ir paverskite spragas užduotimis su atsakingais asmenimis. Tikrintojų komentarus ir žmonių patvirtinimus laikykite prie sprendimų. Dokumentuotas darbo procesas palaiko šį įrodymų kontekstą; techninį atkūrimą vis tiek turi atlikti ir patikrinti atsakinga komanda.

Pradėkite nuo vienos kritinės paslaugos. Susitarkite, ką reiškia atkūrimas, kartu su pavaduojančiu operatoriumi pereikite jos priklausomybių kelią ir suplanuokite apibrėžtą atkūrimo pratybą. Išmatuotą rezultatą naudokite planui atnaujinti, o ne tik pratyboms pažymėti kaip užbaigtoms.