MSSQL Server Hardening – Deo 4: Bezbednost backup fajlova

Prethodna tri dela serije bavila su se zaštitom žive baze — autentifikacijom, autorizacijom i auditom. Ovaj deo se bavi nečim što se često tretira kao čisto operativno pitanje, a zapravo je jednako bitno bezbednosno pitanje: backup fajlovima. Backup sadrži potpuno iste podatke kao produkciona baza, ali se u praksi čuva sa mnogo manje pažnje — i upravo je zato sve češće direktna meta napada, ne samo slučajna žrtva.

Zašto je backup meta, ne samo rezervni plan

Savremeni ransomware napadi na baze podataka retko se zaustavljaju na enkripciji same produkcione baze. Ozbiljniji napadači aktivno traže i backup fajlove, jer znaju da je to jedini način da žrtva ostane bez mogućnosti oporavka bez plaćanja otkupnine. Ako se backup nalazi na istom mrežnom deljenom resursu, sa istim kredencijalima za pristup kao i produkcioni server, napadač koji kompromituje jedno gotovo automatski dobija i drugo.

Drugi, jednako čest scenario nije napad, već obična krađa ili gubitak medija — spoljni disk, traka ili backup fajl kopiran na pogrešno mesto, koji sadrži potpuno iste osetljive podatke kao produkciona baza, samo bez ijedne od zaštita koje važe za samu bazu.

Enkripcija backup fajlova

SQL Server od verzije 2014 nadalje podržava nativnu enkripciju prilikom kreiranja backup-a, nezavisno od Transparent Data Encryption (TDE) opisane u prvom delu serije. Backup se može enkriptovati navođenjem algoritma (AES 128, AES 192, AES 256, ili starije Triple DES) i sertifikata ili asimetričnog ključa koji štiti ključ za enkripciju — ovo radi bez obzira na to da li je sama baza pod TDE zaštitom.

Ako je baza već pod TDE zaštitom, backup fajl je automatski enkriptovan kao posledica toga — dodatna eksplicitna enkripcija backup-a je i dalje korisna kao odvojen sloj, posebno kad se backup prenosi ili čuva van infrastrukture na kojoj je TDE sertifikat lokalno dostupan.

Šta treba uraditi

• Enkriptovati backup fajlove pri kreiranju (WITH ENCRYPTION opcija), koristeći AES 256 gde god performanse to dozvoljavaju
• Sertifikat ili ključ korišćen za backup enkripciju čuvati odvojeno od samih backup fajlova — isti princip kao i za TDE sertifikat iz prvog dela serije
• Obavezno napraviti i bezbedno sačuvati kopiju sertifikata/ključa pre nego što se prvi enkriptovani backup uopšte napravi — bez njega, enkriptovani backup postaje trajno neupotrebljiv, čak i legitimnom vlasniku
• Ako se baza već nalazi pod TDE zaštitom, proveriti da li je dodatna eksplicitna enkripcija backup-a i dalje potrebna za konkretan scenario prenosa/čuvanja, umesto da se pretpostavi da je TDE dovoljna zaštita u svim slučajevima

Napomena o riziku: gubitak sertifikata ili ključa korišćenog za enkripciju backup-a znači trajan gubitak mogućnosti restauracije tog backup-a — ovo je jedan od najčešćih uzroka "backup koji se ispostavi da ne radi" u trenutku kad je stvarno potreban. Backup samog sertifikata mora biti deo redovne procedure, testiran isto ozbiljno kao i sam backup baze, i čuvan na lokaciji fizički odvojenoj od backup fajlova koje štiti.

Odvajanje pristupa i lokacije

Najvažnija pojedinačna mera protiv ransomware scenarija nije enkripcija, već odvajanje — backup ne sme biti dostupan istim kredencijalima i sa iste mreže kao produkciona baza. Ako administrator koji upravlja produkcionim serverom ima automatski i pun pristup za brisanje backup fajlova, kompromitacija tog jednog naloga uništava i produkciju i mogućnost oporavka u istom trenutku.

Šta treba uraditi

• Čuvati backup fajlove van mreže i domena na kojem se nalazi produkciona baza, kad god je to izvodljivo — fizički odvojen sistem koji ne deli kredencijale sa produkcijom
• Koristiti nalog za pisanje backup-a koji nema pravo brisanja postojećih backup fajlova, tako da čak i kompromitovan proces backup-a ne može obrisati prethodne kopije
• Razmotriti immutable (WORM — Write Once, Read Many) skladište za bar deo backup rotacije, gde jednom napisan backup fajl fizički ne može biti izmenjen ili obrisan pre isteka definisanog perioda, bez obzira na to ko pokuša
• Držati bar jednu kopiju backup-a potpuno van domena (offline ili u odvojenom cloud nalogu sa različitim kredencijalima) — "3-2-1" princip (tri kopije, dva različita medija, jedna van lokacije) ostaje validan i za baze podataka
• Redovno proveravati da nalog koji pokreće backup zadatke (SQL Server Agent servisni nalog iz drugog dela serije) nema nepotrebno širok pristup mrežnim deljenim resursima van onih koji su mu stvarno potrebni

Napomena o riziku: uvođenje immutable skladišta ili odvajanje backup mreže od produkcione može zahtevati izmenu postojećih backup skripti, connection string-ova ili zakazanih poslova — testirati ceo lanac (backup, kopiranje, verifikacija, restore) posle svake promene infrastrukture, ne samo sam čin pravljenja backup-a. Restriktivan nalog za backup (bez prava brisanja) takođe zahteva posebnu proceduru za čišćenje starih backup fajlova preko drugog, zasebno ovlašćenog naloga — ako se to ne isplanira, backup direktorijum će se nekontrolisano puniti dok neko ne primeti da je disk pun.

Provera da backup zaista radi

Backup koji se pravi automatski svake noći, ali se nikad ne testira, predstavlja lažni osećaj sigurnosti. Ispravan backup fajl koji ne može uspešno da se restauriše je jednako beskoristan kao da backup uopšte ne postoji — razlika se otkrije tek u trenutku kad je restauracija stvarno potrebna, što je najgori mogući trenutak za takvo otkriće.

Šta treba uraditi

• Redovno izvršavati RESTORE VERIFYONLY nad backup fajlovima, da se potvrdi da je fajl strukturno ispravan i da SQL Server može da ga pročita
• Periodično (bar kvartalno) uraditi punu probnu restauraciju na odvojenom, izolovanom serveru — ne samo proveru strukture fajla, već stvarno vraćanje baze i proveru da su podaci konzistentni i kompletni
• Koristiti CHECKSUM opciju prilikom pravljenja backup-a, kako bi se eventualna oštećenja podataka otkrila već u trenutku pravljenja backup-a, ne tek prilikom restauracije
• Dokumentovati vreme potrebno za punu restauraciju (Recovery Time Objective) na osnovu stvarno izmerenog vremena iz probne restauracije, ne na osnovu pretpostavke — ovo je informacija koja se najčešće traži prva na tehničkoj proveri kontinuiteta poslovanja

Ovim se dodatno proširuje MSSQL hardening serija na temu koja se u praksi najčešće otkrije tek kad je prekasno da se ispravi. Sledeći delovi mogu ići dublje na bezbednost Always On Availability Group konfiguracija ili na to kako autorizacija i audit iz prethodnih delova zajedno ograničavaju štetu od SQL injection napada, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.