Questão de Segurança da Informação — Autorização e Controle de Acesso (RBAC, ABAC, MAC, DAC e ACL) — FCC 2026

Modelos de controle de acesso: RBAC e ABAC na prática

Gabarito: letra C. A solução mais adequada combina RBAC (Role-Based Access Control) para os colaboradores internos — pois o acesso aos módulos administrativos é definido pela função organizacional (atendente, fiscal, supervisor) — e ABAC (Attribute-Based Access Control) para os passageiros nas catracas, pois a decisão de liberar a passagem depende de atributos dinâmicos como tipo de cartão, horário e zona tarifária. Essa combinação atende aos requisitos com escalabilidade e facilidade de gestão.

O controle de acesso é um dos pilares da segurança da informação, responsável por gerenciar a interação entre sujeitos (usuários, processos) e objetos (arquivos, sistemas). Ele se apoia no modelo AAA: autenticação (verificar quem é o usuário), autorização (definir o que ele pode fazer) e auditoria (registrar o que foi feito). A questão trata especificamente da autorização, ou seja, de como decidir se um sujeito autenticado pode acessar um determinado recurso.

Existem quatro modelos clássicos de autorização, cada um com sua lógica de decisão:

A escolha entre RBAC e ABAC depende da natureza da decisão de acesso. O RBAC é ideal quando o acesso é estável e vinculado à função do usuário na organização: um atendente de guichê tem um conjunto fixo de permissões, um supervisor tem outro, e assim por diante. É simples de gerenciar, pois basta atribuir papéis aos usuários e as permissões vêm junto. Já o ABAC é mais flexível e granular, pois avalia atributos dinâmicos do contexto (horário, localização, tipo de cartão) em cada solicitação. É a escolha certa quando a decisão varia conforme condições que mudam a cada acesso.

No cenário da bilhetagem eletrônica, os dois requisitos são claramente distintos. Para os colaboradores, o acesso é definido pela função — um fiscal de linha não deve acessar os mesmos módulos que um administrador de sistema. Isso é a essência do RBAC. Para os passageiros, a liberação na catraca depende de atributos contextuais — um estudante fora do horário de pico em uma zona tarifária específica pode ou não ter passagem liberada. Isso é a essência do ABAC. A alternativa C captura exatamente essa divisão.

A pegadinha da questão está em inverter os modelos: aplicar ABAC para colaboradores (quando o RBAC é mais simples e adequado) ou RBAC para passageiros (quando o ABAC é necessário para lidar com a dinamicidade dos atributos). A banca também explora a confusão entre autorização e autenticação, como na alternativa E, que trata o SSO (Single Sign-On) como se fosse uma política de autorização, quando na verdade ele é apenas um mecanismo de autenticação.

Guarde a fronteira entre RBAC e ABAC: papel fixo versus atributos dinâmicos. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Esta alternativa comete dois erros graves. Primeiro, propõe ABAC na camada de banco de dados para filtrar registros, o que é uma aplicação inadequada do modelo — ABAC é uma política de autorização, não um mecanismo de filtragem de dados. Segundo, e mais grave, concede acesso irrestrito a todos os módulos administrativos a qualquer colaborador autenticado, independente da função. Isso viola o princípio do menor privilégio e ignora completamente o requisito de que o acesso deve ser definido pela função organizacional. A alternativa confunde autenticação (quem é o usuário) com autorização (o que ele pode fazer).

Alternativa B — ❌ Incorreta

Esta alternativa inverte os modelos. Aplica ABAC para colaboradores, avaliando atributos como cargo e unidade de lotação — o que é desnecessariamente complexo, pois o acesso por função é mais simples e adequado ao RBAC. E aplica RBAC para passageiros, tratando cada tipo de cartão como um papel fixo, com as mesmas permissões independentemente de horário e zona. Isso é exatamente o oposto do que o requisito pede: a liberação na catraca deve considerar horário e zona tarifária, que são atributos dinâmicos, não papéis fixos. A alternativa erra ao ignorar a necessidade de decisões contextuais para os passageiros.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta alternativa acerta ao aplicar RBAC para os colaboradores, definindo papéis como atendente, fiscal e supervisor nos módulos administrativos — exatamente o que o requisito pede, com boa escalabilidade e facilidade de gestão. E aplica ABAC para o acesso de passageiros às catracas, baseando as decisões em atributos como tipo de cartão, horário da viagem e zona tarifária — exatamente o que o requisito pede para a liberação dinâmica da passagem. A combinação é tecnicamente correta e atende aos dois requisitos de forma eficiente.

Alternativa D — ❌ Incorreta

Esta alternativa propõe ACL (Access Control Lists) baseadas em usuários individuais, registrando em cada catraca quais CPFs podem passar em cada horário e linha. Isso é inviável na prática: exigiria uma lista gigantesca e de difícil manutenção para cada catraca, com atualização constante. Além disso, ACL é um mecanismo de controle de acesso a objetos (arquivos, recursos), não uma política de autorização para decisões dinâmicas como liberação de passagem. A alternativa ignora a necessidade de escalabilidade e gestão eficiente, que são requisitos explícitos do enunciado.

Alternativa E — ❌ Incorreta

Esta alternativa confunde autenticação com autorização. O SSO (Single Sign-On) é um mecanismo de autenticação que permite ao usuário fazer login uma única vez e acessar múltiplos sistemas. Ele não define quem pode usar quais módulos administrativos ou passar na catraca — isso é função da autorização. A alternativa afirma que um único login "dispensa políticas específicas de autorização", o que é um erro conceitual grave. O SSO resolve o problema de autenticação, mas não substitui as políticas de autorização, que são essenciais para definir o que cada usuário pode fazer após autenticado.

Gabarito: letra C