Windows Server Hardening – Deo 3: Lokalne bezbednosne politike, kontrola softvera i BitLocker

Prva dva dela serije pokrila su baseline, lokalne administratorske naloge, RDP, firewall i osnove Microsoft Defender-a. Treći deo ide dublje u lokalne bezbednosne politike servera — ko sme lokalno da se prijavi, koji softver sme da se izvršava, i kako zaštititi sadržaj diska ako mašina fizički padne u pogrešne ruke. Ovo su podešavanja koja retko privlače pažnju jer ne "rade" ništa vidljivo iz dana u dan — sve dok se jednom, u pravom trenutku, ne pokažu kao presudna.

User Rights Assignment na serverima van domain kontrolera

User Rights Assignment (URA) je koncept koji smo detaljno obradili u seriji o Active Directory-ju, ali gotovo isključivo u kontekstu domain kontrolera. Isti princip, i isti rizik od akumulacije zaboravljenih dodela, jednako važi i za obične članske servere — aplikativne, fajl, veb servere. Razlika je što se URA na ovim serverima još ređe pregleda, jer ne postoji isti nivo pažnje kao za domain kontrolere.

Jedno konkretno, često previđeno podešavanje zaslužuje posebnu pažnju: pravo "Access this computer from the network" po difoltu uključuje grupu Everyone na mnogim starijim ili neregulisanim konfiguracijama, što znači da bilo koji autentifikovan, pa čak i anoniman korisnik može mrežno da pristupi deljenim resursima tog servera. Ovo je podešavanje koje se retko svesno menja, a nosi realan rizik u svakom scenariju gde server ima bilo kakav mrežni deljeni resurs.

Šta treba uraditi

• Proveriti i po potrebi izmeniti "Access this computer from the network" tako da ne uključuje Everyone grupu, već tačno određene naloge ili grupe kojima je mrežni pristup zaista potreban
• Ograničiti "Allow log on locally" isključivo na administratorske naloge na serverima — obični korisnici retko imaju legitiman razlog za interaktivnu prijavu direktno na server
• Ograničiti "Allow log on through Remote Desktop Services" na tačno određenu administratorsku grupu, po istom principu opisanom za RDP u prvom delu serije
• Preuzeti Microsoft Security Baseline za odgovarajuću ulogu servera (Member Server, ne Domain Controller) i koristiti Policy Analyzer ili sličan alat da se uporedi trenutna URA konfiguracija sa preporučenim baseline-om
• Sprovesti istu vežbu pregleda i čišćenja koja je opisana za Default Domain Controllers Policy u AD seriji — na svim serverima, ne samo na domain kontrolerima

Napomena o riziku: izmena URA podešavanja, posebno "Access this computer from the network" i "Allow log on locally", može prekinuti rad servisnih naloga, aplikacija ili zakazanih poslova koji se oslanjaju na ta prava na način koji nije odmah očigledan. Pre primene, popisati sve naloge koji trenutno koriste ta prava (uključujući servisne naloge aplikacija), primeniti izmenu prvo na manjem broju servera ili u test okruženju, i pratiti rezultate kroz nekoliko punih radnih ciklusa pre šire primene.

Politika lozinki — noviji pristup nasuprot starim navikama

Dugo vremena je standardna preporuka bila periodična, prisilna promena lozinke (npr. svakih 90 dana), bez obzira na to da li postoji ikakav razlog za sumnju na kompromitaciju. Noviji zvanični smernice (NIST SP 800-63B) menjaju ovaj pristup — prisilna, periodična rotacija lozinke bez konkretnog razloga se više ne preporučuje, jer u praksi često vodi ka predvidljivim, samo neznatno izmenjenim lozinkama (npr. dodavanjem broja na kraju), što svodi bezbednosnu korist rotacije na minimum, uz realan operativni trošak.

Šta treba uraditi

• Za lokalne i servisne naloge, prioritetno postaviti dužinu lozinke (najmanje 15 karaktera za administratorske naloge) i složenost, umesto da se prisilna rotacija tretira kao glavna mera zaštite
• Menjati lozinku po konkretnom povodu — sumnja na kompromitaciju, odlazak zaposlenog koji je znao lozinku, ili istek definisanog perioda za posebno osetljive naloge — ne mehanički na fiksnom intervalu bez razloga
• Uvesti MFA za sve privilegovane naloge gde je to tehnički izvodljivo, jer to daje znatno veću zaštitu od same politike lozinke
• Za lokalne administratorske naloge, osloniti se na LAPS (opisan u prvom delu serije) za rotaciju, umesto na ručno upravljanje lozinkom kroz politiku

Kontrola izvršavanja softvera

Čak i uz dobro postavljenu autorizaciju i firewall, server ostaje ranjiv na scenario u kojem napadač uspe da postavi izvršnu datoteku na disk i pokrene je — bilo kroz kompromitovanu aplikaciju, socijalni inženjering usmeren ka administratoru, ili iskorišćavanje neke druge ranjivosti. Windows nudi dva mehanizma za sprečavanje ovog scenarija: AppLocker i noviji Windows Defender Application Control (WDAC).

Razlika između njih nije samo kozmetička. AppLocker radi na nivou korisničkog moda (user mode), što znači da napadač sa lokalnim administratorskim pravima može, uz dovoljno znanja, da ga isključi ili zaobiđe. WDAC radi na nivou kernela — politika se proverava pre nego što se bilo koji izvršni fajl uopšte učita, i administrator ne može jednostavno da je isključi bez ponovnog pokretanja u pouzdano okruženje za oporavak. Microsoft je eksplicitno naveo da AppLocker neće dobijati nove funkcionalnosti i da je WDAC preporučen put unapred, iako AppLocker i dalje prima bezbednosne ispravke.

Šta treba uraditi

• Za nove implementacije, planirati direktno uvođenje WDAC-a umesto AppLocker-a, gde okruženje (Windows Server 2022 i noviji) to podržava
• Ako je AppLocker već u upotrebi, uključiti WDAC migraciju u plan za naredni period, umesto da se AppLocker tretira kao trajno rešenje
• Početi sa politikom u audit modu (ne odmah u enforce modu), po istom principu kao i kod ASR pravila iz drugog dela serije, kako bi se identifikovao legitiman softver pre stvarnog blokiranja
• Za servere sa jasno definisanom, ograničenom namenom (npr. dedikovan aplikativni server koji pokreće samo jednu aplikaciju), razmotriti stroži, "lockdown" pristup — dozvoljen samo tačno određen, poznat skup izvršnih fajlova, sve ostalo podrazumevano odbijeno
• Kod PowerShell-a, imati u vidu da WDAC politika automatski prebacuje nepoverljive skripte u Constrained Language mode, što ograničava njihove mogućnosti čak i ako uspeju da se izvrše — dodatan sloj zaštite bez dodatne konfiguracije

Napomena o riziku: uvođenje WDAC-a ili AppLocker-a u enforce modu bez prethodnog, dovoljno dugog audit perioda može prekinuti rad legitimnog softvera, uključujući skripte za automatizaciju, agente za monitoring, ili alate za održavanje koje IT tim svakodnevno koristi. Ovo je jedna od operativno najosetljivijih promena u celoj seriji — greška ovde ne uzrokuje suptilan problem, već potpuno zaustavljanje izvršavanja softvera koji nije eksplicitno dozvoljen. Testirati temeljno, u audit modu, kroz dovoljno dug period da se pokriju i ređe, periodične operacije (npr. mesečni izveštaji ili kvartalno održavanje), pre prelaska na stvarno blokiranje.

BitLocker — kad je zaista potreban na serveru

Za razliku od prenosivih uređaja (laptopova), gde je BitLocker gotovo uvek opravdan zbog rizika fizičke krađe, kod servera odgovor zavisi od konteksta. Server u zaključanom data centru sa kontrolisanim fizičkim pristupom nosi manji rizik od fizičke krađe diska nego server na udaljenoj lokaciji sa slabijom fizičkom bezbednošću — tačno scenario opisan za RODC u AD hardening seriji, gde je BitLocker eksplicitno preporučen upravo zbog slabije fizičke kontrole.

Šta treba uraditi

• Prioritetno uključiti BitLocker na serverima koji se fizički nalaze van centralnog, dobro obezbeđenog data centra — regionalne kancelarije, manje udaljene lokacije, RODC-ovi opisani u AD seriji
• Za virtuelizovane servere, proceniti rizik na nivou same virtuelizacione infrastrukture (ko ima pristup skladištu i snapshot-ovima, opisano u AD seriji za domain kontrolere) pre nego što se donese odluka da li je BitLocker na nivou gost operativnog sistema neophodan dodatni sloj
• Gde se BitLocker koristi, čuvati recovery ključeve centralno (Active Directory ili odgovarajući sistem za upravljanje ključevima), nikad samo lokalno na istom serveru koji ključ štiti
• Koristiti TPM (Trusted Platform Module) gde je fizički dostupan, radi automatske, transparentne dekripcije pri pokretanju bez potrebe za ručnim unosom ključa pri svakom restartu

Ovim se zaokružuje treći deo, i sa njim širi pregled OS-nivoa hardeninga na serveru. Sledeći deo serije bavi se Windows Update disciplinom i upravljanjem ranjivostima na nivou operativnog sistema — kako uspostaviti realan, održiv ciklus zakrpa bez stalnog balansiranja između bezbednosti i stabilnosti produkcije.