Pular para o conteúdo principal

Restrinja o acesso a registros individuais com políticas ABAC

As permissões respondem este usuário pode ler entidades? Uma política ABAC — controle de acesso baseado em atributos — responde este usuário pode ler esta entidade?, usando atributos de quem consulta, do registro e da requisição.

Antes de começar

  • abac-policy.create para criar políticas e abac-policy.read para revisá-las.
  • Os papéis que você pretende alcançar já existem (componha papéis).

1. Entenda a precedência da negação antes de escrever

Uma negação sempre vence. Não é "a regra de maior prioridade vence", nem "a mais específica vence" — se qualquer política negar a requisição, ela é negada, independentemente do que a permita. A prioridade ordena a lista na tela; ela não faz parte da decisão.

A base é permitir. As políticas são uma camada de negação sobre as permissões já concedidas, não uma segunda lista de permissões.

2. Escolha a condição que expressa a restrição

A tela de políticas ABAC listando quatro políticas de negação com efeito, prioridade, estado e condições Quatro políticas, todas de negação, cada uma com um escopo diferente: por tipo de entidade, por valor de atributo, por relacionamento e por consentimento. A coluna Conditions resume aquilo em que cada uma se baseia.

CondiçãoNega a menos que…Use para
Tipo de entidadeo registro seja de um tipo permitidoManter um papel fora de uma classe inteira de registro
Valor de atributoo atributo do registro correspondaRegistros com uma classificação, jurisdição ou marcação
Relacionamentoquem consulta esteja relacionado ao registro"Só quem está ligado a este cliente pode abri-lo"
Consentimentoum consentimento ativo cubra o registroTratamento lícito apenas enquanto houver consentimento

3. Crie a política

O formulário de nova política ABAC, com o efeito, o campo de prioridade marcado como apenas ordenação, e as seções de sujeito e ação O próprio formulário declara o modelo: "A deny always wins. Priority only changes the sort order, never the decision" — e o campo de prioridade é rotulado (sort only). Abaixo do efeito vêm o sujeito (quem), a ação e as condições.

Uma negação sem condições é recusada

Uma política que corresponderia a toda requisição é rejeitada ao salvar. Sob precedência da negação, ela trancaria o tenant fora dos próprios dados — inclusive fora da tela necessária para removê-la.

A integridade referencial também é verificada: uma política que cite um código de permissão, papel, tipo de relacionamento ou tipo de consentimento inexistente é recusada. Uma política não pode silenciosamente não fazer nada por causa de um erro de digitação.

Uma política ABAC salva, mostrando efeito, prioridade, descrição, papéis de sujeito e códigos de ação Uma política salva: o efeito, a prioridade marcada como (sort only), a quem se aplica e as ações que cobre. As condições vêm abaixo. Uma aba Recent matches mostra onde ela realmente disparou — é o que abrir quando um curador relata ter sido recusado.

4. Saiba onde ela é aplicada

Uma política é avaliada duas vezes, e é a segunda vez que a sustenta:

  • No limite da requisição, contra o que se sabe antes de qualquer registro ser carregado — quem está perguntando, qual ação, o contexto da requisição.
  • Contra cada registro, depois de carregado.

Esse segundo ponto é o que torna o comportamento previsível em listas. Quando o registro pedido diretamente é negado, a requisição é recusada. Quando um registro dentro de uma resposta é negado — uma linha de uma lista, a contraparte de um relacionamento, um registro consolidado, um lado de um par de correspondência — ele é removido da resposta, e a contagem ao lado dele diminui junto. Quem consulta nunca recebe um marcador no lugar de algo que não pode ver.

A administração do controle de acesso é isenta

As políticas nunca controlam as telas que gerenciam políticas, papéis, grupos e permissões. Uma política pode restringir dados; ela nunca pode tornar o próprio controle de acesso ingerenciável.

5. Verifique com uma conta real

Entre como um usuário que a política atinge — não como um administrador imaginando o resultado.

  • Confirme que um registro negado está ausente, e não com erro.
  • Confirme que as contagens refletem a ausência.
  • Confirme que um registro não coberto continua acessível.
  • Confirme que alguém fora do papel atingido não é afetado.
Teste com a conta, não com a teoria

Uma pessoa detém a união dos seus papéis. Uma política que atinge um deles se aplica independentemente do que os outros concedem — isso é precedência da negação — mas quais registros ela vê também depende de permissões sobre as quais a política nada diz.

A seguir