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

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.