VMware

Bezbednost vSphere platforme ne završava se uspešnom prijavom, ispravno dodeljenom ulogom ili važećim sertifikatom. Lekcija 42 uspostavila je identitet i kontrolu pristupa; sada taj model proširujemo na integritet hosta, kriptografsku zaštitu virtuelnih mašina i podataka, smanjenje površine napada, zapisivanje administratorskih aktivnosti i dokazivanje da su dogovorene kontrole zaista primenjene. Cilj nije da se bez razumevanja uključi što više opcija, već da se izgradi proverljiv sistem u kome svaka kontrola ima vlasnika, razlog, očekivano stanje, način validacije i bezbedan postupak za izuzetak ili oporavak.

Produkcioni hardening je upravljanje rizikom i promenama. Prestroga kontrola može prekinuti podržanu integraciju, onemogućiti recovery pristup ili ostaviti host nedostupnim posle restarta; preslaba kontrola može omogućiti neovlašćenu administraciju, učitavanje neproverenog koda ili iznošenje podataka. Zbog toga se bezbednosna smernica najpre prevodi u tehničku kontrolu, zatim testira na reprezentativnom sistemu, uvodi kontrolisanom promenom i na kraju potvrđuje dokazima koji se mogu ponoviti.

1. Od bezbednosne smernice do merljive kontrole

Hardening je sistematsko uklanjanje nepotrebnih mogućnosti, bezbedno podešavanje potrebnih servisa i smanjivanje verovatnoće i posledice zloupotrebe. Za vSphere to obuhvata ESXi, vCenter Server Appliance, virtuelne mreže, administrativne protokole, naloge, logove, kriptografske servise, virtuelne mašine i spoljne zavisnosti kao što su DNS, NTP, syslog, backup i Key Management Server (KMS). Hardening nije jednokratna instalaciona faza: update, novi drajver, promena integracije ili novi regulatorni zahtev mogu promeniti prihvatljivo stanje.

Zvanični vSphere Security Configuration and Controls dokumenti predstavljaju početnu referencu, ali se kontrolni skup mora vezati za tačnu verziju i build proizvoda. Kontrola namenjena vSphere 8.0 Update 3 ne primenjuje se automatski na starije izdanje, a preporuka nije isto što i fabrička podrazumevana vrednost. Organizacija zatim mapira relevantne kontrole na sopstvenu politiku i, kada je potrebno, na CIS Benchmark, DISA STIG ili drugi ugovorni/regulatorni okvir. Za svako odstupanje potrebni su procena rizika, kompenzujuća kontrola, vlasnik i datum ponovne provere.

2. Hardening ESXi hosta i vCenter Server Appliance-a

2.1. Smanjenje upravljačke površine napada

ESXi je namenski hipervizor, ali svaki omogućen servis, firewall izuzetak i lokalni nalog povećava površinu napada. SSH i ESXi Shell treba da budu zaustavljeni kada nisu potrebni, sa politikom pokretanja koja ih neće neočekivano vratiti posle restarta. Privremeno uključivanje mora imati odobren razlog, ograničeno trajanje i događaj koji se može povezati sa ticketom. Ugrađeni alarm za omogućene Shell/SSH servise nije smetnja koju treba trajno utišati, već signal da operativni izuzetak traje.

ESXi firewall nije zamena za mrežnu segmentaciju. Management VMkernel interfejsi treba da budu dostupni samo sa administrativnih mreža i kontrolisanih jump hostova, dok vMotion, storage i drugi infrastrukturni tokovi dobijaju zasebne VLAN-ove i pravila. CIM provider, SNMP, WBEM, NTP/PTP i agentski VIB-ovi ostaju uključeni samo kada imaju dokumentovanu zavisnost. Uklanjanje servisa bez provere može prekinuti monitoring, backup, multipathing ili vendor podršku; zato se zavisnost dokazuje pre promene.

2.2. Lockdown Mode i kontrolisani direktni pristup

Lockdown Mode usmerava redovnu administraciju ESXi hosta kroz vCenter Server. U normalnom režimu DCUI može ostati dostupan ovlašćenim korisnicima sa odgovarajućom privilegijom; strict režim zaustavlja DCUI servis i podiže zaštitu, ali povećava recovery rizik ako je vCenter nedostupan. Exception users nisu lista administratora za svakodnevni rad: namenjeni su servisnim nalozima koji moraju direktno pristupati hostu i ne dobijaju privilegije samim upisom na listu. Svaki izuzetak zato zahteva zasebno ovlašćenje i periodičnu proveru.

Pre aktiviranja strict režima mora postojati testiran plan za gubitak vCenter-a, funkcionalna out-of-band konzola servera, poznata procedura izlaska iz režima i nadzirani break-glass identitet. Lockdown Mode ne rešava kompromitovan vCenter: on centralizuje upravljanje, pa bezbednost, dostupnost i backup vCenter-a postaju još važniji.

2.3. Host image, acceptance level i konfiguracioni drift

vSphere Lifecycle Manager desired image iz lekcije 41 kontroliše deklarisani softverski sastav klastera; Secure Boot proverava kriptografski lanac pri pokretanju; hardening baseline proverava konfiguraciju. To su povezane, ali različite kontrole. Potpisan paket može biti ranjiv ili nepotreban, host može imati ispravan image a nebezbedna podešavanja, a usklađena konfiguracija ne dokazuje integritet boot lanca. Acceptance level ne treba snižavati radi instaliranja nepotvrđenog VIB-a bez vendor potvrde, laboratorijskog testa i plana uklanjanja.

Za ponovljivu konfiguraciju mogu se koristiti Host Profiles kada ih konkretno izdanje i licenca podržavaju, a u novijim vSphere 8 izdanjima i vSphere Configuration Profiles odnosno desired configuration pristup. Funkcionalnost i podržani skup podešavanja razlikuju se po verziji; zato se ne pretpostavlja da alat obuhvata svaku security kontrolu. Rezultat alata je ulaz u proveru, ne konačni dokaz sam po sebi.

3. UEFI Secure Boot – integritet lanca pokretanja

UEFI Secure Boot uspostavlja lanac poverenja od firmware-a do ESXi boot komponenti. Firmware proverava potpis bootloader-a, a ESXi nastavlja proveru potpisanih komponenti. Kontrola sprečava pokretanje neovlašćeno izmenjenog koda u tom lancu, ali ne šifruje disk, ne zamenjuje patching i ne dokazuje da je svaka runtime konfiguracija bezbedna. Legacy BIOS boot nije isto što i UEFI Secure Boot.

Pre uključivanja u firmware-u treba proveriti kompatibilnost servera i instaliranih VIB-ova, boot režim postojeće instalacije, vendor dokumentaciju i mogućnost povratka preko out-of-band konzole. Promena BIOS/UEFI boot režima na postojećem hostu može učiniti sistem nebootabilnim. Produkcioni postupak zato podrazumeva evakuaciju workload-a, maintenance mode, proveru image-a, backup konfiguracije, promenu kroz odobren maintenance window i validaciju posle restarta.

Sledeća read-only provera izvršava se kao root u ESXi Shell-u ili preko kontrolisanog SSH pristupa. Prva komanda proverava da li su instalirani VIB-ovi kompatibilni sa Secure Boot-om; druga prikazuje trenutno stanje. Ne uključuju Secure Boot i ne menjaju firmware.

/usr/lib/vmware/secureboot/bin/secureBoot.py -c
esxcli system settings encryption get

Očekuje se potvrda da se Secure Boot može bezbedno omogućiti i, nakon firmware promene i restarta, da je Secure Boot prikazan kao uključen. Nazivi polja u izlazu mogu se razlikovati između izdanja. Ako compatibility provera navede VIB, ne uklanjati ga naslepo: utvrditi vlasnika, funkciju, OEM image zavisnost i podržanu zamenu. Dokaz treba da sadrži host, build, vreme provere, rezultat i vezu ka odobrenoj promeni.

4. Fizički TPM 2.0, atestacija hosta i recovery ključ

Fizički Trusted Platform Module 2.0 je hardverski koren poverenja servera. ESXi meri relevantne delove boot procesa u TPM registre, a vCenter koristi atestaciju da proceni da li je host pokrenut u očekivanom stanju. TPM ne „čini host bezbednim” samostalno: potrebni su podržani hardware/firmware, UEFI Secure Boot, pravilno vreme i DNS, zdrava komunikacija sa vCenter-om i odgovarajući ESXi image metadata.

Od vSphere 7.0 Update 2, host sa aktivnim TPM 2.0 može koristiti TPM za zaštitu ESXi konfiguracije. Tada recovery ključ postaje kritičan za oporavak ako TPM ili matična ploča budu zamenjeni, firmware bude resetovan ili host više ne može da otključa konfiguraciju. Alarm da recovery ključ nije backupovan ne treba samo potvrditi i sakriti: ključ se preuzima po zvaničnoj proceduri, čuva u odobrenom sistemu tajni sa kontrolom pristupa i testira kroz dokumentovani recovery scenario. Ključ se nikada ne stavlja u ticket, chat, nezaštićeni CSV ili javni repozitorijum.

4.1. Tumačenje neuspešne atestacije

Alarm Host TPM attestation prvo se tretira kao signal narušenog poverenja, ne kao razlog za trenutno brisanje ključeva ili reset TPM-a. Beleže se vreme pojave, obim hostova, poslednji firmware/BIOS/ESXi update, promena matične ploče ili TPM-a i status Secure Boot-a. Zatim se proveravaju vCenter događaji i /var/log/vmware/vpxd/vpxd.log na VCSA, uz ESXi /var/log/vmkernel.log, /var/log/hostd.log i boot logove. Vreme događaja mora biti korelisano između sistema.

Neposredni uzrok može biti isključen Secure Boot, nedostajući image profile metadata, promenjen TPM identity ili problem komunikacije. Osnovni uzrok može biti neodobrena firmware promena, pogrešan redosled zamene hardware-a, image koji nije uveden podržanim putem ili proces promene koji nije sačuvao recovery materijal. Privremeno zaobilazno rešenje ne sme postati trajno: reset TPM-a, ponovno povezivanje hosta ili intervencija u vCenter bazi sprovode se samo prema odgovarajućem Broadcom KB-u i, kada je potrebno, uz podršku proizvođača.

5. Key provider arhitektura i životni ciklus ključeva

vCenter posreduje između kriptografskih potrošača i key provider-a. Standard Key Provider koristi spoljne KMIP-kompatibilne KMS servere i zahteva projektovanje njihove dostupnosti, sertifikata, mrežnih putanja, backup-a i disaster recovery-ja. vSphere Native Key Provider (NKP), dostupan od vSphere 7.0 Update 2, ugrađen je u vCenter i smanjuje potrebu za spoljnim KMS-om, ali njegov backup je obavezan pre oslanjanja na provider. U okruženjima sa vSphere Trust Authority postoji i Trusted Key Provider, vezan za poseban trust model i atestaciju; to nije samo druga etiketa za standardni KMS.

Izbor zavisi od regulatornog zahteva, broja vCenter instanci, zahteva za razdvajanjem dužnosti, postojećeg enterprise KMS-a, DR arhitekture i podržane verzije/licence. KMS ili key provider ne sme biti pojedinačna tačka otkaza. Ako vCenter ili host ne mogu da dobiju potreban ključ, uključena VM može neko vreme nastaviti rad, ali power-on, migracija, reconfiguration ili recovery mogu biti blokirani. Zato se testira i normalan rad i ponašanje pri nedostupnosti servisa.

5.1. Obavezni kontrolni elementi

• Key provider ima jasno ime, vlasnika, namenu i dokumentovan trust postupak.
• Za spoljni KMS postoje najmanje dve podržane instance kada arhitektura to zahteva, nezavisne putanje i nadzor sertifikata.
• NKP je backupovan u šifrovanom obliku, backup lokacija je odvojena od vCenter-a, a lozinka nije uskladištena uz backup.
• Cryptographic privileges su dodeljene zasebnim ulogama po principu najmanjih privilegija.
• Postoje procedure za rotaciju, obnovu sertifikata, restore vCenter-a i povratak šifrovanih VM-ova.
• Brisanje provider-a ili ključa je zabranjena ad hoc operacija: pre toga se dokazuje da nijedan objekat više ne zavisi od njega.

6. VM Encryption, vTPM i šifrovanje vSAN-a

6.1. VM Encryption

vSphere VM Encryption je policy-based zaštita VM datoteka i virtuelnih diskova na nivou hipervizora. Ne zahteva da guest OS zna za enkripciju i može štititi VM nezavisno od osnovnog datastore tipa, ali zahteva konfigurisan key provider, odgovarajuće privilegije, kompatibilne hostove i plan za backup/recovery ključeva. Enkripcija povećava bezbednost podataka u mirovanju, ali ne štiti podatke od administratora ili procesa koji im legitimno pristupa dok je VM pokrenuta.

Enkripcija menja operativni model. Backup proizvod, replikacija, snapshot tok, hot-add, cross-vCenter migracija i disaster recovery moraju eksplicitno podržavati šifrovane VM-ove i odgovarajući key-provider trust. CPU overhead je na modernom podržanom hardware-u često nizak zahvaljujući kriptografskim instrukcijama, ali se ne pretpostavlja: meri se na reprezentativnom workload-u. Usklađenost storage policy-ja i uspešan restore važniji su dokaz od same oznake „Encrypted”.

6.2. Virtual TPM

vTPM izlaže TPM 2.0 uređaj guest operativnom sistemu za funkcije kao što su measured boot, čuvanje ključeva ili BitLocker. Dodavanje vTPM-a zahteva EFI firmware i key provider. vSphere kriptografski štiti datoteke koje sadrže osetljivi vTPM state; to ne znači nužno da su svi VMDK diskovi VM-a obuhvaćeni punom VM Encryption politikom. Ovu razliku treba proveriti u storage policy stanju, a ne zaključivati samo iz prisustva vTPM uređaja.

Kloniranje, template, export/import i migracija vTPM VM-a imaju dodatna bezbednosna pravila jer kopiranje TPM identiteta može proizvesti neželjene duplikate. Za podržane tokove bira se kreiranje novog TPM identiteta kada je cilj nova mašina; zadržavanje identiteta opravdano je samo kada se ista VM premešta ili oporavlja i aplikativni slučaj to zahteva.

6.3. vSAN Data-at-Rest i Data-in-Transit Encryption

vSAN enkripcija pripada storage sloju i razlikuje se od VM Encryption-a. Data-at-Rest Encryption štiti podatke na vSAN uređajima; Data-in-Transit Encryption štiti vSAN mrežni saobraćaj između hostova. Njihov obim, key management, rekey postupci i uticaj na operacije nisu isti. Uključivanje jedne kontrole ne dokazuje prisustvo druge, niti automatski zadovoljava zahtev da pojedinačna VM ostane šifrovana pri migraciji na drugi datastore.

7. Audit trag, centralno logovanje i dokaz usklađenosti

Audit trag mora odgovoriti ko je, kada, odakle, nad kojim objektom i sa kakvim rezultatom izvršio operaciju. vCenter Tasks and Events pruža operativni kontekst, SSO audit događaji identitetski kontekst, a VCSA i ESXi logovi detalje komponenti. Nijedan pojedinačni izvor nije dovoljan za svaki incident. Tačno vreme je osnov korelacije, pa redundantni NTP izvori, nadzor vremenskog odstupanja i dosledna vremenska zona predstavljaju bezbednosnu kontrolu, ne samo administrativnu urednost.

Lokalni log na hostu može biti izgubljen kvarom boot medija, reinstalacijom ili napadom. Remote syslog zato treba da koristi redundantne kolektore, ograničene mrežne putanje, odgovarajuću zaštitu transporta i kontrolu pristupa. Samo upisana adresa syslog servera nije dokaz: generiše se bezbedan test događaj, potvrđuje prijem na kolektoru, proverava pravilno parsiranje polja i dokumentuje retencija. Ako je lokalni scratch nepostojan, mora se podesiti podržana persistent lokacija ili pouzdano udaljeno prikupljanje.

7.1. Paket dokaza

Dobar evidence package je ponovljiv i minimalno izlaže osetljive podatke. Sadrži obim i vreme prikupljanja, verziju/build, identitet alata i naloga koji je prikupljao podatke, odobren baseline, sirove rezultate ili njihov kontrolisani izvoz, listu odstupanja, ticket promene i zaključak odgovorne osobe. Screenshot može biti pomoćni dokaz, ali je slabiji od strukturisanog, vremenski označenog izvoza jer se teže pretražuje, poredi i automatizovano proverava. Lozinke, recovery ključevi, session tokeni i privatni ključevi moraju se redigovati pre prilaganja.

8. Bezbedna validacija pomoću CLI-ja i PowerCLI-ja

Sledeći PowerCLI primer je read-only inventar, izvršava se sa administrativne radne stanice nakon Connect-VIServer, nalogom koji ima samo privilegije za čitanje potrebnih objekata. Ne menja hostove. Rezultat je početni dokaz i treba ga povezati sa tačnom verzijom Security Controls dokumenta; lista nekoliko podešavanja nije kompletan hardening audit.

$report = foreach ($vmhost in Get-VMHost | Sort-Object Name) {
    $ssh = Get-VMHostService -VMHost $vmhost |
        Where-Object Key -eq 'TSM-SSH'

    $shell = Get-VMHostService -VMHost $vmhost |
        Where-Object Key -eq 'TSM'

    $lockdown = $vmhost.ExtensionData.Config.LockdownMode

    [pscustomobject]@{
        VMHost       = $vmhost.Name
        Version      = $vmhost.Version
        Build        = $vmhost.Build
        Connection   = $vmhost.ConnectionState
        LockdownMode = $lockdown
        SSHRunning   = $ssh.Running
        SSHPolicy    = $ssh.Policy
        ShellRunning = $shell.Running
        ShellPolicy  = $shell.Policy
    }
}

$report | Format-Table -AutoSize
$report | Export-Csv -Path './esxi-security-inventory.csv' -NoTypeInformation

CSV može sadržati infrastrukturne identifikatore i čuva se kao kontrolisani audit artefakt. Očekivani rezultat je po jedan red za svaki host, bez neočekivano aktivnih Shell/SSH servisa i sa dokumentovanim Lockdown stanjem. Host u maintenance ili disconnected stanju nije automatski „neusklađen”, ali zahteva objašnjenje i ponovnu proveru kada postane dostupan.

Sledeći primer čita izabrane advanced settings. Nazivi i preporučene vrednosti moraju se preuzeti iz vodiča za konkretnu verziju; primer demonstrira metod prikupljanja, ne univerzalni baseline.

$settingNames = @(
    'Security.AccountLockFailures',
    'Security.AccountUnlockTime',
    'UserVars.ESXiShellInteractiveTimeOut',
    'UserVars.ESXiShellTimeOut',
    'Syslog.global.logHost'
)

Get-VMHost | ForEach-Object {
    $vmhost = $_
    Get-AdvancedSetting -Entity $vmhost -Name $settingNames |
        Select-Object @{N='VMHost';E={$vmhost.Name}}, Name, Value
} | Sort-Object VMHost, Name

Za izmenu se koristi zaseban, odobren postupak sa Set-AdvancedSetting; on je state-changing i namerno nije spojen sa audit skriptom. Time se sprečava da prikupljanje dokaza neočekivano promeni sistem. Pre masovne korekcije proveravaju se verzija, tip vrednosti, zavisnosti i rollback vrednost na jednom laboratorijskom ili pilot hostu.

9. Praktikum – od baseline-a do proverljivog evidence package-a

Vežba 1: Read-only hardening pregled ESXi klastera

Cilj i kontekst: napraviti početni inventar bezbednosnog stanja klastera bez promene konfiguracije i izdvojiti odstupanja koja zahtevaju dalju proveru.

Topologija i preduslovi: jedan vCenter, klaster sa najmanje dva ESXi hosta i administratorska stanica sa podržanim VCF PowerCLI/PowerCLI modulima. Koristi se read-only nalog sa pristupom host konfiguraciji, Tasks and Events i alarmima. Potrebni su tačan NTP/DNS i odobrena lokacija za dokaze. Rizik je nizak; izvoz ipak sadrži nazive hostova i tretira se kao interni podatak.

1. U vSphere Client-u zabeležiti vCenter i ESXi verzije/buildove, aktivne alarme i vreme početka provere.
2. Za svaki host pregledati Configure → System → Security Profile: Lockdown Mode, Services i Firewall.
3. Pokrenuti read-only PowerCLI inventar iz prethodnog odeljka i sačuvati CSV uz ticket ili laboratorijski ID.
4. Uporediti rezultate sa zvaničnim Security Controls dokumentom za tačno izdanje, a ne sa baseline-om druge verzije.
5. Za svako odstupanje navesti očekivanu vrednost, stvarnu vrednost, poslovnu zavisnost, vlasnika i predloženu korekciju. Ne menjati stanje u ovoj vežbi.

Očekivani rezultat i validacija: broj redova u izveštaju odgovara broju hostova; nijedan objekat nije preskočen bez obrazloženja; GUI i PowerCLI stanje se poklapaju; svako odstupanje ima klasifikaciju „greška”, „odobren izuzetak”, „nije primenljivo” ili „zahteva podatke”. Kriterijum završetka je potpisana početna matrica, ne nula nalaza.

Troubleshooting: ako servis nije vraćen za host, prvo proveriti ConnectionState, dozvole i vCenter događaje. Ne povećavati privilegije naslepo. Ako PowerCLI svojstvo nije dostupno u datoj verziji, potvrditi stanje preko vSphere Client-a ili podržanog API-ja i dokumentovati metod.

Rollback: nije potreban jer je vežba read-only; obrisati samo lokalne privremene kopije koje nisu deo odobrenog evidence package-a.

Vežba 2: Laboratorijska provera Secure Boot-a i TPM atestacije

Cilj i kontekst: razlikovati kompatibilnost, uključen Secure Boot i uspešnu TPM atestaciju, te prikupiti dokaze bez rizičnog resetovanja TPM-a.

Preduslovi: fizički laboratorijski host sa podržanim TPM 2.0 i UEFI firmware-om, out-of-band konzola, evakuisane VM-ove, maintenance mode, backup ESXi konfiguracije i poznat recovery postupak. Nested ESXi često ne može verno demonstrirati fizički TPM trust i nije dokaz produkcione kompatibilnosti. Rizik je visok ako se menja boot režim; promenu firmware-a izvršiti samo u laboratoriji ili odobrenom maintenance window-u.

1. Pre promene zabeležiti ESXi build, vendor firmware, boot režim, TPM status i aktivne alarme.
2. U ESXi Shell-u izvršiti samo secureBoot.py -c. Ako nalaz nije čist, zaustaviti postupak i identifikovati svaki VIB.
3. Preuzeti i zaštititi TPM encryption recovery ključ prema zvaničnoj proceduri za konkretnu verziju. Potvrditi da backup postoji bez prikazivanja samog ključa u dokazima.
4. U odobrenom prozoru ugasiti/restartovati host, u firmware-u uključiti podržani UEFI Secure Boot i TPM 2.0 redosledom koji propisuje vendor, zatim pokrenuti host.
5. U vSphere Client-u proveriti attestation status i alarme. Ponoviti read-only ESXi proveru i pregledati događaje nastale tokom reconnect-a.

Očekivani rezultat: host se vraća u Connected stanje, Secure Boot je aktivan, TPM je prepoznat i atestacija nema neobjašnjen failure. HA/DRS i management mreža ostaju zdravi, a host tek posle tih provera izlazi iz maintenance mode-a.

Grane dijagnostike: ako host ne bootuje, koristiti out-of-band konzolu i vratiti prethodno dokumentovan firmware režim; ne menjati više parametara odjednom. Ako host radi, ali atestacija ne uspeva, proveriti Secure Boot, vreme, poslednju hardware/firmware promenu, vCenter vpxd.log i relevantan Broadcom KB. Ne čistiti TPM i ne uređivati VCDB bez eksplicitne podržane procedure.

Rollback i kriterijum završetka: laboratorijski rollback je vraćanje prethodnog firmware stanja samo ako je unapred potvrđeno da je bezbedno i da postoji recovery materijal. Vežba je završena kada su sačuvani pre/post dokazi, host funkcionalno validiran i postupak oporavka dokumentovan.

Vežba 3: Native Key Provider i vTPM na testnoj virtuelnoj mašini

Cilj i kontekst: bezbedno uspostaviti laboratorijski key provider, dokazati njegov backup i dodati vTPM testnoj VM bez pogrešnog zaključka da su svi njeni diskovi automatski šifrovani.

Preduslovi: podržano vSphere 7.0 U2 ili novije okruženje, kompatibilni ESXi hostovi, testna VM sa podržanim guest OS-om, EFI firmware, backup VM-a koji je moguće vratiti i nalog sa minimalno potrebnim Cryptographic i VM configuration privilegijama. Funkcija i licenca moraju se potvrditi za konkretno izdanje. Rizik je srednji: gubitak provider backup-a ili lozinke može ugroziti oporavak.

1. U vSphere Client-u otvoriti konfiguraciju Key Providers, kreirati NKP jasnog laboratorijskog imena i završiti trust/aktivaciju prema čarobnjaku.
2. Odmah izvesti šifrovani backup provider-a. Sačuvati fajl i lozinku u odvojenim odobrenim lokacijama; zabeležiti ko je izvršio operaciju, ali ne i tajnu.
3. Potvrditi da je provider aktivan i dostupan svim hostovima na kojima VM može raditi.
4. Napraviti proverljiv backup testne VM, ugasiti je i proveriti da koristi EFI firmware.
5. Dodati Trusted Platform Module uređaj kroz Edit Settings. Ne menjati istovremeno druge virtuelne uređaje.
6. Pokrenuti VM, u guest OS-u potvrditi prisustvo TPM 2.0 i zatim u vSphere Client-u posebno proveriti storage policy/encryption stanje VM home-a i svakog diska.
7. Pregledati Tasks and Events: kreiranje provider-a, backup i reconfiguration VM-a moraju imati očekivanog izvršioca i rezultat.

Očekivani rezultat: guest vidi vTPM, VM se uspešno pokreće na svim planiranim hostovima, key provider je zdrav i postoji proverljiv backup. Evidence package jasno razdvaja „vTPM prisutan”, „vTPM state zaštićen” i „VMDK obuhvaćen encryption policy-jem”.

Troubleshooting: ako je opcija vTPM nedostupna, proveriti EFI firmware, key provider status, privilegije, kompatibilnost i power state VM-a. Ako VM ne može da se uključi, ne uklanjati provider; proveriti dostupnost ključa, host crypto stanje, Tasks and Events i vpxd.log. Privremeno rešenje koje zaobilazi enkripciju nije prihvatljiva trajna mera.

Rollback: na laboratorijskoj VM isključiti guest funkciju koja koristi TPM i ukloniti vTPM samo ako je potvrđeno da guest neće izgubiti pristup šifrovanim podacima. BitLocker ili slična zaštita mora biti suspendovana/dekriptovana po pravilima guest OS-a pre uklanjanja. Provider se ne briše dok postoji bilo koji zavisan objekat.

Vežba 4: Audit događaj, centralni syslog i incident response

Cilj i kontekst: dokazati da kontrolisana administratorska aktivnost ostavlja korelisan trag u vCenter-u, ESXi-ju i centralnom kolektoru, a zatim obraditi simulirano odstupanje.

Preduslovi: laboratorijski host, udaljeni syslog/SIEM kolektor, sinhronizovano vreme, testni nalog, odobren ticket i snapshot/backup samo za sisteme na kojima je to podržano. Ne koristiti produkcioni incident za prvi test. Rizik je nizak ako se kao test koristi kratkotrajno uključivanje SSH-a na izolovanom laboratorijskom hostu.

1. Zabeležiti UTC početak testa, nalog, izvorni IP, host i ticket ID.
2. Potvrditi configured syslog destination i prijem redovnih poruka na kolektoru.
3. Na laboratorijskom hostu kroz vSphere Client privremeno pokrenuti SSH servis; ovo je state-changing korak i mora imati vremensko ograničenje.
4. Sa kontrolisane stanice izvršiti jednu prijavu, read-only komandu esxcli system version get, odjaviti se i odmah zaustaviti SSH servis.
5. U vCenter Tasks and Events pronaći promenu servisa; u ESXi auth.log i shell.log potvrditi prijavu i komandu; na centralnom kolektoru potvrditi iste događaje i vremensku korelaciju.
6. Dokumentovati simptom (neočekivano aktivan SSH), obim, posledicu, neposredni uzrok (testna promena), osnovni uzrok u realnom scenariju, korekciju i dokaz oporavka.

Očekivani rezultat: sva tri izvora pokazuju konzistentan tok, parser prepoznaje host i vreme, a završna provera potvrđuje da je SSH zaustavljen i da politika pokretanja nije promenjena. Ako događaj ne stiže udaljeno, prvo proveriti lokalno generisanje, zatim DNS/rutu/firewall, konfiguraciju transporta, sertifikat gde se koristi TLS i tek potom kolektor/parser.

Rollback i kriterijum završetka: SSH je zaustavljen, privremeni pristup ukinut, alarm razrešen sa komentarom i dokazi sačuvani prema retenciji. Vežba nije završena ako događaj postoji samo lokalno ili ako centralni zapis nema upotrebljivo vreme/identitet.

10. Troubleshooting matrica – od simptoma do trajne mere

11. Administratorske prakse

• Veži svaku kontrolu za tačan proizvod, verziju, rizik, vlasnika i metod validacije.
• Odvoji nalog koji prikuplja dokaze od naloga koji menja stanje; read-only audit skripta ne sme prikriveno da vrši remediation.
• Secure Boot, fizički TPM, host attestation, vTPM i enkripciju tretiraj kao različite, povezane kontrole.
• Backup key provider-a i TPM recovery materijala završi pre oslanjanja na kriptografsku funkciju, a restore testiraj bez izlaganja tajni.
• Pre strict Lockdown Mode-a testiraj vCenter outage i break-glass proceduru preko out-of-band konzole.
• Centralni syslog proveravaj end-to-end kontrolisanim događajem; konfigurisan target bez potvrđenog prijema nije dokaz.
• Ne primenjuj ceo benchmark odjednom. Pilot host, maintenance window, pre-check, validacija workload-a i rollback čine jednu promenu.
• Izuzetak nije nevidljiva greška: dokumentuj razlog, kompenzujuću kontrolu, odobrenje, rok i vlasnika.
• Posle firmware-a, zamene matične ploče/TPM-a, ESXi image promene ili vCenter restore-a ponovi trust i encryption validaciju.
• Dokaze zaštiti kao osetljive operativne podatke i rediguj ključeve, tokene, lozinke i privatne sertifikatske materijale.

12. Završna kontrolna tačka

Nakon ove lekcije administrator treba proverljivo da ume da:

• prevede zvaničnu hardening preporuku u verzijski vezanu, merljivu kontrolu i dokumentovan izuzetak;
• objasni razliku između desired image-a, konfiguracione usklađenosti, Secure Boot-a i TPM atestacije;
• bez promene stanja prikupi ESXi hardening inventar kroz vSphere Client, ESXi CLI i PowerCLI;
• planira uključivanje Secure Boot-a uz compatibility proveru, maintenance mode, out-of-band pristup i rollback;
• razlikuje fizički TPM 2.0 od vTPM-a i bezbedno postupa sa TPM recovery ključem;
• izabere standardni, Native ili Trusted Key Provider prema arhitekturi i potvrdi backup/recovery zavisnosti;
• objasni obim VM Encryption-a, vTPM zaštite i vSAN enkripcije bez mešanja njihovih garancija;
• korelira Tasks and Events, SSO/vCenter i ESXi logove sa centralnim syslog/SIEM zapisom;
• obradi neuspešnu atestaciju ili nedostupan ključ od simptoma do potvrđenog osnovnog uzroka i trajne mere;
• izradi evidence package koji je ponovljiv, vremenski označen, verzijski precizan i bez izloženih tajni.

Zaključak

Napredno zaštićena vSphere platforma nije ona sa najvećim brojem uključenih kontrola, već ona u kojoj su kontrole međusobno usklađene i operativno održive. Hardening smanjuje površinu napada; Secure Boot i TPM grade i mere poverenje u host; key provider omogućava kontrolisanu kriptografsku zaštitu; VM Encryption, vTPM i vSAN enkripcija štite različite slojeve; audit trag pretvara administratorsku aktivnost u proverljiv dokaz. Slaba karika može poništiti ostatak sistema: recovery ključ bez zaštite ugrožava tajnost, key provider bez DR-a ugrožava dostupnost, a log bez tačnog vremena ugrožava istragu.

Odgovoran administrator zato pre promene prikuplja početno stanje, proverava verziju i zavisnosti, pilotira kontrolu, obezbeđuje rollback i recovery materijal, validira funkcionalnost posle promene i čuva dokaz koji drugi stručnjak može ponoviti. Takav pristup priprema teren za narednu lekciju: automatizacija kroz VCF PowerCLI i vSphere API ima smisla tek kada je jasno koje stanje želimo, ko sme da ga menja i kako ćemo dokazati da je promena bila bezbedna i uspešna.