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 dataset
s y zvol
s, 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.