Segurança
Última atualização: 31 de julho de 2026
Esta página descreve o que está implementado hoje — e, na seção 10, o que não está. Ela é escrita para quem precisa avaliar o Contatia como fornecedor.
1. Isolamento entre workspaces
A separação entre clientes é feita no banco de dados, com Row Level Security do PostgreSQL, e não apenas na tela. Cada consulta carrega a identidade de quem a fez, e o banco recusa linhas de outro workspace mesmo que a aplicação peça.
Isso importa porque muda a consequência de um bug: um erro numa tela vira uma tela errada, não um vazamento.
2. Acesso e identidade
- Autenticação pelo Supabase Auth. Senha nunca é gravada em texto claro.
- Quatro papéis — dono, admin, gestor, SDR/vendedor — com o que cada um pode fazer definido em um só lugar do código.
- Quem não é gestor enxerga apenas a própria carteira. Esse recorte vale no banco, não só na interface.
- Convite por link com validade de 14 dias, revogável.
3. Credenciais dos seus canais
Para enviar em seu nome, guardamos a senha SMTP da sua caixa, o token do Gmail e a chave da sua instância de WhatsApp. Elas nunca são devolvidas ao navegador: só o servidor as usa, na hora do envio.
Desde julho/2026, caixas e números podem ser pessoais. Nesse caso a regra no banco é: você lê a sua, as compartilhadas e as do workspace — a caixa privada de um colega não existe para você, nem para uma consulta feita à mão fora da aplicação. Compartilhar é uma decisão explícita, com aviso de que expõe a configuração completa.
Ressalva honesta: essas credenciais ficam no banco protegidas por RLS, e não cifradas em coluna com chave separada. Um comprometimento das chaves de serviço do banco as exporia. Cifrar em coluna está no plano.
4. Criptografia
- TLS em todo o tráfego, sem exceção.
- Criptografia em repouso pela infraestrutura (Supabase/AWS).
- Os serviços no nosso servidor próprio só respondem por HTTPS e com token; o banco da Receita não aceita conexão de fora da máquina.
5. O que fica registrado
Ações destrutivas e de risco vão para um registro que não pode ser alterado nem apagado pela aplicação — exclusão em massa, importação, envio, mudança de permissão, alteração de canal. O registro guarda quem fez, quando, quantos e uma amostra do que saiu, e sobrevive à exclusão do próprio registro afetado. Está em Resultados → Registro.
6. Seus dados são seus
- Exportação de contatos e empresas em CSV, por você, a qualquer momento.
- O CSV exportado sai no mesmo formato que a importação aceita — sem formato proprietário.
- Não usamos o conteúdo da sua operação para treinar modelo de IA, nem para análise entre clientes.
- Após o encerramento: 30 dias para exportar, exclusão em até 90 dias.
7. Quem opera não enxerga a sua operação
O acesso administrativo alcança assinatura, cobrança, consumo agregado e conversas de suporte. Não alcança a sua carteira, suas mensagens nem seus relatórios. Quando um acesso de suporte é necessário, ele é pedido, registrado e limitado no tempo.
8. Terceiros que participam
| Terceiro | Para quê | O que recebe |
|---|---|---|
| Supabase (Canadá) | Banco, login, arquivos | Todos os dados operacionais, em repouso |
| Vercel (EUA) | Execução da aplicação | Dados em trânsito durante o uso |
| Asaas (Brasil) | Cobrança | Só dados de cobrança do assinante |
| Brevo (França) | E-mails transacionais | Destinatário e conteúdo |
| Servidor próprio (Contabo, Alemanha) | Base da Receita, descoberta de e-mail, WhatsApp | Domínio e nome para o teste; número para verificação |
| BrasilAPI / ReceitaWS | Consulta de CNPJ | Só o CNPJ |
| Gmail e Agenda, se você conectar | Só o que a sua autorização permite |
Não há provedor de inteligência artificial nesta lista. Nenhum dado da sua operação é enviado a um modelo de IA. Se isso mudar, esta tabela muda antes.
9. Como o software chega ao ar
- Verificação de tipos e compilação completa antes de qualquer publicação — build quebrado não sobe.
- Alterações de banco em migrations versionadas e idempotentes, aplicadas na ordem.
- Regras de acesso são testadas contra um PostgreSQL real, com tentativa deliberada de ler o que não se deve. O teste confere o efeito (quantas linhas saíram), não a mensagem de erro.
- SQL destrutivo é validado num banco descartável, com usuário sem privilégio, antes de ser entregue.
10. O que ainda não temos
Com todas as letras, porque isto costuma decidir uma avaliação:
- Sem certificação SOC 2 ou ISO 27001.
- Sem teste de intrusão por terceiro independente.
- Sem autenticação em dois fatores (2FA). É a lacuna mais relevante da lista e está no plano.
- Sem SSO / login corporativo.
- Sem cifragem em coluna das credenciais de canal (ver seção 3).
- Sem exclusão de conta self-service — hoje é por pedido.
- Sem segregação de funções: a operação é de uma pessoa só.
- Monitoramento de disponibilidade é interno; não há monitor externo independente.
11. Achou uma falha?
Escreva para seguranca@contatia.com.br. Respondemos em até 2 dias úteis.
Não tomamos medida legal contra quem reporta de boa-fé. Em troca pedimos o de sempre: não acessar dado de terceiro além do necessário para demonstrar a falha, não degradar o serviço e não divulgar antes da correção.
12. Documentos
As práticas por trás desta página estão em Políticas internas. Veja também Privacidade e Termos de Uso.