Mova
Como a Mova processa, protege e limita o acesso aos dados financeiros pessoais através de uma API no servidor e de um modelo de cifragem por utilizador.
Atualizado 7 de março de 2026
Idioma do documento
Altere o texto da política de privacidade sem mudar o idioma do perfil autenticado dentro da aplicação.
Dossier técnico de segurança
Abra um dossier técnico otimizado para impressão com capa, resumo, abreviaturas, tabelas de controlo, fronteiras de ameaça e comparação pública com fintechs baseada em documentação oficial de segurança.
A exportação PDF abre um documento pronto para impressão numa nova aba e aciona o fluxo Guardar como PDF do navegador.
A Mova armazena e processa dados de perfil, preferências de idioma e moeda, cartões, transações, rendimentos, despesas, ativos, passivos, investimentos, metas financeiras, informação fiscal, metadados de faturas, notificações, metadados de feedback e registos operacionais ou de auditoria estritamente necessários para executar o serviço.
O produto foi concebido para organização e planeamento financeiro. Os dados são processados para autenticar utilizadores, persistir registos, calcular dashboards, gerar relatórios, operar notificações e aplicar controlos de segurança em torno do acesso autenticado à API.
O navegador deve comunicar com os dados da aplicação através de rotas de API em Next.js. As credenciais privadas de serviço do Supabase permanecem apenas no servidor e não devem ser expostas em bundles frontend, armazenamento do cliente ou código visível no navegador.
As rotas protegidas validam o bearer token em cada pedido, rejeitam caminhos inseguros, aplicam verificação de mesma origem em pedidos mutativos, definem cabeçalhos no-store e aplicam rate limiting antes de qualquer operação privilegiada na base de dados.
A Mova utiliza um modelo de cifragem na camada da aplicação para as principais tabelas financeiras do utilizador. Os campos sensíveis pertencentes ao utilizador são serializados em blobs cifrados antes do armazenamento e só são descifrados no servidor para um pedido autenticado e autorizado.
O modelo deriva uma chave AES-GCM por utilizador a partir de um segredo do servidor, do identificador do utilizador e de um salt único do perfil. Isto significa que o acesso bruto à base de dados, por si só, não revela plaintext para os campos protegidos.
A row-level security permanece ativa nas tabelas voltadas ao utilizador, e os endpoints administrativos ficam restritos a utilizadores com privilégios de admin. Operações sensíveis de manutenção, como reencriptação, ficam isoladas em rotas administrativas dedicadas.
Alterações administrativas como ajustes de acesso do utilizador ou tratamento de feedback são registadas em logs de auditoria. Isto cria uma trilha de revisão para ações privilegiadas e reduz a dependência de intervenções manuais sem rasto.
Os uploads de faturas são aceites apenas por rotas autenticadas do servidor, que validam origem, MIME type e tamanho antes do envio para o storage. O download é mediado por URLs assinadas de curta duração e limitadas ao caminho do próprio utilizador.
Este desenho reduz a exposição direta dos objetos no storage e evita o acesso arbitrário entre utilizadores através de simples tentativa de caminhos pelo cliente.
O desenho atual aumenta de forma material o custo de leitura dos dados a partir de um bundle do navegador roubado, de uma consola da base de dados sem o segredo da aplicação, ou de um operador que tenha apenas acesso direto às linhas. Nesses cenários, os campos protegidos permanecem cifrados e não aparecem em plaintext.
O modelo também reduz exposições acidentais ao manter credenciais privilegiadas apenas no servidor e ao centralizar leituras autenticadas dentro da API da aplicação, em vez de espalhar chamadas diretas à base de dados pelo cliente.
A Mova não afirma atualmente zero-knowledge nem end-to-end encryption. Um operador com acesso privilegiado ao ambiente de produção, ao segredo de serviço e ao caminho de execução do servidor ainda pode derivar chaves por utilizador e decifrar registos autorizados.
Por isso, a plataforma deve ser entendida como uma arquitetura endurecida no servidor com armazenamento cifrado por utilizador, e não como um desenho criptográfico em que o operador é matematicamente incapaz de ver plaintext em qualquer circunstância.
Os dados operacionais e de segurança são mantidos apenas pelo tempo necessário para prestar o serviço, apoiar investigações, cumprir obrigações legais ou preservar a integridade da plataforma. Os prazos de retenção podem variar por tipo de registo e necessidade de resposta a incidentes.
Este documento pode ser atualizado quando a arquitetura, a infraestrutura ou a posição de conformidade da plataforma mudarem de forma material. A data efetiva nesta página é revista quando essas alterações são publicadas.