클라우드의 서버 측에서 https 웹 요청의 이면

클라우드의 서버 측에서 https 웹 요청의 이면

SRE/DevOps에게도 인기 있는 인터뷰 질문인 웹 요청 처리 비하인드 스토리에 대한 게시물을 거의 읽지 못했습니다. 일반적인 흐름에 대한 좋은 설명 페이지가 많이 있습니다. DNS 확인 -> tcp 연결 -> SSL 연결 -> HTTPS 요청 -> 로드 밸런서 -> 방화벽 -> 웹 서버에서 요청이 돌아갑니다.

그러나 특히 클라우드의 서버 측에서 이면에 있는 몇 가지 의심에 대한 답을 찾을 수 없었습니다. 예를 들어, 요청이 글로벌 로드 밸런서에 도달하면 어떻게 될까요? 그곳에서 SSL을 종료합니까, 아니면 내부 로드 밸런서(구성된 경우)로 가서 그곳에서 종료됩니까? 거기에서 특정 VM에 대한 요청은 안전하지 않습니다. 여기서는 VM과 내부 부하 분산 장치도 호스팅하는 다른 공급업체가 있습니다. 요청이 일부 ACL/방화벽 또는 일부 내부 VPC 메커니즘을 통해 보호됩니까?

보안을 강화하지만 리소스 비용이 많이 들기 때문에 암호화된 트래픽을 다시 암호화하거나 웹 서버로 전달할 수 있다는 것을 이해합니다. 하지만 우리가 그렇게 하지 않으면 어떻게 될까요? 나는 쉬운 접근을 피하기 위해 사용되는 다른 보안 메커니즘이 여전히 있을 것이라고 생각합니다.

미리 감사드립니다.

답변1

댓글을 기다리려면:

그런 면접 질문은 학교에서 하는 과학 시험이 아니고 정답이 단 하나뿐이므로 기대해서는 안 됩니다."통과하다"무작위 인터넷 플랫폼에서 찾은 답변을 앵무새처럼 따라하는 것뿐입니다. 그리고 일반적으로 관심도 없고 익숙하지도 않은 것을 놓쳤다고 해서 "실패"하지 않습니다(특정 직업 요구 사항이 아닌 한).

내 동료는 자신의 키보드를 만들고 키보드의 키를 누를 때 생성되는 전기 신호로 일련의 이벤트를 시작했다면 매우 기뻐했을 것입니다. 나는 덜 신경 쓸 수 없었다.

당신이 저와 인터뷰를 했다면 당신의 답변은 즉시 실격 처리되지 않을 만큼 충분합니다. (그러나 예를 들어 당신이 설명하는 일련의 이벤트 중 첫 번째 링크에서 즉시 당신에게 도전할 DNSSEC 사양에 대해서는 충분히 알지 못합니다.) 나는 당신의 발언에 촉발될 것입니다:"보안 강화를 위해 트래픽을 암호화하지만 리소스 비용이 높음"자주 말하듯이개인적으로 의문점이 있습니다그 주장의 진실성에 대해.

보안 설계 및 보안 절충과 관련하여 설계하려는 측정은 위험 분석 및 비용 편익 비율에서 결정된 실제 위협과 인지된 위협에 대한 대응입니다.
이러한 위험은 보편적인 사실이 아니며(일부는 매우 일반적임) 회사마다 다르며 이미 구현된 조치에 따라 위험이 변경되는 경우가 많습니다.
실제 생활에서는 상황에 따라 다르게 구현되는 일반적인 디자인 패턴을 볼 수 있습니다. 로드 밸런싱을 구현하는 방법과 TLS를 종료할 위치도 그러한 것 중 하나입니다. 이별의 생각으로 :"IPSEC를 사용할 때 여전히 HTTPS가 필요합니까?"

관련 정보