agosto 1, 2021

Cronica

Mundo completo de noticias

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

7 min read
Ampliar / El cifrado de disco es un tema complejo, pero este artículo debería proporcionar un enfoque sólido para implementar OpenZFS.

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.

READ  El Banco Central de China distribuirá $ 1,5 millones en e-yuan en la primera prueba pública del nuevo sistema de pago.

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.

READ  Cómo saber qué correos electrónicos te rastrean silenciosamente

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:

[email protected]:~# zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase banshee/encrypted
Enter passphrase: 
Re-enter passphrase: 

[email protected]:~# zfs create banshee/encrypted/child1
[email protected]:~# zfs create banshee/encrypted/child2
[email protected]:~# zfs create banshee/encrypted/child3

[email protected]:~# 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

[email protected]:~# 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:

[email protected]:~# wget -qO /banshee/encrypted/child2/HuckFinn.txt http://textfiles.com/etext/AUTHORS/TWAIN/huck_finn

[email protected]:~# zfs unmount banshee/encrypted
[email protected]:~# zfs unload-key -r banshee/encrypted
1 / 1 key(s) successfully unloaded

[email protected]:~# zfs mount banshee/encrypted
cannot mount 'banshee/encrypted': encryption key not loaded

[email protected]:~# ls /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

[email protected]:~# 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.

READ  Desinstale estas aplicaciones maliciosas de Android que robaron contraseñas de Facebook

Es importante tener en cuenta que intentar ls un conjunto de datos cifrado que no tiene su clave cargada no producirá necesariamente un error:

[email protected]:~# zfs get keystatus banshee/encrypted
NAME               PROPERTY   VALUE        SOURCE
banshee/encrypted  keystatus  unavailable  -
[email protected]e:~# ls /banshee/encrypted
[email protected]:~# 

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:

[email protected]:~# zfs load-key -r banshee/encrypted
Enter passphrase for 'banshee/encrypted': 
1 / 1 key(s) successfully loaded
[email protected]:~# zfs mount | grep encr
[email protected]:~# ls /banshee/encrypted
[email protected]:~# 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:

[email protected]:~# zfs get keystatus banshee/encrypted/child2
NAME                      PROPERTY   VALUE        SOURCE
banshee/encrypted/child2  keystatus  available    -

[email protected]:~# ls -l /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

[email protected]:~# zfs mount -a
[email protected]:~# 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.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Copyright © All rights reserved. | Newsphere by AF themes.