MSSQL Server Hardening – Deo 1: Autentifikacija i pristup

Ovim tekstom počinje nova mini-serija posvećena hardeningu Microsoft SQL Server-a — baze podataka koja u velikom broju organizacija čuva najosetljiviji deo poslovnih podataka, a istovremeno se u praksi retko sistematski proverava posle inicijalne instalacije. Prvi deo pokriva osnovu svega ostalog: kako se korisnici i servisi autentifikuju na server, i kako se ograničava površina napada na samom nivou instance.

Zašto je SQL Server često slabija karika

Operativni sistem na kojem SQL Server radi često prolazi kroz redovan hardening i patch ciklus, dok se sama baza tretira kao "crna kutija" koju administrira aplikacija, ne IT tim. Rezultat je da instanca ostaje na podrazumevanim podešavanjima godinama — uključena mixed-mode autentifikacija koja nikad nije bila potrebna, aktivan sa nalog sa lozinkom postavljenom prilikom instalacije, ili opcije poput xp_cmdshell koje niko nije svesno uključio, a koje omogućavaju direktno izvršavanje komandi operativnog sistema iz same baze.

Režim autentifikacije

SQL Server podržava dva režima: Windows Authentication (isključivo preko Windows/AD naloga) i Mixed Mode (Windows nalozi i SQL Server nalozi zajedno). Microsoft-ova preporuka je jasna — Windows Authentication treba da bude podrazumevan izbor gde god je to moguće, jer se tako autentifikacija oslanja na Active Directory politike (kompleksnost lozinke, isteka, MFA gde je uveden), umesto na odvojen, često slabije nadgledan sistem naloga unutar same baze.

Mixed Mode ostaje neophodan u realnim uslovima — mnoge starije ili treće-strane aplikacije zahtevaju SQL login sa fiksnim korisničkim imenom i lozinkom u connection string-u, jer ne podržavaju Windows integrisanu autentifikaciju.

Šta treba uraditi

• Gde aplikacija to dozvoljava, koristiti isključivo Windows Authentication mode
• Ako je Mixed Mode neophodan, onemogućiti (disable) sa nalog nakon instalacije, ili mu bar postaviti dugu, nasumično generisanu lozinku koja se ne koristi ni za jednu drugu svrhu — sa nalog je najpoznatija i najčešće ciljana meta na bilo kojoj SQL Server instanci
• Za SQL login naloge koji moraju postojati, primenjivati istu disciplinu kao za servisne naloge u Active Directory-ju — dugačka, nasumična lozinka, redovna rotacija, nikad deljena između više aplikacija
• Kad god je moguće, davati pristup preko Windows grupa, ne pojedinačnih naloga — uklanjanje korisnika iz grupe automatski oduzima i pristup bazi, dok se pojedinačni pristup lako zaboravi da se ukloni prilikom odlaska zaposlenog

Napomena o riziku: isključivanje sa naloga ili prelazak sa Mixed Mode na Windows Authentication može prekinuti rad starijih aplikacija, izveštajnih alata ili skripti za backup koje se oslanjaju na SQL login. Pre bilo koje izmene režima autentifikacije, obavezno popisati sve konekcione stringove i zakazane poslove (SQL Agent jobs) koji koriste SQL login, i promenu testirati van produkcije.

Enkripcija konekcije

Podrazumevano, saobraćaj između klijenta i SQL Server-a ne mora biti šifrovan, što znači da su kredencijali i podaci u prenosu potencijalno vidljivi svakom ko ima pristup istom mrežnom segmentu. Rešenje je uključivanje enkripcije na nivou same instance, ne prepuštanje toga pojedinačnim aplikacijama da same odluče.

Šta treba uraditi

• U SQL Server Configuration Manager-u postaviti Force Encryption na "Yes" (za starije verzije), odnosno Force Strict Encryption za SQL Server 2022 i novije, koji koristi noviji TDS 8.0 protokol
• Kod Windows autentifikacije, dodatno postaviti Extended Protection na "Required" radi zaštite od relay napada sličnih onima opisanim u delu serije o Active Directory-ju

Napomena o riziku: Force Strict Encryption (TDS 8.0) nije unazad kompatibilan sa svim starijim ODBC/OLE DB drajverima i starijim verzijama aplikacija. Pre uključivanja, proveriti da li svi klijenti koji se konektuju na instancu podržavaju noviji protokol — u suprotnom, konekcija će jednostavno prestati da radi umesto da se degradira na stariji, nešifrovan režim.

Smanjenje površine napada instance

SQL Server dolazi sa nekoliko funkcija koje značajno proširuju mogućnosti napadača ako ostanu uključene bez stvarne poslovne potrebe. Najpoznatija je xp_cmdshell — ugrađena procedura koja članovima sysadmin uloge dozvoljava da direktno izvršavaju komande operativnog sistema kroz SQL upit. Ako napadač uspe da izvede SQL injection napad ili na drugi način dobije mogućnost izvršavanja upita sa dovoljnim privilegijama, xp_cmdshell mu efektivno daje komandnu liniju servera.

Slično važi za CLR integraciju (mogućnost pokretanja .NET koda unutar baze) i za TRUSTWORTHY podešavanje na nivou baze, koje bazi daje povišen nivo poverenja i otvara put da zlonamerni CLR kod utiče na celu instancu, ne samo na tu jednu bazu.

Šta treba uraditi

• Proveriti status xp_cmdshell opcije i, ako nije u aktivnoj upotrebi za legitimnu, dokumentovanu potrebu, isključiti je
• Ako CLR integracija nije neophodna za konkretnu aplikaciju, ostaviti je isključenom (podrazumevano stanje) — a ako mora biti uključena, obavezno zadržati clr strict security uključen, jer to sprečava CLR sklopove da se tretiraju sa većim poverenjem nego što je opravdano
• Nikad ne postavljati TRUSTWORTHY na ON za bazu, osim ako postoji vrlo konkretan, dokumentovan i vremenski ograničen razlog, uz plan da se to podešavanje ukloni čim prestane potreba
• Periodično (bar kvartalno) proći kroz sve server-level konfiguracijske opcije (sp_configure) i uporediti ih sa poznatim, bezbednim baseline-om, umesto da se oslanja na to da niko ništa nije menjao od instalacije

Napomena o riziku: isključivanje xp_cmdshell ili CLR integracije može prekinuti rad starijih skripti za održavanje, ETL procesa ili aplikacija koje su na njih navikle da se oslanjaju kao na "praktično rešenje". Pre isključivanja, proveriti sve zakazane SQL Agent poslove i uskladiti sa vlasnicima aplikacija, jer greška ovde obično ne izaziva grešku odmah, već tek prilikom sledećeg izvršavanja zakazanog posla.

Enkripcija podataka u mirovanju

Transparent Data Encryption (TDE) štiti fajlove baze, log fajlove i tempdb na nivou diska — ako neko fizički iznese disk ili backup fajl, bez odgovarajućeg sertifikata ne može da ga pridruži (attach) niti pročita sadržaj. Ovo je posebno bitno za backup fajlove, koji se često čuvaju sa manje pažnje nego sama produkciona baza, a sadrže potpuno iste podatke.

Šta treba uraditi

• Uključiti TDE na svim bazama koje sadrže osetljive poslovne podatke
• Sertifikat i privatni ključ korišćen za TDE čuvati odvojeno od same baze i od backup fajlova — ako se sertifikat izgubi, enkriptovani podaci postaju trajno nedostupni, čak i legitimnom vlasniku
• Backup sertifikata i privatnog ključa uraditi odmah po uključivanju TDE-a i čuvati ga na bezbednoj, odvojenoj lokaciji, po mogućstvu i van same organizacije (npr. u sefu ili kod ovlašćenog trećeg lica)

Napomena o riziku: uključivanje TDE-a na velikoj, aktivnoj bazi izaziva privremeno intenzivno opterećenje diska i procesora dok se svi podaci enkriptuju, što može uticati na performanse tokom tog perioda — planirati ovu operaciju van radnog vremena ili perioda pojačanog opterećenja.

Sledeći deo serije bavi se autorizacijom — rolama, principom najmanjih privilegija na nivou baze, i praktičnim pristupom za servisne naloge aplikacija koje se konektuju na SQL Server.