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.

Diagrama comparativo de modelos de autorização entre controle por papéis RBAC e políticas contextuais dinâmicas por atributos ABAC
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:

  1. Atributos do Sujeito (Usuário): Cargo, departamento, certificados de segurança, tempo de casa, filial de registro.
  2. Atributos do Recurso (Dado/Objeto): Tipo de documento, classificação de confidencialidade (Público, Interno, Secreto), departamento proprietário.
  3. Atributos da Ação: Ler, Criar, Atualizar, Excluir, Exportar em PDF, Aprovar.
  4. 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:

  1. A aplicação recebe a requisição do usuário com o token JWT.
  2. O microsserviço repassa o contexto da chamada (usuário, recurso e ambiente) para o OPA em formato JSON.
  3. O motor avalia as políticas declarativas escritas em linguagem Rego e responde com uma decisão booleana simples (allow: true ou allow: 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.

Explorar este tema no Grafo de Conhecimento