雲端安全:共同責任進行中

雲端安全屬於共同責任,現在是個很好的時間點去進一步地探討這個想法,看看這個模型應用到真實環境內會如何。

Cloud5

這個模型

在我們深入探討之前,讓我們先確保彼此對於這個模型有著相同的理解。

這是個很簡單直接的模型。讓我們從安全需求無所不在這觀點開始,為了管理一次部署的安全性,我們將各種責任劃分成以下幾個領域:

  • 實體基礎架構
  • 網路基礎架構
  • 虛擬化層
  • 作業系統
  • 應用程式
  • 資料

下一步就是要確認誰該負責上述各領域的安全性:AWS(雲端服務供應商)或使用者 (使用雲端服務的人)。

根據服務的不同,「需要為該領域負責的人」也會有所不同。

這些領域的安全責任會隨著你所使用服務的類型而改變。

以使用EC2作為例子,AWS負責實體基礎架構、網路基礎結構和虛擬化層。這代表你需要負責作業系統、應用程式和資料方面的安全性。

身為一個認真(也可以說是偏執)的資安工作者,你會想要確認AWS有負責好他們的那一塊(這裏先透露答案:他們有)。你可以連上http://aws.amazon.com/compliance和http://aws.amazon.com/security來確認。

移動標準(Sliding Scale) 

雖然EC2是最常使用的例子,你對AWS的每個服務都有安全責任。這些責任和服務類型有直接的關係。對於此移動標準的共同觀點是:

但我更加喜歡Mark Ryland區分服務的方式。Mark並非使用IaaS > PaaS > SaaS,他所採用的方式是基礎架構(infrastructure) > 容器(container) > 抽象(abstract)。

這樣子就可以很容易的了解你對於服務安全性的責任層級。

EC2、EBS、VPC等是基礎架構服務。RDS、EMR、OpsWorks 等是容器服務;SQS、SNS、SE、Route53等可算是抽象的類別。

這裡的一般規則是,服務越抽象,你的安全責任就越不那麼直接。

 

控制項與決定項

我們是故意用「直接安全責任」這個詞。像是基礎架構服務,為了履行你的責任,你會需要實施、運作和維護更多的安全控制項。

除了充分運用AWS所提供的像是IAM、安全性群組和網路存取控制列表等選項之外。最少還要做到像是強化作業系統和安裝協力廠商控制項(如入侵防禦系統、防毒軟體、程序監控等。)

當你越向容器和抽象服務移動,你所需要部署和維護的直接控制項也減少。你對這些服務的責任變得越來越注重正確的設定存取管理(通常透過 IAM)和決定什麼類型的資料要處理和儲存。

還有更多

雖然這個模型大體來說很簡單呈現和理解,在應用上還是有許多細微的差別。

可參考我在AWS HQ所演講的幻燈片

 

@原文出處:Cloud Security: Shared Responsibility in Action作者:Mark Nunnikhoven(首席工程師)