我們用下面的AWS基礎設施:SSL卸載
Route53-> CloundFront - > Elasticbeanstalk(+負載平衡器= ELB) - > EC2實例
現在我們必須建立在CloudFront的SSL證書級別和ELB級別相同,因此爲我們提供了CF和ELB之間的端到端加密。 End2End AWS CF與原產地之間的結尾被描述爲最佳實踐here。
這是指完全SSL(嚴格)在此picture(這是CloudFlare堆棧,但它是爲了更好的說明,所以沒關係)。我們希望卸載AWS CF級別的SSL,以避免從CF到ELB的往返轉移到Flexible SSL,如圖所示。
卸載CF卡上的SSL是一個好主意嗎?在CF級別之後,是否有任何性能改進值得丟棄end2end加密?
我們可以以某種方式限制ELB只接受來自某些AWS CF的連接嗎?
此外還有約ELB SSL performance一些性能問題(似乎證明是擅長,但我還是有顧慮)。一般來說,如果AWS CF在SSL解密工作上的表現比ELB更好,那麼也很有趣。
*「一個可能的方法是使用Lambda函數來更新ELB的安全組,正從AWS的CF IP範圍內提供JSON的URL。」 *這不是特別有用,因爲它仍然允許*任何* CloudFront的分佈(包括由其他人創建)聯繫您的ELB。 –
確實,其他CF也可以在安全組白名單中列出CF IP範圍時訪問,但由於CF僅允許第7層流量,因此減少了攻擊面。但是,如果您希望將其限制爲單個CF,則可以將安全組與CF生成的標題結合使用,並在您的服務器上進行驗證 – Ashan
另一個原因是,在部署在CloudFront後面時,ELB對ELB的影響應該很小,因爲CloudFront將會堅持並重用自身與ELB之間的連接,最大限度地減少設置這些連接的開銷,這是一個耗時且昂貴的SSL部分。 –