Una de las muchas características que ofrece OpenZFS es el cifrado ZFS nativo. 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 elimina la necesidad de herramientas separadas como LUX, VeraCrypt, o BitLocker.

El algoritmo de cifrado de OpenZFS tiene por defecto cualquier 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, hay más en la criptografía OpenZFS nativa que los algoritmos utilizados, por lo que intentaremos proporcionar una base breve pero sólida desde la perspectiva del 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 no necesita cifrado OpenZFS nativo, por supuesto. Como se mencionó en la introducción, LUKS, VeraCrypt, y muchos otros esquemas están disponibles y se pueden colocar debajo o encima del propio OpenZFS.

Primero, el «por qué no»

Poner algo como Linux LUKS bajo OpenZFS tiene una ventaja: con el entero 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 existen desventajas significativas al poner LUKS (o similar) debajo de OpenZFS. Uno de los más desagradables es que cada Individual El disco que formará parte del grupo debe estar cifrado, con cada volumen cargado y descifrado antes del grupo ZFS. import etapa. Esto puede ser un desafío notable para los sistemas ZFS con muchos discos; en algunos casos, muchos docenas de discos. Otro problema con el cifrado por debajo de ZFS es que la capa adicional es algo adicional que puede salir mal y puede deshacer todas las garantías normales de integridad de ZFS.

Poniendo LUKS o similar en OpenZFS elimina los problemas mencionados: un LUKS cifrado zvol todo lo que necesita es una clave, independientemente de cuántos discos estén involucrados, y el LUKS La capa no puede deshacer las garantías de integridad de OpenZFS desde aquí. Desafortunadamente, el cifrado sobre ZFS presenta un nuevo problema: derrota efectivamente la compresión incorporada de OpenZFS, ya que los datos cifrados a menudo son incompresibles. Este enfoque también requiere el uso de un zvol por sistema de archivos cifrado, junto con un sistema de archivos invitado (por ejemplo, ext4) para formatear el LUKS propio volumen con.

Ahora, el «por qué»

El cifrado nativo de OpenZFS divide la diferencia: opera sobre los niveles de almacenamiento normales de ZFS y, por lo tanto, no anula 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 zvol.

Sin embargo, existe una razón aún más convincente para elegir el cifrado OpenZFS nativo, algo llamado «envío sin procesar». La replicación de ZFS es ridículamente rápida y eficiente, a menudo varios órdenes de magnitud más rápido que las herramientas neutrales del sistema de archivos como rsync—Y el envío sin procesar hace posible no solo replicar cifrado datasetarena zvols, pero 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 es confiable ubicación, no se preocupe por leer sus datos privados. Con el envío sin procesar, sus datos se replican sin que se descifren nunca, y sin que el destino de la copia de seguridad pueda descifrarlos. Esto significa que puede replicar sus copias de seguridad externas a la casa de un amigo o un servicio comercial como rsync.net o zfs.rent sin comprometer su privacidad, incluso si el servicio (o amigo) está comprometido.

En caso de que necesite recuperar su copia de seguridad externa, simplemente puede replicarla Vuelve a su propia ubicación – entonces, y solo luego cargue la clave de descifrado para acceder realmente a los datos. Esto funciona tanto para la replicación completa (moviendo cada bloque a través de la red) como para la replicación incremental asincrónica (comenzando con una instantánea mantenida comúnmente 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 / zvol y no se puede habilitar para grupos completos como un todo. 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 llamado pool/encrypted, y debajo de eso creamos varios otros conjuntos de datos secundarios. O encryption La propiedad para niños 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 el momento, 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 existe, 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

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 adentro /banshee/encrypted/child2/. Lo que Yo puedo Lo que todavía vemos 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, incluidas, entre otras, USED, AVAIL, y REFER de cada conjunto de datos.

Es importante tener en cuenta que intentar ls un conjunto de datos cifrado 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:~# 

Esto se debe a que existe un directorio plano 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:

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 ensamblar 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

Ahora que ambos hemos cargado la clave requerida y ensamblado los conjuntos de datos, podemos volver a ver nuestros datos cifrados.