Katastrofu atjaunošanas plāns uzņēmumam

Ja serveris apstājas pirmdienas rītā, rezerves kopijas vienas pašas uzņēmumu neizglābj. Katastrofu atjaunošanas plāns uzņēmumam nosaka, kas notiek pirmajās minūtēs, kurš pieņem lēmumus, kā tiek atjaunotas kritiskās sistēmas un cik ātri bizness var atgriezties pie darba. Tieši šī atšķirība nošķir kontrolētu incidentu no dārgas dīkstāves ar klientu, ieņēmumu un reputācijas zaudējumiem.

Mazajiem un vidējiem uzņēmumiem šis jautājums bieži kļūst aktuāls tikai pēc sāpīga pārtraukuma - izspiedējvīrusa, bojāta datu nesēja, kļūdaina atjauninājuma vai cilvēka kļūdas. Taču biznesa vadībai katastrofu atjaunošana nav tikai IT tēma. Tā ir darbības nepārtrauktības, līgumu izpildes un finanšu kontroles tēma.

Kas patiesībā ir katastrofu atjaunošanas plāns uzņēmumam

Katastrofu atjaunošanas plāns uzņēmumam ir praktisks darbību kopums, kas nosaka, kā uzņēmums atjaunos IT sistēmas, datus un piekļuvi pēc nopietna traucējuma. Tajā tiek definētas prioritātes, atbildīgās personas, atjaunošanas secība, saziņas kārtība un tehniskie resursi, kas vajadzīgi, lai samazinātu dīkstāvi.

Svarīgi saprast, ka tas nav tas pats, kas rezerves kopiju politika. Dublējumi atbild uz jautājumu, vai dati eksistē. Atjaunošanas plāns atbild uz jautājumu, cik ātri uzņēmums spēs atsākt darbu un kādā apjomā. Ja rezerves kopijas ir pieejamas, bet nav skaidrs, kas jādara vispirms, cik ilga būs atkopšana un kurš to vada, uzņēmums joprojām ir riskā.

Tieši tāpēc labs plāns vienmēr savieno tehnisko un vadības pusi. Tas ietver ne tikai serverus, lietotnes un tīklu, bet arī klientu apkalpošanu, grāmatvedību, ražošanu, noliktavu un vadības lēmumu pieņemšanu.

Kāpēc uzņēmumi kļūdaini domā, ka ir gatavi

Praksē visbiežākā kļūda ir pieņēmums, ka mākoņpakalpojumi vai automātiskas rezerves kopijas nozīmē pilnu aizsardzību. Patiesībā mākoņvide neatceļ nepieciešamību pēc atjaunošanas scenārija. Ja ir bojāti piekļuves dati, sinhronizēti izdzēsti faili, nepareizi konfigurētas tiesības vai kompromitēts lietotāja konts, atkopšana var būt sarežģīta un laikietilpīga.

Otrs izplatīts pieņēmums - pietiek ar dokumentu mapē vai kādu vecu Excel failu. Taču plāns, kas nav pārbaudīts un atjaunināts, incidenta brīdī kļūst mazvērtīgs. Kontakti ir novecojuši, infrastruktūra mainīta, piegādātāji nomainīti, bet atbildības palikušas neskaidras.

Vadības līmenī tas rada maldīgu drošības sajūtu. Uz papīra viss izskatās pieņemami, bet reālā incidentā atklājas, ka neviens nezina, kurš aktivizē plānu, kā atjaunot kritisko sistēmu secību vai cik ilgi uzņēmums var izturēt bez konkrētas lietotnes.

Ko šādam plānam jāaptver

Lietderīgs katastrofu atjaunošanas plāns sākas ar biznesa prioritātēm, nevis ar tehnoloģiju sarakstu. Vispirms jānosaka, kuras sistēmas tiešām ir kritiskas ieņēmumu, klientu apkalpošanas un iekšējo procesu uzturēšanai. Vienam uzņēmumam tā būs ERP vai noliktavas sistēma, citam - grāmatvedība, e-pasts un dokumentu aprite.

Pēc tam jādefinē pieļaujamais dīkstāves ilgums un pieļaujamais datu zuduma apjoms. Šeit parasti tiek lietoti divi rādītāji - RTO un RPO. RTO nosaka, cik ātri sistēmai jābūt atjaunotai. RPO nosaka, cik daudz datu uzņēmums drīkst zaudēt laika izteiksmē. Ja finanšu sistēmai RPO ir četras stundas, bet rezerves kopijas notiek reizi dienā, aizsardzība nav pietiekama.

Tālāk plānā jāiekļauj konkrēta atjaunošanas secība. Nav jēgas vispirms atjaunot perifēras sistēmas, ja bez identitātes pārvaldības, tīkla, datubāzes vai virtualizācijas platformas pārējais nemaz nedarbosies. Tieši šī secība bieži nosaka atkopšanas ātrumu.

Ne mazāk svarīga ir lomu sadale. Incidenta brīdī jābūt skaidram, kas pieņem biznesa lēmumus, kas koordinē tehnisko atkopšanu, kas komunicē ar darbiniekiem un klientiem, un kas pieņem lēmumu par eskalāciju ārējiem partneriem. Ja šīs atbildības nav skaidri nodefinētas, kavēšanās sākas jau pirmajā stundā.

Kā izskatās praktiski derīgs katastrofu atjaunošanas plāns uzņēmumam

Dokumentam jābūt pietiekami detalizētam, lai komanda varētu rīkoties, bet ne tik sarežģītam, ka to neviens nelasa. Labā praksē tajā ir iekļauti kritisko sistēmu saraksti, atjaunošanas prioritātes, infrastruktūras atkarības, piegādātāju un atbildīgo personu kontakti, piekļuves glabāšanas principi un incidenta komunikācijas scenāriji.

Svarīgi ir arī iepriekš definēti scenāriji. Piemēram, ko darīt, ja pieejama tikai daļa no datiem, ja nav piekļuves birojam, ja uzbrukums skāris identitātes vidi vai ja jāstrādā pagaidu režīmā no alternatīvas lokācijas. Ne visiem uzņēmumiem vajag identisku detalizācijas pakāpi. Ražošanas uzņēmumam, e-komercijas uzņēmumam un profesionālo pakalpojumu birojam riska profils būs atšķirīgs.

Šeit parādās arī izmaksu jautājums. Ātrāka atkopšana parasti maksā vairāk - replikācija, rezerves infrastruktūra, papildu drošības slāņi un regulāri testi nav bezmaksas. Tāpēc plānam jāatbilst biznesa realitātei. Ne katrai sistēmai vajag gandrīz tūlītēju atjaunošanu, bet kritiskajām sistēmām kompromiss var izmaksāt ievērojami dārgāk.

Biežākie riski, kurus plāns ignorē

Daudzi uzņēmumi domā par aparatūras bojājumu, bet mazāk - par cilvēka kļūdu, piekļuves zaudēšanu un piegādātāju atkarību. Ja viena mākoņplatforma, viens interneta savienojums vai viens konkrēts speciālists kļūst par vienīgo balstu, atkopšanas spējas ir trauslas.

Vēl viena bieža nepilnība ir pieņēmums, ka kiberdrošība un katastrofu atjaunošana ir divas atsevišķas tēmas. Patiesībā izspiedējvīrusa incidents ir klasisks atjaunošanas gadījums. Ja rezerves kopijas nav izolētas, ja administratīvās piekļuves nav segmentētas un ja nav pārbaudīts atjaunošanas process pēc kompromitācijas, teorētiska gatavība ātri sabrūk.

Jāvērtē arī juridiskās un līgumiskās sekas. Dažās nozarēs pieejamības pārtraukums nozīmē ne tikai iekšēju neērtību, bet arī SLA pārkāpumus, termiņu neizpildi vai datu aizsardzības riskus. Tāpēc plānu nevar veidot tikai IT komanda viena pati.

Testēšana ir svarīgāka par pašu dokumentu

Plāns bez testēšanas ir pieņēmums. Testēšana atklāj, vai rezerves kopijas tiešām ir izmantojamas, vai piekļuves darbojas, vai atkarības ir korekti dokumentētas un vai komanda saprot savu lomu. Tieši šeit kļūst redzamas praktiskās nepilnības, kuras dokumentā bieži nepamana.

Ne katram uzņēmumam vajag pilna mēroga katastrofu simulāciju vairākas reizes gadā. Taču vismaz regulāri galda vingrinājumi, atsevišķu sistēmu atjaunošanas testi un procesu pārbaudes ir nepieciešamas. Ja uzņēmums būtiski maina infrastruktūru, pārceļas uz citu vidi, ievieš jaunu biznesa sistēmu vai strauji aug, testēšanas biežums jāpalielina.

Vadībai šeit jāuzdod ļoti vienkāršs jautājums - kad pēdējo reizi mēs reāli pārbaudījām, cik ilgi aizņem atjaunošana? Nevis pieņēmām, bet izmērījām. Šis ir viens no retajiem IT jautājumiem, kur optimismam ir augsta cena.

Kad vajadzīgs ārējs skatījums

Ja uzņēmumā nav pilna iekšējā IT vadības slāņa, katastrofu atjaunošanas plāna izstrāde bieži iestrēgst starp tehniskām detaļām un biznesa prioritātēm. Iekšējā komanda var labi pārzināt sistēmas, taču nepietiekami strukturēt riskus vadības vajadzībām. Savukārt vadība skaidri saprot biznesa ietekmi, bet ne vienmēr redz tehniskās atkarības.

Tāpēc ārējs audits vai neatkarīgs DRP izvērtējums bieži dod lielāku vērtību nekā vēl viens nepārbaudīts dokuments. Tas palīdz saprast, kur plāns balstās uz faktiem un kur - uz cerību. Uzņēmumiem, kas aug, strādā hibrīdā infrastruktūrā vai apkalpo klientus ar augstām pieejamības prasībām, šāds skatījums ir īpaši noderīgs.

Šādās situācijās KSK IT tipa partneris var dot ne tikai tehnisku izpildi, bet arī vadības līmeņa struktūru - sasaistot atjaunošanas mērķus ar reāliem biznesa riskiem, budžetu un atbildību sadalījumu.

No kā sākt, ja plāna vēl nav

Sākumpunkts nav sarežģīta platforma vai dārgs projekts. Sākumpunkts ir skaidrs saraksts ar kritiskajām sistēmām, biznesa procesu prioritātēm un pieļaujamo dīkstāvi. Pēc tam jānovērtē, vai esošās rezerves kopijas, piekļuves pārvaldība un infrastruktūras dizains šos mērķus vispār atbalsta.

Ja atbilde nav pārliecinoša, nav jēgas atlikt. Katrs mēnesis bez pārbaudīta plāna nozīmē, ka uzņēmums paļaujas uz improvizāciju. Un improvizācija darbojas tikai tad, ja incidentam nav nozīmes. Biznesam ar klientu saistībām, finanšu plūsmu un reputācijas risku tas nav pieņemams modelis.

Labs katastrofu atjaunošanas plāns uzņēmumam nav formāla prasība vai audits mapē. Tas ir vadības instruments, kas ļauj saglabāt kontroli brīdī, kad apstākļi kļūst nestabili. Jo agrāk tas ir sakārtots, jo mazāka iespēja, ka nākamais incidents pārvērtīsies par ilgstošu biznesa krīzi.