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

Controle de acesso e autenticação forte em RBAC

Gabarito: letra C. A falha descrita é que usuários com funções administrativas acessavam recursos críticos sem que a autenticação forte fosse exigida — ou seja, o controle de autorização (RBAC) não estava aplicando a política de autenticação a todos os papéis. A correção imediata é configurar as regras de autorização para que os administradores também estejam sujeitos à autenticação forte, sem exceções, garantindo que a política de segurança seja uniforme.

O controle de acesso lógico é um dos pilares da segurança da informação, composto por três processos fundamentais: autenticação, autorização e auditoria (modelo AAA). A autenticação verifica a identidade do usuário (quem você é), a autorização define o que esse usuário pode fazer (quais recursos acessar e com quais permissões), e a auditoria registra as atividades para rastreamento e conformidade. No modelo RBAC (Role-Based Access Control), as permissões são vinculadas a papéis organizacionais — um usuário recebe um papel e, por meio dele, adquire os direitos associados. A falha relatada ocorre justamente na interseção entre autenticação e autorização: o sistema exigia autenticação forte para acessar dados críticos, mas os administradores, por terem um papel privilegiado, estavam sendo tratados como exceção e pulando essa etapa.

A autenticação forte, geralmente implementada como autenticação multifator (MFA), é uma camada adicional de segurança que combina dois ou mais fatores independentes — algo que você sabe (senha), algo que você tem (token, smart card) e algo que você é (biometria). Ela é essencial para proteger recursos críticos, pois reduz drasticamente o risco de acesso não autorizado, mesmo que uma credencial seja comprometida. O princípio do menor privilégio, que orienta a concessão de permissões mínimas necessárias para cada função, também reforça a necessidade de que nenhum papel, por mais elevado que seja, fique isento das políticas de segurança — na verdade, papéis administrativos são alvos prioritários de ataques e devem estar sujeitos a controles ainda mais rígidos.

Na prática, a correção da falha envolve revisar as políticas de autorização no sistema RBAC para garantir que a exigência de autenticação forte seja aplicada a todos os papéis, incluindo os administrativos. Isso pode ser feito configurando regras de acesso que condicionem a permissão de acesso a recursos críticos à conclusão bem-sucedida da autenticação multifator, sem exceções. Medidas como logs de auditoria, redefinição de senhas, timeout de sessão ou SSO são complementares, mas não resolvem a causa raiz — que é a brecha na política de autorização que permitia que administradores contornassem a autenticação forte.

A distinção crucial aqui é entre autenticação (verificar quem é o usuário) e autorização (decidir o que ele pode acessar). A falha não está na autenticação em si, mas na autorização que não exigia a autenticação forte para um grupo específico. Portanto, a solução deve atuar na camada de autorização, ajustando as regras para que a autenticação forte seja um pré-requisito inegociável para todos os acessos a dados críticos. É exatamente esse o critério que separa a alternativa correta das demais: a alternativa C trata diretamente da configuração das regras de autorização, enquanto as outras abordam aspectos periféricos ou paliativos.

Alternativa A — ❌ Incorreta

Implementar um log de auditoria mais robusto para monitorar os acessos dos administradores é uma medida de detecção, não de prevenção. A auditoria registra o que aconteceu, mas não impede que o acesso sem autenticação forte ocorra. A falha já representa um risco ativo; o log apenas ajudaria a identificar incidentes após a ocorrência, não corrigiria a brecha na autorização.

Alternativa B — ❌ Incorreta

Redefinir todas as senhas dos usuários administrativos é uma medida corretiva temporária e insuficiente. Mesmo com senhas novas, o problema persiste: os administradores continuariam acessando recursos críticos sem autenticação forte. A redefinição de senhas não aborda a causa raiz — a falta de exigência de autenticação forte na política de autorização.

Alternativa C — ✅ Correta ⟵ GABARITO

Configurar regras de autorização para que os administradores também estejam sujeitos ao controle de autenticação forte, sem exceções, ataca diretamente a causa da falha. No RBAC, as permissões são definidas por papéis; ajustar as regras para que o papel administrativo não contorne a autenticação forte garante que todos os usuários, independentemente do privilégio, passem pela verificação exigida ao acessar dados críticos. Essa é a medida preventiva correta e imediata.

Alternativa D — ❌ Incorreta

Configurar uma política de timeout para encerrar sessões inativas é uma boa prática de segurança, mas não resolve o problema descrito. O timeout atua após o acesso já ter sido concedido, encerrando sessões ociosas; não impede que o acesso inicial ocorra sem autenticação forte. É uma medida complementar, não a correção da falha.

Alternativa E — ❌ Incorreta

Adotar Single Sign-On (SSO) centraliza a autenticação, mas não garante, por si só, que a autenticação forte seja exigida para todos os acessos. O SSO pode até facilitar o problema, pois uma única autenticação forte poderia valer para múltiplos sistemas, mas a falha específica — administradores acessando sem autenticação forte — não é resolvida apenas pela centralização. A política de autorização ainda precisaria ser ajustada para exigir a autenticação forte.

Gabarito: letra C