Cifrado ZFS: seguridad sólida sin matar el rendimiento

enero 26, 2026 • febrero 3, 2026 • Lectura: 28 min • Views: 10

¿Te fue útil?

Antes, el cifrado era algo que activabas porque el departamento legal lo exigía, y luego pasabas el siguiente trimestre explicando por qué las gráficas de almacenamiento parecían una pista de esquí. ZFS cambió esa dinámica: el cifrado es por dataset, online y está diseñado para mantener tu canal de almacenamiento predecible—si lo tratas como ingeniería, no como una casilla por marcar.

Esta es la guía de producción que desearía que más equipos hubieran tenido antes de su primer incidente “lo ciframos todo, ¿por qué llora la base de datos?”. Cubriremos qué hace realmente el cifrado nativo de ZFS, de dónde viene el overhead, cómo mantener la replicación coherente y cómo diagnosticar cuellos de botella rápidamente cuando el pager ya está caliente.

Qué es el cifrado ZFS (y qué no es)

El cifrado nativo de OpenZFS es cifrado a nivel de dataset. Puedes cifrar un dataset y dejar otro en texto plano, y al pool no le importa. Eso no es un accidente: es una decisión operativa incorporada en la característica. El cifrado ocurre por debajo de la interfaz del sistema de archivos pero por encima de la capa vdev. En términos prácticos:

Lo que hace

Cifra el contenido y los metadatos del dataset para ese dataset. Eso incluye datos de archivos, atributos de archivos, la estructura de directorios y la mayor parte de los metadatos que ZFS guarda para ese dataset. Un atacante con acceso bruto al disco (o un array robado) no puede leer tus datos sin las claves.

Lo que no hace

No cifra todo el pool. Algunos metadatos a nivel de pool permanecen visibles (nombre del pool, topología de vdev, alguna información de asignación). Normalmente está bien—si alguien tiene tus discos, tienes problemas más grandes que que sepan que usaste raidz2—pero importa para modelar amenazas.

No reemplaza el control de acceso. Si un atacante tiene root en un host en ejecución con el dataset desbloqueado, el cifrado es mayormente escenografía. El cifrado protege los datos en reposo, no las máquinas comprometidas. Si alguien puede ejecutar zfs send como root, no necesita derrotar AES; puede simplemente exfiltrar los datos “educadamente”.

No es una sentencia de muerte para el rendimiento. Pero puede convertirse en una si lo combinas con bloques pequeños, escrituras síncronas, CPUs débiles y la creencia de que “la compresión es opcional”. Una pila de almacenamiento no te castiga por cifrar; te castiga por pretender que el cifrado es lo único que está pasando.

Chiste #1: El cifrado es como el cinturón de seguridad—molesto hasta que te salva, y aun así no deberías estrellarte a propósito.

Algunos hechos e historia que importan

Algunos puntos breves de contexto que te ayudan a tomar mejores decisiones:

ZFS nació en Sun con la mentalidad de “el almacenamiento es un sistema, no un montón de discos”; el ecosistema moderno de OpenZFS mantuvo esa disciplina incluso cuando las implementaciones se separaron y reunieron.
El cifrado nativo de ZFS llegó más tarde de lo que la gente esperaba porque hacerlo “a la manera de ZFS” significa mantener correcta la semántica de snapshots, el comportamiento de send/receive y la consistencia en disco.
El cifrado de ZFS es por dataset, no por pool. Eso permite una adopción gradual y hace que las migraciones sean menos aterradoras.
Cifrado y compresión conviven bien en ZFS porque la compresión ocurre antes del cifrado en la tubería—comprimir texto cifrado es, por conocido, inútil.
AES-GCM es común en configuraciones modernas de ZFS porque ofrece cifrado autenticado (confidencialidad + integridad) con buena aceleración por hardware en la mayoría de CPUs de servidor.
zfs send puede transmitir flujos cifrados en crudo (cuando es compatible) de modo que el receptor puede almacenar bloques cifrados sin ver nunca el texto plano—útil para dominios de backup.
El recordsize y la forma de la carga importan más que el “overhead de cifrado” para muchos sistemas reales; I/O aleatorio y escrituras síncronas dominan mucho antes que AES.
La gestión de claves es el verdadero riesgo de fiabilidad: no porque la criptografía sea difícil, sino porque los humanos olvidan frases, rotan claves mal o diseñan el desbloqueo en el arranque como una ocurrencia tardía.

Modelo de amenazas: qué proteges, de forma realista

Antes de elegir una estrategia de cifrado, decide qué significa “seguro” en tu entorno. En producción, el modelo de amenazas que más importa es aburrido:

Discos perdidos o robados durante RMA, envío o desmantelamiento.
Servidores robados (sí, todavía sucede, especialmente en oficinas remotas y sucursales).
Exposición de medios de backup—un snapshot replicado fuera del sitio es una brecha de datos esperando a ser encontrada.
Acceso mal ubicado: alguien obtiene acceso a un estante de almacenamiento, consola de hipervisor o un appliance de backup que no debería.

El cifrado nativo de ZFS es muy bueno para “los datos están seguros si los discos se van caminando”. Es menos útil para “alguien obtuvo root en la máquina”. Para eso necesitas hardening, mínimo privilegio y monitorización. El cifrado es una capa, no un halo.

Modelo de rendimiento: a dónde van los ciclos

Hablemos de la parte de “matar el rendimiento”. En campo, las regresiones de rendimiento atribuidas al cifrado suelen venir de uno de cuatro sitios:

1) Ciclos de CPU (pero a menudo no donde crees)

En servidores x86 modernos con AES-NI (o aceleración equivalente), el cifrado AES-GCM típicamente no es el cuello de botella para cargas secuenciales. Donde lo notas:

IOPS muy altos con bloques pequeños (cargas con muchos metadatos, lectura/escritura aleatoria).
Sistemas ya limitados por CPU (compresión, checksums, dedup, matemáticas de paridad RAIDZ pesadas, SMB signing, etc.).
Entornos virtualizados donde el tiempo “steal” de CPU se vuelve el saboteador silencioso.

2) Amplificación de I/O por desajuste del recordsize

El cifrado no cambia tu recordsize, pero sí sube la apuesta. Si ejecutas bases de datos en un dataset con un recordsize enorme, ya estás haciendo churn de read-modify-write. Añade escrituras síncronas y de repente todo el mundo piensa “el cifrado lo hizo”. No—tu estrategia de bloques lo hizo.

3) Escrituras síncronas y la historia del ZIL/SLOG

ZFS respeta la semántica síncrona. Si tu carga emite escrituras síncronas (bases de datos, NFS, algunos patrones de almacenamiento de VM), la latencia está dominada por la ruta del log. El overhead del cifrado en la ruta de datos principal se vuelve secundario si tu SLOG es lento, está mal configurado o no existe.

4) Carga de claves y orquestación de montaje

Este es el que muerde a los equipos de operaciones: un dataset cifrado que no está cargado no se monta. Si tu orden de arranque, servicios o reglas de automount asumen que el dataset siempre está ahí, puedes convertir un reinicio simple en un outage. La gráfica de rendimiento puede estar bien; tu gráfica de disponibilidad no lo estará.

Chiste #2: Lo bueno del cifrado es que hace tus datos ilegibles para atacantes; lo menos agradable es que también puede hacerlos ilegibles para ti si tratas las claves como “problema del yo del futuro”.

Diseñar datasets cifrados sin arrepentimientos

Los despliegues de cifrado ZFS más inteligentes que he visto comparten un patrón: no cifran “el pool”. Cifran dominios de datos.

Cifra en límites de dataset que mapeen a límites de confianza

Ejemplos de buenos límites:

Datasets por aplicación: pool/app1, pool/app2
Datasets por tenant en almacenamiento multi-inquilino
Dataset separado para backups/réplicas (a menudo con manejo de claves distinto)
Dataset de “archivos fríos” con propiedades de rendimiento distintas

Por qué importa: puedes rotar claves, replicar, snapshotear y aplicar cuotas por límite. Y puedes mantener espacio de scratch de alta rotación sin cifrar si tu modelo de riesgo lo permite, ahorrando ciclos donde importan.

Elige las propiedades de cifrado intencionalmente

El cifrado de OpenZFS se configura al crear el dataset y se hereda. Lo importante:

encryption: algoritmo/modo (comúnmente aes-256-gcm)
keyformat: passphrase o raw
keylocation: dónde obtener la clave (prompt, archivo, etc.)

En producción, la decisión real no es “AES-256 vs AES-128”. Es: ¿quieres una passphrase humana (buena para desbloqueo manual, arriesgada para automatización) o una clave raw en archivo (buena para automatización, requiere seguridad fuerte del SO y distribución de secretos)?

La compresión es tu amiga, no tu enemiga

Si vas a cifrar, casi siempre deberías habilitar compresión (comúnmente lz4). Reduce I/O en disco, reduce ancho de banda de replicación y a menudo mejora el rendimiento de extremo a extremo. La compresión ahorra más tiempo que lo que cuesta el cifrado en muchas cargas. La única vez que regularmente desactivo compresión es cuando sé que los datos ya están comprimidos y la CPU es realmente el cuello de botella—y eso es más raro de lo que la gente asume.

No confundas cifrado con checksums e integridad

Los checksums de ZFS detectan corrupción; el cifrado evita lectura no autorizada. Con AES-GCM también obtienes autenticación, lo que ayuda a detectar manipulación. Pero los checksums de ZFS siguen haciendo trabajo real, especialmente frente a hardware, controladores o RAM defectuosos. No desactives checksums (y no lo intentes; ZFS no te lo permitirá como podrías esperar).

Gestión de claves que funcione a las 3 a.m.

El éxito operativo del cifrado ZFS es, en gran parte, el éxito del ciclo de vida de tus claves. Esto es lo que realmente funciona en producción:

Prefiere un número pequeño de “clases” de claves

Demasiadas claves únicas convierten cada restauración en una búsqueda del tesoro. Muy pocas claves aumentan el radio de blast. Un término medio práctico:

Una clave por frontera de aplicación o tenant
Una clave separada para backups/targets de replicación
Una clave separada para datasets de “infraestructura compartida” (logs, configs) si contienen secretos

Decide cómo ocurre el desbloqueo

Patrones comunes:

Desbloqueo manual después del arranque para datasets sensibles (el operador introduce la passphrase). Genial para el modelo “servidor robado”; recuperación más lenta.
Desbloqueo automatizado vía archivo de clave almacenado en el host (protegido por seguridad del SO, TPM o acceso restringido). Recuperación más rápida; aumenta el riesgo si el host se compromete.
Desbloqueo dividido: datasets de infraestructura se desbloquean automáticamente; datasets joya requieren desbloqueo manual.

Los outages más dolorosos que he visto no fueron causados por overhead del cifrado—fueron causados por un reinicio donde el sistema arrancó “bien”, excepto que los datasets no se montaron porque nadie pensó en la carga de claves en el grafo de servicios.

Tareas prácticas (comandos + interpretación)

Las siguientes tareas asumen OpenZFS en Linux con herramientas estándar. Adapta rutas y manejo de servicios a tu entorno. Los comandos se muestran como una sesión de shell real; las salidas son representativas.

Tarea 1: Comprobar qué está cifrado y qué no

cr0x@server:~$ zfs list -o name,encryption,keylocation,keystatus,mounted -r tank
NAME                 ENCRYPTION        KEYLOCATION         KEYSTATUS  MOUNTED
tank                 off               none                -          yes
tank/apps             aes-256-gcm      file:///etc/zfs/keys/apps.key  available yes
tank/apps/db          aes-256-gcm      inherit             available yes
tank/backups          aes-256-gcm      prompt              unavailable no

Interpretación: tank/apps está cifrado y usa un archivo de clave; los hijos heredan. tank/backups necesita desbloqueo interactivo y actualmente no está disponible, así que no está montado.

Tarea 2: Crear un dataset cifrado con valores por defecto sensatos

cr0x@server:~$ sudo install -d -m 0700 /etc/zfs/keys
cr0x@server:~$ sudo dd if=/dev/urandom of=/etc/zfs/keys/app1.key bs=32 count=1 status=none
cr0x@server:~$ sudo chmod 0400 /etc/zfs/keys/app1.key

cr0x@server:~$ sudo zfs create \
  -o encryption=aes-256-gcm \
  -o keyformat=raw \
  -o keylocation=file:///etc/zfs/keys/app1.key \
  -o compression=lz4 \
  -o atime=off \
  tank/app1

Interpretación: Clave raw + archivo de clave es amigable para la automatización. compression=lz4 y atime=off son valores por defecto comunes en producción para muchas cargas.

Tarea 3: Crear un dataset hijo para una base de datos con recordsize afinado

cr0x@server:~$ sudo zfs create -o recordsize=16K -o logbias=latency tank/app1/pgdata
cr0x@server:~$ zfs get -o name,property,value encryption,recordsize,logbias tank/app1/pgdata
NAME              PROPERTY    VALUE
tank/app1/pgdata  encryption  aes-256-gcm
tank/app1/pgdata  recordsize  16K
tank/app1/pgdata  logbias     latency

Interpretación: El hijo hereda el cifrado, pero afinaste recordsize para una carga estilo base de datos y le dijiste a ZFS que optimice para latencia síncrona.

Tarea 4: Cargar una clave y montar un dataset cifrado

cr0x@server:~$ sudo zfs load-key tank/backups
Enter passphrase for 'tank/backups': 
cr0x@server:~$ sudo zfs mount tank/backups
cr0x@server:~$ zfs get -o name,property,value keystatus,mounted tank/backups
NAME         PROPERTY  VALUE
tank/backups keystatus available
tank/backups mounted   yes

Interpretación: Clave cargada, dataset ahora montable. Si olvidas el paso de mount, te quedarás mirando un directorio vacío y culparás al universo.

Tarea 5: Descargar una clave (y lo que realmente hace)

cr0x@server:~$ sudo zfs unmount tank/backups
cr0x@server:~$ sudo zfs unload-key tank/backups
cr0x@server:~$ zfs get -o name,property,value keystatus,mounted tank/backups
NAME         PROPERTY  VALUE
tank/backups keystatus unavailable
tank/backups mounted   no

Interpretación: Descargar la clave hace que el dataset sea inaccesible hasta que se vuelva a cargar. No “re-encripta” bloques existentes—ya están cifrados en reposo.

Tarea 6: Confirmar que la replicación puede permanecer cifrada de extremo a extremo

cr0x@server:~$ sudo zfs snapshot -r tank/app1@replica-test
cr0x@server:~$ zfs get -H -o value encryption tank/app1
aes-256-gcm

Interpretación: Se toma el snapshot. Si puedes enviar un stream cifrado en crudo depende del soporte de features en ambos extremos; debes validar en tu entorno, no asumir.

Tarea 7: Estimar impacto en compresión y throughput escrito

cr0x@server:~$ zfs get -o name,property,value compressratio,logicalused,used -r tank/app1
NAME           PROPERTY      VALUE
tank/app1      compressratio 1.62x
tank/app1      logicalused   48.3G
tank/app1      used          29.8G
tank/app1/pgdata compressratio 1.08x
tank/app1/pgdata logicalused 310G
tank/app1/pgdata used        287G

Interpretación: Los datos de la app se comprimen bien; la base de datos menos. Esto importa porque los ahorros de compresión a menudo compensan el overhead del cifrado reduciendo I/O físico.

Tarea 8: Comprobar si estás limitado por CPU o por I/O durante una carga

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server)  12/25/2025  _x86_64_  (16 CPU)

12:01:10 PM  CPU  %usr %nice %sys %iowait %steal %idle
12:01:11 PM  all  22.1  0.0   7.4    0.6    0.0  69.9
12:01:12 PM  all  78.5  0.0  12.0    0.3    0.0   9.2

Interpretación: Si las CPUs están a tope con bajo iowait, estás limitado por cómputo (podría ser cifrado, compresión, checksums, RAIDZ o la propia aplicación). Si iowait sube, el camino de almacenamiento es lento.

Tarea 9: Observar el comportamiento de I/O de ZFS en vivo

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.21T  6.78T  1.25K  2.10K   210M  355M
  raidz2    3.21T  6.78T  1.25K  2.10K   210M  355M
    sda         -      -    150    260  26.0M  44.3M
    sdb         -      -    155    265  26.5M  45.0M
    ...

Interpretación: Esto te dice si el pool está ocupado y si el ancho de banda/IOPS coincide con las expectativas. Si el cifrado “te ralentizó”, deberías ver si estás saturando los discos, no adivinar.

Tarea 10: Verificar flags de features y compatibilidad (chequeo de replicación)

cr0x@server:~$ zpool get all tank | egrep 'feature@|ashift'
tank  ashift                      12                     local
tank  feature@encryption          active                 local
tank  feature@edonr               active                 local

Interpretación: Necesitas features compatibles entre sender/receiver para replicación limpia. Si el receptor no soporta cifrado, tu plan cambia (o falla).

Tarea 11: Confirmar la herencia de claves del dataset y evitar sorpresas

cr0x@server:~$ zfs get -r -o name,property,value,keylocation,encryption keylocation,encryption tank/app1
NAME            PROPERTY    VALUE          SOURCE
tank/app1       encryption  aes-256-gcm    local
tank/app1       keylocation file:///etc/zfs/keys/app1.key local
tank/app1/pgdata encryption aes-256-gcm    inherited from tank/app1
tank/app1/pgdata keylocation file:///etc/zfs/keys/app1.key inherited from tank/app1

Interpretación: La herencia es tu amiga—hasta que no lo es. Confirma siempre qué están haciendo realmente los hijos antes de rotar claves o cambiar ubicaciones.

Tarea 12: Rotar una clave de cifrado (versión operativamente segura)

Aquí es donde los equipos se ponen nerviosos, y con razón. Debes programar, snapshotear y validar.

cr0x@server:~$ sudo dd if=/dev/urandom of=/etc/zfs/keys/app1-new.key bs=32 count=1 status=none
cr0x@server:~$ sudo chmod 0400 /etc/zfs/keys/app1-new.key

cr0x@server:~$ sudo zfs snapshot -r tank/app1@before-key-rotate
cr0x@server:~$ sudo zfs change-key -o keylocation=file:///etc/zfs/keys/app1-new.key tank/app1
cr0x@server:~$ zfs get -o name,property,value keylocation tank/app1
NAME      PROPERTY     VALUE
tank/app1 keylocation  file:///etc/zfs/keys/app1-new.key

Interpretación: Cambiaste la ubicación y el material de la clave de wrapping del dataset. El snapshot es tu ancla de rollback. No borres la clave vieja hasta haber probado reboot, replicación y rutas de restauración.

Tarea 13: Medir el impacto del cifrado con una prueba controlada de escritura

cr0x@server:~$ sudo zfs create -o encryption=off -o compression=off tank/test-plain
cr0x@server:~$ sudo zfs create -o encryption=aes-256-gcm -o keyformat=raw -o keylocation=file:///etc/zfs/keys/app1.key -o compression=off tank/test-enc

cr0x@server:~$ sync
cr0x@server:~$ dd if=/dev/zero of=/tank/test-plain/blob bs=1M count=4096 oflag=direct status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 4.8 s, 895 MB/s

cr0x@server:~$ dd if=/dev/zero of=/tank/test-enc/blob bs=1M count=4096 oflag=direct status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 5.1 s, 842 MB/s

Interpretación: Es un instrumento contundente, pero te da una sensación del orden de magnitud. Si la diferencia es enorme, probablemente estés limitado por CPU o cambiaste accidentalmente más de una variable (compresión, sync, recordsize, etc.).

Tarea 14: Confirmar que la clave no sea accidentalmente legible por todos

cr0x@server:~$ ls -l /etc/zfs/keys/app1.key
-r-------- 1 root root 32 Dec 25 11:58 /etc/zfs/keys/app1.key

Interpretación: Si ese archivo es legible por usuarios no root, has convertido “cifrado en reposo” en “cifrado con snacks”. Ciérralo.

Tres micro-historias del mundo corporativo

Micro-historia #1: El incidente causado por una suposición errónea

Cifraron los datasets en el host de almacenamiento primario y se fueron a casa sintiéndose responsables. La ventana de cambio fue limpia; la app siguió funcionando; el rendimiento parecía básicamente sin cambios. La suposición del equipo fue simple: “Si el dataset existe, systemd lo montará como antes”.

Entonces vino una actualización rutinaria del kernel. Reinicio. El host volvió, la monitorización mostró el OS up, SSH funcionó y la carga media estaba sospechosamente tranquila. Pero la aplicación estaba caída. El punto de montaje existía, vacío y alegre, y la app creó obedientemente una nueva jerarquía de directorios en el filesystem raíz. Fue uno de esos fallos que no parecen fallos hasta que notas que tu base de datos tiene de repente 200 MB y es completamente nueva.

La causa raíz no fue ZFS siendo “truco”. Fue el grafo de servicios. El dataset cifrado requería zfs load-key antes de montar; la clave estaba configurada para prompt, y nadie estaba para teclearla. El sistema arrancó “con éxito”, simplemente sin los datos. La app no falló rápido porque el punto de montaje existía. Escribió en el lugar equivocado y empeoró la recuperación.

La solución fue aburrida y eficaz: hicieron que el montaje del dataset fuera una dependencia dura, añadieron una comprobación en el arranque que se negaba a iniciar la app a menos que el dataset estuviera montado, y cambiaron el manejo de claves para ese dataset para que debidamente reflejara la realidad (o desbloqueo manual con un paso explícito en on-call, o desbloqueo automatizado con controles fuertes en el host). También añadieron una barrera: un archivo pequeño almacenado en el dataset que la app comprueba al inicio. Si no está presente, se niega a arrancar.

La lección: el cifrado rara vez rompe el rendimiento primero. Rompe las suposiciones primero.

Micro-historia #2: La optimización que salió mal

Un equipo decidió “optimizar” el overhead del cifrado apagando la compresión—en la teoría de que la compresión quema CPU y el cifrado quema CPU, así que quitar la compresión ahorraría ciclos. Sonaba bonito en una diapositiva.

En realidad, la compresión llevaba su carga. Almacenaban muchos logs textuales, JSON y imágenes VM con grandes regiones zeradas. Con la compresión apagada, sus escrituras físicas aumentaron drásticamente, lo que empujó al pool a latencias sostenidas altas. Las ventanas de replicación crecieron. El target de backup empezó a quedarse atrás. De repente estaban haciendo planificación de capacidad de emergencia porque “el cifrado hizo todo más grande”. No lo había hecho—apagar la compresión lo había hecho.

Luego el contragolpe fue peor: el equipo intentó compensar aumentando recordsize por doquier para “reducir overhead”. Eso ayudó a escrituras secuenciales grandes, pero castigó actualizaciones aleatorias y churn de metadatos. Unos cuantos servicios que ya eran sensibles a la latencia de cola (una pequeña base OLTP y una cola) empezaron a hacer timeout bajo carga. La revisión del incidente fue brutal, sobre todo porque el cambio se hizo bajo la bandera de “seguridad”, así que nadie quiso cuestionarlo hasta que producción lo hizo.

La recuperación fue clásica: volvieron a compression=lz4, afinaron recordsize por dataset y dejaron de tratar el “overhead de CPU” como un cubo único. El cifrado no era el villano; la afinación sin medidas lo era.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Esta es menos dramática, que es justo el punto. Un sistema adyacente a finanzas (datos sensibles, escrutinio regulatorio, la diversión habitual) tenía cifrado nativo ZFS con datasets por aplicación. La práctica del equipo era agresivamente aburrida: cada rotación de claves tenía un runbook, cada dataset tenía un método de desbloqueo documentado y trimestralmente probaban una restauración bare-metal en un entorno aislado.

Una tarde un shelf de almacenamiento sufrió una fallo de controlador que requirió enviar piezas y mover cargas temporalmente. El equipo decidió conmutar a un host en standby. El standby tenía snapshots replicados, pero nunca se había usado en serio. Ahí es donde la mayoría de planes de DR mueren.

La conmutación funcionó—no porque ZFS sea mágico, sino porque el equipo había ensayado el manejo de claves. Cargaron claves en el orden correcto, confirmaron montajes, validaron que el stream de replicación permaneciera cifrado y levantaron servicios solo después de confirmar los datasets. No descubrieron archivos de claves faltantes, propiedades desajustadas o misteriosos problemas de orden de montaje. Todos esos problemas se habían arreglado meses antes durante una aburrida prueba trimestral que nadie quería atender.

Cuando llegó el informe post-incidente, fue casi decepcionante: sin heroicidades, sin hacks de medianoche, sin “copiamos claves de una captura de pantalla”. Solo una lista de verificación, ejecutada. En mi experiencia, ese es el mayor cumplido que puedes darle a un sistema de almacenamiento cifrado: que falle como si no estuviera cifrado en absoluto.

Guion rápido de diagnóstico

Esta es la secuencia que uso cuando alguien dice, “Después de habilitar el cifrado ZFS, el rendimiento es malo.” El objetivo es encontrar la restricción dominante rápido, no debatir cripto por principios.

Primero: confirma qué cambió (eaisla variables)

Verifica el estado de cifrado y las propiedades en los dataset afectados: algoritmo, compresión, recordsize, sync, logbias.
Confirma que las claves están cargadas y los datasets montados (problemas de disponibilidad frecuentemente se hacen pasar por “rendimiento”).
Revisa si la carga también cambió: nueva versión de la app, patrón I/O distinto, horario de replicación diferente.

cr0x@server:~$ zfs get -o name,property,value -r encryption,compression,recordsize,sync,logbias tank/app1
NAME              PROPERTY     VALUE
tank/app1          encryption   aes-256-gcm
tank/app1          compression  lz4
tank/app1          recordsize   128K
tank/app1          sync         standard
tank/app1          logbias      latency
tank/app1/pgdata   encryption   aes-256-gcm
tank/app1/pgdata   compression  lz4
tank/app1/pgdata   recordsize   16K
tank/app1/pgdata   sync         standard
tank/app1/pgdata   logbias      latency

Segundo: decide si es CPU-bound o I/O-bound

Mira la utilización de CPU y el iowait durante la degradación.
Si la CPU está alta y el iowait bajo: estás limitado por cómputo (el cifrado puede contribuir, pero también lo pueden hacer compresión/checksums/RAIDZ/app).
Si iowait está alto: la latencia de almacenamiento es el cuello de botella; revisa SLOG, salud de vdevs, fragmentación, profundidad de colas y la carga síncrona.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 821220  88048 7340120   0    0   512  1024  980 2200 22  8 69  1  0
 9  2      0 780112  88120 7310040   0    0  4096  8192 1400 3400 55 15 10 20  0

Tercero: revisa el comportamiento del pool ZFS y pistas de latencia

zpool iostat -v para ver si los discos están saturados o desparejos.
zpool status para descartar resilvers, errores de checksum o vdevs degradados.
Si es heavy en sync: valida el SLOG y sus características de latencia.

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Cuarto: valida la ruta de la carga (sync, escrituras pequeñas, tormentas de metadatos)

Si la app está haciendo escrituras síncronas y no tienes un SLOG real (o es lento), ese es tu primer sospechoso. Si la app es heavy en metadatos (millones de archivos pequeños), el cifrado puede aumentar la presión de CPU, pero el problema mayor suele ser la ruta de IOPS, no el cifrado en sí.

Errores comunes, síntomas, correcciones

Error 1: Cifrar “todo” sin límites de dataset

Síntoma: La rotación de claves se vuelve aterradora; la replicación y restauración son frágiles; el troubleshooting es “¿qué clave desbloquea qué?”

Corrección: Refactoriza en datasets por aplicación/tenant. Usa herencia para reducir la deriva de configuración. Documenta qué datasets comparten claves y por qué.

Error 2: Suponer que los datasets cifrados se montan automáticamente después del reinicio

Síntoma: Tras un reinicio, los servicios arrancan pero las rutas de datos están vacías; las aplicaciones crean datos nuevos en el filesystem raíz; comportamiento tipo “instalación fresca”.

Corrección: Asegura que las claves se carguen en el arranque (o requiere desbloqueo manual explícito), y haz que los servicios dependan de los montajes. Añade archivos de guardia/comprobaciones para que las apps fallen rápido si el dataset real no está montado.

Error 3: Apagar la compresión para “ahorrar CPU para el cifrado”

Síntoma: Spike en ancho de banda del pool, subida de latencia, ventanas de replicación más largas, aceleración del consumo de capacidad.

Corrección: Re-habilita compression=lz4 y mide. Si la CPU es realmente el cuello de botella, escala CPU o afina la carga; no cambies amplificación de I/O por una ganancia teórica de CPU.

Error 4: Tratar recordsize como una perilla universal

Síntoma: Bases de datos hacen timeout tras la “optimización”, o el almacenamiento de VM se vuelve inestable; aumenta la amplificación de escritura.

Corrección: Ajusta recordsize por dataset según la carga. Mantén recordsize grande para datos secuenciales; reduce para cargas de actualización aleatoria.

Error 5: Usar passphrases para servidores sin atención sin un plan

Síntoma: Reinicio requiere acceso a consola; la conmutación DR se atora; on-call atrapado buscando a la única persona que “sabe la passphrase”.

Corrección: O comprométete con desbloqueo manual con procedimientos y personal explícito, o usa claves raw con distribución controlada y protecciones estrictas en el SO. El híbrido es común: auto-unlock para datasets no críticos, unlock manual para las joyas de la corona.

Error 6: Malentender la semántica de replicación con cifrado

Síntoma: Jobs de replicación fallan, o los datos aterrizan descifrados en el receptor, o las restauraciones requieren claves que no preservaste.

Corrección: Prueba modos send/receive en un laboratorio que coincida con las versiones y features de producción. Confirma propiedades del receptor y disponibilidad de claves. Ten un proceso de custodia de claves que cumpla con compliance.

Error 7: Dejar archivos de claves legibles o respaldados casualmente

Síntoma: Hallazgos de auditoría, o peor: backups “cifrados” que se pueden descifrar porque las claves están en el mismo backup.

Corrección: Haz cumplir permisos, aisla el almacenamiento de claves y decide explícitamente si las claves se respaldan y dónde. Si las claves se respaldan, protege ese backup como si fuera los datos—porque lo es.

Listas de verificación / plan paso a paso

Checklist A: Desplegar cifrado ZFS de forma segura (greenfield o retrofit)

Define el modelo de amenazas: discos robados, hosts robados, compromiso del dominio de backups, etc.
Elige límites de dataset: por app/tenant, backups separados, archivos fríos separados.
Escoge estrategia de claves: archivos de clave raw para automatización vs passphrases para desbloqueo manual; decide por clase de dataset.
Establece propiedades base: compression=lz4, atime=off, recordsize por carga, sync/logbias según necesidad.
Crea datasets y migra datos con un plan reversible (snapshots antes y después).
Actualiza orden de arranque y servicios: cargar claves, luego montar, luego servicios. Añade guardias de montaje.
Prueba replicación: tanto workflows rutinarios como restauraciones, incluyendo disponibilidad de claves en DR.
Prueba de carga: tests controlados más canario con carga real.
Documenta y ensaya: rotación de claves y restauración deben practicarse, no solo escribirse.

Checklist B: Secuencia de afinado de rendimiento (no afines a ciegas)

Mide si estás CPU-bound vs I/O-bound durante el periodo lento (mpstat/vmstat + zpool iostat).
Confirma que la compresión está habilitada a menos que tengas pruebas de que perjudica.
Valida que recordsize coincida con el patrón de la carga.
Revisa la ruta de escrituras síncronas y la idoneidad del SLOG si aplica.
Confirma salud del pool y descarta operaciones de fondo (resilver/scrub).
Solo entonces considera el “overhead de cifrado” como causa primaria—y si lo haces, valida las capacidades de CPU y las restricciones de virtualización.

Checklist C: Ejercicio de rotación de claves (la versión que no arruina tu fin de semana)

Snapshot de los datasets relevantes (@before-key-rotate).
Genera y da permisos al nuevo material de clave.
Cambia la clave en un dataset no crítico primero (canario), luego procede.
Reinicia un host standby o prueba el flujo de mount/unlock para asegurar que la automatización funciona.
Valida replicación y restauración con la nueva clave.
Retira las claves antiguas solo después de poder probar la restauración de snapshots que aún dependan de ellas (si aplica a tu workflow).

FAQ

1) ¿El cifrado nativo de ZFS es “cifrado de disco completo”?

No. Es cifrado a nivel de dataset. Algunos metadatos a nivel de pool permanecen visibles. Si necesitas “todo, incluyendo swap y arranque, está cifrado”, puede que combines estrategias (por ejemplo, cifrado a nivel OS para la raíz y cifrado de datasets ZFS para datos).

2) ¿Debería usar cifrado ZFS o LUKS?

Resuelven problemas operativos distintos. LUKS cifra dispositivos de bloque (límite simple, amplio soporte OS). El cifrado nativo de ZFS cifra datasets (límites granulares, consciente de snapshots/replicación). Si necesitas claves por dataset y semántica de replicación cifrada, el cifrado nativo de ZFS es la herramienta. Si necesitas un modelo “desbloquea el disco” único, LUKS puede ser más simple.

3) ¿El cifrado rompe la compresión?

No—ZFS comprime antes de cifrar. La compresión sigue siendo efectiva y a menudo marca la diferencia entre “el cifrado está bien” y “¿por qué nos quedamos sin IOPS?”.

4) ¿El cifrado ralentizará mi base de datos?

Pueda que sí, pero con frecuencia los factores mayores son la latencia de escrituras síncronas, desajuste de recordsize y diseño del pool. Si ya vas cerca del límite de CPU, el cifrado puede empujarte encima. Mide CPU vs iowait y afina propiedades del dataset para la carga de la base de datos.

5) ¿Puedo replicar datasets cifrados sin exponer texto plano al servidor de backup?

En muchos setups OpenZFS, sí—existen workflows de send/receive en crudo cifrados donde el receptor almacena bloques cifrados sin necesitar claves. Debes validar el soporte de features y probar restauraciones. No asumas que tus versiones sender/receptor se comportan idénticamente.

6) ¿Qué pasa si pierdo la clave?

Pierdes los datos. No hay “puerta trasera”. Ese es el punto y el riesgo. Si tu negocio no puede tolerarlo, necesitas una estrategia de custodia de claves con controles fuertes y pruebas periódicas de restauración.

7) ¿Deben las claves vivir en el mismo host que los datos?

A veces sí—especialmente para sistemas que deben reiniciarse sin atención. Pero estás intercambiando protección contra “discos robados” por riesgo de “host comprometido”. Si un host se compromete y el archivo de clave es accesible, el atacante puede leer los datos. Usa hardening del host, permisos restringidos y considera desbloqueo manual para los datasets más sensibles.

8) ¿Puedo cifrar un dataset existente in-place?

No como un simple cambio de propiedad. En la práctica, los equipos crean un nuevo dataset cifrado y migran datos (a menudo con snapshots y sends incrementales). Planifica un flujo de migración y prueba rollback.

9) ¿El cifrado afecta scrubs y resilvers?

Los scrubs y resilvers aún leen y verifican datos; el cifrado añade trabajo de CPU para descifrar/autenticar donde aplique. En muchos sistemas, el throughput de disco sigue siendo el limitador, pero en hosts limitados por CPU puedes ver ventanas de mantenimiento más largas.

10) ¿Cuál es la mejor forma de evitar incidentes “el cifrado mató el rendimiento”?

No cambies una perilla a la vez. Cambia una variable a la vez, mantén compression=lz4 por defecto, afina recordsize por carga y usa el guion rápido de diagnóstico para probar si estás CPU-bound o I/O-bound.

Conclusión

El cifrado nativo de ZFS es una de esas raras características de seguridad que se puede desplegar de forma pragmática: por dataset, con rendimiento predecible y con semántica de replicación que realmente respeta cómo se usa el almacenamiento en empresas reales. La trampa es que mueve el riesgo de “datos en discos” a “claves y operaciones”. Eso no es un fallo—es todo el juego.

Si quieres seguridad fuerte sin matar el rendimiento, trata el cifrado como parte del diseño del sistema: alinea límites de dataset con límites de confianza, mantén la compresión activada salvo prueba en contrario, afina recordsize por carga y haz que la carga de claves y el montaje sean una parte de primera clase del arranque y DR. Si haces eso, el cifrado se convierte en la parte menos interesante de la pila de almacenamiento—que es exactamente donde lo quieres.