Criptografia e limites de proteção de dados
Após a configuração e a migração previstas, o minddy cifra conteúdos e arquivos antes das gravações persistentes usando criptografia autenticada no servidor.
Entender criptografia e dados ainda visíveis
Após a configuração e a migração previstas, o minddy cifra conteúdos e arquivos antes das gravações persistentes usando criptografia autenticada no servidor. As chaves de projeto, usuário e sistema são versionadas e protegidas por uma chave raiz mantida fora do PostgreSQL. Uma cópia isolada do banco não permite ler os conteúdos protegidos sem as chaves. A aplicação os decifra para usuários autorizados, busca e trabalho de IA autorizado, inclusive sem uma sessão interativa. Um ambiente de execução comprometido ou o acesso aos dados e às chaves ultrapassa esse limite. Não se trata de criptografia ponta a ponta que impeça o operador de ler o conteúdo.
Reconhecer dados legíveis e exportados
O Auth mantém o email de login. Identificadores, chaves de projeto e issue, status, prioridades, datas e metadados permitidos continuam consultáveis. Publicações ficam legíveis por escolha de quem publica. Exporte, baixe e envie dados a provedores externos de IA, email, Git ou MCP com os controles adequados; os dados no navegador também precisam de proteção. Uma flag não comprova que o histórico foi convertido ou removido de cópias, logs e provedores. A leitura do código não demonstra que a migração de criptografia foi executada no minddy Cloud em produção.
Preservar a recuperação
Proteja MINDDY_DATA_ROOT_KEY fora do banco e conserve o material de recuperação necessário aos backups atuais e históricos. Restaure banco, bytes e configuração juntos. Cifre o backup externo que contém tanto dados quanto chaves. Trocar a raiz sem reencapsular as chaves torna os conteúdos ilegíveis; desativar a flag não os devolve ao texto aberto. Antes de ativar a criptografia em uma instância existente, teste a recuperação e verifique a decifragem e os bytes efetivamente retornados.