Gostaria de adicionar uma partição LUKS a um VPS remoto. No entanto, o VPS deve ser reinicializado automaticamente ocasionalmente (aproximadamente a cada 10 a 14 dias) porque ele instala automaticamente as atualizações de segurança. Isso é compatível com cryptsetup/LUKS?
Se eu estiver lendo este tutorial do Digital Ocean corretamente, posso criar um arquivo-chave no próprio disco e usá-lo como uma segunda senha para a partição. Isso significa que só preciso inserir manualmente minha própria senha uma vez, durante a criação inicial do volume LUKS, e posso então esquecer minha própria senha?
Se isso for possível, quais são as implicações de segurança de ter a nova senha no próprio disco?
É possível - a maioria das distribuições Linux suporta o desbloqueio de volumes LUKS na inicialização por /etc/crypttab (usando um arquivo-chave ou solicitando uma senha), e um arquivo-chave funciona da mesma maneira que uma senha, e o LUKS suporta a adição de múltiplas senhas (keyslots) para um volume, então tudo feito no tutorial funcionará.
A questão é se é útil configurar a criptografia dessa maneira.
Este é apenas um problema potencial se você tiver um SSD dedicado – seja um sistema físico com os discos conectados via SATA ou se for uma VM com o disco “bruto” passado. Nesse caso, a criptografia é uma boa ideia; e embora seja responsabilidade da empresa de hospedagem higienizar o servidor antes de reutilizá-lo (ou antes de jogá-lo fora), há de fato um pequeno risco de que isso não aconteça e um SSD usado seja conectado. (Quando aluguei um servidor com desconto na Hetzner, ele tinha dois SSDs incompatíveis que foram claramente usados, mas ambos foram substituídos por dados aleatórios.)
Para VMs, porém, isso praticamente nunca acontece. O que você obtém como um “disco” virtual é, na maioria dos casos, um arquivo – provavelmente uma nova imagem .qcow2 armazenada em um enorme pool de armazenamento ZFS – e todos os sistemas de arquivos modernos já garantem que um novo arquivo não “incluirá” dados antigos. (E como são arquivos, há motivos práticos para reutilizar os arquivos existentes; é mais simples excluí-los quando uma VM é excluída e criar novos quando uma VM é criada.)
Ou a imagem do disco cresce sob demanda (onde o formato da imagem rastreia quais áreas estão alocadas), ou é um arquivo esparso de tamanho fixo (onde o sistema de arquivos subjacente rastreia o mesmo), ou é um arquivo de tamanho fixo arquivo pré-alocado (onde o sistema de arquivos zera proativamente os setores), mas geralmente você não terá pré-alocação sem zerar. (Acho que já vi isso no ESXi VMFS, mas ninguém executa serviços VPS no ESXi.)
Portanto, embora a configuração do LUKS forneça uma camada adicional de segurança (supondo que o "outro cliente" não obterá os dois discos simultaneamente) e facilite a limpeza do volume jogando fora o arquivo-chave, ainda é não é particularmente útil neste caso.
Se já houvesse o risco de outro cliente obter seus dados antigos, então a segurança de tal configuração dependeria da separação dos dois volumes (os dados criptografados do volume do sistema operacional em texto não criptografado) – é seguro se o "futuro cliente" obtém acesso a apenas um dos volumes, mas não se obtiver acesso a ambos.
Digamos que ambos os volumes foram armazenados no mesmo disco (novamente, apenas no caso de ser um servidor físico com seu próprio SSD dedicado), então qualquer pessoa que obtivesse acesso ao disco poderia simplesmente olhar seu /etc/crypttab, encontrar o arquivo-chave e desbloqueie o outro volume da mesma forma que é desbloqueado na reinicialização.