Un vistazo en 33 segundos
- La interfaz de Proxmox controla todas tus VMs, discos y backups: quien la compromete, lo compromete todo. Es el activo a proteger primero.
- Usar
root@pam para el día a día es el error base. Crea cuentas personales con permisos mínimos y reserva root para lo imprescindible.
- Activa doble factor (2FA/TOTP) en las cuentas administrativas: una contraseña robada deja de ser suficiente para entrar.
- Para automatización, usa tokens de API acotados, nunca la contraseña de root; se revocan sin cambiar credenciales de personas.
- Aísla la red de gestión: el acceso a la interfaz (puerto 8006) no debería estar expuesto a Internet, sino tras VPN o bastión y firewall.
Dedicas esfuerzo a cifrar los datos, a segmentar la red, a hacer backups. Y entonces dejas la interfaz de administración de Proxmox accesible con un solo usuario root, contraseña, y sin más. Es como blindar todas las habitaciones de una casa y dejar la llave maestra puesta en la puerta principal. Porque eso es el panel de Proxmox: la llave maestra. Desde ahí se controlan todas las máquinas virtuales, se accede a sus discos, se borran o se restauran los backups, se reconfigura la red. Quien compromete ese acceso no compromete una máquina: las compromete todas, y además tus copias de seguridad.
Por eso endurecer el acceso al hipervisor no es un extra: es la base sobre la que se sostiene todo lo demás. De poco sirve la microsegmentación o el cifrado en reposo si la consola que gobierna toda la plataforma tiene una puerta débil. Este artículo explica cómo cerrar esa puerta: cuentas y permisos, doble factor, tokens de API y aislamiento de la red de gestión. Nada exótico; medidas concretas que mucha gente no aplica.
Deja de usar root para todo
El primer y más común error: administrar el día a día con root@pam, la cuenta de superusuario. Es cómodo —puede todo— y precisamente por eso es peligroso: si esa credencial se filtra o se usa en un sitio comprometido, el atacante hereda el control total. Además, con todo el mundo usando la misma cuenta root, pierdes la trazabilidad: no sabes quién hizo qué.
La práctica correcta se apoya en el sistema de control de acceso basado en roles (RBAC) que Proxmox trae de serie:
- Cuentas personales, una por administrador, en lugar de un root compartido. Cada acción queda atribuida a una persona.
- Permisos mínimos por cuenta: cada usuario recibe solo los roles que necesita, sobre los recursos que le competen. El operador que gestiona un grupo de VMs no necesita poder reconfigurar el clúster entero.
root@pam reservado para lo que de verdad lo requiere, no para el trabajo diario.
Proxmox organiza esto con usuarios, grupos, roles y pools (agrupaciones de recursos). Asignas permisos a grupos sobre pools, y metes a las personas en los grupos que les tocan. El principio rector es el de mínimo privilegio: nadie tiene más poder del que su tarea exige. Es el mismo criterio de «denegar por defecto, permitir lo justo» que aplica a la red, llevado a las personas.
Doble factor: que una contraseña robada no baste
Una contraseña, por buena que sea, puede filtrarse: phishing, reutilización, una brecha en otro sitio. El doble factor de autenticación (2FA) hace que robar la contraseña no baste para entrar, porque además hace falta un segundo elemento —un código temporal de una app, o una llave de seguridad física— que el atacante no tiene.
Proxmox soporta 2FA de fábrica, y activarlo en las cuentas administrativas es de las mejores relaciones esfuerzo/protección que existen:
- TOTP (códigos temporales de una app como cualquier autenticador): lo más habitual y accesible.
- WebAuthn / llaves de hardware (tipo YubiKey): el nivel más alto, resistente incluso al phishing.
- Claves de recuperación, para no quedarte fuera si pierdes el segundo factor.
La recomendación es clara: 2FA obligatorio, como mínimo, en toda cuenta con permisos administrativos. Si tu Proxmox es accesible desde cualquier red que no controles al 100 %, 2FA en todas las cuentas. Es la medida que convierte una contraseña filtrada en un susto en vez de una brecha.
Tokens de API: automatizar sin repartir la llave maestra
Cuando automatizas —con Terraform, scripts, herramientas de monitorización o backup—, algo necesita autenticarse contra Proxmox sin una persona detrás. La tentación es usar la contraseña de root. Es un error de seguridad grave: esa credencial acaba en ficheros de configuración, en variables, en pipelines, y si se filtra, es control total.
La forma correcta son los tokens de API: credenciales específicas para automatización, con dos propiedades clave:
- Acotados: un token se crea con permisos limitados —solo lo que esa automatización necesita, sobre los recursos que toca—. Un token para crear VMs en un pool no puede tocar el resto del clúster.
- Revocables de forma independiente: si un token se filtra o la herramienta que lo usa se retira, lo revocas sin afectar a nadie más ni cambiar contraseñas de personas. Un token comprometido se apaga en segundos.
La regla: una automatización, un token acotado; nunca la contraseña de root en un script. Y los tokens, como cualquier secreto, fuera del control de versiones y en un gestor de secretos.
Aísla la red de gestión
De nada sirve el mejor control de acceso si la interfaz está colgada de Internet para que cualquiera intente fuerza bruta contra ella. El acceso a la administración de Proxmox —la interfaz web en el puerto 8006, y el SSH de los nodos— no debería estar expuesto directamente a Internet. Debe vivir en una red de gestión aislada, alcanzable solo por quien tiene que administrarla:
- Red de gestión separada, no la misma por la que salen los servicios públicos. Es una zona más en tu esquema de microsegmentación.
- Acceso solo por VPN o bastión: administras conectándote primero a una red de confianza, no exponiendo el panel al mundo.
- Firewall delante: el firewall de Proxmox restringe quién puede siquiera intentar hablar con el puerto de gestión. Denegar por defecto, permitir las IPs de administración.
- Certificados TLS válidos para la interfaz, evitando el aviso de certificado que normaliza ignorar advertencias.
Con esto, aunque una credencial se filtrara, el atacante primero tendría que estar dentro de tu red de gestión para siquiera intentar usarla. Capas.
El encaje con el cumplimiento
Nada de esto es solo buena higiene: es lo que esperan los marcos de cumplimiento. El ENS, el RGPD y NIS2 exigen control de accesos, autenticación robusta y trazabilidad de quién hace qué sobre los sistemas. Cuentas personales con permisos mínimos dan trazabilidad; el 2FA da autenticación robusta; los tokens acotados y el aislamiento de gestión reducen la superficie. Ante una auditoría, «cada administrador tiene su cuenta con 2FA y permisos mínimos, y la gestión está aislada tras VPN» es una respuesta sólida; «entramos todos con root y contraseña» no lo es.
Preguntas frecuentes
¿Por qué no debo usar root@pam para administrar Proxmox a diario?
Porque concentra el control total en una credencial compartida: si se filtra o se usa en un sitio comprometido, el atacante hereda el poder sobre toda la plataforma, y además pierdes la trazabilidad de quién hizo qué. Lo correcto es una cuenta personal por administrador con permisos mínimos, y reservar root para lo imprescindible.
¿Proxmox soporta doble factor?
Sí, de fábrica: TOTP (códigos de una app autenticadora), WebAuthn con llaves de hardware tipo YubiKey, y claves de recuperación. La recomendación es activarlo al menos en todas las cuentas con permisos administrativos. Convierte una contraseña filtrada en un susto en lugar de una brecha.
¿Qué es un token de API y por qué usarlo?
Es una credencial para automatización (Terraform, scripts, monitorización) que se crea con permisos acotados y se puede revocar de forma independiente. Usarlo evita poner la contraseña de root en ficheros y pipelines: si el token se filtra, lo apagas al instante sin tocar credenciales de personas, y su alcance limitado reduce el daño posible.
¿Puedo dejar la interfaz de Proxmox accesible desde Internet?
No es recomendable. El panel de gestión (puerto 8006) y el SSH de los nodos deberían vivir en una red aislada, accesible solo por VPN o bastión y protegida por firewall. Exponerlos a Internet invita a ataques de fuerza bruta y amplía enormemente la superficie. La gestión se administra desde dentro, no desde el mundo.
¿Todo esto es necesario o es exagerado?
Es proporcional a lo que protege: el panel controla todas tus máquinas y tus backups. Las medidas (cuentas con permisos mínimos, 2FA, tokens acotados, red de gestión aislada) son estándar de la industria y las esperan marcos como ENS, RGPD y NIS2. El coste de aplicarlas es bajo; el de no hacerlo, un único punto de fallo que compromete toda la plataforma.
Fuentes
¿Tu plataforma está bien protegida por dentro pero el panel que la controla sigue con root y contraseña? Te ayudamos a endurecer el acceso a Proxmox —cuentas, 2FA, tokens y red de gestión aislada— para cerrar la puerta que lo abre todo. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
