Questão de Segurança da Informação — Autorização e Controle de Acesso (RBAC, ABAC, MAC, DAC e ACL) — FCC 2026
Segurança da Informação›Autorização e Controle de Acesso (RBAC, ABAC, MAC, DAC e ACL)
Código
fc141932
Banca
FCC
Órgão
SEFAZ MT
Ano
2026
Cargo
FTE ( )
Durante uma auditoria preventiva nos logs do sistema de arrecadação da Secretaria da Fazenda, a equipe de TI detecta que uma conta de serviço, utilizada para integração com bancos, está realizando tentativas de acesso a tabelas de sigilo fiscal que não pertencem ao seu escopo. O Fiscal suspeita de um código malicioso explorando uma configuração de permissões excessivas. Para mitigar o risco de exfiltração de dados e reestabelecer a governança de segurança, a ação prática mais adequada, baseada em gestão de riscos, é
Aimplementar imediatamente um processo de classificação de toda a base de dados como "sigilosa" para eliminar a ameaça detectada, porque as vulnerabilidades de sistema são corrigidas automaticamente por essa mudança de rótulo e, então, o risco residual será aceitável após o reinício dos serviços.
Bsubstituir a política de controle de acesso discricionário por uma autenticação multifator para a conta de serviço, focando no bloqueio de ameaças externas, uma vez que vulnerabilidades internas de permissão de acesso não geram impacto financeiro ou legal significativo para o fisco.
Cpriorizar a atualização das políticas formais de segurança para incluir novas punições disciplinares, partindo do princípio de que ameaças internas são neutralizadas por normas administrativas, e manter os perfis de acesso atuais até que a classificação das informações seja revisada pela diretoria.
Drealizar o mapeamento do agente causador da atividade atípica e identificar a falha de configuração ou falta de controle que permitiu o desvio; em seguida, aplicar o princípio do privilégio mínimo para reduzir o risco, ajustando os controles de acesso com base na criticidade da informação atacada.
Eisolar o servidor afetado para tratar a vulnerabilidade técnica de hardware, pois o risco é inerente aos sistemas legados e a classificação da informação não deve ser usada para restringir integrações automatizadas entre sistemas fiscais e bancários.
Revelar gabarito e comentário▾
GabaritoD — realizar o mapeamento do agente causador da atividade atípica e identificar a falha de configuração ou falta de controle que permitiu o desvio; em seguida, aplicar o princípio do privilégio mínimo para reduzir o risco, ajustando os controles de acesso com base na criticidade da informação atacada.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Gestão de riscos e controle de acesso: privilégio mínimo
Gabarito: letra D. A ação mais adequada é mapear o agente causador da atividade atípica, identificar a falha de configuração que permitiu o desvio e aplicar o princípio do privilégio mínimo, ajustando os controles de acesso com base na criticidade da informação. Essa é a abordagem correta de gestão de riscos: primeiro entender o incidente e a vulnerabilidade, depois tratar o risco com controles proporcionais — exatamente o que a norma de segurança da informação determina ao exigir que os direitos de acesso sejam provisionados, analisados criticamente, modificados e removidos conforme a política da organização.
A gestão de riscos em segurança da informação segue um ciclo lógico: identificação do risco (o que pode acontecer e como), análise e avaliação (qual a probabilidade e o impacto), e tratamento (o que fazer para reduzir, transferir, aceitar ou evitar o risco). No cenário da questão, a equipe detectou um evento atípico — uma conta de serviço acessando tabelas de sigilo fiscal fora do seu escopo. Antes de qualquer ação corretiva, é preciso mapear o agente causador (quem ou o que está por trás da atividade) e identificar a falha de configuração (a vulnerabilidade que permitiu o desvio). Só depois disso é possível aplicar o controle adequado.
O princípio do privilégio mínimo (least privilege) é um dos pilares do controle de acesso: cada usuário, processo ou conta de serviço deve ter apenas as permissões estritamente necessárias para executar suas funções. No caso, a conta de serviço de integração com bancos não deveria ter acesso a tabelas de sigilo fiscal — isso é uma permissão excessiva, uma vulnerabilidade de configuração. A correção passa por reduzir essas permissões ao mínimo necessário, com base na criticidade da informação (dados fiscais são altamente sensíveis e protegidos por sigilo legal).
A norma técnica de segurança da informação reforça exatamente esse ponto: os direitos de acesso devem ser provisionados, analisados criticamente, modificados e removidos de acordo com a política da organização. Isso significa que o controle de acesso não é estático — ele deve ser revisado e ajustado continuamente, especialmente quando há indícios de uso indevido.
A banca explora aqui a confusão entre tratar a causa (configuração de permissões) e tratar sintomas (classificar dados, punir pessoas, isolar servidor). A alternativa correta é a única que segue o ciclo completo de gestão de riscos: identificar → analisar → tratar. As demais propõem ações precipitadas, que não atacam a raiz do problema ou que ignoram a natureza do incidente.
Guarde o critério decisivo: em incidentes de segurança, a primeira ação é entender o que aconteceu e por quê, para então aplicar o controle correto — e, no caso de permissões excessivas, o controle é o privilégio mínimo.
Gestão de riscos em incidentes: Identificar (Mapear agente causador, Identificar falha de configuração); Analisar (Probabilidade e impacto, Criticidade da informação); Tratar (Privilégio mínimo, Ajustar controles de acesso, Reduzir, transferir, aceitar ou evitar)
Alternativa A — ❌ Incorreta
Classificar toda a base de dados como "sigilosa" não elimina a ameaça nem corrige vulnerabilidades automaticamente. A classificação da informação é um processo de gestão que define o nível de proteção necessário, mas não substitui a correção de configurações de acesso. Além disso, classificar tudo como sigiloso pode até piorar a situação, dificultando o acesso legítimo e criando uma falsa sensação de segurança. O risco residual não se torna aceitável apenas por mudar rótulos — é preciso tratar a causa do desvio.
Alternativa B — ❌ Incorreta
Substituir a política de controle de acesso discricionário por autenticação multifator (MFA) não resolve o problema. O MFA é um controle de autenticação (provar quem é o usuário), não de autorização (o que o usuário pode fazer). A conta de serviço já está autenticada — o problema é que ela tem permissões excessivas. Além disso, a alternativa afirma que vulnerabilidades internas de permissão não geram impacto financeiro ou legal significativo, o que é falso: o acesso indevido a sigilo fiscal pode gerar graves consequências legais e financeiras para o fisco.
Alternativa C — ❌ Incorreta
Atualizar políticas formais e incluir punições disciplinares não neutraliza ameaças internas por si só. Políticas e normas são importantes, mas precisam ser implementadas com controles técnicos efetivos. Manter os perfis de acesso atuais até que a classificação seja revisada é exatamente o oposto do que se deve fazer: o risco está ativo e precisa ser tratado imediatamente. A alternativa confunde governança documental com controle técnico — a punição é uma consequência, não uma prevenção.
Alternativa D — ✅ Correta ⟵ GABARITO
Esta é a ação correta porque segue o ciclo de gestão de riscos: primeiro mapear o agente causador (entender o incidente), depois identificar a falha de configuração (a vulnerabilidade), e então aplicar o princípio do privilégio mínimo (o controle adequado), ajustando os controles de acesso com base na criticidade da informação (sigilo fiscal é altamente sensível). Essa abordagem ataca a causa raiz do problema — permissões excessivas — e reduz o risco de exfiltração de dados de forma efetiva.
Alternativa E — ❌ Incorreta
Isolar o servidor para tratar uma "vulnerabilidade técnica de hardware" é um diagnóstico errado. O problema descrito é de configuração de permissões (controle de acesso), não de hardware. Além disso, a alternativa afirma que a classificação da informação não deve ser usada para restringir integrações automatizadas — o que é incorreto: a criticidade da informação deve sempre orientar os controles de acesso, inclusive em integrações entre sistemas. Isolar o servidor pode ser uma medida de contenção temporária, mas não trata a causa e não é a ação mais adequada para reestabelecer a governança.
NÃO CAIA NESSA!
A banca tenta confundir autenticação com autorização (alternativa B) e tratamento de sintoma com tratamento de causa (alternativas A, C e E). A pegadinha central é fazer o candidato escolher uma ação imediata e superficial (classificar dados, punir, isolar) em vez da abordagem correta de gestão de riscos: identificar a causa e aplicar o controle adequado. Lembre-se: em incidentes de segurança, primeiro se entende o problema, depois se age.
PEGA ESSA DICA!
Em questões de gestão de riscos, siga o ciclo: identificar → analisar → tratar. A alternativa que descreve esse fluxo completo, com ações específicas e proporcionais ao risco, é quase sempre a correta. Desconfie de alternativas que propõem soluções mágicas (classificar tudo, punir todos) ou que atacam o problema errado (hardware, MFA).