Segurança & 2FA
Isolamento multi-tenant — como provamos via teste E2E
O Lefia usa Row-Level Security (RLS) do Postgres pra garantir que um cliente nunca vê dado de outro. Isso é provado por suíte E2E que roda no CI a cada push.
Atualizado em 8/6/2026
O Lefia é multi-tenant: dados de empresas diferentes coexistem nas mesmas tabelas, separados pelo campo
32 policies aplicadas nas tabelas tenant-scoped (
Isso significa que mesmo um bug na camada de aplicação que esquecesse de filtrar por tenant não vaza dados — o banco corta antes.
Em
Tempo total: ~22s. Sobe
O artifact PNG fica em
tenant_id. A garantia de isolamento vem de duas camadas:Camada 1 — Row-Level Security (RLS) no Postgres
32 policies aplicadas nas tabelas tenant-scoped (
message_types, integrations, mappings, messages, tenants, user_tenants, etc.). Quando um usuário autenticado consulta qualquer tabela, o Postgres adiciona automaticamente um filtro WHERE user_belongs_to_tenant(tenant_id), transparente pra aplicação.Isso significa que mesmo um bug na camada de aplicação que esquecesse de filtrar por tenant não vaza dados — o banco corta antes.
Camada 2 — Teste E2E executável (#61)
Em
e2e/multi-tenant.spec.ts rodamos 10 testes Playwright que provam isolamento:- Listagem em 4 tabelas chave (message_types, integrations, mappings, tenants) — A só vê A
- Leitura por id direto do tenant B → retorna
[](não 403, evita oracle attack) - Tentativa de UPDATE/DELETE no id de B → 0 rows afetadas, B continua intacto
message_logsbloqueada via policyqual=falsemesmo pra autenticado- UI smoke: login na tela /login → /monitor → screenshot artifact + assert que nome do tenant B não aparece no HTML
Tempo total: ~22s. Sobe
npm run dev automaticamente. Cada execução cria 2 tenants temporários no Supabase (prefixados e2e_<runId>_) e apaga no fim.Como rodar
npm run test:e2e -- multi-tenant
O artifact PNG fica em
test-results/multi-tenant-monitor-A-<runId>.png e serve como evidência em call de segurança.