MSSQL Server Hardening – Deo 5: Bezbednost Always On Availability Group konfiguracija

Prethodna četiri dela serije bavila su se pojedinačnom SQL Server instancom. Peti deo prelazi na Always On Availability Group (AG) — mehanizam za visoku dostupnost koji povezuje više instanci u jednu celinu, i koji sa sobom nosi sopstveni, poseban skup bezbednosnih pitanja. Kad se jedna baza replicira na više servera, površina napada se ne deli, već množi — svaka replika mora biti podjednako zaštićena kao i primarna, jer napadaču je dovoljno da probije samo jednu kariku.

Zašto AG nije samo "backup koji radi sam od sebe"

Availability Group se često posmatra kroz prizmu dostupnosti — šta se dešava ako primarni server otkaže. Bezbednosna strana se pritom lako zapostavi: podaci se u realnom vremenu prenose između više servera, preko mreže, i taj kanal komunikacije mora biti zaštićen isto ozbiljno kao i sam pristup bazi. Ako je komunikacija između replika nezaštićena, napadač sa pristupom internom mrežnom segmentu može da prisluškuje ili čak menja podatke koji se prenose između primarne i sekundarnih replika.

Enkripcija endpoint komunikacije

Replike unutar Availability Group-a komuniciraju preko posebnog endpoint-a (podrazumevano na portu 5022), i ta komunikacija po difoltu koristi enkripciju, ali je bitno proveriti da je konfiguracija zaista onoliko stroga koliko okruženje zahteva. Sa SQL Server 2025 i novijim, dostupna je opcija stroge TLS 1.3 enkripcije (Encrypt=Strict, kroz TDS 8.0) i za komunikaciju replika i za konekcije klijenata ka listener-u, što predstavlja značajno poboljšanje u odnosu na stariju, manje strogu enkripciju endpoint-a.

Šta treba uraditi

• Proveriti da je enkripcija na AG endpoint-u zaista aktivna i da koristi savremen algoritam — ne pretpostaviti da je podrazumevano podešavanje dovoljno strogo bez provere
• Na SQL Server 2025 i novijim verzijama, razmotriti prelazak na Encrypt=Strict (TDS 8.0) za endpoint i listener komunikaciju radi pune TLS 1.3 zaštite
• Ograničiti mrežni pristup portu 5022 (ili prilagođenom AG portu) isključivo na servere koji su deo klastera — ovaj port ne treba da bude dostupan sa opšte korisničke mreže
• Redovno proveravati validnost i datum isteka sertifikata korišćenih za autentifikaciju endpoint-a, posebno u domain-independent klasterima gde se autentifikacija oslanja isključivo na sertifikate, ne na Windows autentifikaciju

Napomena o riziku: prelazak na Encrypt=Strict zahteva istovremenu promenu na svim replikama i failover da bi se podešavanje primenilo, i nije unazad kompatibilan sa starijim klijentskim drajverima koji ne podržavaju TDS 8.0 — pre primene, proveriti da li sve aplikacije koje se konektuju na listener podržavaju noviji protokol, jer će konekcija u suprotnom jednostavno prestati da radi, ne degradirati na stariji režim. Ovu promenu obavezno prvo testirati u AG konfiguraciji van produkcije.

TDE sertifikat mora biti identičan na svim replikama

Ako je baza u Availability Group-u zaštićena Transparent Data Encryption-om (TDE, opisano u prvom delu serije), isti sertifikat ili asimetrični ključ za enkripciju/dekripciju mora postojati na svakoj instanci koja hostuje tu bazu — na primarnoj i na svim sekundarnim replikama. Ovo nije opcionalno podešavanje performansi, već tehnički preduslov: bez odgovarajućeg sertifikata na sekundarnoj replici, ta replika jednostavno ne može da dekriptuje i primeni podatke koje prima od primarne.

Šta treba uraditi

• Pri uvođenju nove sekundarne replike u AG koja hostuje TDE-zaštićenu bazu, preneti TDE sertifikat na tu repliku pre dodavanja baze u grupu, ne posle
• Čuvati backup TDE sertifikata na bezbednoj lokaciji dostupnoj timu koji upravlja AG-om, ne samo administratoru primarne instance — u slučaju potrebe za dodavanjem nove replike ili disaster recovery scenarija, sertifikat mora biti brzo dostupan
• Voditi evidenciju o tome koje instance u AG-u imaju koji TDE sertifikat, posebno u većim, distribuiranim AG konfiguracijama sa replikama u više lokacija

Least privilege za AG operacije

Kreiranje i upravljanje Availability Group-om zahteva visoke privilegije — sysadmin pravo za kreiranje AG listener-a, i odgovarajuća prava na nivou Windows klastera za kreiranje mrežnog imena i računarskog objekta u Active Directory-ju. Ovo je dodatna dimenzija privilegovanog pristupa koja se lako previdi ako se AD hardening (opisan u prethodnoj seriji na ovom blogu) posmatra odvojeno od SQL Server bezbednosti.

Poseban slučaj su čitljive sekundarne replike (readable secondaries) — funkcija koja omogućava da se SELECT upiti preusmere na sekundarnu repliku radi rasterećenja primarne. Ako se autorizacija na sekundarnoj replici ne postavi jednako pažljivo kao na primarnoj, sekundarna replika postaje slabija karika kroz koju je moguće pročitati iste osetljive podatke, uz manje pažnje posvećene proveri.

Šta treba uraditi

• Ograničiti krug naloga koji imaju sysadmin pravo za kreiranje i izmenu AG listener-a, po istom principu kao i za sysadmin rolu opisanu u drugom delu serije
• Dodeliti računarskom objektu klastera u Active Directory-ju samo prava koja su mu zaista potrebna za kreiranje mrežnog imena (Create Computer Objects na odgovarajućem OU-u), ne šira administratorska prava "da bi se izbegli problemi" — isti princip najmanjih privilegija kao i kod OU delegacije opisane u AD seriji
• Primenjivati identičnu autorizacionu politiku (role, dozvole, audit) na čitljivim sekundarnim replikama kao i na primarnoj — readable secondary ne sme biti tretiran kao "manje bitna" kopija sa labavijim pristupom
• Uključiti audit (opisan u trećem delu serije) i na sekundarnim replikama gde je to primenjivo, ne samo na primarnoj instanci

Napomena o riziku: smanjivanje širokih dozvola dodeljenih klaster računarskom objektu ili nalozima koji upravljaju AG-om može, ako se uradi neoprezno, prekinuti automatski failover proces ili sprečiti kreiranje novih listener objekata u budućnosti. Svaku izmenu dozvola testirati kroz kontrolisan, najavljen failover test van produkcionog vremena, kako bi se potvrdilo da mehanizam visoke dostupnosti i dalje radi ispravno nakon pooštravanja pristupa.

Ovim je pokriven i mrežni, replicirani aspekt MSSQL hardeninga. Sledeći deo serije može ići na to kako se autorizacija i audit iz prethodnih delova zajedno ponašaju u praksi protiv SQL injection napada — šta tačno ograničava štetu kad prevencija na nivou aplikacije zakaže, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.