服務模型決定責任分工
以 AWS 的模型為例，供應商負責支撐雲端的基礎設施；客戶責任隨服務而變。使用 EC2 時，客戶通常負責客體作業系統與應用更新；使用 S3 等抽象化服務時，客戶仍負責資料與存取權限等設定。
因此「已上雲」不是安全驗收。應建立服務清單、資料分類、身分與權限、日誌及復原責任表，再對照該供應商當前文件。不同產品與合約的細節不能互相套用。
責任要連到設定與驗證
客戶若把私人儲存物件設定為公開，底層機房的安全仍不能保護這個公開設定。權限審查需要考慮主體、動作、資源與條件，也要檢查匿名存取及跨帳號分享。
加密、備份、日誌與復原各有不同驗收。開啟加密不等於權限最小化；備份存在不等於可以還原。把每個責任交給明確角色並記錄驗證結果。
例子：公開網站與私人資料
虛構專案把公開圖片與私人研究原始資料放在同一個儲存空間，為了讓圖片顯示而開啟整個空間的公開讀取。
需求只有圖片公開，卻把存取範圍擴大到私人資料。應分離公開資源或精確限制政策，並驗證匿名使用者不能取得私人物件。
判斷：供應商負責底層基礎設施，不會自動替客戶修正這個資料公開決策。
紙上練習：共同責任表
只分析虛構服務，不登入雲端或修改任何政策。
- 列出機房硬體、虛擬機客體更新、物件公開權限、資料分類四項。
- 以本課 AWS 例子分配供應商或客戶責任。
- 為私人物件加入一個匿名讀取應被拒絕的驗證案例。
預期結果
硬體由供應商處理；客體更新、客戶資料分類與客戶物件權限仍需客戶管理。
自行檢核
改用另一個託管產品時，哪些責任必須重新查文件？
結束與清理
保留責任表，沒有雲端資源或費用變更。