雲端共同責任模型是什麼？IaaS、PaaS、SaaS 誰負責什麼
共同責任模型（Shared Responsibility Model）是雲端服務商與客戶劃分資安責任的方式：服務商負責雲端本身的安全，客戶負責自己放在雲端上的資料、帳號與設定。服務模式不同，分工也不同，但資料與帳號不論哪種模式都是客戶的責任。
最常見的誤解是「上雲就等於把資安交給 AWS 或 Microsoft」，但帳號沒開多因子驗證、儲存空間設成公開，都是客戶自己要負責的事。下面整理責任對照表、最常被忽略的 5 件事與合約要確認的項目。如果您是 SaaS 業者或正要回覆客戶問卷，可以參考我們的 ISO 27017 驗證輔導。
重點整理 – AWS 的說法是「服務商負責雲端的安全，客戶負責雲端裡的安全」；客戶的責任取決於選用哪項服務。 – 依 Microsoft 的責任矩陣，資料、設定與帳號在 IaaS、PaaS、SaaS 下都由客戶負責。 – 2024 年 Snowflake 事件約 165 個組織受影響，Mandiant 認定主因是客戶憑證遭竊且未啟用多因子驗證，並未發現 Snowflake 本身遭入侵。 – SLA 談的是可用性，不等於替您的資料安全負責。
雲端責任共擔模型是什麼？
雲端責任共擔模型又稱共同責任模型，用來說明哪些資安工作由服務商負責，哪些必須由客戶完成。沒有畫清楚這條線，就會出現雙方都以為對方在做的空窗。
AWS 以「security of the cloud」和「security in the cloud」區分：AWS 負責運算、儲存、網路與實體機房等基礎設施，客戶負責放在上面的東西。同一份說明也舉例：使用 Amazon EC2 時，客戶要管理作業系統、應用程式與安全群組防火牆；使用 S3 這類託管服務時，AWS 管到作業系統與平台，客戶仍要管資料、加密選項與 IAM 權限。
AWS 共同責任模型也列出雙方都有份的項目：修補、組態管理與教育訓練。AWS 修補基礎設施，客戶修補自己的作業系統與應用程式；AWS 訓練自己的員工，客戶要訓練自己的員工。
IaaS、PaaS、SaaS 責任對照表
越接近 SaaS，服務商管得越多，但資料、設定與帳號始終留在客戶這一側。下表依 Microsoft Azure 文件的責任矩陣整理；AWS、Google 的細節略有不同，且以合約為準。
| 責任項目 | 自建機房 | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| 資料 | 客戶 | 客戶 | 客戶 | 客戶 |
| 設定與組態 | 客戶 | 客戶 | 客戶 | 客戶 |
| 帳號與使用者 | 客戶 | 客戶 | 客戶 | 客戶 |
| 用戶端裝置 | 客戶 | 客戶 | 客戶 | 共同 |
| 應用程式 | 客戶 | 客戶 | 共同 | 共同 |
| 網路控制 | 客戶 | 客戶 | 共同 | 服務商 |
| 作業系統 | 客戶 | 客戶 | 服務商 | 服務商 |
| 實體主機、網路與機房 | 客戶 | 服務商 | 服務商 | 服務商 |
對照常見服務來看，虛擬機是 IaaS，Azure SQL Database 與 App Service 是 PaaS，Microsoft 365 是 SaaS。同一家公司常常三種都用，所以要逐項服務確認，不能用一句「我們在雲端」帶過。
Microsoft 也有 AI 與 AI 代理的共同責任說明，導入生成式 AI 時同樣要重新確認這條線。
企業最常忽略的 5 個責任
實務上最常出問題的不是機房，而是客戶自己這一側的日常管理。這 5 項都不需要等服務商，可以直接列入自查：
- 帳號與多因子驗證：管理者、API 與服務帳號都要檢查，包括離職人員與長期未更換的金鑰。
- 公開存取設定：儲存空間、資料庫與分享連結有沒有開放給所有人。
- 備份與還原：確認哪些資料有備份、保留多久，並實際測試還原。
- 日誌與告警：確認日誌有開啟、保留夠久，而且有人看。
- 修補與組態：IaaS 上的作業系統與軟體，仍由客戶負責修補。
Snowflake 事件是第一項的典型案例。Mandiant 2024 年 6 月的報告指出，攻擊者使用資訊竊取惡意程式偷來的憑證，登入客戶帳戶，約 165 個組織收到通知；這些帳戶沒有啟用多因子驗證，有些憑證多年未更換，也沒有設定連線來源限制。報告也說明，未發現 Snowflake 企業環境遭入侵的證據。
服務商有資安驗證，也不能代替這些工作。就算服務商取得 ISO 27017 或其他驗證，也只代表服務商那一側的管理，客戶的組態、帳號與資料仍要自己負責。
合約與 SLA 要確認什麼？
SLA 主要約定服務可用性與未達標時的補償，通常不涵蓋資料遭竊的損失。以 AWS 運算服務的 SLA 為例，除合約另有約定外，服務抵用金就是服務未達可用性承諾時的唯一補救。選服務前要把資安責任另外確認清楚。
建議在簽約或續約時，逐項確認下列內容：
| 項目 | 要問什麼 |
|---|---|
| 責任分工 | 服務商是否提供責任矩陣？哪些控制由誰負責？ |
| 事故通知 | 服務商多久內通知客戶？通知內容與管道？ |
| 資料位置 | 資料存放在哪裡？是否有分包商或跨境傳輸？ |
| 備份與還原 | 服務內建的保留範圍？客戶要自備什麼？ |
| 稽核佐證 | 能否提供 SOC 2、ISO 27001、ISO 27017 等報告或證書？ |
| 資料返還與刪除 | 終止契約後多久刪除？如何取回？ |
這份清單也對應到台灣個資法的委外監督：依個資法施行細則第 8 條，委託他人處理個資時，要對受託者適當監督並留下紀錄。選標準時的比較可以參考 雲端資安標準 的整理。
共同責任模型與 ISO 27017 的關係
ISO/IEC 27017 把共同責任模型變成可稽核的控制措施。2026 年版的 5.38 條談雲端環境中的共同角色與責任，要求服務商與客戶把各自的責任界定清楚。
它適用於雲端服務提供者，也適用於雲端服務客戶。實務上導入時的核心文件，就是一份共同責任矩陣：逐項列出每個控制由誰負責，並留下佐證。已有 ISO 27001 的企業，可以把這份矩陣納入資訊安全管理系統，也能拿來回覆客戶問卷。
如果您只是一般雲端使用者，不一定需要取得 ISO 27017 驗證，做好上面的自查與合約確認就有很大幫助；SaaS 業者或客戶明確要求時，再考慮進一步驗證。
公司的雲端責任矩陣怎麼開始？
挑出最重要的 3 項雲端服務，用上面的對照表各寫一頁：哪些事由服務商負責、哪些由我們負責、由誰執行、多久檢查一次。凡是答不出負責人的項目，就是現在的破口。
如果需要協助把責任矩陣納入管理制度，或要回應客戶的稽核要求，可以了解我們的 雲端安全驗證 服務，或 直接與顧問聊聊貴公司的狀況。
共同責任模型常見問題
用了雲端就不用管資安嗎？
不是。雲端服務商負責基礎設施，但資料、帳號、存取權限與設定都由客戶負責。使用 IaaS 時，作業系統與應用程式的修補也是客戶的工作。上雲可以減少機房與硬體維護的負擔，但不會把資安責任全部轉移出去。
資料外洩是誰的責任？
要看破口在哪一側，以及合約怎麼約定。帳號遭盜用或設定錯誤多屬客戶責任，基礎設施被入侵則屬服務商。不論原因為何，對當事人而言企業通常仍是蒐集資料的一方，依個資法或 GDPR 的通知與監督義務仍要處理，不能只說是雲端業者的問題。
M365 的資料要自己備份嗎？
建議依 RPO 與留存需求評估。Microsoft 365 本身有備援副本，但主要用於服務韌性；面對勒索軟體或誤刪，Microsoft 還提供按用量計費的 Microsoft 365 Backup，也有第三方方案。Microsoft 消費者服務條款也建議使用者定期備份內容。
參考資料
- Shared Responsibility Model – security of／in the cloud、EC2 與託管服務的差異。AWS
- Shared responsibility in the cloud – IaaS、PaaS、SaaS 責任矩陣。Microsoft Learn · 2026 年 8 月
- UNC5537 Targets Snowflake Customer Instances – Snowflake 事件調查。Google Cloud／Mandiant · 2024 年 6 月
- Amazon Compute Service Level Agreement – SLA 與服務抵用金。AWS
- Overview of Microsoft 365 Backup – 備份與還原功能、計費方式。Microsoft Learn · 2026 年 11 月
- 個人資料保護法施行細則 – 第 8 條委託監督。全國法規資料庫
