Backup Infrastructure Hardening – Deo 3: Testiranje i verifikacija backup-a

Prva dva dela serije postavila su arhitekturu i zaštitu od ransomware-a. Ovaj deo se bavi poslednjom, i možda najčešće zapostavljenom cifrom u 3-2-1-1-0 okviru iz prvog dela serije — onom "0". Nula grešaka, potvrđenih testiranjem, nije opciona stavka na kraju liste — to je jedini način da se ostatak strategije, ma koliko pažljivo osmišljen, pretvori iz teorije u nešto na šta se organizacija stvarno može osloniti u trenutku krize.

Zašto "backup zadatak je prošao uspešno" nije isto što i "backup radi"

Ovo je razlika koja zaslužuje eksplicitno objašnjenje, jer je uzrok najvećeg broja neprijatnih iznenađenja u praksi. Standardni backup softver prijavljuje "uspeh" kad se proces kopiranja podataka završi bez greške — fajl je pročitan, prenet, i zapisan na odredište. Ovo ne dokazuje ništa o tome da li se taj isti podatak može uspešno pročitati nazad, da li je aplikacija koja ga koristi u stanju da ga ispravno interpretira, ili da li ceo lanac (backup, prenos, skladištenje, enkripcija, ključevi) zaista funkcioniše od početka do kraja. "Zadatak je prošao zeleno" i "podaci se mogu stvarno vratiti u upotrebu" su dva različita tvrđenja, i samo drugo od njih ima stvarnu vrednost u trenutku krize.

Vredi dodati i drugu, srodnu razliku: immutability, detaljno obrađena u drugom delu serije, štiti postojeću kopiju od brisanja ili izmene — ali ne dokazuje ništa o tome da li su podaci unutar te kopije ispravni. Nepromenljiv, ali oštećen ili nekompletan backup ostaje nepromenljiv, oštećen i nekompletan backup. Ova dva koncepta — zaštita od uništavanja i potvrda ispravnosti sadržaja — rešavaju različite probleme, i oba moraju biti pokrivena.

Slojevit pristup testiranju — od lakog i čestog do punog i retkog

Realan, održiv program testiranja ne znači da se svaki test mora izvoditi na najvišem, najskupljem nivou. Praktičan pristup kombinuje nekoliko slojeva različite dubine i učestalosti, gde lakši, jeftiniji testovi rade često i automatski, dok najdublji, najskuplji testovi rade ređe, ali sa punom ozbiljnošću.

Šta treba uraditi

• Uključiti automatizovanu proveru integriteta (checksums/hash verifikacija) kao svakodnevni, potpuno automatizovan sloj — ovo otkriva tihu korupciju podataka (bitrot, greške u prenosu) rano, pre nego što restauracija postane hitno potrebna, isti princip opisan za verify zadatke kroz MSSQL i Proxmox serije na ovom blogu
• Sprovoditi granularne, ciljane provere sadržaja gde platforma to dozvoljava — direktan upit nad backup podacima (npr. provera da konkretna tabela, šema ili zapis postoji i ima očekivan sadržaj) bez potrebe za punom restauracijom, čime se validacija pretvara iz retkog, skupog događaja u kontinuiranu, jeftiniju proveru
• Sprovoditi periodične restore testove na nivou pojedinačnog fajla ili objekta — brz, jeftin test koji potvrđuje da se osnovna operacija vraćanja podataka zaista izvršava ispravno, bez punog obima punog sistemskog testa
• Rezervisati pune, sistemske restore testove (ceo VM, cela baza, cela aplikacija sa svim zavisnostima) za manje čest, ali dublji ciklus — kvartalno je čest, razuman polazni obrazac, prilagođen kritičnosti konkretnog sistema opisanoj kroz RPO/RTO planiranje iz prvog dela serije

Napomena o riziku: oslanjanje isključivo na automatizovanu proveru integriteta bez ikad sprovedenog stvarnog restore testa ostavlja rupu koju checksum provera ne pokriva — mogućnost da se ceo proces restauracije (ne samo sami podaci) pokvari usled promene infrastrukture, isteka sertifikata, zaboravljene lozinke ili nekompatibilne verzije softvera. Slojevit pristup postoji upravo zato što nijedan pojedinačan nivo testiranja sam po sebi ne pokriva sve moguće načine na koje backup može zakazati.

Izolovano test okruženje — testiranje bez rizika za produkciju

Restore test koji se izvodi direktno preko postojećih, aktivnih produkcionih podataka nosi očigledan rizik — greška u samom testu može oštetiti ono što je test trebalo da proveri. Standardna, ispravna praksa je izvođenje restauracije u potpuno odvojenom, izolovanom okruženju (sandbox), koje liči na produkciju dovoljno da test bude realan, ali je mrežno i sistemski odvojeno tako da ništa iz tog procesa ne može uticati na stvarnu produkciju.

Šta treba uraditi

• Održavati dedikovano, izolovano test okruženje za restore testove — ovo ne mora biti trajno, potpuno duplirana produkcija, ali treba da bude dovoljno slično (ista verzija operativnog sistema, iste zavisnosti aplikacije) da test stvarno otkrije probleme koji bi se desili i u pravoj restauraciji
• Mrežno izolovati test okruženje od produkcije tokom testa, posebno ako se testira restauracija VM-ova ili sistema koji bi, ako bi slučajno dobili mrežnu vidljivost ka produkciji, mogli izazvati sukobe (duplirane IP adrese, konfliktni servisi na istoj mreži)
• Za organizacije sa dovoljno resursa, razmotriti "paralelno" testiranje — obnavljanje sistema u odvojenom okruženju dok produkcija nastavlja normalno da radi, umesto testova koji zahtevaju privremeni prekid produkcije radi testiranja failover-a
• Automatizovati podizanje i rušenje test okruženja gde je moguće, kako sam proces testiranja ne bi zahtevao veliki ručni napor svaki put — trošak ručnog rada je čest, praktičan razlog zašto se testiranje odlaže ili preskače, i automatizacija direktno rešava taj problem

Testiranje na tri nivoa dubine

Vredi razlikovati tri različita nivoa na kojima restauracija treba biti proverena, jer uspeh na jednom nivou ne garantuje uspeh na drugom. Nivo fajla potvrđuje da se pojedinačni podaci mogu izvući i pročitati. Nivo aplikacije potvrđuje da aplikacija koja koristi te podatke zaista radi ispravno nakon restauracije — baza podataka koja se uspešno restaurirala, ali čija aplikacija ne može da joj se poveže zbog promenjene konfiguracije, i dalje predstavlja neuspeh sa poslovne tačke gledišta. Nivo celog sistema potvrđuje da čitava zavisna celina — server, mreža, više povezanih aplikacija — funkcioniše zajedno posle pune restauracije.

Šta treba uraditi

• Definisati za svaki kritičan sistem koji nivo dubine testiranja je stvarno relevantan, na osnovu njegove arhitekture — jednostavan, samostalan fajl server možda zahteva samo nivo fajla, dok višeslojna aplikacija sa bazom, aplikativnim serverom i zavisnim servisima zahteva testiranje na nivou celog sistema da bi test imao stvarnu vrednost
• Ne zaustavljati se na potvrdi da se sistem "pokreće" (boot) nakon restauracije — proveriti da su aplikacije, baze podataka, i zavisni servisi zaista funkcionalni, ne samo da je operativni sistem uspešno startovao
• Za višeslojne sisteme, testirati ceo lanac zavisnosti zajedno bar povremeno (kao deo punog, kvartalnog testa opisanog ranije u tekstu), ne samo svaku komponentu izolovano — greška se često javlja upravo na granici između komponenti (npr. promenjena mrežna adresa nakon restauracije koja prekida vezu između aplikacije i baze), ne unutar bilo koje pojedinačne komponente

Dokumentovanje kao deo samog testa, ne kao naknadna administracija

Test koji se izvede, ali čiji rezultati nisu zabeleženi, gubi veći deo svoje vrednosti — ne postoji način da se prati trend (da li se RTO pogoršava tokom vremena), ne postoji dokaz za auditora ili osiguravajuće društvo da je proces stvarno sproveden, i ne postoji osnova za poređenje sa prethodnim testovima radi otkrivanja obrazaca.

Šta treba uraditi

• Beležiti za svaki test: datum, koji sistem je testiran, izmereno stvarno vreme restauracije (uporediti sa dokumentovanim RTO ciljem iz prvog dela serije), da li je test uspeo u potpunosti, i svaki problem koji je otkriven
• Čuvati istorijske zapise testova na centralnoj, lako pretraživoj lokaciji — ovo postaje direktan, konkretan dokaz spremnosti za auditore, regulatore, ili osiguravajuća društva koja sve češće zahtevaju upravo ovakvu dokumentaciju kao uslov pokrića za kibernetičko osiguranje
• Tretirati svaki neuspešan ili delimično uspešan test kao priliku za poboljšanje procesa, ne kao izolovan, jednokratan problem — ako je restauracija otkrila da RTO cilj nije realan, ili da je konfiguracija zastarela, to je informacija koju treba uneti nazad u ažuriranje procedure, ne samo ispraviti za taj jedan test i zaboraviti
• Ažurirati dokumentaciju procedure restauracije nakon svakog testa koji otkrije razliku između onoga što je dokumentovano i onoga što je stvarno bilo potrebno uraditi — procedura koja ne odražava stvarno stanje infrastrukture je jednako beskorisna kao i backup koji se nikad nije testirao

Napomena o riziku: dokumentacija testiranja koja postoji isključivo radi "kvačice" u audit izveštaju, bez stvarne namere da se otkriveni problemi zaista isprave, stvara lažan osećaj spremnosti opasniji od potpunog odsustva testiranja — organizacija veruje da je spremna, dok stvarno stanje govori suprotno. Test ima vrednost samo ako njegovi rezultati stvarno utiču na sledeći korak, ne samo ako formalno postoji zapisnik da je izveden.

Ovim se zaokružuje osnovni, platformski-nezavisni deo serije o backup infrastrukturi — arhitektura, zaštita od ransomware-a, i disciplina testiranja koja sve to potvrđuje ili opovrgava. Poslednji deo serije prelazi na konkretnu platformu — Veeam Backup & Replication — i pokazuje kako se principi opisani kroz prethodna tri dela prevode u stvarna, specifična podešavanja unutar te platforme.