Guía de inicio rápido de cifrado nativo OpenZFS

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

Algoritmo de cifrado OpenZFS por defecto o uno aes-256-ccm (hasta 0.8.4) o: aes-256-gcm (> = 0.8.4) cuando: encryption=on Pero también se puede mencionar 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 (por defecto en OpenZFS> = 0.8.4)

Hay más en el cifrado original de OpenZFS que los algoritmos utilizados. Así que trataremos de darle una base breve pero sólida para el ojo del administrador de sistemas sobre «por qué» և «qué» como él և en términos de simple «cómo».

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

Un administrador de sistemas inteligente que quiera proporcionar cifrado de ocio no necesita realmente el cifrado nativo OpenZFS. Como se menciona en el prefacio, LUKS, VeraCryptև Hay muchos otros esquemas disponibles և se pueden colocar debajo o encima de OpenZFS.

Primero, «por qué no»

Poner algo como Linux LUKS Tiene una ventaja bajo OpenZFS completo: cifrado de disco, el atacante ya no puede ver los nombres, tamaños o propiedades de ZFS datasets և: zvols sin una entrada clave. De hecho, es posible que un atacante no vea necesariamente que se está utilizando ZFS.

Pero la instalación tiene importantes inconvenientes. LUKS (o similar) en OpenZFS. Una de las cosas más maravillosas de todos es que individual El disco que formará parte de la agrupación debe estar cifrado, cada volumen se carga y decodifica en la agrupación ZFS. import Este puede ser un desafío notable para los sistemas ZFS de varios discos. En algunos casos, mucho docenas Otro problema con el cifrado de discos en ZFS es que la capa adicional es incorrecta, puede anular todas las garantías de integridad normal de ZFS.

Poniendo: LUKS o encima de OpenZFS similar elimina los problemas anteriores LUKS cifrado zvol solo necesita una clave, sin importar cuántos discos estén involucrados LUKS layer no puede reclamar garantías de integridad de OpenZFS desde aquí. Desafortunadamente, ZFS presenta un nuevo problema con el cifrado. Importa efectivamente la compresión interna de OpenZFS porque los datos cifrados generalmente son incompatibles. Este enfoque también requiere usar uno zvol por el sistema de archivos cifrado, así como por el sistema de archivos invitado (p. ej. ext4) Para medir LUKS el volumen en sí.

Ahora por qué»

La codificación original de OpenZFS divide la diferencia. Opera por encima de las capas normales de almacenamiento ZFS, por lo que no garantiza la propia integridad de ZFS. Pero eso tampoco evita que ZFS se comprima. Los datos se comprimen antes de cifrarlos dataset o: zvol,

Aunque existe una razón aún más convincente para elegir el cifrado nativo OpenZFS. Algo llamado «envío sin procesar». La copia de seguridad ZFS es ridículamente rápida y eficiente. A menudo, unos pocos órdenes de magnitud más rápido que las herramientas del sistema de archivos neutrales, como: rsync– ում el envío sin procesar permite no solo copiar la contraseña datasetս և: zvols, pero hágalo sin revelar la clave del sistema remoto.

Esto significa que puede utilizar la copia de seguridad ZFS para realizar una copia de seguridad de sus datos. no fidedigno ubicación sin la molestia de leer sus datos personales. Al enviar datos sin procesar, se realiza una copia de seguridad de sus datos sin ser decodificados, sin que ningún objetivo de copia de seguridad pueda descifrarlos en absoluto. Esto significa que puede hacer una copia de seguridad de sus reservas externas en la casa de un amigo o en un servicio comercial similar. rsync.net: o: zfs.rent: sin comprometer su privacidad, incluso si el servicio (o amigo) en sí está comprometido.

En caso de que necesite restaurar su copia de seguridad externa, simplemente puede reproducirla espalda: tu propia ubicación – entonces, և solo: luego, descargando la clave de descifrado para acceder realmente a los datos. Esto funciona para una copia de seguridad completa (moviendo cada bloque por cable) o una copia de seguridad incremental asincrónica (comenzando con una imagen generalmente guardada և moviendo solo los bloques cambiados después de esa imagen).

¿Qué está cifrado, qué no?

El cifrado original de OpenZFS no es un esquema de cifrado de disco completo. Está habilitado o deshabilitado en cada base de datos / uno a uno, no se puede habilitar para todos los grupos en general. El contenido de las tiras o bases de datos encriptadas ry está protegido contra software espía, pero los metadatos que describen bases de datos / tiras no.

Digamos que creamos una base de datos encriptada por nombre pool/encryptedև bajo él creamos և bases de datos de varios niños. En: encryption La propiedad para niños se hereda de forma predeterminada de la base 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  -

En este momento, todas nuestras bases de datos cifradas están instaladas. Pero aunque los bajemos, descarguemos la clave de cifrado, haciéndolos inaccesibles, veremos al mismo tiempo que existejunto 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 Finn arándano en: /banshee/encrypted/child2/¿Que somos? lata todavía vemos la estructura de existencia de todo nuestro árbol codificado en ZFS. También podemos ver las propiedades de cada base de datos cifrada, que incluyen: USED, AVAIL, և: REFER de cada base de datos.

Vale la pena señalar que intentar hacerlo ls Una base de datos encriptada cuya clave no está cargada no necesariamente causa 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 hay un directorio vacío en el host, incluso cuando la base de datos original no está instalada. La carga de la clave o la recopilación de datos no cambia automáticamente.

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 última copia Finn arándano, también necesitamos instalar bases de datos cargadas con nuevas 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 descargado la clave requerida և: instalado las bases de datos, podemos volver a ver nuestros datos cifrados.