Pular para o conteúdo principal

Criptografia do banco de dados

O Libre WebUI inclui um serviço de criptografia no nível da aplicação para valores sensíveis antes de gravá-los no armazenamento.

Método de criptografia​

O backend usa AES-256-GCM por meio do crypto do Node.js. A chave deve ter 32 bytes, representados como uma string hexadecimal de 64 caracteres:

ENCRYPTION_KEY=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Gere uma chave:

openssl rand -hex 32

Armazenamento da chave​

O Libre WebUI carrega a chave nesta ordem:

  1. ENCRYPTION_KEY do ambiente.
  2. Um arquivo .encryption_key persistente no DATA_DIR selecionado.
  3. Somente em um armazenamento novo, uma chave gerada e gravada de forma durável em DATA_DIR/.encryption_key antes do banco iniciar.

Se o ambiente e o arquivo persistente fornecerem uma chave, elas devem coincidir ou a inicialização falhará. Um estado criptografado existente sem sua chave original também falha de forma segura; o Libre nunca gera uma substituta para um armazenamento existente.

Regras importantes​

  • Faça backup de ENCRYPTION_KEY com o banco de dados.
  • Não troque a chave sem um plano de migração dos valores criptografados.
  • Perder a chave impede a recuperação dos valores.
  • Alterar a chave sem recriptografar os dados torna os valores existentes ilegíveis.

O que é protegido​

A criptografia é aplicada pelos caminhos que usam o serviço ou os auxiliares de armazenamento criptografado. Ela foi projetada para valores sensíveis, como credenciais e dados privados tratados por esses auxiliares.

Não é criptografia de disco inteiro, de páginas SQLite nem de ponta a ponta entre usuários e navegador. Use criptografia de disco e HTTPS para essas camadas.

Dados do Work​

A criptografia da aplicação não protege uma tarefa Work inteira. Arquivos-fonte e dependências são arquivos comuns em volumes nomeados do Docker específicos da tarefa. Conversas, resultados de ferramentas, saída de comandos e metadados são armazenados no SQLite e não são automaticamente criptografados só porque alguns caminhos de credenciais usam o serviço.

Proteja a raiz de dados do Docker e o DATA_DIR com controles de acesso e criptografia de disco quando necessário. Faça backup conjunto do banco, ENCRYPTION_KEY e volumes Work gerenciados. Enviar uma tarefa Work a um modelo remoto também pode expor contexto e arquivos ou saídas solicitadas ao provedor; a criptografia de armazenamento não altera essa fronteira de rede.

Docker e Kubernetes​

Defina uma chave estável em produção:

ENCRYPTION_KEY=replace-with-64-hex-characters
DATA_DIR=/data

Monte o DATA_DIR em armazenamento persistente. No Kubernetes, guarde a chave em um Secret e monte os dados em um PersistentVolume.

Solução de problemas​

Tamanho de chave inválido

A chave deve ter exatamente 64 caracteres hexadecimais. Gere uma nova:

openssl rand -hex 32

Não é possível descriptografar após reimplantar

Confirme que o mesmo ENCRYPTION_KEY está em uso e que o mesmo volume DATA_DIR está montado.

O desenvolvimento gerou uma nova chave

Mantenha DATA_DIR/.encryption_key com o banco. Você também pode definir o mesmo valor em ENCRYPTION_KEY; se ambas as fontes existirem, devem coincidir.

Documentos relacionados​