Segurança e isolamento
Cada projeto DIVZ tem seu próprio processo de compute, seus próprios roles e seu próprio banco — não há schema compartilhado entre clientes. TLS é obrigatório na porta pública e a allowlist de IPs fecha o banco para o resto da internet.
Isolamento entre clientes
Cada projeto DIVZ tem processo de compute próprio, banco próprio e roles próprios. Não existe schema compartilhado, nem uma tabela grande com uma coluna tenant_id separando clientes. Um projeto não enxerga o banco de outro porque não há caminho de rede nem role em comum entre eles.
O pooler público repassa a identidade do cliente ao compute de destino — ele não usa uma credencial de serviço compartilhada. O compute só conhece os roles daquele projeto, então uma credencial vazada de um cliente não abre a porta de nenhum outro.
Rede
| Porta | Serviço | Exposição |
|---|---|---|
| 443 | site, console e API | pública, HTTPS |
| 5432 | PostgreSQL (pooler) | pública, TLS obrigatório, sujeita à allowlist do projeto |
| — | storage engine e object store | nunca expostos à internet, em rede interna |
O armazenamento — onde as páginas do banco de fato vivem — não tem porta pública. Ele só é alcançável pela rede interna do servidor, e nenhum caminho da internet chega até lá.
Allowlist de IPs
Cada projeto tem uma lista de IPs e faixas CIDR autorizados a abrir conexão. O filtro é aplicado no firewall do host, antes do PostgreSQL — quem não está na lista não chega a apresentar senha.
Lista vazia significa liberado para qualquer origem. É o padrão de um projeto novo, para você conseguir conectar do seu computador no primeiro minuto. Assim que souber de onde a aplicação conecta, preencha a lista — enquanto ela estiver vazia, a senha é a única coisa entre o seu banco e a internet.
Roles e privilégio mínimo
| Role | Pode | Use para |
|---|---|---|
| <projeto>_owner | tudo no banco, inclusive contornar RLS | migração e manutenção pontual |
| <projeto>_app | o que você conceder; respeita row level security | a aplicação em produção |
| roles extras | o que você conceder | relatórios, BI, integrações de terceiros |
A separação só protege se você usá-la: um serviço que conecta como dono anula o RLS que você escreveu, porque o dono do banco passa por cima da política por definição.
Criptografia
- Em trânsito: TLS obrigatório na porta pública do banco e HTTPS no console e na API. Conexão sem TLS é recusada.
- Nos backups: os dumps diários são cifrados com age antes de deixar o servidor. Quem tiver acesso ao armazenamento de backup não lê o conteúdo.
- Nos segredos da plataforma: credenciais de provedores configuradas no painel ficam cifradas com AES-256-GCM, não em texto claro no banco de controle.
Trilha de auditoria
Ações relevantes ficam registradas com autor, recurso e horário: criação e exclusão de projeto, rotação de credencial, mudança de allowlist, execução de SQL pelo editor. Veja em Projeto → Atividade, ou por GET /api/v1/projects/:id/activity.
No caso do SQL, o registro guarda o hash da consulta e os primeiros caracteres — não o texto inteiro. É o suficiente para responder “quem rodou o quê e quando” sem que a própria trilha vire um depósito de dado pessoal dos seus usuários.
Onde os dados ficam e sob qual lei
A região padrão é a Alemanha (Falkenstein) e há uma região em São Paulo. A operação é da MDA Brasil, empresa brasileira, sujeita à LGPD. Hospedar na União Europeia significa que a infraestrutura também está sob o regime do GDPR — o que soma proteção, não substitui a LGPD.
Os dados são seus. Você pode pedir o dump do seu banco a qualquer momento pelo suporte, ou gerar o seu próprio com pg_dump — a connection string é padrão e a ferramenta é a de sempre.
Reportar uma falha
Encontrou um problema de segurança? Abra um chamado em console.divz.com.br/suporte marcando como segurança. Relatos de boa-fé são bem-vindos e respondidos.
Próximo: Perguntas frequentes