Pular para o conteúdo principal

Questão de Redes de Computadores — Protocolo — FGV 2024

Redes de ComputadoresProtocolo
Código
fg101741
Banca
FGV
Órgão
TRF - 1ª REGIÃO
Ano
2024
Nível
Superior
Cargo
Técnico Judiciário - Área Administrativa - Especialidade: Desenvolvimento de Sistemas de Informação
O analista Anderson está reforçando a segurança das rotas públicas no OpenShift do TRF1. Ele deve habilitar o HTTP Strict Transport Security (HSTS) para a rota 12. No OpenShift, o HSTS é efetivo apenas se aplicado a rotas com determinados tipos de segurança.Para que o HSTS seja efetivo na rota 12, Anderson deve se certificar de que a segurança da rota é do tipo:
  1. Ainsecure ou edge;
  2. Bedge ou re-encrypt;
  3. Cedge ou passthrough;
  4. Dinsecure ou re-encrypt;
  5. Einsecure ou passthrough.
Revelar gabarito e comentário

GabaritoB — edge ou re-encrypt;

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”.

HSTS no OpenShift – tipos de rota compatíveis

Gabarito: letra B. O HTTP Strict Transport Security (HSTS) instrui o navegador a sempre usar HTTPS. No OpenShift, o HSTS só é efetivo se o roteador (router) puder inserir o cabeçalho Strict-Transport-Security na resposta. Isso ocorre apenas em rotas com terminação TLS no roteador: edge (TLS termina no router, tráfego HTTP para os pods) e re-encrypt (TLS termina no router e é re-criptografado para os pods). Nas rotas passthrough, a conexão é criptografada integralmente até o pod, impedindo o router de modificar os cabeçalhos. Já as rotas insecure são puramente HTTP, sem TLS. Portanto, HSTS não se aplica a rotas insecure nem passthrough.

Tipo de Rota

HSTS é efetivo?

Motivo

Edge

Sim

O roteador termina o TLS e pode inserir o cabeçalho HSTS.

Re-encrypt

Sim

O roteador termina o TLS e pode inserir o cabeçalho HSTS (depois re-criptografa para o pod).

Passthrough

Não

O TLS vai diretamente ao pod; o roteador não pode modificar cabeçalhos.

Insecure

Não

É rota HTTP pura, sem TLS; HSTS exige HTTPS.

Rota OpenShift
  • 1HSTS efetivo
    • Edge (TLS termina no router)
    • Re-encrypt (router reinsere TLS)
  • 2HSTS inefetivo
    • Passthrough (router não vê HTTP)
    • Insecure (HTTP puro)
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Inclui insecure, que é HTTP, portanto não suporta HSTS. O correto seria apenas edge (e também re-encrypt).

Alternativa B — ✅ Correta ⟵ GABARITO

Lista exatamente os dois tipos de terminação TLS que permitem ao router inserir o cabeçalho HSTS: edge e re-encrypt.

Alternativa C — ❌ Incorreta

Inclui passthrough, que não permite modificação de cabeçalhos pelo router, inviabilizando o HSTS.

Alternativa D — ❌ Incorreta

Inclui insecure (HTTP sem TLS), incompatível com HSTS. Apesar de conter re-encrypt, a presença de insecure torna a alternativa errada.

Alternativa E — ❌ Incorreta

Ambos os tipos (insecure e passthrough) são incompatíveis com HSTS por razões distintas: ausência de TLS e impossibilidade de injeção de cabeçalho, respectivamente.

PEGA ESSA DICA!

Memorize: no OpenShift, HSTS funciona apenas em rotas edge e re-encrypt. Nas provas, a banca costuma incluir passthrough ou insecure como distratores. Lembre-se de que o router precisa "ver" e modificar os cabeçalhos HTTP — o que não ocorre no passthrough.

Link permanente: /questoes/fg101741