7 principi rezerves kopiju politikai uzņēmumā

Failu kopēšana reizi nedēļā uz ārējo disku var šķist pietiekama, līdz brīdim, kad tiek izdzēsta grāmatvedības datubāze, šifrēti koplietošanas faili vai nedarbojas kritiska biznesa sistēma. Tad jautājums vairs nav par to, vai uzņēmumam ir rezerves kopijas. Jautājums ir, vai rezerves kopiju politika uzņēmumam ļauj atjaunot darbu pietiekami ātri un ar pieņemamu datu zudumu.

Mazajiem un vidējiem uzņēmumiem dīkstāve bieži rada ne tikai tiešus finanšu zaudējumus. Tā aptur pasūtījumu apstrādi, kavē klientu apkalpošanu, sarežģī algu un rēķinu apriti, kā arī var radīt līgumiskas un reputācijas sekas. Skaidra politika pārvērš rezerves kopijas no tehniska uzdevuma par vadāmu nepārtrauktības procesu.

Ko nosaka rezerves kopiju politika uzņēmumam

Rezerves kopiju politika nav tikai instrukcija IT speciālistam par to, kurā laikā palaist kopēšanu. Tā nosaka uzņēmuma lēmumus par datu vērtību, pieņemamo risku un atbildību incidenta laikā. Labā politikā ir precīzi definēts, kuri dati un sistēmas tiek aizsargāti, cik bieži veido kopijas, cik ilgi tās glabā un kā tiek pārbaudīta atjaunošana.

Tajā jābūt arī skaidrai atbildei uz praktiskiem vadības jautājumiem: cik ilgi uzņēmums var strādāt bez piekļuves ERP sistēmai, e-pastam vai dokumentu krātuvei? Cik daudz datu drīkst pazust? Kurš drīkst ierosināt atjaunošanu, un kurš apstiprina, ka atjaunotā informācija ir korekta?

Bez šīm atbildēm tehniski veiksmīga kopēšana var neatrisināt biznesa problēmu. Piemēram, kopija, kas tiek veidota vienreiz naktī, var būt pieņemama arhīva dokumentiem, bet nederīga noliktavas vai ražošanas sistēmai, kur dati mainās visas dienas garumā.

Sāciet ar sistēmu un datu kritiskumu

Vienāda pieeja visiem datiem parasti nozīmē pārmaksu vai nepietiekamu aizsardzību. Efektīvāk ir sadalīt informāciju pēc tās nozīmes biznesam. Kritiskajā grupā parasti ietilpst finanšu uzskaites dati, klientu un pasūtījumu informācija, ražošanas vai noliktavas sistēmas, līgumi, projektu dokumentācija un identitāšu pārvaldības dati.

Otrajā grupā var būt darba faili, vēsturiska korespondence un sistēmas, kuru īslaicīga nepieejamība rada neērtības, bet neaptur pamatdarbību. Savukārt daļa informācijas var būt arhīva dati ar ilgāku glabāšanas termiņu, taču zemākām prasībām attiecībā uz ātru atjaunošanu.

Šāds sadalījums jāveido kopā ar procesu īpašniekiem, nevis tikai IT komandu. Finanšu vadītājs vislabāk zina, cik ilgi pieļaujama piekļuves neesamība grāmatvedības sistēmai. Operāciju vadītājs var novērtēt, kuras lietojumprogrammas apstādina piegādes. IT funkcijas uzdevums ir pārvērst šīs biznesa prasības tehniskā risinājumā.

RPO un RTO - divi rādītāji, kas nosaka prioritātes

Politikā ir vērts izmantot divus konkrētus rādītājus. RPO jeb atjaunošanas punkta mērķis nosaka maksimāli pieļaujamo datu zuduma periodu. Ja RPO ir četras stundas, uzņēmums pieņem, ka incidentā var zaudēt līdz četrām stundām pēdējo izmaiņu.

RTO jeb atjaunošanas laika mērķis nosaka, cik ātri sistēmai jāatgriežas darbā. Ja pasūtījumu sistēmas RTO ir divas stundas, nepietiek ar solījumu to atjaunot “pēc iespējas ātrāk”. Jābūt infrastruktūrai, piekļuvēm, atbildīgajiem un pārbaudītai procedūrai, kas šo termiņu padara reālistisku.

Jo īsāks RPO un RTO, jo lielākas parasti ir izmaksas. Tādēļ mērķiem jābūt samērīgiem ar katras sistēmas ietekmi uz ieņēmumiem, klientu saistībām un regulatīvajām prasībām.

Nepietiek ar vienu kopiju vienā vietā

Klasiskais 3-2-1 princips joprojām ir labs pamats: vismaz trīs datu kopijas, divos atšķirīgos datu nesējos, un viena kopija ārpus primārās vides. Mūsdienās uzņēmumiem jāskatās tālāk - ārpus primārās vides esošajai kopijai jābūt aizsargātai arī pret izspiedējvīrusiem, kļūdainu dzēšanu un kompromitētiem administratora kontiem.

Ja rezerves kopijas atrodas tajā pašā tīklā ar tām pašām administratora piekļuves tiesībām, uzbrucējs var mēģināt dzēst vai šifrēt arī tās. Tāpēc politikā jāparedz nemainīgas jeb immutable kopijas, piekļuves tiesību nošķiršana, daudzfaktoru autentifikācija un atsevišķa rezerves kopiju administrēšana.

Mākonis pats par sevi nav rezerves kopija. Daudzi mākoņpakalpojumi nodrošina pieejamību savā infrastruktūrā, taču tas ne vienmēr pasargā no lietotāja kļūdas, nepareizas sinhronizācijas vai ļaunprātīgas datu dzēšanas. Konkrētie pakalpojuma nosacījumi ir jāizvērtē, nevis jāpieņem, ka piegādātājs automātiski atrisina visus atjaunošanas scenārijus.

Drošība un datu glabāšanas termiņi

Rezerves kopijas bieži satur pilnu uzņēmuma informācijas kopumu - personas datus, finanšu dokumentus, paroles, konfigurācijas un komercnoslēpumus. Tādēļ tām jāpiemēro līdzvērtīgas vai pat stingrākas drošības prasības nekā darba videi. Tas nozīmē šifrēšanu pārsūtīšanas un glabāšanas laikā, piekļuves reģistrēšanu un regulāru tiesību pārskatīšanu.

Glabāšanas termiņi jānosaka atbilstoši biznesa, juridiskajām un nozares prasībām. Īss termiņš var neatstāt pietiekami senu, tīru kopiju, ja ļaunprogrammatūra sistēmā uzturas nepamanīta vairākas nedēļas. Pārāk ilga glabāšana savukārt palielina izmaksas un datu pārvaldības risku.

Praktiska pieeja ir saglabāt biežas īstermiņa kopijas operatīvai atjaunošanai, retākas ilgtermiņa kopijas arhīvam un atsevišķus nosacījumus kritiskiem periodiem, piemēram, gada pārskatiem vai būtiskiem projektiem. Politikā jānorāda arī drošas kopiju dzēšanas kārtība pēc termiņa beigām.

Atjaunošanas tests ir svarīgāks par veiksmīgu kopēšanas atskaiti

Zaļa atzīme rezerves kopiju sistēmas panelī apliecina, ka kopēšanas uzdevums ir noslēdzies. Tā neapliecina, ka dati ir izmantojami un lietojumprogramma pēc atjaunošanas darbosies. Bojāti faili, nepilnīgas datubāzu kopijas, trūkstošas atkarības vai nepareizas piekļuves tiesības var atklāties tikai atjaunošanas brīdī.

Politikā jāparedz regulāri testi dažādos līmeņos. Ikdienā var pārbaudīt kopēšanas uzdevumu statusu un kļūdas. Periodiski jāatjauno atsevišķi faili, mapes un datubāzes. Vismaz noteiktam kritisko sistēmu lokam jāveic pilns scenārija tests - piemēram, atjaunošana izolētā vidē ar lietotāju validāciju.

Testa rezultāts ir jāfiksē: ko atjaunoja, cik ilgu laiku tas aizņēma, vai sasniegts RPO un RTO, kādas problēmas konstatētas un kam jānovērš trūkumi. Šie pierādījumi ir vērtīgi arī auditos, apdrošināšanas prasībās un klientu drošības izvērtējumos.

Nosakiet atbildību pirms incidenta

Pat labi konfigurēts risinājums rada risku, ja nav skaidrs, kas par to atbild. Politikai jānorāda sistēmu īpašnieki, tehniskais operators, piekļuves tiesību pārvaldītājs un lēmuma pieņēmējs incidenta laikā. Īpaši svarīgi ir definēt, kurš drīkst pieprasīt lielapjoma atjaunošanu un kā tiek pārbaudīta šāda pieprasījuma autentiskums.

Ja pakalpojumu nodrošina ārējais IT partneris, līgumiskajās vienošanās jāatspoguļo pārvaldības robežas. Jābūt saprotamam, kurš uzrauga kopiju veidošanu, kā tiek eskalētas kļūdas, kādi ir reakcijas laiki un kā tiek veikti atjaunošanas testi. KSK IT šādās situācijās palīdz sasaistīt tehnisko ieviešanu ar uzņēmuma nepārtrauktības prasībām, lai risinājums nebūtu tikai licenču un glabātuves apjoma jautājums.

Kā ieviest politiku bez nevajadzīgas sarežģīšanas

Sāciet ar esošās situācijas auditu: noskaidrojiet, kur glabājas dati, kas jau tiek kopēts, kuri uzdevumi regulāri beidzas ar kļūdu un vai ir iespējams atjaunot kritiskās sistēmas. Pēc tam apstipriniet sistēmu prioritātes, RPO un RTO kopā ar vadību un procesu īpašniekiem.

Nākamais solis ir dokumentēt izvēlēto arhitektūru, glabāšanas termiņus, drošības prasības un atbildību. Dokumentam nav jābūt apjomīgam, taču tam jābūt pietiekami konkrētam, lai incidentā nebūtu jāpieņem pamatlēmumi no jauna. Visbeidzot, ieplānojiet testus un regulāru politikas pārskatīšanu - īpaši pēc jaunas sistēmas ieviešanas, uzņēmuma iegādes, biroja pārcelšanās vai būtiskām izmaiņām mākoņvidē.

Rezerves kopiju politika ir vērtīga tad, kad tā atbilst tam, kā uzņēmums patiesībā strādā, un tiek regulāri pārbaudīta. Pirmais atjaunošanas tests bieži atklāj vairāk nekā mēnešiem ilgas diskusijas par teorētisku aizsardzību.