2017-04-16 25 views
2

我們用下面的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更好,那麼也很有趣。

回答

2

根據應用程序的性質和合規性要求,在CF上卸載SSL。

一般來說,如果所有實體訪問通過CF應用(例如不具有某些客戶端的VPN連接到後端VPC)在CF卸載是足夠的。兩者都具有SSL的性能差異並不顯着。

,只允許從入站到CF ELB,有可用的那一刻沒有直接的方法。一種可能的方法是使用Lambda函數更新ELB的安全組,從AWS提供的JSON url中獲取CF IP範圍。

此外SSL卸載在CF被更快相比ELB,因爲有,在邊緣位置操作接受您的連接,同時ELB具有用於每個AZS服務器的許多服務器(通常爲2或3)。

+1

*「一個可能的方法是使用Lambda函數來更新ELB的安全組,正從AWS的CF IP範圍內提供JSON的URL。」 *這不是特別有用,因爲它仍然允許*任何* CloudFront的分佈(包括由其他人創建)聯繫您的ELB。 –

+1

確實,其他CF也可以在安全組白名單中列出CF IP範圍時訪問,但由於CF僅允許第7層流量,因此減少了攻擊面。但是,如果您希望將其限制爲單個CF,則可以將安全組與CF生成的標題結合使用,並在您的服務器上進行驗證 – Ashan

+1

另一個原因是,在部署在CloudFront後面時,ELB對ELB的影響應該很小,因爲CloudFront將會堅持並重用自身與ELB之間的連接,最大限度地減少設置這些連接的開銷,這是一個耗時且昂貴的SSL部分。 –