Hay una pregunta que aparece en toda auditoría de seguridad y que mucha gente responde mal: «¿Ciframos los datos en reposo?». Se responde mal en las dos direcciones. Unos dicen que no hace falta porque «tenemos firewall y backups», confundiendo amenazas. Otros cifran todo por reflejo, sin entender de qué protege realmente, y acaban con un sistema que no arranca solo tras un corte de luz y nadie recuerda dónde está la clave.
El cifrado en reposo no es una medida contra el ransomware —ese ataque ocurre con el sistema encendido y las claves cargadas, así que el disco está descifrado para el atacante igual que para ti—. Tampoco frena a quien ya tiene acceso legítimo. Protege de un escenario distinto y muy concreto: que el soporte físico salga de tu control con los datos dentro. Un disco que se retira para RMA. Una cabina que se da de baja. Un servidor que se roba de un rack. Un backup que viaja a otra sede. En todos esos casos, sin cifrado, los datos son legibles por quien tenga el hardware en la mano.
Este artículo explica cómo se cifra en reposo un cloud privado sobre Proxmox, las dos vías reales —LUKS y ZFS nativo—, el problema de verdad (la gestión de claves) y por qué esto ha dejado de ser opcional cuando te aplican el ENS, el RGPD o NIS2.
Antes de tocar una tecla, hay que tener clara la amenaza. El cifrado en reposo (data at rest) protege el dato mientras está guardado y el sistema no lo está usando activamente con las claves cargadas. Su modelo de amenaza es el acceso físico no autorizado al soporte.
Protege bien de:
No protege de:
Entender esto evita la trampa de creerse protegido por marcar una casilla. El cifrado en reposo es una capa, con un trabajo concreto. Ni más ni menos.
Proxmox, al asentarse sobre Debian, hereda dos formas maduras de cifrar en reposo. No son excluyentes, pero conviene elegir según el caso.
LUKS (Linux Unified Key Setup) cifra el dispositivo de bloque completo, por debajo del sistema de ficheros. Todo lo que se escribe en ese disco —o partición— va cifrado; todo lo que se lee, se descifra al vuelo. Es transparente para las capas superiores: ZFS, LVM o ext4 ni se enteran de que trabajan sobre un volumen cifrado.
# Cifrar un dispositivo con LUKS
cryptsetup luksFormat /dev/sdb
# Abrirlo (pide la passphrase o la clave) y exponerlo como /dev/mapper/cifrado
cryptsetup open /dev/sdb cifrado
# A partir de aquí se usa /dev/mapper/cifrado como cualquier disco:
# se le pone LVM, ZFS o un sistema de ficheros encimaCuándo LUKS. Cuando quieres cifrar el disco entero de un nodo, incluido el sistema, o cuando trabajas sobre LVM-thin (el almacenamiento por defecto de muchos Proxmox). Es la opción más «de sistema»: cifra el ladrillo y lo demás se construye encima sin cambios.
Si tu almacenamiento es ZFS —muy habitual en Proxmox—, ZFS trae cifrado propio, y es más fino que LUKS: cifra por dataset, no por disco. Puedes tener un pool donde unos datasets están cifrados y otros no, cada uno con su clave, y todo convive en el mismo conjunto de discos.
# Crear un dataset cifrado con clave por passphrase
zfs create -o encryption=aes-256-gcm \
-o keyformat=passphrase \
rpool/datos-sensibles
# Ver el estado de cifrado y de la clave
zfs get encryption,keystatus rpool/datos-sensibles
# Cargar la clave tras un arranque (el dataset no monta sin ella)
zfs load-key rpool/datos-sensiblesCuándo ZFS nativo. Cuando ya usas ZFS y quieres granularidad: cifrar solo los datasets con datos sensibles, dejando el resto sin el coste de cifrado. Tiene una ventaja operativa importante: la replicación ZFS de un dataset cifrado viaja cifrada (zfs send --raw), así que un nodo réplica o un backup remoto recibe los datos sin descifrarlos nunca en tránsito ni en destino. Encaja de maravilla con esquemas de replicación entre sedes.
| LUKS | ZFS nativo | |
|---|---|---|
| Granularidad | Disco / partición | Dataset individual |
| Capa | Bloque (por debajo del FS) | Integrada en ZFS |
| Cifra el sistema operativo | Sí (disco raíz) | No directamente |
| Replicación cifrada extremo a extremo | No de serie | Sí (send --raw) |
| Encaje típico | Nodo completo, LVM-thin | Datasets sensibles sobre ZFS |
La regla práctica: si tu storage es ZFS, el cifrado nativo por dataset suele ser la opción más limpia y flexible. Si necesitas cifrar el disco raíz del nodo o trabajas sobre LVM, LUKS. Y nada impide combinarlos: LUKS para el sistema, ZFS nativo para los datos.
Cifrar es un comando. La parte difícil —la que causa incidentes— es qué pasa con la clave. Aquí es donde los proyectos se pegan el tiro en el pie, en una de dos direcciones opuestas:
El extremo cómodo y falso. Guardas la passphrase en un fichero del propio nodo para que arranque solo sin pedir nada. El sistema se descifra en el boot sin intervención… porque la llave está pegada a la cerradura. Si roban el disco, roban la clave con él. Has cifrado y no has protegido de nada: el escenario del que el cifrado debía defenderte —el hardware fuera de tu control— sigue expuesto.
El extremo seguro y frágil. La passphrase la sabe una persona, vive en su cabeza o en un papel, y hay que teclearla en cada arranque. Muy seguro contra el robo del disco. Muy peligroso el día que hay un corte de luz a las cuatro de la mañana, esa persona no contesta y todo el clúster espera una clave que nadie más tiene. La disponibilidad se ha sacrificado sin querer.
El punto medio sensato pasa por tres ideas:
Este es el 80 % del trabajo real de un despliegue de cifrado. El cryptsetup es el 20 % fácil.
El cifrado en reposo pasó de recomendación a expectativa regulatoria. Con matices que conviene precisar, porque casi ninguna norma dice literalmente «cifra en reposo obligatoriamente».
RGPD. El artículo 32 exige medidas técnicas «apropiadas al riesgo» y menciona el cifrado de forma explícita como ejemplo de medida adecuada. No es una obligación universal, pero sí un estándar de facto: ante datos personales sensibles, un responsable que no cifra en reposo tendrá difícil justificar que aplicó medidas apropiadas. Y hay una zanahoria concreta —el artículo 34: si hay brecha pero los datos estaban cifrados y la clave a salvo, puede no ser obligatorio notificar a los afectados. El cifrado convierte «hemos perdido un disco con datos personales» en un no-incidente reportable.
ENS (Esquema Nacional de Seguridad). En sus categorías media y alta, el ENS contempla el cifrado de la información almacenada dentro de las medidas de protección. Para organismos públicos y sus proveedores, no es opcional en los niveles que manejan información sensible.
NIS2. La directiva —y su trasposición— exige medidas de gestión de riesgos que incluyen el uso de criptografía y cifrado donde proceda. De nuevo, «donde proceda» según análisis de riesgo, pero para las entidades esenciales e importantes que cubre, un dato sensible en reposo sin cifrar es difícil de defender ante un supervisor.
El patrón común: ninguna norma te obliga a cifrarlo absolutamente todo, pero todas esperan que, tras un análisis de riesgo, los datos sensibles en reposo estén cifrados —y que puedas demostrar cómo gestionas las claves. Documentar esa decisión es tan importante como aplicarla. La soberanía del dato empieza por poder afirmar, con pruebas, que quien tenga el soporte físico no tiene los datos.
Sin heroísmos ni parálisis:
¿El cifrado en reposo me protege del ransomware? No. El ransomware ataca con el sistema encendido y los volúmenes montados y descifrados, así que ve los datos igual que tú. Contra ransomware, la defensa son los backups inmutables y la regla 3-2-1. El cifrado en reposo protege de otra cosa: que el soporte físico salga de tu control con los datos legibles.
¿Uso LUKS o el cifrado nativo de ZFS? Si tu almacenamiento es ZFS, el cifrado nativo por dataset suele ser más limpio: granular, con clave por dataset y replicación cifrada extremo a extremo. LUKS es la opción cuando necesitas cifrar el disco raíz del nodo o trabajas sobre LVM. Pueden combinarse.
¿Qué pasa si pierdo la clave de cifrado? Pierdes los datos. Por eso la gestión de claves es la parte crítica: debe existir una copia de la clave o una clave de recuperación custodiada de forma segura y accesible por más de una persona autorizada. Cifrar sin plan de recuperación de claves es programar una pérdida de datos.
¿El RGPD me obliga a cifrar en reposo? No de forma literal y universal, pero el artículo 32 cita el cifrado como medida apropiada, y el 34 permite no notificar a los afectados de una brecha si los datos estaban cifrados y la clave a salvo. En la práctica, para datos personales sensibles, no cifrar es difícil de justificar ante una auditoría.
¿El cifrado ralentiza mucho el almacenamiento? En hardware moderno, poco: las CPU llevan aceleración AES por instrucciones (AES-NI) y algoritmos como AES-256-GCM aprovechan eso. El impacto en cargas típicas de virtualización suele ser marginal frente al beneficio de cumplimiento y protección física.
zfs encryption).¿Tienes que demostrar en una auditoría que tus datos en reposo están cifrados y que gestionas las claves como es debido? Diseñamos contigo el cifrado del almacenamiento y de los backups sobre Proxmox, con un plan de claves que no sacrifique la disponibilidad. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
El modelo de castillo con foso —un cortafuegos fuerte fuera y confianza total dentro— cae en cuanto un atacante entra. La microsegmentación divide la red interna en zonas que no se fían entre sí, de modo que comprometer una máquina no da acceso a las demás. Explicamos cómo se hace con el SDN y el firewall integrados de Proxmox, y por qué NIS2 empuja hacia este modelo.
La guía BP/36 del CCN-CERT (junio de 2026) confirma que el pentest anual ya no basta frente a atacantes que usan IA. Del modelo de auditoría periódica a la validación continua, el gobierno de agentes y la resiliencia por diseño.
El ransomware moderno busca y cifra tus backups antes de atacar. La regla 3-2-1 y las copias inmutables son la diferencia entre restaurar en horas o pagar el rescate. Cómo aplicarlas de verdad.