Windows Server Hardening – Deo 4: Windows Update disciplina i upravljanje ranjivostima

Prethodna tri dela serije bavila su se konfiguracijom — baseline, pristupom, firewall-om, lokalnim politikama. Četvrti deo se bavi disciplinom koja mora da postoji kontinuirano, ne kao jednokratno podešavanje: redovnom primenom bezbednosnih ažuriranja. Ovo je tema koja zvuči jednostavno — "samo instaliraj zakrpe" — a u praksi je jedan od najčešćih izvora i bezbednosnih incidenata i operativnih problema, u zavisnosti od toga da li je urađena prebrzo ili presporo.

Zašto ni prebrzo ni presporo ne funkcioniše

Dve krajnosti podjednako loše ispadaju. Prva: primena svake zakrpe odmah po objavljivanju, bez ikakvog testiranja, jer "bezbednost je prioritet" — ovo povremeno dovodi do neplaniranog prekida rada, kad zakrpa unese regresiju ili sukobi se sa specifičnom konfiguracijom servera. Druga, češća u praksi: odlaganje ažuriranja mesecima ili godinama "dok se ne nađe prozor za održavanje", što ostavlja server izložen ranjivostima koje su već javno poznate i aktivno se iskorišćavaju. Cilj discipline opisane u ovom tekstu je da izbegne obe krajnosti — strukturiran, ponovljiv proces koji je dovoljno brz da zatvori realan rizik, a dovoljno pažljiv da ne izazove sopstvene probleme.

WSUS je u fazi gašenja — vreme je za plan

Windows Server Update Services (WSUS), dugogodišnji standardni alat za centralizovanu distribuciju ažuriranja unutar domena, zvanično je označen kao deprecated od strane Microsoft-a u septembru 2024. Alat i dalje radi i ima najavljenu podršku bar do 2035. godine, ali neće dobijati nove funkcionalnosti niti dalji razvoj. Za organizacije koje trenutno oslanjaju svoju infrastrukturu ažuriranja isključivo na WSUS, ovo nije razlog za paniku, ali jeste jasan signal da migraciju treba uključiti u srednjoročno planiranje, ne odlagati je do trenutka kad podrška zaista prestane.

Šta treba uraditi

• Ako je WSUS trenutno u upotrebi, tretirati ga kao stabilno, ali privremeno rešenje — ne ulagati dalje u proširenje njegove uloge, i početi evaluaciju alternativa (Windows Update for Business sa deployment ringovima, Azure Update Manager, ili komercijalni alati za patch management) u narednom planskom ciklusu
• Za nove implementacije ili veće infrastrukturne promene, razmotriti direktno uvođenje modernijeg rešenja umesto proširenja postojeće WSUS instalacije
• Bez obzira na alat, obezbediti da postoji centralizovan pregled statusa ažuriranja za sve servere — koji server je ažuriran, koji čeka, i koji je neuspešno primenio poslednju turu zakrpa

Fazna primena — "prvo pilot, zatim šire, izuzeci na kraju"

Osnovni obrazac koji se pokazao pouzdanim, nezavisno od konkretnog alata, jeste fazna primena kroz grupe (rings): manja pilot grupa servera prima ažuriranje prva, zatim šira grupa nakon što pilot prođe bez problema, a servere sa posebnim, dokumentovanim razlogom za odlaganje tretirati kao izuzetak koji zahteva eksplicitno obrazloženje, ne kao podrazumevano stanje.

Šta treba uraditi

• Definisati bar dve do tri grupe servera prema toleranciji na rizik i osetljivosti na prekid rada — pilot grupa (manje kritični, lakše se oporavljaju), produkciona grupa, i eventualno posebno osetljiva grupa sa duže planiranim prozorom testiranja
• Postaviti realno vreme zadržavanja između faza — dovoljno da se uoče problemi koji se ne ispolje odmah (npr. sedam do četrnaest dana između pilot i šire primene za rutinska mesečna ažuriranja)
• Za domain kontrolere i SQL servere iz prethodnih serija na ovom blogu, primenjivati posebno pažljiv, uvek ručno potvrđen proces, uz prethodno proveren i validan backup pre primene — u skladu sa preporukama iz AD i MSSQL hardening serije
• Voditi evidenciju izuzetaka (koji server, zašto je odložen, do kada) — izuzetak bez roka i bez vlasnika ima tendenciju da postane trajno, neopravdano stanje

Napomena o riziku: i sama primena zakrpa nosi operativni rizik — ažuriranje može uneti regresiju, promeniti ponašanje servisa, ili zahtevati restart u trenutku koji nije usklađen sa poslovnim potrebama. Uvek imati proveren plan povratka na prethodno stanje (rollback) pre primene na produkcione servere, i nikad ne primenjivati ažuriranja na kritične sisteme van planiranog prozora za održavanje, osim u slučaju hitne bezbednosne potrebe opisane u nastavku teksta.

Prioritizacija po riziku, ne po datumu objavljivanja

Mesečni ciklus ažuriranja (npr. Microsoft-ov "Patch Tuesday") donosi veliki broj zakrpa odjednom, često i preko stotinu ranjivosti u jednom ciklusu. Primena svih redom istim tempom, bez razlikovanja ozbiljnosti, nije realan pristup za tim sa ograničenim vremenom — prioritet treba da određuje stvarni rizik, ne samo formalna CVSS ocena ranjivosti.

Koristan, praktičan orijentir je CISA-in katalog poznato iskorišćavanih ranjivosti (Known Exploited Vulnerabilities, KEV) — spisak ranjivosti za koje postoji potvrda da se aktivno iskorišćavaju u stvarnim napadima, ne samo teorijski. Iako je zvanično obavezujući samo za američke federalne agencije, spisak je javno dostupan i predstavlja koristan, konkretan signal za bilo koju organizaciju: ranjivost na ovom spisku zaslužuje mnogo brži odgovor od ranjivosti sa istom CVSS ocenom koja se ne nalazi na njemu.

Vredi napomenuti da je CISA sredinom 2026. godine dodatno pooštrila svoj pristup (Binding Operational Directive 26-04), zamenivši raniji, jednoobrazni rok od 14 dana modelom koji razlikuje rizik prema izloženosti sistema internetu, statusu na KEV katalogu, mogućnosti automatizovanog iskorišćavanja i težini posledice — sa rokovima koji, za najkritičnije kombinacije, iznose svega tri dana. Ovo direktno ne obavezuje organizacije van američke federalne uprave, ali jasno pokazuje pravac u kojem se pomera očekivanje o brzini reagovanja u industriji.

Šta treba uraditi

• Redovno proveravati da li neka od ranjivosti pokrivenih tekućim ciklusom ažuriranja postoji na CISA KEV katalogu ili sličnom javnom izvoru potvrđenog aktivnog iskorišćavanja
• Za servere direktno izložene internetu (veb serveri, RD Gateway, VPN uređaji), primenjivati znatno kraći rok reagovanja na kritične, aktivno iskorišćavane ranjivosti nego za interne servere bez direktne izloženosti
• Uspostaviti poseban, ubrzan proces za hitne (out-of-band) zakrpe — kad Microsoft objavi ispravku van redovnog mesečnog ciklusa zbog ozbiljnosti ranjivosti, taj proces mora moći da zaobiđe standardni prozor čekanja između faza, uz i dalje minimalno, ali stvarno testiranje
• Kombinovati CVSS ocenu, status na KEV katalogu i stvarnu izloženost sistema (da li je dostupan sa interneta, da li čuva osetljive podatke) pri određivanju redosleda primene, umesto da se ranjivosti obrađuju isključivo po datumu objavljivanja

Napomena o riziku: ubrzan, hitan proces primene zakrpa (out-of-band) po definiciji ima manje vremena za testiranje nego redovan ciklus, što povećava šansu da se zakrpa primeni bez potpune provere kompatibilnosti sa specifičnom konfiguracijom servera. Ovaj rizik treba svesno prihvatiti kao kompromis samo za ranjivosti sa potvrđenim aktivnim iskorišćavanjem — za sve ostalo, standardan, testiran ciklus ostaje bezbedniji izbor, čak i ako deluje sporije.

Verifikacija da je ažuriranje zaista uspešno primenjeno

Poslednji, često preskočen korak: potvrda da je ažuriranje stvarno, u potpunosti primenjeno, ne samo da je proces "prijavio uspeh". Neuspešna instalacija koja izgleda uspešno u konzoli za upravljanje jedan je od najčešćih razloga zašto server ostaje ranjiv mesecima nakon što je tim uveren da je zakrpljen.

Šta treba uraditi

• Nakon svake faze primene, proveriti stvarni status instaliranih ažuriranja na serverima (ne samo status zadatka u alatu za distribuciju), uključujući proveru da li je zahtevani restart zaista izvršen
• Voditi izveštaj o usklađenosti (compliance) po serveru — koji procenat servera je na najnovijem nivou zakrpa, i koji su izuzeci sa jasnim razlogom
• Periodično (nezavisno od redovnog ciklusa ažuriranja) pokrenuti sken ranjivosti nad celom serverskom infrastrukturom, kao nezavisnu proveru da li stvarno stanje odgovara onome što alat za patch management prijavljuje

Ovim se zaokružuje četvrti deo Windows Server hardening serije. Sledeći deo bavi se PowerShell bezbednošću — logovanjem izvršenih komandi, Constrained Language Mode-om pomenutim u trećem delu, i razlikom između legitimne administrativne upotrebe i obrazaca koji ukazuju na zloupotrebu ovog moćnog alata od strane napadača koji se već nalazi unutar mreže.