雲端最大的改變，不是責任轉移，而是責任重新分工。

雲端改變的不只是技術，也改變了責任邊界

前面的章節介紹了架構設計的方法、平台能力以及架構品質，也逐步建立了企業如何規劃與管理雲端平台的整體觀念。

然而，在開始討論各種安全控制之前，還有一個非常重要的基礎需要先建立：這些控制，到底應該由誰負責？

許多企業第一次導入雲端時，經常出現兩種截然不同的看法。有些人認為，既然系統已經部署到雲端，安全自然就應該全部交由雲端服務供應商負責；也有人認為，因為系統仍然屬於企業，所以所有事情都應該自行管理。

這兩種理解其實都過於極端。

企業導入雲端之後，責任並沒有消失，也沒有完全移轉，而是重新劃分了企業與雲端服務供應商各自負責的範圍。這也是 Shared Responsibility Model（責任共擔模型） 想要傳達的核心觀念。

理解這個責任邊界，不只是學習雲端安全的重要基礎，也是架構設計時必須建立的第一個觀念。因為只有先知道哪些事情由誰負責，後續才能正確規劃治理方式、安全控制以及管理機制。

Shared Responsibility Model 想表達什麼？

幾乎所有主流的雲端服務供應商，都提出過自己的 Shared Responsibility Model（共同責任模型）。

雖然 Microsoft、AWS、Google Cloud 所使用的圖示略有不同，但背後傳達的概念幾乎完全一致：雲端服務供應商負責維護雲端平台本身，而企業則需要管理自己部署到雲端中的系統、資料以及各項設定。

圖 12-1 Shared Responsibility Model（共同責任模型）

這也是國際雲端安全專業認證 CCSP（Certified Cloud Security Professional） 特別強調的重要觀念之一。在 CCSP 的教材中，Shared Responsibility Model 被視為雲端治理與架構設計的基礎，因為它直接影響企業如何規劃安全控制、分配管理責任，以及建立治理機制。教材中特別區分 雲端服務供應商（Cloud Service Provider，CSP） 與 雲端服務客戶（Cloud Service Customer，CSC） 的責任範圍，強調雙方各自承擔不同的安全義務，而不是由其中一方負責所有事情。

對 CSP 而言，主要負責雲端平台本身的安全與穩定，包括資料中心、實體設備、網路基礎設施、虛擬化平台，以及各項雲端服務的可用性與安全性。企業之所以能夠放心使用雲端服務，正是建立在這些基礎設施已由雲端服務供應商持續維護與保護的前提之上。

而 CSC 則需要對部署在雲端上的資產負責，例如身分與存取管理、資料保護、應用程式安全、組態設定、權限管理，以及各項治理與法規遵循要求。即使採用了 PaaS 或 SaaS 等高階服務，企業仍然必須決定誰可以存取資料、如何設定權限、如何分類資料，以及如何符合內部治理與外部法規要求。這些責任並不會因為採用雲端服務而轉移給雲端服務供應商。

因此，CCSP 一再強調，Shared Responsibility 並不是責任的切割，而是責任的重新分工。 雲端服務供應商負責提供安全可靠的平台，而企業則必須善用這些平台能力，建立符合自身需求的治理、安全控制與管理機制。只有雙方各自履行應盡的責任，才能共同建立一個安全且可信賴的雲端環境。

很多人在剛接觸 Shared Responsibility Model 時，容易把它理解成一張責任分工表，認為只要知道哪些工作由雲端服務供應商負責、哪些工作由企業負責就足夠了。

但從架構設計的角度來看，Shared Responsibility Model 更重要的價值，在於協助企業理解責任邊界。

當企業採用不同的雲端服務時，需要承擔的管理工作也會隨之改變。例如，採用 IaaS 時，企業需要自行管理作業系統與中介軟體；採用 PaaS 之後，這些工作可以交由雲端服務供應商負責，但身分管理、資料保護、權限控管以及治理要求，仍然需要由企業自行規劃與管理。

因此，Shared Responsibility Model 並不是要告訴企業哪些事情可以不用做，而是協助企業更清楚理解：哪些工作可以交由雲端平台負責，哪些控制措施仍然需要由企業自行建立。 只有釐清這些責任邊界，才能避免因為角色認知不清，而在治理、安全或法規遵循上產生缺口。

服務模式改變，責任內容也跟著改變

Shared Responsibility Model 通常會搭配 IaaS、PaaS 與 SaaS 一起說明。第一次看到這張圖時，很多人都會得到一個印象：「服務越高階，企業需要負責的事情就越少。」這樣的理解並不完全正確，更準確地說，改變的並不是責任的多寡，而是責任的內容。

以 IaaS 為例，企業仍然需要管理虛擬機器、作業系統、中介軟體以及應用程式，因此仍需投入相當多的平台管理工作；到了 PaaS，作業系統與平台元件改由雲端服務供應商維護，企業便能將更多心力放在應用程式與資料本身；至於 SaaS，企業雖然不需要管理應用平台，但仍然必須負責帳號、權限、資料以及組織自身的安全政策。

因此，服務模式愈高階，並不代表企業的責任愈少，而是企業可以將更多資源投入真正與業務相關的管理工作，而不需要持續維護大量基礎設施。 責任並沒有消失，而是逐漸從平台維運轉移到資料治理、身分管理、權限控管與業務流程等更貼近企業核心價值的工作。

從架構設計的角度來看，更重要的是理解每採用一種新的服務模式，責任邊界也會跟著改變。只有清楚知道哪些工作由雲端服務供應商負責、哪些工作仍然需要企業自行承擔，後續的架構設計、治理規劃以及安全控制，才能建立在正確的基礎之上。

越接近業務，責任越屬於企業

隨著服務模式從 IaaS、PaaS 發展到 SaaS，雲端服務供應商確實承擔了越來越多的平台管理工作。然而，那些真正與企業核心業務相關的責任，卻始終沒有改變。

例如， 身分（Identity）、資料（Data）、應用程式（Application）、組態設定（Configuration） 以及 存取控制（Access Control），都仍然屬於企業需要自行管理的重要範圍。這些工作不只是技術設定，更直接影響企業的營運方式、資料保護以及風險管理，因此也是最難交由雲端服務供應商代為決定的部分。

原因其實並不複雜。雲端服務供應商知道如何維護平台的安全與穩定，但並不了解企業真正的業務需求。它不知道哪些資料屬於機密資料，不知道哪些人應該擁有管理權限，也不知道哪些系統彼此可以互相存取，更不知道哪些資料可以分享給外部合作夥伴。因此，雲端服務供應商提供的是平台能力，而如何使用這些能力、如何建立治理規範，以及如何保護企業的重要資產，仍然需要由企業自行決定。

換句話說，企業導入雲端之後，真正需要管理的重點，已經不再是機房、伺服器或網路設備，而是那些最貼近企業營運與業務價值的資產。

架構設計需要思考的是責任邊界

從架構設計的角度來看，Shared Responsibility Model 最重要的價值，並不是背下 IaaS、PaaS 或 SaaS 各自負責哪些項目，而是理解每採用一項新的雲端服務，責任邊界都可能跟著改變。

以 PaaS 的資料庫服務為例，企業不需要再維護作業系統，也不需要管理資料庫版本更新，但與資料相關的重要管理工作仍然沒有消失。例如，誰可以存取資料？是否需要使用 Private Access？備份應該保留多久？是否符合企業的資料分類要求？是否符合相關法規要求？這些問題仍然需要企業自行決定。

同樣地，採用 SaaS 時，企業雖然不需要管理基礎設施，也不需要維護應用程式本身，但仍然需要規劃帳號與權限管理、多因素驗證、條件式存取（Conditional Access）、外部資料分享、稽核日誌（Audit Log）保存期限，以及法規遵循等管理要求。

可以發現，這些責任並不會因為採用了雲端服務而消失，而是從平台維護逐漸轉移到資料治理、身分管理以及安全控制等更貼近企業營運的工作。

因此，對架構師而言，更重要的不是思考哪些工作可以交給雲端服務供應商，而是持續確認哪些控制措施仍然需要由企業建立，以及哪些責任始終屬於企業。只有清楚掌握責任邊界，才能在不同的服務模式下，建立一致且完整的治理與安全架構。

小結

Shared Responsibility Model 不只是用來說明責任分工的一張圖，更是企業導入雲端時必須建立的重要觀念。

雲端服務供應商負責提供安全、可靠的平台；企業則需要善用這些平台能力，建立符合自身需求的治理機制、安全控制以及管理流程。隨著採用的服務模式不同，企業需要負責的工作內容會有所改變，但真正與業務相關的責任並不會因此消失。

對架構師而言，理解 Shared Responsibility Model 的目的，也不是記住每一項服務由誰負責，而是建立一種思考方式。每導入一項新的雲端服務，都應該重新檢視責任邊界是否發生改變，確認哪些控制措施仍然需要由企業建立，哪些管理要求需要持續維持，才能讓整體架構在享受雲端帶來便利的同時，也維持應有的治理能力與安全水準。