Criptografia de disco completo no VPS: LUKS e desbloqueio remoto

O que o seu provedor realmente consegue ver

Comece pela física, não pela política, porque uma política pode mudar e a física não. Em uma máquina virtual, a imagem de disco vive em um hardware que outra pessoa instalou no rack. Se essa imagem não estiver criptografada, ela é legível por qualquer um que acabe com a mão na mídia de armazenamento: um operador com acesso ao hypervisor, um técnico trocando um NVMe com falha em um par RAID-1, quem quer que receba esse disco quando ele for descomissionado e — no caso que todo mundo está realmente perguntando — qualquer um que chegue com uma ordem vinculante de um tribunal com jurisdição sobre a máquina. Nada disso exige má-fé ou uma backdoor. Um volume não criptografado é simplesmente um arquivo, e arquivos podem ser copiados.

A segunda camada é a memória. Nossos planos de VPS são virtualização completa em KVM, então você roda o seu próprio kernel em vez de compartilhar um — mas o hypervisor ainda é dono da RAM que entrega a você, e qualquer hypervisor pode, tecnicamente, fazer introspecção de um guest. A terceira camada é tudo que nunca toca o disco: o tráfego que sai da sua interface de rede, os metadados que a sua aplicação emite, o DNS que você resolve. Do lado da conta, mantemos muito pouco por design — um hash de senha argon2id, seu saldo e o respectivo livro-razão, as especificações dos pedidos e logs de acesso rotacionados após 14 dias, sem nome, endereço, telefone ou cartão em nenhum lugar disso, como detalhado na página da política sem KYC. Não reter nada sobre você é uma garantia diferente de ser incapaz de ler o seu disco, e só uma dessas duas coisas é algo que você mesmo pode impor.

O que a criptografia de disco completo resolve, e o que ela não resolve

A criptografia de disco completo é um controle para dados em repouso. Ela cobre exatamente os cenários acima, em que um volume muda de mãos enquanto a máquina está desligada ou a cópia é levada offline: um disco descomissionado ou que passou por RMA, um disco copiado em imagem, um volume clonado a partir da camada de armazenamento, um snapshot frio tirado à sua revelia. Em todos esses casos, um container LUKS criptografado é um blob opaco, e quem o possui precisa de uma frase secreta que só existiu na sua cabeça ou no seu laptop. Essa é uma fronteira real e sólida, e é a maior melhoria isolada que a maioria das pessoas pode fazer em um servidor alugado.

É igualmente importante ser direto sobre a outra metade. Um servidor em funcionamento tem a chave na RAM — é isso que torna o sistema de arquivos legível para os seus próprios processos — então a criptografia não faz nada contra um comprometimento de root em tempo real, um processo hostil dentro do guest, um dump de memória tirado com a máquina ligada, ou um hypervisor que faça introspecção dessa memória. Ela não criptografa o que sai pela porta de rede, e não ajuda se a sua aplicação grava segredos em um log que depois é enviado para outro lugar. Se o seu modelo de ameaça realmente exclui a introspecção do hypervisor, a resposta honesta não é uma cifra melhor: é hardware dedicado a partir de $66.00/mês, onde não existe hypervisor nenhum acima de você. Para tudo que fique aquém disso, criptografia em repouso somada a um provedor que retém quase nada cobre os casos realistas — os termos usados aqui estão definidos no glossário.

Volume de dados criptografado, ou raiz criptografada?

Existem dois desenhos, e cada um serve para uma situação diferente. O primeiro é um volume de dados criptografado: o sistema operacional fica em claro e você coloca tudo que importa — o estado da sua aplicação, o seu banco de dados, o seu repositório de documentos, as suas chaves — dentro de um container LUKS montado em um caminho de sua escolha. É instalável em uma máquina que já está em produção, nunca bloqueia uma reinicialização, e protege o material que alguém realmente iria querer. O que ele deixa legível é o formato do sistema: sua lista de pacotes, suas unidades systemd, seus vhosts do nginx, seu histórico de shell, seus logs.

O segundo é uma raiz criptografada, em que tudo, exceto uma pequena partição de boot, fica dentro do container. Nada sobre a máquina é legível quando ela está desligada, que é o resultado que a maioria das pessoas imagina quando diz que quer um servidor criptografado. O preço é pago a cada inicialização: a máquina para completamente em um prompt de frase secreta em um console que você não consegue ver, até que você dê a ela uma forma de perguntar remotamente. Esse é o motivo pelo qual a próxima seção existe. Como regra geral — criptografe a raiz quando estiver construindo uma máquina do zero e puder testá-la antes que ela carregue qualquer coisa; criptografe um volume de dados quando a máquina já existir e o tempo de inatividade for custoso. A conversão de uma raiz em funcionamento com cryptsetup reencrypt é possível no LUKS2, mas não é algo que recomendaríamos fazer em um servidor de produção que você não pode reconstruir.

Desbloqueio remoto: um pequeno servidor SSH no initramfs

O truque que torna uma raiz criptografada viável em uma máquina remota é o dropbear-initramfs. O initramfs é o sistema em miniatura que o kernel descompacta antes que a raiz de verdade exista; como você é dono do kernel em um VPS KVM, pode colocar um daemon SSH bem pequeno dentro dele. Na inicialização, a máquina sobe a sua interface de rede, inicia esse daemon e espera. Você se conecta, roda um comando, a frase secreta desbloqueia o container, o boot continua para o sistema real e o pequeno daemon desaparece. De fora, parece um servidor que leva trinta segundos a mais e uma ação deliberada para voltar.

Dois detalhes causam quase toda a dor de cabeça. O primeiro é que o servidor SSH do initramfs tem sua própria chave de host, diferente da que o sistema em funcionamento apresenta no mesmo endereço — então, se você deixá-lo na porta 22, o seu cliente vai recusar a segunda conexão por divergência de chave de host, todas as vezes. Dê a ele uma porta separada e um arquivo known_hosts separado, e o problema desaparece. O segundo é o timeout: o daemon não deve ficar esperando para sempre se você estiver dormindo, mas também não deve desistir antes que você consiga alcançar um terminal. Cinco minutos é um padrão sensato. Restrinja a chave para que ela não consiga fazer nada além de desbloquear, e trate o endereço desse listener de boot como algo que você não publica — o mesmo instinto que percorre manter seu nome fora de um servidor.

Slots de chave, cabeçalhos, e a falha que todo mundo enfrenta

Um container LUKS2 não criptografa os seus dados com a sua frase secreta. Ele criptografa uma chave mestra com a sua frase secreta, guarda essa cópia encapsulada em um slot de chave no cabeçalho, e criptografa o volume com a chave mestra. A consequência vale a pena internalizar: existem vários slots, então você pode cadastrar uma segunda frase secreta ou um keyfile sem recriptografar um único byte, e pode revogar um sem tocar nos outros. A outra consequência é mais afiada — o cabeçalho é o dado. Sobrescreva os primeiros megabytes desse volume e todos os slots desaparecem de uma vez, junto com qualquer chance de recuperação. Faça backup do cabeçalho, fora da máquina, no momento em que você cria o container, e de novo sempre que adicionar ou remover uma chave.

Depois há o modo de falha que este host torna incomumente evidente. O registro aqui é um nome de usuário e uma senha, com oito códigos de recuperação e nenhum e-mail em qualquer parte do processo, justamente para que não haja identidade a vazar — o que também significa que não existe caminho de recuperação baseado em identidade para nada, incluindo a sua própria conta. Ninguém pode dar aval por você, e ninguém tem uma cópia da sua frase secreta. Então construa a máquina criptografada enquanto você ainda tem uma funcionando, reinicie-a deliberadamente e desbloqueie-a remotamente antes que ela carregue dados, guarde o backup do cabeçalho e um segundo slot de chave em algum lugar que você ainda alcançaria depois de perder o seu laptop, e garanta que o seu plano de recuperação termine em reimplantar e restaurar do backup, e não em outra pessoa digitando uma frase secreta para você.

Os vazamentos nas bordas: swap, snapshots e backups

Uma raiz criptografada com uma partição de swap em texto claro é uma fechadura em uma porta com a janela aberta — o kernel vai jogar qualquer coisa para esse swap, incluindo material de chave, via paginação. A correção é regerar a chave do swap a partir de /dev/urandom a cada boot, o que não custa nada, porque o swap nunca precisa sobreviver a uma reinicialização. Dê o mesmo tratamento ao /tmp com tmpfs sempre que possível, desative a hibernação em um servidor, e pense bem sobre o discard antes de ativá-lo: repassar o TRIM para a camada de armazenamento é bom para o disco, mas vaza o padrão de quais blocos estão em uso, o que é uma exposição pequena, mas real, sobre o quão cheio está o seu volume e onde.

Backups merecem um pensamento à parte, porque um backup é uma cópia dos seus dados em algum lugar que a criptografia que você acabou de configurar não alcança. Nosso complemento de backups diários criptografados guarda snapshots fora do host nos planos de VPS, e snapshots manuais — que ficam no mesmo host — são uma conveniência de rollback, não um backup, como diz o FAQ. Se você considera o provedor dentro do escopo do seu modelo de ameaça, então criptografe no lado do cliente antes que qualquer coisa saia da máquina, com uma chave que não fique armazenada nela. Esse único hábito também torna o caminho de restauração portátil: um backup que só você consegue ler é um backup que você pode restaurar em qualquer lugar, inclusive em um plano de VPS diferente, em uma região diferente.

Onde a criptografia se encaixa em um modelo de ameaça offshore

A criptografia é um de três controles que falham de forma independente, e é exatamente por isso que usar os três não é paranoia, mas engenharia comum. O primeiro é o que o host sabe sobre você — nada, quando a conta é um nome de usuário financiado por um saldo pré-pago em cripto a partir de $30.00, em 8 moedas e variantes de rede, cobrindo 7 moedas, sem cartão e sem documento em nenhuma etapa da cadeia; esse é o assunto de pagar por hosting de forma anônima. O segundo é qual lei se aplica, o que é decidido por onde a máquina está, não por onde você está, e é trabalhado região por região em qual localização offshore você deveria escolher? e, do ponto de vista legal, em jurisdições de hosting offshore comparadas.

O terceiro é o que fica legível em repouso, e esse é só seu — nenhum provedor pode fazer isso por você, porque um provedor que guarda a sua chave não resolveu o problema que te preocupava. Empilhe os três e cada um cobre uma falha distinta: um vazamento de identidade não expõe o disco, uma surpresa jurisdicional não entrega uma frase secreta, e um disco roubado não revela o seu nome. Há 6 regiões para escolher entre nossas localizações, com um VPS online em cerca de 15 min; em hardware dedicado, entregue em 2–12 h com credenciais IPMI, você pode ir ainda mais longe e inicializar o seu próprio instalador em vez de confiar cegamente em uma imagem fornecida pelo provedor.

Desempenho, e as máquinas que não valem a pena criptografar

A questão do desempenho é resolvida, em grande parte, pelo hardware. Todo VPS da frota roda em AMD EPYC 9354 com AES-NI, então o aes-xts-plain64 move dados a vários gigabytes por segundo por núcleo — bem além do que qualquer carga de trabalho isolada exige de um array RAID-1 de NVMe. Rode o cryptsetup benchmark na sua máquina e leia os números, em vez de confiar em um post de blog, incluindo o nosso. O overhead que você consegue realmente medir aparece na latência, não na vazão, e só em cargas de trabalho que já são limitadas por fsync: um banco de dados relacional com muita escrita, um spool de e-mail movimentado, uma fila que confirma cada mensagem. Para um servidor web, um backend de aplicação, um endpoint de VPN ou um repositório de arquivos, o custo é praticamente zero.

A pergunta mais útil é quais máquinas não merecem essa peça móvel a mais. Uma máquina sem nenhum estado privado não ganha nada com a criptografia e passa a ter uma reinicialização que não consegue terminar sem intervenção — um mirror estático público, um nó de cache, um relé intermediário de Tor cujo único segredo é uma chave de identidade que você poderia rotacionar em um minuto. Criptografe onde há algo a perder: o banco de dados, o repositório de e-mail, o destino do backup, a máquina que termina o seu túnel WireGuard e guarda as suas chaves privadas. Decida máquina por máquina, não pela frota inteira, e anote qual é qual — o operador daqui a seis meses é você, com menos contexto e uma noite de sono pior.

Passo a passo

1. 01

   Decida o que você está protegendo, e escolha o desenho

   Escreva a única frase que importa: quais arquivos causariam dano se uma cópia desse volume saísse do prédio. Se a resposta for um banco de dados e um diretório de chaves, um volume de dados criptografado é suficiente, e você mantém reinicializações sem intervenção. Se a resposta for a máquina inteira conta uma história que eu preferiria que não contasse, construa uma raiz criptografada e aceite que toda inicialização vai precisar de você. Não comece a digitar antes que essa frase exista.

2. 02

   Implante um VPS novo e reforce a segurança antes de qualquer outra coisa

   Implante pelo painel — um VPS fica online em cerca de 15 min — e faça primeiro o trabalho chato, em uma máquina limpa, enquanto um erro ainda não custa nada. SSH somente por chave, um firewall padrão-negar, atualizações de segurança automáticas, e o cryptsetup instalado.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   Crie o container LUKS2 e coloque um sistema de arquivos nele

   Para um volume de dados, um container baseado em arquivo é a opção menos invasiva e se comporta de forma idêntica a uma partição. Dimensione-o para o que ele vai guardar, não para o tamanho do disco. Escolha uma frase secreta que você consiga digitar de memória sob estresse — essa não é uma senha que você vai colar de um gerenciador em uma máquina que ainda não inicializou.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   Cadastre uma segunda chave e faça backup do cabeçalho fora da máquina

   Um único slot de chave está a um dia ruim de distância da perda total. Adicione uma segunda frase secreta ou um keyfile, exporte o cabeçalho para um arquivo, e copie esse arquivo para algum lugar fora do servidor — um volume criptografado no seu laptop, ou um armazenamento offline. Repita a exportação sempre que mudar um slot; um backup de cabeçalho desatualizado pode ressuscitar uma chave que você pensava ter revogado.

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   Para uma raiz criptografada, instale o daemon SSH do initramfs

   Só é relevante se a própria raiz estiver criptografada. Coloque sua chave pública onde o initramfs vai encontrá-la, mova o listener para fora da porta 22 para que ele nunca colida com a chave de host real, suba a interface com DHCP, e reconstrua. Os caminhos mudaram no Debian 12: lá é /etc/dropbear/initramfs/, e /etc/dropbear-initramfs/ no Debian 11.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   Reinicie de propósito, enquanto a máquina ainda está vazia

   Esta é a etapa que as pessoas pulam e depois se arrependem. Reinicie deliberadamente, antes de existir qualquer dado, e desbloqueie pela rede exatamente como você faria às três da manhã. Mantenha o listener de boot em seu próprio arquivo known_hosts, para que sua chave de host nunca entre em conflito com a real. Se ela não voltar, você perdeu uma máquina de teste, e não uma de produção.

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   Feche as brechas e escreva o plano de recuperação

   Regenere a chave do swap a partir de /dev/urandom para que nada do que foi paginado sobreviva a uma reinicialização, mantenha a hibernação desligada, e criptografe os backups no lado do cliente antes que eles saiam da máquina. Depois escreva o runbook de recuperação — onde o backup do cabeçalho está guardado, qual slot é qual, e o caminho de reimplantar-e-restaurar que você vai seguir quando desbloquear não for uma opção. Um plano que você não escreveu é um plano que você não tem.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256