Row-level security explicada para fundadores não técnicos

Row-level security explicada: a RLS (segurança ao nível da linha) é uma funcionalidade da base de dados que filtra automaticamente todas as consultas para que cada cliente só possa ver os seus próprios dados — mesmo que o código da tua aplicação tenha bugs. Defines a regra uma vez, na base de dados, e ela não pode ser contornada. É, honestamente, a razão por que durmo descansado.

Se estás a construir um SaaS com IA e não és técnico, a RLS é o único conceito de segurança que vale mesmo a pena perceber. Eis o que é, porque é melhor do que todas as alternativas e a checklist para entregares à tua IA.

Row-level security explicada: a analogia do segurança à porta

Imagina que a tua base de dados é uma sala de ficheiros e que os registos de cada cliente são pastas lá dentro. Sem RLS, a porta da sala de ficheiros está aberta e dependes de cada funcionário — de cada pedaço do código da tua aplicação — para se lembrar, sempre, de ir buscar só as pastas do cliente certo. Um momento de esquecimento e alguém sai de lá com os ficheiros de um concorrente.

A RLS põe um segurança dentro da própria sala de ficheiros. O segurança verifica a identificação de quem pede e só entrega, fisicamente, as pastas que pertencem à organização dessa pessoa. Não importa se o funcionário se esquece de pedir da forma certa, ou se pede tudo — o segurança filtra o que sai. Todos os pedidos. Automaticamente. Sem exceções.

Tecnicamente: em vez de ser a tua aplicação a filtrar os dados ("mostra só as linhas deste cliente"), defines essa regra uma vez, dentro da base de dados, como uma política. A partir daí, todas as consultas são filtradas antes de qualquer dado sair da base de dados. Está integrada no PostgreSQL, e plataformas como o Supabase fazem dela uma funcionalidade de primeira linha.

Porque é que filtrar no código da aplicação não chega

Eis a verdade desconfortável sobre a alternativa. Sem RLS, o isolamento dos dados depende de um humano — ou de uma IA — se lembrar de acrescentar "só para este cliente" em todos os sítios onde o teu produto toca em dados. Centenas de sítios. Para sempre. Cada funcionalidade nova, cada correção rápida, cada alteração feita a altas horas.

Os humanos esquecem-se. A IA também se esquece — pede-lhe uma funcionalidade de relatórios numa terça-feira cansada e ela pode, toda contente, consultar tudo. Um exemplo real: um programador esqueceu-se de filtrar por organização num endpoint de relatórios. Sem RLS, teria exposto dados de clientes a concorrentes. Com RLS, a base de dados bloqueou automaticamente o acesso não autorizado. Ninguém reparou até à revisão do código — porque não aconteceu nada de mal.

As pessoas da segurança chamam a isto defesa em profundidade: não dependas de uma única camada ser perfeita. O código da tua aplicação filtra os dados (primeira camada) e a RLS impõe isso na base de dados (segunda camada). Se a primeira camada falhar — um bug, um mau prompt, uma alucinação da IA — a segunda aguenta. Isto conta a dobrar quando é a IA a escrever a maior parte do teu código, porque o código gerado por IA falha de formas que não vais detetar até sair caro.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

As quatro permissões de que cada tabela precisa

As políticas de RLS existem em quatro variantes, uma para cada coisa que um utilizador pode fazer com os dados. Pensa nelas como quatro perguntas que o segurança faz:

Todas as tabelas com dados de clientes recebem as quatro. O sistema é só isto: a etiqueta organization_id em todas as tabelas diz a quem pertence cada linha; as quatro políticas fazem a base de dados impô-lo.

Como aprendi RLS (com o Claude)

Vou ser honesto — não aprendi RLS num curso de segurança. Aprendi com o Claude. Quando comecei com o Supabase, perguntei: "Como garanto que os utilizadores só veem os dados da sua própria organização?" O Claude explicou-me as políticas de RLS. Implementei-as em todas as tabelas. Agora é automático.

É esse o ponto para os fundadores não técnicos: não escreves estas políticas à mão. Percebes o conceito — o segurança na sala de ficheiros, quatro permissões por tabela — e dás instruções à tua IA: "Ativa a row-level security em todas as tabelas, com políticas para ver, criar, atualizar e eliminar, restritas à organização do utilizador." A IA produz as políticas; a base de dados impõe-nas para sempre.

Todas as tabelas da minha plataforma, o FIKR Space, estão protegidas desta forma. Sem exceções. Isso só é gerível porque a regra é imposta pela base de dados, não pela minha memória — a mesma razão por que defendo desenhar a base de dados antes de escrever qualquer funcionalidade.

A checklist de RLS do fundador

Não precisas de escrever uma linha de SQL. Precisas de insistir em cinco coisas:

1. RLS ativa em todas as tabelas com dados de clientes. Pergunta diretamente à tua IA: "A row-level security está ativa em todas as tabelas? Lista as que não estão."
2. Os quatro tipos de política em cada tabela — ver, criar, alterar, eliminar. Uma tabela só com a política de ver continua a deixar fugir dados pelas escritas.
3. Políticas restritas por organização, alinhadas com a tua configuração multi-tenant.
4. Testa com duas contas. Cria duas organizações de teste. Entra como uma e tenta ler e editar os dados da outra. Se vier alguma coisa, para e corrige antes de lançar.
5. Volta a verificar depois de cada tabela nova. Faz de "ativa a RLS com as quatro políticas padrão" uma regra permanente que a tua IA aplica a todas as tabelas que cria — não algo de que te lembras funcionalidade a funcionalidade.

Um código de aplicação mais simples é o bónus: quando a base de dados impõe o isolamento, as tuas funcionalidades não precisam de lógica de filtragem por cliente espalhada por todo o lado. Segurança por defeito, menos código, e deixas de te preocupar com a tal consulta de que alguém se esqueceu.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Perguntas frequentes

O que é a row-level security, em termos simples?

É uma regra que defines uma vez dentro da base de dados e que filtra automaticamente todas as consultas, para que cada utilizador só veja as linhas que pertencem à sua organização. Como um segurança dentro da sala de ficheiros: seja quem for que peça, e seja como for, só saem as pastas certas.

Preciso de RLS se a minha aplicação já filtra os dados?

Sim. A filtragem na aplicação depende de cada pedaço de código — escrito por humanos ou por IA — se lembrar do filtro, para sempre. A RLS é a rede de segurança para quando algo se esquece: um bug na tua aplicação deixa de poder tornar-se uma fuga de dados, porque é a própria base de dados que bloqueia a fuga.

Consigo configurar a RLS sem saber SQL?

Sim. Percebe o conceito e depois dá instruções à tua IA: "Ativa a row-level security em todas as tabelas, com políticas para ver, criar, atualizar e eliminar, restritas à organização do utilizador." Depois verifica com duas contas de teste a tentar ler os dados uma da outra. A IA escreve as políticas; a checklist é tua.

A RLS torna o meu produto mais lento?

Não de forma significativa, se as tuas tabelas estiverem bem configuradas — o segredo é ter um índice na coluna de organização que as políticas verificam (algo a incluir nas instruções permanentes da tua IA). Plataformas com milhares de tabelas protegidas funcionam exatamente com este padrão, e o FIKR Space também.