Definir como as permissões são concedidas é parte central de uma estratégia de Governança de Identidades e Acessos (IGA). Controle de acesso não é “só TI”: é o mecanismo que impede que um usuário certo vire um risco só porque ganhou permissões demais ao longo do tempo (o clássico privilege creep).
Na prática, RBAC, ABAC e PBAC são três formas de responder a uma pergunta simples:
“Quem pode acessar o quê, fazer o quê, em quais condições?”
A diferença está em qual lógica você usa para tomar essa decisão.
Para que esses modelos servem nas empresas
Eles servem para:
- Reduzir risco: menos permissões desnecessárias, menos brecha.
- Escalar sem caos: quando a empresa cresce, “dar acesso na mão” vira dívida técnica e auditoria ruim.
- Acelerar operação: onboardings e mudanças de área mais rápidas, com menos chamado.
- Aprovar auditoria: rastreabilidade, justificativa e consistência (quem aprovou, por quê, com base em qual regra).
RBAC (Role-Based Access Control) — acesso por papéis
O que é: Permissões são associadas a papéis/funções (ex.: “Analista de RH”, “Financeiro Contas a Pagar”). O usuário herda permissões do papel.
Quando funciona muito bem:
- Estruturas organizacionais claras e relativamente estáveis.
- Sistemas com perfis bem definidos (ERP, CRM, ITSM).
- Quando você precisa de um “padrão mínimo” de acesso por função.
Pontos de atenção (onde RBAC falha se você exagera):
- Explosão de papéis: cada exceção vira um novo role (“Analista RH – filial X – temporário”), e você perde controle.
- RBAC puro lida mal com contexto (horário, local, dispositivo, sensibilidade do dado).
Exemplo simples:
“Todo Analista de RH pode ler dados cadastrais de colaboradores, mas não pode exportar folha salarial.”
ABAC (Attribute-Based Access Control): Acesso por atributos e contexto
A decisão de acesso considera atributos do usuário, do recurso e do contexto. Ex.: área=RH, senioridade=pleno, dado=confidencial, dispositivo=gerenciado, horário=comercial, localização=Brasil.
O NIST define ABAC como um modelo em que a autorização é determinada pela avaliação de atributos do sujeito, do objeto, da operação e, às vezes, do ambiente, contra políticas/regras. (NIST CSRC)
Quando ABAC é superior:
- Ambientes dinâmicos (cloud, SaaS, trabalho remoto).
- Dados com classificação (público / interno / confidencial / restrito).
- Necessidade de decisões finas (“pode ver, mas não pode baixar”; “pode acessar só com device corporativo”).
Pontos de atenção
- Se seus atributos são ruins (desatualizados, inconsistentes), ABAC vira “complexidade sem segurança”.
- Regras demais sem governança viram “caixa-preta” difícil de auditar.
Exemplo simples:
“Permitir download de arquivos ‘Confidenciais’ somente para usuários do time X, usando dispositivo gerenciado e MFA, dentro do horário comercial.”
PBAC (Policy-Based Access Control): Acesso dirigido por políticas centralizadas
Em vez de permissões fixas espalhadas, você define políticas centralizadas que descrevem condições e resultados (“permitir”, “negar”, “exigir step-up MFA”, etc.). O NIST descreve PBAC como uma estratégia em que papéis de negócio combinados com políticas determinam privilégios e em que diferenças entre privilégios teóricos e reais podem ser automaticamente aplicadas. (NIST CSRC)
Onde PBAC brilha:
- Quando a empresa quer padronização e consistência entre vários sistemas.
- Quando existe pressão de conformidade (LGPD, SOX, ISO 27001, auditorias internas).
- Quando você quer traduzir regras corporativas em decisões executáveis (“se for dado sensível, exige controle extra”).
Pontos de atenção:
- PBAC não é “mágico”: depende de boa modelagem de políticas e integração.
- Geralmente PBAC e ABAC se aproximam na prática (política avaliando atributos). O ganho do PBAC costuma ser centralização e governança.
Exemplo simples:
“Qualquer acesso a dados ‘Restritos’ fora do Brasil é negado automaticamente, independentemente do papel.”
Modelos de acesso e cibersegurança: A relação direta
O inimigo número 1 no dia a dia não é só invasão externa. É o acesso interno acumulado e mal governado.
- Sem modelo, o acesso vira histórico de exceções.
- Com modelo + IGA, você estrutura o ciclo Joiner–Mover–Leaver:
- Joiner (entrada): recebe apenas o necessário.
- Mover (mudança de função): perde o que não faz mais sentido e ganha o novo.
- Leaver (saída): revogação total no timing certo.
É aqui que você reduz privilege creep: a pessoa muda de área e os acessos antigos deixam de existir porque a concessão está atrelada a regra/papel/política, não a “favor” manual.
Qual escolher?
A resposta que passa mais confiança é: quase nunca é “um ou outro”. Em empresas maduras, o padrão é híbrido:
- RBAC como base (estrutura organizacional e funções).
- ABAC/PBAC como camada de refinamento (contexto, sensibilidade, compliance).
Regra prática para decidir:
- Quer simplicidade operacional? Comece com RBAC bem feito.
- Precisa de granularidade, contexto e decisões dinâmicas? Adicione ABAC.
- Quer governança e consistência centralizada entre muitos sistemas? Evolua com PBAC.
Governança com precisão
Modelo de acesso não é slide bonito: é controle real sobre risco. A escolha certa melhora operação, reduz incidente e sustenta auditoria.
A Raise IT apoia na definição da arquitetura ideal para o seu cenário, conectando Governança de Identidades à realidade dos sistemas (legados, SaaS e cloud), com foco em menor privilégio, automação e conformidade que se sustenta na prática.
