Questão de Segurança da Informação — Gestão de Identidade e Acesso (IAM, IdP e Identidade Federada) — FCC 2026

Segregação de Funções (SoD) em Controle de Acesso

Gabarito: letra A. A situação descreve a History-based Separation of Duties (HistSoD), que permite ao usuário manter papéis conflitantes, mas impede que ele execute ações sobre o mesmo objeto quando já houve atuação anterior — exatamente o caso do funcionário que pode ser "Solicitante" e "Aprovador", mas não pode atuar sobre o mesmo pagamento. Esse tipo de controle é uma das variações do princípio de segregação de funções, previsto em normas como a ISO 27001 (controle 5.3).

A segregação de funções (SoD) é um princípio fundamental de segurança da informação que visa impedir que uma única pessoa execute tarefas críticas que, combinadas, poderiam permitir fraudes ou erros. O exemplo clássico é o fluxo de pagamento: quem solicita não deve aprovar, pois poderia criar e aprovar um pagamento fraudulento sem supervisão. A SoD divide essas responsabilidades entre diferentes pessoas ou, quando isso não é possível, impõe controles que limitam a atuação de uma mesma pessoa.

Existem diferentes formas de implementar a SoD, cada uma com uma abordagem específica. A Static Separation of Duties (SSSoD) impede a associação de um usuário a dois papéis conflitantes desde o início — se você tem o papel de solicitante, não pode ter o de aprovador. A Dynamic Separation of Duties (DSoD) permite que o usuário tenha ambos os papéis, mas bloqueia a ativação simultânea deles em uma mesma sessão. Já a Operational Separation of Duties (OpSoD) permite o acúmulo de papéis, desde que não completem todo o fluxo de trabalho. E a Object-based Separation of Duties (ObjSoD) permite ativar papéis exclusivos, desde que sobre objetos distintos.

A History-based Separation of Duties (HistSoD) é a mais flexível: permite que o usuário tenha papéis conflitantes e os utilize, mas registra o histórico de ações para impedir que ele atue sobre o mesmo objeto em etapas diferentes do fluxo. No caso do enunciado, o funcionário pode solicitar um pagamento e, em outro momento, aprovar outro pagamento — mas não pode aprovar o mesmo pagamento que ele mesmo solicitou. O sistema verifica o histórico de atuação sobre aquele objeto específico e bloqueia a ação conflitante.

A pegadinha desta questão está em distinguir HistSoD de DSoD. A DSoD bloqueia a ativação simultânea de papéis, enquanto a HistSoD permite a ativação, mas impede a ação sobre o mesmo objeto com base no histórico. O enunciado deixa claro que o funcionário "podia manter ambos os papéis" — ou seja, não há restrição de associação nem de ativação — mas o sistema deveria impedir que atuasse sobre o mesmo pagamento. Isso é exatamente o que a HistSoD faz.

Guarde a fronteira entre os tipos de SoD: o que é restrito (associação, ativação, ou ação sobre objeto) e quando a restrição ocorre (no momento da atribuição, na sessão, ou com base no histórico). É nessa fronteira que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa descreve precisamente a History-based Separation of Duties (HistSoD): permite o uso de papéis conflitantes, mas impede ações sobre o mesmo objeto quando já houve atuação anterior. O enunciado afirma que o funcionário pode manter ambos os papéis (solicitante e aprovador), mas o sistema deve impedir que atue sobre o mesmo pagamento. Isso é exatamente o comportamento da HistSoD, que consulta o histórico de ações do usuário sobre o objeto para bloquear a ação conflitante.

Alternativa B — ❌ Incorreta

A Operational Separation of Duties (OpSoD) permite o acúmulo de papéis conflitantes, desde que não completem todo o fluxo de trabalho. No caso, o funcionário poderia solicitar e aprovar pagamentos diferentes, desde que não completasse o fluxo de um mesmo pagamento. Mas o enunciado especifica que a restrição é sobre o mesmo objeto (o mesmo pagamento), não sobre completar o fluxo. A OpSoD não é o tipo de controle descrito.

Alternativa C — ❌ Incorreta

A Static Separation of Duties (SSSoD) impede a associação de um usuário a dois papéis diferentes no sistema. O enunciado afirma explicitamente que o funcionário "podia manter ambos os papéis" — ou seja, a associação é permitida. A SSSoD é exatamente o oposto: ela impede a associação desde o início. Portanto, não se aplica à situação.

Alternativa D — ❌ Incorreta

A Dynamic Separation of Duties (DSoD) permite a associação a papéis exclusivos, mas bloqueia sua ativação simultânea. O enunciado não menciona restrição de ativação — o funcionário pode manter ambos os papéis e, implicitamente, ativá-los. A restrição é sobre a ação no mesmo objeto, não sobre a ativação simultânea. A DSoD não é o tipo de controle descrito.

Alternativa E — ❌ Incorreta

A Object-based Separation of Duties (ObjSoD) permite ativar papéis exclusivos, desde que sobre objetos distintos. O enunciado descreve exatamente o oposto: o funcionário pode ativar ambos os papéis, mas não pode atuar sobre o mesmo objeto. A ObjSoD permitiria atuar sobre objetos distintos, mas não impede a atuação sobre o mesmo objeto — ela apenas exige que os papéis sejam usados em objetos diferentes. A descrição não corresponde ao controle descrito.

Gabarito: letra A — a History-based Separation of Duties (HistSoD) é o controle que permite papéis conflitantes, mas impede ações sobre o mesmo objeto com base no histórico de atuação.