O que criptografar um disco alugado realmente te dá
Um servidor tem dois estados, e a criptografia de disco só tem opinião sobre um deles. Desligado, o volume é texto cifrado: o armazenamento contém bytes indistinguíveis de ruído sem a chave. Em execução, o volume está montado, o que significa que a chave mestra foi derivada, carregada na memória do kernel e deixada lá enquanto a máquina estiver ligada. Todo arquivo que o sistema operacional consegue ler, ele consegue ler porque essa chave está residente. A criptografia não parou de funcionar — ela está simplesmente fazendo exatamente o que foi pedido para fazer.
Essa é uma garantia mais restrita do que o marketing sugere, e ainda assim vale a pena ter, porque os eventos que ela cobre são os que realmente acontecem. Um drive é desativado e revendido. Um NVMe com defeito volta para o fabricante em RMA com seus dados dentro. Um nó é desligado e seus discos são copiados. Um arquivo de backup sai do prédio em uma mídia que ninguém criptografou. Alguém com acesso físico a um rack leva para casa a coisa errada. Isso não tem nada de glamouroso e é a esmagadora maioria das exposições do mundo real — muito mais comum do que a batida em uma máquina em funcionamento que todo mundo imagina.
| Cenário | Estado da máquina | O LUKS ajuda? | O que fica exposto |
|---|---|---|---|
| Drive desativado, revendido ou em RMA | Desligada | Sim, completamente | Texto cifrado e o cabeçalho LUKS |
| Nó desligado, discos copiados | Desligada | Sim | Texto cifrado, layout de partições, /boot em texto plano |
| Arquivo de backup copiado para fora do local | n/a | Só se o próprio arquivo estiver criptografado | O que quer que o arquivo contenha, em texto plano |
| Aquisição ao vivo de uma instância em execução | Em execução | Praticamente não | Tudo — a chave está na RAM |
| Comprometimento do sistema em execução | Em execução | Não | Tudo o que o volume montado expõe |
O hypervisor está dentro do seu modelo de ameaça, e a criptografia não o remove
Em um VPS, o seu kernel é um convidado. Quem opera o hypervisor tem acesso à memória desse convidado da mesma forma que você tem acesso ao conteúdo de um arquivo, e não existe nenhuma etapa criptográfica no meio do caminho. virsh dump grava a RAM de um domínio em execução em um arquivo como uma operação de rotina; a migração ao vivo copia essa mesma memória pela rede por design, porque é exatamente isso que a migração é. Uma chave mestra do LUKS que vive na memória do convidado está dentro de tudo isso.
Então a frase honesta é esta: a criptografia de disco completo em um VPS protege seus dados de todo mundo, exceto de quem opera o hypervisor — e até dessa parte também, mas só enquanto a máquina está desligada. Qualquer hospedagem que afirme que criptografar o disco do seu convidado torna seus dados ilegíveis para ela em uma instância em execução está descrevendo uma máquina que não existe. Preferimos deixar isso escrito do que deixar você inferir algo mais confortável.
Se o provedor genuinamente faz parte do seu modelo de ameaça, a resposta não é uma cifra mais forte. É remover o hypervisor: um servidor dedicado roda o seu kernel direto no metal, então ler a memória dele exige ter a máquina fisicamente em mãos e montar um ataque estilo DMA ou cold-boot contra a RAM — lento, barulhento, e exigindo um nível de acesso que uma solicitação de rotina não concede. O guia VPS versus dedicado cobre onde essa troca também se paga por outros motivos. Extensões de computação confidencial como AMD SEV-SNP e Intel TDX visam exatamente essa lacuna, mas hoje não são commodity em VPS alugados, e elas transferem a confiança para o fabricante da CPU em vez de eliminá-la.
Três formas de rodar isso, e o que cada uma custa para você
Na prática existem três formatos, e eles trocam segurança por quanto seus reboots vão doer. Uma raiz criptografada desbloqueada pelo console é a mais forte e a mais chata: nada sobrevive a um reboot sem um humano. Uma raiz criptografada com um servidor SSH no initramfs tem a mesma segurança com desbloqueio remoto, e é o que a maioria das pessoas deveria montar. Um volume de dados criptografado sobre uma raiz em texto plano é a opção fácil, e a que decepciona silenciosamente.
Decepciona porque uma raiz em texto plano coleta seus segredos, você querendo ou não. O journal do systemd escreve lá. Assim como o histórico do shell, o cache de pacotes, os core dumps, o /tmp, o data root padrão do Docker e — o que pega quase todo mundo — o swap, que é para onde vai a memória de um processo quando a máquina está sob pressão. Criptografar o /var/lib/mysql enquanto o swap fica descriptografado ao lado não é uma defesa parcial, é uma defesa completa com um buraco no meio.
| Configuração | Desbloqueio | Sobrevive a um reboot sem supervisão | Veredito honesto |
|---|---|---|---|
| Raiz criptografada, desbloqueio pelo console | KVM-over-VNC ou IPMI | Não — fica fora do ar até um humano desbloquear | A mais forte; ótima para uma máquina que você reinicia raramente |
| Raiz criptografada, dropbear no initramfs | SSH para a porta de desbloqueio | Não — mas você pode desbloquear de qualquer lugar | O padrão sensato |
| Volume de dados criptografado, raiz em texto plano | Script ou manual após o boot | Sim | Fraca a menos que swap, logs e temporários sejam tratados |
| Raiz criptografada, arquivo de chave no /boot em texto plano | Automático | Sim | Defende contra um drive revendido e nada além disso |
Instalando uma raiz criptografada, passo a passo
1. Inicie um instalador, não um template. Uma imagem pré-pronta não pode te dar uma raiz criptografada, porque o disco foi escrito antes de você existir como cliente. Todo plano BitVPS suporta rebuild a partir de ISO, upload de ISO personalizada e netboot, e todo plano inclui um console de emergência KVM-over-VNC — que é a parte que importa, porque você precisa acompanhar um instalador que vai fazer perguntas. Servidores dedicados expõem a mesma capacidade por meio de um endpoint IPMI protegido por VPN, com montagem de ISO e acesso à BIOS.
2. Particione com uma pequena área de boot em texto plano. Uma partição pequena para o /boot ou a partição de sistema EFI, e tudo o mais em um único container LUKS. O bootloader e o initramfs precisam ser legíveis antes que qualquer chave exista, então essa partição continua legível para quem quer que copie o disco. Projete em torno disso em vez de fingir que é diferente.
3. Crie o container. cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/vda2. LUKS2 com argon2id é todo o ponto da coisa: argon2id é memory-hard, especificado na RFC 9106, e torna um ataque de força bruta offline caro em hardware, em vez de apenas lento em software — a diferença entre uma fazenda de GPUs mastigando sua passphrase e uma fazenda de GPUs que não vale a pena apontar para isso. Mantenha o custo de memória dentro do que a máquina consegue alocar durante o boot inicial; em uma instância de 4 GB, um custo ajustado no seu laptop de 64 GB simplesmente vai falhar ao desbloquear.
4. Abra e instale. cryptsetup open /dev/vda2 cryptroot, depois LVM ou um sistema de arquivos diretamente em /dev/mapper/cryptroot, depois rode o instalador da distribuição apontado para isso, com /boot na partição em texto plano. Debian, Ubuntu, Alpine, Arch, Rocky, Fedora e FreeBSD lidam com isso; as páginas de dm-crypt da wiki do Arch são a referência mais completa, independentemente de qual distribuição você realmente roda.
5. Coloque um servidor SSH no initramfs. Instale o dropbear-initramfs, coloque sua chave pública em /etc/dropbear/initramfs/authorized_keys, e adicione um parâmetro ip= na linha de comando do kernel para que a interface suba antes do prompt de passphrase. Pule esse parâmetro e você terá construído uma máquina que inicializa até um prompt que ninguém consegue alcançar.
6. Reconstrua e reinicie. update-initramfs -u incorpora o servidor, sua chave e as configurações de rede na imagem que o bootloader carrega. Depois reinicie com o console aberto, porque a primeira tentativa é a que dá errado.
7. Desbloqueie e confirme a transição. Conecte via SSH na porta de desbloqueio e rode cryptroot-unlock. O initramfs apresenta uma host key diferente da do sistema instalado, então seu cliente vai avisar em voz alta na primeira conexão — isso é comportamento correto e um sinal útil, não um obstáculo: fixe essa fingerprint como sua própria entrada em known_hosts em vez de desligar a verificação de host key. A sessão cair é como você sabe que o sistema real assumiu.
Desbloqueio remoto, e a pergunta das 04h que ninguém faz primeiro
Rode o servidor SSH do initramfs em sua própria porta — 2222 é o convencional — para que as duas host keys nunca colidam na mesma entrada de known_hosts. Prefira um ip= estático em vez de DHCP: o initramfs é um ambiente mínimo, e um round trip de DHCP que falha te deixa com uma máquina que está ligada, inalcançável e travada em um prompt. Se você depende de IPv6, verifique se o seu initramfs realmente o configura; várias distribuições ainda sobem apenas v4 nesse estágio.
Mantenha o console como alternativa mesmo depois que o desbloqueio via SSH funcionar. A falha que você eventualmente vai encontrar não é criptográfica, é uma atualização de kernel que reconstruiu o initramfs sem a sua chave, ou um parâmetro de rede que mudou debaixo de você — e nesse momento a única rota de entrada é o console KVM-over-VNC que veio com o plano. Ter os dois não é redundância, é a diferença entre um inconveniente e uma reconstrução do zero.
Depois vem a questão operacional, que é a que você precisa resolver antes de construir qualquer coisa disso: uma raiz criptografada significa que um reboot sem supervisão deixa o seu serviço fora do ar até que um humano o desbloqueie. Manutenção de nó, um kernel panic, um evento de energia — a máquina volta para um prompt, não para a sua aplicação. Se isso for inaceitável para a carga de trabalho, não maquie o problema com um arquivo de chave na partição de boot em texto plano. Isso é uma fechadura com a chave colada na porta, e defende contra um drive revendido e nada além disso. Escolha isso deliberadamente se quiser, mas escreva no seu próprio runbook que foi essa a escolha que você fez.
Tudo o que vaza ao redor do volume criptografado
O volume raramente é onde as coisas dão errado. O que dá errado é o material que nunca chegou a entrar nele.
| Vazamento | Por que acontece | Correção |
|---|---|---|
| Swap | A memória do processo — incluindo chaves — transborda para o disco sob pressão | Swap dentro do container, ou um dispositivo de swap com chave aleatória, ou nenhum swap |
| Imagem de hibernação | Um dump completo da RAM gravado no disco por design | Desative isso em um servidor; não tem razão de estar lá |
| /boot e initramfs em texto plano | Precisam ser legíveis antes que qualquer chave exista | Aceite isso, e trate qualquer modificação como um comprometimento — verifique, ou use Secure Boot onde estiver disponível |
| Journal escrito antes da montagem | Logs do boot inicial caem na partição em texto plano | Verifique onde o seu journal realmente vive antes de o volume abrir |
| Data root do Docker | Usa /var/lib/docker por padrão, fora de um volume de dados anexado à parte | Mova para dentro, ou criptografe a raiz em vez disso |
| Monitoramento e logs fora da máquina | Agentes enviam o conteúdo de arquivos para terceiros em texto plano | Audite o que o agente envia antes de confiar no volume |
Uma propriedade que precisa ficar clara, porque é regularmente vendida além da conta: um cabeçalho LUKS se anuncia sozinho. Qualquer um que copie o disco vê que existe um container criptografado presente, qual cifra ele usa, os parâmetros do KDF e quantos slots de chave estão ocupados. O LUKS te dá confidencialidade, não negação plausível, e construir um plano que depende de ninguém notar o container é construir sobre areia.
Passphrases, arquivos de chave e cabeçalhos destacados
A passphrase é o sistema inteiro. O argon2id torna cada tentativa cara, mas caro multiplicado por um keyspace pequeno ainda é barato: cinco ou seis palavras de uma lista diceware superam uma senha de onze caracteres com substituições, por uma margem que nem é próxima. Ajuste o custo com --iter-time contra a máquina que realmente vai desbloquear o volume, não a que você está usando para digitar, e nunca reutilize uma passphrase que já chegou perto de uma conta com KYC.
Um arquivo de chave elimina a digitação e move o problema: cryptsetup luksAddKey adiciona um a um slot livre, e a única versão que vale a pena ter é a que nunca fica no servidor — guardada na sua própria máquina ou em um token de hardware e entregue ao desbloqueio durante a sessão SSH. Um cabeçalho destacado (--header) vai além: o dispositivo de dados fica indistinguível de bytes aleatórios porque os metadados vivem em outro lugar. O lado ruim disso é implacável. Perca o cabeçalho e o volume desaparece, permanentemente, sem nenhum tipo de recurso — então leve o cryptsetup luksHeaderBackup a sério e guarde esse backup em algum lugar que também esteja criptografado. A FAQ do cryptsetup oficial e a documentação do dm-crypt do kernel são as duas referências que vale a pena ler antes de você se comprometer com um layout.
E uma regra sem exceções: a passphrase nunca entra em um ticket de suporte. Nem o nosso, nem o de ninguém. Nada do que fazemos exige isso, nenhuma operação que podemos realizar em seu nome precisa disso, e um ticket é um registro escrito em um banco de dados. Se uma hospedagem algum dia pedir isso a você, ali termina a conversa.
O que a imagem de um disco realmente revela
Vamos ao caso desligado de forma concreta, porque vagueza aqui não ajuda ninguém. Um investigador com uma imagem do seu disco tem: o texto cifrado, o cabeçalho LUKS com sua cifra, parâmetros do KDF e contagem de slots, a tabela de partições, os tamanhos de tudo, e a partição de boot inteira em texto plano — seu kernel, seu initramfs e os timestamps de modificação de cada arquivo nela. Esse último item é mais informativo do que as pessoas esperam. Os horários de instalação de pacotes esboçam uma linha do tempo, e um initramfs contendo uma chave do dropbear diz algo sobre como a máquina foi administrada.
O que ele não tem é o conteúdo. Contra um container LUKS2 moderno com argon2id e uma passphrase de verdade, o ataque offline não é uma questão de esperar mais tempo — simplesmente não está na mesa. Essa é toda a proposta de valor, e é uma boa proposta.
O caso em execução é o oposto, e é curto: tudo. Não porque a criptografia falhou, mas porque a chave está residente, que é justamente a condição que faz um sistema de arquivos montado funcionar.
Os snapshots ficam no meio do caminho e surpreendem as pessoas. Nossos snapshots por hora com retenção de 7 dias são em nível de bloco, então um volume criptografado gera snapshots como texto cifrado — bom, e a consequência morde: esse snapshot também não é uma cópia que você consegue ler sem a passphrase. Perca a chave e os snapshots ficam exatamente tão irrecuperáveis quanto o original. Planeje um caminho de restauração que inclua a passphrase, ou você construiu sete dias de ruído muito confiável. O que guardamos sobre você fora do volume está escrito na política de privacidade, e publicamos semanalmente um warrant canary assinado com PGP como evidência permanente, não como promessa.
As partes que decidem o resultado não são criptográficas
Ninguém perdeu dados porque o AES-256-XTS falhou. As pessoas perdem dados porque a passphrase foi reutilizada de uma conta de exchange que tinha o passaporte delas cadastrado, porque o arquivo de chave foi deixado na partição de boot em texto plano para deixar os reboots tranquilos, porque o backup fora do local era um tarball puro, porque a passphrase está no histórico do shell do laptop delas, ou porque um agente de monitoramento estava enviando o conteúdo de arquivos para um SaaS o tempo todo.
E o silencioso: um servidor que nunca é desligado passa a vida inteira no estado em que nada disso ajuda. Uma instância com 400 dias de uptime está descriptografada há 400 dias. Se o dado é genuinamente frio — um arquivo morto, um backup de chave, registros que você consulta duas vezes por ano — mantenha-o em um container que você abre quando precisa e fecha com cryptsetup close quando termina. Dez segundos digitando convertem uma exposição permanente em uma momentânea, e essa conversão vale mais do que qualquer parâmetro que você possa passar para o luksFormat.
Já que está nisso, alinhe a jurisdição ao mesmo raciocínio. A criptografia decide o que é legível; onde a máquina está fisicamente decide quem tem o direito de pedir, e por quais alianças o pedido passa. As duas coisas não são substitutas uma da outra, e quem acerta nisso trata as duas como uma única decisão.
O que nós fornecemos, e o que não podemos fornecer
Todo plano a partir do Starter de $8.50 já vem com o que uma raiz criptografada realmente exige: virtualização KVM com root completo, a capacidade de dar boot em ISOs personalizadas e netboot, rebuild a partir de ISO pelo painel, carregamento de módulos de kernel, e um console de emergência KVM-over-VNC para o momento em que o initramfs não volta. Os níveis dedicados adicionam um endpoint IPMI protegido por VPN, com console, power cycle, montagem de ISO e acesso à BIOS. Nada na criptografia é um produto que vendemos a você — é algo que você constrói, e o nosso trabalho é não atrapalhar.
O que não podemos fazer é mais útil de declarar. Em um VPS em execução, o hypervisor consegue ler a memória do convidado; isso é arquitetura, não uma configuração de política, e nenhuma criptografia que você instale dentro do convidado muda isso. O que oferecemos contra isso não é matemática, mas postura e evidência: sem netflow, sem PCAP, sem espelhamento de NIC, IPs de sessão do painel apagados em 24 horas, sem KYC no cadastro para que a conta não seja uma alavanca, pagamento só em cripto para que o rastro de faturamento também não seja uma, e um canary semanal assinado com PGP que você mesmo pode conferir. Só o hardware dedicado remove o hypervisor da equação, e só desligar a máquina remove a RAM dela.
Se isso soa como um argumento contra o nosso próprio VPS em certos modelos de ameaça, é porque é mesmo. Preferimos vender a você a coisa certa duas vezes do que a coisa errada uma vez. Faça o deploy de uma instância com uma ISO e teste a instalação em um Starter por um mês; se a resposta acabar sendo metal, os níveis dedicados começam em $39.50 e levam de duas a quatro horas para provisionar, em vez de 41 segundos.
