Criptografar o SQLite é só o começo de proteger uma automação financeira

Fabio Akita descreveu a revisão de segurança de um consolidador financeiro pessoal em Rust, QtQuick/QML e SQLite, com coleta de extratos por navegador.[9] Na arquitetura revisada, o usuário faz login e segundo fator manualmente antes de entregar a sessão à automação.[9] O interesse técnico do caso está na separação de responsabilidades, não em transformar uma lista de ferramentas em certificado de segurança.

O que muda para quem desenvolve

O desenho usa SQLCipher para o banco, proteção da chave com TPM 2.0 e systemd-creds, entrega por pipe anônimo e separação entre interface e backend.[9] O navegador opera em isolamento com perfil descartável e restrição de saída de rede, enquanto documentos baixados passam por outro sandbox, sem rede nem banco.[9] São barreiras para riscos diferentes.

Minha leitura: cifrar o armazenamento responde apenas a parte da pergunta. Também é necessário decidir quem pode abrir o dado, quais componentes recebem a chave e o que um parser comprometido alcança. Uma interface sem acesso direto ao banco e um parser sem a chave têm responsabilidades mais fáceis de auditar.

Como aplicar

Comece por um mapa de dados: credenciais de login, sessão do navegador, chave do banco, documentos importados e backups. Para cada item, descreva onde existe em texto legível e qual processo precisa acessá-lo. Corte acessos que só estejam presentes por conveniência da implementação.

Para um experimento seguro, use documentos sintéticos e uma base descartável. Execute a importação em um processo sem acesso à base e aceite apenas uma estrutura de saída limitada. Tente alimentar o fluxo com arquivo inválido e saída fora do esquema esperado. O critério é rejeitar a entrada sem ampliar permissões.

Na migração relatada, o autor compara fingerprints lógicos de esquema e linhas e valida um backup por restauração antes da troca do banco oficial.[9] A recomendação geral é separar duas provas: confidencialidade do novo armazenamento e preservação dos dados. Uma não substitui a outra.

Cuidados e limites

O desenho cobra login e 2FA a cada execução e acrescenta dependências e restrições de rede.[9] Esse custo deve entrar na avaliação de usabilidade e manutenção.

O autor explicita riscos residuais, como malware no host, adulteração do código, resíduos antigos em SSD e controle por root com o cofre aberto.[9] Portanto, não atribua proteção absoluta ao TPM ou ao sandbox.

A recuperação também precisa existir fora da máquina: o relato combina código offline, backup cifrado validado e cópias externas.[9] Antes de amarrar uma chave ao hardware, prove como recuperar os dados sem aquele hardware. Segurança que impede o próprio dono de restaurar o sistema não é uma entrega completa.

Fonte

[9] Fonte: AkitaOnRails