Segurançaדִּגְלוֹ
RBAC: cada um junto à sua bandeira
Como o acesso por papel organiza o acampamento, por que os papéis explodem, como minerá-los do uso real e quando RBAC sozinho não basta.
שֹׁפְטִים וְשֹׁטְרִים תִּתֶּן לְךָ בְּכָל שְׁעָרֶיךָ
shoftim veshotrim titen lecha bechol shearecha · juízes e oficiais porás em todas as tuas portas · Devarim 16:18
Blog/Artigos · Segurança
ABAC: juízes e oficiais em todas as tuas portas
Decisão por atributo, o modelo PEP-PDP-PIP, política declarativa e a combinação com RBAC.
Devarim manda pôr juízes e oficiais em todas as portas, para que cada caso seja julgado onde acontece, pelo que ele traz, não por uma regra fixa decidida longe dali. ABAC é esse juízo à porta aplicado ao acesso: a decisão não olha só quem pede, olha os atributos da requisição, o recurso, a ação e o contexto, e decide caso a caso. Onde o RBAC pergunta que papel você tem, o ABAC pergunta, aqui e agora, você pode isto.
A decisão olha o contexto, não só o papel
RBAC decide pela função: você é analista, então pode o que analista pode. ABAC decide por atributos combinados: atributos de quem pede (departamento, nível, projeto), do recurso (classificação, dono, região), da ação (ler, aprovar) e do ambiente (horário, dispositivo, risco). A política é uma regra sobre esses atributos, avaliada a cada requisição.
Isso permite decisões que o papel não expressa: aprovar pagamento apenas do próprio centro de custo, ler o prontuário apenas do próprio hospital, acessar o console apenas em horário comercial e de dispositivo gerenciado. O acesso deixa de ser um crachá que abre tudo da função e passa a ser um juízo sobre a circunstância exata do pedido.
Figura 1As quatro categorias de atributo que compõem uma decisão ABAC
| Categoria | Exemplos | Pergunta que responde |
|---|---|---|
| Sujeito | departamento, nível, projeto, certificação | quem está pedindo |
| Recurso | classificação, dono, região, centro de custo | sobre o que é o pedido |
| Ação | ler, escrever, aprovar, exportar | o que se quer fazer |
| Ambiente | horário, dispositivo gerenciado, risco da sessão, rede | em que circunstância |
Quem julga e quem executa: PEP, PDP e PIP
ABAC separa quem decide de quem aplica. O ponto de aplicação (PEP) fica na frente do recurso, intercepta a requisição e pergunta se pode. O ponto de decisão (PDP) avalia a política contra os atributos e responde permite ou nega. O ponto de informação (PIP) fornece os atributos que faltam, buscando na fonte de identidade ou no catálogo do recurso.
Essa separação é o que torna o modelo sustentável. A política vive em um lugar só, o PDP, e não espalhada em cada aplicação. Trocar uma regra é mudar a política central, não reescrever dez sistemas. E o mesmo juízo vale para toda porta, porque toda porta consulta o mesmo juiz, em vez de cada uma inventar seu próprio critério.
Figura 2O caminho de uma requisição no modelo ABAC
- 01Requisição no recursoa identidade pede uma ação; o PEP intercepta
- 02PEP pergunta ao PDPenvia sujeito, recurso, ação e o contexto que tem
- 03IAPDP busca atributoso PIP completa o que falta na fonte de identidade
- 04PDP avalia a políticaa regra sobre atributos resolve em permite ou nega
- 05PEP aplica a decisãolibera ou bloqueia, e registra o motivo na trilha
A política vive só no PDP. Trocar a regra é mudar um lugar, e toda porta passa a julgar diferente sem tocar em nenhuma aplicação.
Política declarativa e testável
A política ABAC é declarativa: descreve a condição, não o passo a passo. Isso a torna legível e, principalmente, testável. Uma regra sobre atributos pode ser exercida com casos, cada caso um conjunto de atributos com o veredito esperado, e o conjunto de testes vira a especificação viva do que a política realmente decide.
Sem esses testes, política declarativa é armadilha: uma condição sutil abre acesso que ninguém pretendia, e o erro só aparece em produção. Com eles, cada mudança de regra passa por um caso que confirma o permite e um caso que confirma o nega. A política entra no mesmo rito de código de qualquer mudança sensível: revisão, teste e histórico.
Figura 3Política ABAC declarativa com casos de teste
politica: aprovar_pagamento_da_propria_regiao
permite: pagamento:aprovar
quando:
- sujeito.papel == "gestor"
- sujeito.regiao == recurso.regiao
- recurso.valor <= sujeito.alcada
- ambiente.mfa == true
casos:
- nome: gestor aprova na propria regiao dentro da alcada
sujeito: {papel: gestor, regiao: sul, alcada: 50000}
recurso: {regiao: sul, valor: 12000}
ambiente: {mfa: true}
espera: permite
- nome: gestor tenta aprovar de outra regiao
sujeito: {papel: gestor, regiao: sul, alcada: 50000}
recurso: {regiao: norte, valor: 12000}
ambiente: {mfa: true}
espera: negaABAC e RBAC andam juntos
A escolha não é ABAC contra RBAC, é a combinação. RBAC dá a base grossa e legível: o papel define o grande conjunto do que a função pode. ABAC afina com o contexto: dentro do que o papel permite, os atributos restringem ao caso concreto. O papel diz que gestor aprova pagamento; o atributo diz que este gestor aprova este pagamento, da sua região, dentro da sua alçada, com MFA.
Começar tudo em ABAC puro costuma dar uma teia de políticas que ninguém audita. Começar em RBAC e adicionar ABAC onde a decisão depende de contexto costuma envelhecer melhor: poucos papéis para a legibilidade, atributos para as condições que o papel não expressa. O juiz à porta não substitui a ordem do acampamento; ele julga o caso dentro dela.
Figura 4RBAC como base, ABAC como afinação, da decisão grossa à fina
- Papel (RBAC) basedefine o grande conjunto do que a função pode fazer
- Atributo do sujeito quemregião, alçada e projeto restringem dentro do papel
- Atributo do recurso o quêdono, classificação e região do alvo entram na decisão
- Contexto (ABAC) quandohorário, dispositivo e MFA fecham o caso concreto
Para levar
ABAC põe um juiz em cada porta: a decisão de acesso olha os atributos do sujeito, do recurso, da ação e do ambiente, e julga o caso concreto, não só a função. Ele se sustenta com o PDP separado da aplicação, política declarativa com testes e a base legível do RBAC por baixo. A IA traduz regra de negócio em política, gera os casos de fronteira e explica a negação; pôr o juiz certo em cada porta continua sendo decisão de quem responde pelo acesso.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
