A verificação que prova, com
evidência matemática, se o isolamento
de dados do seu banco é real.
Validação algorítmica de Row-Level Security (RLS) para SaaS B2B, ERPs e Fintechs em PostgreSQL. Comprove que os dados de clientes diferentes estão 100% segregados na infraestrutura.
Zero Leitura de Dados Privados
Inspeciona apenas o catálogo estrutural (pg_catalog) e regras de RLS. Nenhum dado do cliente é lido ou armazenado.
Algoritmo Imparcial vs Pentest Manual
Elimina a falha humana e substitui checklists lentos por validação matemática instantânea.
Certificação Imutável (SHA-256)
Hash criptográfico emitido em segundos para blindagem contra multas e comprovação perante auditorias de conformidade.
“RLS ativado” não é o mesmo que banco seguro
Row-Level Security (RLS) é a camada que garante que a conexão de um cliente só enxerga as linhas dele mesmo — o coração do isolamento em qualquer SaaS multi-tenant. Mas ligar RLS numa tabela é só o primeiro passo. Os quatro cenários abaixo são as formas mais comuns de um banco parecer protegido e não estar.
Dono da tabela ignora a política
Ativar RLS com ENABLE ROW LEVEL SECURITY não alcança o dono da tabela por padrão — ele continua vendo tudo, a menos que FORCE ROW LEVEL SECURITY também esteja ligado nessa mesma tabela. É a causa mais comum de “RLS ativo, mas os dados ainda vazam” que encontramos em auditorias reais.
Credencial de serviço ignora RLS de propósito
Chaves administrativas (como a service_role do Supabase, ou qualquer role com o atributo BYPASSRLS) foram desenhadas para pular todas as políticas — é assim que rotinas de backend funcionam. O problema é quando essa chave aparece onde não devia: no código do front-end, num log, num repositório público ou numa automação de terceiros. Nesse momento, todo o isolamento entre clientes deixa de existir, mesmo com RLS perfeitamente configurado em cada tabela.
Bots e automações usam privilégio de mais
É comum uma automação (n8n, Zapier, Make, um script interno, um agente de IA) se conectar ao banco usando a credencial mais privilegiada disponível — “porque é mais simples de configurar”. Isso cria um ponto cego: um bug na automação, uma URL mal montada ou uma instrução manipulada (no caso de agentes de IA) pode ler ou alterar dados de qualquer cliente, mesmo que o painel do produto, sozinho, respeite o isolamento perfeitamente.
Nem toda conexão deveria ter o mesmo poder
Uma boa arquitetura separa claramente os papéis: conexões anon/authenticated (baixo privilégio, sujeitas a RLS) para o que o cliente final usa, e credenciais administrativas isoladas — usadas só onde é estritamente necessário, nunca reaproveitadas em integrações externas ou automações que não precisam desse nível de acesso.
O que o Genesis VaultCheck audita: além de confirmar que RLS está habilitado tabela por tabela, verificamos se FORCE ROW LEVEL SECURITY está aplicado e se existem concessões diretas (GRANT) para papéis de baixo privilégio (como anon) que contornam a intenção das suas políticas — o mesmo tipo de brecha que uma automação malconfigurada ou uma chave vazada exploraria.
Por que o S91 é diferente?
Comparamos a abordagem forense algorítmica com as alternativas tradicionais do mercado.
Auditoria Algorítmica S91
- Inspeciona pg_catalog e information_schema diretamente
- Verifica RLS habilitado em cada tabela com tenant_id
- Detecta tabelas sem política USING automaticamente
- Gera prova criptográfica SHA-256 imutável
- Resultado em segundos, sem intervenção humana
- Zero leitura de dados de negócio dos seus clientes
Checklist Manual
- Baseado em perguntas e respostas subjetivas
- Não verifica o banco diretamente
- Leva dias ou semanas para completar
- Sem evidência técnica gerada
- Depende da honestidade do respondente
- Não detecta configurações incorretas automaticamente
Pentest Tradicional
- Foco em vulnerabilidades de rede e aplicação
- Raramente verifica RLS no nível de metadados
- Custo elevado (R$ 10k–50k por ciclo)
- Necessita acesso amplo ao sistema
- Resultado em semanas ou meses
- Sem foco específico em multi-tenancy PostgreSQL