多雲環境下安全麵臨的概念性及技術性挑戰

作者: 伊人影院科技集團 / 時間: 2019-07-18 09:34:15
瀏覽次數 146

現代公共雲環境給世界提供了無數可能。主流雲服務(如:亞馬遜AWS、微軟Azure和穀歌雲平台(GCP))不僅有健壯的解決方案,其服務和功能還在不斷增加。

1

時至今日,81%的公司企業與多家雲服務提供商(CSP)合作。

采用多雲戰略的原因各不相同:可能是想在另一個雲平台上創建災難恢複(DR),或者按最適宜的雲服務來平衡工作負載,也可能是公司並購的產物。無論多雲環境是如何引入的, 保護多雲平台的安全始終是擺在公司企業麵前的一大挑戰。

雲供應商爭先恐後地補齊自己的功能短板,並努力在產品上出新出彩,以求吸引並留住客戶。他們的安全服務發展很快,能跨不同安全領域提供強大的安全功能,但安全功能的實現方式卻多種多樣。有些服務可能看起來差不多,但細微的差異也能導致安全問題和配置錯誤。

多雲部署中安全公司會麵臨哪些挑戰呢?

1. 不同供應商引入不同賬戶模式

第一個挑戰就出現在部署之初:每個雲供應商都有自己的一套獨特的賬戶管理模式。安全公司常需將資源匹配給雲供應商的客戶。為此,2010年比特幣成交價格,他們必須理解需應用的正確權限模式。使用多個異構CSP的情況下,此項任務就頗具挑戰性了。

AWS模式基於雲賬戶,可以將賬戶分配給某個公司,讓用戶來指定的計費和策略繼承。

2

GCP基於項目。任何GCP資源都必須屬於某個項目。項目放置在目錄中,支持多級目錄。

Azure基於訂閱,一個賬戶可以包含多個訂閱。Azure資源被分組為資源組,按訂閱管理。

3

雖然這些不同的概念相互關聯,但還是存在可以影響到安全的細微差別。要理解資源層級,就需知道該應用哪種安全模型。

2. 控製不同平台上的安全組

IT工程師積累了數十年的私有網絡經驗。但雖然實體域控製器(DC)中他們控製從電纜到應用的一切東西,在雲環境下,卻是亞馬遜、微軟和穀歌控製著物理層,並創建了運行在虛擬網絡上的不同服務。雲解決方案使用的路由模型不同於DC所用的,不同雲解決方案使用的模型也各不相同。DC的網絡防火牆嵌入到基礎設施即安全組(SG)裏,而SG之間各有不同。

AWS SG 包含入站和出站流量規則,都是些“允許”規則,作為白名單起到流量放行作用。用戶可以將多個SG接入每個彈性計算雲(EC2)實例(實際上是彈性網絡接口(ENI)),每個安全組的規則被有效聚合,創建出一整套規則。SG可被應用到不同實體,包括實例或負載平衡器之類的托管服務。

Azure網絡安全組(NSG)和穀歌彈性計算雲(GCP) SG 提供的體驗更近似經典防火牆,擁有允許和禁止兩張規則列表。規則的順序很重要:高優先級規則控製著流量是允許還是禁止的決策權。Azure隻允許一台虛擬機有一個NSG,而NSG也可應用到連接虛擬機的子網或網絡接口(NIC)上。GCP安全組基於標簽,允許將規則附加到虛擬機之類資產上。

4

創建網絡時需得考慮到實現正確模型的需求。Azure中規則優先級設置錯誤,可能導致流量被誤允許。AWS中的虛擬機若被指派了多個安全組,原始SG拒絕掉的流量就有可能被誤允許。主要與AWS打交道的工程師可以修改拒絕優先規則並阻止對服務的訪問(或者,在不應該暴露服務的情況下將其暴露到互聯網上)。配置安全需要清醒的頭腦,總在不同部署中間切換的IT工程師就很容易出錯。

3. 雲中虛擬網絡的行為模式不同

進一步深入到網絡層。AWS虛擬專用雲(VPC)子網可以是私有的,也可以是公共的;連接互聯網網關(IGW)就是公共的。隻有公共子網允許自身部署的資源訪問互聯網。Azure VNet 沒有私有或公共子網;連接VNet的資源默認可以訪問互聯網。習慣了AWS的工程師依賴AWS來阻止實例訪問互聯網。但在Azure上創建DR站點時,工程師就得顯式阻止互聯網訪問了。上下文切換問題可能是有危險的。

AWS組網中的另一個問題與網絡訪問控製(NACL)有關。NACL檢測流量出入子網情況,運行在子網層級,而SG運行在虛擬機層級(實際上是彈性網絡接口層)。NACL是無狀態的,也就是說幾百年入站流量被允許了,其響應也未必就自動允許——除非子網規則中顯示允許。AWS提供的下列圖表闡明了跨不同安全層的流量流。

Azure和GCP不采用NACL的概念,於是從這些平台遷移到AWS的工程師常常搞不清楚為什麽SG中明明允許了的流量還會被封堵了。

聲明:本網所有文章(包括圖片和音視頻資料)係出於傳遞更多信息之目的,且明確注明來源和作者,不希望被轉載的媒體或個人可與伊人影院聯係,伊人影院將立即進行刪除處理。所有文章僅代表作者觀點,不代表本站立場。