Software · Segurança & Identidade
RBAC versus ABAC: Da Autorização Baseada em Papéis às Políticas Dinâmicas por Atributos
Como evoluir do controle de acesso estático baseado em funções (RBAC) para políticas granulares orientadas a atributos (ABAC) sem sofrer com a explosão de perfis.
Neste artigo
No gerenciamento de identidade e controle de acesso corporativo (IAM), conceder o acesso correto ao usuário certo no momento apropriado representa um dos maiores desafios de segurança e governança. Conforme as empresas crescem e adotam trabalho remoto, microsserviços e exigências estritas de privacidade de dados (como LGPD e GDPR), os modelos tradicionais de permissão baseados em grupos estáticos mostram sinais evidentes de esgotamento.
O dilema clássico de engenharia manifesta-se na escolha entre dois paradigmas de autorização: o RBAC (Role-Based Access Control), estruturado em papéis fixos, e o ABAC (Attribute-Based Access Control), orientado à avaliação dinâmica de atributos contextuais.
RBAC: A Simplicidade Inicial e o Fenômeno da Explosão de Papéis
O Controle de Acesso Baseado em Funções (RBAC) é o modelo mais amplamente utilizado no setor. A premissa é direta: usuários não recebem permissões individuais; em vez disso, permissões são associadas a papéis organizacionais (Roles como "Administrador", "Gerente" ou "Auditor"), e os usuários são atribuídos a esses papéis:
flowchart LR
User["<b>Usuário</b>"] -->|"Pertence a"| Role["<b>Papel: GerenteFinanceiro</b>"]
Role -->|"Concede"| Perm["<b>Permissão: Acesso a Relatórios</b>"]
O Desafio da "Explosão de Papéis" (Role Explosion)
O RBAC funciona com extrema clareza enquanto as regras de negócio são simples. Contudo, quando a organização precisa impor restrições refinadas, o modelo colapsa sob sua própria rigidez estrutural.
Imagine que a diretoria estabeleça as seguintes regras:
- "Um gerente financeiro só pode aprovar pagamentos da filial de São Paulo."
- "Se o pagamento for superior a R$ 100.000, exige-se aprovação em horário comercial."
- "Se o acesso ocorrer a partir de uma rede externa não corporativa, o acesso a faturas confidenciais é bloqueado."
Para atender a esses requisitos utilizando apenas RBAC puro, a equipe de segurança é forçada a multiplicar os perfis de acesso: cria-se Gerente_SP, Gerente_RJ, Gerente_SP_Acima100k, Gerente_Remoto_SomenteLeitura... Em poucos anos, o sistema acumula centenas de papéis sobrepostos e despadronizados. A auditoria torna-se inviável e os usuários acumulam privilégios indevidos por herança histórica.
ABAC: Autorização Granular Orientada a Atributos
O Controle de Acesso Baseado em Atributos (ABAC) supera essa limitação ao transformar a autorização em um motor dinâmico de avaliação de regras booleanas. Em vez de perguntar apenas "qual é o papel deste usuário?", o motor do ABAC analisa múltiplos vetores de contexto no instante exato em que a requisição de acesso é despachada:
flowchart TD
subgraph Atributos["Vetores de Contexto & Atributos"]
S["<b>Atributos do Sujeito</b><br/>• Departamento: Financeiro<br/>• Filial: São Paulo<br/>• Alçada Máxima: R$ 50.000"]
R["<b>Atributos do Recurso</b><br/>• Documento: Fatura Fiscal<br/>• Filial Origem: São Paulo<br/>• Valor: R$ 35.000"]
E["<b>Atributos do Ambiente</b><br/>• Horário Comercial: Sim<br/>• Conexão: VPN Corporativa<br/>• Conformidade do Endpoint: Sim"]
end
PDP["<b>Motor de Políticas ABAC (Policy Decision Point)</b><br/>Regra: Permitir SE (Sujeito.Dept == Financeiro) E<br/>(Recurso.Filial == Sujeito.Filial) E<br/>(Horário Comercial) E (Conforme)"]
Decisao{"Avaliação da Política"}
Permitir["<b>ALLOW</b> (Acesso Autorizado)"]
Negar["<b>DENY</b> (Acesso Bloqueado)"]
S --> PDP
R --> PDP
E --> PDP
PDP --> Decisao
Decisao -->|"Condições Atendidas"| Permitir
Decisao -->|"Qualquer Violação"| Negar
Os atributos dividem-se em quatro categorias:
- Atributos do Sujeito (Usuário): Cargo, departamento, certificados de segurança, tempo de casa, filial de registro.
- Atributos do Recurso (Dado/Objeto): Tipo de documento, classificação de confidencialidade (Público, Interno, Secreto), departamento proprietário.
- Atributos da Ação: Ler, Criar, Atualizar, Excluir, Exportar em PDF, Aprovar.
- Atributos do Ambiente (Contexto): Hora do dia, dia da semana, país de origem do IP, status de criptografia de disco do notebook solicitante.
Com o ABAC, uma única política declarativa atende a toda a corporação de forma dinâmica: "Permitir que usuários do departamento financeiro aprovem faturas da sua própria filial se o valor for compatível com sua alçada e a requisição originar-se de um dispositivo corporativo em conformidade". Nenhuma nova função estática precisa ser criada no banco de dados.
Comparativo Estrutural: RBAC versus ABAC
A escolha entre os modelos depende do nível de complexidade e auditoria exigido pela aplicação:
| Dimensão | RBAC (Controle por Papéis) | ABAC (Controle por Atributos) |
|---|---|---|
| Complexidade Inicial | Baixa: tabelas relacionais simples (User, Role, Permission). |
Média a Alta: exige um motor de avaliação de políticas (ex: OPA, Cedar). |
| Flexibilidade | Estática; regras contextuais exigem código customizado na aplicação. | Totalmente dinâmica e adaptável a variáveis ambientais em tempo real. |
| Manutenibilidade a Longo Prazo | Sofre com a multiplicação descontrolada de papéis (Role Explosion). | Altíssima; poucas políticas atendem a cenários complexos de negócio. |
| Alinhamento com Zero Trust | Fraco; a função concede acesso contínuo sem avaliar o contexto. | Nativo; valida a postura do dispositivo e contexto a cada transação. |
Padrões de Implementação Moderna com OPA (Open Policy Agent)
Na arquitetura moderna de microsserviços, a lógica de autorização não deve permanecer espalhada em condicionais de código dentro dos controladores. Ferramentas de código aberto como o Open Policy Agent (OPA) desacoplam a decisão de autorização do código da aplicação:
- A aplicação recebe a requisição do usuário com o token JWT.
- O microsserviço repassa o contexto da chamada (usuário, recurso e ambiente) para o OPA em formato JSON.
- O motor avalia as políticas declarativas escritas em linguagem Rego e responde com uma decisão booleana simples (
allow: trueouallow: false).
Essa separação permite que a equipe de segurança corporativa altere as políticas de acesso em tempo real em um repositório centralizado, sem necessidade de recompilar ou fazer novas implantações das aplicações de negócio.