Criptografia de disco em uma máquina de terceiros

Todo provedor que vende privacidade diz que os discos são criptografados. Isso costuma ser verdade, e costuma responder a uma pergunta que ninguém fez. A criptografia tem três estados a considerar, e um servidor passa toda a sua vida útil justamente naquele que a criptografia de disco completo não cobre. É aqui que a linha realmente cai, o que fica de cada lado dela, e qual dos dois arranjos vendidos sob as mesmas quatro palavras é aquele em que a chave permanece com o cliente.

Três estados, e o único que ninguém criptografa

Costuma-se descrever os dados como estando em um de três estados, e o setor resolveu de forma convincente dois deles. Em repouso é o dado que está em um disco que no momento ninguém está lendo: resolvido pela criptografia de disco completo, e por camadas adicionais de criptografia em bancos de dados ou armazenamento de objetos. Em trânsito é o dado atravessando uma rede: resolvido pelo TLS, e tão bem resolvido que um certificado emitido por engano já vira notícia. Em uso é o dado carregado na memória de um processo em execução — que é onde cada byte servido pelo servidor precisa estar, ainda que por um instante, para poder ser entregue.

A expressão criptografia em repouso é exata, e é exata de um jeito fácil de não perceber. Ela descreve o estado dos dados enquanto a máquina está desligada. Um servidor é uma máquina cujo trabalho inteiro é nunca estar desligada. Durante os meses em que fica em funcionamento, seus volumes estão abertos, os arquivos do banco de dados podem ser lidos por qualquer processo rodando com o usuário certo, e a criptografia não faz nada além de esperar uma queda de energia.

A segunda coisa que essas quatro palavras escondem é de quem é a chave. Dois arranjos completamente diferentes são vendidos sob o mesmo rótulo. Um provedor pode criptografar a camada de armazenamento com chaves que ele mesmo administra: isso protege o processo de descarte do provedor e reduz sua própria exposição a vazamentos, e protege de fato contra um disco que sai do prédio — mas quem detém a chave é justamente a parte sobre a qual a pergunta era feita. Ou o volume pode ser criptografado dentro da própria máquina, com uma chave que não existe em lugar nenhum além da cabeça do responsável e da memória de um kernel em execução. Só o segundo arranjo muda o que um terceiro consegue obter, e só o segundo é o que o restante deste guia tem em mente.

Nada disso é um argumento contra criptografar discos. É um argumento a favor de saber quais dos oito cenários a seguir estão cobertos e quais não estão. Uma criptografia que impede uma coisa real vale a pena; uma criptografia que se acredita impedir oito é pior do que nenhuma, porque essa crença encerra a conversa.

Onde fica a chave enquanto a máquina está em execução

Ao destravar um volume LUKS, a senha digitada não é a chave. Ela desbloqueia uma chave-mestra guardada no cabeçalho do volume, e essa chave-mestra fica então retida na memória do kernel até o volume ser fechado ou a máquina perder energia. Toda leitura e toda escrita passam por ela. Não existe configuração de um disco criptografado funcional em que a chave esteja em outro lugar enquanto o disco está em uso — isso não é um detalhe de implementação que se possa corrigir, é o que significa usar um disco criptografado.

No hardware próprio, essa memória fica dentro de um gabinete em uma sala sob controle direto, e o ataque contra ela é exótico: presença física, e os segundos de resíduo que os chips de memória retêm depois que a energia é cortada. Em um servidor virtual a situação muda de natureza, não só de grau. A memória do kernel é uma região da memória do host. O hypervisor consegue endereçá-la por definição, porque endereçá-la é justamente como ele a entregou ao cliente em primeiro lugar. Três operações inteiramente comuns a leem:

• Uma live migration. Mover uma máquina virtual em execução entre hosts físicos copia sua memória enquanto ela roda. Isso é um recurso — é assim que um host recebe manutenção sem que o cliente precise reiniciar — e a chave-mestra está entre as páginas copiadas.
• Um snapshot que inclui memória. Um snapshot apenas do disco, de um volume que o próprio cliente criptografou, contém somente texto cifrado e nada além disso. Já um snapshot que permite retomar a máquina exatamente de onde parou contém a chave, porque a chave faz parte do que significa estar exatamente onde estava.
• Um memory dump. A memória da instância convidada vive dentro do espaço de endereçamento de um processo no host. Ler a memória desse processo é uma operação de depuração rotineira, e as ferramentas para isso já vêm junto da pilha de virtualização, sem precisar ser contrabandeadas.

Nada disso afirma que o provedor faz alguma dessas coisas. Afirma que essas ações não exigem nenhuma cooperação do cliente, não deixam rastro em nada que ele possa ver, e são indistinguíveis da manutenção normal da plataforma. Essa é a única propriedade que vale a pena registrar em um modelo de ameaças: não o que alguém está fazendo, mas o que essa pessoa é capaz de fazer sem que ninguém perceba. O mesmo raciocínio, uma camada acima, é o motivo pelo qual o registro de imagens e o proxy à frente da máquina pertencem à mesma lista que o host.

O problema da reinicialização, e o atalho que o desfaz

Um volume raiz criptografado precisa ser destravado antes que o sistema avance o suficiente no boot para aceitar uma conexão SSH. Em um notebook, a senha é digitada no próprio teclado. Em uma máquina a dois mil quilômetros de distância, em um prédio onde ninguém da equipe jamais pôs os pés, não há teclado algum ao alcance no momento em que ele é necessário. Toda resposta prática a isso é uma troca — e uma das quatro opções a seguir não é uma troca de verdade, mas um jeito de parecer que uma foi feita.

Quatro formas de desbloquear um volume raiz criptografado em uma máquina remota

Método	Reinicialização sem intervenção	Impede um disco roubado	O que isso custa
SSH na imagem de boot	Não	Sim	Um servidor SSH mínimo dentro do initramfs permite conectar e digitar a senha. A máquina fica fora do ar até alguém acordado e alcançável perceber. Essa é a opção honesta, e o custo é real: uma reinicialização às quatro da manhã vira uma interrupção até alguém notar.
Chave vinculada à rede	Sim	Parcialmente	A máquina busca sua chave de destravamento no boot junto a um servidor mantido separadamente, e é possível recusar entregar a chave a uma máquina que mudou de lugar ou que ninguém mandou reiniciar. Esse servidor de chaves precisa ficar sempre no ar, e precisa estar em algum lugar que a mesma ordem judicial não alcance — senão a chave só foi dividida entre duas portas com uma única fechadura.
Arquivo de chave na imagem de boot	Sim	Não	A chave fica no initramfs, o initramfs fica em uma partição de boot sem criptografia, e essa partição fica no mesmo disco que se queria proteger. Quem leva o disco leva a chave junto. Essa configuração é comum, inicializa perfeitamente, e não defende absolutamente nada.
Selada em um TPM	Sim	Parcialmente	Em hardware próprio, um chip de segurança de verdade só libera a chave para uma cadeia de boot que não foi alterada. Em um servidor virtual esse chip é emulado pelo próprio host, então selar uma chave nele entrega a chave justamente à parte de quem se queria protegê-la.

A terceira linha merece um olhar mais demorado. É onde se acaba quando o requisito foi escrito como os discos devem ser criptografados e ninguém perguntou para quê. A auditoria passa. O dispositivo de bloco está de fato criptografado. A chave viaja no mesmo pedaço de metal, em um arquivo que um shell de recuperação lê em uns quatro segundos.

Essa é também a diferença prática mais clara entre uma máquina virtual alugada e uma máquina própria. Em hardware dedicado a interface de gerenciamento fora de banda oferece um console que sobrevive a uma reinicialização, então a primeira linha deixa de ser uma interrupção e vira um transtorno de dois minutos — e o problema do chip emulado da quarta linha desaparece, porque o chip está soldado numa placa, e não escrito em software pela mesma parte contra a qual se está tentando se proteger.

O que a criptografia de disco completo realmente compra

A mesma pergunta, feita de oito jeitos diferentes. A coluna que importa é a última, porque em toda linha em que a criptografia não ajuda, alguma outra coisa ajuda — e nomear essa outra coisa é todo o valor do exercício.

Oito cenários, e se a criptografia de disco completo muda o resultado

Cenário	A criptografia ajuda	O que realmente decide
Um disco é desativado, revendido ou devolvido em garantia	Sim	Nada mais cobre esse caso. Discos saem de data centers o tempo todo, a sanitização é um processo, e processos falham em silêncio. Este é exatamente o cenário para o qual a criptografia de disco completo foi criada, e contra ele funciona tal como prometido.
A máquina é desligada e o disco é removido	Sim	A mesma proteção, com o mesmo limite, e o limite é a palavra desligada. Uma máquina levada enquanto está em funcionamento é uma máquina levada destravada, com os volumes abertos e a chave residente.
Uma cópia de backup fica em outro lugar	Parcialmente	A criptografia no volume de origem não faz nada por uma cópia dos dados. O que decide é se o backup foi criptografado antes de sair, com uma chave que não fica guardada na máquina que está sendo copiada.
A plataforma tira um snapshot	Parcialmente	Um snapshot apenas do disco, de um volume criptografado pelo próprio cliente, é texto cifrado e inútil para quem não tem a senha. Um snapshot que também captura o estado da memória captura a chave junto. Os dois são chamados de snapshot.
Alguém obtém um shell na máquina em funcionamento	Não	O volume já está aberto, e um invasor lê arquivos em vez de blocos brutos. Aplicação de patches, privilégio mínimo, e credenciais que não são reaproveitadas entre serviços é o que decide essa linha, e a criptografia não contribui em nada aqui.
O operador do host, ou quem tiver acesso dele	Não	Só ajuda uma criptografia cuja chave nunca chega a entrar na máquina. A criptografia de memória em hardware é a única exceção, e vem desligada por padrão em praticamente todo lugar, o que é tratado na próxima seção.
Uma ordem é apresentada ao provedor	Parcialmente	A jurisdição decide quem pode pedir e sob qual justificativa; a criptografia decide o que uma resposta pode conter. Nossa própria posição publicada tem duas frases separadas, e ambas importam: não guardamos as chaves de criptografia dos clientes e não podemos produzi-las, e um volume sem criptografia em um servidor virtual ainda exige uma ordem que nomeie esse serviço especificamente.
É preciso divulgar uma violação de dados	Parcialmente	Se os usuários estão na UE, o Artigo 32 do RGPD cita nomeadamente a criptografia entre as medidas esperadas, e o Artigo 34 dispensa o dever de notificar os titulares dos dados — nunca a autoridade de controle — quando os dados foram tornados ininteligíveis. Se isso se aplica depende inteiramente de onde a chave estava quando os dados saíram.

Acima do disco: o que sobrevive a um host hostil

Tudo até aqui diz respeito a uma camada que para no dispositivo de bloco. Três coisas ficam acima dela, e juntas são as únicas respostas para a quinta, a sexta e a sétima linha daquela tabela.

Criptografar acima da aplicação, não por baixo dela

Criptografia em nível de campo significa que a própria aplicação criptografa um valor antes de ele chegar ao banco de dados, e o descriptografa depois de lê-lo de volta. Um dump do banco de dados resulta em texto cifrado, não importa quem tenha feito o dump nem por qual caminho. O custo é perder a capacidade de buscar ou indexar as colunas criptografadas, e é por isso que essa técnica cabe nos poucos campos que merecem — corpo de mensagens, documentos enviados, tokens de terceiros — e não em tudo. O fim desse caminho é o end-to-end: a chave pertence ao usuário, o servidor nunca guarda o texto em claro, e um host hostil não obtém nada porque não há nada ali para obter. É a única arquitetura desta página genuinamente indiferente a quem opera o hardware, e é uma decisão de produto muito antes de ser uma decisão de infraestrutura.

Backups são uma decisão separada, não uma consequência

A forma mais comum de dados saírem de uma máquina criptografada é um backup. Um snapshot enviado para um object storage, um dump do banco sincronizado com um segundo provedor, um arquivo baixado para uma estação de trabalho — nenhum deles herda absolutamente nada do volume de origem. Criptografe no momento em que o dado é gravado no backup, com uma chave guardada em algum lugar que a própria máquina não alcança, para que um servidor comprometido não consiga descriptografar seu próprio histórico. Depois, restaure um backup, em uma máquina diferente, antes que seja realmente necessário: um backup criptografado que não pode ser aberto é uma forma incomumente organizada de perder tudo de uma vez. Uma cópia em outro país também é uma cópia sob outro conjunto de regras — uma segunda jurisdição escolhida sem perceber.

Criptografia de memória, e por que normalmente não está disponível

O estado que ninguém criptografa tem, sim, uma resposta em hardware. Extensões de computação confidencial — o SEV-SNP da AMD, o TDX da Intel — criptografam a memória e o estado dos registradores da instância convidada sob uma chave mantida por um processador de segurança separado, e não pelo hypervisor, de modo que um host que copia essa memória recebe de volta apenas texto cifrado. É um recurso real e já disponível. Também é estreito: o SEV-SNP exige silício EPYC de terceira geração ou mais recente, o host precisa ser configurado deliberadamente para isso, e a instância convidada precisa atestar que o recebeu. Praticamente nenhum servidor virtual de uso geral oferece esse recurso, e nenhum o oferece silenciosamente. A premissa correta é presumir que ele não está disponível, a menos que um provedor afirme por escrito que está, e explique como verificar essa atestação por conta própria.

Uma configuração honesta sobre seus limites

Nada disso termina em não vale a pena se preocupar. Termina em uma configuração cujos limites podem ser declarados em voz alta sem constrangimento.

1. Escreva o único cenário contra o qual a defesa está sendo montada (5 min). Um disco desativado, uma máquina apreendida em funcionamento, um host hostil, uma ordem judicial, uma violação que precisa ser divulgada. Cada um tem uma resposta diferente, e uma configuração voltada para os cinco ao mesmo tempo, de forma confiável, não atende nenhum deles.
2. Coloque a criptografia onde estiver a chave (decisão). Se o provedor guarda a chave, o que se comprou foi proteção contra um disco que sai do prédio, e nada além disso. Para ir além, o volume precisa ser destravado de dentro da própria instância, pelo responsável, com algo que a plataforma nunca vê.
3. Criptografe o volume de dados, e não a raiz (configuração). Uma raiz criptografada significa que toda reinicialização espera por alguém. Um volume criptografado separado, guardando o diretório do banco de dados, os uploads e os segredos, permite que a máquina volte sozinha enquanto a parte sensível permanece fechada até ser destravada. Esse é o meio-termo que a maioria das pequenas plataformas deveria adotar, e quase ninguém registra essa decisão.
4. Nunca deixe o arquivo de chave na partição de boot sem criptografia (regra). Se a máquina inicializa sem intervenção, sem servidor de chaves e sem console, a chave está no disco; não existe uma terceira possibilidade. Essa é uma troca razoável quando um disco roubado é de fato todo o modelo de ameaças, e é autoengano em qualquer outro caso.
5. Criptografe os backups no momento em que são gravados, com uma chave guardada em outro lugar (configuração). Depois, restaure um deles em uma máquina diferente, em um dia em que nada esteja pegando fogo.
6. Diga, em uma única frase, o que está coberto (5 min). Algo perto de: um invasor que retira este disco do rack não obtém nada, e qualquer um com root na máquina em funcionamento ou no host dela obtém tudo. Se essa frase é desconfortável de escrever, é porque ela é verdadeira.

Dois desses seis pontos são decisões e quatro são configuração. As decisões levam uma tarde e a configuração leva uma hora, e a hora não vale nada sem a tarde. Fazer na ordem contrária é como se acaba na terceira linha da primeira tabela, com uma máquina que passa na auditoria e não protege ninguém.

Qual cenário está sendo defendido é antes uma pergunta de modelagem de ameaças do que uma pergunta de criptografia, e a versão de uma hora desse exercício produz a frase do sexto passo quase como subproduto. Se a resposta acabar sendo uma ordem judicial em vez de um disco, a camada que decide o resultado não está no disco nenhum — está em qual lei alcança o provedor, e como verificar isso antes de confiar.

Escrito pelos engenheiros que operam a plataforma, e revisado em hoje. Se algo aqui estiver errado ou desatualizado, informe pelo painel — foi de lá que veio cerca de metade destes conteúdos.