Segurança em pipelines de CI/CD e infraestrutura de rede
Gabarito: letra A. A alternativa correta afirma que o balanceamento de carga deve distribuir solicitações entre servidores em ambientes de teste e produção, promovendo escalabilidade e alta disponibilidade — exatamente a função central de um balanceador de carga (como Nginx e HAProxy) em uma arquitetura moderna. As demais alternativas contêm erros técnicos que comprometem a segurança ou a disponibilidade, como tornar testes de segurança opcionais, dispensar balanceamento entre aplicações internas, manter rotinas manuais de verificação ou usar canais abertos na comunicação interna.
O enunciado descreve um cenário de modernização de infraestrutura com práticas de DevSecOps (SAST, DAST, verificação de dependências) e serviços de rede (DNS, DHCP, SMTP, proxies reversos). A questão testa o conhecimento sobre o papel de cada componente e as boas práticas de segurança e disponibilidade. O balanceamento de carga é uma técnica fundamental para distribuir o tráfego entre múltiplos servidores, garantindo que nenhum fique sobrecarregado e que, se um falhar, os demais continuem atendendo — isso é escalabilidade e alta disponibilidade. Essa distribuição deve ocorrer tanto em ambientes de teste quanto em produção, pois ambos precisam de resiliência e desempenho.
O SAST (Static Application Security Testing) analisa o código-fonte estaticamente, enquanto o DAST (Dynamic Application Security Testing) testa a aplicação em execução. Ambos são complementares e devem ser integrados ao pipeline de CI/CD de forma automatizada e obrigatória, não opcional. A verificação de dependências (SCA) identifica vulnerabilidades em bibliotecas de terceiros. Essas práticas seguem o modelo DevSecOps, que integra segurança em todas as fases do desenvolvimento, seguindo o princípio de "shift-left" (antecipar a segurança).
Os proxies reversos, como Nginx e HAProxy, atuam como intermediários entre clientes e servidores, oferecendo funcionalidades como balanceamento de carga, terminação SSL, cache e proteção contra ataques. O SSL offloading (ou terminação SSL) é uma técnica em que o proxy descriptografa o tráfego de entrada, inspeciona-o e o encaminha aos servidores internos, muitas vezes em HTTP. Isso reduz a carga de criptografia nos servidores de aplicação, mas a comunicação interna também deve ser protegida, especialmente em arquiteturas de confiança zero (Zero Trust), onde nenhuma comunicação é implicitamente confiável.
A pegadinha central desta questão é a tentativa de relativizar a segurança em nome da praticidade ou do desempenho. Alternativas que sugerem testes opcionais, rotinas manuais, dispensa de balanceamento ou canais abertos internos contradizem as boas práticas de segurança e disponibilidade. A banca explora a tendência do candidato de aceitar soluções "mais simples" ou "mais rápidas" sem considerar o impacto na segurança.
Guarde o critério decisivo: em questões de infraestrutura e segurança, a alternativa correta é aquela que reforça a automação, a segurança em todas as camadas e a alta disponibilidade. Alternativas que enfraquecem qualquer um desses pilares são distratores.
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa está correta porque descreve com precisão a função do balanceamento de carga: distribuir solicitações entre servidores para promover escalabilidade e alta disponibilidade. Essa distribuição deve ocorrer tanto em ambientes de teste quanto em produção, pois ambos precisam de resiliência e desempenho. O balanceamento de carga é uma prática essencial em arquiteturas modernas, permitindo que o sistema cresça horizontalmente (escalabilidade) e continue operando mesmo se um servidor falhar (alta disponibilidade).
Alternativa B — ❌ Incorreta
A alternativa erra ao tornar os testes de segurança "opcionais". Em um modelo DevSecOps, a segurança é integrada ao pipeline de forma contínua e obrigatória, não opcional. Testes de segurança (SAST, DAST, SCA) devem ser executados automaticamente em todas as builds, independentemente da criticidade da aplicação. A criticidade pode influenciar a profundidade ou a frequência dos testes, mas nunca a sua execução. A banca explora a ideia de que "nem toda aplicação precisa de testes de segurança", o que é uma falácia perigosa.
Alternativa C — ❌ Incorreta
A alternativa está errada ao afirmar que o uso de proxies reversos "dispensa o balanceamento aplicado entre aplicações internas homologadas". O proxy reverso é justamente uma das ferramentas usadas para implementar balanceamento de carga, e essa função não é dispensada — ela é essencial para distribuir o tráfego entre as aplicações internas, garantindo disponibilidade e desempenho. A alternativa confunde o papel do proxy reverso, que não substitui o balanceamento, mas o implementa.
Alternativa D — ❌ Incorreta
A alternativa erra ao sugerir "rotina manual de verificação periódica" para administração de DNS e DHCP. Em infraestruturas modernas, a administração desses serviços deve ser automatizada e centralizada, com políticas de atualização e segurança gerenciadas de forma proativa, não manual. A automação reduz erros humanos, garante consistência e permite resposta rápida a incidentes. A banca explora a ideia de que "verificação manual é mais segura", o que é incorreto — a automação é uma prática recomendada.
Alternativa E — ❌ Incorreta
A alternativa está errada ao afirmar que a comunicação entre serviços internos deve usar "canais abertos para reduzir latência e sobrecarga". Em uma arquitetura de segurança robusta, especialmente com o modelo Zero Trust, toda comunicação — inclusive interna — deve ser criptografada. O SSL offloading no proxy reverso é correto para o tráfego de entrada, mas a comunicação interna também deve ser protegida (por exemplo, com mTLS). A alternativa sacrifica a segurança em nome do desempenho, o que é uma prática inadequada.
Gabarito: letra A