VMware Hardening – Deo 2: vCenter Server – autentifikacija, RBAC i zaštita baze

Prvi deo serije pokrio je ESXi — pojedinačni hipervizor. Drugi deo prelazi na vCenter Server — centralnu tačku koja upravlja svim ESXi hostovima, klasterima i virtuelnim mašinama u infrastrukturi. Ovo čini vCenter posebno atraktivnom metom: kompromitacija jednog ESXi hosta pogađa VM-ove na tom hostu, ali kompromitacija vCenter-a potencijalno daje kontrolu nad celom virtuelizovanom infrastrukturom odjednom. Isti princip koji smo naglasili za etcd u Kubernetes seriji na ovom blogu — komponenta koja centralno upravlja svime iznad sebe zaslužuje nesrazmerno veću pažnju od pojedinačnih delova kojima upravlja.

RBAC u vCenter-u — tri elementa koja moraju postojati zajedno

vCenter implementira Role-Based Access Control po principu sličnom onom opisanom za Kubernetes u ranijoj seriji, samo sa vlastitom terminologijom. Permisija u vCenter-u nastaje iz tri odvojena elementa koja moraju postojati zajedno: korisnik ili grupa (ko), rola (skup privilegija — šta sme), i objekat u hijerarhiji inventara (na čemu — cela vCenter instanca, konkretan datacenter, klaster, ili pojedinačan VM). Nedostatak bilo kog od ova tri elementa znači da pristup nije dodeljen — sama rola, definisana ali nikad dodeljena nikome ni na jednom objektu, ne daje ništa nikom, isti princip razdvajanja definicije od dodele opisan za Kubernetes Role/RoleBinding par.

Podrazumevano, korisnik bez ijedne dodeljene role ne može uopšte da se poveže na vCenter (ekvivalent "No Access" role) — ovo je "default deny" polazna tačka, dobra vest za bezbednost, ali stvarna vrednost dolazi iz toga kako se dozvole dalje grade iznad te osnove.

Šta treba uraditi

• Dodeljivati permisije preko AD grupa, nikad preko lokalnih vCenter naloga ili pojedinačnih korisnika — isti princip koji se provlači kroz svaku seriju na ovom blogu, ovde sa dodatnim naglaskom da lokalni vCenter nalozi ne prate centralnu AD politiku lozinki niti proces deprovizioniranja pri odlasku zaposlenog
• Kreirati prilagođene (custom) role sa tačno potrebnim privilegijama umesto rutinske dodele ugrađene Administrator role — Administrator rola nosi široke mogućnosti (uključujući, po difoltu, interakciju sa fajlovima i programima unutar gostujućeg operativnog sistema VM-a) koje većina administratora stvarno nikad ne koristi, a čije prisustvo širi štetu ako nalog bude kompromitovan
• Grupisati objekte u foldere prema stvarnoj organizacionoj ili timskoj podeli (npr. po odeljenju, po timu, po nivou osetljivosti radnog opterećenja), i dodeljivati permisije na nivou tih foldera umesto pojedinačno na svaki VM — ovo drastično pojednostavljuje upravljanje pri rastu infrastrukture
• Koristiti Global Permissions (koje važe kroz sve vCenter instance povezane u istom SSO domenu) izuzetno oprezno i retko — širina ove opcije čini je lako podložnom greškom u dodeli šireg pristupa nego što je nameravano
• Pre dodele restriktivne role bilo kojoj grupi, proveriti da ta grupa slučajno ne uključuje već postojeće administratore — nenamerno se restriktivna rola može primeniti i na naloge koji su u drugom kontekstu trebalo da zadrže puna prava, ako je grupno članstvo šire nego što je administrator pretpostavio

Napomena o riziku: mrežne privilegije (dozvola da se VM poveže na drugačiji virtuelni switch ili port grupu) zaslužuju posebnu pažnju u multi-tenant ili segmentisanim okruženjima — korisnik sa ovom privilegijom teoretski može premestiti VM sa jedne mreže (npr. interne, poverljive) na drugu (npr. javno dostupnu), zaobilazeći mrežnu segmentaciju koja je inače pažljivo postavljena na nivou samog vSwitch-a. Ograničiti ovu privilegiju na uzak krug administratora kojima je stvarno potrebna, ne dodeljivati je uz standardni "VM management" paket privilegija bez posebnog razmišljanja.

Break-glass nalog — plan za slučaj da SSO postane nedostupan

Vredi eksplicitno planirati scenario u kojem centralni identity provajder (AD ili federisani provajder poput Entra ID-a) postane privremeno nedostupan — bez rezervnog puta pristupa, ceo administratorski tim ostaje zaključan van vCenter-a upravo u trenutku kad je najverovatnije da će im pristup biti hitno potreban (istraga incidenta, oporavak nakon pada).

Šta treba uraditi

• Zadržati tačno jedan, dobro dokumentovan lokalni "break-glass" administratorski nalog u vCenter SSO domenu, nezavisan od spoljne identity federacije, za tačno ovaj scenario
• Postaviti dugu, nasumično generisanu lozinku za taj nalog, čuvanu na bezbednoj, fizički odvojenoj lokaciji (isti princip čuvanja kritičnih kredencijala opisan kroz svaku prethodnu seriju), sa jasnim, ograničenim krugom ljudi koji imaju pristup toj lokaciji
• Auditirati svaku upotrebu break-glass naloga sa najvišim prioritetom — svaka prijava pod tim nalogom, bez izuzetka, treba da pokrene proveru i potvrdu da je upotreba bila legitimna i planirana
• Periodično (bar godišnje) testirati da break-glass nalog stvarno radi — nalog koji se nikad ne testira može tiho prestati da funkcioniše (istekla lozinka, izmenjena politika) i biti otkriven kao neispravan tačno u trenutku kad je hitno potreban

Zaštita administratora vCenter host mašine — poseban, često zaboravljen sloj

Ovo je razlika koju vredi eksplicitno naglasiti, jer je lako previdi. RBAC opisan ranije u tekstu kontroliše ko sme šta preko vCenter aplikacije same — ali vCenter Server Appliance (VCSA) je sama po sebi virtuelna mašina koja radi na nekom ESXi hostu, sa sopstvenim operativnim sistemom (Photon OS) i sopstvenom administracijom (VAMI — vCenter Appliance Management Interface, dostupan preko porta 5480). Neko sa administratorskim pristupom toj osnovnoj mašini — bilo direktno, bilo kroz kompromitaciju hipervizora na kojem VCSA radi — može zaobići svu pažljivo postavljenu vCenter RBAC strukturu, jer ima pristup ispod tog sloja, isti princip "sloj ispod poništava zaštitu sloja iznad" koji se provlači kroz svaku seriju o virtuelizaciji i infrastrukturi na ovom blogu.

Šta treba uraditi

• Ograničiti pristup VAMI interfejsu (port 5480) na isti uzak, upravljački mrežni segment kao i ostatak administrativnog pristupa, ne ostavljati ga dostupnim iz šire, korisničke mreže
• Ograničiti ko ima administratorski pristup samom ESXi hostu ili klasteru na kojem VCSA radi — ovi ljudi imaju, faktički, mogućnost da zaobiđu vCenter RBAC u celini, i treba ih tretirati sa istim nivoom poverenja kao i pun vCenter Administrator pristup
• Postaviti VCSA na dedikovan, dobro zaštićen host ili klaster, po istom principu izdvajanja kritične infrastrukture opisanom u Hyper-V hardening seriji za virtuelizovane domain kontrolere

Sertifikati — kičma poverenja koja se lako zaboravi

vCenter se u velikoj meri oslanja na TLS sertifikate za sopstvenu unutrašnju i spoljnu komunikaciju (MACHINE_SSL_CERT je centralni od njih). Istekao sertifikat ne samo da narušava poverenje veze — u praksi direktno prekida funkcionalnost, uključujući, konkretno i često viđeno u praksi, neuspešno izvršavanje redovnog file-based backup-a, jer backup mehanizam zahteva validnu TLS proveru identiteta pre nego što uopšte započne prenos podataka.

Šta treba uraditi

• Voditi jasnu evidenciju datuma isteka svih vCenter sertifikata (uključujući MACHINE_SSL_CERT i sertifikate povezanih servisa) i postaviti podsetnike dovoljno unapred da obnavljanje ne postane hitna, poslednja-minuta operacija
• Pre bilo koje izmene sertifikata, napraviti snapshot cele SSO domen infrastrukture (svi vCenter/PSC čvorovi u istom SSO domenu, ugašeni istovremeno pre snimanja) — ovo je eksplicitna, dokumentovana VMware preporuka upravo zbog toga koliko izmena sertifikata može poremetiti međusobno poverenje čvorova u istom SSO domenu ako nešto pođe po zlu
• Nakon zamene sertifikata, potvrditi da se redovan backup i dalje uspešno izvršava, ne pretpostaviti da je zamena sertifikata izolovana, bezopasna operacija bez daljih posledica

Backup vCenter-a — agentless, ugrađen, ali zahteva svesnu konfiguraciju

vCenter Server Appliance dolazi sa ugrađenom, besplatnom funkcijom file-based backup-a dostupnom kroz VAMI, koja štedi konfiguraciju, inventar i internu PostgreSQL bazu bez potrebe za dodatnim agentom — praktičan, agentless pristup sličan filozofiji opisanoj za etcd backup u Kubernetes seriji. Ipak, ova funkcija zahteva svesno podešavanje da bi imala stvarnu vrednost.

Šta treba uraditi

• Konfigurisati redovan, zakazan file-based backup kroz VAMI, sa enkripcijom uključenom (backup fajl zaštićen lozinkom) — po istom principu enkripcije backup podataka opisanom kroz MSSQL, Hyper-V i Kubernetes serije
• Čuvati backup na lokaciji odvojenoj od same vCenter/ESXi infrastrukture koju štiti — isti "izvan dometa istog kompromitovanog pristupa" princip ponovljen kroz svaku prethodnu seriju o backup-u
• Ako se koristi SMB kao odredište backup-a, potvrditi da odredišni server podržava SMB 3.0 — stariji SMB 1.0 serveri mogu tiho propustiti backup operaciju bez jasne greške, ostavljajući administratora sa lažnim osećajem da backup redovno uspeva
• Redovno testirati stvarnu restauraciju iz file-based backup-a na odvojenom, test okruženju — isti princip verifikacije ponovljen kroz svaku seriju o backup-u na ovom blogu, jer backup koji se nikad ne testira nosi rizik da otkrije svoj nedostatak tačno u trenutku kad je najpotrebniji

Napomena o riziku: file-based backup štiti konfiguraciju i inventar vCenter-a, ali ne zamenjuje backup samih VM-ova koje vCenter upravlja — to je odvojena tema, sa odvojenim, namenskim rešenjima. Ne meriti otpornost infrastrukture isključivo prema tome da li je vCenter file-based backup uključen; posmatrati ga kao jedan, neophodan, ali ne i dovoljan deo ukupne backup strategije za celu virtuelizovanu infrastrukturu.

Sledeći deo serije prelazi na mrežni sloj VMware infrastrukture — vSwitch/distributed switch segmentaciju, i posebno vMotion, čiji saobraćaj po difoltu putuje mrežom u čistom, nešifrovanom tekstu, sa svim posledicama koje to nosi za poverljivost podataka koji se prenose između hostova.