Modelagem de papéis de acesso: como fazer RBAC que sobrevive ao dia a dia

Toda empresa que cresce chega no mesmo ponto. A concessão de acesso deixa de ser um pedido por semana e vira trinta por dia. O time de TI vira despachante de permissão, e ninguém explica mais por que um usuário tem determinado direito.

RBAC é a resposta padrão. Também é onde a maioria dos projetos de governança de acessos empaca, porque modelar papel é trabalho de negócio, não de infraestrutura. Feita às pressas, a modelagem cai em um de dois extremos: o papel gigante que libera demais para caber todo mundo, ou mil papéis exclusivos que repetem a concessão avulsa com outro nome.

O que é RBAC e por que papel não é permissão avulsa

RBAC (role based access control, ou controle de acesso baseado em papéis) é o modelo em que a permissão não vai para a pessoa. Ela vai para um papel, e a pessoa recebe o papel. O vínculo entre usuário e permissão fica sempre indireto e explicável.

A diferença aparece na manutenção. Permissão avulsa resolve um caso. Papel resolve uma categoria.

Quando um analista fiscal entra e recebe permissão avulsa, alguém reconstrói de cabeça a lista que o trabalho exige. Ela sai copiada de um colega, com sobras. Com o papel, ele herda uma lista revisada, com owner.

O ganho maior é de auditabilidade. Uma trilha que mostra "recebeu o papel X, aprovado pelo owner Y, na data Z" responde ao auditor. Dezenas de permissões soltas não respondem nada.

Os dois erros opostos da modelagem de papéis

Explosão de papéis e papel genérico são o mesmo erro em dois ângulos. Nos dois, o papel deixou de representar uma função.

O papel gigante que virou acesso universal

Acontece quando um papel serve a um departamento inteiro. Financeiro tem contas a pagar, contas a receber, tesouraria e controladoria. Com um só "Acesso Financeiro", o papel carrega a união de tudo que eles fazem.

O resultado é privilégio excessivo estrutural. Quem só lança nota fiscal também libera pagamento. O conflito de segregação de funções nasce por desenho. E como o papel atende muita gente, reduzi-lo quebra alguém.

Os mil papéis exclusivos que são concessão avulsa disfarçada

O erro oposto é criar um papel por pessoa. "Analista Fiscal Regional Sul Turno Tarde." Funciona no primeiro mês. No segundo ano a maioria dos papéis tem um único usuário, a recertificação volta a ser item por item, e administrar papéis custa mais que administrar permissões.

Como modelar papéis de acesso na prática

Modelagem de papéis é levantamento, não configuração. A sequência abaixo cabe em ciclos curtos, um departamento por vez.

1. 1Mapeie cargo e função de negócio com o RH. Cargo formal e função real divergem. Use o RH como esqueleto e valide com os gestores.
2. 2Levante o acesso real de quem já faz o trabalho. Extraia as permissões atuais dos sistemas críticos e do Active Directory por função.
3. 3Ache o denominador comum. O que todos têm e usam entra no papel base. O que um ou dois têm vira papel adicional ou resíduo a revogar.
4. 4Separe papel base de papel adicional. O base vem por herança do cargo. O adicional exige pedido, justificativa, prazo e aprovação.
5. 5Defina um owner por papel. Owner é gestor de negócio ou proprietário da aplicação, nunca a TI genérica. Sem owner, ninguém revisa.
6. 6Valide contra a matriz de risco e as regras de SoD. Papel base com conflito interno precisa ser dividido antes de ir para produção.
7. 7Versione toda mudança de papel. Alterar um papel altera o acesso de todos que o têm. Isso pede aprovação, registro e data de vigência.
8. 8Publique no catálogo e migre os usuários, removendo as permissões avulsas equivalentes. É aqui que os projetos param: papel criado sem remover a concessão anterior duplica o inventário.

Role mining: de cima para baixo ou de baixo para cima

Role mining é a análise dos acessos já concedidos para achar agrupamentos que se repetem na prática. Serve para descobrir papéis candidatos a partir do que as pessoas realmente usam, em vez de deduzir tudo do organograma. Há duas abordagens, e elas se corrigem.

A modelagem de cima para baixo parte do organograma e da descrição de cargo. Produz papéis limpos, porém ignora parte do acesso que o trabalho exige. O papel nasce insuficiente e as exceções aparecem logo.

A modelagem de baixo para cima parte do acesso instalado. Acha padrões reais, inclusive os indevidos. Se tratar tudo como legítimo, o RBAC oficializa o privilégio excessivo e os acessos órfãos que já estavam lá.

As duas se combinam. O organograma define a fronteira, os dados de acesso definem o conteúdo, e o owner decide o que fica de fora.

Exemplo de papel base e papéis adicionais

O catálogo de acessos precisa falar linguagem de negócio

Quem solicita acesso é gestor de área, não administrador de sistema. Se o catálogo lista "AC_FIN_PROD_RW_02", ele pede pelo que parece certo e aprova pelo que parece familiar. A aprovação existe no papel e não na prática.

Catálogo governado significa item com nome descritivo, descrição do que o acesso permite, criticidade declarada, owner visível e prazo padrão. "Aprovar pagamento a fornecedor no ERP" é linguagem de negócio. O código técnico continua por baixo, para a execução.

Catálogo e governança de acessos se encontram aqui. Sem tradução, a aprovação não produz decisão informada.

Quando o RBAC não basta: ABAC e aprovação caso a caso

RBAC responde bem à pergunta "o que esse cargo faz". Responde mal ao contexto: qual filial, qual cliente, qual faixa de valor.

Forçar contexto dentro do papel é a receita da explosão de papéis. Trinta filiais vezes quatro funções geram cento e vinte papéis para representar quatro funções.

Aí entra ABAC (attribute based access control), que decide por atributos do usuário, do recurso e da situação. O padrão é híbrido: o papel define a capacidade, o atributo define o escopo. "Analista Fiscal" concede o módulo, o atributo filial limita os dados visíveis.

Sobra uma terceira categoria: acesso raro, sensível e temporário. Fechamento de exercício, investigação, migração. Não pertence a papel nenhum. Vai como solicitação individual, com justificativa, vigência compulsória e aprovação do owner.

Movimentação de cargo pede troca de papel, não soma de papel

Movimentação interna é o maior gerador silencioso de privilégio excessivo. O colaborador muda de área, recebe o acesso novo e mantém o antigo: a concessão tem dono, a remoção não.

No ciclo de vida do acesso, joiner e leaver recebem atenção. Mover é o elo fraco. Com RBAC bem modelado a regra é simples: a mudança de cargo remove o papel base anterior e aplica o novo. Os adicionais da função antiga expiram.

Sobreposição temporária pode existir no repasse, com data de término registrada.

Como o AuditAcesso administra RBAC com herança por cargo

O AuditAcesso é a camada de governança acima do IAM. Não substitui o Active Directory nem o provedor de identidade. Governa decisão, prazo e evidência.

A administração por RBAC com herança por cargo aplica o papel base a partir da estrutura organizacional, na entrada do ciclo de governança em cinco etapas. O colaborador chega com o acesso mínimo provisionado, e o pedido individual vira exceção rastreada.

O catálogo categórico governado resolve a linguagem. Cada item aparece em termos de negócio, com criticidade e owner, para que aprovar seja decidir.

A aprovação pelos proprietários das aplicações descentraliza sem perder controle. Quem entende o risco do sistema decide, e a plataforma registra quem pediu, quem aprovou, por que e por quanto tempo. A validação de SoD roda antes da liberação, com bloqueio preventivo quando o papel pedido conflita com o acesso atual. O provisionamento sai por ITSM (Jira, GLPI) ou API, com integrações nativas homologadas na página de integrações.

O argumento de escala é direto. Sem RBAC, dobrar o quadro dobra a fila de pedidos, de aprovações e de itens na recertificação. Com herança por cargo, o crescimento entra pelo papel que já existe. O esforço operacional acompanha as funções de negócio, que mudam pouco, e não o número de pessoas. Os riscos da concessão manual param de crescer junto.

Checklist prático

Critério de aceite antes de declarar o RBAC pronto.

• Cada papel tem nome de negócio, descrição do que permite e criticidade declarada.
• Cada papel tem owner nomeado: gestor de negócio ou proprietário da aplicação.
• Papel base e adicionais separados, com o base vindo por herança do cargo.
• Nenhum papel base tem conflito interno de SoD nem dado produtivo sensível.
• Papéis de um único usuário viraram exceção ou se juntaram a um maior.
• Mudança de conteúdo de papel exige aprovação, versão e data de vigência.
• Movimentação de cargo remove o papel anterior, não só adiciona o novo.
• A recertificação roda por papel, com lista curta de exceções.

Perguntas frequentes

Qual a diferença entre RBAC e ABAC?

RBAC concede acesso pelo papel que a pessoa ocupa. ABAC decide por atributos do usuário, do recurso e do contexto, como filial, valor ou horário. Na prática os dois se combinam: o papel define a capacidade, e o atributo limita o escopo de dados.

Quantos papéis uma empresa deveria ter?

Não existe número certo, existe um teste. Se a maioria dos papéis tem um único usuário, o modelo virou concessão avulsa com nome novo. Se poucos papéis cobrem departamentos inteiros, há privilégio excessivo por desenho. Catálogo saudável tem papéis por função de negócio, com vários ocupantes cada.

O que é explosão de papéis?

É o crescimento descontrolado do catálogo, quando cada exceção gera um papel novo em vez de um acesso adicional temporário. O sintoma é um número de papéis próximo ao de usuários. O efeito é perder o benefício do RBAC: tudo volta a ser item por item.

Como funciona o role mining?

Role mining analisa as permissões já concedidas para encontrar agrupamentos recorrentes entre pessoas que fazem o mesmo trabalho. Esses agrupamentos são candidatos a papel. O cuidado é não tratar o acesso atual como correto: o levantamento passa pelo owner, que remove sobras e privilégio de funções antigas.

RBAC substitui a segregação de funções?

Não. RBAC organiza a concessão, SoD define quais combinações são proibidas. Um papel bem modelado respeita SoD internamente, mas o usuário pode acumular dois papéis incompatíveis em conjunto. A validação de conflito precisa rodar sobre o acesso total do usuário, antes da liberação.

Próximo passo

Modelagem de papéis é decisão de negócio sustentada por dados de acesso. Ferramenta nenhuma decide no lugar do owner, mas a plataforma certa encurta o levantamento, aplica herança por cargo, bloqueia conflito de SoD e guarda a evidência.

Para ver o RBAC com herança por cargo, o catálogo governado e a aprovação por proprietário de aplicação, agende uma demonstração com o time do AuditAcesso.

==============================================================