MSSQL Server Hardening – Deo 3: SQL Server Audit i praćenje izmena podataka

Prva dva dela serije pokrila su ko sme da se poveže na SQL Server (autentifikacija) i šta sme da radi kad se poveže (autorizacija). Treći deo zatvara krug pitanjem koje se najčešće postavlja tek posle incidenta: ko je i kada zapravo nešto uradio. SQL Server Audit funkcija i mehanizmi za praćenje izmena podataka (temporal tables) daju odgovor na to pitanje — ako su unapred podešeni.

Zašto se audit ne podrazumeva sam po sebi

Podrazumevano, SQL Server beleži relativno malo toga van osnovnog ERRORLOG-a — uspešne prijave, na primer, uopšte se ne loguju bez eksplicitnog podešavanja. To znači da instanca može raditi godinama bez ijednog traga o tome ko je čitao ili menjao osetljive podatke, sve dok se prvi put ne postavi pitanje "ko je ovo izmenio" — obično nakon što je šteta već nastala.

SQL Server Audit je ugrađena funkcija dizajnirana upravo za ovo, ali zahteva svesnu odluku o tome šta se prati. Praćenje svega bez razlike nosi merljiv trošak po performansama i brzo generiše toliko podataka da postaju neupotrebljivi bez jasnog fokusa — isti problem kao i sa Event log-ovima na domain kontroleru iz prethodnih delova serije o Active Directory-ju.

Arhitektura SQL Server Audit funkcije

SQL Server Audit se sastoji od tri sloja. Audit objekat definiše gde se zapisi čuvaju — u fajl, u Windows Application log ili u Security log. Server Audit Specification prati događaje na nivou cele instance (npr. promene servisne konfiguracije, izmene login naloga, promene rola). Database Audit Specification prati događaje unutar jedne konkretne baze (npr. SELECT, INSERT, UPDATE, DELETE nad tačno određenom tabelom).

Bitno praktično ograničenje: Database Audit Specification je dostupna samo u Enterprise izdanju SQL Server-a — Standard izdanje ne podržava praćenje na nivou pojedinačnih tabela kroz ovaj mehanizam, što treba uzeti u obzir pri planiranju licence, ako je granularni audit podataka poslovni zahtev.

Šta treba uraditi

• Kreirati Server Audit Specification koja prati bar sledeće: neuspešne i uspešne prijave, promene login naloga i server rola, promene konfiguracije instance (DDL na nivou servera)
• Za osetljive tabele (finansijski podaci, lični podaci korisnika, tabele sa pravima pristupa) kreirati Database Audit Specification koja prati SELECT, INSERT, UPDATE, DELETE — ali isključivo na tim, unapred identifikovanim tabelama, ne na celoj bazi
• Postaviti audit zapise da se pišu na Security log (uz odgovarajuće OS podešavanje) ili u zaseban, zaštićen fajl, kako bi audit trag bio odvojen od same baze — u slučaju kompromitacije baze, napadač ne bi trebalo da može da izbriše i sopstveni trag
• Definisati redovan raspored pregleda audit podataka (bar jednom nedeljno) — audit koji se nikad ne pregleda ima istu vrednost kao i da ne postoji, dok se ne desi incident
• Imati na umu da tempdb i privremene tabele nisu pokrivene auditom zbog ograničenja performansi — ako aplikacija radi sa osetljivim podacima kroz privremene tabele, tragovi te obrade neće biti vidljivi u audit logu

Napomena o riziku: uključivanje audita na nivou pojedinačnih redova ili na tabelama sa velikim brojem transakcija (npr. tabela porudžbina u sistemu sa hiljadama transakcija dnevno) može primetno opteretiti performanse servera, posebno na već opterećenim instancama. Pre uključivanja u produkciji, testirati opterećenje u test okruženju sa realističnom količinom saobraćaja, i razmotriti ograničavanje audita samo na operacije koje su zaista bitne (npr. samo UPDATE i DELETE, ne i SELECT, ako čitanje nije predmet interesovanja).

Praćenje sadržaja izmena — temporal tables

SQL Server Audit odgovara na pitanje "ko je i kada nešto uradio", ali ne čuva nužno i "šta je tačno bilo pre izmene". Za tu svrhu, od SQL Server 2016 nadalje, postoji ugrađena funkcija sistemski-verzionisanih tabela (temporal tables) — svaka izmena reda automatski se beleži u posebnu istorijsku tabelu, sa tačnim vremenskim opsegom kad je ta verzija reda bila važeća.

Ovo je posebno korisno za tabele gde je bitno moći rekonstruisati prethodno stanje podatka — na primer, ko je i kada promenio iznos na fakturi, ili stanje na korisničkom nalogu pre i posle izmene. Za razliku od ručno pisanih trigera koji rade istu stvar, temporal tables su ugrađena, dobro testirana funkcija SQL Server-a, sa manje prostora za grešku u implementaciji.

Šta treba uraditi

• Za tabele gde je bitno znati ne samo da je nešto izmenjeno, već i tačno šta je izmenjeno, uključiti sistemsko verzionisanje (SYSTEM_VERSIONING) i definisati odgovarajuću istorijsku tabelu
• Postaviti retention politiku na istorijskoj tabeli (koliko dugo se čuva istorija) usklađenu sa realnim poslovnim i regulatornim zahtevima, a ne podrazumevano čuvati sve zauvek
• Imati u vidu da direktna izmena podataka u istorijskoj tabeli nije dozvoljena standardnim putem — ovo je zapravo prednost sa bezbednosne strane, jer otežava naknadno "čišćenje tragova"
• Za tabele sa velikim binarnim poljima (npr. nvarchar(max), varbinary(max)) posebno razmotriti da li je temporal pristup opravdan, jer istorijska tabela može vrlo brzo narasti i značajno povećati potrošnju skladišnog prostora

Napomena o riziku: uključivanje sistemskog verzionisanja na postojećoj, aktivnoj tabeli dodaje trošak pisanja pri svakoj izmeni (upisuje se i u glavnu i u istorijsku tabelu), što može uticati na performanse aplikacija sa visokim brojem UPDATE operacija. Takođe, retention politika mora biti pažljivo isplanirana unapred — ako se istorijska tabela nekontrolisano gomila godinama bez čišćenja, može postati veća od same produkcione tabele i otežati backup i restore procedure. Ovu promenu prvo testirati na kopiji podataka realne veličine, ne na maloj test bazi koja ne pokazuje stvarni obim rasta.

Ovim se zaokružuje osnovni ciklus MSSQL hardening serije — autentifikacija, autorizacija i audit. Sledeći delovi mogu ići dublje na specifične teme poput bezbednosti Always On Availability Group konfiguracija, zaštite backup fajlova, ili konkretnih SQL injection scenarija i kako ih audit i autorizacija zajedno ograničavaju, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.