MSSQL Server Hardening – Deo 2: Autorizacija, role i servisni nalozi aplikacija

U prvom delu serije pokrili smo autentifikaciju — ko sme da se poveže na SQL Server i kako. Drugi deo se bavi sledećim logičnim korakom: kad je neko već autentifikovan, šta konkretno sme da radi. Ovo uključuje role na nivou baze i servera, servisne naloge aplikacija koje se konektuju na bazu, i poseban slučaj koji se često zaboravi — nalog pod kojim radi sam SQL Server proces.

Zašto se autorizacija zapušta

U praksi je uobičajen obrazac: aplikacija tokom razvoja dobije db_owner ili čak sysadmin rolu "da se ne bi javljale greške sa dozvolama", i to podešavanje ostane nepromenjeno kad aplikacija ode u produkciju, a često i godinama posle toga. Ekonomski gledano, to jeste najbrži put da se izbegnu problemi tokom razvoja — ali istovremeno znači da svaka ranjivost u toj aplikaciji, uključujući običan SQL injection, napadaču daje pun pristup celoj bazi ili čak celoj instanci.

Server role vs. database role

SQL Server razlikuje dva nivoa privilegija: server role (deluju na nivou cele instance, npr. sysadmin, dbcreator) i database role (deluju unutar jedne konkretne baze, npr. db_owner, db_datareader, db_datawriter). Mešanje ova dva nivoa je čest izvor problema — nalog kome je zapravo potreban pristup samo jednoj bazi ponekad dobije server-level rolu, jer je to bilo "brže rešenje" u trenutku kad je neko tražio pristup.

Fiksne database role poput db_datareader i db_datawriter su praktične, ali daju pristup svim tabelama u bazi — što je često više nego što je aplikaciji ili korisniku zaista potrebno. Preciznije rešenje su prilagođene (custom) role, kreirane za konkretnu funkciju, sa dozvolama ograničenim na tačno određene tabele, poglede ili šeme.

Šta treba uraditi

• Strogo razdvojiti server role od database role — nalog dodati u server-level rolu samo ako mu je zaista potrebna administracija na nivou cele instance
• Članstvo u sysadmin server roli svesti na apsolutni minimum, sa jasnom evidencijom ko je član i zašto, slično kao Domain Admins u Active Directory-ju
• Za aplikacije koje ne zahtevaju pristup celoj bazi, kreirati prilagođene role sa dozvolama vezanim za konkretnu šemu ili skup tabela, umesto automatskog korišćenja db_datareader/db_datawriter
• Nikad ne dodavati aplikativni ili servisni nalog u db_owner rolu samo da bi se "rešio" problem sa dozvolama — identifikovati tačno koja operacija ne prolazi i dodeliti samo tu dozvolu
• Proveriti dozvole dodeljene public roli (koja važi za svakog autentifikovanog korisnika u bazi) — ona po difoltu ne bi trebalo da ima nikakve dozvole na nivou objekata; ako ih ima, to je gotovo uvek nenamerno
• Raditi kvartalni pregled članstva u svim rolama i uporediti sa stvarnim poslovnim potrebama, isto kao i za AD grupe

Napomena o riziku: smanjivanje postojećih dozvola aplikaciji koja je godinama radila sa db_owner ili sysadmin nivoom pristupa nosi realan rizik da nešto prestane da radi — i to često na način koji se ne primeti odmah, već tek kad se izvrši određena, ređe korišćena operacija. Ovakve promene raditi isključivo u test okruženju, uz temeljno testiranje svih funkcija aplikacije pre prelaska u produkciju, i zadržati mogućnost brzog vraćanja na prethodno stanje ako nešto zakaže.

Nalozi za AD grupe umesto pojedinačnih naloga

Isti princip koji važi za Active Directory delegaciju važi i ovde — pristup bazi treba dodeljivati preko AD grupa, ne preko pojedinačnih naloga. Kad je pristup vezan za grupu, uklanjanje zaposlenog iz te grupe u AD-u automatski mu oduzima i pristup bazi, bez potrebe da neko ručno pamti da ga ukloni i iz SQL Server-a.

Šta treba uraditi

• Kreirati po jednu AD grupu za svaku funkcionalnu ulogu koja pristupa bazi (npr. jedna grupa za čitanje izveštaja, druga za administraciju šeme)
• U SQL Server-u kreirati login i database user za tu AD grupu, ne za pojedinačne naloge zaposlenih
• Dodeljivati database rolu grupi, a zatim upravljati stvarnim pristupom isključivo kroz članstvo u AD grupi
• Za aplikativni pristup uvek koristiti dedikovan servisni nalog — nikad deljene kredencijale, i nikad lični nalog razvojnog inženjera "privremeno", jer to privremeno rešenje po pravilu ostane trajno

Nalog pod kojim radi sam SQL Server servis

Postoji i treći, često zaboravljen nivo: Windows nalog pod kojim se pokreće sam SQL Server proces (Database Engine servis) i SQL Server Agent servis. Ovo nije login unutar baze, već nalog na nivou operativnog sistema, i greške ovde imaju širi domet — kompromitovan servisni nalog SQL Server-a može da utiče na ceo server, ne samo na bazu.

Čest anti-obrazac je da ovaj nalog bude član lokalne Administrators grupe na serveru, "da se ne bi javljale greške sa dozvolama" — isti razlog kao i kod db_owner problema, samo jedan nivo niže. SQL Server servisu ne treba lokalno administratorsko pravo za normalan rad; potrebna prava mu se dodeljuju kroz specifične lokalne SQL Server grupe i politike koje instalacija sama kreira.

Šta treba uraditi

• Koristiti gMSA (Group Managed Service Account) za SQL Server i SQL Server Agent servise gde god okruženje to podržava — isti princip kao i kod servisnih naloga u Active Directory-ju, sa automatski rotiranom lozinkom koju niko ne mora ručno da menja
• Na samostalnim serverima bez domena, koristiti virtuelni nalog (Virtual Account, format NT SERVICE\naziv_instance) kao podrazumevanu, bezbednu alternativu
• Nikad ne dodavati servisni nalog SQL Server-a u lokalnu Administrators grupu — potrebna prava se dodeljuju kroz standardne SQL Server lokalne grupe i "Log on as a Service" pravo, koje instalacija automatski konfiguriše
• Ako se servisni nalog ipak menja nakon instalacije, koristiti isključivo SQL Server Configuration Manager (ne Windows Services konzolu), jer Configuration Manager automatski podešava sve potrebne dozvole na registru, fajl sistemu i lokalnim grupama

Napomena o riziku: uklanjanje servisnog naloga SQL Server-a iz lokalne Administrators grupe, ako je prethodno tu bio, može prekinuti rad servisa ako je aplikacija ili sam SQL Server u nekom trenutku počeo da se oslanja na administratorska prava za operaciju koja je zapravo trebalo da prolazi kroz standardne SQL Server dozvole. Pre uklanjanja, proveriti da li su sve potrebne lokalne grupe i "Log on as a Service" pravo ispravno dodeljeni novom, ograničenom nalogu, i testirati pun restart servisa van produkcionog vremena. Isto važi i za promenu servisnog naloga na klasteru ili Always On Availability Group konfiguraciji — ovde je dodatni korak neophodan (kopiranje dozvola na sve čvorove), a greška se često ne ispolji dok ne dođe do failover-a.

Sledeći deo serije bavi se auditingom i logovanjem na nivou baze — SQL Server Audit funkcijom, praćenjem izmena osetljivih tabela, i onim što se najčešće traži na tehničkim proverama: ko je i kada menjao podatke.