IAM: RBAC × ABAC; menor privilégio, segregação de funções; PAM

A ideia que organiza o assunto

Controle de acesso é uma cadeia de quatro perguntas que acontecem nessa ordem e nunca se substituem:

Identificação — quem você alega ser (o login, a conta, o certificado).
Autenticação — a prova de que a alegação é verdadeira (senha, token, biometria). É o assunto da nota de MFA.
Autorização — o que essa identidade já provada pode fazer sobre cada objeto. É o assunto desta nota.
Auditoria — o registro do que foi feito, que é o que torna as três anteriores verificáveis.

O erro que a banca mais explora aqui não é confundir dois modelos de autorização: é deixar um elo da cadeia fazer o trabalho do outro. Papel não autentica. Senha não autoriza. Criptografia não decide permissão. Sempre que um item disser que um elemento da cadeia dispensa outro, ele está errado por essa linha, sem que você precise saber mais nada sobre o modelo citado.

Dentro da autorização, a segunda régua separa três funções que os itens insistem em fundir:

função	quem exerce	exemplo
decidir a regra	a política de segurança, o dono do dado, o gestor	“estagiário não vê folha de pagamento”
guardar a regra	a base de autorização: ACL, matriz de acesso, atributos, diretório	a ACL do objeto, o papel no diretório
aplicar a regra	o monitor de referência, em todo acesso	o núcleo do sistema operacional

O monitor de referência não contém as regras — ele as consulta e media cada tentativa de acesso. Essa distinção sozinha derruba um item deste corpus.

Quanto isto foi medido. Treze itens. E o título do tópico não descreve o que eles cobram: RBAC aparece nominalmente em 1 item (e ainda assim para ser comparado a MFA), ABAC em nenhum, MAC em nenhum, o discricionário em 1. Não há um único item que compare RBAC com ABAC. O que de fato decide os treze é outra coisa: segregação de funções em 2, menor privilégio e negação por padrão em 3, ACL e monitor de referência em 2, ciclo de vida da identidade em 2 — e um item que sequer é de controle de acesso (trata de webhooks). A tabela de modelos abaixo está aqui porque a prova pode cobrá-la a qualquer momento, não porque o corpus já a tenha cobrado.

Por que se usa (e o que custa)

RBAC existe para desligar a permissão da pessoa. Quem entra, sai e muda de área é o colaborador; o papel fica. Por isso o RBAC é o modelo indicado em organização com alta rotatividade e em qualquer lugar onde a revisão de acesso precise ser auditável: você revisa dezenas de papéis, não milhares de contas. O custo é a explosão de papéis — cada exceção vira um papel novo, e organizações grandes chegam a ter mais papéis do que usuários.

ABAC existe para resolver o que o RBAC não expressa: contexto. A decisão é calculada a partir de atributos do sujeito (cargo, lotação, nível de habilitação), do objeto (classificação, dono), da ação e do ambiente (hora, local, postura do dispositivo, rede de origem). Ganha-se granularidade e regra dinâmica; perde-se previsibilidade — responder “quem pode ver este arquivo?” no ABAC exige avaliar a política, não consultar uma lista, e é por isso que ele é mais difícil de auditar e de depurar.

DAC é barato e é o modelo do sistema de arquivos comum: o dono do objeto concede acesso a quem quiser. O custo é que a política fica descentralizada na mão de cada usuário, propaga-se sem controle central e não acompanha rotatividade — é justamente o oposto do que se recomenda quando o quadro muda o tempo todo.

MAC é o mais rígido: rótulos de classificação e credenciais de habilitação fixados pelo sistema, fora do alcance do dono do objeto. Serve a ambiente militar e governamental onde a confidencialidade rotulada é obrigatória, e o custo é a inflexibilidade.

Como funciona

Os modelos, em uma frase cada. DAC: quem decide é o dono do objeto. MAC: quem decide é o sistema, por rótulo de segurança, e nem o dono pode contrariar. RBAC: quem decide é o papel que a pessoa exerce. ABAC: quem decide é a regra avaliada sobre atributos, inclusive de ambiente. RuBAC (baseado em regras): condições fixas aplicadas a todos, como a lista de um firewall ou uma janela de horário.

Onde a regra fica guardada. A matriz de acesso é o modelo conceitual — sujeitos nas linhas, objetos nas colunas, direitos nas células. Ela é grande e esparsa demais para existir de verdade, então é fatiada de duas maneiras opostas: a ACL é a matriz por coluna (cada objeto carrega a lista de quem pode o quê) e a lista de capacidades é a matriz por linha (cada sujeito carrega os bilhetes do que pode acessar). Responder “quem pode acessar este arquivo?” é imediato na ACL e caro na capability; “o que este usuário pode acessar?” é o inverso. Uma ACL não lista apenas indivíduos: aceita grupos e papéis, e as entradas especificam o nível da operação — ler, escrever, executar, excluir.

O monitor de referência. É a abstração que media todo acesso de sujeito a objeto. Três propriedades o definem: mediação completa (não existe caminho que o contorne), proteção contra violação (não pode ser alterado por quem ele controla) e verificabilidade (é pequeno o bastante para ser analisado). As regras não moram nele; moram na base de autorização que ele consulta, e a implementação concreta é o núcleo de segurança do sistema operacional.

Gestão de identidades (IAM) é ciclo de vida, não só login. Um sistema de IAM faz: descoberta e reconciliação — localizar identidades preexistentes nos sistemas conectados e casá-las com a identidade corporativa, que é o passo sem o qual a migração nunca termina; provisionamento e desprovisionamento automáticos a partir do evento de RH (admissão, transferência, desligamento); revisão periódica de acesso (recertificação); gestão de contas privilegiadas (PAM); e a trilha de auditoria. O desligamento é o ponto crítico: conta órfã é o achado mais comum de auditoria.

Os princípios que a prova cobra pelo nome.

Menor privilégio — cada sujeito recebe o mínimo necessário para a função, pelo menor tempo necessário. Sua violação típica não é um acesso a mais: é o recurso que deveria estar protegido e está disponível para qualquer pessoa. Parente próximo: necessidade de conhecer (need to know), que limita pelo dado, não pela operação.

Negação por padrão — o que não foi expressamente permitido está proibido. É a forma correta de escrever qualquer política: lista de permitidos, nunca lista de proibidos. Em nuvem é o mesmo princípio: negar por padrão e conceder apenas quando necessário.

Segregação de funções — nenhuma pessoa deve controlar sozinha um processo do começo ao fim, para que uma fraude exija conluio e um erro seja apanhado por outra pessoa. Quem solicita não aprova; quem aprova não executa; quem executa não concilia; quem opera não audita. É prática recomendada de redução de risco de fraude e de erro — e é aí que mora a pegadinha: ela não é uma vedação automática a qualquer acúmulo. Na Lei n.º 14.133/2021 o que se veda é designar o mesmo agente para atuação simultânea em funções mais suscetíveis a riscos na mesma contratação; acumular papéis de planejamento — requisitante e área técnica na elaboração do ETP — não é o que a norma proíbe, e em órgão de quadro reduzido é o caso comum. Quando não há como segregar, a resposta é controle compensatório (supervisão, revisão por terceiro, trilha de auditoria), não a paralisação.

Propriedade do registro. A regra de aplicação segura é o espelho do que a banca escreve: o controle deve impor a propriedade do registro, em vez de aceitar que o usuário crie, leia, atualize ou exclua qualquer registro. O identificador vindo do cliente nunca decide o acesso; quem decide é o servidor, confrontando a identidade autenticada com o dono do objeto.

O que decide os itens

Os quatro modelos, lado a lado — a tabela que o corpus ainda não cobrou e que a prova pode cobrar amanhã:

modelo	quem decide	com base em	cabe bem quando
DAC	o dono do objeto	identidade do sujeito e concessão do dono	ambiente colaborativo, quadro estável
MAC	o sistema, de forma imposta	rótulo do objeto × habilitação do sujeito	sigilo classificado, militar, governo
RBAC	o papel exercido	função organizacional	alta rotatividade, revisão auditável
ABAC	a política avaliada em tempo real	atributos de sujeito, objeto, ação e ambiente	decisão dependente de contexto (hora, local, dispositivo)

ACL × lista de capacidades — matriz por objeto × matriz por sujeito. A ACL responde rápido “quem pode acessar isto”; a capability responde rápido “o que este sujeito alcança”.

Autenticação × autorização — provar quem é × decidir o que pode. Nenhuma supre a outra: RBAC bem desenhado não dispensa MFA, e MFA correta não concede permissão nenhuma.

Identificação × autenticação — alegar a identidade × prová-la. Login é identificação; senha é autenticação.

Menor privilégio × necessidade de conhecer × negação por padrão — o mínimo de permissão para a função × o mínimo de informação para a tarefa × o padrão da política quando nada foi dito.

Segregação de funções × menor privilégio — a primeira separa etapas de um processo entre pessoas diferentes (antifraude, exige conluio); a segunda reduz o tamanho do acesso de cada um. Item que explica uma com a definição da outra trocou o par.

Monitor de referência × base de autorização × política — aplica × guarda × define. O monitor media todo acesso; ele não contém as regras.

Papel × grupo × atributo — papel é função organizacional com permissões anexadas; grupo é agrupamento de contas para facilitar a atribuição; atributo é característica avaliada na hora da decisão. Ferramentas de IAM costumam oferecer os três ao mesmo tempo, e políticas baseadas em usuário, em papel, em grupo, em atributos e em tempo convivem no mesmo produto.

Autorização com referência temporal existe. Restringir acesso por horário, por dia ou por janela de validade é política legítima e implementada — no ABAC como atributo de ambiente, e em produtos de IAM como tipo próprio de política. Nenhum motivo de segurança a proíbe.

Como a CEBRASPE derruba você aqui

Medido sobre os 13 itens do tópico: 7 certos e 6 errados. Com seis itens errados não há tipo dominante — cinco tipos diferentes aparecem, um deles duas vezes —, e por isso o que segue é ordenado por utilidade, não por frequência alegada. Leia como padrão reconhecível, não como estatística.

Um elo da cadeia apresentado como suficiente para o outro (2 dos 6). É o padrão mais rentável e o único que se repete. “A adoção do controle de acesso baseado em papéis (RBAC) elimina a necessidade da autenticação baseada em múltiplos fatores (MFA), uma vez que os papéis e as permissões são suficientes para garantir a segurança do acesso”; e o mesmo movimento aparece do lado administrativo, esticando a segregação de funções para proibir um acúmulo que a norma não proíbe. Defesa: sempre que o item disser que A dispensa, elimina ou é suficiente em lugar de B, pergunte a que etapa cada um pertence. Se forem etapas diferentes da cadeia — identificar, autenticar, autorizar, auditar — o item está errado.

A capacidade negada com uma justificativa inventada. “As políticas de autorização do Keycloak… não permitam controle de acesso com referência temporal por questões de segurança”. A restrição não existe e a causa foi fabricada para torná-la plausível. Defesa: quando o item nega um recurso e oferece um porquê de segurança, desconfie — o produto normalmente tem o recurso, e o porquê está ali para você não conferir.

A função certa no componente errado. “O monitor de referência para controle de acesso contém as regras que definem quando e como os objetos podem ser acessados” — a descrição é da base de autorização ou da política; o monitor media, não armazena. Defesa: para cada item de componente, diga em voz alta quem define, quem guarda e quem aplica.

O modelo trocado pelo vizinho na recomendação. “O modelo de controle de acesso discricionário é indicado para organizações com alta rotatividade” — a indicação descrita é a do RBAC, cujo sentido é desligar permissão de pessoa. Defesa: leia a característica e nomeie o modelo você mesmo antes de olhar a sigla escrita no item.

A recomendação virada do avesso. “Os controles de acesso devem liberar a propriedade do registro para que usuário possa criar, ler, atualizar ou excluir qualquer registro” — o guia de boas práticas diz exatamente o contrário: impor a propriedade do registro em vez de aceitar que o usuário faça qualquer coisa com qualquer registro. Defesa: quando o item prescreve um dever com devem, teste se a prescrição aumenta ou reduz o privilégio. Controle de acesso que libera e amplia é quase sempre a inversão de uma recomendação real.

E o alerta de sinal: caçar quantificador não funciona neste tópico. O único item do corpus com somente — “somente os usuários que tenham sido especificamente autorizados podem usar e receber acesso às redes” — é certo, porque é a redação literal de um controle da ISO/IEC 27002. Restrição copiada de norma é certa; restrição inventada sobre produto é errada. O que decide é a origem da frase, não a palavra absoluta.

Erros clássicos

Achar que autorização forte compensa autenticação fraca. Papel, ACL e política não sabem quem está do outro lado do teclado. Se a autenticação cair, toda a autorização vem junto, corretamente aplicada ao invasor.

Confundir segregação de funções com proibição de acumular qualquer coisa. O que se separa são etapas incompatíveis de um mesmo processo — solicitar, aprovar, executar, conciliar, auditar. Papéis de planejamento podem recair sobre o mesmo agente, e a falta de quadro se resolve com controle compensatório.

Dizer que o monitor de referência armazena as regras. Ele media cada acesso e consulta a base; mediação completa, proteção contra violação e verificabilidade são as três propriedades que se cobram dele.

Supor que ACL só serve para usuário individual. Ela aceita indivíduos, grupos e papéis, e define o nível de operação permitido em cada entrada.

Tratar menor privilégio como “pouco acesso”. É o acesso necessário, nem mais nem menos, e por prazo determinado. Acesso insuficiente também é falha de controle — ele empurra a operação para contas compartilhadas.

Esquecer o desligamento. Provisionar é fácil e todo mundo cobra; a conta que sobrou depois da saída é o achado clássico, e é por isso que reconciliação e revisão periódica de acesso são funções de IAM tão cobradas quanto a criação de usuário.

Achar que DAC é “inseguro” e MAC é “seguro”. São adequações diferentes: o DAC descentraliza a decisão no dono, o MAC a impõe por rótulo. O erro não é escolher DAC; é escolhê-lo onde a política precisa ser central e o quadro muda toda semana.