Segurança da Informação em Contratações de Nuvem e Desenvolvimento de Software
Gabarito: letra D. A alternativa correta reúne práticas de segurança e conformidade técnica adequadas para uma contratação pública de serviços de nuvem e desenvolvimento de software: exigir certificação SOC 2 Type II do provedor, utilizar métricas de Ponto de Função com análise estática de código (SAST) e prever sanções por descumprimento de níveis de serviço de segurança. As demais alternativas apresentam equívocos conceituais ou práticas inadequadas para o contexto.
A questão aborda a segurança da informação no contexto de contratação de serviços de nuvem e desenvolvimento de software, um tema recorrente em concursos públicos. Para resolver corretamente, é preciso dominar alguns conceitos fundamentais:
1. Modelos de implantação de nuvem:
Public Cloud (Nuvem Pública): Infraestrutura compartilhada, provisionada para uso aberto pelo público em geral. O provedor gerencia a infraestrutura.
Private Cloud (Nuvem Privada): Infraestrutura dedicada a uma única organização, oferecendo maior controle e segurança.
Community Cloud (Nuvem Comunitária): Infraestrutura compartilhada por várias organizações com interesses comuns (ex.: órgãos governamentais).
Hybrid Cloud (Nuvem Híbrida): Combinação de nuvens públicas e privadas.
Multicloud: Uso de múltiplos provedores de nuvem pública para evitar dependência de um único fornecedor (vendor lock-in).
2. Modelos de serviço em nuvem:
IaaS (Infraestrutura como Serviço): Oferece infraestrutura virtualizada (servidores, armazenamento, redes).
PaaS (Plataforma como Serviço): Oferece uma plataforma para desenvolvimento e implantação de aplicações.
SaaS (Software como Serviço): Oferece software pronto para uso, acessado via internet.
3. Métricas de desenvolvimento de software:
Ponto de Função: Métrica de tamanho funcional do software, baseada na funcionalidade entregue ao usuário, independente da tecnologia utilizada.
Story Points: Métrica de esforço relativo em metodologias ágeis (ex.: Scrum).
4. Análise estática de código (SAST):
5. Certificações de segurança:
SOC 2 Type II: Certificação de auditoria que avalia os controles de segurança, disponibilidade, integridade do processamento, confidencialidade e privacidade de um provedor de serviços, com base em um período de observação (Type II).
6. Requisitos de acessibilidade:
No Brasil, a acessibilidade digital é regida pela Lei Brasileira de Inclusão (Lei 13.146/2015) e pela WCAG (Web Content Accessibility Guidelines). A ISO 27001 trata de gestão de segurança da informação, não de acessibilidade.
7. Requisitos funcionais e não funcionais:
Requisitos funcionais: Descrevem o que o sistema deve fazer (funcionalidades).
Requisitos não funcionais: Descrevem como o sistema deve se comportar (desempenho, segurança, usabilidade, etc.).
A pegadinha da questão está em misturar conceitos corretos com práticas inadequadas ou atribuir a norma errada a um requisito específico. A alternativa D é a única que apresenta um conjunto coerente e tecnicamente correto de práticas para garantir segurança e conformidade em uma contratação pública.
Alternativa A — ❌ Incorreta
A alternativa A apresenta dois erros principais. Primeiro, a criptografia de ponta a ponta gerida pelo provedor não é uma prática recomendada para garantir a soberania e o controle dos dados pela Administração Pública; o ideal é que a gestão das chaves permaneça com o contratante. Segundo, os requisitos técnicos de sustentabilidade não devem focar apenas no descarte de hardware, mas em todo o ciclo de vida do serviço, incluindo eficiência energética dos data centers. Além disso, entregar o desenvolvimento via SaaS não é uma decisão de segurança, mas sim de modelo de serviço, e não reduz necessariamente a superfície de ataque local.
Alternativa B — ❌ Incorreta
A alternativa B prioriza o modelo On-premises para manter a soberania dos dados, o que contraria o enunciado, que planeja migrar para a nuvem. Além disso, trata a segurança da informação como um requisito funcional específico, quando na verdade ela é um requisito não funcional que deve ser considerado em todo o ciclo de vida do sistema. Por fim, a acessibilidade não deve ser orientada por ferramentas de tradução automática, mas sim por padrões como a WCAG e a legislação brasileira (Lei 13.146/2015).
Alternativa C — ❌ Incorreta
A alternativa C apresenta dois equívocos. Primeiro, o modelo Community Cloud não garante isolamento lógico total; na verdade, ele é compartilhado por organizações com interesses comuns, o que não oferece o mesmo nível de isolamento que uma nuvem privada. Segundo, os requisitos de acessibilidade não seguem a norma ISO 27001, que trata de gestão de segurança da informação, mas sim padrões como a WCAG. O uso de story points em regime Agile é uma prática válida, mas não é suficiente para tornar a alternativa correta.
Alternativa D — ✅ Correta ⟵ GABARITO
A alternativa D é a única que apresenta um conjunto de práticas tecnicamente corretas e adequadas para uma contratação pública de serviços de nuvem e desenvolvimento de software:
Certificações SOC 2 Type II: Exigir essa certificação do provedor de nuvem é uma prática recomendada para garantir que ele possui controles de segurança, disponibilidade, confidencialidade e privacidade adequados, auditados por terceiros.
Métricas de Ponto de Função com SAST: Utilizar Ponto de Função para medir o tamanho funcional do software e integrar a análise estática de código (SAST) no processo de desenvolvimento é uma prática de segurança e qualidade que ajuda a identificar vulnerabilidades precocemente.
Sanções por descumprimento de níveis de serviço de segurança: Prever sanções contratuais para o não cumprimento dos níveis de serviço de segurança é essencial para garantir a conformidade e a responsabilização do contratado.
Alternativa E — ❌ Incorreta
A alternativa E apresenta dois problemas. Primeiro, a sustentação contratada por postos de trabalho presenciais para controle físico é uma prática inadequada para um ambiente de nuvem, que é gerenciado remotamente pelo provedor. Segundo, os requisitos não funcionais de segurança devem ser validados durante todo o ciclo de desenvolvimento, não apenas após a homologação final do software. A arquitetura Multicloud para evitar vendor lock-in é uma prática válida, mas não é suficiente para tornar a alternativa correta.
Gabarito: letra D