Backup Infrastructure Hardening – Deo 2: Zaštita od ransomware-a – immutability, air-gap i pristupna kontrola

Prvi deo serije postavio je arhitekturu — RPO/RTO, 3-2-1-1-0 okvir, tipove backup-a. Drugi deo ide u dubinu na deo tog okvira koji je najviše promenio način razmišljanja o backup-u u poslednjih nekoliko godina: kako backup infrastrukturu učiniti otpornom na napadača koji je ne samo prisutan u mreži, već aktivno i namerno cilja upravo backup sisteme kao prvi korak pre same enkripcije produkcije. Prema Veeam-ovom istraživanju iz 2025. godine, 89% organizacija je imalo backup repozitorijume koji su bili konkretna meta napada — ovo više nije rub-slučaj scenario, već očekivan deo svakog ozbiljnijeg incidenta.

Zašto klasičan pristup više nije dovoljan

Klasično 3-2-1 pravilo, opisano u prvom delu serije, rešava probleme poput otkaza diska ili lokalnog požara — scenarija u kojima je pretnja neselektivna, slučajna. Ransomware koji cilja backup je suštinski drugačiji protivnik: inteligentan, namerno usmeren, i sposoban da iskoristi upravo administratorske alate i kredencijale dizajnirane za legitimno upravljanje backup-om. Ako sve tri kopije iz 3-2-1 pravila ostaju dostupne (i time brisive ili enkriptovane) istom kompromitovanom administratorskom nalogu, broj kopija sam po sebi ne pruža stvarnu zaštitu — napadač sa dovoljno vremena i pristupa može obrisati sve tri, jednu za drugom.

Immutability — zaštita na nivou skladišta, ne na nivou dozvole

Ovo je koncept vredan preciznog objašnjenja, jer se lako meša sa običnim kontrolama pristupa. Nepromenljiv (immutable) backup je zaštićen na nivou samog skladišnog sloja — kroz WORM (Write Once, Read Many) mehanizam — ne kroz to da neki nalog "nema dozvolu" da ga obriše. Razlika je suštinska: dozvola je pravilo koje sistem primenjuje i koje administrator sistema teoretski uvek može izmeniti ili zaobići, dok je WORM zaštita fizičko ili firmversko ograničenje koje ne zavisi od toga ko se prijavljuje ili kojim kredencijalima raspolaže.

Najrasprostranjenija implementacija ovog principa danas je S3 Object Lock (i njegovi ekvivalenti kod drugih provajdera S3-kompatibilnog object storage-a) sa dva režima koje vredi razlikovati: Governance Mode dozvoljava korisnicima sa posebnim, povišenim ovlašćenjem da izmene ili uklone retention zaštitu pre isteka perioda, dok Compliance Mode to ne dozvoljava nikome, uključujući i root/administratorski nalog samog storage sistema, sve dok period zadržavanja ne istekne. Za backup podatke, gde je pretpostavljeni model pretnje upravo kompromitacija administratorskih kredencijala, Compliance Mode je ono što stvarno zatvara taj vektor napada — Governance Mode i dalje ostavlja teoretski put kroz koji dovoljno privilegovan, kompromitovan nalog može ukloniti zaštitu.

Šta treba uraditi

• Koristiti Compliance Mode (ne Governance Mode) za backup podatke gde je pretnja kompromitacije administratorskih kredencijala realan deo modela pretnje — što je, u praksi, gotovo svaka produkciona backup infrastruktura danas
• Postaviti period zadržavanja (retention lock) dovoljno dug da pokrije realno vreme potrebno za otkrivanje incidenta plus vreme za oporavak — prekratak period znači da napadač koji uspe da ostane neotkriven dovoljno dugo i dalje može dočekati istek zaštite i tek onda obrisati podatke
• Imati na umu da je immutability ograničena na retention period koji je definisan pre nego što je zaštita uključena — jednom postavljen prekratak period ne može se naknadno produžiti na već zaštićenim objektima u Compliance Mode-u; ova odluka zahteva pažljivo planiranje unapred, ne naknadno prilagođavanje
• Za veće platforme koje nude ugrađenu, po difoltu uključenu nepromenljivost na nivou same arhitekture fajl sistema (za razliku od naknadno primenjene konfiguracije), razmotriti tu prednost kao faktor pri odabiru platforme — manje prostora za grešku u konfiguraciji obično znači i manje realnog rizika u praksi

Napomena o riziku: softverska nepromenljivost, ma koliko dobro implementirana, i dalje zavisi od ispravnosti softvera koji je sprovodi — teoretski, zero-day ranjivost u samom storage sistemu ili backup platformi mogla bi zaobići WORM zaštitu na način koji administratorski nalog inače ne bi mogao. Ovo je razlog zašto se za najviši nivo poverenja i dalje preporučuje kombinacija sa fizičkim air-gap-om, opisanim dalje u tekstu, umesto oslanjanja isključivo na softversku immutability kao jedini sloj zaštite.

Air-gap — fizička, ne softverska granica

Air-gap rešava isti problem na suštinski drugačiji način: umesto softverskog ograničenja koje zabranjuje brisanje, fizički uklanja mogućnost pristupa u celini. Klasičan primer je LTO traka fizički izvađena iz biblioteke i uskladištena van mreže, ili disk koji je povremeno, ciklično povezan radi sinhronizacije i zatim fizički odvojen. Dok je jedina kopija koja postoji fizički nedostupna mreži, nijedan napadač — koliko god privilegovan pristup imao unutar mreže — ne može da je izmeni, obriše ili enkriptuje, jednostavno zato što do nje ne postoji mrežni put.

Prednost air-gap-a nad čistom softverskom nepromenljivošću je konceptualna čistoća: ne postoji zavisnost od ispravnosti softverske implementacije, jer fizička odsutnost mrežne konekcije je apsolutna, ne uslovna. Nedostatak je operativna složenost i sporije vreme oporavka — podaci na traci koja se mora fizički doneti iz udaljenog trezora nisu odmah dostupni na isti način kao immutable kopija koja ostaje online i trenutno čitljiva.

Šta treba uraditi

• Za organizacije sa najvišim zahtevima za otpornost (regulisane industrije, ili jednostavno visok apetit za rizik prema ransomware pretnji), kombinovati oba pristupa — immutable, online kopiju za brz oporavak od tipičnog incidenta, i air-gapped kopiju kao poslednju liniju odbrane za scenario u kojem bi čak i immutable zaštita, iz bilo kog razloga, bila zaobiđena
• Ako se koristi rotacija fizičkih diskova kao praktičan, pristupačniji oblik air-gap-a (umesto klasične trake), obezbediti da je bar jedan set diskova uvek fizički odvojen od mreže u svakom trenutku — rotacija koja ostavlja prozor u kojem su svi diskovi istovremeno povezani poništava svrhu air-gap-a tokom tog prozora
• Testirati stvarno vreme potrebno za dovođenje air-gapped kopije nazad u upotrebljivo stanje (fizički transport, ponovno povezivanje, verifikacija) i uključiti to vreme u RTO planiranje opisano u prvom delu serije — air-gapped kopija koja postoji, ali čije vraćanje u pogon traje danima, mora biti tretirana u skladu sa tim realnim vremenom, ne kao da je odmah dostupna
• Dokumentovati jasnu proceduru za fizičko rukovanje air-gapped medijima — ko ih prenosi, gde se čuvaju, ko ima fizički pristup trezoru — sa istom ozbiljnošću kao i digitalna kontrola pristupa

Pristupna kontrola backup infrastrukture — odvojena, ne nasleđena

Ovo je princip koji smo dodirivali kroz svaku prethodnu seriju o backup-u na ovom blogu (MSSQL, Hyper-V, VMware, Proxmox), ovde eksplicitno artikulisan kao samostalno pravilo: kredencijali koji upravljaju backup infrastrukturom ne treba da budu isti, niti da zavise od istog identity sistema, kao kredencijali koji upravljaju produkcijom koju ta infrastruktura štiti. Ako je backup konzola integrisana sa istim Active Directory-jem koji je kompromitovan tokom napada, Domain Admin nalog koji je napadač već preuzeo daje mu, po difoltu, i pristup backup sistemu — brisanje backup-a postaje samo još jedan korak u istom, već uspešnom napadu, ne odvojena prepreka.

Šta treba uraditi

• Koristiti odvojene, dedikovane kredencijale za administraciju backup infrastrukture, idealno u odvojenom identity domenu ili bar u posebnoj, strogo ograničenoj AD grupi koja nije deo standardnog administratorskog lanca privilegija
• Zahtevati phishing-otpornu, hardversku MFA (FIDO2 ključevi ili ekvivalent) za pristup backup konzoli i skladištu, ne osloniti se na SMS ili aplikacijske kodove koji su podložniji presretanju — backup administratorski nalog zaslužuje isti nivo zaštite kao i Domain Admin nalog opisan u AD hardening seriji, jer u praksi nosi uporedivu moć nad organizacijom
• Uvesti Multiuser Authorization (MUA) za kritične, destruktivne operacije — brisanje backup zadataka, izmenu retention politike, uklanjanje immutable zaštite — gde takva operacija zahteva eksplicitno odobrenje drugog, nezavisnog administratora pre nego što se izvrši; ovo direktno sprečava scenario u kojem jedan kompromitovan nalog, ma koliko privilegovan, sam izvede destruktivnu akciju bez ikakve dodatne prepreke
• Primenjivati just-in-time pristup za administraciju backup infrastrukture gde je to izvodljivo — trajno aktivan administratorski pristup je nepotreban rizik za sistem koji se ne administrira svakodnevno, po istom principu privremenog dodeljivanja privilegija opisanom u AD hardening seriji
• Redovno (bar kvartalno) revidirati ko ima administratorski pristup backup sistemu, po istom principu periodične revizije koji se ponavlja kroz svaku seriju na ovom blogu

Napomena o riziku: potpuno izolovana backup infrastruktura (odvojen identity, odvojena mreža, odvojeni administratori) nosi realan operativni trošak — sporiji, komplikovaniji svakodnevni rad, potreba za dodatnim, posebno obučenim osobljem ili procesima. Za manje organizacije sa ograničenim resursima, potpuna izolacija možda nije realna od prvog dana; ali čak i delimični koraci — makar odvojena MFA, makar poseban administratorski nalog van standardne Domain Admin grupe — značajno smanjuju rizik u odnosu na potpuno deljenu, nasleđenu administraciju. Prioritizovati ono što je stvarno izvodljivo sa raspoloživim resursima, umesto odustajanja od svega jer "prava" izolacija deluje nedostižno.

Mrežna izolacija backup infrastrukture

Isti princip segmentacije koji se provlači kroz svaku seriju na ovom blogu primenjuje se i ovde, sa specifičnom napomenom za backup kontekst: backup server ili konzola ne treba da bude mrežno dostupan sa iste, opšte produkcione mreže na način koji dozvoljava lateralno kretanje od kompromitovanog produkcionog sistema direktno ka backup infrastrukturi.

Šta treba uraditi

• Smestiti backup infrastrukturu u odvojen mrežni segment, sa strogo ograničenim, eksplicitno definisanim pravcima komunikacije (produkcioni sistemi šalju podatke ka backup-u, ne obrnuto, i administrativni pristup ide isključivo sa uskog, upravljačkog segmenta)
• Ograničiti odlazni pristup interneta sa backup infrastrukture na tačno neophodne destinacije (npr. cloud storage endpoint za offsite kopiju), po istom principu opisanom kroz seriju o hardeningu Windows i Linux servera
• Onemogućiti da backup server bude član iste domenske infrastrukture (Active Directory) koju štiti, gde je to operativno izvodljivo — nezavisan, minimalno integrisan backup server je teže dostupan istim putevima lateralnog kretanja koje napadač koristi unutar kompromitovanog domena

Sledeći deo serije bavi se testiranjem i verifikacijom — zašto backup koji se nikad ne testira nosi lažan osećaj sigurnosti, kako izgraditi realan, održiv raspored testiranja, i šta konkretno meriti da bi se znalo da li je "0" u 3-2-1-1-0 okviru zaista postignuto, a ne samo pretpostavljeno.