Nos bastidores de uma solicitação da web https no lado do servidor na nuvem

Nos bastidores de uma solicitação da web https no lado do servidor na nuvem

Eu li algumas postagens sobre os bastidores do processamento de uma solicitação da web, que também é uma pergunta popular em entrevistas para SREs/DevOps. Existem muitas páginas de explicação boas sobre o fluxo geral disso: Resolução DNS -> conexão tcp -> Conexão SSL -> solicitação HTTPS -> Balanceador de carga -> Firewall -> servidor web e a partir daí a solicitação volta.

Mas não consegui encontrar resposta para algumas dúvidas nos bastidores do lado do servidor, especialmente para nuvem. Tipo, o que acontece quando a solicitação chega ao balanceador de carga global? Ele termina o SSL lá ou vai para o balanceador de carga interno (se configurado) e termina lá? A partir daí, a solicitação para uma VM específica não é segura, onde há outros fornecedores que também hospedam VMs e balanceadores de carga internos. A solicitação está protegida por algumas ACLs/firewall ou algum mecanismo interno de VPC?

Entendo que podemos criptografar novamente ou encaminhar o tráfego criptografado para o servidor da Web para obter melhor segurança, mas com alto custo de recursos. Mas o que acontece quando não estamos fazendo isso? Sinto que ainda haveria algum outro mecanismo de segurança usado para evitar acesso fácil.

Desde já, obrigado.

Responder1

Ansiando por um comentário:

Perguntas de entrevista como essa não são exames de ciências na escola, com apenas uma resposta correta e você não deve esperar"passar"apenas repetindo respostas encontradas em plataformas aleatórias da Internet. E geralmente você não “falha” por perder algo com o qual não tem interesse nem familiaridade (a menos que seja um requisito específico do trabalho).

Meu colega fabrica seus próprios teclados e ficaria emocionado se você iniciasse sua cadeia de eventos com os sinais elétricos gerados ao pressionar uma tecla no teclado. Eu não poderia me importar menos.

Se você estava me entrevistando, sua resposta é boa o suficiente para não ser desqualificada imediatamente (mas também não sei o suficiente sobre, por exemplo, a especificação DNSSEC para desafiá-lo imediatamente no primeiro elo da cadeia de eventos que você descreve), mas Eu seria acionado por sua observação:”tráfego criptografado para melhor segurança, mas alto custo de recursos”como isso é dito com freqüência eEu pessoalmente tenho minhas dúvidassobre a veracidade dessa afirmação.

No que diz respeito ao design de segurança e às compensações de segurança, as medidas que você deseja projetar são uma resposta às ameaças reais e percebidas determinadas em uma análise de risco e à sua relação custo-benefício.
Esses riscos não são uma verdade universal (embora alguns sejam muito comuns), diferem de empresa para empresa e muitas vezes os riscos mudam com base em medidas já implementadas.
Na vida real, você verá padrões de design comuns implementados de forma diferente com base em diferentes circunstâncias. Como implementar o balanceamento de carga e onde encerrar o TLS também é uma dessas coisas. Como um pensamento de despedida:”Você ainda precisa de HTTPS quando usa IPSEC?”

informação relacionada