Criptografia de Disco Completo em um VPS

A criptografia de disco completo responde exatamente a uma pergunta: o que um adversário obtém quando está com o seu armazenamento em mãos e a máquina está desligada? Toda outra pergunta que você possa ter — o que o provedor consegue ver, o que acontece se um servidor em execução for apreendido, se seus backups estão seguros — tem uma resposta diferente, e tratar todas como uma só é como as pessoas acabam com uma criptografia que não protege nada.

Vale ser direto sobre essa distinção, porque "criptografado com LUKS" aparece em toda página de hospedagem voltada à privacidade neste setor, a nossa inclusive. É um controle real, custa quase nada para manter, e também é o controle mais superestimado em hospedagem. Este guia cobre o que a criptografia em repouso realmente impede em um servidor alugado, os três arranjos que valem a pena implantar e os comandos para cada um, as duas configurações que de fato importam em um VPS pequeno, e o punhado de erros que transforma todo o exercício em decoração.

Contra o que a criptografia em repouso realmente protege

Criptografia em repouso significa que os bytes no meio de armazenamento são texto cifrado sempre que o volume está fechado. É uma afirmação estreita, e seu valor depende de uma única variável: onde a chave está no momento em que o adversário chega.

Leia isso como uma definição, não como uma decepção. Eliminar a classe de exposição do disco retirado vale a hora de trabalho justamente porque é a classe contra a qual você não tem nenhuma outra defesa, e a que acontece sem que ninguém esteja te visando: hardware falha e é devolvido, arrays são desativados, volumes são reatribuídos ao próximo locatário. A criptografia transforma tudo isso em um não evento.

Por que um VPS não é um laptop

Em um laptop, o design é autoevidente. Você digita uma senha na inicialização, a chave existe apenas na RAM enquanto a máquina está ligada, e desligá-la encerra a história. Um servidor não tem ninguém no console. Algo precisa fornecer a chave a cada inicialização, e cada candidato a "algo" troca disponibilidade por proteção:

• Um humano a digita. O arranjo mais forte, porque a chave nunca fica na máquina — mas o servidor não consegue voltar de uma reinicialização sem você, e você precisa de um caminho de entrada antes mesmo de o sistema operacional existir.
• A máquina a guarda. Conveniente, e na maioria das configurações caseiras, autodestrutivo: um arquivo de chave no mesmo disco virtual significa que quem tiver o disco tem a chave.
• Outra máquina a entrega. Desbloqueio vinculado à rede, geralmente Clevis com um servidor Tang. O servidor só se desbloqueia sozinho enquanto conseguir alcançar um host que você controla, o que é uma propriedade genuinamente útil — e um deslocamento de confiança, não uma eliminação dela.

Há uma segunda diferença que a maioria dos guias ignora. Em um VPS, /boot e o initramfs são texto claro, ficam em um armazenamento que o provedor, em última instância, controla, e não existe uma cadeia de boot que você possa verificar — nenhum TPM que pertença a você, nenhum boot medido, nada a atestar. Um provedor que quisesse sua senha poderia alterar o initramfs e capturá-la na próxima vez que você desbloqueasse o volume. Isso não é a descrição de nada que fazemos; é a descrição do que a arquitetura permite, que é a única forma honesta de raciocinar sobre um computador que você aluga. Nossa comparação entre VPS e dedicado percorre a mesma fronteira de confiança pelo lado do hardware, e nossa resposta honesta sobre anonimato offshore aplica a mesma disciplina ao marketing em torno do assunto.

Os três arranjos que valem a pena implantar

Não existe uma única configuração correta — existe aquela cujo modo de falha você consegue conviver. Estes três cobrem essencialmente todos os casos reais.

Comece pelo primeiro, a menos que você tenha um motivo específico para não fazê-lo. Ele entrega a maior parte da proteção por uma fração do risco operacional, e tem a única propriedade que os outros dois não têm: nada nele pode impedir o servidor de voltar a ficar on-line. O arranjo três é o único em que a senha é um fato que o provedor não consegue alcançar, em vez de uma promessa que o provedor faz, e é por isso que nossos servidores dedicados recebem o LUKS na instalação com uma senha que nunca vemos.

Criptografando um volume de dados em um VPS em execução

Este é o arranjo a buscar primeiro. Nada é reinstalado, nada no processo de boot muda, e se você cometer um erro o pior resultado é um arquivo de contêiner que você descarta. Quinze minutos em um servidor Debian ou Ubuntu ativo.

• Instale as ferramentas. apt install cryptsetup. Se o seu plano veio com um segundo dispositivo de bloco, use-o diretamente e pule a próxima etapa.
• Crie um contêiner. Em um VPS de disco único, o caminho prático é um arquivo: fallocate -l 40G /var/lib/vault.img. Ele se comporta como um disco e pode ser expandido depois.
• Formate-o como LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Aceite os padrões para a cifra; a seção abaixo cobre o único parâmetro que vale a pena ajustar em um servidor pequeno.
• Abra-o e crie um sistema de arquivos. cryptsetup open /var/lib/vault.img vault te dá /dev/mapper/vault; depois mkfs.ext4 /dev/mapper/vault e mount /dev/mapper/vault /srv/vault.
• Mova os dados que importam e depois aponte os serviços para lá. Um bind mount, ou um rsync com o serviço parado, costuma ser mais limpo do que links simbólicos — bancos de dados, em particular, não gostam de ser seguidos por aí.
• Faça backup do cabeçalho do LUKS. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, depois mova esse arquivo para fora do servidor. Alguns kilobytes corrompidos no início do contêiner destroem todos os bytes atrás deles, permanentemente, e essa é a única garantia que existe.
• Feche-o e comprove que consegue voltar a entrar. umount /srv/vault && cryptsetup close vault, depois abra-o novamente a partir das suas anotações, não da memória. Faça isso antes de haver qualquer coisa de valor lá dentro.

Depois de uma reinicialização, o cofre permanece fechado até você fazer login e abri-lo. Isso não é uma limitação para contornar com engenharia — é o objetivo inteiro. Um volume que se abre sozinho é um volume cuja chave está na máquina.

Criptografia completa da raiz com desbloqueio remoto via SSH

Quando o requisito é que nada legível sobreviva a uma apreensão com a máquina desligada — logs, histórico do shell, listas de pacotes, o formato do que você roda — o sistema de arquivos raiz também precisa estar dentro do contêiner. O problema passa a ser levar uma senha até uma máquina que ainda não inicializou, e a resposta é um pequeno servidor SSH vivendo no initramfs.

• Instale já criptografado desde o início. Inicie o instalador da distribuição por meio de upload de ISO personalizada e escolha o particionamento guiado com LVM criptografado. Converter um sistema de arquivos raiz em execução é possível, mas não vale o risco.
• Adicione o servidor SSH de pré-boot. apt install dropbear-initramfs, depois coloque sua chave pública em /etc/dropbear/initramfs/authorized_keys. Esse é um conjunto de chaves separado do seu SSH normal — use uma chave dedicada.
• Trave-o. Em /etc/dropbear/initramfs/dropbear.conf, defina DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": sem login por senha, sem encaminhamento de porta, porta própria, e um tempo limite de inatividade para que uma sessão travada não mantenha o boot aberto.
• Dê uma rede ao initramfs. Adicione um parâmetro ip= estático a GRUB_CMDLINE_LINUX em /etc/default/grub — o formato é ip=address::gateway:netmask::interface:off. Depender de DHCP nesta etapa é como as pessoas acabam trancadas para fora.
• Reconstrua e reinicie. update-initramfs -u && update-grub, depois reinicie e conecte com ssh -p 2222 root@your-server e rode cryptroot-unlock. Seu cliente vai avisar sobre uma chave de host desconhecida: o initramfs tem a sua própria, o que é esperado e vale a pena fixar em uma entrada separada de known_hosts.
• Teste o caminho de falha antes de depender dele. Instale uma atualização de kernel, reinicie, desbloqueie de novo. Atualizações de kernel regeneram o initramfs, e é exatamente nesse momento que uma configuração incorreta aparece.

As duas configurações que importam, e a armadilha do VPS pequeno

Por padrão, o LUKS2 usa AES-XTS com chave de 512 bits e derivação de chave Argon2id. Ambos estão corretos. Ajustar a cifra manualmente é uma forma de ficar mais lento e mais fraco ao mesmo tempo, e a internet está cheia de linhas de comando copiadas que fazem exatamente isso. Duas coisas, porém, merecem sua atenção.

Desempenho não é um problema, até ser

Verifique a aceleração de hardware com grep -m1 -o aes /proc/cpuinfo e meça com cryptsetup benchmark. Em qualquer CPU com AES-NI — que é o caso de todo nó que operamos — o AES-XTS processa vários gigabytes por segundo por núcleo, folgadamente acima do que um único disco virtual entrega, então o custo visível é de alguns por cento de CPU sob I/O pesado e um pequeno aumento de latência. Sem AES-NI, o quadro se inverte e a criptografia vira o gargalo; esse é o único caso em que uma cifra alternativa é uma decisão real, e não um culto à carga.

A memória do Argon2id é o que morde

O Argon2id é deliberadamente faminto por memória, e o cryptsetup o calibra no momento da formatação em relação à RAM da máquina em que você está formatando. Formate um volume em uma workstation de 32 GB, mova-o para um VPS de 1 GB, e o desbloqueio pode falhar completamente porque a memória exigida pela derivação de chave não está disponível — pior ainda dentro de um initramfs, onde há muito menos disponível do que em um sistema em execução. Em instâncias pequenas, fixe o valor: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb limita a 256 MB. Um valor menor é uma redução real na resistência a ataques de força bruta offline, então compense com uma senha mais longa.

Uma flag opcional merece uma decisão consciente, não um copiar e colar: --allow-discards repassa o TRIM para o dispositivo subjacente, o que é bom para o desgaste do SSD e o desempenho em regime permanente, e que também revela quanto do volume está em uso e aproximadamente onde. Ela vem desativada por padrão. Ative-a sabendo o que ela vaza.

Swap, logs, snapshots — as partes que as pessoas esquecem

Um cofre criptografado com texto claro vazando ao redor dele é a falha mais comum de todas, e ela permanece invisível até alguém olhar.

• Swap. Qualquer coisa na memória pode ser paginada para o disco, incluindo material que você cuidadosamente colocou no cofre. Desative o swap, ou dê a ele uma chave aleatória a cada boot com uma linha em /etc/crypttab como swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Tudo que escreve onde você não olhou. /var/log, /tmp, o diretório de dados do banco de dados, /var/lib/docker, histórico do shell, journals do systemd. Criptografar /srv/vault enquanto o PostgreSQL escreve em /var/lib/postgresql não realiza absolutamente nada. Enumere antes de criptografar.
• Snapshots. Um snapshot em nível de bloco de um volume criptografado é texto cifrado e, portanto, está tudo bem. Um snapshot que captura o estado da memória é um objeto completamente diferente e pode conter a chave. Saiba qual tipo o painel do seu provedor faz antes de usá-lo.
• Backups. O destino é o lugar errado para resolver isso. Ferramentas como restic e BorgBackup criptografam na origem, com uma chave que o destino nunca vê, e é por isso que um servidor de backup pode ser uma máquina comum em outra jurisdição, em vez de uma confiável.
• O texto claro que você já enviou para algum lugar. A criptografia em repouso não é retroativa. Qualquer coisa já copiada, enviada por e-mail ou sincronizada em outro lugar fica fora do limite que você está traçando agora.

Onde a chave vive é todo o design

Cada arranjo acima é, na verdade, uma declaração sobre a custódia da chave. Existem quatro opções, e elas não são equivalentes:

• Na sua cabeça, digitada a cada boot. Proteção máxima, atrito operacional máximo. A máquina genuinamente não pode ser lida sem você.
• Em um arquivo na máquina criptografada. Protege contra uma revenda ingênua do disco e nada mais. Se esse arquivo estiver em um /boot em texto claro, ele não protege absolutamente nada — o erro mais comum na criptografia autogerenciada.
• Em uma máquina que você controla, obtida pela rede. Clevis vinculado a um servidor Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. O servidor inicializa sem intervenção enquanto consegue alcançar sua casa, e se recusa a desbloquear em qualquer outro lugar. Excelente para frotas headless, e isso faz do host Tang a coisa que precisa ser defendida.
• Em um TPM. Significativo em hardware que você possui. Em um VPS, o TPM virtual é fornecido pelo mesmo hipervisor que você está tentando excluir, então ele resolve conveniência, não confiança.

Um teste resolve a maioria dos designs: se a máquina consegue chegar a um prompt de login sem você, a chave está na máquina. Essa pode ser uma troca perfeitamente razoável — muitas cargas de trabalho querem reinicializações sem intervenção mais do que querem resistência a um adversário determinado. Faça a escolha deliberadamente, e não descreva o resultado como algo que ele não é.

O que o seu provedor consegue ver, e onde a jurisdição assume o controle

Em um VPS, um hipervisor fica abaixo de você. Nós não lemos a memória do convidado, e não mantemos logs de tráfego, conexão ou DNS, nem rastro de console — mas essas são políticas, e a moldura honesta é que um VPS pede que você confie nelas. Em hardware dedicado não há hipervisor entre você e o silício: a criptografia de disco completo configurada na instalação, com uma senha que nunca recebemos, é uma propriedade física da máquina, não uma garantia dada por nós. Essa diferença, não a escolha da cifra, é o que você está realmente escolhendo.

É por isso que criptografia e jurisdição são duas metades de uma mesma resposta. A criptografia decide quanto vale uma cópia do seu disco; a jurisdição decide quem pode obrigar a máquina a ser apresentada, por qual processo e com que rapidez. Operamos em sete — Islândia, Suíça, Panamá, Romênia, Moldávia, Holanda e Rússia — e o raciocínio para escolher entre elas está no nosso guia de jurisdição, ou de forma mais resumida pelo seletor de jurisdição e pela página de localizações.

A parte que a criptografia não consegue tocar é a divulgação compulsória, porque ela mira em você, não no hardware. Reino Unido, França e Austrália estão entre os países cuja lei pode exigir que uma pessoa apresente uma chave de decriptografia ou enfrente uma penalidade por se recusar. Essa exposição segue para onde você está, não para onde o servidor está, e nenhuma configuração na máquina muda isso. Cadastrar-se sem documentos de identidade limita, desde o início, o quanto de rastro em papel existe — a razão prática e nada glamorosa pela qual hospedagem sem KYC e criptografia acabam na mesma conversa — mas não é uma defesa contra um tribunal que já tem o seu nome.

Nove erros que transformam a criptografia em decoração

• Desbloqueio automático a partir de um arquivo de chave no mesmo disco. A maioria dos servidores "criptografados", e o equivalente a deixar a chave na fechadura.
• Criptografar um volume que os dados sensíveis nunca alcançam. O cofre está vazio e o banco de dados não está nele.
• Nunca fazer backup do cabeçalho do LUKS. Um setor danificado no início do contêiner e cada byte atrás dele se perde para sempre.
• Nunca testar o caminho de desbloqueio. Aí uma atualização de kernel regenera o initramfs e a próxima reinicialização vira uma operação de resgate.
• Formatar em uma máquina grande e desbloquear em uma pequena. O Argon2id pede uma memória que o VPS não consegue fornecer, e o volume não abre.
• Escolher uma senha como se fosse uma senha de login. Nada limita a taxa de um ataque offline, exceto a função de derivação de chave. É o comprimento que compra tempo.
• Migrar texto claro para dentro da criptografia e presumir que o original sumiu. Em armazenamento virtualizado, sobrescrever não apaga de forma confiável.
• Enviar a senha pelo mesmo canal usado para administrar a máquina. O OpSec de servidor cobre o problema de correlação que isso cria.
• Confundir a criptografia do seu provedor com a sua própria. "Toda a infraestrutura é criptografada em repouso" — a nossa inclusive — protege a infraestrutura. Só uma chave que você guarda te protege da infraestrutura.

Então vale a pena fazer isso em um VPS?

Sim, com expectativas calibradas. Por uma hora de trabalho e sem custo operacional mensurável, um volume de dados criptografado elimina uma classe inteira de exposição que você não conseguiria resolver de outra forma, e a elimina permanentemente: hardware aposentado, armazenamento reatribuído, uma máquina desligada sob a custódia de outra pessoa. Faça pelo menos isso em todo servidor que guarde algo que importa, logo depois da checklist de blindagem da primeira hora.

O que isso não faz é transformar um computador alugado no seu computador. Se o seu modelo de ameaça tem o próprio provedor como adversário, nenhuma cifra resolve isso — a resposta é o hardware dedicado, onde a chave é digitada via IPMI e nunca passa por um hipervisor, uma jurisdição escolhida de propósito, e a disciplina de não colocar em nenhum servidor o que não precisa estar lá. Ajustar o controle à ameaça real é a diferença entre privacidade e a aparência dela.