Row Level Security: a proteção que age quando o código erra
A maioria dos vazamentos de dado não vem de invasão, vem de uma consulta mal escrita. O que é isolamento no nível do banco e por que ele é a rede sob o trapézio.
Quase todo sistema com dados de vários usuários funciona assim: a aplicação recebe o pedido, descobre quem está pedindo e monta uma consulta ao banco filtrando por aquele usuário. Funciona — enquanto o filtro estiver certo em todos os lugares.
O problema é a quantidade de lugares. Um sistema de saúde tem dezenas de consultas ao banco, escritas ao longo de anos por pessoas diferentes. Basta uma esquecer o filtro para que um pedido devolva o registro de outro paciente. E esse tipo de falha não faz barulho: a tela abre normalmente, com o dado errado.
Mover a regra para o banco
Row Level Security (RLS) inverte a lógica. Em vez de cada consulta lembrar de filtrar, a regra vive no próprio banco, ligada à tabela: uma política declara quem pode ver cada linha, e o banco aplica isso a toda consulta, venha de onde vier.
No SUSVIDA, as políticas dizem que um exame é visível para o paciente dono dele, e para o médico que tem um compartilhamento aceito com aquele paciente. Uma consulta que "esqueça" o filtro não devolve dado alheio — devolve vazio, porque o banco não entrega o que a política não permite.
Por que isso é diferente de criptografia
Criptografia protege o dado de quem não deveria ter acesso ao armazenamento — disco roubado, backup vazado. RLS protege de quem tem acesso legítimo ao sistema mas não àquele registro. São ameaças distintas e uma não cobre a outra; um sistema que só tem criptografia está protegido contra o ladrão de disco e não contra a consulta mal escrita.