Atjaunota sistēma vēl nenozīmē atjaunotu uzņēmumu

Pēc nopietna kiberincidenta uzņēmuma vadība saņem ziņu, ka sistēmas ir atjaunotas. Serveri darbojas, lietojumprogramma atveras, lietotāji var autentificēties un datubāze ir pieejama. Tehniskā komanda ir paveikusi lielu darbu, iespējams, sarežģītos apstākļos un ar būtiskiem resursu ierobežojumiem. Tomēr nākamajā rītā grāmatvedība konstatē neatbilstības darījumu uzskaitē, klientu apkalpošanas nodaļa nevar noteikt daļas pieprasījumu statusu, bet noliktavā nav pārliecības, vai iepriekš izpildītie pasūtījumi nav apstrādāti atkārtoti. Vai uzņēmums ir atjaunots? No infrastruktūras administratora skatpunkta atbilde var būt apstiprinoša. Serveris ir pieejams, nepieciešamie servisi startējušies un uzraudzības sistēma neuzrāda būtiskas kļūdas. No biznesa procesa īpašnieka skatpunkta situācija ir cita: darbs nevar atsākties, kamēr nav noskaidrots datu stāvoklis un iespējamās neatbilstības. Vadībai savukārt jāpieņem lēmums, vai uzņēmums drīkst atjaunot klientu operācijas, kāda kontrole nepieciešama pārejas periodā un kurš uzņemas atbildību par atlikušo risku.

Šī atšķirība ir nozīmīga, jo atkopšanos mēdz aprakstīt ar tehniskiem rādītājiem, kuri nesniedz pilnīgu priekšstatu par uzņēmuma darbspēju. Rezerves kopijas esamība nepierāda, ka no tās varēs atjaunot nepieciešamo sistēmu. Veiksmīga datubāzes atjaunošana nepierāda, ka visas biznesa transakcijas ir korektas. Arī lietojumprogrammas pieejamība neapliecina, ka tās atkarīgie pakalpojumi, integrācijas un organizatoriskie procesi ir gatavi normālai ekspluatācijai. NIST SP 800-184 kiberdrošības incidentu atkopšanos aplūko kā plānošanas, prioritizācijas, testēšanas un pastāvīgas uzlabošanas procesu. Savukārt ISO 22301 darbības nepārtrauktību skata organizācijas spējas uzturēt un atjaunot pieņemamu darbību kontekstā. Šie ietvari palīdz saprast, kāpēc pēc kiberincidenta atjaunošanai vajadzīgs plašāks pierādījumu kopums nekā tikai pozitīvs tehniskā testa rezultāts. S01S02

Informācijas sistēmas tehnisko atjaunošanu var raksturot salīdzinoši konkrēti. Ir atjaunota infrastruktūra, operētājsistēmas un lietojumprogrammu komponenti, nepieciešamā konfigurācija un datu piekļuve. Tehniskās uzraudzības līmenī iespējams pārbaudīt, vai pakalpojums atbild uz pieprasījumiem, vai sistēmas resursi ir pieejami un vai nav konstatētas kritiskas kļūdas. Uzņēmuma darbības atkopšanās prasa vairāk. Darbiniekiem jāspēj veikt savus uzdevumus, klientiem — izmantot nepieciešamos pakalpojumus, bet datiem jābūt pietiekami pilnīgiem un korektiem, lai uzņēmums nepieņemtu lēmumus uz nepareizas informācijas pamata. Turklāt jābūt pārliecībai, ka atjaunotā vide nav saglabājusi zināmu kompromitēšanas mehānismu, kas ļautu incidentam turpināties.

Pieņemsim, ka uzņēmuma norēķinu sistēma pēc uzbrukuma atjaunota no rezerves kopijas. Datubāze veiksmīgi startējas un lietojumprogramma spēj parādīt klientu kontus. Tomēr kopijas izveides brīdī daļa transakciju vēl nebija sinhronizētas ar ārēju pakalpojumu. Ja šo neatbilstību nepārbauda, pēc darbības atsākšanas var parādīties dubulti maksājumi, kļūdaini atlikumi vai nekorekti dokumenti. Šis ir ilustratīvs scenārijs, nevis apraksts par konkrētu uzņēmumu. Tomēr tas parāda būtisku tehniskās un biznesa atkopšanās atšķirību. Serveris var būt pieejams, kamēr uzņēmumam vēl nav pietiekamu pierādījumu, ka drīkst atsākt visas operācijas.

NIST SP 800-34 Rev. 1 uzsver darbības ietekmes analīzes nozīmi, nosakot atkopšanās prioritātes un resursu vajadzības. Publikācija ir izstrādāta ASV federālajām informācijas sistēmām, tāpēc tās saturs nav automātiski uzskatāms par Latvijas uzņēmumiem juridiski saistošu prasību. Taču darbības ietekmes analīzes metodoloģija ir izmantojama arī citās organizācijās. S03

Atkopšanās plānos parasti izmanto divus būtiskus rādītājus — RTO (Recovery Time Objective) un RPO (Recovery Point Objective). Tie ļauj definēt pieļaujamās atkopšanās robežas, tomēr to interpretācijā nepieciešama precizitāte. RTO ir mērķis attiecībā uz laiku, kurā jāatjauno konkrēta sistēma vai funkcija pēc noteikta traucējuma. RPO raksturo pieļaujamo datu zudumu laika izteiksmē, nosakot, cik senam atjaunošanas punktam jābūt attiecībā pret traucējuma brīdi. RPO nav zaudēto ierakstu skaits, un tas pats par sevi nepierāda datu integritāti.

Svarīgi arī nošķirt izvirzītos mērķus no faktiskajiem rezultātiem. Ja atkopšanas plānā sistēmai noteikts četru stundu RTO, tas ir mērķis, nevis pierādījums, ka sistēmu iespējams atjaunot četrās stundās. Lai to apstiprinātu, nepieciešami testu vai reālas atkopšanās pierādījumi, kuros precīzi fiksēti sākuma un beigu nosacījumi. Pieņemsim, ka organizācija apgalvo: tās klientu portāla RTO ir četras stundas. Tehniskajā mācībā portāls kļūst pieejams pēc trim stundām. Vai mērķis sasniegts? Tas ir atkarīgs no definētajiem kritērijiem. Ja RTO noteikts tikai tehniskajai pieejamībai un šī funkcija ir atjaunota, tests var apliecināt attiecīgā mērķa sasniegšanu. Ja pieņemšanas kritēriji ietver arī autentifikāciju, darījumu apstrādi un ārējās integrācijas, nepieciešami papildu pierādījumi.

Tāpēc atkopšanās laiks jāsaista ar konkrētu funkciju un skaidru pieņemšanas nosacījumu. Pretējā gadījumā divi uzņēmumi ar identisku RTO vērtību var aprakstīt pilnīgi atšķirīgu atkopšanās gatavības līmeni.

Kāpēc RPO nav datu kvalitātes garantija?

Ja atjaunošanas punkts atbilst pieļaujamajam datu zuduma intervālam, tas vēl neapliecina, ka dati šajā punktā ir pareizi. Rezerves kopijā var būt nekonsekventas transakcijas, nekorekti konfigurācijas dati vai informācija, kas kompromitēta jau pirms kopijas izveides. Dažās sistēmās nepieciešama arī saskaņošana ar ārējiem ierakstiem, kuri turpina pastāvēt neatkarīgi no atjaunojamās datubāzes. Tādēļ es atsevišķi pārbaudītu vismaz datu atjaunošanas punkta atbilstību, struktūras integritāti, transakciju konsekvenci un biznesa procesu saskaņotību. Šīs ir atšķirīgas pārbaudes, un veiksmīgs rezultāts vienā no tām nepadara pārējās nevajadzīgas.

Kiberincidenta laikā ne vienmēr ir iespējams uzreiz noteikt brīdi, kad dati kļuvuši neuzticami. Ja uzbrucējam bijušas tiesības mainīt datubāzes ierakstus vai sistēmas konfigurāciju, var izrādīties, ka pēdējā rezerves kopija satur daļu kompromitētā stāvokļa. Sistēmu tehniski iespējams atjaunot no šādas kopijas, bet organizācija riskē atjaunot arī nekorektus datus vai ievainojamu konfigurāciju. Līdzīga problēma var rasties bez ļaunprātīgas datu mainīšanas. Ja incidenta laikā pārtrūkuši vairāki savstarpēji saistīti pakalpojumi, viena datubāze var būt atjaunota no agrāka punkta, kamēr cita saglabājusi jaunākus ierakstus. Katras sistēmas dati atsevišķi var būt tehniski korekti, taču to savstarpējā saskaņotība vairs nav garantēta.

Piemēram, noliktavas sistēmā prece jau norakstīta, bet pasūtījumu sistēmā tās izsniegšanas statuss pēc atjaunošanas atkal ir neizpildīts. Ja abas sistēmas atsāk darbu bez saskaņošanas, pastāv risks pasūtījumu apstrādāt atkārtoti. Tas var radīt finansiālas sekas arī tad, ja neviena datubāzes integritātes pārbaude nav uzrādījusi tehnisku bojājumu. Es prasītu dokumentētu datu saskaņošanas procedūru, kas katrai kritiskajai biznesa funkcijai nosaka kontrolsummas, ierakstu skaita vai summu salīdzinājumus, transakciju identifikatoru pārbaudi, ārējo avotu saskaņošanu un izņēmumu apstrādes kārtību. Konkrētās metodes jāizvēlas atbilstoši datu modelim un biznesa riskam. Vienkārša faila kontrolsumma var pierādīt attiecīgā faila nemainīgumu, bet tā viena pati nevar apliecināt darījuma ekonomisko pareizību.

Lai organizācijas nepārprastu savus atkopšanās ziņojumus, piedāvāju atšķirt piecus stāvokļus. Tas ir mans praktiskais novērtēšanas modelis, nevis ISO, NIST vai ENISA oficiāla klasifikācija.

Šie stāvokļi nav obligāti jāizpilda visā uzņēmumā vienlaikus. Atsevišķi pakalpojumi var sasniegt dažādus atkopšanās līmeņus. Turklāt pārbaudes daļēji var notikt paralēli, ja tas ir droši un ir skaidri pieņemšanas kritēriji. Tabulas mērķis ir novērst situāciju, kur vienas sistēmas tehniska pieejamība tiek neprecīzi pasniegta kā visa uzņēmuma darbības atjaunošana. Pēdējais stāvoklis nenozīmē, ka visi riski ir pilnībā novērsti. Dažkārt organizācijai jāatsāk darbs ar pagaidu kontrolēm, kamēr turpinās dziļāka incidenta izmeklēšana vai ilgtermiņa uzlabojumi. Taču šādai izvēlei jābūt pamatotai, dokumentētai un pieņemtai attiecīgā pilnvaru līmenī.

Apskatīsim hipotētisku ražošanas uzņēmumu, kura pasūtījumu un noliktavas sistēmas pārtraukušas darbu izspiedējprogrammatūras incidenta laikā. Uzņēmumam ir pieejamas rezerves kopijas, un IT komanda spēj izveidot jaunu infrastruktūru izolētā vidē. Sākotnējā atjaunošana izdodas. Serveri darbojas, lietojumprogrammas startējas un darbinieki var pieteikties. Taču drošības komanda vēl pārbauda, vai atjaunotajā konfigurācijā nav palikusi kompromitēta identitāte vai uzbrucēja izmainīti administratīvie mehānismi. Noliktavas sistēmas ieraksti atbilst rezerves kopijas stāvoklim, savukārt daļa pasūtījumu pēc kopijas izveides bija apstrādāti ārējā transporta pakalpojumā.

Ja uzņēmums nekavējoties atsāks visu operāciju apstrādi, var rasties neatbilstības pasūtījumu statusos un nosūtīto preču uzskaitē. Tāpēc procesa īpašnieks sākumā atļauj tikai ierobežotu darbu: jaunu pasūtījumu reģistrāciju bez automātiskas izpildes, kamēr iepriekšējie darījumi tiek saskaņoti. Paralēli IT un drošības komandas pārbauda atjaunotās vides konfigurāciju un piekļuves tiesības. Pēc saskaņošanas, funkcionālajiem testiem un atlikušo risku izvērtēšanas vadība apstiprina pāreju uz normālu darbības režīmu. Šajā gadījumā sistēmas tehniskā atjaunošana un uzņēmuma pilna darbspēja iestājas atšķirīgos brīžos. Tieši šī atšķirība jāatspoguļo atkopšanās pārskatos.

Scenārijs nav empīrisks incidents vai apgalvojums par kādu konkrētu uzņēmumu. Tas paredzēts pārbaudes metodes ilustrēšanai.

Atkopšanās pieņemšanas tests jāsāk ar skaidri definētu pakalpojumu, nevis ar serveru sarakstu. Piemēram, maksājumu apstrādes pakalpojuma atjaunošanai var būt nepieciešama lietotāja autentifikācija, darījuma pieņemšana, autorizācija, stāvokļa saglabāšana, saskaņošana ar ārējo sistēmu un korekta informācijas parādīšana lietotājam. Katram posmam jānosaka pārbaudāms rezultāts un pierādījuma iegūšanas veids. Atkopšanās pārbaudē būtiski izmantot kontrolētus testa darījumus vai citus drošus validācijas mehānismus, lai netiktu radīta nepamatota ietekme uz klientu datiem vai finansēm. Es izmantotu šādu pieņemšanas matricu:

Šī matrica nepretendē uz universālu sertifikācijas standartu. Atkarībā no nozares tai var būt nepieciešamas papildu prasības par funkcionālo drošību, personas datiem, medicīnisko informāciju, finanšu transakcijām vai citu īpaši aizsargājamu procesu integritāti.

Atkopšanās plāns nevar būt ticams, ja organizācija nav novērtējusi pašu rezerves kopiju kompromitēšanas risku. Izspiedējprogrammatūras uzbrukumos var tikt apdraudētas ne tikai darba sistēmas, bet arī kopiju pārvaldības konti, konfigurācijas un datu glabātuves. Tāpēc svarīgi atdalīt piekļuves tiesības, noteikt atbilstošus saglabāšanas periodus un nodrošināt tādu kopiju aizsardzību, kas atbilst organizācijas riskam. ENISA 2025. gada tehniskās ieviešanas vadlīnijas noteiktajām digitālās infrastruktūras un IKT pakalpojumu kategorijām apskata gan rezerves kopiju integritātes pārbaudi, gan nemaināmu vai bezsaistes kopiju izmantošanu. Tās arī iesaka darbības nepārtrauktības un atkopšanās plānošanu sasaistīt ar incidentu reaģēšanu un krīzes pārvaldību. S04

Nemaināma rezerves kopija tomēr automātiski nepierāda, ka tā satur pareizus datus. Ja kopija izveidota pēc nevēlamām izmaiņām, nemainīguma mehānisms var saglabāt arī nepareizu stāvokli. Tāpat ģeogrāfiski atdalītas kopijas vēl nenozīmē neatkarīgu atkopšanās spēju, ja piekļuve tām atkarīga no viena kompromitēta identitātes pakalpojuma vai vadības konta. Atkopšanās plānošanā jāpārbauda arī konfigurācijas, nepieciešamās programmatūras versijas, atslēgas, licences, ārējo piegādātāju iesaiste un administratīvā piekļuve. Ja uzņēmums spēj atjaunot datus, bet nevar iegūt nepieciešamās atslēgas vai izvietot lietojumprogrammu drošā vidē, tā atkopšanās spēja ir nepilnīga.

Direktīvas (ES) 2022/2555 jeb NIS2 21. panta otrās daļas c) punkts kiberdrošības risku pārvaldības pasākumu vidū ietver darbības nepārtrauktību, tostarp rezerves kopiju pārvaldību, katastrofu seku novēršanu un krīzes pārvaldību. Turpat minēta arī piegādes ķēdes drošība un kiberdrošības risku pārvaldības pasākumu efektivitātes izvērtēšana. Konkrētie pienākumi ir atkarīgi no piemērojamā regulējuma un subjekta statusa. S05 Komisijas Īstenošanas regula (ES) 2024/2690 noteiktām digitālās infrastruktūras, IKT pakalpojumu un citām tajā norādītajām subjektu kategorijām nosaka konkrētākas tehniskās un metodoloģiskās prasības. Regulas pielikuma 4.1. sadaļā paredzēti darbības nepārtrauktības un katastrofu seku novēršanas plāni, darbības ietekmes analīze un šo plānu testēšana, pārskatīšana un atjaunināšana. Savukārt 4.2. sadaļa ietver prasības rezerves kopiju pārvaldībai, datu pilnīgumam un precizitātei, glabāšanas drošībai un integritātes pārbaudēm. S06

Šīs regulas detalizētās prasības nedrīkst automātiski attiecināt uz pilnīgi visiem uzņēmumiem vai visām NIS2 nozarēm. Piemērošanas tvērums jānosaka atsevišķi. ISO 22301:2019, kam ir 2024. gada grozījums, savukārt nosaka darbības nepārtrauktības pārvaldības sistēmas prasību ietvaru. Tas ir starptautisks standarts, kura piemērošanas un sertifikācijas jautājumi jānošķir no tiesību aktos tieši noteiktajiem pienākumiem. Raksta sagatavošanas brīdī ISO publicētajā informācijā nākamā standarta redakcija vēl ir izstrādes stadijā. S02 Praktiskais secinājums ir tāds, ka atkopšanās nedrīkst palikt tikai tehniskas nodaļas iekšējais jautājums. Ir nepieciešama sasaite starp informācijas sistēmu atjaunošanu, biznesa procesu prioritātēm, atbildības sadalījumu un pierādījumiem par to, ka organizācija spēj turpināt savas būtiskās funkcijas.

Atkopšanās pārbaudei jābūt pietiekami līdzīgai faktiskajai darbības videi, lai no rezultāta varētu izdarīt pamatotus secinājumus. Ja tests notiek ar ievērojami mazāku datu apjomu, vienkāršotām integrācijām vai iepriekš sagatavotu vidi, tā rezultātus nevar bez papildu pamatojuma attiecināt uz pilnu produkcijas vidi. Es ieteiktu sākt ar vienu kritisku biznesa procesu, noteikt tā pieņemšanas kritērijus un pēc tam izvēlēties ticamu incidenta scenāriju. Piemēram, primārā sistēma ir nepieejama, rezerves kopijas administrēšanas vide jāuzskata par potenciāli kompromitētu, un atjaunošana jāveic atsevišķā, kontrolētā infrastruktūrā. Šādu pārbaudi var organizēt, nepārtraucot produkcijas darbību, ja ir sagatavota atbilstoša izolēta vide un pārbaudes dati.

Testa laikā jāmēra ne tikai serveru atjaunošanas laiks, bet arī brīdis, kad ir pieejams konkrētais biznesa pakalpojums ar noteikto funkcionalitāti. Atsevišķi jāfiksē datu atjaunošanas punkts, neatbilstību skaits, nepieciešamā manuālā datu saskaņošana, piegādātāju iesaistes laiks un cilvēku vai piekļuves tiesību ierobežojumi. Ja tests neizdodas, tas nav iemesls slēpt rezultātu. Tieši neveiksmīga pārbaude var atklāt kritiskas atkarības, kuras nav redzamas parastā darbības režīmā. Tomēr jābūt noteiktam, kā nepilnības tiek novērstas un kad tās pārbaudīs atkārtoti. Bez atkārtotas pārbaudes arī labi sagatavots uzlabojumu plāns vēl nepierāda efektīvāku atkopšanās spēju.

NIST SP 800-184 uzsver atkopšanās plānošanu, praktisku scenāriju izmantošanu un uzlabošanu pēc iegūtās pieredzes. Šī pieeja ir vērtīga arī tad, ja uzņēmums izmanto citus standartus vai savu iekšējo darbības nepārtrauktības pārvaldības modeli. S01

Rezerves kopijas atjaunošanas protokols nav pietiekams pierādījums, ka organizācija atjaunojusi pakalpojumu. Izvēlētos vienu klientam nozīmīgu procesu un pārbaudītu tā izpildi no sākuma līdz beigām: pieprasījuma pieņemšanu, autorizāciju, datu izmaiņu, ārējās sistēmas atbildi un korekta rezultāta atgriešanu. Vērtējums jāveic arī gadījumā, kad lietotājs atkārto darbību, kas incidenta laikā šķita neveiksmīga. Divreiz izpildīts maksājums vai atkārtoti izveidots ieraksts var būt ievērojami problemātiskāks par skaidri redzamu nepieejamību. Šādu testu nevar aizstāt ar servera darbspējas indikatoru. Vajadzīgs zināms sākuma datu stāvoklis, kontrolēta testu kopa, sagaidāmo rezultātu uzskaite un procesu īpašnieku apstiprinājums. Ja daļa vēsturisko notikumu pēc atjaunošanas vēl nav savietoti, to fiksētu kā atvērtu atkopšanas ierobežojumu, nevis paslēptu zem statusa «serviss darbojas». Atkopšanās pabeigšana ir pierādāms pakalpojuma un datu korektuma stāvoklis, kam vajadzīgas vairākas neatkarīgas pārbaudes.

Šeit svarīgi nošķirt vadlīniju tvērumu no organizācijas konkrētajiem pienākumiem. NIST SP 800-34 Rev. 1 darbības ietekmes analīzes pieeja ir izmantojama kā plānošanas metode, taču pati par sevi tā nenosaka katra Latvijas uzņēmuma obligāto atkopšanās modeli. Tāpat tehniskās atjaunošanas protokols neapliecina biznesa atjaunošanos, ja nav pārbaudīta datu saskaņotība, ārējās integrācijas un kritisko procesu faktiska izpilde.

Atkopšanās gatavību nevar objektīvi novērtēt tikai pēc rezerves kopiju skaita, veiksmīgu kopēšanas uzdevumu īpatsvara vai serveru atjaunošanas ilguma. Šie dati ir noderīgi, taču tie aptver tikai daļu no organizācijas spējas atsākt darbu pēc nopietna kiberincidenta. Būtiski ir arī atjaunoto datu stāvoklis, kritisko biznesa funkciju pareizība, ārējo integrāciju darbība un pierādījumi par atjaunotās vides drošību. Es prasītu, lai katram būtiskam pakalpojumam būtu skaidri pieņemšanas kritēriji. Tiem jānosaka, kā pārbaudīt datu pareizību, darbības scenārijus, atkopšanās laiku un atlikušos riskus. Tikai pēc šo pierādījumu izvērtēšanas pilnvarotā persona var pieņemt pamatotu lēmumu par normāla darbības režīma atsākšanu.

Ja uzņēmuma atkopšanās pārskatā redzams tikai serveru statuss, tajā joprojām trūkst atbildes uz svarīgāko jautājumu: vai uzņēmums atkal spēj droši un korekti izpildīt savas saistības pret klientiem, darbiniekiem un sadarbības partneriem?