Um guia de início rápido para criptografia OpenZFS nativa

Prolongar / A criptografia de disco é um tópico complexo, mas este artigo deve dar uma ideia sólida da implementação do OpenZFS.

Um dos muitos recursos que o OpenZFS traz para a mesa é a criptografia ZFS nativa. Introduzida pela primeira vez no OpenZFS 0.8, a criptografia nativa permite que o administrador do sistema criptografe de forma transparente os dados em repouso no próprio ZFS. Isso evita a necessidade de ferramentas separadas, como LUXO, VeraCrypt, ou BitLocker.

O algoritmo de criptografia OpenZFS é padronizado para qualquer aes-256-ccm (antes de 0.8.4) ou aes-256-gcm (> = 0,8.4) quando encryption=on Está estabelecido. Mas também pode ser especificado diretamente. Os algoritmos atualmente suportados são:

  • aes-128-ccm
  • aes-192-ccm
  • aes-256-ccm (padrão em OpenZFS <0.8.4)
  • aes-128-gcm
  • aes-192-gcm
  • aes-256-gcm (padrão em OpenZFS> = 0.8.4)

No entanto, há mais na criptografia OpenZFS nativa do que os algoritmos usados, então tentaremos fornecer uma base curta, mas sólida na perspectiva do administrador do sistema sobre o “por que” e o “o quê”, bem como o simples “como”.

Por que (ou por que não) criptografia OpenZFS nativa?

Um administrador de sistema inteligente que deseja fornecer criptografia em repouso realmente não precisa da criptografia OpenZFS nativa, obviamente. Conforme mencionado na introdução, LUKS, VeraCrypt, e muitos outros esquemas estão disponíveis e podem ser colocados abaixo ou acima do OpenZFS.

Primeiro, o “por que não”

Coloque algo como Linux LUKS no OpenZFS tem uma vantagem, com o cheio disco criptografado, um invasor empreendedor não pode mais ver nomes, tamanhos ou propriedades do ZFS datasets Y zvols sem acesso à chave. Na verdade, o invasor não pode necessariamente ver que o ZFS está em uso.

Mas existem desvantagens significativas em colocar LUKS (ou similar) no OpenZFS. Uma das mais distorcidas é que cada Individual O disco que fará parte do grupo deve ser criptografado, com cada volume carregado e descriptografado antes do grupo ZFS. import etapa. Esse pode ser um desafio notável para sistemas ZFS com muitos discos; em alguns casos, muitos dezenas Dos discos. Outro problema com a criptografia sob ZFS é que a camada extra é algo extra que pode falhar e pode desfazer todas as garantias normais de integridade do ZFS.

colocando LUKS ou semelhante no topo do OpenZFS elimina os problemas mencionados, um LUKS criptografia zvol você só precisa de uma chave, independentemente de quantos discos estão envolvidos, e o LUKS camada não pode desfazer as garantias de integridade do OpenZFS a partir daqui. Infelizmente, a criptografia sobre ZFS apresenta um novo problema: ela enfraquece efetivamente a compactação online do OpenZFS, pois os dados criptografados geralmente são incompressíveis. Esta abordagem também requer vestindo um zvol por sistema de arquivos criptografado, junto com um sistema de arquivos convidado (por exemplo, ext4) para formatar o LUKS mesmo volume com.

Agora, o “porquê”

A criptografia nativa do OpenZFS divide a diferença: ela opera sobre as camadas normais de armazenamento do ZFS e, portanto, não enfraquece as garantias de integridade do ZFS. Mas também não interfere na compactação ZFS: os dados são compactados antes de serem armazenados em uma criptografia. dataset ou zvol.

No entanto, há uma razão ainda mais convincente para escolher a criptografia OpenZFS nativa: algo chamado “envio bruto”. A replicação do ZFS é ridiculamente rápida e eficiente; muitas vezes várias ordens de magnitude mais rápido do que ferramentas neutras do sistema de arquivos, como rsyncE o envio bruto torna possível não apenas replicar datasetareia zvolSim, mas sem expor a chave ao sistema remoto.

Isso significa que você pode usar a Replicação ZFS para fazer backup de seus dados em um suspeito localização, sem se preocupar em ler seus dados privados. Com o envio bruto, seus dados são replicados sem nunca serem descriptografados e sem serem descriptografados pelo destino de backup. Isso significa que você pode replicar seus backups externos para a casa de um amigo ou para um serviço comercial como rsync.net ou zfs.rent sem comprometer a sua privacidade, mesmo que o serviço (ou amigo) seja comprometido.

No caso de precisar recuperar seu backup externo, você pode simplesmente replicá-lo costas para sua própria localização, então, e em seguida, carregar a chave de descriptografia para realmente acessar os dados. Isso funciona para replicação completa (movendo cada bloco através da conexão) ou replicação incremental assíncrona (começando de um instantâneo comum e movendo apenas os blocos que mudaram desde aquele instantâneo).

O que é criptografado e o que não é?

A criptografia nativa do OpenZFS não é um esquema de criptografia de disco completo; ele é habilitado ou desabilitado por conjunto de dados / por zvol e não pode ser habilitado para grupos inteiros em sua totalidade. O conteúdo dos conjuntos de dados criptografados ou zvols são protegidos contra espionagem em repouso, mas os metadados que descrevem os próprios conjuntos de dados / zvols não são.

Digamos que criamos um conjunto de dados criptografados chamado pool/encrypted, e abaixo dele criamos vários outros conjuntos de dados secundários. O encryption A propriedade para filhos é herdada por padrão do conjunto de dados principal, portanto, podemos ver o seguinte:

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

No momento, todos os nossos conjuntos de dados criptografados estão montados. Mas mesmo se os desmontarmos e baixarmos a chave de criptografia, o que os torna inacessíveis, ainda podemos ver que existe, junto com suas propriedades:

[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 acima, depois de baixar a chave de criptografia, não podemos mais ver nossa cópia recém-baixada de Mirtilo finlandês sobre /banshee/encrypted/child2/. O que posso Ainda vemos a existência e a estrutura de toda a nossa árvore criptografada pelo ZFS. Também podemos ver as propriedades de cada conjunto de dados criptografado, incluindo, mas não se limitando a, o USED, AVAIL, Y REFER de cada conjunto de dados.

É importante notar que tentar ls um conjunto de dados criptografado que não tem sua chave carregada não necessariamente falhará:

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

Isso ocorre porque existe um diretório simples no host, mesmo quando o conjunto de dados real não está montado. Recarregar a chave não remonta automaticamente o conjunto de dados:

[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 acessar nossa nova cópia do Mirtilo finlandês, também precisaremos montar os conjuntos de dados recarregados recentemente com as chaves:

[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

Agora que ambos carregamos a chave necessária Y montado os conjuntos de dados, podemos ver nossos dados criptografados novamente.

You May Also Like

About the Author: Gabriela Cerqueira

"Solucionador de problemas do mal. Amante da música. Especialista certificado em cultura pop. Organizador. Guru do álcool. Fanático por café."

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *