Una guía de inicio rápido para el cifrado nativo OpenZFS

Aprenda el cómo, el por qué y el qué del cifrado OpenZFS con esta breve guía.

Una de las muchas características que OpenZFS trae a la mesa es el cifrado nativo ZFS. Introducido por primera vez en OpenZFS 0.8, el cifrado nativo permite al administrador del sistema cifrar de forma transparente los datos en reposo dentro del propio ZFS. Esto evita la necesidad de herramientas independientes como LUKS , VeraCrypt o BitLocker .

El algoritmo de cifrado de OpenZFS se establece de forma predeterminada en aes-256-ccm (antes de 0.8.4) o aes-256-gcm (> = 0.8.4) cuando encryption=on está configurado. Pero también se puede especificar directamente. Los algoritmos admitidos actualmente son:

• aes-128-ccm
• aes-192-ccm
• aes-256-ccm (predeterminado en OpenZFS <0.8.4)
• aes-128-gcm
• aes-192-gcm
• aes-256-gcm (predeterminado en OpenZFS> = 0.8.4)

Sin embargo, hay más en el cifrado nativo de OpenZFS que los algoritmos utilizados, por lo que intentaremos brindarle una base breve pero sólida en la perspectiva del administrador de sistemas sobre el «por qué» y el «qué», así como el simple «cómo».

¿Por qué (o por qué no) el cifrado nativo OpenZFS?

Un administrador de sistemas inteligente que quiera proporcionar cifrado en reposo no necesita en realidad cifrado nativo OpenZFS, obviamente. Como se mencionó en la introducción, LUKS, VeraCrypt, y muchos otros esquemas están disponibles y se pueden superponer ya sea por debajo o encima de sí mismo OpenZFS.

Primero, el «por qué no»

Poner algo como Linux LUKS debajo de OpenZFS tiene una ventaja: con  todo el disco cifrado, un atacante emprendedor ya no puede ver los nombres, tamaños o propiedades de ZFS datasets y zvols sin acceso a la clave. De hecho, el atacante no puede ver necesariamente que ZFS está en uso.

Pero hay desventajas significativas al poner LUKS (o similar) debajo de OpenZFS. Uno de los más complicados es que cada  disco individual que formará parte del grupo debe estar cifrado, con cada volumen cargado y descifrado antes de la import etapa del grupo ZFS . Esto puede ser un desafío notable para los sistemas ZFS con muchos discos; en algunos casos, muchas  decenas de discos. Otro problema con el cifrado por debajo de ZFS es que la capa adicional es algo adicional que puede fallar y está en condiciones de deshacer todas las garantías de integridad normales de ZFS.

Poner LUKS o algo similar encima de OpenZFS elimina los problemas mencionados anteriormente: un LUKS cifrado zvol solo necesita una clave independientemente de cuántos discos estén involucrados, y la LUKS capa no puede deshacer las garantías de integridad de OpenZFS desde aquí. Desafortunadamente, el cifrado sobre ZFS presenta un nuevo problema: debilita efectivamente la compresión en línea de OpenZFS, ya que los datos cifrados generalmente son incompresibles. Este enfoque también  requiere el uso de uno  zvol por sistema de archivos cifrado, junto con un sistema de archivos invitado (por ejemplo,  ext4) para formatear el LUKS volumen.

Ahora, el «por qué»

El cifrado nativo de OpenZFS divide la diferencia: opera sobre las capas normales de almacenamiento de ZFS y, por lo tanto, no debilita las garantías de integridad de ZFS. Pero tampoco interfiere con la compresión ZFS: los datos se comprimen antes de guardarlos en un archivo cifrado dataset o zvol.

Sin embargo, existe una razón aún más convincente para elegir el cifrado nativo OpenZFS: algo llamado «envío sin procesar». La replicación de ZFS es ridículamente rápido y eficiente con frecuencia en varios órdenes de magnitud más rápido que las herramientas del sistema de archivos-neutral como rsync-y envío prima hace que sea posible no sólo para replicar cifrada datasets y zvols, pero para hacerlo sin exponer la clave para el sistema remoto.

Esto significa que puede utilizar la replicación ZFS para realizar una copia de seguridad de sus datos en una  ubicación que no sea de confianza , sin preocuparse por la lectura de sus datos privados. Con el envío sin procesar, sus datos se replican sin que se descifren nunca, y sin que el objetivo de la copia de seguridad pueda descifrarlos en absoluto. Esto significa que puede replicar sus copias de seguridad fuera de la casa de un amigo o en un servicio comercial como rsync.net  o zfs.rent  sin comprometer su privacidad, incluso si el servicio (o amigo) es en sí comprometidos.

En el caso de que necesite recuperar la copia de seguridad fuera del sitio, puede simplemente replicar que  volver a su propia ubicación, entonces, y solamente entonces, la carga de la clave de descifrado para realmente tener acceso a los datos. Esto funciona para la replicación completa (moviendo cada bloque a través del cable) o la replicación incremental asincrónica (comenzando desde una instantánea común y solo moviendo los bloques que han cambiado desde esa instantánea).

¿Qué está cifrado y qué no?

El cifrado nativo de OpenZFS no es un esquema de cifrado de disco completo; está habilitado o deshabilitado por conjunto de datos / por zvol, y no se puede activar para grupos completos en su totalidad. El contenido de los conjuntos de datos cifrados o zvols está protegido contra el espionaje en reposo, pero los metadatos que describen los conjuntos de datos / zvols en sí no lo están.

Digamos que creamos un conjunto de datos cifrado con nombre pool/encrypted, y debajo de él creamos varios conjuntos de datos secundarios más. La encryption propiedad de los hijos se hereda de forma predeterminada del conjunto de datos principal, por lo que podemos ver lo siguiente:

root@banshee:~# zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase banshee/encrypted
Enter passphrase: 
Re-enter passphrase: 

root@banshee:~# zfs create banshee/encrypted/child1
root@banshee:~# zfs create banshee/encrypted/child2
root@banshee:~# zfs create banshee/encrypted/child3

root@banshee:~# zfs list -r banshee/encrypted
NAME                       USED  AVAIL     REFER  MOUNTPOINT
banshee/encrypted         1.58M   848G      432K  /banshee/encrypted
banshee/encrypted/child1   320K   848G      320K  /banshee/encrypted/child1
banshee/encrypted/child2   320K   848G      320K  /banshee/encrypted/child2
banshee/encrypted/child3   320K   848G      320K  /banshee/encrypted/child3

root@banshee:~# zfs get encryption banshee/encrypted/child1
NAME                      PROPERTY    VALUE        SOURCE
banshee/encrypted/child1  encryption  aes-256-gcm  -

Seleccionar código

Por el momento, todos nuestros conjuntos de datos cifrados están montados. Pero incluso si los desmontamos y descargamos la clave de cifrado, lo que los hace inaccesibles, aún podemos ver que  existen , junto con sus propiedades:

root@banshee:~# wget -qO /banshee/encrypted/child2/HuckFinn.txt http://textfiles.com/etext/AUTHORS/TWAIN/huck_finn

root@banshee:~# zfs unmount banshee/encrypted
root@banshee:~# zfs unload-key -r banshee/encrypted
1 / 1 key(s) successfully unloaded

root@banshee:~# zfs mount banshee/encrypted
cannot mount 'banshee/encrypted': encryption key not loaded

root@banshee:~# ls /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

root@banshee:~# zfs list -r banshee/encrypted
NAME                       USED  AVAIL     REFER  MOUNTPOINT
banshee/encrypted         2.19M   848G      432K  /banshee/encrypted
banshee/encrypted/child1   320K   848G      320K  /banshee/encrypted/child1
banshee/encrypted/child2   944K   848G      720K  /banshee/encrypted/child2
banshee/encrypted/child3   320K   848G      320K  /banshee/encrypted/child3

Seleccionar código

Como podemos ver arriba, después de descargar la clave de cifrado, ya no podemos ver nuestra copia recién descargada de  Huckleberry Finn en formato/banshee/encrypted/child2/ . Lo que  aún podemos ver es la existencia y la estructura de todo nuestro árbol cifrado con ZFS. También podemos ver las propiedades de cada conjunto de datos cifrados, incluidos, entre otros USED, los AVAIL, y REFER de cada conjunto de datos.

Vale la pena señalar que intentar con ls un conjunto de datos cifrados que no tiene su clave cargada no producirá necesariamente un error:

root@banshee:~# zfs get keystatus banshee/encrypted
NAME               PROPERTY   VALUE        SOURCE
banshee/encrypted  keystatus  unavailable  -
root@banshee:~# ls /banshee/encrypted
root@banshee:~# 

Seleccionar código

Esto se debe a que existe un directorio simple en el host, incluso cuando el conjunto de datos real no está montado. Recargar la clave no vuelve a montar automáticamente el conjunto de datos, ya sea:

root@banshee:~# zfs load-key -r banshee/encrypted
Enter passphrase for 'banshee/encrypted': 
1 / 1 key(s) successfully loaded
root@banshee:~# zfs mount | grep encr
root@banshee:~# ls /banshee/encrypted
root@banshee:~# ls /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

Seleccionar código

Para acceder a nuestra nueva copia de  Huckleberry Finn , también necesitaremos montar los conjuntos de datos recién recargados de claves:

root@banshee:~# zfs get keystatus banshee/encrypted/child2
NAME                      PROPERTY   VALUE        SOURCE
banshee/encrypted/child2  keystatus  available    -

root@banshee:~# ls -l /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

root@banshee:~# zfs mount -a
root@banshee:~# ls -lh /banshee/encrypted/child2
total 401K
-rw-r--r-- 1 root root 554K Jun 13  2002 HuckFinn.txt

Seleccionar código

Ahora que hemos cargado la clave necesaria  y montado los conjuntos de datos, podemos volver a ver nuestros datos cifrados.