Hyper-V Hardening: Bezbednost hosta i virtuelizacione infrastrukture

Hyper-V je ugrađena, besplatna virtuelizaciona platforma dostupna u svakom Windows Server-u, i upravo zbog te dostupnosti se često koristi bez posebne bezbednosne pažnje — instalira se, VM-ovi se kreiraju, i infrastruktura radi godinama na podrazumevanim podešavanjima. Problem sa tim pristupom je fundamentalan: host je jedna tačka kontrole nad svime što radi na njemu. Ko god kompromituje host, ili dobije pristup na nivou hipervizora, dobija pristup svakom VM-u koji taj host pokreće — bez obzira na to koliko je pažljivo hardenovan operativni sistem unutar svakog pojedinačnog VM-a.

Zašto host-nivo hardening ima prioritet nad gostima

Ovo je princip koji smo već pomenuli u AD hardening seriji, u kontekstu virtuelizovanih domain kontrolera — administrator hipervizora efektivno postaje i administrator svakog VM-a koji taj hipervizor pokreće, bez obzira na to da li je ikad formalno dobio to ovlašćenje unutar samog gosta. Isti princip važi univerzalno, ne samo za domain kontrolere: bezbednost hosta je gornja granica bezbednosti svega što se na njemu izvršava. Zato hardening virtuelizacione infrastrukture mora početi od hosta, ne od gostujućih mašina.

Minimalna instalacija hosta

Windows Server nudi opciju instalacije Server Core — verziju bez grafičkog interfejsa, sa znatno manjim brojem instaliranih komponenti u odnosu na punu (Desktop Experience) instalaciju. Za Hyper-V host, ovo nije samo estetski izbor: svaka dodatna komponenta na hostu je potencijalna dodatna ranjivost, a host koji pokreće samo Hyper-V ulogu nema stvarnu potrebu za grafičkim interfejsom, veb pregledačem ili većinom ostalih uloga i funkcija.

Šta treba uraditi

• Instalirati Hyper-V host kao Server Core instalaciju gde god je to operativno izvodljivo, upravljajući njime daljinski preko Hyper-V Manager-a, Windows Admin Center-a ili PowerShell-a, umesto lokalno preko grafičkog interfejsa
• Ne instalirati na hostu nikakve dodatne uloge ili aplikacije van onoga što je striktno potrebno za virtuelizaciju — host nije mesto za pokretanje veb servera, fajl servisa ili bilo koje aplikacije koja bi trebalo da radi unutar VM-a
• Onemogućiti nepotrebne servise i funkcije koje dolaze uz podrazumevanu instalaciju, po istom principu smanjenja površine napada opisanom u seriji o hardeningu Windows Server-a
• Redovno ažurirati host — firmver, drajvere i sam operativni sistem — po disciplini opisanoj u toj seriji, sa dodatnim oprezom jer restart hosta znači istovremeni prekid rada svih VM-ova koje pokreće

Napomena o riziku: prelazak sa pune instalacije na Server Core na postojećem, već aktivnom hostu je netrivijalna migracija koja zahteva ponovnu instalaciju, ne prostu izmenu podešavanja — ovo planirati kao poseban projekat sa migracijom VM-ova na privremeni ili alternativni host, ne kao rutinsku izmenu konfiguracije. Za nove hostove, Server Core od početka izbegava ovaj problem u potpunosti.

Ograničavanje ko sme da upravlja hostom

Podrazumevano, svaki lokalni administrator hosta ima pun pristup Hyper-V Manager-u i svemu što se na hostu izvršava. Windows nudi posredan nivo — lokalnu grupu Hyper-V Administrators — koja omogućava upravljanje virtuelnim mašinama bez potrebe da član te grupe bude i pun lokalni administrator operativnog sistema hosta. Ovo je koristan alat za razdvajanje dužnosti (separation of duties), ali sa važnim ograničenjem koje treba imati na umu: član Hyper-V Administrators grupe i dalje ima praktičan pristup virtuelnim diskovima, konfiguracionim fajlovima i mogućnost izmene boot medija VM-a — mogućnosti dovoljno moćne da zahtevaju isti nivo pažnje kao i puna administrativna prava.

Šta treba uraditi

• Za timove ili pojedince kojima je potrebno upravljanje virtuelnim mašinama, ali ne i puna administracija operativnog sistema hosta, koristiti lokalnu Hyper-V Administrators grupu umesto dodele punog lokalnog administratorskog naloga
• Dodeljivati članstvo u ovoj grupi preko AD bezbednosnih grupa, ne pojedinačnih naloga, po istom principu opisanom u AD hardening seriji za OU delegaciju
• Tretirati članstvo u Hyper-V Administrators grupi kao privilegovanu ulogu koja zahteva redovnu reviziju, ne kao rutinsku dozvolu tehničke podrške — mogućnost pristupa virtuelnim diskovima i izmene konfiguracije VM-a nosi realan bezbednosni značaj
• Za finije razgraničenje (npr. jedan tim sme da pravi snapshot-ove, drugi sme da gasi/pali VM-ove, treći ima pun pristup), koristiti Authorization Manager (AzMan) za granularniju delegaciju na nivou pojedinačnih operacija, umesto svođenja svih ovlašćenja na binarni izbor "administrator ili ništa"

Mrežna izolacija — upravljanje, migracija i podaci na odvojenim putanjama

Uobičajena greška u manjim ili brzo rastućim okruženjima je da sav saobraćaj hosta — administrativni pristup, live migracija VM-ova između hostova, i sam mrežni saobraćaj virtuelnih mašina — prolazi kroz istu fizičku mrežu. Ovo znači da neko ko prisluškuje ili kontroliše taj jedan mrežni segment ima uvid u sve, uključujući i osetljiv saobraćaj live migracije, koji po difoltu ne mora biti enkriptovan.

Šta treba uraditi

• Razdvojiti mrežni saobraćaj na odvojene fizičke ili barem logički izolovane (VLAN) segmente: upravljanje hostom, live migracija VM-ova, saobraćaj samih virtuelnih mašina, i po potrebi odvojen segment za storage (npr. iSCSI ili SMB direktno povezan storage)
• Uključiti enkripciju za live migraciju saobraćaja — bez nje, memorijsko stanje VM-a (koje može uključivati osetljive podatke, pa i kredencijale trenutno u memoriji) putuje mrežom u čitljivom obliku tokom migracije
• Ograničiti administrativni pristup hostu (Hyper-V Manager, WinRM, RDP) isključivo sa upravljačke mreže, po istom principu segmentacije opisanom u seriji o hardeningu Windows Server-a
• Za VM-ove sa mrežnim pristupom ka internetu ili nepoverljivim mrežama, primenjivati firewall pravila i na nivou samog gosta, ne oslanjati se isključivo na segmentaciju na nivou hosta ili virtuelnog switch-a

Napomena o riziku: uvođenje mrežne segmentacije na već aktivnoj infrastrukturi (razdvajanje postojećeg jedinstvenog segmenta na više VLAN-ova) može privremeno prekinuti live migraciju, replikaciju ili pristup storage-u ako redosled izmena nije pažljivo isplaniran — proveriti i ažurirati sve konfiguracije koje referenciraju stare mrežne adrese ili opsege pre nego što se stari segment potpuno ukine, i sprovesti izmenu postepeno, host po host, ne za celu infrastrukturu odjednom.

Shielded VM i Guarded Fabric — najviši nivo izolacije

Za posebno osetljive radne opterećenje — VM-ovi koji nose podatke visoke vrednosti, ili scenarije gde ni administrator hosta ne bi trebalo da ima uvid u sadržaj gosta — Hyper-V nudi Shielded VM funkcionalnost. Shieled VM enkriptuje stanje virtuelne mašine i saobraćaj migracije, i ograničava administrativni pristup kritičnim funkcijama VM-a čak i za administratore hosta. Ovo zahteva Guarded Fabric infrastrukturu — poseban Host Guardian Service (HGS) klaster koji izdaje ključeve za pokretanje zaštićenih VM-ova, i hostove opremljene TPM 2.0 čipom sa uključenom proverom integriteta koda.

Šta treba uraditi

• Za standardne, rutinske radne opterećenje, standardna mrežna i administrativna izolacija opisana ranije u tekstu ostaje dovoljna — Shielded VM nije podrazumevani zahtev za svaku virtuelnu mašinu
• Za VM-ove sa posebno osetljivim podacima (npr. regulatorno osetljivi finansijski ili lični podaci, ili scenario gde je hosting infrastruktura van pune kontrole organizacije), razmotriti uvođenje Shielded VM i Guarded Fabric arhitekture
• Pre uvođenja, imati u vidu da Guarded Fabric dodaje realnu operativnu složenost — poseban HGS klaster (tipično tri čvora radi otpornosti na otkaz), zahtev za TPM 2.0 na svim hostovima, i dodatnu proceduru za svaki novi host koji se dodaje u fabric
• Koristiti Generation 2 VM-ove sa uključenim Secure Boot-om kao preduslov (i podrazumevano, korisno podešavanje i van konteksta Shielded VM-a) — ovo sprečava neovlašćen firmver, operativni sistem ili UEFI drajver da se pokrene pri startu VM-a

Snapshot-ovi (checkpoint-i) — praktičan alat, ali i bezbednosni rizik

Isti rizik koji smo opisali za snapshot-ove virtuelizovanih domain kontrolera u AD hardening seriji važi generalno za bilo koji VM: snapshot sadrži kompletno stanje diska i memorije u trenutku snimanja, uključujući sve što je u tom trenutku bilo u memoriji — potencijalno i kredencijale ili druge osetljive podatke. Nekontrolisano pravljenje ili čuvanje snapshot-ova, posebno za VM-ove sa osetljivim sadržajem, produžava vreme tokom kojeg ti podaci ostaju izloženi na disku hosta, van standardnih zaštita koje važe za samu produkcionu bazu ili aplikaciju.

Šta treba uraditi

• Ograničiti ko sme da pravi, čuva i briše snapshot-ove — ovo pravo ne treba da bude podrazumevano dostupno svima sa pristupom Hyper-V Manager-u
• Za VM-ove sa osetljivim podacima (domain kontroleri, baze podataka, sistemi sa ličnim ili finansijskim podacima), izbegavati dugotrajno čuvanje snapshot-ova kao zamenu za pravi backup — snapshot je namenjen kratkoročnom, privremenom stanju (npr. neposredno pre rizične izmene), ne dugoročnoj arhivi
• Audit-ovati kreiranje, čuvanje i brisanje snapshot-ova (Hyper-V administratorska aktivnost) kroz Windows Event Forwarding ili SIEM integraciju, po istom principu logovanja administrativne aktivnosti opisanom kroz prethodne serije na ovom blogu
• Enkriptovati skladište na kojem se čuvaju VHD/VHDX fajlovi i snapshot podaci (BitLocker na nivou hosta, ili enkripcija na nivou storage sistema), kako bi fizička krađa diska ili neovlašćen pristup skladištu ostali bez efekta bez odgovarajućeg ključa

Backup virtuelizovane infrastrukture

Isti principi opisani u seriji o hardeningu MSSQL backup-a važe i ovde, samo na nivou cele virtuelne mašine umesto pojedinačne baze — backup VM-a sadrži sve što VM sadrži, i zaslužuje istu pažnju kao i produkcija koju štiti.

Šta treba uraditi

• Čuvati backup virtuelnih mašina odvojeno od produkcione virtuelizacione infrastrukture — isti "izvan dometa istog kompromitovanog naloga" princip opisan za MSSQL backup fajlove
• Enkriptovati backup podatke i čuvati ključeve odvojeno, po istom principu opisanom za TDE i backup enkripciju u MSSQL seriji
• Razmotriti immutable (WORM) skladište za bar deo backup rotacije, posebno za kritične VM-ove, kao zaštitu od ransomware scenarija koji cilja i produkciju i njen backup istovremeno
• Redovno testirati stvarnu restauraciju cele virtuelne mašine, ne samo proveru da backup fajl postoji — isti princip verifikacije opisan u MSSQL seriji, ovde primenjen na ceo VM umesto na pojedinačnu bazu

Napomena o riziku: agentless backup rešenja koja komuniciraju direktno sa API-jem hipervizora smanjuju potrebu za softverom unutar svakog gosta, ali istovremeno znače da nalog ili servis koji ima taj API pristup poseduje veoma širok, efektivno privilegovan pristup celoj infrastrukturi — tretirati kredencijale backup rešenja sa istim nivoom pažnje kao i administratorski pristup samom hipervizoru, uključujući ograničen pristup i redovnu reviziju tih kredencijala.

Ovim je pokrivena osnova bezbednosti Hyper-V virtuelizacione infrastrukture — hardening hosta, kontrola pristupa, mrežna izolacija, napredna izolacija za posebno osetljive slučajeve, i zaštita snapshot-ova i backup-a. Kao i kod prethodnih serija na ovom blogu, princip koji povezuje sve ove mere je isti: bezbednost sloja ispod (ovde, hipervizora) postavlja gornju granicu za sve što se gradi iznad njega, bez obzira na to koliko je pažljivo hardenovan sadržaj svakog pojedinačnog VM-a.