Una de las muchas características que trae OpenZFS 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 en el propio ZFS. Esto evita la necesidad de herramientas independientes como LUJO, VeraCrypt, o entonces Bitlocker.

El algoritmo de cifrado de OpenZFS está predeterminado en aes-256-ccm (antes de 0.8.4) o aes-256-gcm (> = 0.8.4) cuando encryption=on Está establecido. 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, el cifrado nativo de OpenZFS no se limita a los algoritmos utilizados. Por lo tanto, intentaremos brindarle una base breve pero sólida desde el punto de vista de un administrador del sistema 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 sistema inteligente que quiera proporcionar cifrado en reposo, obviamente, no necesita cifrado OpenZFS nativo. Como se mencionó en la introducción, LUKS, VeraCrypt, y hay muchos otros esquemas disponibles que pueden colocarse debajo o encima del propio OpenZFS.

Primero el «por qué no»

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

Pero hay importantes inconvenientes que se deben poner LUKS (o similar) en OpenZFS. Uno de los más molestos es que cada individual el disco que formará parte del grupo debe estar cifrado, cada volumen se debe cargar y descifrar antes del grupo ZFS import paso. Esto puede ser un desafío notable para los sistemas ZFS con muchos discos; en algunos casos, muchos decenas discos. Otro problema con el cifrado en ZFS es que la capa adicional es una cosa más que puede salir mal, y puede anular todas las garantías de integridad normales de ZFS.

Poniendo LUKS o similar en OpenZFS elimina los problemas mencionados anteriormente: un LUKS cripta zvol solo necesita una clave independientemente del número de discos involucrados, y el LUKS La capa no puede anular las garantías de integridad de OpenZFS desde aquí. Desafortunadamente, el cifrado en ZFS presenta un nuevo problema: debilita efectivamente la compresión en línea de OpenZFS, porque los datos cifrados generalmente son incompresibles. Este enfoque también necesita el uso de un zvol por sistema de archivos cifrado, así como un sistema de archivos invitado (por ejemplo, ext4) para formatear el LUKS volumen mismo con.

Ahora el «por qué»

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

Sin embargo, existe una razón aún más convincente para elegir el cifrado OpenZFS nativo, que se denomina «carga sin procesar». La replicación ZFS es ridículamente rápida y eficiente, a menudo varios órdenes de magnitud más rápida que las herramientas independientes del sistema de archivos como rsync– y el envío sin procesar no solo permite replicar cifrado datasetla arena zvols, pero hacerlo sin exponer la llave al sistema remoto.

Esto significa que puede utilizar la replicación ZFS para realizar una copia de seguridad de sus datos en un no hay confianza ubicación, sin preocuparse por leer sus datos privados. Con el envío sin procesar, sus datos se replican sin nunca ser descifrados y sin que el objetivo de la copia de seguridad pueda descifrarlos. Esto significa que puede replicar sus copias de seguridad fuera del sitio en la casa de un amigo o en un departamento de ventas como rsync.net o entonces zfs.rent sin comprometer su privacidad, incluso si el servicio (o amigo) en sí está comprometido.

En caso de que necesite recuperar su copia de seguridad externa, simplemente puede replicarla. espalda en su propia ubicación, entonces, y Sólo luego cargue la clave de descifrado para acceder realmente a los datos. Esto funciona para la replicación completa (moviendo cada bloque en el cable) o la replicación incremental asincrónica (comenzando desde una instantánea común y moviendo solo 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 habilitar para grupos completos como un todo. El contenido de los conjuntos de datos cifrados o zvols están protegidos contra la indagación 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 llamado pool/encryptedy, a continuación, creamos varios conjuntos de datos secundarios más. la encryption La 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  -

Por ahora, todos nuestros conjuntos de datos cifrados están reunidos. Pero incluso si los desmontamos y descargamos la clave de cifrado, haciéndolos inaccesibles, todavía podemos ver que existir, así como 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

Como podemos ver arriba, después de descargar la clave de cifrado, ya no podemos ver nuestra copia recién descargada de Finn arándano dentro /banshee/encrypted/child2/. Lo que lata todavía vemos la existencia – y estructura – de todo nuestro árbol encriptado ZFS. También podemos ver las propiedades de cada conjunto de datos cifrados, incluidos, entre otros, los USED, AVAIL, y REFER de cada conjunto de datos.

Cabe señalar que intentar ls un conjunto de datos cifrado cuya clave no está cargada no necesariamente producirá un error:

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

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 carga automáticamente el conjunto de datos:

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

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

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

Ahora que ambos hemos cargado la clave necesaria y montado los conjuntos de datos, podemos revisar nuestros datos cifrados.