VMware

Nadograđen i tehnički usklađen vSphere sistem nije bezbedan samo zato što su binarne komponente aktuelne. On postaje upravljiv tek kada administrator može pouzdano da odgovori na četiri pitanja: ko se prijavio, ko je potvrdio njegov identitet, šta mu je dozvoljeno i kojim kriptografskim identitetom servis dokazuje da je zaista onaj kome se korisnik ili druga komponenta obraća. U vSphere okruženju te odgovore zajedno daju vCenter Single Sign-On, izvori identiteta i federisani identity provider-i, model privilegija, uloga i dozvola, kao i infrastruktura sertifikata koju čine VMware Certificate Authority i VMware Endpoint Certificate Store.

Ova lekcija se nastavlja na kontrolisani lifecycle iz prethodne lekcije: nadogradnja vCenter Server-a može promeniti podržane identity provider-e, tokove prijave, API ponašanje i sertifikatske zavisnosti, pa se identitet i pristup moraju uključiti u pre-check i post-check. Istovremeno, ovde se postavlja osnova za narednu lekciju o hardening-u, enkripciji i audit dokazima. Cilj nije da jedan nalog „može sve”, već da svaki čovek i servis dobije tačno potreban pristup, u poznatom vremenskom okviru, uz proverljiv trag i održiv način oporavka.

1. Identitet, autentikacija i autorizacija nisu ista kontrola

Identitet je digitalna reprezentacija čoveka, grupe, aplikacije ili servisa. Autentikacija dokazuje da je subjekt zaista taj identitet, na primer lozinkom, sertifikatom ili procesom kod spoljašnjeg identity provider-a. Autorizacija se izvršava nakon uspešne autentikacije i određuje koje operacije identitet sme da izvrši nad kojim objektima. Accounting i audit beleže šta je urađeno, kada, sa koje sesije i nad kojim objektom. TLS sertifikat ima još jednu ulogu: omogućava klijentu ili servisu da proveri identitet druge strane i uspostavi šifrovan kanal.

Uspešna prijava ne dokazuje da je autorizacija dobra, a pravilno podešena uloga ne pomaže ako je identity source nedostupan. Sertifikat koji je još u roku može biti neupotrebljiv ako mu nedostaje odgovarajući SAN, ako privatni ključ ne odgovara sertifikatu ili ako klijent nema kompletan trust chain. Zato se incident ne opisuje samo kao „SSO ne radi”: razdvajaju se dohvat identiteta, provera kredencijala, izdavanje tokena, evaluacija dozvole, dostupnost ciljnog servisa i TLS poverenje.

2. Arhitektura vCenter Single Sign-On sistema

vCenter Single Sign-On je autentikaciona infrastruktura vCenter Server-a. U savremenom appliance modelu Platform Services Controller je ugrađen u vCenter Server; istorijske topologije sa spoljnim PSC-om ne treba koristiti kao projekat nove implementacije. SSO domen, često inicijalno nazvan vsphere.local, nije DNS ni Active Directory domen. To je administrativna granica u kojoj postoje lokalni korisnici i grupe, identity source konfiguracija, registracije servisa, rešenja i poverenje potrebno za izdavanje i proveru tokena.

SSO domen, site i Enhanced Linked Mode

Više vCenter Server instanci može pripadati istom SSO domenu i raditi u Enhanced Linked Mode topologiji. Tada se dele ili replikuju određeni SSO podaci, kao što su identity source i globalne permission konfiguracije, a administrator dobija objedinjeni pogled. To nije samo pogodnost: kvar zajedničkog tokena, nekonzistentna vmdir replika ili pogrešna promena identity provider-a može imati širi blast radius. STS signing certificate je zajednička SSO zavisnost; njegova zamena mora se planirati za celu ELM topologiju, uz provere svih partnera.

Kod vSphere 8 federacije u ELM-u, vCenter čvor koji hostuje VMware Identity Services mora biti dostupan ostalim povezanim čvorovima. Ako nije, federisane prijave mogu otkazati i na vCenter instancama koje su inače zdrave. Lokalni SSO break-glass nalog ostaje neophodan, a produkcioni dizajn razmatra dostupnost hosting čvora i dokumentovan oporavak. VCF 9 može koristiti drugačiji Identity Broker deployment model; to je verzijska razlika, ne procedura za vSphere 8.

Vreme, DNS i mreža kao bezbednosne zavisnosti

Kerberos, OIDC tokeni, STS tokeni i X.509 sertifikati zavise od vremena. Značajan clock skew može izgledati kao pogrešna lozinka ili nevažeći token. Forward i reverse DNS, stabilan vCenter PNID/FQDN i odgovarajući SAN u sertifikatu nisu kozmetika. Pre svake SSO ili sertifikatske intervencije proveravaju se NTP izvori, DNS rezolucija iz pravca vCenter-a i klijenata, portovi do LDAP/LDAPS i IdP endpoint-a, proxy pravila i TLS trust chain.

3. Izvori identiteta i federacija

vCenter uvek ima lokalni SSO identity source. Spoljni direktorijum omogućava centralni lifecycle korisnika i grupa, dok federacija premešta interaktivnu autentikaciju ka podržanom IdP-u. Izbor nije samo pitanje komfora prijave: utiče na MFA, mrežne tokove, dostupnost, provisioning i recovery. Produkcioni cilj je koristiti grupe iz enterprise direktorijuma za redovan pristup, a lokalne SSO naloge ograničiti na kontrolisanu administraciju i oporavak.

LDAPS kao preporučeni direktorijumski kanal

Nešifrovani LDAP izlaže bind i direktorijumski saobraćaj mrežnom riziku. LDAPS obezbeđuje šifrovanje i proveru identiteta domain controller-a, ali samo ako vCenter veruje izdavačkom lancu i ako se povezuje imenom koje sertifikat pokriva. Bind nalog treba da bude namenski, bez interaktivne prijave i bez administrativnih privilegija; njegova lozinka se čuva u kontrolisanom secrets procesu i rotira uz prethodno testiranje. Base DN treba suziti koliko organizacioni model dopušta, jer pogrešan opseg povećava mogućnost dvosmislenih naloga i nepotrebnog pretraživanja.

• Koristiti najmanje dva pouzdana LDAP server endpoint-a kada podržani dijalog to omogućava i potvrditi da sertifikati svih servera imaju odgovarajući SAN.
• Uvesti kompletan root/intermediate lanac, ne samo slučajno preuzet leaf sertifikat; planirati obnovu pre isteka.
• Ne uklanjati stari identity source dok se novi ne validira iz odvojene administratorske sesije.
• U ELM okruženju tretirati promenu kao SSO-domain promenu: konfiguracija se replikuje, pa se ne ponavlja nasumično na svakom čvoru.

Federacija, OIDC, SCIM i MFA

Kod federacije, browser se preusmerava ka spoljašnjem identity provider-u, koji autentikuje korisnika i vraća rezultat kroz OpenID Connect tok. Provisioning korisnika i grupa u VMware Identity Services može koristiti SCIM 2.0. Autentikacija i provisioning su povezani, ali nisu isto: OIDC uspeh ne garantuje da vCenter može da mapira autentikovanog subjekta na provisioned korisnika ili grupu. Zato incident „IdP kaže success, vCenter kaže access denied” prvo vodi ka proveri SCIM sinhronizacije, immutable identifikatora, group push-a i dodeljene vCenter dozvole.

Za vCenter 8.x zvanično podržani federacioni izbor zavisi od update izdanja; dokumentacija obuhvata Microsoft Entra ID, Okta i PingFederate u odgovarajućim verzijama. Ne pretpostavlja se da bilo koji generički OIDC ili SAML provider radi samo zato što implementira standard. AD FS podrška pripada određenim starijim federacionim putevima i integracijama; pre dizajna proverava se tačna matrica za build i povezane proizvode. MFA se kod vSphere 8 federacije sprovodi na IdP strani. „Dodavanje MFA” lokalnom administrator@vsphere.local nalogu nije podržani nativni model.

4. RBAC: privilegija, uloga i dozvola

vSphere RBAC se razume kroz preciznu formulu: permission = principal + role + inventory object + propagation. Principal je korisnik ili grupa. Role je skup privilegija. Inventory object određuje opseg, a propagation odlučuje da li se dozvola nasleđuje na potomke. Privilegija je atomsko pravo, na primer uključivanje VM-a ili menjanje mrežne konfiguracije; sama uloga ne daje pristup dok nije uparena sa principal-om na objektu.

Hijerarhija, nasleđivanje i No Access

Dozvola postavljena na datacenter, folder, cluster ili drugi roditeljski objekat može se propagirati. Direktna dozvola na potomku može promeniti efektivni rezultat, a članstvo istog korisnika u više grupa može proizvesti zbir privilegija. No Access nije univerzalna „deny uvek pobeđuje” kontrola koju treba primenjivati bez modelovanja; vSphere objekti, naročito VM i vApp, mogu učestvovati u različitim propagation lancima. Efektivni pristup se zato proverava konkretnim test nalogom i konkretnom operacijom, ne samo vizuelnim pregledom jedne permission stavke.

Za organizacionu skalabilnost, VM-ove i druge objekte treba grupisati u foldere koji predstavljaju stabilne administrativne granice, a dozvole dodeljivati AD/IdP grupama na najnižem zajedničkom objektu koji ispunjava zahtev. Dodeljivanje pojedinačnim korisnicima otežava offboarding i audit. Dodela na vCenter root-u sa propagacijom je velika promena i mora imati eksplicitno poslovno opravdanje.

Sistemske i prilagođene uloge

Ugrađene sistemske uloge, uključujući Administrator, Read-only i No access, imaju posebno ponašanje i nisu zamena za dobro projektovane operativne role. Produkcione role se grade po personama: VM operator, backup servis, monitoring, mrežni administrator, storage administrator ili automation service account. Svaka uloga dobija opis, vlasnika, change ID, datum pregleda i testirani use case. Naziv „VM Admin” nije dovoljan dokaz šta uloga sadrži.

Tagovi, Content Library i druga odvojena prava

Inventory RBAC nije jedina permission površina. Tag kategorije i tagovi imaju posebne privilegije i dodele; Content Library, vSphere Namespaces, kriptografske operacije i povezana rešenja mogu zahtevati zasebna prava. Korisnik može videti VM, ali ne i tag koji automatizacija očekuje, ili može imati pravo nad namespace-om koje se ne vidi iz klasičnog VM folder modela. Zato se matrica pristupa vodi po resursu i funkciji, a ne samo po vCenter ulozi.

5. Projektovanje najmanjih privilegija i lifecycle pristupa

Najmanje privilegije nisu jednokratno uklanjanje prava nego lifecycle: zahtev, odobrenje vlasnika resursa, dodela grupi, tehnička validacija, nadzor korišćenja, periodična recertifikacija i povlačenje. Privremeni pristup mora imati datum isteka izvan vCenter-a ako sama platforma ne sprovodi željeni JIT model. Segregation of duties odvaja osobu koja traži, odobrava, implementira i proverava privilegovanu promenu kad god organizaciona veličina to dopušta.

1. Definiši posao: napiši dozvoljene operacije i zabranjene posledice, ne samo naziv tima.
2. Mapiraj objekte: utvrdi folder, cluster, datastore, network, tag ili namespace koji operacija dodiruje.
3. Prikupi required privilege dokaz: koristi zvaničnu dokumentaciju, test u laboratoriji i PowerCLI privilege report gde je primenljivo.
4. Kreiraj grupu i ulogu: pristup dodeli grupi, a ulogu verzioniši opisom i izvozom.
5. Testiraj pozitivno i negativno: dozvoljena operacija mora uspeti, a najmanje jedna kritična nedozvoljena mora biti odbijena.
6. Prati i recertifikuj: orphaned principals, direktne user dodele i široke root/global permissions tretiraj kao nalaze.

Service account i automatizacija

Servisni nalog mora imati jednog poslovnog i jednog tehničkog vlasnika, namenu, opseg, metod čuvanja i rotacije tajne, očekivane izvore konekcije i plan povlačenja. Ne koristi lični nalog u backup proizvodu ili CI/CD pipeline-u. Ako integracija podržava token, OAuth2 client ili sertifikatski identitet, proveri da li je to podržani i bezbedniji model za konkretnu verziju; ne pretpostavljaj da svaka vSphere integracija koristi isti auth mehanizam.

PowerCLI skripte ne treba da sadrže plaintext lozinku. Interaktivni Get-Credential je prihvatljiv za laboratoriju i ad hoc administraciju, dok produkciona automatizacija koristi enterprise secrets manager i kratkotrajne kredencijale gde je moguće. Set-PowerCLIConfiguration -InvalidCertificateAction Ignore nije popravka sertifikata; njime se gubi dokaz identiteta servera i ne treba ga ostaviti kao globalnu produkcionu konfiguraciju.

6. Sertifikatska arhitektura: VMCA, VECS i STS

VMware Certificate Authority, VMCA, izdaje sertifikate za vSphere komponente. VMware Endpoint Certificate Store, VECS, čuva sertifikate i privatne ključeve u imenovanim store-ovima. Machine SSL sertifikat predstavlja vCenter endpoint klijentima i servisima. Solution User sertifikati omogućavaju autentikaciju internih vCenter rešenja prema SSO-u; tipični store-ovi obuhvataju machine, vpxd, vpxd-extension i vsphere-webclient, a dodatne komponente mogu imati svoje store-ove. STS signing certificate potpisuje tokene i nije isto što i Machine SSL sertifikat.

Modeli upravljanja sertifikatima

Najjednostavniji podržani model koristi VMCA kao root CA. Interni servisi rade bez ručnog izdavanja, ali browseri i enterprise klijenti po pravilu ne veruju VMCA root-u dok se on kontrolisano ne distribuira. Čest produkcioni kompromis je da Machine SSL sertifikat bude potpisan enterprise CA-om, dok solution user sertifikate održava VMCA. Model u kome je VMCA subordinate CA ima širi PKI uticaj i mora ga odobriti PKI tim; privatni ključ i policy posledice zahtevaju strogu procenu. Potpuno custom upravljanje svim sertifikatima povećava operativni trošak i rizik isteka.

Sertifikat se izdaje za stabilni FQDN/PNID, sa SAN vrednostima koje odgovaraju podržanom pristupu. Dodavanje IP adresa ili alias-a „za svaki slučaj” širi identitet i komplikuje lifecycle. Wildcard sertifikati nisu dobar podrazumevani izbor za infrastrukturni management plane. Private key se generiše i čuva kontrolisano, a PKCS#8/PEM format, redosled chain-a i key match potvrđuju se pre importa.

Bezbedan lifecycle i redosled promene

1. Inventariši sve relevantne sertifikate, izdavače, SAN, rokove, store-ove i vlasnike.
2. Proveri health vCenter-a, file-based backup i mogućnost restore-a. Snapshot samog appliance-a nije zamena za podržani backup; u ELM-u nekonzistentni online snapshot-i mogu pogoršati stanje.
3. Proveri DNS, NTP, PNID, ELM partnere, vmdir replikaciju i servisno stanje.
4. Generiši CSR i key prema zvaničnoj proceduri za tačan build; PKI tim vraća leaf i kompletan chain.
5. Pre importa proveri subject/SAN, EKU, rok, chain i podudaranje javnog i privatnog ključa.
6. Izvrši podržanu zamenu pomoću vSphere Client-a, certificate-manager ili zvanično preporučenog vCert alata za konkretan slučaj.
7. Validiraj UI, API, PowerCLI, backup/monitoring integracije, ELM pogled i solution servise; dokumentuj nove fingerprint-e i rokove.

7. Inventar, nadzor i read-only provere

Sledeće komande se izvršavaju preko SSH sesije na vCenter Server Appliance-u sa odgovarajućim administrativnim ovlašćenjem. One čitaju stanje. SSH pristup treba uključiti samo po odobrenoj proceduri i ponovo ograničiti nakon rada. Izlaz može sadržati interne identifikatore i ne objavljuje se nekontrolisano.

# Prikaži VECS store-ove; read-only.
/usr/lib/vmware-vmafd/bin/vecs-cli store list

# Prikaži alias-e u Machine SSL store-u; read-only.
/usr/lib/vmware-vmafd/bin/vecs-cli entry list \
  --store MACHINE_SSL_CERT

# Prikaži sertifikat bez privatnog ključa; read-only.
/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert \
  --store MACHINE_SSL_CERT \
  --alias __MACHINE_CERT \
  | openssl x509 -noout -subject -issuer -serial -dates \
      -fingerprint -sha256 -ext subjectAltName

Očekuje se jedan aktivan Machine SSL identitet čiji SAN obuhvata vCenter FQDN, čiji rok nije blizu isteka i čiji issuer odgovara planiranom modelu. Ako verzija OpenSSL-a ne podržava prikaz ekstenzije navedenim parametrom, sertifikat se može pregledati sa openssl x509 -noout -text; to ne menja stanje.

# Provera sertifikata koji endpoint zaista prezentuje; read-only.
openssl s_client -connect vcsa01.example.test:443 \
  -servername vcsa01.example.test -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates \
      -fingerprint -sha256 -ext subjectAltName

Ova provera se izvršava sa administratorske radne stanice ili dijagnostičkog Linux sistema. Ona dokazuje šta klijent vidi na mreži, što može biti različito od očekivanog store-a ako između postoji proxy ili load balancer. Bez -servername SNI scenario može vratiti pogrešan sertifikat.

PowerCLI inventar dozvola

Sledeći PowerCLI primer je read-only nakon uspostavljanja sesije. Izvršava se sa administratorske radne stanice, nalogom koji ima pravo čitanja dozvola na pregledanom opsegu. Izvoz predstavlja osetljiv bezbednosni artefakt i mora se zaštititi.

$server = "vcsa01.example.test"
$credential = Get-Credential
$vi = Connect-VIServer -Server $server -Credential $credential

$permissions = Get-VIPermission |
  Select-Object @{N="Entity";E={$_.Entity.Name}},
                Principal,
                Role,
                Propagate,
                IsGroup

$permissions | Sort-Object Entity, Principal |
  Export-Csv -Path "./vcenter-permissions.csv" -NoTypeInformation -Encoding UTF8

Disconnect-VIServer -Server $vi -Confirm:$false

CSV se upoređuje sa odobrenom access matricom. Posebno se traže direktne user dodele, nepoznati principal-i, Administrator na širokom opsegu, root/global permissions i Propagate = True tamo gde nije namerno. Get-VIPermission prikazuje definisane dodele; efektivni pristup može zahtevati dodatnu analizu grupnog članstva i više propagation putanja.

8. Logovi, događaji i sistematična dijagnostika

Tačna imena i lokacije mogu se menjati između build-ova; proverava se zvanični „Location and Contents of vCenter Server log files” dokument. Debug logging se uključuje samo privremeno prema KB proceduri jer povećava količinu podataka i može zabeležiti osetljiv kontekst. Najpre se beleže UTC i lokalno vreme incidenta, korisnički principal, vCenter FQDN, client IP, IdP request/correlation ID i poslednja promena. Tek zatim se korelišu logovi u istom vremenskom prozoru.

# Read-only pretraga ograničena na relevantne obrasce i poslednjih 300 linija.
tail -n 300 /var/log/vmware/sso/websso.log \
  | grep -Ei 'error|exception|certificate|ldap|authentication|token'

tail -n 300 /var/log/vmware/vc-ws1a-broker/federation-service.log \
  | grep -Ei 'error|oidc|tls|user_not_found|denied'

Jedna reč error nije root cause. Nalaz se povezuje sa timestamp-om, konkretnim request-om, prethodnim i narednim linijama, stanjem IdP-a i mrežnim/TLS dokazom. Log se prvo kopira ili support bundle čuva prema incident proceduri; rotirani logovi se ne brišu da bi se „oslobodio prostor” bez provere filesystem-a i retention politike.

Troubleshooting matrica

9. Praktikum: od identity source-a do dokazive najmanje privilegije

Laboratorijska topologija, preduslovi i rizik

Laboratorija koristi vcsa01.example.test, jedan ESXi host, datacenter LAB-DC, VM folder App-Team-A, LDAPS direktorijum ad01.example.test, grupu GG-vSphere-AppA-Operators i test korisnika koji je član samo te grupe. Potrebni su lokalni SSO administrator, direktorijumski nalog za kreiranje/test grupe, PowerCLI na administratorskoj stanici, važeći CA lanac za LDAPS i sinhronizovan NTP.

Vežba menja identity source i RBAC stanje. U produkciji zahteva change odobrenje, file-based vCenter backup, zabeleženo početno stanje i potvrđen break-glass pristup. Bezbedna laboratorijska simulacija koristi novu test grupu i folder, ne postojeću produkcionu ulogu. Kriterijum završetka je: korisnik se autentikuje, može da izvrši dozvoljenu power operaciju samo nad VM-om u folderu, ne može da menja permissions niti host networking, a sve dodele su izvezene kao dokaz.

Vežba 1: pre-check identiteta, DNS-a, vremena i TLS-a

1. Prijavi se lokalnim SSO break-glass test nalogom u odvojenom privatnom browser prozoru. Ne zatvaraj tu sesiju dok spoljna prijava nije potvrđena.
2. U vSphere Client-u zabeleži verziju/build i idi na Administration → Single Sign On → Configuration. Izvezi ili snimi postojeći spisak identity source-a bez prikazivanja tajni.
3. Sa dijagnostičke stanice proveri forward DNS za vCenter i oba LDAP endpoint-a, zatim proveri TCP/TLS konekciju i sertifikat.

getent hosts vcsa01.example.test
getent hosts ad01.example.test

openssl s_client -connect ad01.example.test:636 \
  -servername ad01.example.test -showcerts </dev/null

Komande su read-only. Očekuje se rezolucija na planirane adrese i TLS handshake bez hostname/chain greške kada se koristi odgovarajući CA trust. Proveri notAfter, SAN i ceo lanac. Ako handshake ne uspe, ne nastavljaj konfiguraciju: ispravi DNS, firewall ili sertifikat sa vlasnikom direktorijuma. Ne zaobilazi validaciju prelaskom na plaintext LDAP.

Vežba 2: dodavanje AD over LDAPS identity source-a

1. U Administration → Single Sign On → Configuration → Identity Provider/Identity Sources izaberi dodavanje Active Directory over LDAP. Nazivi menija mogu se neznatno razlikovati po 8.x update-u.
2. Unesi tačan domain name, Base DN za korisnike i grupe, primary i secondary URL u obliku ldaps://fqdn:636, namenski bind principal i njegovu tajnu.
3. Uvezi potreban pouzdani CA lanac prema dijalogu i zvaničnoj proceduri. Ne koristi leaf sertifikat kao trajnu zamenu za pravilno poverenje u izdavača ako PKI model očekuje rotaciju DC sertifikata.
4. Sačuvaj konfiguraciju, pronađi test grupu i izvrši prijavu test korisnikom u novom browser prozoru.

Očekivani rezultat je da vCenter može da pretraži grupu i autentikuje korisnika. Ako pretraga radi, a prijava ne, proveri format principal-a, user lockout i SSO logove. Ako ništa ne može da se pronađe, proveri Base DN i bind prava. Ako je TLS greška, potvrdi koji sertifikat endpoint zaista prezentuje i da li je njegov chain importovan. Rollback je uklanjanje samo novog laboratorijskog source-a nakon što je potvrđen lokalni SSO pristup i sačuvan dokaz greške.

Vežba 3: prilagođena uloga i dodela grupi

Kreiraj ulogu TASHIZZA-LAB-VM-Power-Operator sa minimumom privilegija potrebnim za pregled i kontrolisane power operacije nad VM-ovima. Tačan skup utvrdi pomoću vSphere Client opisa privilegija i laboratorijskog testa; ne kopiraj slepo ulogu iz druge verzije ili proizvoda. Zatim dodeli grupi ulogu na folderu App-Team-A sa propagacijom.

# State-changing: izvršiti samo u laboratoriji nakon pregleda promenljivih.
$server = "vcsa01.example.test"
$folderName = "App-Team-A"
$roleName = "TASHIZZA-LAB-VM-Power-Operator"
$principal = "EXAMPLE\GG-vSphere-AppA-Operators"

$vi = Connect-VIServer -Server $server -Credential (Get-Credential)
$folder = Get-Folder -Name $folderName -Type VM

# Primer privilegija mora se potvrditi za konkretan use case i build.
$privilegeIds = @(
  "System.Anonymous",
  "System.Read",
  "System.View",
  "VirtualMachine.Interact.PowerOn",
  "VirtualMachine.Interact.PowerOff",
  "VirtualMachine.Interact.ConsoleInteract"
)

$privileges = Get-VIPrivilege | Where-Object { $_.Id -in $privilegeIds }
if ($privileges.Count -ne $privilegeIds.Count) {
  throw "Nisu pronađene sve planirane privilegije; promena je prekinuta."
}

$role = Get-VIRole -Name $roleName -ErrorAction SilentlyContinue
if (-not $role) {
  $role = New-VIRole -Name $roleName -Privilege $privileges
}

$existing = Get-VIPermission -Entity $folder |
  Where-Object { $_.Principal -eq $principal -and $_.Role -eq $roleName }

if (-not $existing) {
  New-VIPermission -Entity $folder -Principal $principal \
    -Role $role -Propagate:$true
}

Blok menja stanje i zato se prvo pregleda identitet servera, principal, folder i privilege ID. Idempotentna provera sprečava duplu dodelu, ali ne dokazuje da postojeća uloga ima očekivani sadržaj; to se posebno upoređuje. Ako Get-VIPrivilege ne vrati sve ID vrednosti, skripta prekida promenu umesto da kreira nepotpunu ulogu. U produkciji se uloga kreira kroz verzionisanu automatizaciju ili kontrolisan GUI change.

Vežba 4: pozitivni i negativni authorization test

1. Prijavi se test korisnikom i proveri da vidi VM u folderu App-Team-A.
2. Izvrši dozvoljenu operaciju nad bezbednom test VM, na primer power on ako je VM namenjena vežbi. Zabeleži task ID, vreme i rezultat.
3. Pokušaj read-only pregled objekta izvan foldera; očekivanje zavisi od namerno dodeljenih view prava. Ne širi ulogu samo da bi UI izgledao „lepše”.
4. Pokušaj da otvoriš uređivanje permissions ili host networking. Operacija mora biti nedostupna ili odbijena. Ne pokušavaj destruktivnu radnju samo radi testa.
5. Administrator proverava Tasks and Events i PowerCLI izvoz da principal, objekat, uloga i propagation odgovaraju planu.

Ako dozvoljena power operacija ne uspe, pročitaj poruku o nedostajućoj privilegiji i proveri da li operacija dodiruje dodatni objekat. Dodaj samo dokazano potrebnu privilegiju, ponovi test i dokumentuj razlog. Ako negativni test uspe, to je bezbednosni incident u laboratorijskom smislu: odmah identifikuj dodatno grupno članstvo, inherited/global permission ili drugu direktnu dodelu pre bilo kakvog nasumičnog uklanjanja.

Vežba 5: incident – LDAPS sertifikat je istekao

Bez stvarnog obaranja produkcionog direktorijuma, instruktor daje kopiju isteka sertifikata ili menja laboratorijski LDAPS endpoint na sertifikat kome vCenter ne veruje. Simptom je da lokalni SSO login radi, dok AD korisnici ne mogu da se prijave. Obim je spoljni identity source; posledica je gubitak redovnog administratorskog pristupa, ali ne i potpuni vCenter outage.

1. Ne menjaj identity source. Zabeleži vreme, korisnika, poruku i poslednju PKI/DC promenu.
2. Potvrdi lokalni SSO pristup i proveri vCenter service health.
3. Sa vCenter mrežnog pravca proveri DNS, port 636 i endpoint chain; u websso.log traži certificate path ili handshake grešku u istom intervalu.
4. Formuliši hipotezu: vCenter ne veruje novom LDAPS leaf/intermediate lancu ili se hostname ne poklapa.
5. Privremeni workaround je kontrolisani lokalni SSO pristup za nužnu administraciju, ne plaintext LDAP i ne globalno isključivanje TLS validacije.
6. Trajna mera je obnova direktorijumskog sertifikata/trust-a prema Broadcom KB proceduri za tačan build, uz potvrdu svih DC endpoint-a i ponovnu prijavu test korisnika.

Recovery je završen tek kada spoljašnji korisnik može da se prijavi, group lookup radi, oba LDAPS endpoint-a prolaze proveru, u logu nema novih handshake grešaka i postoji evidentiran novi datum isteka. Root cause nije „vCenter bug”, već neusklađen lifecycle LDAPS sertifikata i vCenter trust konfiguracije. Preventivna mera je zajednički certificate inventory i alarm znatno pre isteka.

Vežba 6: sertifikatski health check i plan obnove

Ova vežba je read-only: izlistaj VECS store-ove i sertifikate, proveri endpoint sertifikat sa klijentske stanice i napravi tabelu: komponenta, store, subject, issuer, SAN, serial, SHA-256 fingerprint, notAfter, vlasnik i plan obnove. Ne izvoziti privatne ključeve. Za ELM dodaj svaki čvor i zajedničke SSO zavisnosti.

Kriterijum završetka nije samo „nijedan nije istekao”. Svi sertifikati moraju pripadati očekivanom trust modelu, endpoint mora prezentovati planirani leaf i chain, SAN mora odgovarati FQDN-u, a svaki rok mora imati vlasnika i promenu zakazanu pre incidentnog perioda. Ako se pronađe sertifikat blizu isteka, vežba proizvodi change plan sa backup-om, alatom, redosledom, post-check integracijama i rollback/recovery odlukom; sama zamena nije deo read-only provere.

Rollback laboratorije

# State-changing rollback: pregledati rezultat pre potvrde.
$permission = Get-VIPermission -Entity (Get-Folder -Name "App-Team-A" -Type VM) |
  Where-Object { $_.Principal -eq "EXAMPLE\GG-vSphere-AppA-Operators" }

$permission | Format-Table Principal, Role, Entity, Propagate
$permission | Remove-VIPermission -Confirm:$true

$role = Get-VIRole -Name "TASHIZZA-LAB-VM-Power-Operator" \
  -ErrorAction SilentlyContinue
if ($role) {
  Remove-VIRole -Role $role -Confirm:$true
}

Pre uklanjanja proveri da uloga nije korišćena drugde i da filter vraća isključivo laboratorijsku dodelu. Identity source ukloni kroz GUI samo ako je napravljen isključivo za vežbu i ako je lokalni SSO pristup potvrđen. Test grupu briše vlasnik direktorijuma po svojoj proceduri. Završno stanje se dokazuje novim PowerCLI izvozom i odsustvom laboratorijske role i permission stavke.

10. Administratorske prakse

• Za redovan rad koristi imenovane naloge i direktorijumske grupe; lokalni SSO Administrator rezerviši za SSO administraciju i break-glass.
• Za svaki privilegovani pristup vodi vlasnika, razlog, opseg, odobrenje, datum pregleda i uslov povlačenja.
• Uloge projektuj po poslu i testiraj pozitivnim i negativnim slučajem; ne kloniraj široku ulogu bez privilege analize.
• Root i global permissions pregledaj češće od lokalnih dodela jer imaju najveći blast radius.
• Direktne user permissions, nepoznate principal-e i servisne naloge bez vlasnika tretiraj kao nalaze za korekciju.
• SSO, LDAPS, IdP, VMCA, STS i endpoint sertifikate vodi u jedinstvenom inventory-ju sa alarmima i planom obnove.
• Pre sertifikatske intervencije obezbedi podržani vCenter file-based backup i proveru restore preduslova; u ELM-u planiraj celu topologiju.
• Nikada ne rešavaj TLS problem trajnim isključivanjem certificate validation-a u browser-u, PowerCLI-ju, backup alatu ili skripti.
• Koreliraj vCenter Tasks/Events, SSO/IdP logove i change evidenciju u SIEM-u; čuvaj vreme sistema usklađenim.
• Posle nadogradnje proveri lokalni i spoljašnji login, group lookup, ključne service account integracije, ELM i certificate health.

11. Završna kontrolna tačka

Administrator je završio lekciju kada može dokazivo da:

• razdvoji identity source, autentikaciju, STS token, autorizaciju i TLS poverenje u incidentnom toku;
• objasni SSO domen, vmdir, STS, Lookup Service, ELM i VMware Identity Services zavisnosti;
• izabere između lokalnog SSO-a, LDAPS direktorijuma i podržane federacije prema dostupnosti, MFA i recovery zahtevima;
• projektuje permission kao principal + role + object + propagation i proveri efektivni pristup;
• napravi prilagođenu ulogu sa najmanjim privilegijama, dodeli je grupi i sprovede pozitivni i negativni test;
• inventariše Machine SSL, Solution User, STS, trusted root i spoljne LDAPS/IdP sertifikate bez izvoza privatnih ključeva;
• prepozna razliku između VMCA root, hybrid i custom PKI modela i njihov operativni trošak;
• prikupi SSO, federation, vmdir, vpxd i Tasks/Events dokaze pre promene stanja;
• dijagnostikuje LDAPS trust, OIDC/SCIM mapping, permission inheritance i certificate expiry od najmanje invazivne provere;
• izradi bezbedan change, rollback i recovery plan koji obuhvata backup, ELM partnere i post-check svih integracija.

Zaključak

Pouzdana kontrola pristupa u vSphere-u nastaje tek kada su identitet, token, dozvola i sertifikatsko poverenje projektovani kao jedan sistem. SSO omogućava zajedničku autentikacionu osnovu, ali njegova dostupnost zavisi od direktorijuma, vremena, DNS-a, STS-a i zdravlja replike. RBAC ograničava posledice kompromitovanog ili pogrešno korišćenog naloga samo ako su uloge uske, dodeljene grupama na ispravnom objektu i proverene stvarnim negativnim testom. Sertifikati štite servisne identitete i komunikaciju samo ako njihov lifecycle obuhvata trust chain, SAN, privatni ključ, vlasnika, alarm i testiranu obnovu.

Odgovoran administrator zato ne počinje incident resetovanjem sertifikata niti širenjem uloge na Administrator. On najpre čuva dokaze, određuje obim, proverava poslednju promenu i razdvaja autentikaciju od autorizacije. Zatim primenjuje najmanju bezbednu korekciju, validira i dozvoljene i zabranjene ishode i ostavlja trag iz kog sledeći administrator može da razume odluku. Takav identitetski temelj omogućava da hardening, enkripcija i audit iz naredne lekcije budu proverljive kontrole, a ne skup nepovezanih opcija.