雲端安全屬於共同責任，現在是個很好的時間點去進一步地探討這個想法，看看這個模型應用到真實環境內會如何。
這個模型
在我們深入探討之前，讓我們先確保彼此對於這個模型有著相同的理解。
這是個很簡單直接的模型。讓我們從安全需求無所不在這觀點開始，為了管理一次部署的安全性，我們將各種責任劃分成以下幾個領域：
- 實體基礎架構
- 網路基礎架構
- 虛擬化層
- 作業系統
- 應用程式
- 資料
下一步就是要確認誰該負責上述各領域的安全性：AWS（雲端服務供應商）或使用者 （使用雲端服務的人）。
根據服務的不同，「需要為該領域負責的人」也會有所不同。
這些領域的安全責任會隨著你所使用服務的類型而改變。
以使用EC2作為例子，AWS負責實體基礎架構、網路基礎結構和虛擬化層。這代表你需要負責作業系統、應用程式和資料方面的安全性。
身為一個認真（也可以說是偏執）的資安工作者，你會想要確認AWS有負責好他們的那一塊（這裏先透露答案：他們有）。你可以連上https://aws.amazon.com/compliance和https://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（首席工程師）