Segurança
Última atualização: 23 de julho de 2026
Em resumo. A separação entre os dados de um cliente e os de outro é feita dentro do banco de dados, não na aplicação — e é testada por uma bateria de ataque que verifica o efeito, não apenas a ausência de erro. Nenhum dado da sua operação é enviado a terceiros. Você exporta tudo, a qualquer momento, sem pedir autorização.
Esta página descreve o que está implementado hoje. O que ainda não temos está dito com o mesmo destaque — mais abaixo, em “O que ainda não temos”.
1. Isolamento entre clientes
Cada organização enxerga apenas os próprios dados. Essa separação é aplicada por Row Level Security do PostgreSQL, em toda tabela que guarda informação de cliente — e não por filtro escrito na aplicação.
A diferença importa: um erro de programação numa tela não é suficiente para vazar dado de um cliente para outro, porque a decisão de acesso não está na tela. Ela está no banco, e é aplicada mesmo quando a consulta chega por outro caminho.
O isolamento é verificado por uma suíte de 28 arquivos de teste que roda do zero a cada alteração, incluindo tentativas deliberadas de escrita cruzada entre organizações, de leitura fora do alcance do papel e de escalada de privilégio. Os testes verificam o efeito da tentativa — se a linha foi criada, se o dado apareceu — e não apenas se houve mensagem de erro.
2. Acesso e identidade
| Autenticação | E-mail e senha, ou acesso corporativo (SSO) pelo provedor de identidade da sua empresa, por domínio de e-mail. A organização decide se exige SSO. |
|---|---|
| Papéis | Proprietário, administrador, analista e ponto focal. O ponto focal enxerga apenas as carteiras às quais está vinculado — e esse limite também é aplicado no banco. |
| Verificação em duas etapas | Disponível por aplicativo autenticador (TOTP). |
| Senhas | Mínimo de oito caracteres, com verificação contra bases públicas de senhas vazadas. A senha nunca é enviada nessa verificação. |
| Sessões | Rotação de token de atualização com detecção de reuso: um token usado duas vezes derruba a sessão inteira. |
| Chaves de API | Guardadas apenas como resumo criptográfico (SHA-256). A chave é exibida uma única vez, na criação, e não pode ser recuperada depois — nem por nós. |
3. O que fica registrado
Toda alteração relevante grava quem alterou, o que mudou e quando. Além disso, o sistema mantém registro de cada chamada de API recebida — inclusive as recusadas, com o motivo —, um diário de execução das rotinas automáticas e a medição de disponibilidade minuto a minuto.
Erros ocorridos na tela do usuário chegam à nossa equipe com rota, tipo e mensagem técnica, e nunca com dado de negócio: nome de conta, valores e texto de registro são removidos antes de o relato sair do navegador, e há teste automatizado que trava esse comportamento.
4. Criptografia
Tráfego em trânsito por TLS. Dados em repouso criptografados pela infraestrutura do Supabase e do Vercel. Senhas armazenadas com função de derivação própria do provedor de autenticação, nunca em texto claro.
5. Seus dados são seus
| Exportação | Completa, em CSV e JSON, a qualquer momento, pela própria interface — sem abrir chamado e sem pedir autorização. |
|---|---|
| Formato | PostgreSQL padrão. Não há formato proprietário que prenda a informação aqui. |
| Uso do conteúdo | Não usamos o conteúdo da sua operação para nenhuma finalidade que não seja prestar o serviço a você. Não treinamos modelos, não agregamos para vender panorama de mercado. |
| Encerramento | Ao fim do contrato, você exporta e a base é apagada. |
6. Quem opera a plataforma não enxerga a sua operação
Nossa equipe tem acesso administrativo ao produto — assinatura, plano, situação de pagamento e uso agregado. Esse acesso é deliberadamente estreito: carteiras, contas, contratos e histórico ficam fora dele, e a restrição é aplicada pelas mesmas políticas de banco que separam um cliente do outro.
Administrar assinatura não é motivo para ler a operação de ninguém — e essa frase está escrita como comentário no código que aplica a regra.
7. Terceiros que participam do serviço
Esta é a lista completa. Nenhum outro serviço recebe dado da sua operação.
| Quem | Para quê | O que recebe |
|---|---|---|
| Supabase | Banco de dados, autenticação e arquivos | Todos os dados da operação, em repouso |
| Vercel | Execução da aplicação | Dados em trânsito durante o uso |
| Brevo | Envio de e-mail (extrato, resumo, convite, acesso) | Endereço de e-mail e conteúdo das mensagens enviadas |
| Consulta pública de CNPJ | Preencher razão social e segmento a partir do CNPJ | Apenas o CNPJ — e apenas se sua organização ligar o recurso, que nasce desligado. Cada consulta fica registrada. |
Note o que não está nesta lista: nenhum provedor de inteligência artificial. O resumo de conta que o produto oferece antes de uma reunião é montado por regra, com os dados que já estão aqui. Enviar o histórico das suas contas a um modelo de terceiro contradiria o resto desta página, então não fazemos.
8. Disponibilidade e recuperação
A disponibilidade é medida por um monitor externo, minuto a minuto, e minuto sem medição conta como fora do ar — é o número que se sustenta numa discussão, e não o que favorece quem o publica. O compromisso contratual está nos Para desenvolvedores Termos de uso.
As cópias de segurança são responsabilidade da infraestrutura de banco, com retenção conforme o plano contratado. O procedimento de restauração já foi executado e cronometrado em ambiente de teste.
9. Como o software chega ao ar
Toda alteração passa por verificação automática antes de ser publicada: checagem de tipos, suíte de testes e compilação. As alterações de banco são versionadas em arquivos numerados e uma alteração já aplicada nunca é editada — correção é sempre um arquivo novo, o que preserva a trilha do que foi feito e quando.
Cada arquivo de alteração de banco carrega, no fim, uma verificação que falha se o estado resultante não for o esperado. Se algo não ficou como deveria, a publicação para ali.
10. O que ainda não temos
Não temos SOC 2 nem ISO 27001. Se a sua área de segurança exige um desses relatórios como condição, isso é um bloqueador hoje — e preferimos dizer agora a descobrir no fim do processo.
Não fizemos teste de intrusão por empresa independente. A bateria de ataque descrita no item 1 é nossa, é séria e não substitui um pentest de terceiro.
O que podemos oferecer no lugar: a documentação técnica completa, acesso às nossas políticas internas e uma conversa direta com quem construiu o produto — incluindo as partes que não estão prontas.
11. Encontrou uma falha?
Escreva para seguranca@proximia.com.br com o que encontrou e como reproduzir. Respondemos em até dois dias úteis, corrigimos o que for procedente e damos o retorno de como foi resolvido. Não movemos ação contra quem relata de boa-fé e não divulga antes da correção.
12. Documentos
Nossas políticas internas estão publicadas: segurança da informação, controle de acesso, resposta a incidentes, gestão de mudanças, continuidade e gestão de fornecedores. O tratamento de dados pessoais está na política de privacidade.