Qué te da realmente cifrar un disco alquilado
Un servidor tiene dos estados, y el cifrado de disco solo tiene algo que decir sobre uno de ellos. Apagado, el volumen es texto cifrado: el almacenamiento contiene bytes indistinguibles del ruido sin la clave. En marcha, el volumen está montado, lo que significa que la clave maestra se ha derivado, se ha cargado en la memoria del kernel y ha permanecido ahí mientras la máquina ha estado encendida. Cada archivo que el sistema operativo puede leer, lo puede leer porque esa clave está residente. El cifrado no ha dejado de funcionar — simplemente está haciendo exactamente lo que se le pidió.
Esa es una garantía más limitada de lo que sugiere el marketing, y aun así vale la pena tenerla, porque los eventos que cubre son los que realmente ocurren. Un disco se retira de servicio y se revende. Una NVMe averiada vuelve al fabricante bajo RMA con tus datos dentro. Un nodo se apaga y sus discos se clonan. Un archivo de respaldo sale del edificio en un soporte que nadie cifró. Alguien con acceso físico a un rack se lleva a casa lo que no debía. Todo esto es poco vistoso y constituye la inmensa mayoría de las exposiciones reales — mucho más frecuente que la redada sobre una máquina en marcha que todo el mundo imagina.
| Escenario | Estado de la máquina | ¿Ayuda LUKS? | Qué queda expuesto |
|---|---|---|---|
| Disco retirado de servicio, revendido o devuelto por RMA | Apagada | Sí, por completo | Texto cifrado y la cabecera LUKS |
| Nodo apagado, discos clonados | Apagada | Sí | Texto cifrado, diseño de particiones, /boot en claro |
| Archivo de respaldo copiado fuera del sitio | N/D | Solo si el propio archivo está cifrado | Lo que contenga el archivo, en claro |
| Adquisición en vivo de una instancia en marcha | En marcha | En la práctica, no | Todo — la clave está en la RAM |
| Compromiso del sistema en marcha | En marcha | No | Todo lo que expone el volumen montado |
El hipervisor forma parte de tu modelo de amenazas, y el cifrado no lo elimina
En un VPS, tu kernel es un invitado. Quien opera el hipervisor tiene la memoria de ese invitado tal como tú tienes el contenido de un archivo, y no hay ningún paso criptográfico de por medio. virsh dump escribe la RAM de un dominio en marcha a un archivo como operación rutinaria; la migración en vivo copia esa misma memoria por la red por diseño, porque eso es precisamente lo que es una migración. Una clave maestra de LUKS que vive en la memoria del invitado está dentro de todo eso.
Así que la frase honesta es esta: el cifrado de disco completo en un VPS protege tus datos de todo el mundo excepto de quien opera el hipervisor — y también de esa parte, pero solo mientras la máquina está apagada. Cualquier proveedor que afirme que cifrar el disco de tu invitado hace que tus datos sean ilegibles para ellos en una instancia en marcha está describiendo una máquina que no existe. Preferimos dejarlo por escrito antes que dejarte inferir algo más cómodo.
Si el proveedor forma genuinamente parte de tu modelo de amenazas, la respuesta no es un cifrado más fuerte. Es eliminar el hipervisor: un servidor dedicado ejecuta tu kernel directamente sobre el metal, así que leer su memoria exige tener la máquina físicamente en la mano y montar un ataque tipo DMA o cold-boot contra la RAM — lento, ruidoso y que exige un nivel de acceso que una solicitud rutinaria no otorga. La guía de VPS frente a dedicado explica dónde ese cambio se amortiza también por otros motivos. Las extensiones de computación confidencial como AMD SEV-SNP e Intel TDX apuntan precisamente a esta brecha, pero hoy no son algo habitual en un VPS de alquiler y trasladan la confianza al fabricante de la CPU en lugar de eliminarla.
Tres formas de implementarlo, y lo que cuesta cada una
En la práctica hay tres formas, y todas intercambian seguridad por cuánto duelen tus reinicios. Una raíz cifrada desbloqueada desde la consola es la más fuerte y la más molesta: nada sobrevive a un reinicio sin una persona de por medio. Una raíz cifrada con un servidor SSH en el initramfs ofrece la misma seguridad con desbloqueo remoto, y es lo que debería construir la mayoría de la gente. Un volumen de datos cifrado sobre una raíz en claro es la opción fácil, y la que decepciona en silencio.
Decepciona porque una raíz en claro acumula tus secretos, lo quieras o no. Ahí escribe el journal de systemd. También el historial de la shell, la caché de paquetes, los core dumps, /tmp, el data root por defecto de Docker y — la que pilla a casi todo el mundo — el swap, que es adonde va la memoria de un proceso cuando la máquina está bajo presión. Cifrar /var/lib/mysql mientras el swap permanece sin cifrar justo al lado no es una defensa parcial, es una defensa completa con un agujero en el medio.
| Configuración | Desbloqueo | Sobrevive a un reinicio desatendido | Veredicto honesto |
|---|---|---|---|
| Raíz cifrada, desbloqueo por consola | KVM-over-VNC o IPMI | No — se queda caída hasta que una persona la desbloquea | La más fuerte; adecuada para una máquina que reinicias pocas veces |
| Raíz cifrada, dropbear en el initramfs | SSH al puerto de desbloqueo | No — pero puedes desbloquearla desde cualquier lugar | La opción por defecto sensata |
| Volumen de datos cifrado, raíz en claro | Script o manual tras el arranque | Sí | Débil salvo que se gestionen el swap, los logs y lo temporal |
| Raíz cifrada, archivo de clave en /boot en claro | Automático | Sí | Defiende contra un disco revendido y nada más |
Instalar una raíz cifrada, paso a paso
1. Arranca un instalador, no una plantilla. Una imagen preconstruida no puede darte una raíz cifrada, porque el disco se escribió antes de que existieras como cliente. Todos los planes de BitVPS admiten reconstrucción desde ISO, subida de una ISO personalizada y netboot, y todos los planes incluyen una consola de emergencia KVM-over-VNC — que es la parte que importa, porque necesitas observar un instalador que va a hacer preguntas. Los servidores dedicados ofrecen la misma capacidad mediante un punto de acceso IPMI protegido por VPN, con montaje de ISO y acceso a BIOS.
2. Particiona con una pequeña área de arranque en claro. Una partición pequeña para /boot o la partición de sistema EFI, y todo lo demás dentro de un único contenedor LUKS. El bootloader y el initramfs deben ser legibles antes de que exista ninguna clave, así que esa partición sigue siendo legible para cualquiera que clone el disco. Diseña tu esquema contando con eso, en lugar de fingir lo contrario.
3. Crea el contenedor. cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/vda2. LUKS2 con argon2id es precisamente la clave: argon2id es memory-hard, está especificado en RFC 9106, y hace que un ataque de adivinación offline sea costoso en hardware en lugar de simplemente lento en software — la diferencia entre una granja de GPU royendo tu frase de contraseña y una granja de GPU que no vale la pena apuntar contra ella. Mantén el coste de memoria dentro de lo que la máquina puede asignar durante el arranque temprano; en una instancia de 4 GB, un coste ajustado en tu portátil de 64 GB simplemente hará que el desbloqueo falle.
4. Ábrelo e instala. cryptsetup open /dev/vda2 cryptroot, luego LVM o un sistema de archivos directamente sobre /dev/mapper/cryptroot, y a continuación ejecuta el instalador de la distribución apuntando ahí, con /boot en la partición en claro. Debian, Ubuntu, Alpine, Arch, Rocky, Fedora y FreeBSD lo gestionan todos; las páginas de dm-crypt de la wiki de Arch son la referencia más completa, sea cual sea la distribución que realmente uses.
5. Pon un servidor SSH en el initramfs. Instala dropbear-initramfs, deja tu clave pública en /etc/dropbear/initramfs/authorized_keys, y añade un parámetro ip= a la línea de comandos del kernel para que la interfaz se active antes de la solicitud de la frase de contraseña. Si te saltas ese parámetro, habrás construido una máquina que arranca hasta un prompt al que nadie puede llegar.
6. Reconstruye y reinicia. update-initramfs -u incorpora el servidor, tu clave y los ajustes de red a la imagen que carga el bootloader. Luego reinicia con la consola abierta, porque el primer intento es el que sale mal.
7. Desbloquea y confirma el traspaso. Conéctate por SSH al puerto de desbloqueo y ejecuta cryptroot-unlock. El initramfs presenta una clave de host distinta a la del sistema instalado, así que tu cliente avisará ruidosamente en la primera conexión — ese es el comportamiento correcto y una señal útil, no un obstáculo: fija esa huella como su propia entrada en known_hosts en lugar de desactivar la verificación de la clave de host. Que la sesión se corte es cómo sabes que el sistema real ha tomado el control.
Desbloqueo remoto, y la pregunta de las 4 de la madrugada que nadie se hace primero
Ejecuta el servidor SSH del initramfs en su propio puerto — 2222 es lo habitual — para que las dos claves de host nunca choquen en la misma entrada de known_hosts. Prefiere un ip= estático antes que DHCP: el initramfs es un entorno mínimo, y una negociación DHCP que falla te deja con una máquina que está encendida, inalcanzable y esperando en un prompt. Si dependes de IPv6, comprueba que tu initramfs realmente lo configura; varias distribuciones en esa fase todavía solo activan v4.
Conserva la consola como respaldo incluso después de que el desbloqueo por SSH funcione. El fallo con el que acabarás topándote no será criptográfico, sino una actualización del kernel que reconstruyó el initramfs sin tu clave, o un parámetro de red que cambió bajo tus pies — y en ese momento la única vía de entrada es la consola KVM-over-VNC que incluye el plan. Tener ambas cosas no es redundancia, es la diferencia entre una molestia y una reconstrucción desde cero.
Y luego está la pregunta operativa, que es la que hay que resolver antes de construir nada de esto: una raíz cifrada significa que un reinicio desatendido deja tu servicio caído hasta que una persona lo desbloquea. Mantenimiento del nodo, un kernel panic, un corte de energía — la máquina vuelve a un prompt, no a tu aplicación. Si eso es inaceptable para tu carga de trabajo, no lo tapes con un archivo de clave en la partición de arranque en claro. Eso es una cerradura con la llave pegada a la puerta con cinta adhesiva, y solo defiende contra un disco revendido y nada más. Elígelo deliberadamente si quieres, pero anota en tu propio runbook que eso es lo que has elegido.
Todo lo que se filtra alrededor del volumen cifrado
El volumen rara vez es donde las cosas salen mal. Lo que sale mal es el material que nunca llegó a entrar en él.
| Fuga | Por qué ocurre | Solución |
|---|---|---|
| Swap | La memoria de los procesos — incluidas las claves — se vuelca al disco bajo presión | Swap dentro del contenedor, o un dispositivo de swap con clave aleatoria, o ninguno |
| Imagen de hibernación | Un volcado completo de la RAM escrito al disco por diseño | Desactívala en un servidor; ahí no pinta nada |
| /boot e initramfs en claro | Deben ser legibles antes de que exista ninguna clave | Acéptalo, y trata cualquier modificación como un compromiso — verifica, o usa Secure Boot donde esté disponible |
| Journal escrito antes del montaje | Los logs de arranque temprano caen en la partición en claro | Comprueba dónde vive realmente tu journal antes de que se abra el volumen |
| Data root de Docker | Por defecto en /var/lib/docker, fuera de un volumen de datos añadido a posteriori | Muévelo dentro, o cifra la raíz en su lugar |
| Monitorización y logs fuera de la máquina | Los agentes envían el contenido de archivos a un tercero en claro | Audita lo que envía el agente antes de confiar en el volumen |
Hay una propiedad que conviene dejar clara, porque se sobrevende con regularidad: una cabecera LUKS se delata a sí misma. Cualquiera que clone el disco ve que hay presente un contenedor cifrado, qué cifrado usa, los parámetros del KDF y cuántas ranuras de clave están ocupadas. LUKS te da confidencialidad, no negación plausible, y construir un plan que dependa de que nadie note el contenedor es construir sobre arena.
Frases de contraseña, archivos de clave y cabeceras separadas
La frase de contraseña es todo el sistema. Argon2id encarece cada intento, pero caro multiplicado por un espacio de claves pequeño sigue siendo barato: cinco o seis palabras de una lista diceware superan a una contraseña de once caracteres con sustituciones, y no por poco margen. Ajusta el coste con --iter-time frente a la máquina que realmente va a desbloquear el volumen, no la que estás usando para escribir, y nunca reutilices una frase de contraseña que haya estado cerca de una cuenta sometida a KYC.
Un archivo de clave elimina la escritura y desplaza el problema: cryptsetup luksAddKey añade uno a una ranura libre, y la única versión que merece la pena tener es la que nunca reposa en el servidor — guardada en tu propia máquina o en un token de hardware, y entregada al desbloqueo a través de la sesión SSH. Una cabecera separada (--header) va más allá: el dispositivo de datos se vuelve indistinguible de bytes aleatorios porque los metadatos viven en otro sitio. La contrapartida es implacable. Si pierdes la cabecera, el volumen desaparece de forma permanente, sin ningún recurso posible — así que tómate en serio cryptsetup luksHeaderBackup y guarda esa copia de seguridad en algún sitio que esté a su vez cifrado. Las preguntas frecuentes de cryptsetup y la documentación de dm-crypt del kernel son las dos referencias que merece la pena leer antes de comprometerte con un diseño.
Y una regla sin excepciones: la frase de contraseña nunca va en un ticket de soporte. Ni el nuestro, ni el de nadie. Nada de lo que hacemos la requiere, ninguna operación que podamos realizar en tu nombre la necesita, y un ticket es un registro escrito en una base de datos. Si algún proveedor te la pide alguna vez, ahí termina la conversación.
Qué revela realmente un disco clonado
Vayamos al caso concreto de la máquina apagada, porque la vaguedad aquí no ayuda a nadie. Un investigador con una imagen de tu disco tiene: el texto cifrado, la cabecera LUKS con su cifrado, los parámetros del KDF y el número de ranuras, la tabla de particiones, los tamaños de todo, y la partición de arranque en claro completa — tu kernel, tu initramfs, y las marcas de tiempo de modificación de cada archivo que contiene. Este último dato es más informativo de lo que la gente espera. Los momentos de instalación de paquetes esbozan una cronología, y un initramfs que contiene una clave de dropbear dice algo sobre cómo se administró la máquina.
Lo que no tienen es el contenido. Frente a un contenedor LUKS2 moderno con argon2id y una frase de contraseña real, el ataque offline no es cuestión de esperar más tiempo — sencillamente no está sobre la mesa. Esa es toda la propuesta de valor, y es una buena propuesta.
El caso de la máquina en marcha es lo contrario, y se resume en poco: todo. No porque el cifrado haya fallado, sino porque la clave está residente, que es la condición bajo la cual un sistema de archivos montado funciona siquiera.
Las instantáneas se sitúan en un punto intermedio y sorprenden a la gente. Nuestras instantáneas horarias con retención de 7 días son a nivel de bloque, de modo que un volumen cifrado genera instantáneas en forma de texto cifrado — bien, y el corolario muerde: esa instantánea tampoco es una copia que puedas leer sin la frase de contraseña. Pierde la clave y las instantáneas quedan exactamente tan irrecuperables como el original. Planifica una ruta de restauración que incluya la frase de contraseña, o habrás construido siete días de ruido muy fiable. Lo que conservamos sobre ti fuera del volumen está recogido en la política de privacidad, y publicamos semanalmente un warrant canary firmado con PGP como evidencia permanente en lugar de una promesa.
Las partes que deciden el resultado no son criptográficas
Nadie ha perdido datos porque AES-256-XTS haya fallado. Los pierden porque la frase de contraseña se reutilizó de una cuenta de un exchange que tenía su pasaporte registrado, porque el archivo de clave se dejó en la partición de arranque en claro para que los reinicios fueran silenciosos, porque el respaldo fuera del sitio era un tarball sin cifrar, porque la frase de contraseña está en el historial de la shell de su portátil, o porque un agente de monitorización llevaba todo el tiempo enviando el contenido de archivos a un SaaS.
Y la silenciosa: un servidor que nunca se apaga pasa toda su vida en el estado en el que nada de esto ayuda. Una instancia con 400 días de actividad lleva 400 días descifrada. Si los datos son genuinamente fríos — un archivo, una copia de la clave, registros que consultas dos veces al año — mantenlos en un contenedor que abres cuando lo necesitas y cierras con cryptsetup close cuando terminas. Diez segundos de escritura convierten una exposición permanente en una momentánea, y esa conversión vale más que cualquier parámetro que puedas pasarle a luksFormat.
Aprovecha para aplicar el mismo razonamiento a la jurisdicción. El cifrado decide qué es legible; dónde se ubica la máquina decide quién tiene derecho a preguntar, y a través de qué alianzas viaja la solicitud. Las dos cosas no son sustitutas entre sí, y quienes lo hacen bien las tratan como una sola decisión.
Qué ofrecemos, y qué no podemos ofrecer
Todos los planes desde el Starter de $8.50 en adelante incluyen lo que una raíz cifrada realmente necesita: virtualización KVM con root completo, la posibilidad de arrancar ISOs personalizadas y netboot, reconstrucción desde ISO desde el panel, carga de módulos del kernel, y una consola de emergencia KVM-over-VNC para el momento en que el initramfs no vuelve. Los niveles dedicados añaden un punto de acceso IPMI protegido por VPN con consola, ciclo de energía, montaje de ISO y acceso a BIOS. Nada del cifrado es un producto que te vendamos — es algo que tú construyes, y nuestro trabajo es no estorbar.
Lo que no podemos hacer es más útil decirlo. En un VPS en marcha, el hipervisor puede leer la memoria del invitado; eso es la arquitectura, no un ajuste de política, y ningún cifrado que instales dentro del invitado lo cambia. Lo que ofrecemos frente a eso no son matemáticas, sino postura y evidencia: sin netflow, sin PCAP, sin duplicación de NIC, IPs de sesión del panel purgadas a las 24 horas, sin KYC en el registro para que la cuenta no sea una palanca, pago solo en cripto para que el rastro de facturación tampoco lo sea, y un canario semanal firmado con PGP que puedes comprobar tú mismo. Solo el hardware dedicado elimina el hipervisor de la ecuación, y solo apagar la máquina elimina la RAM de ella.
Si esto se lee como un argumento en contra de nuestro propio VPS en ciertos modelos de amenazas, es porque lo es. Preferimos venderte lo correcto dos veces que lo incorrecto una sola. Despliega una instancia con una ISO y prueba la instalación en un Starter durante un mes; si la respuesta resulta ser metal, los niveles dedicados empiezan en $39.50 y tardan de dos a cuatro horas en aprovisionarse en lugar de 41 segundos.
