Criptografar um VPS parece coisa de uma linha só — cryptsetup luksFormat, pronto — e depois silenciosamente deixa de entregar o que as pessoas presumiam estar comprando. Em uma máquina alugada, existe um hypervisor abaixo do seu kernel, então o modelo de ameaça não é aquele para o qual a criptografia de disco completo foi projetada. Este guia é a versão honesta: o que o LUKS derrota em um VPS, o que não derrota, os dois caminhos de implantação que funcionam, e como desbloquear uma raiz criptografada via SSH para que você nunca fique trancado para fora do próprio servidor.
O que a criptografia realmente garante em um servidor alugado
A criptografia de disco completo protege dados em repouso. Essa expressão carrega bastante peso, e em um VPS vale a pena detalhar quais momentos contam como repouso e quais não contam — é nesse intervalo entre os dois que a maioria das expectativas quebra.
Hardware descomissionado
Discos falham, são substituídos e saem do rack. Um volume LUKS em um disco morto é um bloco de ruído para quem lidar com ele depois. A criptografia resolve esse caso por completo.
Um volume desanexado ou copiado
Se um volume é removido da sua instância, clonado ou transformado em imagem enquanto a máquina está desligada, o resultado é texto cifrado e um cabeçalho — não os seus arquivos.
Uma máquina em execução
Depois que o volume é aberto, a chave mestra vive na memória do kernel. Um acesso em nível de hypervisor pode, em princípio, alcançá-la. A criptografia eleva o custo aqui; ela não fecha a porta.
Os seus próprios erros
Swap não criptografado, backups em texto claro e logs escritos antes da montagem ficam todos fora do contêiner. É aí que acontece a maioria dos vazamentos reais em servidores criptografados, não pela cifra.
Diga o limite em voz alta para poder planejar em torno dele: enquanto o volume está desbloqueado, a chave está na RAM de um hardware que não é seu. O LUKS em um VPS é uma resposta forte ao acesso offline e uma resposta parcial ao acesso em tempo real. Combine-o com uma jurisdição em que você realmente confia — veja /offshore-hosting — em vez de tratá-lo como substituto de uma.
Escolha o formato antes de digitar um comando
Quatro arranjos cobrem quase todo requisito real. Escolher o errado custa uma reinstalação, então decida aqui em vez de na metade do caminho.
Caminho A — criptografar um volume de dados em um servidor que você já opera
Essa é a versão que a maioria das pessoas realmente quer: dez minutos de trabalho, sem reinstalação, e tudo o que importa termina dentro do contêiner. Anexe um segundo volume primeiro — em um plano /storage esse é o disco grande; em um /vps padrão você pode adicionar um no momento da implantação.
- 1
Identifique o dispositivo alvo
Rode lsblk e confirme que o dispositivo que você está prestes a formatar é o vazio. luksFormat destrói tudo o que estiver nele e não há como desfazer.
- 2
Crie o contêiner LUKS2
cryptsetup luksFormat --type luks2 /dev/vdb pede que você digite YES em maiúsculas, depois defina uma senha. Escolha uma que você consiga redigitar corretamente em um console sem histórico e sem eco na tela.
- 3
Abra-o e crie um sistema de arquivos
cryptsetup open /dev/vdb cryptdata cria /dev/mapper/cryptdata. Em seguida, mkfs.ext4 /dev/mapper/cryptdata, e monte-o onde os dados vão viver, por exemplo /srv/data.
- 4
Decida como ele será desbloqueado na inicialização
Ou você digita a senha a cada reinicialização, ou adiciona um keyfile com cryptsetup luksAddKey e o guarda na raiz. O keyfile é conveniente e estritamente mais fraco — tenha clareza sobre qual troca está fazendo.
- 5
Configure o crypttab e o fstab
Adicione o mapeamento a /etc/crypttab usando UUID= em vez de um nome de dispositivo, depois monte a partir de /etc/fstab com nofail para que um desbloqueio malsucedido nunca trave a inicialização.
Se o keyfile fica na raiz não criptografada, seja preciso sobre o que você tem: o volume está protegido contra um disco que sai do rack ou é desanexado da sua instância, e não contra uma cópia da VM inteira — porque essa cópia contém a chave. Qualquer coisa mais forte exige que a senha venha de fora do servidor.
Caminho B — uma raiz criptografada a partir de uma ISO personalizada
Quando o requisito é que nada legível exista na máquina enquanto ela está desligada, a própria raiz precisa estar dentro do LUKS. Isso significa uma instalação nova conduzida pelo console, em um provedor que permite inicializar a partir da sua própria ISO.
- 1
Inicialize o instalador pelo console
Monte uma ISO netinst do Debian ou Ubuntu como ISO personalizada e conduza a instalação via VNC ou serial. Nada disso funciona via SSH — ainda não existe sistema ao qual se conectar.
- 2
Use particionamento guiado com LVM criptografado
O instalador deixa um pequeno /boot em texto claro, porque algo precisa rodar antes de o volume ser aberto, e coloca a raiz e o swap dentro de um único contêiner LUKS.
- 3
Escolha uma senha que você consiga digitar às cegas
Você vai redigitá-la via SSH a cada reinicialização, sem eco na tela e sem autocompletar. Uma senha de cinco palavras vence uma sopa de símbolos aqui.
- 4
Configure o desbloqueio remoto antes de sair
Uma raiz recém-criptografada vai ficar parada no prompt de senha para sempre após a próxima reinicialização. Configure o desbloqueio remoto na mesma sessão, enquanto o console ainda está na sua frente.
Em planos com 1–2 GB de RAM, a derivação de chave Argon2id padrão pode pedir mais memória do que o initramfs tem, e o desbloqueio falha na inicialização mesmo com a senha correta. Limite isso no momento da formatação com cryptsetup luksFormat --pbkdf-memory 262144, ou inspecione um cabeçalho existente com cryptsetup luksDump antes de confiar em uma instância pequena para reiniciar sem supervisão.
Desbloqueio remoto via SSH com dropbear-initramfs
Uma raiz criptografada precisa de uma senha antes de o sistema operacional existir. O dropbear-initramfs coloca um servidor SSH minúsculo dentro do initramfs para que você possa fornecê-la de qualquer lugar — a diferença entre um servidor criptografado e um tijolo criptografado.
- 1
Instale o pacote
apt install dropbear-initramfs. Ele se integra à geração do initramfs e é reconstruído automaticamente em toda futura imagem de kernel.
- 2
Autorize uma chave, e apenas um comando
Coloque a sua chave pública em /etc/dropbear/initramfs/authorized_keys — no Debian 11 e anteriores, /etc/dropbear-initramfs/authorized_keys. Prefixe a linha com no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock" para que uma chave roubada não compre nada além de um prompt.
- 3
Dê uma rede ao initramfs
O DHCP funciona onde o provedor o oferece; caso contrário, adicione um parâmetro estático ip=ADDRESS::GATEWAY:NETMASK::eth0:off a GRUB_CMDLINE_LINUX e rode update-grub. Finalize com update-initramfs -u -k all para que a mudança chegue à imagem.
- 4
Teste uma reinicialização completa antes de confiar nela
Reinicie com o console do provedor aberto em outra janela, conecte-se, digite a senha e observe a inicialização continuar. Um caminho de desbloqueio não testado não é um recurso, é uma futura indisponibilidade.
O initramfs carrega a sua própria chave de host SSH, diferente da que o sistema já inicializado apresenta, então o seu cliente vai avisar sobre uma chave de host alterada a cada reinicialização. Rode o dropbear em uma porta separada via DROPBEAR_OPTIONS em /etc/dropbear/initramfs/dropbear.conf, ou conecte-se com ssh -o HostKeyAlias=box-initramfs, e registre as duas impressões digitais.
Gerenciamento de chaves é onde a criptografia de disco costuma falhar
A cifra não é o elo fraco e nunca foi. Todo desastre recuperável envolvendo LUKS se resume a uma chave ou a um cabeçalho, então trate os dois como infraestrutura.
- Faça backup do cabeçalho imediatamente — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — e guarde-o fora do servidor. Um cabeçalho danificado por um dd descuidado é perda de dados permanente, mesmo com uma senha perfeita.
- Use dois slots. O LUKS2 oferece 32: a sua senha em um, uma chave de recuperação longa e aleatória em outro, guardada em um gerenciador de senhas. Um único slot é um ponto único de falha autoinfligido.
- Faça a rotação na ordem certa em uma máquina remota — adicione a nova chave com luksAddKey, verifique se ela abre o volume, depois remova a antiga com luksKillSlot. Nunca o contrário.
- Mantenha a senha e os dados de conexão do servidor em lugares separados. Uma única anotação comprometida não deveria entregar tanto o endereço quanto a chave.
O que a criptografia custa em desempenho
A sobrecarga é real, mas geralmente invisível. Meça-a na máquina que você realmente tem, em vez de confiar em um benchmark de outra década.
As partes que as pessoas esquecem
Um volume criptografado com texto claro vazando pelas bordas é uma falsa sensação de segurança, o que é pior do que nenhuma. Feche esses cinco pontos antes de considerar o trabalho terminado.
- Swap. Uma partição de swap não criptografada pode reter fragmentos de qualquer coisa que tenha passado pela memória. Criptografe-a com uma chave aleatória nova a cada inicialização, via uma entrada /dev/urandom em /etc/crypttab.
- Logs escritos antes da montagem. Tudo o que é registrado enquanto o volume criptografado ainda está fechado cai na raiz em texto claro. Aponte os logs de aplicação e de banco de dados para um caminho dentro do contêiner.
- Backups. Copiar o conteúdo de um volume criptografado para um armazenamento de objetos em texto claro desfaz todo o exercício. Criptografe o backup de forma independente com restic, borg ou age, e guarde essas chaves em outro lugar.
- Snapshots. Um snapshot do provedor captura o disco, não a sua RAM, então o volume LUKS permanece como texto cifrado dentro dele — mas tudo o que foi deixado na raiz não criptografada é capturado exatamente como estava.
- Discard. Passar a flag discard através do LUKS mantém o trim do NVMe funcionando e publica quais blocos estão livres, vazando o quão cheio está o sistema de arquivos e, aproximadamente, o seu formato. Escolha essa opção deliberadamente, não copiando uma configuração pronta.
Onde o host ainda importa
A criptografia é a camada que você controla: ela decide o quão caro é ler os seus dados depois que uma máquina é desligada ou um disco sai do prédio. A camada ao redor dela — quem pode forçar o acesso ao hardware, e quais registros ligam o servidor a você — pertence ao provedor e à sua jurisdição. Seis das nossas quinze regiões são jurisdições de nível de privacidade; /locations lista todas, e /offshore-hosting mostra o que isso realmente muda.
Três capacidades do provedor decidem se os caminhos acima sequer estão disponíveis: inicialização por ISO personalizada, sem a qual o Caminho B é impossível; acesso ao console fora de banda para a reinicialização em que o desbloqueio remoto não volta; e um cadastro que nunca vinculou a máquina à sua identidade legal, desde o início. Todo plano /offshore-vps e /storage aqui inicializa a partir de uma ISO personalizada, oferece acesso ao console, e cobra a partir de um saldo pré-pago em cripto sem KYC — então um disco criptografado não fica em cima de um rastro documental que já leva o seu nome. /guides tem um passo a passo honesto sobre o que um host pode e não pode ver.
O checklist de implantação
- Nomeie a ameaça primeiro: discos descomissionados, volumes desanexados e imagens offline são o que a criptografia responde — um hypervisor ativo não é.
- Criptografe um volume de dados (Caminho A) se o servidor já está em execução; reinstale a partir de uma ISO personalizada (Caminho B) somente quando a própria raiz precisar ser criptografada.
- LUKS2 com aes-xts-plain64, e limite a memória do Argon2id em qualquer plano com menos de 2 GB de RAM.
- Senha em um slot de chave, uma chave de recuperação longa e aleatória em outro, ambas guardadas fora do servidor.
- Faça um backup do cabeçalho do LUKS antes de escrever o primeiro byte de dado real.
- dropbear-initramfs em uma porta não padrão, somente com chave, restrito ao comando cryptroot-unlock.
- Teste um ciclo completo de reinicialização e desbloqueio com o console do provedor ainda aberto ao seu lado.
- Backups criptografados fora do servidor, mais um simulado de restauração — um backup não testado é uma esperança, não um backup.
A criptografia de disco impede que o meu provedor de hospedagem leia os meus dados?
Em repouso, sim: assim que a máquina é desligada, o volume vira texto cifrado e a senha nunca saiu da sua cabeça. Enquanto o servidor está em execução com o volume aberto, a chave mestra fica na RAM de um hardware operado pelo provedor. A criptografia fecha todo caminho offline — discos descomissionados, volumes desanexados, imagens frias — e eleva o custo do restante. Ela complementa uma jurisdição confiável em vez de substituir uma.
Posso criptografar um VPS existente sem reinstalar?
Um volume de dados separado, sim, em cerca de dez minutos — esse é o Caminho A acima. O sistema de arquivos raiz, realisticamente não. O cryptsetup reencrypt consegue converter um sistema de arquivos no local, mas uma conexão perdida ou uma queda de energia no meio do processo em uma máquina remota deixa um servidor que não inicializa e uma noite longa pela frente. Reinstalar a partir de uma ISO personalizada é mais rápido e muito mais seguro.
Quanto desempenho o LUKS custa?
Menos do que a maioria das pessoas espera. Com AES-NI, o AES-XTS custa poucos por cento em cargas de trabalho mistas típicas, e o cryptsetup benchmark em um núcleo EPYC moderno reporta vários GB/s. O caso visível é I/O sequencial de thread única contra um NVMe rápido, onde um núcleo pode saturar antes do disco. Faça o benchmark da sua própria instância em vez de supor.
O que acontece se eu esquecer a senha?
Os dados se foram. Não existe mecanismo de recuperação, nenhuma chave mestra do lado do provedor e nenhum chamado de suporte que desfaça isso — essa característica é o propósito do design. Proteja-se com um segundo slot de chave contendo uma chave de recuperação aleatória, e com um backup do cabeçalho do LUKS guardado em algum lugar que não seja o servidor.
Rodar SSH dentro do initramfs é arriscado?
É uma exposição pequena e bem compreendida. O dropbear roda apenas pelos poucos segundos antes de o seu sistema de arquivos raiz existir, aceita somente chaves públicas, e pode ser restrito a um único comando forçado que não faz nada além de pedir uma senha. Em uma porta não padrão, com a chave de host do initramfs registrada separadamente, o risco prático é mínimo perto da certeza de ficar trancado para fora sem ele.
