Por que criptografar no app, não só em repouso

Um tipo novo de pergunta sobre migrations

Todo curso de migrations até aqui perguntou como as tabelas se relacionam, quão segura é uma operação numa tabela em uso ou como ordenar várias mudanças. Este curso pergunta outra coisa. A questão não é o formato de uma coluna nem com o que ela se relaciona. É o que é seguro guardar nela como texto simples, e o que muda quando a resposta é "nada".

Duas coisas diferentes chamadas "criptografia"

Muitos ambientes de hospedagem criptografam em repouso o disco do banco, e o disco físico não pode ser lido sem a chave dele. Isso protege contra um cenário: alguém roubar o disco, ou um arquivo de backup, sem as credenciais para usá-lo. Ela não faz nada contra os outros jeitos de os dados vazarem. Pense numa senha do banco vazada, num SELECT * amplo demais numa ferramenta de suporte, num pg_dump mandado para a pessoa errada ou numa conta de admin comprometida. Cada um desses entrega texto legível, porque a criptografia de disco mora abaixo do banco. O PostgreSQL nunca sabe que ela existe, e ninguém que consiga entrar e rodar uma consulta sabe.

ActiveRecord::Encryption, o assunto deste curso, trabalha em outra camada: dentro da aplicação Rails, antes de um valor ser escrito e depois de ser lido. Uma coluna criptografada desse jeito guarda um texto cifrado que o PostgreSQL não consegue ler, porque quem guarda a chave é o Rails, e não o banco. Quem tem uma conexão ativa ao banco e um SELECT simples vê bytes ilegíveis. Vale para um atacante, uma ferramenta interna descuidada ou uma réplica de leitura com acesso demais. O modelo de ameaça passa de "alguém roubou o hardware" para "alguém tem acesso comum de leitura a dados que nunca deveria ver".

O que este app poderia criptografar

Nenhum model deste app chama encrypts hoje. O model Partners::Inquiry, com email, company, contact_name, message e notes, tem o formato de dado para o qual este curso existe. São dados de contato de uma pessoa real, enviados por um formulário público. As aulas seguintes usam as colunas de Partners::Inquiry como o exemplo de como a criptografia ficaria.

Uma coluna nunca aparece neste curso: Identity::User#password_digest. Ela já é protegida por has_secure_password com BCrypt, um hash de mão única que nunca deve ser lido de volta. A criptografia supõe o contrário, um valor que precisa ser recuperado e usado depois. Criptografar uma senha que já passou por hash resolveria um problema que essa coluna não tem.

Pontos-chave

• A criptografia de disco em repouso protege contra o roubo do disco ou de um arquivo de backup. Ela não faz nada quando alguém tem uma conexão comum e autenticada com o banco, porque o PostgreSQL nunca sabe que ela existe.
• ActiveRecord::Encryption trabalha uma camada acima, dentro do app Rails, então um SELECT ao vivo no banco devolve texto cifrado em vez de texto simples.
• Nenhum model deste app chama encrypts hoje. Partners::Inquiry (email, company, contact_name, message, notes) é o exemplo deste curso para o tipo de dado a que o recurso se destina.
• Criptografia e hash resolvem problemas diferentes. Identity::User#password_digest (BCrypt, mão única) fica fora do escopo, porque um valor que nunca deve ser lido de volta não precisa de um recurso feito para valores que precisam.