多雲環境下安全面臨的概念性及技術性挑戰
現代公共雲環境給世界提供了無數可能。主流雲服務(如：亞馬遜AWS、微軟Azure和谷歌雲平臺(GCP))不僅有健壯的解決方案，其服務和功能還在不斷增加。
時至今日，81%的公司企業與多家雲服務提供商(CSP)合作。
採用多雲戰略的原因各不相同：可能是想在另一個雲平臺上建立災難恢復(DR)，或者按最適宜的雲服務來平衡工作負載，也可能是公司併購的產物。無論多雲環境是如何引入的， 保護多雲平臺的安全始終是擺在公司企業面前的一大挑戰。
雲供應商爭先恐後地補齊自己的功能短板，並努力在產品上出新出彩，以求吸引並留住客戶。他們的安全服務發展很快，能跨不同安全領域提供強大的安全功能，但安全功能的實現方式卻多種多樣。有些服務可能看起來差不多，但細微的差異也能導致安全問題和配置錯誤。
多雲部署中安全公司會面臨哪些挑戰呢？
1. 不同供應商引入不同賬戶模式
第一個挑戰就出現在部署之初：每個雲供應商都有自己的一套獨特的賬戶管理模式。安全公司常需將資源匹配給雲供應商的客戶。為此，他們必須理解需應用的正確許可權模式。使用多個異構CSP的情況下，此項任務就頗具挑戰性了。
AWS模式基於雲賬戶，可以將賬戶分配給某個公司，讓使用者來指定的計費和策略繼承。
GCP基於專案。任何GCP資源都必須屬於某個專案。專案放置在目錄中，支援多級目錄。
Azure基於訂閱，一個賬戶可以包含多個訂閱。Azure資源被分組為資源組，按訂閱管理。
雖然這些不同的概念相互關聯，但還是存在可以影響到安全的細微差別。要理解資源層級，就需知道該應用哪種安全模型。
2. 控制不同平臺上的安全組
IT工程師積累了數十年的私有網路經驗。但雖然實體域控制器(DC)中他們控制從電纜到應用的一切東西，在雲環境下，卻是亞馬遜、微軟和谷歌控制著物理層，並建立了執行在虛擬網路上的不同服務。雲解決方案使用的路由模型不同於DC所用的，不同雲解決方案使用的模型也各不相同。DC的網路防火牆嵌入到基礎設施即安全組(SG)裡，而SG之間各有不同。
AWS SG 包含入站和出站流量規則，都是些“允許”規則，作為白名單起到流量放行作用。使用者可以將多個SG接入每個彈性計算雲(EC2)例項(實際上是彈性網路介面(ENI))，每個安全組的規則被有效聚合，創建出一整套規則。SG可被應用到不同實體，包括例項或負載平衡器之類的託管服務。
Azure網路安全組(NSG)和谷歌彈性計算雲(GCP) SG 提供的體驗更近似經典防火牆，擁有允許和禁止兩張規則列表。規則的順序很重要：高優先順序規則控制著流量是允許還是禁止的決策權。Azure只允許一臺虛擬機器有一個NSG，而NSG也可應用到連線虛擬機器的子網或網路介面(NIC)上。GCP安全組基於標籤，允許將規則附加到虛擬機器之類資產上。
建立網路時需得考慮到實現正確模型的需求。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中明明允許了的流量還會被封堵了。
一些建議
- 以上例子還只是多雲解決方案帶給我們的真實體驗與挑戰當中的一小部分。成為一個雲平臺的專家就需要很多時間的磨練，在多雲環境下工作就更困難更容易出錯了。為減小風險，可以遵循以下建議：
- 自動化過程。人工改動容易出錯；自動化可以減少出錯概率。
- 採購跨雲系統。提供不同雲平臺上的抽象和類似體驗的解決方案，可以消除上下文切換的問題。
- 採納改動稽核機制。