雲端安全到底誰負責？看懂 AWS 共同責任模型與 IAM 基本觀念

「資料放在 AWS 上，安全就是 AWS 的事了吧？」這大概是雲端安全最常見、也最危險的誤會。翻遍雲端相關的資安事件，很大一部分不是雲端業者被攻破，而是使用者自己把儲存桶設成公開、把金鑰寫進程式碼、給帳號開了過大的權限。

AWS 用一張圖回答「到底誰負責什麼」，就是共同責任模型（Shared Responsibility Model）。這一篇把這張圖講清楚，再帶你認識管理權限的核心服務 IAM 的基本觀念。

一條線分兩半：雲端本身與雲端裡面

共同責任模型的核心就是一句話：AWS 負責雲端本身的安全（security of the cloud），客戶負責雲端裡面的安全（security in the cloud）。介係詞差一個字，範圍差很多。

AWS 蓋機房、買機器、鋪網路、維護底層軟體，並且讓這一切通過各種安全認證，這是「雲端本身」；你放上去的資料、你開的帳號、你設的網路規則、你裝的應用程式，這些是「雲端裡面」。

常見的比喻是租房子：房東負責建築結構、水電管線與大樓門禁，這是他該給你的安全；但你房間的門有沒有鎖、貴重物品放哪裡、鑰匙借給誰，房東管不著，也不該由房東管。雲端安全出事的新聞，多數是「住戶忘了鎖門」，而不是「大樓被拆了」。

AWS 管什麼、你管什麼

把兩邊的清單攤開來看會更具體。AWS 負責的：資料中心的實體安全（門禁、警衛、監控）、伺服器與儲存設備等硬體、全球網路骨幹，以及虛擬化層與託管服務的底層軟體維護。這些你既碰不到，也不需要碰。

你負責的：放上去的資料本身與它的加密（傳輸中與存放時）、帳號與存取權限的管理、客體作業系統的更新與修補（在你自管伺服器的情況下）、網路與防火牆的設定，以及你自己開發的應用程式安全。

其中有一條鐵律值得畫線：不管用哪種服務，資料與存取權限永遠是客戶的責任。AWS 不會、也不該替你決定誰能看你的資料。

那條線會隨服務型態移動

共同責任模型不是一條固定的線，它會隨你選的服務型態上下移動。

自己開一台虛擬機（EC2），作業系統的更新、防毒、防火牆規則都是你的事；改用託管資料庫（RDS），作業系統與資料庫軟體的修補就移交給 AWS，你剩下帳號、資料與連線設定；再走到 S3 或 Lambda 這類抽象度更高的服務，底層基礎設施幾乎全由 AWS 接手，你的責任收斂到資料本身與權限設定。

一句話總結：服務越託管，你的責任越少，但永遠不會歸零。權限設錯、資料設成公開，再託管的服務也救不了你。這就是為什麼接下來要講 IAM。

IAM：管「誰、能對什麼、做什麼」

IAM（Identity and Access Management）是 AWS 管理身分與權限的核心服務，回答的問題永遠是同一句：誰、能對哪個資源、做什麼動作。它有幾個基本零件：

• root 使用者：開帳號時產生的最高權限身分。最佳實務是設一組強密碼、開啟 MFA，然後收起來不用，日常工作絕不用 root。
• IAM 使用者（user）：給一個人或一個應用程式的身分，各自有自己的憑證。
• 群組（group）：把使用者裝進群組，權限掛在群組上統一管理，人來人走只要進出群組，不必逐人改權限。
• 角色（role）：可以被暫時「戴上」的身分，沒有固定密碼，常用於服務對服務的授權，例如讓一台 EC2 有權讀某個 S3 儲存桶，不必把金鑰寫進程式碼。
• 政策（policy）：定義權限的文件，寫明允許或拒絕哪些動作。權限預設全部拒絕，有明確允許才放行。

貫穿這一切的原則是最小權限（least privilege）：每個身分只拿完成工作所需的最小權限。只需要讀報表的人不該能刪資料；只需要寫入一個儲存桶的程式，不該拿到整個帳號的管理權。權限給小了頂多再開，給大了出事就是全面的。