Hardening de VCF: el P0 cierra la puerta y el P2 te deja la llave

La hoja de cálculo tiene 260 filas. En 160 de ellas, la columna que dice si el valor seguro ya viene puesto responde que no. Esa es, contada, la guía de hardening de VMware Cloud Foundation 9.1.

El 5 de octubre VMware publicó una entrada explicando su Security Configuration Guide para VCF, dentro de una serie de veintidós piezas por el mes de la ciberseguridad. La guía en sí no es nueva —las vienen publicando desde los tiempos de vSphere 4.0, y en el repositorio siguen todas— pero la entrada es útil porque explica, columna a columna, qué significa cada campo. Nosotros hicimos lo obvio: descargar el CSV y contar.

Qué hay dentro de la hoja

La guía se entrega como Excel y como CSV. El directorio de VCF 9.1 trae un fichero VERSION con la cadena 910-20260612-01, y el CSV, veinte columnas por control: el identificador, los mapeos a marcos de cumplimiento, el componente afectado, una discusión en prosa, el impacto funcional previsto, la prioridad, el parámetro, el valor de fábrica, el valor recomendado y los comandos de PowerCLI para comprobarlo y para cambiarlo. Son 260 controles. Todo lo que sigue sale de ahí, y cualquiera puede rehacer la cuenta con el mismo fichero.

El reparto por componente no está equilibrado, y conviene saberlo antes de repartir el trabajo: 120 controles son de ESX, 51 de vCenter, 29 de NSX, 26 de Operations y 17 de vSAN. Los 17 restantes se reparten entre Automation, VCF, Operations for Networks, Protection and Recovery, SDDC Manager y el instalador. Casi la mitad de los controles están en el hipervisor.

160 de 260: la lista corta no es tan corta

La entrada del blog tranquiliza al lector con esta frase: «Many controls are secure by default, so the list of real work is usually shorter than it first appears». Es un consejo general y razonable. Para esta guía concreta, la cuenta va en la otra dirección: la columna Is the Default? responde NO en 160 de los 260 controles, y la columna Action Needed dice Modify exactamente en esos mismos 160. El 61,5% de la hoja es trabajo, no auditoría.

Hay además una coincidencia limpia que ahorra tiempo: todos los controles P0 y P1 son de los que hay que cambiar, y todos los P2 ya vienen bien. No hay ni una excepción en las 260 filas. Así que la columna de prioridad y la de trabajo pendiente dicen lo mismo, y puedes ordenar por cualquiera de las dos. Un matiz honesto: 22 de esos 160 llevan la coletilla Upon Feature Enablement, es decir, solo aplican si usas esa función. Quedan 138 que aplican sí o sí.

El P0 cierra la puerta. El P2 te deja la llave

La prioridad P0 significa, según la propia guía, «where there is not a secure default, and you should do this immediately». Hay un control P0 que casi todo el mundo reconoce: esx-9.lockdown-mode, el modo de bloqueo del host. Viene de fábrica en lockdownDisabled y la guía recomienda lockdownNormal. Con él activado, al host ya no se entra por la puerta de atrás: se administra desde vCenter, y los roles y la auditoría de vCenter dejan de poder saltarse entrando directamente a la máquina.

La columna de impacto funcional de ese mismo control dice lo que pasa si lo haces mal:

Y aquí está lo que nos llamó la atención, y lo damos como lectura nuestra, no como hallazgo del fabricante. El control que mantiene esa vía de rescate —esx-9.lockdown-dcui-access, la lista de cuentas que todavía pueden entrar por la consola física del host si queda aislado de vCenter— está clasificado como P2. Y P2 significa que el valor por defecto ya es seguro y que basta con auditarlo de vez en cuando. Su propio texto de impacto avisa de que configurar mal esa lista con el modo de bloqueo activo «can leave the host unrecoverable if vCenter is unreachable».

Es decir: si trabajas la hoja por orden de prioridad, que es lo que la guía te pide, cierras la puerta antes de comprobar que sigues teniendo llave. El orden de prioridad mide riesgo de exposición, no riesgo operativo. Los tres controles de lockdown de la guía —el modo, la lista de la consola y la de usuarios de excepción— se leen juntos o no se leen.

Una columna que existe porque esperan que lo deshagas

Entre las veinte columnas hay una que se llama Installation Default Value, y la entrada del blog explica para qué está: «What the value was before you changed it, because once in a while you may want to undo what you changed». Una guía de hardening que incluye de serie el valor anterior está diciendo en voz baja qué espera que ocurra.

La confirmación está en la primera pregunta frecuente. A «¿da soporte Broadcom a la guía?» la respuesta empieza por sí, y sigue así: «However, if you make a change and something is amiss, our support engineers may ask you to undo it». Es una frase perfectamente razonable desde el lado del fabricante, y es la que convierte tu registro de cambios en parte del control. Si endureciste sin anotar qué tocaste, la noche que algo se rompa estarás deshaciendo a ciegas, y el reloj corriendo.

El switch virtual: el mismo ajuste, el defecto contrario

La entrada del blog elige como ejemplo de control con precio los ajustes de seguridad del switch virtual: «Setting them to what the Guide recommends may prevent clustered applications from working correctly». Fuimos a mirar esas filas y hay algo que el ejemplo no cuenta.

Son tres ajustes clásicos: rechazar transmisiones falsificadas, rechazar cambios de MAC desde el invitado y rechazar el modo promiscuo. En el switch estándar, los dos primeros vienen de fábrica en Accept y la guía los marca como P0 en cuanto uses esa función. En el switch distribuido, esos mismos dos ajustes ya vienen en Reject y figuran como P2: solo auditar, y en dos niveles, porque la política del switch la heredan los grupos de puertos pero un grupo puede sobreescribirla. El modo promiscuo viene cerrado en ambos. La conclusión es nuestra: dos de los tres ajustes te dan trabajo o no según qué tipo de switch tengas, una decisión de red que en la mayoría de instalaciones que hemos visto se tomó por otros motivos.

Y en el texto de impacto del control de cambios de MAC aparece, entre las cargas que dependen de poder cambiarla, una que no es una aplicación del cliente: «applications licensed by MAC address, and vCenter Reduced Downtime Upgrade». Dicho de otro modo, ese endurecimiento puede chocar con el mecanismo que te permite actualizar vCenter sin pararlo. La salida que propone la guía es buena y conviene anotarla: crear un grupo de puertos aparte que lo permita y conectar ahí solo las máquinas autorizadas. La guía documenta además una excepción que ella misma monta: al habilitar vSAN File Services, el proceso pone Accept en el grupo de puertos de ese servicio porque sus nodos presentan más de una MAC, y cerrarlo ahí rompe el tráfico del servicio de ficheros.

La palabra que no sale en los titulares: recuperabilidad

La frase que mejor describe para qué sirve de verdad esta guía está escondida en la explicación de la columna de discusión: «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». Recuperabilidad. Contamos cuántos controles mencionan la recuperación en su discusión o en su impacto: 32 de los 260.

El propio control del modo de bloqueo avisa de que «some operations, such as backup integrations and low-level troubleshooting, require direct host access», y recomienda desactivarlo temporalmente en el host afectado para esas tareas. Ahí está el nudo, y es el eje de casi todo lo que escribimos: un fallo es inevitable, una avería es una decisión de diseño. Si endureces y con ello alargas media hora el camino para restaurar, has cambiado un riesgo que quizá nunca se materialice por un coste que se cobra seguro el día malo. Hazlo, pero ponle número antes de hacerlo. De cuánto cuesta no medirlo hablamos en su día en RTO y RPO sin humo.

Lo que la guía dice que no hace

Esta es la parte que más nos gustó, porque es rara de ver y porque te ahorra una conversación incómoda con un auditor. La guía lleva mapeos a marcos de cumplimiento —contamos NIST SP 800-53 R5 en los 260 controles, PCI DSS 4.0.1 en 255 y un identificador de STIG de la DISA en 168, así que 92 controles no tienen ninguno—, y aun así responde esto a la pregunta de si implementarla te deja conforme con PCI DSS o con NIST: «Not by itself». Los mapeos ahorran tiempo; el cumplimiento, dice, depende del alcance, de los procesos, de las personas y del criterio del auditor.

Sigue diciendo que no cubre lo que corre dentro de las máquinas virtuales, solo la infraestructura y la configuración de las propias máquinas; y que ideas como el mínimo privilegio o la separación de funciones no están enumeradas porque son de diseño, no parámetros. Hay una respuesta más que merece un párrafo propio: en VCF 9.1 las funciones de gestión pasan a una plataforma nueva, VCF Management Services, descrita como una capa con Kubernetes dentro del propio VCF. Y como «there are no user-configurable settings inside VCFMS», no hay controles para ella en la guía.

Menos mandos significa menos formas de equivocarse, y como decisión de ingeniería nos parece defendible. Pero cambia lo que quiere decir la frase «hemos aplicado la guía»: ese plano no lo endureces tú y tampoco lo auditas tú. Lo que te sigue perteneciendo es quién llega hasta él, y eso es justo lo que la guía dice que no enumera.

Del 9.0 al 9.1: 34 controles más y una columna nueva

En el repositorio están las dos guías, y las dos llevan la misma fecha en su número de versión. Contadas igual: la de VCF 9.0 tiene 226 controles y 19 columnas, con 135 que no vienen puestos; la de 9.1 tiene 260 y 20 columnas, con 160. La columna que aparece en la 9.1 y no estaba en la 9.0 es el mapeo a NIST SP 800-53 R5: la tabla de correspondencias con la norma es más nueva que la guía.

Comparando identificadores, 58 aparecen en la 9.1 y no en la 9.0, y 24 estaban en la 9.0 y ya no están. Parte de ese movimiento serán renombrados y no controles nuevos de verdad —no lo podemos distinguir desde fuera y no lo vamos a afirmar—, pero es exactamente lo que avisa la guía cuando le preguntan si puede usarse la versión anterior sobre una posterior: «Between major versions we rename or remove parameters, change defaults, and add and retire components». Un hardening hecho contra la hoja de 9.0 no es un hardening hecho contra la de 9.1.

La frase que describe la mayoría de incidentes que vemos

A la pregunta de si hay que volver a comprobar los ajustes después de parchear o actualizar, la guía responde que sí y da tres motivos. El tercero es este: «people make changes during troubleshooting that they never put back». Lleva razón, y encaja con lo que dice la literatura desde hace más de veinte años: en el estudio de Oppenheimer, Ganapathi y Patterson presentado en USENIX en 2003 sobre por qué fallan los grandes servicios de internet, los cambios de configuración hechos por operadores encabezan la lista de causas, y el hardware explica una parte mucho menor.

Por eso la reauditoría periódica se gana su hueco en el calendario: es lo que pilla el cambio temporal que nadie devolvió a su sitio. Y por eso insistimos tanto con la monitorización —nosotros tiramos de Zabbix y SmokePing— con una regla simple: que avise por síntomas antes de que llame un cliente.

El orden de trabajo, y el paso que la guía no tiene

La guía propone seis pasos y son buenos: filtra a lo que de verdad tienes desplegado, audita antes de cambiar nada, haz primero los P0, lee la discusión y el impacto antes de tocar el parámetro, anota lo que decidas saltarte y por qué, y vuelve a comprobarlo más adelante. El quinto es el que más gente se salta y el que la propia guía justifica mejor: «Your auditors will ask about the ones you skipped, as will anyone who inherits the environment after you».

Hay un supuesto escondido en el cuarto paso, el de probar el cambio en un entorno de pruebas antes: presupone que lo tienes y que se parece a producción. Si no lo tienes, ese paso no existe y lo que llamas «probar» es desplegar. Montar un entorno de pruebas parecido, un despliegue por fases y una vuelta atrás de un clic es menos glamuroso que endurecer, y evita más averías.

Y nosotros añadimos un séptimo paso que la lista no trae, y lo marcamos como criterio nuestro: después de aplicar los P0, vuelve a cronometrar la restauración y el camino de actualización. Los controles que tocan la recuperabilidad no fallan el día que los aplicas; fallan el día que los necesitas, que es precisamente cuando nadie tiene tiempo de descubrir que el acceso directo al host hacía falta para el agente de copias. Nuestro último simulacro de recuperación completa tardó 14 minutos: es un dato interno y de una prueba nuestra, lo contamos como prueba y no como promesa contractual.

Y si estás pensando en irte de VMware

Decimos el conflicto de interés por delante, como siempre: no somos resellers de VMware ni de ninguna otra plataforma y no vendemos licencias de nadie, así que esto no nos paga comisión en ninguna dirección. Hemos migrado empresas de VMware a Proxmox y también hemos recomendado quedarse cuando tenía sentido. Esta guía no mueve esa decisión ni un milímetro: la hoja de cálculo existe igual al otro lado, con otros nombres y la misma letra pequeña. De hecho, el día que publicamos nuestro checklist de hardening de Proxmox VE incluimos a propósito un apartado con lo que NO hacemos, por el mismo motivo por el que VMware incluye una columna de impacto.

Si te quedas con una sola idea, que sea esta: el entregable de un trabajo de cumplimiento y continuidad no es un clúster endurecido, es el registro. Qué cambiaste, qué decidiste no cambiar y por qué, y cuál era el valor antes de tocarlo. El clúster endurecido se deshace en una noche mala; el registro es lo que te permite volver a montarlo.

Fuentes (verificadas el 6 de octubre de 2026): la explicación de las columnas, los seis pasos, la definición de las prioridades y las respuestas frecuentes citadas salen de «Security Configuration Guide for VMware Cloud Foundation (VCF)», que en la página aparece encabezado como «VCF Security Hardening Guidance», publicado el 5 de octubre de 2026 en el blog de VMware Cloud Foundation y firmado por Bob Plankers. Los ficheros de controles de VCF 9.0 y 9.1 están en el repositorio público vcf-security-and-compliance-guidelines; usamos el CSV de 9.1 (versión 910-20260612-01) y el de 9.0 (versión 902-20260612-01). Todas las citas en cursiva están en inglés y literales. Los recuentos que siguen son NUESTROS y se hicieron con un script sobre esos dos CSV, de modo que cualquiera puede rehacerlos: los recuentos de 260 y 226 controles, los 160 y 135 valores no predeterminados, el reparto por componente, la coincidencia entre prioridad y acción necesaria, los 32 controles que mencionan la recuperación, los mapeos de NIST, PCI y STIG, y la comparación de identificadores entre las dos versiones. Son también lectura nuestra, y así se marca en el texto, el contraste entre la prioridad del modo de bloqueo y la de la lista de la consola, y la observación sobre el switch estándar frente al distribuido. El dato de los 14 minutos del simulacro de recuperación es interno de everyWAN, de una prueba propia, y se ofrece como prueba y no como compromiso contractual. Estudio citado: Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. Fotografía de portada: «Front of server racks at NERSC», de Derrick Coetzee, Wikimedia Commons, CC0; recortada y oscurecida por nosotros.