Hardening de VCF: el P0 tanca la porta i el P2 et deixa la clau

El full de càlcul té 260 files. En 160, la columna que diu si el valor segur ja ve posat respon que no. Aquesta és, comptada, la guia de hardening de VMware Cloud Foundation 9.1.

El 5 d'octubre VMware va publicar una entrada explicant la seva Security Configuration Guide per a VCF, dins d'una sèrie de vint-i-dues peces pel mes de la ciberseguretat. La guia en si no és nova —les publiquen des dels temps de vSphere 4.0, i al repositori hi són totes— però l'entrada és útil perquè explica, columna a columna, què significa cada camp. Nosaltres vam fer l'obvi: descarregar el CSV i comptar.

Què hi ha dins del full

La guia s'entrega com a Excel i com a CSV. El directori de VCF 9.1 porta un fitxer VERSION amb la cadena 910-20260612-01, i el CSV, vint columnes per control: l'identificador, els mapatges a marcs de compliment, el component afectat, una discussió en prosa, l'impacte funcional previst, la prioritat, el paràmetre, el valor de fàbrica, el valor recomanat i les ordres de PowerCLI per comprovar-ho i per canviar-ho. Són 260 controls. Tot el que segueix surt d'aquí, i qualsevol pot refer el compte amb el mateix fitxer.

El repartiment per component no està equilibrat, i convé saber-ho abans de repartir la feina: 120 controls són d'ESX, 51 de vCenter, 29 de NSX, 26 d'Operations i 17 de vSAN. Els 17 restants es reparteixen entre Automation, VCF, Operations for Networks, Protection and Recovery, SDDC Manager i l'instal·lador. Gairebé la meitat dels controls són a l'hipervisor.

De 260, 160: la llista curta no és tan curta

L'entrada del blog tranquil·litza el lector amb aquesta frase: «Many controls are secure by default, so the list of real work is usually shorter than it first appears». És un consell general i raonable. Per a aquesta guia concreta, el compte va en l'altra direcció: la columna Is the Default? respon NO en 160 dels 260 controls, i la columna Action Needed diu Modify exactament en aquests mateixos 160. El 61,5% del full és feina, no auditoria.

Hi ha a més una coincidència neta que estalvia temps: tots els controls P0 i P1 són dels que cal canviar, i tots els P2 ja vénen bé. No hi ha ni una excepció en les 260 files. Així que la columna de prioritat i la de feina pendent diuen el mateix, i pots ordenar per qualsevol de les dues. Un matís honest: 22 d'aquests 160 porten la coda Upon Feature Enablement, és a dir, només apliquen si fas servir aquella funció. En queden 138 que apliquen sí o sí.

El P0 tanca la porta. El P2 et deixa la clau

La prioritat P0 significa, segons la mateixa guia, «where there is not a secure default, and you should do this immediately». Hi ha un control P0 que gairebé tothom reconeix: esx-9.lockdown-mode, el mode de bloqueig de l'amfitrió. Ve de fàbrica en lockdownDisabled i la guia recomana lockdownNormal. Amb ell activat, a l'amfitrió ja no s'entra per la porta del darrere: s'administra des de vCenter, i els rols i l'auditoria de vCenter deixen de poder saltar-se entrant directament a la màquina.

La columna d'impacte funcional d'aquest mateix control diu què passa si ho fas malament:

I aquí hi ha el que ens va cridar l'atenció, i ho donem com a lectura nostra, no com a troballa del fabricant. El control que manté aquesta via de rescat —esx-9.lockdown-dcui-access, la llista de comptes que encara poden entrar per la consola física de l'amfitrió si queda aïllat de vCenter— està classificat com a P2. I P2 vol dir que el valor per defecte ja és segur i que n'hi ha prou amb auditar-lo de tant en tant. El seu propi text d'impacte avisa que configurar malament aquesta llista amb el mode de bloqueig actiu «can leave the host unrecoverable if vCenter is unreachable».

És a dir: si treballes el full per ordre de prioritat, que és el que la guia et demana, tanques la porta abans de comprovar que encara tens clau. L'ordre de prioritat mesura risc d'exposició, no risc operatiu. Els tres controls de lockdown de la guia —el mode, la llista de la consola i la d'usuaris d'excepció— es llegeixen junts o no es llegeixen.

Una columna que existeix perquè esperen que ho desfacis

Entre les vint columnes n'hi ha una que es diu Installation Default Value, i l'entrada del blog explica per a què hi és: «What the value was before you changed it, because once in a while you may want to undo what you changed». Una guia de hardening que inclou de sèrie el valor anterior està dient en veu baixa què espera que passi.

La confirmació és a la primera pregunta freqüent. A «dona suport Broadcom a la guia?» la resposta comença per sí, i continua així: «However, if you make a change and something is amiss, our support engineers may ask you to undo it». És una frase perfectament raonable des del costat del fabricant, i és la que converteix el teu registre de canvis en part del control. Si vas endurir sense anotar què vas tocar, la nit que alguna cosa es trenqui estaràs desfent a cegues, i el rellotge corrent.

El switch virtual: el mateix ajust, el defecte contrari

L'entrada del blog tria com a exemple de control amb preu els ajustos de seguretat del switch virtual: «Setting them to what the Guide recommends may prevent clustered applications from working correctly». Vam anar a mirar aquelles files i hi ha una cosa que l'exemple no explica.

Són tres ajustos clàssics: rebutjar transmissions falsificades, rebutjar canvis de MAC des del convidat i rebutjar el mode promiscu. Al switch estàndard, els dos primers vénen de fàbrica en Accept i la guia els marca com a P0 tan bon punt facis servir aquella funció. Al switch distribuït, aquests mateixos dos ajustos ja vénen en Reject i figuren com a P2: només auditar, i en dos nivells, perquè la política del switch l'hereten els grups de ports però un grup pot sobreescriure-la. El mode promiscu ve tancat als dos. La conclusió és nostra: dos dels tres ajustos et donen feina o no segons quin tipus de switch tinguis, una decisió de xarxa que a la majoria d'instal·lacions que hem vist es va prendre per altres motius.

I en el text d'impacte del control de canvis de MAC apareix, entre les càrregues que depenen de poder canviar-la, una que no és una aplicació del client: «applications licensed by MAC address, and vCenter Reduced Downtime Upgrade». Dit d'una altra manera, aquell enduriment pot xocar amb el mecanisme que et permet actualitzar vCenter sense aturar-lo. La sortida que proposa la guia és bona i convé anotar-la: crear un grup de ports a part que ho permeti i connectar-hi només les màquines autoritzades. La guia documenta a més una excepció que ella mateixa munta: en habilitar vSAN File Services, el procés posa Accept al grup de ports d'aquell servei perquè els seus nodes presenten més d'una MAC, i tancar-ho allà trenca el trànsit del servei de fitxers.

La paraula que no surt als titulars: recuperabilitat

La frase que millor descriu per a què serveix de debò aquesta guia està amagada a l'explicació de la columna de discussió: «Many of the security controls in the Guide have secure defaults. However, many do not, and that's because they require you to make a decision, or have implications for functionality or recoverability of the system». Recuperabilitat. Vam comptar quants controls esmenten la recuperació a la seva discussió o al seu impacte: 32 dels 260.

El mateix control del mode de bloqueig avisa que «some operations, such as backup integrations and low-level troubleshooting, require direct host access», i recomana desactivar-lo temporalment a l'amfitrió afectat per a aquelles tasques. Aquí hi ha el nus, i és l'eix de gairebé tot el que escrivim: una fallada és inevitable, una avaria és una decisió de disseny. Si endureixes i amb això allargues mitja hora el camí per restaurar, has canviat un risc que potser mai no es materialitzarà per un cost que es cobra segur el dia dolent. Fes-ho, però posa-li número abans de fer-ho. De quant costa no mesurar-ho en vam parlar al seu dia a RTO i RPO sense fum.

El que la guia diu que no fa

Aquesta és la part que més ens va agradar, perquè és rara de veure i perquè t'estalvia una conversa incòmoda amb un auditor. La guia porta mapatges a marcs de compliment —vam comptar NIST SP 800-53 R5 als 260 controls, PCI DSS 4.0.1 a 255 i un identificador de STIG de la DISA a 168, així que 92 controls no en tenen cap—, i tot i així respon això a la pregunta de si implementar-la et deixa conforme amb PCI DSS o amb NIST: «Not by itself». Els mapatges estalvien temps; el compliment, diu, depèn de l'abast, dels processos, de les persones i del criteri de l'auditor.

Continua dient que no cobreix el que corre dins de les màquines virtuals, només la infraestructura i la configuració de les mateixes màquines; i que idees com el mínim privilegi o la separació de funcions no estan enumerades perquè són de disseny, no paràmetres. Hi ha una resposta més que mereix un paràgraf propi: a VCF 9.1 les funcions de gestió passen a una plataforma nova, VCF Management Services, descrita com una capa amb Kubernetes dins del mateix VCF. I com que «there are no user-configurable settings inside VCFMS», no hi ha controls per a ella a la guia.

Menys comandaments vol dir menys maneres d'equivocar-se, i com a decisió d'enginyeria ens sembla defensable. Però canvia què vol dir la frase «hem aplicat la guia»: aquell pla no l'endureixes tu i tampoc no l'audites tu. El que et continua pertanyent és qui hi arriba, i això és justament el que la guia diu que no enumera.

Del 9.0 al 9.1: 34 controls més i una columna nova

Al repositori hi ha les dues guies, i totes dues porten la mateixa data al seu número de versió. Comptades igual: la de VCF 9.0 té 226 controls i 19 columnes, amb 135 que no vénen posats; la de 9.1 en té 260 i 20 columnes, amb 160. La columna que apareix a la 9.1 i no hi era a la 9.0 és el mapatge a NIST SP 800-53 R5: la taula de correspondències amb la norma és més nova que la guia.

Comparant identificadors, 58 apareixen a la 9.1 i no a la 9.0, i 24 eren a la 9.0 i ja no hi són. Part d'aquell moviment seran reanomenaments i no controls nous de debò —no ho podem distingir des de fora i no ho afirmarem—, però és exactament el que avisa la guia quan li pregunten si pot fer-se servir la versió anterior sobre una de posterior: «Between major versions we rename or remove parameters, change defaults, and add and retire components». Un hardening fet contra el full de 9.0 no és un hardening fet contra el de 9.1.

La frase que descriu la majoria d'incidents que veiem

A la pregunta de si cal tornar a comprovar els ajustos després de pedaçar o actualitzar, la guia respon que sí i dona tres motius. El tercer és aquest: «people make changes during troubleshooting that they never put back». Té raó, i encaixa amb el que diu la literatura des de fa més de vint anys: a l'estudi d'Oppenheimer, Ganapathi i Patterson presentat a USENIX el 2003 sobre per què fallen els grans serveis d'internet, els canvis de configuració fets per operadors encapçalen la llista de causes, i el maquinari n'explica una part molt menor.

Per això la reauditoria periòdica es guanya el seu lloc al calendari: és el que enxampa el canvi temporal que ningú va tornar al seu lloc. I per això insistim tant amb la monitorització —nosaltres tirem de Zabbix i SmokePing— amb una regla simple: que avisi per símptomes abans que truqui un client.

L'ordre de feina, i el pas que la guia no té

La guia proposa sis passos i són bons: filtra al que de debò tens desplegat, audita abans de canviar res, fes primer els P0, llegeix la discussió i l'impacte abans de tocar el paràmetre, anota el que decideixis saltar-te i per què, i torna a comprovar-ho més endavant. El cinquè és el que més gent es salta i el que la mateixa guia justifica millor: «Your auditors will ask about the ones you skipped, as will anyone who inherits the environment after you».

Hi ha un supòsit amagat al quart pas, el de provar el canvi en un entorn de proves abans: pressuposa que el tens i que s'assembla a producció. Si no el tens, aquell pas no existeix i el que anomenes «provar» és desplegar. Muntar un entorn de proves semblant, un desplegament per fases i una tornada enrere d'un clic és menys glamurós que endurir, i evita més avaries.

I nosaltres afegim un setè pas que la llista no porta, i el marquem com a criteri nostre: després d'aplicar els P0, torna a cronometrar la restauració i el camí d'actualització. Els controls que toquen la recuperabilitat no fallen el dia que els apliques; fallen el dia que els necessites, que és precisament quan ningú no té temps de descobrir que l'accés directe a l'amfitrió calia per a l'agent de còpies. El nostre últim simulacre de recuperació completa va trigar 14 minuts: és una dada interna i d'una prova nostra, ho expliquem com a prova i no com a promesa contractual.

I si estàs pensant a marxar de VMware

Diem el conflicte d'interès al davant, com sempre: no som resellers de VMware ni de cap altra plataforma i no venem llicències de ningú, així que això no ens paga comissió en cap direcció. Hem migrat empreses de VMware a Proxmox i també hem recomanat quedar-s'hi quan tenia sentit. Aquesta guia no mou aquella decisió ni un mil·límetre: el full de càlcul existeix igual a l'altre costat, amb altres noms i la mateixa lletra petita. De fet, el dia que vam publicar el nostre checklist de hardening de Proxmox VE hi vam incloure a propòsit un apartat amb el que NO fem, pel mateix motiu pel qual VMware inclou una columna d'impacte.

Si et quedes amb una sola idea, que sigui aquesta: l'entregable d'una feina de compliment i continuïtat no és un clúster endurit, és el registre. Què vas canviar, què vas decidir no canviar i per què, i quin era el valor abans de tocar-ho. El clúster endurit es desfà en una nit dolenta; el registre és el que et permet tornar a muntar-lo.

Fonts (verificades el 6 d'octubre del 2026): l'explicació de les columnes, els sis passos, la definició de les prioritats i les respostes freqüents citades surten de «Security Configuration Guide for VMware Cloud Foundation (VCF)», que a la pàgina apareix encapçalat com a «VCF Security Hardening Guidance», publicat el 5 d'octubre del 2026 al blog de VMware Cloud Foundation i signat per Bob Plankers. Els fitxers de controls de VCF 9.0 i 9.1 són al repositori públic vcf-security-and-compliance-guidelines; vam fer servir el CSV de 9.1 (versió 910-20260612-01) i el de 9.0 (versió 902-20260612-01). Totes les cites en cursiva són en anglès i literals. Els recomptes que segueixen són NOSTRES i es van fer amb un script sobre aquells dos CSV, de manera que qualsevol pot refer-los: els recomptes de 260 i 226 controls, els 160 i 135 valors no predeterminats, el repartiment per component, la coincidència entre prioritat i acció necessària, els 32 controls que esmenten la recuperació, els mapatges de NIST, PCI i STIG, i la comparació d'identificadors entre les dues versions. També són lectura nostra, i així es marca al text, el contrast entre la prioritat del mode de bloqueig i la de la llista de la consola, i l'observació sobre el switch estàndard davant del distribuït. La dada dels 14 minuts del simulacre de recuperació és interna d'everyWAN, d'una prova pròpia, i s'ofereix com a prova i no com a compromís contractual. Estudi citat: Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. Fotografia de portada: «Front of server racks at NERSC», de Derrick Coetzee, Wikimedia Commons, CC0; retallada i enfosquida per nosaltres.