Detrás de escena de una solicitud web https en el lado del servidor en la nube

Detrás de escena de una solicitud web https en el lado del servidor en la nube

He leído algunas publicaciones sobre el detrás de escena del procesamiento de una solicitud web, que también es una pregunta de entrevista popular para SRE/DevOps. Hay muchas buenas páginas de explicación sobre el flujo general de eso: resolución DNS -> conexión tcp -> Conexión SSL -> Solicitud HTTPS -> Equilibrador de carga -> Firewall -> servidor web y desde allí la solicitud regresa.

Pero no pude encontrar respuesta a algunas dudas detrás de escena en el lado del servidor, especialmente para la nube. ¿Qué sucede cuando la solicitud llega al equilibrador de carga global? ¿Termina el SSL allí o va al balanceador de carga interno (si está configurado) y termina allí? A partir de ahí, la solicitud a una VM en particular no es segura, donde hay otros proveedores que también alojan sus VM y el balanceador de carga interno. ¿La solicitud está protegida a través de algunas ACL/firewall o algún mecanismo interno de VPC?

Entiendo que podemos volver a cifrar o reenviar el tráfico cifrado al servidor web para mayor seguridad pero con un alto costo de recursos. Pero ¿qué pasa cuando no hacemos eso? Siento que todavía se utilizaría algún otro mecanismo de seguridad para evitar un fácil acceso.

Gracias de antemano.

Respuesta1

Anhelar un comentario:

Preguntas de entrevista como esa no son exámenes de ciencias en la escuela, con una sola respuesta correcta y no debes esperar"aprobar"simplemente repitiendo como loros las respuestas encontradas en plataformas de Internet aleatorias. Y normalmente no “fallas” por perderte algo que no te interesa ni con lo que no estás familiarizado (a menos que sea un requisito laboral específico).

Mi colega fabrica sus propios teclados y le hubiera encantado que comenzara su cadena de eventos con las señales eléctricas que se generan al presionar una tecla en su teclado. No podría importarme menos.

Si me estaba entrevistando, su respuesta es lo suficientemente buena como para no ser descalificado de inmediato (pero tampoco sé lo suficiente, por ejemplo, sobre la especificación DNSSEC para desafiarlo de inmediato en el primer eslabón de la cadena de eventos que describe), pero Me motivaría tu comentario:"tráfico cifrado para mayor seguridad pero alto costo de recursos"como eso se dice frecuentemente yyo personalmente tengo mis dudassobre la veracidad de esa afirmación.

Con respecto al diseño de seguridad y las compensaciones de seguridad, las medidas que desea diseñar son una respuesta a las amenazas reales y percibidas determinadas en un análisis de riesgos y su relación costo-beneficio.
Esos riesgos no son una verdad universal (aunque algunos son muy comunes), difieren de una empresa a otra y, a menudo, los riesgos cambian en función de las medidas ya implementadas.
En la vida real, verá patrones de diseño comunes implementados de manera diferente según las diferentes circunstancias. Cómo implementar el equilibrio de carga y dónde terminar TLS también es una de esas cosas. Como pensamiento de despedida:"¿Todavía necesitas HTTPS cuando usas IPSEC?"

información relacionada