雲端伺服器端 https Web 請求的幕後花絮

雲端伺服器端 https Web 請求的幕後花絮

我讀過一些關於處理 Web 請求幕後的文章,這對 SRE/DevOps 來說也是一個流行的面試問題。關於一般流程有很多很好的解釋頁面:DNS 解析 -> tcp 連線 -> SSL 連線 -> HTTPS 請求 -> 負載平衡器 -> 防火牆 -> Web 伺服器,然後要求返回。

但我無法在伺服器端專門針對雲端的幕後找到一些疑問的答案。例如,當請求到達全域負載平衡器時會發生什麼?它是在那裡終止 SSL 還是轉到內部負載平衡器(如果已配置)並在那裡終止?從那裡到特定虛擬機器的請求是不安全的,其中還有其他供應商也託管那裡的虛擬機器和內部負載平衡器。請求是否透過某些 ACL/防火牆或某些內部 VPC 機制進行保護?

據我了解,我們可以重新加密或將加密流量轉發到網路伺服器,以獲得更好的安全性,但資源成本較高。但是當我們不這樣做時會發生什麼?我覺得還是會使用一些其他安全機制來避免輕易存取。

提前致謝。

答案1

太渴望評論了:

像這樣的面試問題不是學校裡的科學考試,只有一個正確答案,你不應該期望“經過”透過模仿在隨機網路平台上找到的答案。通常你不會因為錯過一些你既不感興趣也不熟悉的東西而「失敗」(除非它是特定的工作要求)。

我的同事製作了自己的鍵盤,如果您使用鍵盤上按鍵產生的電信號來開始一系列事件,他會感到很興奮。我一點也不在乎。

如果你正在接受我的面試,你的回答足夠好,不會立即被取消資格(但我對DNSSEC 規範的了解也不夠,無法在你描述的事件鏈的第一個環節立即向你提出挑戰),但是我會被你的話所觸動:“加密流量可以提高安全性,但資源成本較高”正如人們常說的那樣我個人有疑問關於該說法的真實性。

關於安全設計和安全權衡,您想要設計的措施是對風險分析中確定的實際和感知威脅及其成本效益比的回應。
這些風險並不是普遍存在的事實(儘管有些風險非常常見),它們因公司而異,並且通常風險會根據已實施的措施而變化。
在現實生活中,您會看到常見的設計模式根據不同的情況以不同的方式實現。如何實現負載平衡以及在何處終止 TLS 也是其中之一。作為臨別感想:“當您使用 IPSEC 時,還需要 HTTPS 嗎?”

相關內容