RLS (Row Level Security)
RLS é a política de banco de dados que isola cada linha por cliente — no escritório contábil, garante que a empresa A nunca veja dado fiscal da empresa B.
RLS (Row Level Security) é um mecanismo de banco de dados — nativo no PostgreSQL — que restringe quais linhas de uma tabela cada usuário pode ver ou alterar, aplicando a regra direto no banco, não no código da aplicação.
Pro escritório contábil que atende dezenas de clientes na mesma base de dados, é a diferença entre “confiamos que o sistema filtra certo” e “o banco garante que o cliente A nunca vê nota fiscal do cliente B, mesmo se alguém esquecer um filtro no código”. Seus dados com você começa aqui: dentro da camada que guarda o dado, não numa promessa da aplicação por cima.
Como funciona na prática
Cada política RLS é uma regra anexada a uma tabela — uma cláusula WHERE que o Postgres aplica sozinho em toda consulta, venha de onde vier. Você define que lancamentos_fiscais só retorna linhas onde cliente_id = current_setting('app.cliente_atual'). Depois disso nenhuma query esquece o filtro — ele não está no código, está no banco.
Ferramentas como Supabase, que rodam Postgres por baixo, usam RLS como base pra multi-tenant: um app só, uma base só, isolamento linha por linha.
Por que importa pro escritório contábil
Escritório contábil pequeno atende 30, 50, 100 empresas no mesmo sistema — e boa parte confia só em login e senha pra separar quem vê o quê. Funciona até alguém copiar uma query errada, até um estagiário logar com credencial de administrador, ou até um filtro de tela falhar calado.
Número antes de promessa: se o seu sistema atual não usa RLS (ou equivalente), pergunte pro fornecedor como ele garante, linha por linha, que o cliente A não acessa dado fiscal do cliente B. Se a resposta for “confia no código da aplicação”, existe risco de vazamento — e um problema de LGPD (Art. 46, medidas técnicas de segurança) esperando pra acontecer.
Erro comum: RLS ligado só nas tabelas “óbvias”
O erro mais comum é ativar RLS nas tabelas evidentes — clientes, lançamentos — e esquecer a tabela nova criada 6 meses depois: relatório, log, exportação. Postgres não liga RLS por padrão em tabela nova; alguém precisa rodar ENABLE ROW LEVEL SECURITY toda vez que uma nasce. Sem processo documentado, isolamento vira sorte.
Como aplicar hoje
Três passos pra começar:
- Audite as tabelas que guardam dado de mais de um cliente na mesma base — a maioria dos sistemas contábeis tem isso.
- Ative RLS por tabela, com política testada de verdade — usuário real tentando acessar dado que não é dele, não só a política criada e esquecida.
- Documente o processo pra toda tabela nova nascer com RLS ligado, em vez de virar reforma depois do susto.
Montar essa isolação do zero — banco com RLS, backup testado, auditoria de quem acessou o quê — é o tipo de projeto que a iAvancada estrutura pra quem atende múltiplos clientes na mesma base.
Termos relacionados
- DPA (Data Processing Agreement) — o contrato que deveria citar como o fornecedor isola seus dados
- Audit trail em IA — o log que prova quem acessou o quê, complemento do RLS
- Disaster recovery em IA — isolamento não substitui backup testado