Guia do servidor de encriptação de disco completo LUKS

O LUKS (Linux Unified Key Setup) encripta um dispositivo de bloco Linux na totalidade, de modo que o conteúdo fica ilegível sem a chave mestra. Uma unidade roubada, um chassis desativado, um disco de backup esquecido: nenhum destes expõe os seus dados, desde que o LUKS esteja configurado corretamente. Esta publicação aborda como implementar a encriptação de disco completo LUKS num servidor, incluindo o layout LVM, a gestão de chaves, o desbloqueio remoto e os modos de falha que impedem as pessoas de aceder aos seus próprios dados.

A implementação de referência aqui é o LUKS2 com LVM dentro do contentor encriptado, num servidor Linux com AES-NI na CPU. Essa combinação lida com todas as cargas de trabalho modernas, tem um bom desempenho e cumpre os requisitos de dados em repouso da HIPAA, PCI-DSS, RGPD e SOC 2.

Porquê o LUKS2 e o que verificar primeiro

O LUKS encripta na camada de dispositivos de bloco utilizando o dm-crypt, com a chave mestra armazenada em slots de chave dentro do cabeçalho do LUKS. Essa separação é importante: pode alternar frases-passe ou adicionar novas chaves sem ter de encriptar novamente o disco.

O LUKS2 é o padrão atual. Suporta até 32 slots de chave, metadados no formato JSON, re-encriptação online e encriptação autenticada através do --integrity sinalizador. O LUKS1 suporta 8 slots de chave e funciona bem em sistemas mais antigos, mas novas implementações devem começar com o LUKS2.

A sobrecarga de desempenho com o AES-NI é normalmente inferior a 5% em hardware moderno. Verifique antes de começar:

grep -o aes /proc/cpuinfo | head -1
cryptsetup benchmark

Se grep não retornar nada, a sua CPU não possui AES-NI e a encriptação ficará limitada pela CPU sob I/O intenso. cryptsetup benchmark mostra a taxa de transferência por algoritmo de encriptação, para que possa escolher o mais rápido que o seu hardware suporta. Confirme também que o cryptsetup está instalado e que o dm-crypt módulo do kernel está disponível. Ambos vêm por padrão no Ubuntu, Debian, RHEL e Arch.

Estrutura do disco

Duas partições permanecem sem encriptação: a partição do sistema EFI (512 MB FAT32) e /boot (1 a 2 GB, ext4 ou xfs). O GRUB precisa de ler ambas antes de poder solicitar a frase-passe. Tudo o resto fica dentro do contentor LUKS.

O layout recomendado é LVM dentro do LUKS: um contentor LUKS a conter um grupo de volumes LVM, com volumes lógicos para as partições raiz, swap e quaisquer partições de dados. Isto mantém os metadados do LVM encriptados e permite redimensionar ou criar instantâneos de volumes sem afetar a camada LUKS. O LUKS sobre LVM também funciona, mas expõe a estrutura do grupo de volumes.

O ext4 é a opção padrão segura para o volume raiz. O xfs lida melhor com ficheiros grandes e gravações paralelas, o que é importante para servidores de multimédia, ML e bases de dados. Para SSDs e NVMe, adicione a discard opção em /etc/crypttab para ativar o TRIM. O TRIM revela quais os setores que estão em uso, o que constitui uma pequena fuga de informação. Na maioria das cargas de trabalho, vale a pena pelo benefício do nivelamento de desgaste. Se o seu modelo de ameaças incluir a análise forense do dispositivo, mantenha-o desativado.

Configurar o LUKS com o LVM

Identifique o disco de destino com lsblk e limpe quaisquer metadados existentes:

wipefs -a /dev/sdX

Opcionalmente, sobrescreva com dados aleatórios para que os blocos encriptados não sejam distinguíveis do espaço vazio:

dd if=/dev/urandom of=/dev/sdX bs=1M status=progress

Inicialize o contentor LUKS2. Utilize --sector-size 4096 para NVMe e SSDs modernos com setores físicos de 4K:

cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/sdX
cryptsetup luksOpen /dev/sdX cryptdata

Faça uma cópia de segurança do cabeçalho imediatamente, antes de colocar quaisquer dados no disco:

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file luks-header-backup.img

Crie o LVM sobre o contentor desbloqueado e, em seguida, formate os volumes lógicos:

pvcreate /dev/mapper/cryptdata
vgcreate vg_secure /dev/mapper/cryptdata
lvcreate -L 50G -n lv_root vg_secure
lvcreate -L 8G -n lv_swap vg_secure
 
mkfs.xfs /dev/vg_secure/lv_root
mkswap /dev/vg_secure/lv_swap

Adicione uma entrada ao /etc/crypttab usando o UUID, e não /dev/sdX, que pode mudar entre reinicializações. Obtenha-o com blkid /dev/sdX:

cryptdata UUID=<your-uuid> none luks,discard

Em seguida, monte através de /etc/fstab:

/dev/vg_secure/lv_root  /  xfs  defaults,noatime  0 1

Regenera o initramfs para que os ganchos de encriptação sejam carregados no arranque:

# Debian/Ubuntu
update-initramfs -u -k all
 
# RHEL/Fedora
dracut -f --regenerate-all

Reinicie, introduza a frase de passagem e confirme a configuração com cryptsetup status cryptdata e lsblk -f. Este último deve mostrar crypto_LUKS como o FSTYPE na partição encriptada.

Gestão de chaves e desbloqueio remoto

O LUKS2 suporta 32 slots de chave. Utilize pelo menos três desde o início: uma frase-passe de administrador, uma chave de recuperação armazenada offline (impressa e guardada em local seguro, ou numa pen USB encriptada num cofre) e um ficheiro de chave para o desbloqueio automático de volumes de dados secundários. Limite-se aos 95 caracteres ASCII imprimíveis, pois os caracteres não ASCII causam problemas de disposição do teclado no prompt de arranque que são irritantes de depurar. Altere a frase-passe de administrador sempre que alguém com acesso sair da equipa.

Visualize os slots ativos com cryptsetup luksDump /dev/sdX, adicione uma chave com cryptsetup luksAddKey, e revogue uma com cryptsetup luksKillSlot. Proteja todos os ficheiros de chave com permissões rigorosas:

chmod 0400 /etc/luks/keyfile.bin

Para servidores sem monitor em centros de dados remotos, o prompt da senha é um problema. Três formas de lidar com isso:

O Dropbear executa um pequeno servidor SSH no initramfs. Inicia sessão via SSH após o arranque e introduz a frase-passe manualmente. O Clevis com Tang utiliza encriptação de disco ligada à rede: o servidor desbloqueia-se desde que consiga aceder a um servidor Tang na rede de confiança. O Tang não armazena a sua chave, fornece apenas metade de uma troca McCallum-Relyea. Utilize vários servidores Tang com o sss pin para que o desbloqueio continue a funcionar se um estiver offline. A ligação TPM 2.0 via systemd-cryptenroll vincula a chave ao PCR 7 (estado de Arranque Seguro), pelo que o servidor só se desbloqueia se o firmware e o gestor de arranque não tiverem sido adulterados. Mantenha sempre uma frase-passe como alternativa ao utilizar o TPM, porque as atualizações de firmware alteram os valores do PCR.

Reforço da segurança e prevenção de bloqueios

Utilize frases-passe com pelo menos 20 caracteres. Ative a encriptação autenticada com --integrity se luksFormat se o seu modelo de ameaças incluir a adulteração de dados, em vez de apenas a confidencialidade. Isto acarreta um custo de amplificação de gravação, por isso faça primeiro um teste de desempenho.

Não clone um contentor LUKS entre máquinas. A chave do volume é copiada com ele, pelo que alterar a frase-passe num host não protegerá o outro. Reformate cada disco individualmente.

Para um desmantelamento seguro, cryptsetup erase /dev/sdX limpa todas as entradas de chave em milésimos de segundo, tornando o disco irrecuperável sem destruição física. Isso por si só é um forte argumento para encriptar tudo por predefinição.

Modos de falha comuns:

O modo de falha mais importante é a corrupção do cabeçalho. Se o cabeçalho LUKS se perder ou ficar corrompido, os dados desaparecem. Não há recuperação possível, a não ser restaurando a partir de uma cópia de segurança do cabeçalho. Guarde uma cópia num suporte separado, idealmente em dois locais, e nunca no próprio disco encriptado. Para volumes secundários não críticos, adicione nofail a /etc/crypttab para que uma montagem falhada não bloqueie o arranque.

Os servidores dedicados da FDC vêm equipados com hardware que suporta AES-NI e encriptação total do disco de fábrica. Configure um servidor dedicado quando estiver pronto para a implementação.