Cifrado de disco completo en un VPS

El cifrado de disco completo responde exactamente a una pregunta: ¿qué obtiene un adversario cuando tiene tu almacenamiento en las manos y la máquina está apagada? Cualquier otra pregunta que puedas tener —qué puede ver el proveedor, qué ocurre si se incauta un servidor en funcionamiento, si tus copias de seguridad están a salvo— tiene una respuesta distinta, y tratarlas todas como una sola es cómo la gente termina con un cifrado que no protege nada.

Esa distinción merece decirse sin rodeos, porque «cifrado con LUKS» aparece en todas las páginas de hosting centrado en la privacidad de este sector, la nuestra incluida. Es un control real, cuesta casi nada de mantener, y también es el control más sobrevalorado del hosting. Esta guía cubre lo que el cifrado en reposo realmente detiene en un servidor alquilado, las tres configuraciones que merece la pena desplegar y los comandos de cada una, los dos ajustes que de verdad importan en un VPS pequeño, y el puñado de errores que convierten todo el ejercicio en pura decoración.

Qué protege realmente el cifrado en reposo

El cifrado en reposo significa que los bytes del medio de almacenamiento son texto cifrado siempre que el volumen esté cerrado. Es una afirmación limitada, y su valor depende de una sola variable: dónde está la clave en el momento en que llega el adversario.

Interprétalo como una definición, no como una decepción. Eliminar la clase de exposición del disco extraído vale la pena en una hora de trabajo precisamente porque es la clase de riesgo contra la que no tienes ninguna otra defensa, y la que ocurre sin que nadie te esté apuntando: el hardware falla y se devuelve, los arrays se retiran, los volúmenes se reasignan al siguiente inquilino. El cifrado convierte todo eso en un no-evento.

Por qué un VPS no es un portátil

En un portátil el diseño es evidente por sí mismo. Escribes una frase de contraseña al arrancar, la clave existe solo en la RAM mientras la máquina está despierta, y apagarla pone fin a la historia. Un servidor no tiene a nadie delante de la consola. Algo tiene que suministrar la clave en cada arranque, y cada candidato a ese «algo» intercambia disponibilidad por protección:

• Una persona la escribe. La disposición más sólida, porque la clave nunca reposa en la máquina — pero el servidor no puede volver de un reinicio sin ti, y necesitas una vía de entrada antes de que exista el sistema operativo.
• La máquina la guarda. Cómodo, y en la mayoría de las configuraciones caseras, contraproducente: un archivo de clave en el mismo disco virtual significa que quien tenga el disco tiene la clave.
• Otra máquina la entrega. Desbloqueo dependiente de la red, normalmente Clevis con un servidor Tang. El servidor se desbloquea a sí mismo solo mientras puede seguir alcanzando un host que controlas, lo cual es una propiedad genuinamente útil — y un traslado de la confianza, no su eliminación.

Hay una segunda diferencia que la mayoría de las guías pasa por alto. En un VPS, /boot y el initramfs están en texto plano, viven en un almacenamiento que en última instancia controla el proveedor, y no existe ninguna cadena de arranque que puedas verificar — ningún TPM que te pertenezca, ningún arranque medido, nada que atestiguar. Un proveedor que quisiera tu frase de contraseña podría alterar el initramfs y recogerla la próxima vez que desbloquees. Eso no es una descripción de nada que hagamos; es una descripción de lo que la arquitectura permite, que es la única forma honesta de razonar sobre un ordenador que alquilas. Nuestra comparación entre VPS y dedicado recorre esa misma frontera de confianza desde el lado del hardware, y nuestra respuesta honesta sobre el anonimato offshore aplica la misma disciplina al marketing que lo rodea.

Las tres configuraciones que merece la pena desplegar

No hay una única configuración correcta — hay aquella cuyo modo de fallo puedes asumir. Estas tres cubren esencialmente todos los casos reales.

Empieza por la primera, salvo que tengas una razón concreta para no hacerlo. Aporta la mayor parte de la protección por una fracción del riesgo operativo, y tiene la única propiedad de la que carecen las otras dos: nada en ella puede impedir que el servidor vuelva a estar en línea. La configuración tres es la única en la que la frase de contraseña es un hecho al que el proveedor no puede llegar, en lugar de una promesa que el proveedor hace, y por eso nuestros servidores dedicados aplican LUKS en la instalación con una frase de contraseña que nunca vemos.

Cifrar un volumen de datos en un VPS en funcionamiento

Esta es la configuración a la que recurrir primero. No se reinstala nada, no cambia nada del proceso de arranque, y si cometes un error el peor resultado posible es un archivo contenedor que descartas. Quince minutos en un servidor Debian o Ubuntu ya activo.

• Instala las herramientas. apt install cryptsetup. Si tu plan te dio un segundo dispositivo de bloques, úsalo directamente y sáltate el siguiente paso.
• Crea un contenedor. En un VPS de un solo disco, la vía práctica es un archivo: fallocate -l 40G /var/lib/vault.img. Se comporta como un disco y se puede ampliar más adelante.
• Formatéalo como LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Acepta los valores predeterminados del cifrado; la sección siguiente cubre el único parámetro que vale la pena tocar en un servidor pequeño.
• Ábrelo y crea un sistema de archivos. cryptsetup open /var/lib/vault.img vault te da /dev/mapper/vault; luego mkfs.ext4 /dev/mapper/vault y mount /dev/mapper/vault /srv/vault.
• Traslada los datos que importan y apunta los servicios hacia ahí. Un bind mount, o un rsync con el servicio detenido, suele ser más limpio que los enlaces simbólicos — a las bases de datos en particular no les gusta que las sigan de un lado a otro.
• Haz copia de seguridad de la cabecera de LUKS. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, y luego mueve ese archivo fuera del servidor. Unos pocos kilobytes dañados al principio del contenedor destruyen todos los bytes que hay detrás, de forma permanente, y esta es la única póliza de seguro que existe.
• Ciérralo y comprueba que puedes volver a entrar. umount /srv/vault && cryptsetup close vault, y luego ábrelo de nuevo a partir de tus notas y no de memoria. Hazlo antes de que haya algo valioso dentro.

Después de un reinicio, la bóveda permanece cerrada hasta que inicias sesión y la abres. Eso no es una limitación que haya que sortear con ingeniería — es todo el sentido de la operación. Un volumen que se abre solo es un volumen cuya clave está en la máquina.

Cifrado de raíz completa con desbloqueo remoto por SSH

Cuando el requisito es que nada legible sobreviva a una incautación en frío — registros, historial de shell, listas de paquetes, la forma de lo que ejecutas — el sistema de archivos raíz también tiene que estar dentro del contenedor. El problema entonces pasa a ser cómo introducir una frase de contraseña en una máquina que aún no ha arrancado, y la respuesta es un pequeño servidor SSH que vive dentro del initramfs.

• Instala cifrado desde el principio. Arranca el instalador de la distribución mediante carga de ISO personalizada y elige el particionado guiado con LVM cifrado. Convertir un sistema de archivos raíz en funcionamiento in situ es posible, pero no vale el riesgo.
• Añade el servidor SSH previo al arranque. apt install dropbear-initramfs, y luego pon tu clave pública en /etc/dropbear/initramfs/authorized_keys. Es un juego de claves distinto de tu SSH habitual — usa una clave dedicada.
• Ciérralo bien. En /etc/dropbear/initramfs/dropbear.conf, establece DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": sin inicio de sesión por contraseña, sin reenvío de puertos, con su propio puerto, y un tiempo de espera de inactividad para que una sesión colgada no mantenga el arranque abierto.
• Dale una red al initramfs. Añade un parámetro ip= estático a GRUB_CMDLINE_LINUX en /etc/default/grub — la forma es ip=address::gateway:netmask::interface:off. Confiar en DHCP en esta fase es cómo la gente termina bloqueada fuera.
• Reconstruye y reinicia. update-initramfs -u && update-grub, luego reinicia y conéctate con ssh -p 2222 root@your-server y ejecuta cryptroot-unlock. Tu cliente avisará de una clave de host desconocida: el initramfs tiene la suya propia, lo cual es normal y merece la pena fijar en una entrada separada de known_hosts.
• Prueba la ruta de fallo antes de confiar en ella. Instala una actualización del kernel, reinicia, desbloquea de nuevo. Las actualizaciones del kernel regeneran el initramfs, y es justo entonces cuando una mala configuración sale a la luz.

Los dos ajustes que importan, y la trampa del VPS pequeño

LUKS2 usa por defecto AES-XTS con una clave de 512 bits y derivación de clave Argon2id. Ambos son correctos. Ajustar el cifrado a mano es una forma de volverse más lento y más débil al mismo tiempo, y internet está lleno de líneas de comandos copiadas que hacen exactamente eso. Sin embargo, hay dos cosas que merecen tu atención.

El rendimiento no es un problema, hasta que lo es

Comprueba la aceleración por hardware con grep -m1 -o aes /proc/cpuinfo y mide con cryptsetup benchmark. En cualquier CPU con AES-NI — que es cada nodo que operamos — AES-XTS mueve varios gigabytes por segundo y por núcleo, muy por encima de lo que entrega un solo disco virtual, así que el coste visible es unos pocos puntos porcentuales de CPU bajo E/S intensa y un pequeño aumento de latencia. Sin AES-NI el panorama se invierte y el cifrado se convierte en el cuello de botella; ese es el único caso en el que un cifrado alternativo es una decisión real y no un gesto de imitación.

La memoria de Argon2id es lo que muerde

Argon2id es deliberadamente hambriento de memoria, y cryptsetup lo calibra en el momento del formateo según la RAM de la máquina en la que estás formateando. Formatea un volumen en una estación de trabajo de 32 GB, muévelo a un VPS de 1 GB, y el desbloqueo puede fallar directamente porque la memoria que exige la derivación de clave no está disponible — peor aún dentro de un initramfs, donde hay mucha menos disponible que en un sistema en funcionamiento. En instancias pequeñas, fíjala: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb la limita a 256 MB. Un valor más bajo es una reducción real de la resistencia frente a la fuerza bruta fuera de línea, así que compénsalo con una frase de contraseña más larga.

Un indicador opcional merece una decisión consciente en lugar de un copia y pega: --allow-discards deja pasar TRIM hasta el dispositivo subyacente, lo cual es bueno para el desgaste del SSD y el rendimiento en régimen estable, y que también revela cuánto del volumen está en uso y aproximadamente dónde. Está desactivado por defecto. Actívalo sabiendo qué es lo que filtra.

Swap, registros, instantáneas — las partes que la gente olvida

Una bóveda cifrada con texto plano filtrándose a su alrededor es el fallo más común de todos, y permanece invisible hasta que alguien mira.

• Swap. Cualquier cosa que esté en memoria puede paginarse a disco, incluido el material que colocaste cuidadosamente en la bóveda. O bien desactiva el swap, o dale una clave aleatoria en cada arranque con una línea de /etc/crypttab como swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Todo lo que escribe donde no miraste. /var/log, /tmp, el directorio de datos de la base de datos, /var/lib/docker, el historial de shell, los journals de systemd. Cifrar /srv/vault mientras PostgreSQL escribe en /var/lib/postgresql no consigue absolutamente nada. Haz el inventario antes de cifrar.
• Instantáneas. Una instantánea a nivel de bloque de un volumen cifrado es texto cifrado y por tanto no hay problema. Una instantánea que captura el estado de la memoria es un objeto completamente distinto y puede contener la clave. Averigua qué tipo toma el panel de tu proveedor antes de usarlo.
• Copias de seguridad. El destino es el lugar equivocado para resolver esto. Herramientas como restic y BorgBackup cifran en el origen con una clave que el destino nunca ve, y por eso un servidor de backup puede ser una máquina corriente en otra jurisdicción en lugar de una de confianza.
• El texto plano que ya enviaste a algún sitio. El cifrado en reposo no es retroactivo. Cualquier cosa ya copiada, enviada por correo o sincronizada en otro lugar queda fuera del límite que estás trazando ahora.

Dónde vive la clave es todo el diseño

Cada una de las configuraciones anteriores es, en realidad, una declaración sobre la custodia de la clave. Existen cuatro opciones y no son equivalentes:

• En tu cabeza, tecleada en cada arranque. Protección máxima, fricción operativa máxima. La máquina realmente no se puede leer sin ti.
• En un archivo en la máquina cifrada. Protege frente a una reventa ingenua del disco y nada más. Si ese archivo está en el /boot en texto plano, no protege absolutamente nada — el error más común, con diferencia, en el cifrado autoalojado.
• En una máquina que controlas, obtenida por la red. Clevis vinculado a un servidor Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. El servidor arranca sin supervisión mientras puede alcanzar su base y se niega a desbloquearse en cualquier otro sitio. Excelente para flotas sin consola, y convierte al host Tang en lo que hay que defender.
• En un TPM. Tiene sentido en hardware que posees. En un VPS, el TPM virtual lo proporciona el mismo hipervisor que estás intentando excluir, así que resuelve la comodidad, no la confianza.

Una sola prueba resuelve la mayoría de los diseños: si la máquina puede llegar a un prompt de inicio de sesión sin ti, la clave está en la máquina. Puede ser un intercambio perfectamente razonable — muchas cargas de trabajo quieren reinicios sin supervisión más de lo que quieren resistencia frente a un adversario decidido. Toma la decisión de forma deliberada, y no describas el resultado como algo que no es.

Lo que puede ver tu proveedor, y dónde entra en juego la jurisdicción

En un VPS hay un hipervisor por debajo de ti. No leemos la memoria del invitado, y no conservamos registros de tráfico, de conexión ni de DNS, ni ningún rastro de consola — pero eso son políticas, y el planteamiento honesto es que un VPS te pide que confíes en ellas. En bare metal no hay ningún hipervisor entre tú y el silicio: el cifrado de disco completo configurado en la instalación, con una frase de contraseña que nunca recibimos, es una propiedad física de la máquina y no una garantía de nuestra parte. Esa diferencia, no la elección del cifrado, es entre lo que realmente estás eligiendo.

Por eso el cifrado y la jurisdicción son las dos mitades de una misma respuesta. El cifrado decide cuánto vale una copia de tu disco; la jurisdicción decide quién puede obligar a que se presente la máquina, mediante qué proceso y con qué rapidez. Operamos en siete — Islandia, Suiza, Panamá, Rumanía, Moldavia, los Países Bajos y Rusia — y el razonamiento para elegir entre ellas está en nuestra guía de jurisdicciones, o en forma más breve mediante el selector de jurisdicción y la página de ubicaciones.

La parte que el cifrado no puede tocar es la divulgación forzosa, porque va dirigida a ti y no al hardware. El Reino Unido, Francia y Australia están entre los países cuya legislación puede exigir a una persona que entregue una clave de descifrado o enfrentarse a una sanción por negarse. Esa exposición sigue a dónde estás tú, no a dónde está el servidor, y ninguna configuración en la máquina la cambia. Registrarse sin documentos de identidad limita desde el principio cuánto rastro documental existe — la razón práctica y poco glamurosa por la que el hosting sin KYC y el cifrado terminan en la misma conversación — pero no es una defensa frente a un tribunal que ya tiene tu nombre.

Nueve errores que convierten el cifrado en decoración

• Desbloqueo automático desde un archivo de clave en el mismo disco. La mayoría de los servidores «cifrados», y el equivalente a dejar la llave puesta en la cerradura.
• Cifrar un volumen al que los datos sensibles nunca llegan. La bóveda está vacía y la base de datos no está dentro de ella.
• No hacer nunca copia de seguridad de la cabecera de LUKS. Un sector dañado al principio del contenedor y todos los bytes que hay detrás desaparecen para siempre.
• No probar nunca la vía de desbloqueo. Entonces una actualización del kernel regenera el initramfs y el siguiente reinicio se convierte en una operación de rescate.
• Formatear en una máquina grande y desbloquear en una pequeña. Argon2id pide una memoria que el VPS no puede ofrecer, y el volumen no se abrirá.
• Elegir una frase de contraseña como si fuera una contraseña de inicio de sesión. Nada limita la velocidad de un ataque fuera de línea salvo la función de derivación de clave. La longitud es lo que compra tiempo.
• Migrar texto plano hacia el cifrado y asumir que el original ha desaparecido. En almacenamiento virtualizado, sobrescribir no borra de forma fiable.
• Enviar la frase de contraseña por el mismo canal que se usa para administrar la máquina. OpSec para servidores cubre el problema de correlación que eso crea.
• Confundir el cifrado de tu proveedor con el tuyo propio. «Toda la infraestructura está cifrada en reposo» —la nuestra incluida— protege la infraestructura. Solo una clave que tú controlas te protege de la infraestructura.

Entonces, ¿merece la pena hacerlo en un VPS?

Sí, con expectativas calibradas. Por una hora de trabajo y sin coste de funcionamiento medible, un volumen de datos cifrado elimina toda una clase de exposición que no puedes abordar de otro modo, y la elimina de forma permanente: hardware retirado, almacenamiento reasignado, una máquina apagada bajo la custodia de otro. Haz al menos eso en todo servidor que contenga algo que importe, justo después de la lista de refuerzo de la primera hora.

Lo que no hace es convertir un ordenador alquilado en tu ordenador. Si tu modelo de amenazas incluye al propio proveedor como adversario, ningún cifrado arregla eso — la respuesta es el hardware dedicado, donde la clave se teclea por IPMI y nunca pasa por un hipervisor, una jurisdicción elegida a propósito, y la disciplina de no poner en ningún servidor lo que no necesita estar ahí. Ajustar el control a la amenaza real es la diferencia entre la privacidad y su apariencia.