Questão de Segurança da Informação — Segurança em Recursos Humanos (NBR ISO/IEC 27002 e NBR ISO/IEC 17799) — FGV 2024

Segurança em Recursos Humanos: Procedimentos e Responsabilidades Operacionais (NBR ISO/IEC 27002)

Gabarito: letra C. A prática essencial que a UMTINO deveria implementar é separar as facilidades de desenvolvimento, testes e operações, indicando o nível de separação necessário para prevenir problemas operacionais, principalmente em termos de acesso ou modificações não autorizadas. Essa é a diretriz do controle de "separação de ambientes" da norma ABNT NBR ISO/IEC 27002, que trata exatamente do cenário descrito no enunciado: a mudança de estado do software (desenvolvimento para produção) sem controles adequados.

A questão aborda os procedimentos e responsabilidades operacionais previstos na norma ABNT NBR ISO/IEC 27002 (e sua antecessora, a ISO/IEC 17799), especificamente no que tange à segurança em recursos humanos e à gestão de operações. O problema central da UMTINO não foi a falta de segregação de funções entre pessoas (alternativa A), nem a ausência de controle de mudanças (alternativa B), nem a gestão de incidentes (alternativa D) ou a documentação de procedimentos (alternativa E). O problema foi a ausência de separação entre os ambientes de desenvolvimento, teste e produção, o que permitiu que mudanças não autorizadas ou mal testadas fossem promovidas diretamente ao ambiente produtivo, causando o prejuízo.

A norma ISO/IEC 27002, na seção de segurança em operações, estabelece que "convém que as facilidades de desenvolvimento, teste e operação sejam separadas para reduzir o risco de acesso ou mudanças não autorizadas". Essa separação é um controle preventivo fundamental: ela garante que o código em desenvolvimento não seja promovido a produção sem passar por um processo controlado de testes e aprovação, e que pessoas com acesso ao ambiente de desenvolvimento não tenham, automaticamente, acesso ao ambiente de produção. A falha da UMTINO foi exatamente não ter definido e documentado essas regras de separação, permitindo que o software fosse alterado diretamente em produção, sem os devidos controles.

Na prática, a separação de ambientes envolve: (1) ambientes físicos ou lógicos distintos para desenvolvimento, teste e produção; (2) políticas de acesso diferenciadas para cada ambiente; (3) procedimentos formais de promoção de código entre ambientes; e (4) registro e aprovação das mudanças. A alternativa C captura precisamente essa essência, ao mencionar "separar facilidades de desenvolvimento, testes e operações" e "nível de separação necessário para prevenir problemas operacionais". As demais alternativas, embora sejam controles válidos da norma, não atacam diretamente a causa raiz do problema descrito no enunciado.

Guarde a distinção central: enquanto a alternativa A trata da segregação de funções (pessoas diferentes para tarefas conflitantes), a alternativa C trata da separação de ambientes (desenvolvimento, teste e produção). A banca explora exatamente essa confusão: ambas são controles de segurança, mas respondem a problemas diferentes. O enunciado deixa claro que o problema foi a mudança de estado do software sem níveis de separação, o que aponta diretamente para a separação de ambientes.

Alternativa A — ❌ Incorreta

A alternativa descreve corretamente o conceito de segregação de funções (ou segregação de responsabilidades), que é um controle válido da norma ISO/IEC 27002. No entanto, ela não responde ao problema específico da UMTINO. A segregação de funções visa evitar que uma única pessoa execute tarefas conflitantes (ex.: quem desenvolve não deve ser quem aprova a promoção para produção), mas o enunciado fala em "regras para a mudança do estado do software" e "níveis de separação", o que remete à separação de ambientes, não à separação de pessoas. A alternativa A confunde o controle de segregação de funções com o de separação de ambientes.

Alternativa B — ❌ Incorreta

O controle de mudanças operacionais é, de fato, uma prática essencial da norma, e a alternativa descreve corretamente sua diretriz (definir responsabilidades gerenciais e integrar procedimentos de controle de mudanças). Porém, o enunciado especifica que o problema foi a falta de "níveis de separação" para a mudança de estado do software. O controle de mudanças é um processo de gestão (quem aprova, como registra), enquanto a separação de ambientes é uma medida estrutural (ambientes distintos). A alternativa B não aborda a separação entre desenvolvimento, teste e produção, que é o cerne da questão.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta alternativa reproduz fielmente a diretriz da norma ISO/IEC 27002 sobre separação de ambientes de desenvolvimento, teste e operação. O texto da alternativa espelha o controle da norma: "separar facilidades de desenvolvimento, testes e operações, indicando um nível de separação necessário para prevenir problemas operacionais, principalmente em termos de acesso ou modificações não autorizadas". É exatamente o que a UMTINO deixou de fazer: não definiu níveis de separação entre os ambientes, permitindo que mudanças no software fossem feitas sem controle, causando o prejuízo. A alternativa C é a única que ataca diretamente a causa raiz descrita no enunciado.

Alternativa D — ❌ Incorreta

O gerenciamento de incidentes é uma prática essencial da norma (controle 16.1.1), mas trata da resposta a incidentes já ocorridos, não da prevenção de problemas operacionais decorrentes de mudanças não controladas. O enunciado descreve um problema de prevenção (falta de separação de ambientes), não de resposta a incidentes. A alternativa D seria adequada se o problema fosse a falta de procedimentos para lidar com incidentes de segurança, mas não é o caso.

Alternativa E — ❌ Incorreta

A documentação de procedimentos operacionais é uma prática válida e necessária, e a alternativa descreve corretamente seu conteúdo (manutenção, manipulação de erros, contratos de suporte, recuperação). No entanto, a alternativa é genérica: ela não menciona a separação de ambientes, que é o ponto central do problema da UMTINO. Documentar procedimentos é importante, mas não resolve a falta de separação entre desenvolvimento, teste e produção. A alternativa E confunde a documentação de procedimentos com a separação de ambientes, que são controles distintos.

Gabarito: letra C