Questão de Redes de Computadores — Protocolo — FGV 2024
Redes de Computadores›Protocolo
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:
Ainsecure ou edge;
Bedge ou re-encrypt;
Cedge ou passthrough;
Dinsecure ou re-encrypt;
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.