Darbības nepārtrauktība: pierādiet atjaunošanas ceļu

Atjaunošanas plāns kļūst ticams, kad komanda var parādīt, kā kritisks pakalpojums tiks atjaunots, kādā secībā un ar kādiem resursiem. Dublējumkopija ir viens no šī plāna ievaddatiem; tā nepierāda visu atjaunošanas spēju.

Tehnoloģiju direktoram praktiskais jautājums ir, vai atjaunošana joprojām darbojas, kad parastie darbības pieņēmumi vairs nav spēkā. Vai procedūru var izpildīt cits inženieris? Vai komanda var iegūt akreditācijas datus bez ražošanas identitātes pakalpojuma? Vai biznesa lietotāji var pabeigt darījumu pēc infrastruktūras atjaunošanas?

Uztveriet nepārtrauktību kā inženiertehniski veidotu spēju: definējiet pieņemamus rezultātus, identificējiet atkarības, izveidojiet atjaunošanas procedūras, izmēģiniet tās mācībās un saglabājiet pierādījumus par notikušo. Rezultāts ir pierādīts atjaunošanas ceļš ar saprastiem ierobežojumiem un vājajām vietām, kuru novēršana ir piešķirta.

Nosakiet pienākumu un darbības robežu

NIS2 21. pants starp kiberdrošības riska pārvaldības pasākumiem ietver darbības nepārtrauktību, piemēram, dublējumkopiju pārvaldību un atgūšanu pēc katastrofas, kā arī krīžu pārvaldību. Tas attiecas arī uz politikām un procedūrām šo pasākumu efektivitātes novērtēšanai. 20. pants aptver vadības apstiprinājumu un uzraudzību.

NIS2 ir direktīva, kas tiek ieviesta ar nacionālajiem tiesību aktiem. Piemērojamība ir atkarīga no nozares, lieluma, pakalpojuma un iekļaušanas noteikumiem; konkrētos pienākumus nosaka piemērojamās nacionālās un nozares prasības. Neuzskatiet vispārīgu nepārtrauktības veidni par pilnīgu juridisko novērtējumu.

Darbības ziņā nošķiriet četras savstarpēji saistītas darbības:

• Darbības nepārtrauktība: svarīgu biznesa funkciju darbības uzturēšana, iespējams, ar samazinātu jaudu.
• Dublējumkopiju pārvaldība: aizsargātu, atjaunojamu datu un nepieciešamās konfigurācijas kopiju uzturēšana.
• Atgūšana pēc katastrofas: tehnisko sistēmu atjaunošana un to atbalstītā pakalpojuma validācija.
• Krīžu pārvaldība: lēmumu, resursu, saziņas un eskalācijas koordinēšana.

Pakalpojums var turpināties ar manuālu darbu, kamēr tā sistēmas paliek nepieejamas. Savukārt serveri var darboties, kamēr biznesa funkcija paliek nelietojama. Definējiet gan tehniskos, gan biznesa pieņemšanas kritērijus.

Sāciet ar vienu kritisku pakalpojumu un noteiktu scenārija robežu. Atjaunošana pēc nejaušas dzēšanas atšķiras no atjaunošanas pēc administratīvo akreditācijas datu apdraudēšanas. Reģistrējiet, kuras situācijas plāns aptver, kurām nepieciešamas atsevišķas procedūras un kas pieņem jebkuru atlikušo nepilnību.

Strādājiet atpakaļvirzienā no biznesa pakalpojuma

Ietekmes uz darbību analīze jeb BIA nosaka, ko traucējums nozīmē, pirms inženieri izvēlas atjaunošanas risinājumu. Intervējiet pakalpojuma īpašnieku un cilvēkus, kas faktiski veic darbu. Pajautājiet, kas notiek pēc stundas, darba dienas un ilgāka pārtraukuma: neizpildīti darījumi, nedroša darbība, līgumsaistību neizpilde, kaitējums klientiem vai uzkrājies neizpildītā darba apjoms.

Dokumentējiet minimālo pieņemamo darbības līmeni. Klientu portālam var būt nepieciešama pasūtījumu iesniegšana un piekļuve pasūtījumu statusam, pirms atgriežas pārskatu funkcijas. Ražošanas darbībai var būt nepieciešama plānošana un drošības informācija pirms administratīvajām funkcijām.

Risinājumu vada trīs rādītāji:

Tie ir saistīti, bet atšķirīgi. RTO jāatstāj vieta pieļaujamā traucējuma ietvaros biznesa validācijai un darbības atjaunošanai. RPO apraksta pieņemamo datu zudumu; tas nav vēl viens dīkstāves mērķis.

Skaidri vienojieties par laika atskaiti. Ja viena komanda mēra RTO no incidenta izsludināšanas, bet cita – no pakalpojuma pārtraukuma, ziņotie rezultāti būs maldinoši. Reģistrējiet atklāšanas un aktivizēšanas laiku atsevišķi pat tad, ja saskaņotais atjaunošanas rādītājs sākas vēlāk.

Biznesa īpašnieki apstiprina nepieciešamo rezultātu; inženieri pierāda, vai risinājums to spēj sasniegt. Ja izmaksas, personāls vai piegādātāju ierobežojumi padara mērķi nereālu, piedāvājiet iespējas: investēt ātrākā atjaunošanā, ieviest samazinātu darbību, mainīt mērķi ar atbildīgu apstiprinājumu vai pieņemt risku. Neaizstājiet klusi biznesa prasību ar to, ko pašreizējā dublēšanas sistēma nejauši sasniedz.

Kartējiet atkarības, kas var novērst atjaunošanu

Klientu portālam datubāzes atjaunošana var joprojām atstāt pakalpojumu nelietojamu, ja nav pieejama identitāte, DNS vai izvietošanas akreditācijas dati. Veidojiet atkarību karti no biznesa darījuma uz āru, nevis no serveru saraksta uz iekšu.

Iekļaujiet lietotnes un datubāzes, bet arī tīklus, identitātes nodrošinātājus, sertifikātu pakalpojumus, noslēpumus, šifrēšanas atslēgas, izvietošanas artefaktus, uzraudzību, ārējās integrācijas, cilvēkus un piegādātāju atbalstu. Reģistrējiet, kur katra atkarība darbojas, kas to var atjaunot un kam jāpastāv pirms atjaunošanas sākuma.

Īpaši meklējiet cikliskas atkarības. Paroļu glabātuvei var būt nepieciešama identitātes platforma, bet šīs platformas atjaunošanai nepieciešami glabātuvē saglabātie akreditācijas dati. Atjaunošanas rokasgrāmata var atrasties sadarbības pakalpojumā, kas pats ir nepieejams. Atrisiniet šos ciklus ar kontrolētu ārkārtas piekļuvi un neatkarīgi pieejamām instrukcijām; testējiet abus, nevis pieņemiet, ka tie darbojas.

Atjaunošanas secība ir atkarību grafs, nevis obligāti universāla secība: tīkls, datubāze, lietotne. Dažus uzdevumus var veikt paralēli. Citiem ir kontrolpunkti, piemēram, tīras administratīvās vides apstiprināšana, pirms tai tiek pakļautas atjaunotās darba slodzes.

Piegādātājiem nošķiriet solījumus no darbības kārtības. Nosakiet atbalsta kontaktus, eskalācijas ceļus, klienta puses pienākumus, eksporta iespējas, atjaunošanas saistības un to, kā saņemsiet atjauninājumus traucējuma laikā. Piegādātāja atjaunošanas mērķis automātiski nenosaka jūsu pakalpojuma mērķi no gala līdz galam. Modelējiet, kas notiek, ja tas ir nepieejams ilgāk nekā gaidīts.

Veidojiet dublēšanu ap atjaunošanu, nevis uzdevuma pabeigšanu

Veiksmīgs dublēšanas uzdevums parāda, ka process ir pabeigts. Tas nepierāda, ka tika saglabāti pareizie dati, ka atslēgas joprojām ir pieejamas vai ka lietotne var izmantot atjaunoto stāvokli.

Katrai kritiskai sistēmai izveidojiet dublēšanas specifikāciju:

• Iekļautās datu kopas, konfigurācija, artefakti un skaidri izņēmumi.
• Dublēšanas metode, grafiks, gaidāmais atjaunošanas punkta vecums un glabāšana.
• Glabāšanas vietas un atkarības no kontiem, reģioniem vai objektiem.
• Administratīvā piekļuve, šifrēšana, atslēgu atgūšana un dzēšanas kontroles.
• Uzraudzības pienākumi, kļūmju eskalācija un atjaunošanas instrukcijas.
• Atjaunošanas testa tvērums, pieņemšanas kritēriji un saglabātie rezultāti.

Plaši izmantotā 3-2-1 pieeja, ko dažkārt papildina ar bezsaistes vai nemainīgu kopiju un pārbaudi, ir praktisks projektēšanas īkšķa likums, nevis universāla NIS2 formula. Izvērtējiet, vai kopijām ir patiešām atšķirīgi atteices veidi. Vairākas kopijas, kas tiek pārvaldītas ar vienu apdraudētu administratora kontu, var sniegt nelielu aizsardzību pret apzinātu dzēšanu.

Arī bezsaistes un nemainīgas kopijas atšķiras. Bezsaistes glabātuve ir atvienota; nemainīga glabātuve ierobežo modificēšanu vai dzēšanu saskaņā ar noteiktām kontrolēm. Pārbaudiet, kas var mainīt glabāšanas laiku, iznīcināt atslēgas, slēgt kontu vai mainīt piekļuves politikas. Neuzskatiet apzīmējumu vien par aizsardzības pierādījumu.

Saskaņojiet mehānismu ar datiem

Darījumu datubāzei momentuzņēmumu biežums vien var neizpildīt RPO. Var būt nepieciešama žurnālu tveršana, lietotņu līmenī konsekventas dublējumkopijas un atjaunošana uz konkrētu laika punktu. Validējiet, vai darījumus, kas izkliedēti pa vairākām sistēmām, var atjaunot saskaņotā stāvoklī.

Replikācija var samazināt pārtraukumu, taču tā var replicēt arī bojājumus vai ļaunprātīgas izmaiņas. Tā neaizstāj saglabātus atjaunošanas punktus. Līdzīgi SaaS pieejamības saistības var neaptvert atjaunošanu pēc klienta veiktas dzēšanas vai konta apdraudēšanas; pārbaudiet faktisko atjaunošanas un eksporta kārtību.

Iekļaujiet šifrēšanas atslēgas un konfigurāciju, kas nepieciešama atjaunoto datu interpretēšanai. Attiecīgā gadījumā aizsargājiet atjaunošanas materiālus atsevišķi, ar kontrolētu piekļuvi un testētu iegūšanas ceļu. Šifrēšanai un atslēgu pārvaldībai jāaptver atjaunošana, ne tikai parastā darbība.

Glabāšanā jāņem vērā novēlota atklāšana: jaunākā kopija jau var saturēt problēmu. Vecāka tīra punkta izvēle var palielināt datu zudumu virs RPO. Dokumentējiet šo kompromisu un nepieciešamo saskaņošanas darbu, nevis sauciet jebkuru pabeigtu atjaunošanu par panākumu.

Rakstiet rīcības instrukcijas, ko var izpildīt cits inženieris

Noderīga atjaunošanas rīcības instrukcija identificē priekšnosacījumus, darbības, gaidāmos rezultātus, kļūmju zarus un pieņemšanas pārbaudes. Tai jābūt pietiekami konkrētai, lai pilnvarots aizvietotājs to varētu izpildīt, nerekonstruējot arhitektūru spiediena apstākļos.

Sāciet ar aktivizēšanas nosacījumiem un drošības robežām. Kas atļauj atjaunošanu? Kur tā notiks? Kuriem tīkliem jāpaliek izolētiem? Kādas ražošanas izmaiņas mācību laikā ir aizliegtas? Ja ir aizdomas par ļaunprātīgu darbību, saglabājiet attiecīgos pierādījumus un koordinējiet ierobežošanu, pirms atjaunotās sistēmas tiek atkal pieslēgtas.

Katrā solī jābūt:

Videi specifiskām komandām atsaucieties uz kontrolētām procedūrām. Neglabājiet noslēpumus pašā rīcības instrukcijā, bet paskaidrojiet, kā pilnvaroti reaģētāji tos iegūst pārtraukuma laikā.

Atsevišķi mēriet sagatavošanu, pārsūtīšanu, atjaunošanu, konfigurēšanu, validāciju un nodošanu. Ātra datu atjaunošana joprojām var neiekļauties RTO, jo infrastruktūras nodrošināšana vai biznesa pārbaudes aizņem ilgāku laiku nekā gaidīts.

Kiberatjaunošanā pārbūve no uzticamiem artefaktiem var būt drošāka nekā veselu mašīnu atjaunošana. Validējiet priviliģētos kontus, attiecīgā gadījumā nomainiet atklātos akreditācijas datus un pirms nodošanas lietošanā pārbaudiet, vai nav palikuši uzbrucēja noturēšanās mehānismi. Šiem lēmumiem jābūt skaidriem procedūras zariem.

Noslēdziet ar pakalpojuma līmeņa pārbaudēm: autentifikāciju, reprezentatīvu darījumu, integrāciju darbību, uzraudzību un saskaņošanu. Tehniskais vadītājs reģistrē pabeigšanu; biznesa īpašnieks pieņem saskaņoto darbības līmeni. Iekļaujiet kontrolētu atgriešanos no pagaidu risinājumiem, nosakot atbildību par rindā esošā darba un dublēto ierakstu sakārtošanu.

Uzturiet biznesa darbību, kamēr notiek atjaunošana

Alternatīvai darbībai nepieciešamas savas jaudas un drošības robežas. „Izmantojiet izklājlapu” nav plāns, ja vien kāds nav noteicis piekļuvi, laukus, pilnvarojumu, glabāšanas aizsardzību un vēlāku saskaņošanu.

Traucēta pasūtījumu pakalpojuma gadījumā pagaidu process varētu pieņemt ierobežotu pasūtījumu klasi pa apstiprinātu kanālu, izsniegt unikālas atsauces un atlikt maksājumu apstrādi. Reģistrējiet, kas apstiprina pasūtījumus, kā tiek novērsti dublikāti, kā tiek aizsargāta klientu informācija un kad pagaidu risinājums jāpārtrauc.

Izvērtējiet, vai samazināta darbība patiešām nodrošina pietiekami daudz laika. Manuāla apstrāde var izturēt nelielu apjomu, bet sabrukt parastās slodzes apstākļos. Testējiet reprezentatīvu pieprasījumu un identificējiet prioritāros klientus vai darījumus pēc saskaņotiem biznesa kritērijiem.

Plānojiet arī cilvēkus un darba vietas. Atjaunošana var neizdoties, jo vienīgais kvalificētais operators nav pieejams, alternatīvajai vietai nav savienojamības vai reaģētāji nevar droši strādāt ilgstoša incidenta laikā. Piešķiriet aizvietotājus, nodošanas prasības un personāla nodrošinājuma kārtību, nevis paļaujieties uz atsevišķu cilvēku izturību.

Piešķiriet krīzes komandai skaidras lēmumu tiesības

Nošķiriet incidenta koordinēšanu no praktiskās atjaunošanas, lai tehniskais vadītājs vienlaikus neatjaunotu sistēmas, neapstiprinātu izdevumus un neatbildētu katrai ieinteresētajai pusei.

Piešķiriet galvenās un aizvietotāju lomas krīzes koordinēšanai, tehniskajai atjaunošanai, biznesa darbībai, vadības lēmumiem, komunikācijai un juridiskajam vai atbilstības novērtējumam. Reģistrējiet aktivizēšanas sliekšņus, saziņas veidus, lēmumu pilnvaras un eskalācijas nosacījumus. Praktiski iepriekšēji pilnvarojumi var aptvert ārkārtas atbalsta iegādi, alternatīvu infrastruktūru un nedrošu pakalpojumu apturēšanu vadības apstiprinātās robežās.

Sagatavojiet saziņas veidnes darbiniekiem, klientiem, piegādātājiem un iestādēm. Katrā jānošķir zināmi fakti no aplēsēm, jāapraksta ietekmētie pakalpojumi, jāsniedz aktuālās instrukcijas un jānorāda nākamā atjauninājuma laiks. Testējiet alternatīvu kanālu gadījumam, kad uzņēmuma e-pasts un tērzēšana nav pieejami. Nodrošiniet, ka reaģētāji var droši piekļūt kontaktinformācijai ārpus parastajām sistēmām.

Ziņošanas novērtējumam jānotiek paralēli atjaunošanai. Būtiskiem incidentiem tvēruma ietvaros NIS2 23. pants nosaka agrīno brīdinājumu 24 stundu laikā, paziņojumu par incidentu 72 stundu laikā un parasti galīgo ziņojumu viena mēneša laikā pēc paziņojuma. Pārbaudiet piemērojamos nacionālos un nozares noteikumus, sliekšņus, adresātus un procedūras. Ne par katru pārtraukumu automātiski jāziņo.

Norīkojiet kādu, kas izseko uzzināšanas laiku un ziņošanas lēmumus; negaidiet pilnīgu atjaunošanu, pirms novērtējat pienākumus. Ja ir iesaistīti personas dati, atsevišķi izvērtējiet VDAR prasības par paziņošanu par pārkāpumiem atbilstoši organizācijas lomai un riskam personām.

Pārbaudiet dažādus apgalvojumus ar dažādiem testiem

Izvēlieties mācību veidu atbilstoši tam, kas jums jāpierāda:

Nosakiet biežumu kā praktisku, uz risku balstītu lēmumu, ņemot vērā piemērojamās prasības, pakalpojuma kritiskumu, izmaiņu tempu un iepriekšējos konstatējumus. Nepieņemiet, ka universāls ceturkšņa vai gada intervāls izpilda katru pienākumu. Ierosiniet papildu testus pēc būtiskām arhitektūras, piegādātāju, piekļuves vai personāla izmaiņām.

Pirms testēšanas apstipriniet scenāriju, mērķus, drošības kontroles, dalībniekus, apturēšanas nosacījumus un veiksmes kritērijus. Ja iespējams, dodiet priekšroku izolētām vidēm. Novērsiet, ka testa ziņojumi, maksājumi vai paziņojumi klientiem nonāk reālajā darbībā.

Izmantojiet reālistiskus ierobežojumus: prombūtnē esošu speciālistu, nepieejamus identitātes pakalpojumus, vecāku tīru dublējumkopiju vai aizkavētu piegādātāja atbalstu. Neizsniedziet klusi akreditācijas datus un infrastruktūru, kas incidenta laikā nepastāvētu.

Fiksējiet scenāriju, dalībniekus, sākuma un beigu laiku, soļu ilgumu, faktiskos rezultātus un novirzes. Reģistrējiet sniegto palīdzību un īsceļus. Ja testā netika veiktas DNS izmaiņas, izmantoti ražošanas apjoma dati vai ārējās integrācijas, norādiet to. Ierobežots rezultāts ir noderīgāks par pārspīlētu sekmīgu vērtējumu.

Praktisks piemērs: klientu portāla atjaunošanas ceļa pierādīšana

Aplūkosim ilustratīvu portālu, kas atbalsta pasūtījumu iesniegšanu. Turpmākie mērķi un laiki ir pieņēmumi, nevis nozares etaloni vai produkta solījumi.

Uzņēmums vienojas par četru stundu RTO un 15 minūšu RPO. Atjaunošana nozīmē, ka klienti var autentificēties, iesniegt pasūtījumu un redzēt tā statusu; pārskati var atgriezties vēlāk. Scenārijs pieņem, ka ražošanas infrastruktūra un parastie administratora akreditācijas dati nav pieejami, bet atsevišķi kontrolēta dublējumkopija joprojām ir pieejama.

Komanda plāno ceļa laika budžetu šādi:

Tas atstāj tikai 20 minūtes līdz četru stundu mērķim. Tā kā vairākus uzdevumus veic viens atjaunošanas inženieris, komanda nepieņem, ka tos var veikt vienlaikus.

Mācību laikā izvietošanas akreditācijas datu iegūšana aizņem papildu 55 minūtes: dokumentētais piekļuves ceļš ir atkarīgs no nepieejamā identitātes nodrošinātāja. Pakalpojums iztur funkcionālās pārbaudes pēc 275 minūtēm un neiekļaujas RTO. Tā jaunākais atjaunojamais darījums ir 12 minūtes pirms pārtraukuma, kas atbilst šajā scenārijā pieņemtajam RPO.

Rezultāts nav vispārīgs sekmīgs vērtējums. Piekļuves īpašnieks izveido kontrolētu neatkarīgu iegūšanas ceļu, rīcības instrukcija tiek atjaunināta, un aizvietotājs inženieris to testē atkārtoti. Nākamajās integrētajās mācībās vēlreiz jāpārbauda viss kopējais ilgums. Biznesa īpašnieks arī pārskata, vai atlikušā laika rezerve ir pietiekama mazāk labvēlīgiem apstākļiem.

Saglabājiet pierādījumus un novērsiet vājās vietas

Uzturiet saskaņotu pierādījumu kopumu: apstiprināto BIA, pakalpojuma robežu un atkarības, dublēšanas specifikāciju, atjaunošanas rīcības instrukcijas, krīzes lomas un kontaktus, alternatīvās darbības procedūras un mācību ierakstus. Saglabājiet versijas, lai pārskatītāji varētu redzēt, kurš plāns faktiski tika testēts.

Katrai būtiskai vājai vietai reģistrējiet ietekmēto pakalpojumu, novēroto rezultātu, biznesa sekas, īpašnieku, izpildes termiņu, novēršanas pasākumu un pārbaudes metodi. Uzdevuma pabeigšana nav tas pats, kas labojuma pierādīšana. Atkārtoti testējiet ietekmēto soli un, ja atkarības mainījušās, plašāko atjaunošanas ceļu. Eskalējiet nokavētas darbības un mērķu nepilnības atbildīgajam lēmumu pieņēmējam.

Secani modelējiet kritisko pakalpojumu un tā atbalstošās sistēmas un pakalpojumu sniedzējus, savienojiet mācību pierādījumus ar prasībām vai kontrolēm, ko tie atbalsta, un pārvērtiet nepilnības uzdevumos ar īpašniekiem. Uzturiet pārskatītāju komentārus un cilvēku apstiprinājumus piesaistītus lēmumiem. Dokumentētā darba plūsma atbalsta šo pierādījumu kontekstu; tehniskā atjaunošana joprojām jāizpilda un jāvalidē atbildīgajai komandai.

Sāciet ar vienu kritisku pakalpojumu. Vienojieties, ko nozīmē atjaunošana, izejiet tā atkarību ceļu kopā ar aizvietotāju operatoru un ieplānojiet ierobežotas atjaunošanas mācības. Izmantojiet izmērīto rezultātu, lai atjauninātu plānu, nevis tikai lai atzīmētu mācības kā pabeigtas.