Backup Infrastructure Hardening – Deo 1: Arhitektura i strategija backup-a

Ovim tekstom počinje nova serija posvećena backup infrastrukturi kao samostalnoj temi. Backup je bio prisutan kroz gotovo svaku prethodnu seriju na ovom blogu — MSSQL, Hyper-V, VMware, Proxmox — uvek kao deo šire priče o hardeningu konkretne platforme. Ova serija okuplja te principe u jednu, samostalnu celinu, i produbljuje ih dalje nego što je prostor u prethodnim serijama dozvoljavao. Prvi deo postavlja osnovu — arhitekturu i strategiju, pre nego što u narednim delovima pređemo na konkretnu zaštitu od ransomware-a, testiranje, i naposletku Veeam kao konkretnu platformu.

Zašto arhitektura dolazi pre alata

Čest, razumljiv refleks je krenuti od pitanja "koji alat da koristimo za backup" pre nego što se uopšte odgovori na pitanja koja alat treba da opsluži — koliko podataka smemo da izgubimo, koliko brzo moramo da se vratimo u pogon, i koliko nezavisnih kopija treba da postoji da bi organizacija preživela realan scenario napada. Alat bez jasno definisane arhitekture iza sebe je kao pažljivo odabran zamak na vratima kuće čiji plan još nije nacrtan — tehnički ispravan izbor, primenjen na pogrešnom mestu u procesu.

RPO i RTO — dva broja koja moraju postojati pre bilo koje tehničke odluke

Ova dva pojma se često pominju zajedno, ali mere različite stvari, i vredi ih jasno razgraničiti. Recovery Point Objective (RPO) odgovara na pitanje "koliko podataka smemo da izgubimo", izraženo kao vremenski period — RPO od četiri sata znači da je prihvatljivo izgubiti do četiri sata rada u slučaju incidenta, jer se poslednji backup pre incidenta desio negde unutar tog prozora. Recovery Time Objective (RTO) odgovara na drugo pitanje — "koliko dugo sistem sme da bude nedostupan pre nego što to postane neprihvatljivo za poslovanje", izraženo takođe kao vremenski period, ali merenim od trenutka incidenta do trenutka kad je sistem ponovo u funkciji.

Razlika u praksi je bitna jer diktira potpuno različite tehničke odluke. Nizak RPO (npr. nekoliko minuta) zahteva učestalo, granularno praćenje izmena — često kroz Continuous Data Protection ili blok-nivo inkrementalni pristup — dok RPO od 24 sata dozvoljava jednostavan, noćni ciklus pun backup-a. Nizak RTO zahteva brz put do funkcionalnog sistema — često kroz mogućnost pokretanja radnog opterećenja direktno iz backup skladišta, bez potpune restauracije unapred — dok viši RTO dozvoljava sporiji, jednostavniji, ali manje skup proces oporavka.

Šta treba uraditi

• Za svaki značajan sistem (ne za infrastrukturu uopšteno, već za svaki konkretan servis, bazu, ili aplikaciju) definisati RPO i RTO kao svesnu, dokumentovanu odluku doneta zajedno sa poslovnim vlasnikom tog sistema, ne kao tehnički parametar koji IT tim sam procenjuje
• Prihvatiti da različiti sistemi zaslužuju različite RPO/RTO vrednosti — sistem za obradu porudžbina u realnom vremenu zaslužuje znatno strože ciljeve od internog wiki servera, i primena istog, jedinstvenog standarda na sve podjednako obično znači ili preterano trošenje resursa na manje kritične sisteme, ili nedovoljnu zaštitu kritičnih
• Meriti stvarne, izmerene vrednosti nakon svakog testa restauracije (obrađenog detaljnije u trećem delu serije) i porediti ih sa definisanim ciljevima — dokumentovan RTO od jednog sata koji se u praksi pokazuje kao četiri sata je informacija koja zahteva ili izmenu procesa, ili iskreno preispitivanje da li je taj cilj realan
• Ponovo proceniti RPO/RTO vrednosti periodično, jer se poslovna zavisnost od pojedinih sistema menja tokom vremena — sistem koji je pre dve godine bio sporedan može danas biti kritičan, i obrnuto

3-2-1-1-0 — evolucija starog, dobro poznatog pravila

Klasično 3-2-1 pravilo — tri kopije podataka, na dva različita tipa medija, sa jednom kopijom van glavne lokacije — formulisano je sredinom 2000-ih kao odgovor na "obične" rizike gubitka podataka: kvar diska, požar, krađa opreme. Logika je jednostavna i i dalje tačna: eliminiše jedinstvenu tačku otkaza tako da nijedan pojedinačan događaj ne može uništiti sve kopije odjednom.

Ono što klasično 3-2-1 pravilo nije predvidelo jeste protivnik koji aktivno cilja same backup kopije — savremeni ransomware koji, kao što smo detaljno opisali kroz Proxmox i druge serije na ovom blogu, sistematski traži i uništava backup infrastrukturu pre nego što aktivira enkripciju produkcionih sistema. Protiv ovakvog, namernog, inteligentnog protivnika, tri kopije na dva medija nisu dovoljne ako sve tri ostaju dostupne (i time brisive) istom kompromitovanom administratorskom nalogu. Otuda proširenje na 3-2-1-1-0: dodatna "1" za bar jednu nepromenljivu (immutable) ili potpuno odvojenu (air-gapped) kopiju, i "0" kao cilj — nula grešaka potvrđenih kroz redovno, automatizovano testiranje restauracije.

Šta treba uraditi

• Održavati najmanje tri kopije svakog kritičnog skupa podataka — proizvodna kopija se ne računa kao "backup", već kao izvor koji se štiti
• Koristiti dva različita tipa medija ili skladišnog sistema za te kopije (npr. lokalni disk/NAS i cloud object storage, ili disk i LTO traka) — ovo štiti od scenarija u kojem greška specifična za jedan tip tehnologije (firmver bug, greška u konkretnom storage sistemu) pogodi sve kopije istovremeno
• Držati bar jednu kopiju fizički ili mrežno van glavne lokacije — različit data centar, različita geografska regija, u svakom slučaju van dometa istog lokalnog incidenta (požar, poplava, regionalni nestanak struje)
• Obezbediti bar jednu nepromenljivu ili potpuno van-mrežnu (offline/air-gapped) kopiju, dizajniranu tako da čak ni administrator sa punim, kompromitovanim kredencijalima ne može da je izmeni ili obriše pre isteka definisanog perioda zadržavanja — detaljnije mehanizme za ovo obrađujemo u drugom delu serije
• Sprovoditi redovno, automatizovano testiranje restauracije sa ciljem nula grešaka, tretirajući svaku otkrivenu grešku kao signal koji zahteva istragu, ne kao statistički šum koji se ignoriše dok ne postane hitan problem

Napomena o riziku: ambiciozno postavljen 3-2-1-1-0 okvir bez realnog plana za njegovo održavanje (ko prati testove, ko reaguje na greške, ko ažurira dokumentaciju kad se infrastruktura promeni) brzo degradira u formalnost — jedan uspešno postavljen sistem koji se posle prve godine niko ne dotiče. Sprovoditi ovo kao živ proces sa jasno imenovanim vlasnikom, ne kao jednokratan projekat koji se "završi" i posle toga zaboravi.

Tipovi backup-a — trade-off između brzine, prostora i vremena oporavka

Nekoliko osnovnih pristupa pravljenju backup-a nosi različite kompromise, i vredi ih razumeti pre nego što se izabere kombinacija za konkretno okruženje. Pun (full) backup kopira sav sadržaj svaki put — najjednostavniji za restauraciju (jedna kopija, jedan korak), ali najzahtevniji po prostoru i vremenu izvršavanja. Inkrementalni backup kopira samo ono što se promenilo od poslednjeg backup-a bilo kog tipa — najmanji i najbrži za izvršavanje, ali restauracija zahteva ceo lanac (poslednji pun backup plus svaki inkrementalni backup od tada), što produžava vreme oporavka i uvodi više tačaka gde bi greška mogla da naruši ceo lanac. Diferencijalni backup kopira sve promenjeno od poslednjeg punog backup-a (ne od poslednjeg bilo kog backup-a) — kompromis između ova dva, gde restauracija zahteva najviše dva koraka (pun plus najnoviji diferencijalni), po cenu većeg prostora od čistog inkrementalnog pristupa.

Continuous Data Protection (CDP) predstavlja poseban, agresivniji pristup — beleži izmene gotovo u realnom vremenu, umesto u diskretnim, zakazanim ciklusima, omogućavajući izuzetno nizak RPO (mereno u sekundama ili minutima, ne satima), po ceni znatno veće tehničke i finansijske složenosti, opravdane isključivo za sisteme čiji poslovni značaj to zaista zahteva.

Šta treba uraditi

• Kombinovati tipove backup-a prema stvarnoj potrebi svakog sistema, ne primenjivati isti pristup univerzalno — tipičan, razuman obrazac je periodičan pun backup (npr. nedeljno) uz svakodnevne inkrementalne ili diferencijalne backup-e između njih
• Rezervisati CDP isključivo za sisteme sa dokumentovano niskim RPO zahtevom (opisanim ranije u tekstu) — primena CDP-a univerzalno, "da bude sigurnije", nepotrebno troši resurse i komplikuje infrastrukturu bez odgovarajuće poslovne koristi
• Prilagoditi učestalost backup-a kritičnosti podataka — misija-kritični sistemi zaslužuju intervale merene u minutima, operativni podaci sat do nekoliko sati, a arhivski, ređe menjani podaci mogu ostati na dnevnom ciklusu
• Voditi računa o dužini lanca kod inkrementalnog pristupa — vrlo dug lanac inkrementalnih backup-a (npr. mesec dana bez ijednog novog punog backup-a) povećava rizik da oštećenje bilo koje karike u lancu ugrozi mogućnost restauracije do te tačke; periodično "resetovati" lanac novim punim backup-om, ne dozvoliti mu da raste neograničeno

SaaS podaci — često zaboravljena, a rastuća kategorija

Vredi eksplicitno pomenuti kategoriju koja se lako previdi pri planiranju backup strategije: podaci u SaaS platformama poput Microsoft 365, Google Workspace, ili sličnim servisima. Model deljene odgovornosti (shared responsibility model) koji ovi provajderi primenjuju znači da oni garantuju dostupnost same platforme i infrastrukture, ali ne i zaštitu od gubitka podataka izazvanog greškom korisnika, zlonamernim brisanjem od strane kompromitovanog naloga, ili istekom retencije u sopstvenim, ograničenim mehanizmima provajdera (kante za smeće, verzionisanje) koje nisu dizajnirane kao pravi backup sistem.

Šta treba uraditi

• Tretirati podatke u SaaS platformama kao punopravan deo backup strategije, ne kao nešto što je "već pokriveno" samim tim što podaci žive u cloud-u kod velikog provajdera
• Uvesti namensko, treće-stranačko rešenje za backup SaaS podataka, sa nezavisnim, dokumentovanim retencionim periodom koji ne zavisi od podrazumevanih mehanizama same platforme
• Uključiti SaaS podatke u isti 3-2-1-1-0 okvir opisan ranije u tekstu, uključujući periodično testiranje restauracije — vraćanje izbrisanog naloga, mejlbox-a ili SharePoint sajta treba biti testirano isto ozbiljno kao i restauracija bilo kog drugog kritičnog sistema

Sledeći deo serije prelazi na konkretnu zaštitu backup infrastrukture od ransomware napada — immutability mehanizme, air-gap arhitekture, i pristupnu kontrolu specifično dizajniranu da backup preživi čak i scenario u kojem napadač dobije pun administratorski pristup ostatku infrastrukture.