RBAC, ABAC e ReBAC — modelos de controle de acesso

Autorização — a decisão de o que uma identidade autenticada pode fazer — é um problema que os sistemas resolvem mal com surpreendente frequência. Não porque a lógica de negócio seja complexa, mas porque o modelo de dados escolhido para representar políticas de acesso cresce de formas que o design original não antecipou. Sistemas começam com "admin pode tudo, user pode ler" — uma distinção que cabe em um if — e evoluem para "usuário pode editar este documento se for o autor, ou se tiver permissão explícita de edição, ou se for membro de um grupo que tem acesso ao projeto ao qual o documento pertence, ou se for admin mas não estiver fora do horário de expediente". Nesse ponto, o if está muito além do ponto de retorno.

RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control) e ReBAC (Relationship-Based Access Control) são modelos formais para representar políticas de autorização. Cada um resolve um problema diferente com trade-offs diferentes. A escolha incorreta — RBAC para um problema de relacionamento, ABAC para um problema de hierarquia simples — produz sistemas difíceis de manter e impossíveis de auditar. Este conceito cobre os três modelos em profundidade, com as implementações concretas mais usadas em produção e os critérios de escolha.

RBAC — Role-Based Access Control

RBAC foi formalizado por Ferraiolo e Kuhn em 1992 e pelo NIST em 2000 (NIST Special Publication 800-192). O modelo central é simples: usuários são atribuídos a papéis, e papéis têm permissões. A query de autorização é: "o usuário U tem o papel R? O papel R tem a permissão P? Então conceder."

-- Schema RBAC básico em SQL
CREATE TABLE roles (id SERIAL PRIMARY KEY, name TEXT UNIQUE NOT NULL);
CREATE TABLE permissions (id SERIAL PRIMARY KEY, action TEXT, resource TEXT,
  UNIQUE(action, resource));
CREATE TABLE role_permissions (role_id INT REFERENCES roles, permission_id INT REFERENCES permissions,
  PRIMARY KEY(role_id, permission_id));
CREATE TABLE user_roles (user_id INT, role_id INT REFERENCES roles,
  PRIMARY KEY(user_id, role_id));

-- Verificação de permissão
SELECT EXISTS (
  SELECT 1 FROM user_roles ur
  JOIN role_permissions rp ON ur.role_id = rp.role_id
  JOIN permissions p ON rp.permission_id = p.id
  WHERE ur.user_id = $1
    AND p.action = $2    -- ex: 'delete'
    AND p.resource = $3  -- ex: 'documents'
);

O modelo básico é escalável para sistemas com dezenas de papéis e centenas de permissões. O problema surge quando as permissões se tornam muito granulares ou quando os papéis proliferam — o que Ferraiolo e Kuhn chamaram de "role explosion". Times que criam um papel por combinação de permissões únicas chegam a centenas de papéis distintos, tornando a gestão impraticável.

RBAC hierárquico (RBAC-H) resolve parte do problema: papéis herdam permissões de papéis pai. super_admin herda de admin, que herda de editor, que herda de viewer. Permissões do papel pai são transitivas para os filhos. Isso reduz duplicação mas não resolve o problema fundamental de regras de acesso dependentes de contexto.

Implementação em código: a abordagem mais direta para APIs é decorator/middleware que verifica papéis antes de executar o handler. A complexidade de autorização fica nos decorators, não espalhada pelo código de negócio.

// Program.cs — configuração de políticas
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanEditDocuments", policy =>
        policy.RequireRole("admin", "editor"));

    options.AddPolicy("CanDeleteDocuments", policy =>
        policy.RequireRole("admin"));

    options.AddPolicy("CanPublish", policy =>
        policy.RequireClaim("feature_flags", "publishing_enabled")
              .RequireRole("editor", "admin"));
});

// Controller — aplicação da política
[HttpDelete("/documents/{id}")]
[Authorize(Policy = "CanDeleteDocuments")]
public async Task<IActionResult> Delete(int id)
{
    // Política verificada antes de entrar no handler
    var doc = await _docs.GetAsync(id);
    // Ainda precisa verificar ownership — RBAC não resolve isso
    if (doc.UserId != User.GetUserId() && !User.IsInRole("admin"))
        return Forbid();
    await _docs.DeleteAsync(id);
    return NoContent();
}

from functools import wraps
from fastapi import HTTPException, Depends

def require_role(*roles: str):
    def decorator(func):
        @wraps(func)
        async def wrapper(*args, current_user: User = Depends(get_current_user), **kwargs):
            if not any(role in current_user.roles for role in roles):
                raise HTTPException(status_code=403, detail="Insufficient permissions")
            return await func(*args, current_user=current_user, **kwargs)
        return wrapper
    return decorator

@router.delete("/documents/{doc_id}")
@require_role("admin", "editor")
async def delete_document(
    doc_id: int,
    current_user: User = Depends(get_current_user),
    db: AsyncSession = Depends(get_db),
):
    doc = await db.get(Document, doc_id)
    if not doc:
        raise HTTPException(404)
    # RBAC verifica papel — mas ownership precisa de verificação adicional
    if doc.user_id != current_user.id and "admin" not in current_user.roles:
        raise HTTPException(403, "Cannot delete document owned by another user")
    await db.delete(doc)
    await db.commit()

func RequireRole(roles ...string) func(http.Handler) http.Handler {
    roleSet := make(map[string]bool)
    for _, r := range roles { roleSet[r] = true }

    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            user := UserFromContext(r.Context())
            for _, role := range user.Roles {
                if roleSet[role] {
                    next.ServeHTTP(w, r)
                    return
                }
            }
            http.Error(w, `{"error":"forbidden"}`, http.StatusForbidden)
        })
    }
}

// Rotas com middleware de papel
r.With(RequireRole("admin", "editor")).Delete("/documents/{id}", deleteDocument)
r.With(RequireRole("admin")).Post("/documents/{id}/publish", publishDocument)

ABAC — Attribute-Based Access Control

ABAC, descrito pelo NIST no SP 800-162 (2014), generaliza RBAC: em vez de verificar apenas o papel do usuário, verifica atributos arbitrários do sujeito (usuário), do objeto (recurso), da ação, e do contexto. Uma política ABAC pode expressar: "usuários com atributo department=finance podem ler documentos com atributo classification=financial durante horário de trabalho (time BETWEEN 08:00 AND 18:00) de IPs na subnet corporativa".

A engine mais usada para ABAC em sistemas modernos é Open Policy Agent (OPA, CNCF), que usa a linguagem Rego para expressar políticas. OPA roda como sidecar ou como serviço externo e recebe um input JSON com o contexto da requisição; a política Rego retorna um resultado booleano (allow/deny) ou um objeto com detalhes.

# OPA — Política Rego para controle de documentos
package documents.authz

import future.keywords.if

# Por padrão, negar tudo
default allow := false

# Admin pode tudo
allow if {
    input.user.roles[_] == "admin"
}

# Autor pode editar seus próprios documentos em rascunho
allow if {
    input.action == "edit"
    input.document.user_id == input.user.id
    input.document.status == "draft"
}

# Editor pode publicar se document.status == "approved"
allow if {
    input.action == "publish"
    input.user.roles[_] == "editor"
    input.document.status == "approved"
    # Apenas durante horário de trabalho UTC-3
    time.clock(time.now_ns())[0] >= 8
    time.clock(time.now_ns())[0] < 18
}

# Input JSON para a query OPA — enviado pelo resource server
{
  "user": {
    "id": "user_123",
    "roles": ["editor"],
    "department": "content"
  },
  "action": "edit",
  "document": {
    "id": "doc_456",
    "user_id": "user_123",
    "status": "draft",
    "classification": "internal"
  },
  "context": {
    "ip": "10.0.5.42",
    "timestamp": "2026-05-12T14:30:00Z"
  }
}

A vantagem do ABAC com OPA é a separação entre política e código: as regras de negócio de autorização ficam em arquivos Rego versionados, testáveis, e atualizáveis sem redeploy do serviço. Times de segurança podem revisar e atualizar políticas sem acesso ao código da aplicação. O custo é a curva de aprendizado do Rego e a latência adicional da consulta ao OPA por requisição (mitigável com cache e modo em-processo).

ReBAC — Relationship-Based Access Control

Google Zanzibar, descrito no paper "Zanzibar: Google's Consistent, Global Authorization System" (USENIX ATC 2019), é o sistema de autorização que controla o acesso a Google Drive, Gmail, YouTube, e dezenas de outros produtos Google. O problema que Zanzibar resolve é fundamentalmente diferente do que RBAC e ABAC resolvem: autorização baseada em relacionamentos entre objetos.

Em um sistema de documentos colaborativo, a pergunta de autorização é: "o usuário U pode ler o documento D?" A resposta depende de uma cadeia de relacionamentos: U tem papel de viewer em D diretamente? U é membro de um grupo G que tem acesso a D? U tem acesso à pasta F que contém D? U tem acesso ao workspace W que contém F? Em RBAC, modelar essa hierarquia de containment requer queries SQL complexas com múltiplos joins recursivos. Em Zanzibar, a query é expressa como tuplas de relacionamento.

# Tuplas de relacionamento Zanzibar — armazenadas como (objeto, relação, usuário/grupo)
document:123#owner@user:alice         # alice é owner do documento 123
document:123#editor@group:beta-team   # o grupo beta-team é editor do doc 123
group:beta-team#member@user:bob       # bob é membro do grupo beta-team
folder:projects#document@document:123  # documento 123 está na pasta projects
folder:projects#viewer@user:charlie   # charlie tem viewer na pasta projects

# Query: "pode user:bob editar document:123?"
# Check: document:123#editor@user:bob
# → Expand: user:bob pode ser em group:beta-team#member
# → Expand: group:beta-team é document:123#editor
# → Sim, bob pode editar via grupo

# Query: "pode user:charlie ler document:123?"
# Check: document:123#viewer@user:charlie
# → Charlie não tem acesso direto
# → document:123 está em folder:projects
# → folder:projects#viewer@user:charlie → Sim

SpiceDB (Authzed) é a implementação open source mais madura de Zanzibar. Usa uma linguagem de schema chamada Authzed Schema Language (ASL) para definir os tipos de objeto e as relações possíveis, e expõe uma API gRPC para check de permissão, expand de permissão (quem tem acesso?), e list de recursos (quais recursos o usuário tem acesso?).

# SpiceDB schema — sistema de documentos
definition user {}

definition group {
  relation member: user
}

definition folder {
  relation parent: folder
  relation viewer: user | group#member
  relation editor: user | group#member

  permission view = viewer + editor + parent->view
  permission edit = editor + parent->edit
}

definition document {
  relation parent_folder: folder
  relation owner: user
  relation editor: user | group#member
  relation viewer: user | group#member

  permission view = viewer + editor + owner + parent_folder->view
  permission edit = editor + owner + parent_folder->edit
  permission delete = owner
}

O schema define que a permissão view de um documento é a union de viewers diretos, editors, o owner, e quem tem view na pasta pai — transitivamente. Isso é o que torna ReBAC poderoso para sistemas onde a hierarquia de containment define acesso. Google Drive, GitHub (repositórios em organizations), Notion (páginas em workspaces) e Dropbox são exemplos canônicos.

Qual modelo para qual problema

A decisão entre RBAC, ABAC e ReBAC não é de modismo técnico — é de adequação ao problema. Os critérios de escolha:

• Use RBAC quando o acesso é determinado pelo papel organizacional do usuário. "Admin pode tudo, gerente pode aprovar, analista pode visualizar" é RBAC. Simples de implementar, auditar, e explicar para stakeholders de negócio. O modelo falha quando papéis proliferam ou quando o acesso depende de atributos do recurso, não do usuário.
• Use ABAC quando o acesso depende de atributos dinâmicos de usuário, recurso, ação, ou contexto. Útil para multi-tenant SaaS onde cada tenant tem configurações de acesso diferentes, para compliance com regras temporais ou geográficas, e para classificação de dados (acesso a dados classificados requer clearance equivalente). O custo é complexidade de política e auditabilidade reduzida.
• Use ReBAC quando o acesso é determinado por relacionamentos entre objetos — hierarquia de containment, delegação de acesso, grupos aninhados. Google Drive, GitHub, sistemas de gerenciamento de documentos colaborativos. O custo é a complexidade do schema e a necessidade de um serviço de autorização externo (SpiceDB, Ory Keto, OpenFGA).

Na prática, sistemas maduros combinam modelos: RBAC para os casos simples (papéis organizacionais), ABAC para regras de contexto (horário, localização, classificação), e ReBAC para hierarquia de recursos. A tentação de escolher apenas um modelo e forçar todos os casos nele resulta em explosão de papéis (RBAC forçado), políticas incompreensíveis (ABAC forçado), ou schema de relacionamento monstruoso (ReBAC forçado).

Policy Decision Point e Policy Enforcement Point

Uma arquitetura de autorização bem separada distingue dois papéis: o Policy Decision Point (PDP) — onde a decisão de autorização é computada — e o Policy Enforcement Point (PEP) — onde a decisão é aplicada. Em sistemas simples, ambos estão no mesmo código; em sistemas maiores, o PDP é externalizado (OPA, SpiceDB) e o PEP é o middleware do resource server que chama o PDP e aplica o resultado.

A separação tem um custo — latência de rede por requisição de autorização — e um benefício — a lógica de autorização vive em um lugar só, versionável, testável, e atualizável sem redeploy. Para sistemas com múltiplos resource servers e políticas complexas, o benefício supera o custo. Para um monolito com regras simples, externalizar o PDP é over-engineering.

Decisões de engenharia

Como praticar

1. Implementar RBAC com hierarquia no banco de dados. Crie o schema SQL de RBAC com herança de papéis: tabelas de papéis com relação pai-filho (parent_role_id), permissões, e uma query recursiva (CTE WITH RECURSIVE) que resolve as permissões transitivas de um usuário. Implemente a verificação em uma API simples e teste os casos de borda: papel sem permissão própria mas com permissão herdada, usuário com múltiplos papéis onde apenas um tem a permissão necessária.
   Critério: a query recursiva retorna permissões transitivas corretamente em 3+ níveis de hierarquia; testes automatizados cobrem allow por herança e deny quando nenhum papel do usuário tem a permissão — sem false positives.
2. Escrever políticas OPA com testes unitários para um sistema existente. Instale OPA localmente e escreva políticas Rego para um conjunto de regras de autorização reais — mínimo 3 regras distintas (pelo menos uma com condição de atributo de contexto como horário ou departamento). Escreva testes OPA (opa test) cobrindo allow e deny para cada regra, incluindo os edge cases.
   Critério: opa test passa com cobertura ≥ 80% das regras; pelo menos 5 casos de teste com expect deny que realmente retornam deny — garantia de que o default-deny está funcionando.
3. Modelar um sistema colaborativo no playground do Authzed (SpiceDB). Acesse play.authzed.com e modele: documentos em pastas, pastas em projetos, usuários com papéis diferentes por recurso, e grupos com membros. Escreva 10+ tuplas de relacionamento e valide 5 queries de check — algumas allow via herança transitiva, outras deny por ausência de relacionamento. Observe como a hierarquia é resolvida sem SQL.
   Critério: pelo menos 2 queries allow que funcionam exclusivamente via herança transitiva (sem tupla direta usuário→documento); pelo menos 2 queries deny esperadas; o schema exportado tem pelo menos 3 tipos de objeto com permissões compostas por union/intersection.
4. Identificar e resolver role explosion em um sistema existente. Em um sistema RBAC real ou simulado com 10+ papéis, mapeie quais papéis se diferenciam apenas por um atributo do recurso (ex: tenant, projeto, departamento). Para cada classe de role explosion identificada, proponha a substituição: ABAC via OPA (se é atributo do contexto) ou ReBAC via tuplas (se é hierarquia de objeto). Implemente a substituição para pelo menos uma classe.
   Critério: a substituição elimina pelo menos 3 papéis redundantes; os testes de autorização existentes passam contra o novo modelo; documento explica a decisão de qual modelo foi escolhido e por quê.
5. Integrar SpiceDB ou OpenFGA em uma API existente via gRPC. Adicione SpiceDB (via Docker) ou OpenFGA a um projeto com API HTTP. Substitua uma verificação de autorização existente (mesmo que simples) pela chamada ao serviço de autorização: escreva o schema, popule as tuplas no setup do usuário, e substitua o check inline pela chamada gRPC CheckPermission. Meça a latência adicionada pelo sidecar vs chamada de rede.
   Critério: a API existente passa os testes de integração com SpiceDB/OpenFGA como PDP; a latência adicionada pela chamada gRPC é medida e documentada (p50 e p99); o schema SpiceDB está versionado no repositório junto com seeds de tuplas para testes.

Perguntas de entrevista