Segurança
Como protegemos seus dados — inclusive o que ainda não temos.
Última atualização: 17 de agosto de 2026
Como o SuperDB protege os dados que você confia à plataforma, e como relatar uma vulnerabilidade.
Isolamento entre projetos
Todos os projetos compartilham a mesma instância do PostgreSQL, e o isolamento é feito pelo banco — não pela aplicação:
- Cada projeto tem um schema próprio e um papel de banco exclusivo, sem permissão sobre os schemas dos demais;
- O token de acesso carrega o schema a que pertence, e a API de dados recusa a requisição quando o schema pedido não é o do token;
- Tempo real e armazenamento seguem a mesma regra: o token de um projeto é recusado nos canais e buckets de outro.
Criptografia
Aqui a resposta honesta não é um "sim" único: depende da camada. Então vai por camada.
O que é cifrado:
- Em trânsito: TLS 1.2 ou superior em todo o tráfego público, com HSTS. O salto entre a aplicação e o banco acontece dentro da rede privada do servidor, não exposta à internet, e não usa TLS adicional;
- Senhas: Argon2id — não guardamos senha em texto claro, nem temos como recuperá-la;
- Backups do banco e dos arquivos: cifrados no servidor de origem, antes de sair dele (AES-256-CBC com derivação PBKDF2 de 200.000 iterações). A chave não fica no destino. Os arquivos passaram a ser cifrados em 17 de agosto de 2026 — antes dessa data só o banco era;
- CPF e CNPJ do titular da conta: AES-256-GCM, com chave derivada por projeto;
- Segredos operacionais: chaves de assinatura de cada projeto, segredos de MFA, client secrets de OAuth e a service role key — todos com AES-256-GCM.
O que não é cifrado — dizer isso é o ponto desta página:
- O disco do servidor não usa criptografia de disco (LUKS). Os arquivos de dados do PostgreSQL ficam em sistema de arquivos comum;
- As tabelas do seu aplicativo são gravadas em texto. A extensão pgcrypto está disponível se você quiser cifrar uma coluna, mas nada é cifrado automaticamente.
Nessa camada, o que protege é o controle de acesso do banco — schema próprio, papel exclusivo por projeto e RLS —, não a cifragem. Se o seu caso exige o dado ilegível também no disco, cifre a coluna na sua aplicação.
Autenticação e chaves
- Tokens de acesso à API de dados são assinados com ES256, com chave pública publicada por projeto;
- Chaves de API podem ser revogadas e regeradas a qualquer momento pelo painel;
- Autenticação em duas etapas disponível por TOTP;
- Bloqueio progressivo por tentativas de login malsucedidas;
- No cadastro, a senha pode ser conferida contra bases públicas de vazamento (Have I Been Pwned). É opcional e não vem ligada por padrão — quando você ativa, sai daqui apenas os cinco primeiros caracteres do hash da senha, nunca a senha.
Row Level Security por padrão
Tabelas criadas pelo painel nascem com RLS habilitada e sem políticas — ou seja, fechadas até que você defina quem pode ler e escrever. O padrão inseguro seria o contrário: nascer aberta e depender de alguém lembrar de proteger.
Backups e continuidade
- Banco de dados: cópia a cada 6 horas, cifrada e enviada para armazenamento externo;
- Arquivos: sincronização a cada hora, também cifrada;
- Restauração testada com dado real de produção — não basta o backup existir, ele precisa ter sido restaurado com sucesso pelo menos uma vez;
- Retenção: o dump do banco tem rotação por idade — cópias com mais de 30 dias são apagadas, local e no destino externo. Os arquivos e anexos não têm rotação por idade: a cópia externa é um espelho do que existe agora e é removida quando o arquivo original é apagado.
Ainda assim: mantenha seus próprios backups. Os nossos existem para recuperação de desastre da infraestrutura e não substituem a cópia que só você sabe quando precisa restaurar.
O que ainda não temos
Preferimos dizer com clareza a deixar você descobrir depois:
- Não temos certificação SOC 2 nem ISO 27001;
- Não oferecemos SLA contratual de disponibilidade nos planos atuais;
- Não temos recuperação para um instante específico no tempo (PITR); a granularidade é a do backup diário;
- Não temos réplica em outra região nem alta disponibilidade — é um servidor, sem troca automática. A recuperação de um desastre grave envolve restaurar a partir do backup;
- Não apagamos a trilha de auditoria antes de 31 dias, mesmo nos planos que preveem prazo menor: a retenção da trilha de auditoria conforme o plano contratado é aplicada por rotina diária, mas com um piso de 31 dias — o cálculo de usuários ativos do mês lê a própria trilha dos últimos 30 dias, e cortar antes disso quebraria a medição de uso.
Relatar uma vulnerabilidade
Se você encontrou uma falha, escreva para seguranca@superdb.com.br com o máximo de detalhe que puder: onde, como reproduzir e qual o impacto.
Nosso compromisso:
- Confirmamos o recebimento em até 48 horas;
- Damos um retorno com avaliação em até 7 dias;
- Não tomamos medidas legais contra quem pesquisa de boa-fé e segue as regras abaixo.
Regras
- Teste apenas em projetos seus;
- Não acesse, altere nem exfiltre dados de outros clientes — se encontrar um caminho, pare e relate;
- Nada de negação de serviço, spam ou engenharia social contra nossa equipe ou nossos clientes;
- Dê tempo para corrigirmos antes de divulgar publicamente.
Ainda não temos programa de recompensa financeira. Temos gratidão pública a quem quiser ser creditado.