"VPS criptografado" é uma expressão que muitos hosts jogam por aí sem dizer contra o que protege. Preferimos ser diretos, porque quem se importa com isso se importa com exatidão. Você pode rodar armazenamento criptografado num VPS — um volume de dados criptografado com LUKS que você destrava com uma frase-senha — e ele protege seus dados de verdade em repouso. O que não faz é tornar um servidor em execução invisível para quem controla o hardware físico. Aqui vai a forma honesta disso, e como configurar.
O que a criptografia num VPS faz — e não faz
O que é real: um volume LUKS é texto cifrado quando está travado. Desligue o servidor, ou simplesmente não destrave o volume, e os arquivos são ilegíveis sem sua frase-senha. Um disco desativado, imageado a frio ou apreendido desligado não entrega nada legível. É uma proteção genuína e valiosa — e é a ameaça comum para a maioria (um disco aposentado, um snapshot a frio, acesso casual).
O que não é: enquanto o volume está montado e o servidor roda, a chave de criptografia está na RAM, e o provedor opera o hipervisor sob sua VM. Criptografia de disco completo em qualquer VPS — o nosso ou o de qualquer um — não pode proteger um volume rodando e destravado de um operador determinado da máquina física. Qualquer host prometendo o contrário está vendendo demais. Nós não.
Então: proteção real em repouso, limites honestos ao vivo. Essa troca vale a pena para um repositório de dados privado que você mantém ilegível ocioso — junto com cadastro sem KYC para que o repositório nem seja atrelado à sua identidade de início.
Configure um volume criptografado LUKS (Ubuntu 24.04)
# encrypt a data file/volume with LUKS; keep the passphrase OFF the server
apt update && apt install -y cryptsetup
# create a 20 GB encrypted container (or point at a raw data disk)
fallocate -l 20G /srv/secure.img
cryptsetup luksFormat /srv/secure.img # sets your passphrase
cryptsetup luksOpen /srv/secure.img secure # unlock → /dev/mapper/secure
mkfs.ext4 /dev/mapper/secure
mkdir -p /mnt/secure && mount /dev/mapper/secure /mnt/secure
# your files live in /mnt/secure — ciphertext once closed
Após um reboot o volume fica travado até você mesmo destravá-lo:
cryptsetup luksOpen /srv/secure.img secure # enter passphrase over SSH
mount /dev/mapper/secure /mnt/secure
Nunca armazene a frase-senha no servidor. Destrave manualmente (ou canalize-a pela sua sessão SSH) para que a chave só exista na memória enquanto você a usa. Não a coloque num script de boot — isso derrota o propósito.
Escopo honesto, mais uma vez
- Protege: dados em repouso — desligado, antes de destravar, snapshot a frio, disco aposentado.
- Não protege: um volume rodando e destravado de alguém com controle físico/de hipervisor.
- Não é anonimato por si só: seu servidor ainda tem um IP público e tráfego no fio. Isto trata de confidencialidade de dados em repouso, combinada com cobrança sem KYC.
Se seu modelo de ameaça é pressão legal em vez de um disco roubado, o sinal mais significativo é nosso warrant canary — uma declaração datada de que não tivemos ordens secretas ou exigências de enfraquecer a segurança, mantida atual. Um canary que você pode observar vence um selo de criptografia que você não pode verificar. Veja também a análise honesta do VPS anônimo sobre o que o sem-KYC te dá e não te dá.
Por que EQVPS para armazenamento criptografado
- Root completo, então LUKS e seu fluxo de destravamento são inteiramente seus — sem custódia de chave do provedor, sem frase-senha armazenada no boot a menos que você escolha.
- Sem KYC, pagamento em cripto. E-mail para registrar, USDC/USDT para pagar — o repositório não está soldado à sua identidade.
- UE (Alemanha, Finlândia), lei real de proteção de dados, um warrant canary público, root em ~60 segundos.
VPS anônimo, sem KYC — a versão honesta → · Auto-hospedar Vaultwarden (cofre criptografado) →
Comentários
Nenhum comentário ainda. Seja o primeiro.