Controlando o acesso
O controle de acesso é aplicado em quatro camadas independentes. Cada uma é avaliada em toda requisição, e nenhuma depende de outra ter feito seu trabalho.
| Camada | Decide | Aplicada |
|---|---|---|
| Isolamento entre organizações | Quais linhas existem para quem consulta | No banco de dados |
| Permissões | Se quem consulta pode executar esta ação | Na borda da requisição |
| Políticas ABAC | Se quem consulta pode ver este registro específico | No registro, ao carregá-lo |
| Mascaramento de campos | Se quem consulta pode ver este valor específico | Quando a resposta é gerada |
O empilhamento é o desenho. Um defeito numa camada não abre as outras, e a mais interna é aplicada pelo banco de dados, não pelo código da aplicação.
Isolamento entre organizações
A seção de administração. Cada camada descrita abaixo é configurada em sua própria tela aqui.
Todo registro pertence a exatamente uma organização, e o isolamento é aplicado no banco de dados. Uma consulta que esquece de filtrar por organização não vaza — não devolve nada.
É por isso que uma requisição entre organizações retorna "não encontrado" e não "proibido": a linha é genuinamente invisível, não meramente recusada.
Permissões
A autorização é expressa como códigos de permissão no formato
resource.action — entity.read, match-profile.update. Todo endpoint declara os
códigos que exige.
Papéis agrupam códigos. Usuários têm papéis diretamente ou por grupos, e suas permissões efetivas são a união.
Permissões efetivas são resolvidas por requisição, não gravadas no token de quem consulta. Conceder ou revogar acesso vale na requisição seguinte, não quando o token expirar.
Políticas ABAC
Permissões respondem "esta pessoa pode ler entidades?". Políticas ABAC respondem "esta pessoa pode ler esta entidade?" — usando atributos de quem consulta, do registro e da requisição.
Quatro tipos de condição são aplicados:
| Condição | Exemplo |
|---|---|
| Tipo de entidade | Negar acesso a um tipo de registro |
| Valor de atributo | Negar registros com uma classificação específica |
| Relacionamento | Permitir apenas registros relacionados a quem consulta |
| Consentimento | Permitir apenas enquanto um consentimento estiver ativo |
Regras são negação-vence: uma negação sempre prevalece, independentemente da ordem. Sobre uma base que permite por padrão, elas atuam como uma sobreposição de negação sobre a camada de permissões.
Uma negação que corresponderia a toda requisição é rejeitada ao salvar, porque trancaria a organização para fora dos próprios dados.
A administração do controle de acesso é deliberadamente isenta. Você nunca pode escrever uma regra que torne o próprio controle de acesso ingerenciável.
Mascaramento de campos
O mascaramento redige valores nas respostas conforme quem pergunta — mascaramento total, parcial, hash ou omissão.
O mascaramento é aplicado quando a resposta é gerada, em uma única passagem sobre cada entidade nela. É isso que o torna incontornável: não existe endpoint que devolva o valor sem máscara a quem não tem permissão, porque o mascaramento não é implementado por endpoint.
Ele se aplica uniformemente a atributos de entidade, rótulos de exibição, resultados de busca, telas de comparação e valores de auditoria.
Identidade
Usuários e grupos são provisionados a partir do seu provedor de identidade, nunca criados à mão. A entrada é autenticação federada real; não há armazenamento local de senhas nem atalho de desenvolvimento que se comporte de forma diferente da produção.
A seguir
Última verificação no commit d3c2586b (2026-08-03)