Hospedagem VPS criptografadaA criptografia em repouso protege uma máquina que está desligada.

Três estados, e aquele que o setor não vende

Os dados são descritos como estando em um de três estados, e essa distinção é o assunto inteiro desta página. Em repouso é um disco que ninguém está lendo. Em trânsito é um pacote em um fio. Em uso é um processo mantendo o texto claro na memória para poder fazer algo com ele.

As duas primeiras estão resolvidas, e todo provedor as vende. O fio é TLS, e os pratos por baixo de você quase certamente estão criptografados. Muito pouco se diz sobre a terceira, porque é onde o provedor está posicionado: um servidor em execução tem o volume desbloqueado, a chave residente, e os dados em claro. Isso não é uma falha na criptografia. É isso que significa estar em execução.

O que “criptografado em repouso” significa quando um host diz isso

A criptografia em repouso do lado do provedor é real e vale a pena ter. Significa que o drive, o array ou o repositório de snapshots está criptografado sob uma chave que o provedor gerencia, de modo que um disco que sai do prédio — com falha, substituído, revendido, roubado — é um tijolo, e não uma cópia do seu banco de dados. Toda plataforma séria faz isso, e não custa nada a você.

O que ela não consegue fazer é excluir o provedor, porque o provedor guarda a chave por definição. É um controle contra a doca de carregamento, não contra o operador. Um host que responde a uma pergunta sobre seu próprio acesso descrevendo criptografia em repouso respondeu a uma pergunta diferente, e geralmente sabe disso.

A versão que de fato exclui o provedor é aquela em que a chave nunca chega. A troca está registrada no runbook correspondente: os snapshots aqui são armazenados criptografados, esta estrutura não guarda nenhuma chave para o conteúdo de um disco que você mesmo criptografou, e por isso também não consegue resgatar esse disco para você. As duas metades dessa frase são o mesmo fato, e um host que oferece apenas a primeira metade está guardando uma chave.

Três máquinas, três respostas diferentes

“Meu host consegue ler o meu disco” tem respostas diferentes em uma instância compartilhada, em uma máquina inteira e em um gabinete que você aluga por unidade. Vale a pena expor essas diferenças, porque normalmente são vendidas como o mesmo produto, com números diferentes ao lado.

Nenhuma dessas linhas é um argumento contra o produto que está acima dela. São um argumento a favor de saber contra qual ameaça você está comprando proteção. Um operador que roda o hipervisor consegue ler a memória de um convidado em execução nele, e um provedor que afirme o contrário mal-entendeu o próprio stack. O que ele lê é seus dados ou é ruído, e qual dos dois foi decidido meses antes, pelo lugar onde você colocou a chave.

A cerimônia da chave é a garantia inteira

Tudo o que foi dito acima se reduz a uma única questão operacional: no momento em que a máquina inicializa, de onde vem a chave? Existem três respostas em uso, e elas estão longe de ter a mesma força.

1. Guardada na máquina. Um arquivo de chave no mesmo volume, ou uma senha embutida em um script de provisionamento, para que o servidor possa inicializar sem supervisão. Isto é criptografia como item de checklist: quem conseguir ler o disco consegue ler a chave deitada ao lado dele.
2. Mantida pelo provedor. Conveniente, recuperável, e exatamente o arranjo sobre o qual uma ordem judicial pode agir. A chave existe, alguém a guarda, e guardá-la é algo que um tribunal pode determinar em um instrumento.
3. Fornecida por você a cada inicialização. A máquina inicializa em um initramfs e não faz absolutamente nada até que você se conecte e entregue a senha a ela. A chave existe na memória dessa máquina, somente enquanto ela roda, e em nenhum outro lugar do mundo.

Somente o terceiro tira a questão do registro jurídico. Uma ordem pode obrigar um provedor a produzir o que ele guarda; não pode obrigá-lo a produzir uma chave que nunca lhe foi dada. Essa é uma diferença de natureza, não de grau, e é por isso que o warrant canary assinado aqui traz uma alegação separada sobre o enfraquecimento obrigatório de uma proteção criptográfica. Uma promessa sobre comportamento e um fato sobre aritmética são instrumentos diferentes, e só um deles sobrevive à pessoa que o fez.

O que a criptografia de disco completo ainda deixa em claro

Um sistema de arquivos raiz criptografado não é uma caixa opaca. Várias coisas ficam fora dele por construção, e saber quais são é a diferença entre um modelo de ameaça e uma sensação.

• A cadeia de boot. /boot e o initramfs são lidos antes que qualquer coisa possa ser decriptografada, então ficam não criptografados e, em hardware alugado cujo firmware você não pode atestar, não verificados. Quem conseguir escrever ali pode escrever algo que guarde sua senha.
• Swap e hibernação. Um swap não criptografado vai guardar páginas de memória decriptografada sem reclamar. Criptografe-o ou desligue-o; não existe uma terceira opção segura.
• O formato da máquina. Tamanhos de partição, o cabeçalho LUKS, quanto do volume está em uso, e o simples fato de que ela está criptografada.
• Tudo o que o processo em execução mantém. O banco de dados no cache de página, a chave privada TLS que o servidor web carregou na inicialização, as variáveis de ambiente, os sockets abertos. Esta é a maior categoria da lista, e a criptografia em repouso não toca em nada disso.
• Seu tráfego. Com quem você fala, quando e quanto, exatamente como antes. Esse é o assunto do guia sem logs, não deste aqui.

A cadeia de boot é o item que as pessoas subestimam. Se o initramfs é onde você digita a senha, o initramfs agora é um prompt de credencial em uma máquina que você não controla fisicamente — então a impressão digital da sua chave de host SSH importa tanto quanto a senha. É uma chave diferente da que o sistema em execução apresenta, e é exatamente por isso que uma impressão digital alterada na inicialização passa despercebida. Registre-a na primeira vez e confira-a todas as vezes. Um prompt que parece certo e não é: esse é o ataque inteiro.

O que ela impede, e o que não impede

Leia a coluna do meio, de cima a baixo. A criptografia é decisiva exatamente nos casos em que a máquina está desligada ou a chave nunca foi entregue, e irrelevante em todo caso em que a máquina está em execução e alguém já está dentro dela. Isso não é uma fraqueza a ser contornada com engenharia. É o que a criptografia é, e uma página que sugere o contrário está vendendo alguma coisa.

O custo, declarado antes de você se comprometer com ele

Esta é a seção que páginas anunciando “hospedagem criptografada” não têm, e o motivo é que todo item nela é um inconveniente real que você vai encontrar dentro de um mês.

• Nenhuma reinicialização sem supervisão. Uma atualização de kernel, um evento de energia ou uma migração de host deixam a máquina parada em um prompt de senha até que um humano apareça. A disponibilidade agora é uma função do seu horário de sono.
• Nenhum resgate. Um provedor que não consegue ler o volume não consegue repará-lo. Verificações de sistema de arquivos, recuperação de dados e “você poderia só copiar a configuração de lá” passam a ser só seus.
• Backups são texto cifrado. O que está correto, e significa que uma restauração também precisa da chave. Um backup que você não consegue abrir não é um backup.
• Um cabeçalho danificado é fatal. O cabeçalho LUKS guarda a chave mestra encapsulada em uma pequena região no início do volume. Copie-o para fora da máquina logo no primeiro dia; sem ele, nem uma senha correta abre coisa alguma.
• Algum overhead. Real, visível em um benchmark, e raramente o fator limitante em uma carga de trabalho — todo processador atual faz AES em hardware. Meça isso na máquina que você alugou, em vez de discutir sobre o assunto.

Configurar de modo que valha a pena

Os comandos estão na base de conhecimento. O que vem a seguir é a ordem em que executá-los, que é a parte que não é um comando.

1. Providencie o acesso ao console antes de começar, não depois. O primeiro erro acontece no prompt de boot, e o SSH é exatamente o que não está disponível ali.
2. Criptografe um segundo volume primeiro. Dados em um disco criptografado separado já garantem a maior parte do benefício por uma fração do risco operacional, e isso ensina os modos de falha em uma máquina que ainda inicializa sozinha.
3. Só mova o sistema de arquivos raiz para trás dela quando isso já for rotina, com um pequeno servidor SSH no initramfs para receber a senha na inicialização.
4. Registre a impressão digital da chave de host do initramfs no primeiro desbloqueio, e verifique-a em todos os seguintes. Não é a mesma chave que o sistema em execução apresenta, e tratar uma mudança como normal é exatamente como uma senha acaba sendo capturada.
5. Faça backup do cabeçalho LUKS para um local que não seja essa máquina, e depois prove que o backup abre o volume, em vez de simplesmente supor isso.
6. Criptografe ou desative o swap, e depois verifique o que você realmente construiu: lsblk -o NAME,FSTYPE,MOUNTPOINT mostra o que está atrás do mapper e o que silenciosamente não está.
7. Reinicialize-a uma vez, deliberadamente, antes que haja nela qualquer coisa que fizesse falta. A primeira reinicialização sem supervisão, às três da manhã, não é o momento de aprender o procedimento.

Como verificar a alegação de criptografia de um host em dez minutos

O mesmo teste de sempre nesta prateleira: cada pergunta abaixo tem um documento como resposta, ou não tem nenhuma.

1. O que está sendo criptografado é a plataforma, o volume ou o convidado — e qual desses era aquele sobre o qual você perguntou?
2. Quem gera a chave, onde ela vive, e qual é o procedimento quando um cliente a perde? Um caminho de recuperação é uma segunda chave, e uma segunda chave é uma segunda coisa cuja produção pode ser ordenada.
3. Você pode trazer sua própria chave e se recusar a compartilhá-la? Se a resposta for sim, pergunte o que deixa de funcionar. Se nada deixar de funcionar, a criptografia não estava fazendo nada.
4. Existe um console que funciona quando a máquina não inicializa, e ele está incluído ou é cobrado por hora?
5. O que o provedor diz que não consegue mais fazer depois que você criptografa? Um host que alega ao mesmo tempo privacidade perfeita e suporte completo não pensou bem no assunto, ou está descrevendo uma chave que ele guarda.

O último é o sinal revelador. Toda resposta honesta nesta área custa alguma coisa ao provedor, e uma alegação que não custa nada está descrevendo um produto, não uma garantia. O que esta estrutura fará e não fará está exposto no guia para autoridades e contabilizado no relatório de transparência.

Perguntas que as pessoas realmente fazem

Todos os preços desta estrutura são publicados por completo, em um só lugar. Veja o catálogo completo