Kā pārbaudīt, vai rezerves kopijas tiešām strādā

Kāpēc kopēšanas žurnāls neko nepierāda

Izplatītākais scenārijs izskatās šādi: kopijas notiek pēc grafika, indikators ir zaļš, bet atjaunošanas brīdī izrādās, ka datubāzes izgāzums ir nepilnīgs, ka trūkst konfigurācijas failu vai ka arhīvs ir bojāts. Kopēšanas darbs izpildījās veiksmīgi – tas vienkārši nekopēja to, kas vajadzīgs.

Klusās kļūmes ir tik izplatītas, ka par tām ir vērts domāt kā par noklusējumu, ne izņēmumu. Tipiskie iemesli: jauns serveris netika pievienots kopēšanas darbam, mainījās datubāzes ceļš, beidzās vieta krātuvē, mainīta parole servisa kontam, vai kopija tiek veidota atvērtiem failiem bez momentuzņēmuma.

RTO un RPO: divi skaitļi, kas nosaka visu pārējo

Pirms testēšanas ir vērts fiksēt, ko vispār mēra. NIST vadlīnijās SP 800-34 (Rev. 1) šie divi rādītāji definēti precīzi. RTO (Recovery Time Objective) ir maksimālais laiks, cik ilgi sistēmas resurss drīkst būt nepieejams, pirms iestājas nepieņemama ietekme uz procesiem. RPO (Recovery Point Objective) ir brīdis pirms traucējuma, uz kuru datus var atgriezt, ņemot vērā jaunāko rezerves kopiju – tas ir, cik daudz datu drīkst zaudēt.

Praktiski RPO nosaka kopēšanas biežumu, bet RTO – atjaunošanas infrastruktūru. Ja RPO ir viena stunda, ikdienas kopija to nekad neizpildīs. Ja RTO ir četras stundas, bet pilna atjaunošana no lentes aizņem divas dienas, mērķis nav sasniedzams neatkarīgi no tā, cik labas ir kopijas. Testēšana ir vienīgais veids, kā uzzināt, vai reālie skaitļi atbilst mērķiem.

Ko prasa Latvijas regulējums

Regulētajiem subjektiem pārbaude nav ieteikums. Ministru kabineta noteikumu “Minimālās kiberdrošības prasības” 74. punkts nosaka, ka kiberdrošības pārvaldnieks nodrošina ikdienas rezerves kopiju sagatavošanas uzraudzību un rezerves kopiju nolasīšanas pārbaudi izlases kārtā izvēlētai informācijas sistēmai, informācijas resursam vai tehniskā resursa konfigurācijai. Pārbaudi veic ne retāk kā reizi sešos mēnešos A klases informācijas sistēmai un ne retāk kā reizi gadā B klases sistēmai vai pēc būtiskām izmaiņām.

Noteikumu 73. punkts papildus prasa iekšējos dokumentos noteikt kārtību, kādā pārbauda, vai, izmantojot rezerves kopijas, iespējams atjaunot informācijas resursus un sistēmas darbību, kā arī atbildīgos par kopiju pārvaldību. Savukārt 41.4. apakšpunkts paredz, ka kiberrisku pārvaldības un IKT darbības nepārtrauktības plānā iekļauj nepārtrauktības raksturlielumus – kā piemēri minēti RPO, RTO un maksimāli pieļaujamais dīkstāves laiks (MTD) – kopā ar to uzraudzības metodiku – tātad šie rādītāji ir jāizmēra, ne tikai jādeklarē.

Testēšanas līmeņi

Kā veikt testu

1. Izvēlies mērķi nejauši. Vienmēr testējot vienu un to pašu sistēmu, tiek pārbaudīta viena un tā pati konfigurācija.
2. Atjauno atsevišķā vidē. Nekad ne virsū strādājošai sistēmai – tests nedrīkst radīt incidentu.
3. Pārbaudi saturu, ne tikai esamību. Atver failus, palaid vaicājumu, salīdzini ierakstu skaitu ar oriģinālu.
4. Mēri laiku. Cik ilgi aizņēma katrs solis – tas ir tavs reālais RTO, nevis tas, kas rakstīts plānā.
5. Testē bez galvenā speciālista. Ja atjaunot spēj tikai viens cilvēks, tas ir atsevišķs risks.
6. Pārbaudi arī atslēgas. Šifrēta kopija bez pieejamas atšifrēšanas atslēgas ir tikpat nederīga kā šifrēts oriģināls.
7. Dokumentē rezultātu. Datums, sistēma, ilgums, problēmas, atbildīgais par novēršanu.
8. Novērs atrastās problēmas un atkārto testu – nepārbaudīts labojums ir tikai hipotēze.

Ko fiksēt par katru testu

Testa vērtība lielā mērā ir tā pieraksts. Ja katrs tests tiek dokumentēts vienādi, pēc gada ir redzama tendence – vai atjaunošanas laiks samazinās, vai problēmas atkārtojas un vai aptvērums aug. Ja pieraksta nav, katrs tests sākas no nulles, un auditam nav ko parādīt.

• Datums, testētā sistēma un kopijas datums, no kuras atjaunots.
• Atjaunošanas ilgums pa soļiem: sagatavošana, pārsūtīšana, atjaunošana, pārbaude.
• Vai tika sasniegts plānotais RTO un RPO; ja nē – cik liela ir starpība.
• Kas tika pārbaudīts pēc atjaunošanas un ar kādu rezultātu.
• Atrastās problēmas, atbildīgais par katru un novēršanas termiņš.
• Kas testu veica – un vai viņš to spēja izdarīt bez ārējas palīdzības.

Ja tests neizdodas

Neizdevies tests ir labākais iespējamais rezultāts – tas ir atklājums, kas maksāja dažas stundas, nevis nedēļu. Pareizā reakcija ir noskaidrot, vai problēma ir konkrēta un vienreizēja vai sistēmiska. Ja trūka viena datubāzes izgāzuma, tas ir konfigurācijas labojums; ja izrādās, ka jaunās sistēmas kopēšanas darbam netiek pievienotas vispār, jālabo process, kurā sistēmas tiek nodotas ekspluatācijā.

Otrs jautājums pēc neizdevusies testa ir vismaz tikpat svarīgs, un tas ir jāuzdod uzreiz: cik ilgi šī problēma jau pastāvēja? Ja pēdējā veiksmīgā atjaunošana bija pirms gada, tad gadu uzņēmums darbojās bez reālas rezerves kopijas, to nezinot. Tieši šī atbilde parasti pārliecina vadību, ka pārbaudēm jānotiek biežāk un ka tās nav birokrātisks pienākums, bet vienīgais veids uzzināt patieso stāvokli.

Ko pārbaudīt papildus

• Nemaināmību. Pamēģini dzēst kopiju ar administratora kontu – ja izdodas, tā nav aizsargāta pret izspiedējvīrusu.
• Brīdinājumus. Apzināti pārtrauc vienu kopēšanas darbu un pārliecinies, ka paziņojums tiešām pienāk cilvēkam.
• Glabāšanas termiņus. Vai vecākā kopija ir tik veca, cik domā? Politika un faktiskā konfigurācija bieži atšķiras.
• Aptvērumu. Salīdzini sistēmu sarakstu ar kopēšanas darbu sarakstu; jaunas sistēmas bieži paliek ārpusē.
• Atjaunošanu no vecākas kopijas. Ne tikai no jaunākās – pēc uzbrukuma bieži vajadzēs tieši veco.

Biežākās kļūdas

• Testē tikai jaunāko kopiju. Pēc izspiedējvīrusa uzbrukuma jaunākā parasti ir tā, kuru nedrīkst izmantot.
• Testē vienmēr to pašu sistēmu. Rezultāts ir pārliecība par vienu sistēmu un nezināšana par pārējām.
• Netiek mērīts laiks. Bez izmērīta RTO plānā ierakstītais skaitlis ir vēlējums.
• Rezultāts netiek dokumentēts. Nākamajā auditā vai incidentā nav ne pierādījuma, ne salīdzinājuma.
• Problēmas paliek nenovērstas. Tests, pēc kura nekas nemainās, ir tikai laika patēriņš.

Ja pārbaude atklāj, ka kopijas nav aizsargātas pret dzēšanu no darba vides, risinājums ir kopiju stratēģijā, ne testēšanas biežumā – to aprakstām ceļvedī par 3-2-1 principu.