Autorização (RBAC e ABAC)

As decisões de autorização são quatro: qual modelo usar, onde fazer a conferência, onde a política mora e como isolar os dados de cada empresa.

Qual modelo

A maioria dos sistemas de negócio fica bem com RBAC mais atributos do recurso: o papel define o alcance de cada permissão (os próprios, os da equipe, todos), e um atributo do recurso, quase sempre o dono, decide o caso. O ReBAC compensa quando os usuários compartilham itens entre si e a pergunta "quem pode ver isto?" precisa de resposta rápida.

Cuidado com a explosão de papéis

Um sinal de que o RBAC puro não basta: papéis como gerente_sp, gerente_rj, gerente_sp_leitura. Cada combinação de regra com atributo virou um papel. A saída é tirar o atributo do nome do papel e colocá-lo na regra: o papel gerente, e a regra "na região do usuário".

Onde fazer a conferência

As camadas se somam. A conferência por objeto, a que evita o IDOR, só pode acontecer depois de carregar o recurso, ou dentro da consulta que o carrega. Um middleware na entrada da rota não basta.

Para as listagens, a regra vira filtro: "os pedidos que o usuário pode ler" precisa ser traduzido em WHERE cliente_id = $1 para clientes e em nenhum filtro para o suporte. Carregar tudo e filtrar na memória funciona com poucos registros e quebra a paginação.

Onde a política mora

O ponto em comum das quatro: um só lugar. O que dá errado é a regra espalhada em ifs pelas rotas, cada um com uma versão um pouco diferente.

O motor de políticas tem um custo que não aparece no começo. Ele precisa dos dados do recurso para decidir, e alguém tem de buscá-los e enviá-los a cada pergunta. Para regras de dono e de papel numa aplicação só, a função central no código é mais simples e igualmente segura.

Como isolar empresas

A segurança por linha só protege se as armadilhas medidas no nível Conceito forem evitadas:

1. A aplicação conecta com um usuário que não é dono das tabelas, nem superusuário, nem tem BYPASSRLS. Ou a tabela usa FORCE ROW LEVEL SECURITY, que no teste fez o dono respeitar a política, mas não o superusuário.
2. A empresa é definida com SET LOCAL, ou set_config(..., true), dentro da transação de cada pedido. Com SET, o valor ficou na conexão e vazou para o pedido seguinte.
3. A política trata o valor ausente, com nullif sobre o current_setting.
4. Um teste automatizado confere que uma consulta sem empresa definida devolve zero linhas.

Permissões no token ou consultadas

Uma combinação comum: o token leva o identificador e escopos amplos e estáveis; papéis e permissões finas vêm da base, com cache de segundos ou minutos.

Resumo da decisão

1. RBAC com atributos do recurso: papéis que definem o alcance, e o dono decide o caso. ReBAC quando o compartilhamento é central.
2. Conferência por objeto em toda rota que recebe um identificador, depois de carregar o recurso.
3. Uma função ou um motor de políticas, num só lugar, negando o que não estiver permitido.
4. 404 para recursos que o usuário não pode ver; 403 para ações proibidas em recursos visíveis.
5. Isolamento de empresas no banco com segurança por linha, sem dono da tabela e com SET LOCAL.
6. Permissões consultadas quando mudam ou dão muito poder, em vez de presas no token.

O próximo nível mostra a mesma política nas cinco linguagens e num motor de políticas, testadas com os mesmos dez pedidos, e a segurança por linha no Postgres.