什麼是 AWS 責任共擔模型？
AWS 責任共擔模型是一套合約與營運框架，用來劃分 Amazon Web Services（雲端供應商）與你（客戶）之間的資安與合規義務。AWS 負責雲端本身的安全，客戶則負責雲端內的安全。這一句話是整個 CLF-C02 安全領域中最常被考的觀念，而能精準指出每一項 AWS 服務的責任分界線，正是 Task Statement 2.1 的骨幹。
從宏觀角度來看，AWS 責任共擔模型告訴你：AWS 保護承載所有 AWS 服務的全球基礎設施——資料中心、硬體、Hypervisor、網路線材、實體門禁識別卡。客戶則負責保護所有放在這些基礎設施之上的東西——資料、身分、應用程式程式碼、防火牆規則、加密金鑰。這條責任線在真實世界中其實從來不模糊，但考試題目特別愛考那些灰色地帶，尤其是服務模式從 IaaS 轉 PaaS、再轉 SaaS 的時候。
AWS 責任共擔模型之所以在 CLF-C02 中如此重要，是因為「安全與合規」這個領域的權重佔 30%，是所有領域中最高的。社群的考後心得調查一再指出，「責任共擔模型」是考試後最常被提及的安全觀念，在滾動式十二個月視窗中經常累積超過 400 次以上的提及。如果你在走進考場前只能背一件事，就背這一句：「AWS 負責雲端本身，客戶負責雲端內部」，再加上 EC2、RDS 與 Lambda 的標準範例。
理解 AWS 責任共擔模型不只是為了通過認證。它影響你設計雲端架構的方式、如何回應稽核發現、如何撰寫維運手冊，甚至如何談判雲端合約。每一份認真的 AWS 威脅模型都會從一個問題開始：「這是我的責任、AWS 的責任，還是共擔？」— 而這一章正是要訓練你隨時能精準回答這個問題。
白話文解釋 AWS 責任共擔模型
在鑽進技術細節之前，我們用三個貼近日常生活的類比，把 AWS 責任共擔模型牢牢釘進腦袋。每個類比都抓到責任共擔模式的其中一個面向，三個合在一起，就能避免許多考生「死背一條線」的錯誤。
類比一——社區大樓（房東與房客模式）
把 AWS 想像成一棟超大型保全社區大樓的房東。房東負責維護建築結構、門禁森嚴的大廳、停車場的監視器、電梯、灑水系統、電網，以及大門口的保全。這就是雲端本身的安全。你這位房客拿到自家單位的鑰匙。進到屋內後，要複製幾把鑰匙（IAM）、保險箱裡放什麼（客戶資料）、哪扇窗戶要鎖（Security Groups）、要不要裝防盜警報（CloudWatch）、牆上掛什麼（應用程式程式碼），通通由你決定。如果有人走進你家、把筆電偷走，只因為你忘了鎖門，房東不用負責——這就是雲端內的安全，在責任共擔模型裡是你的地盤。房東與房客的切分讓責任邊界非常直覺：基礎設施在下，客戶選擇在上。
類比二——共用廚房租給師傅（夜市中央廚房模式）
再把 AWS 責任共擔模型想成一間把工作檯出租給各路師傅的中央廚房（想像夜市後場那種共用廚房）。AWS 擁有廚房本體：爐台、冰箱、抽風系統、衛生許可證、合法營業登記。這就是雲端本身的安全。每位師傅（客戶）自備食材（資料）、自選食譜（應用邏輯）、決定誰能進自己的工作檯（IAM）、親自試味道（組態設定），也扛起自家招牌菜的名聲（業務成果）。爐子壞了，是 AWS 的事。湯放太鹹，是師傅自己的鍋。從 EC2（從頭開始自己煮）到 RDS（AWS 副廚幫你備料）再到 Lambda（AWS 直接端出半成品給你擺盤），就是同一間廚房、但廚房員工接手的工序越來越多——你借用多少幫手，責任共擔模型的邊界就跟著移動多少。
類比三——保險合約（保單分層模式）
最後，把 AWS 責任共擔模型想成一份綑綁式保險合約。AWS 承保實體層——建築、硬體、Hypervisor、網路骨幹。那些風險（資料中心火災、磁碟故障、Hypervisor 零日漏洞）都是 AWS 要理賠的範圍。但你的保費（AWS 帳單）並不承保你放在上面的內容物。如果你把保單號碼弄丟、密碼外洩、把 bucket 設成公開、或是 root 帳號沒啟用 MFA，責任共擔模型就會把損失算在你頭上。AWS 透過 AWS Artifact 提供官方合規報告來證明他們這一側的承保責任；你則負責提供自己這一側的稽核證據。保險的框架正好解釋了為什麼它叫「共擔」— 任何一方單獨都無法交付完整的安全。
這三個類比——社區大樓、共用廚房、保險合約——各自從不同的心智角度切入 AWS 責任共擔模型。向團隊成員解釋時交叉使用，遇到情境題就不容易被問倒。
核心運作原則——雲端本身的安全 vs 雲端內的安全
AWS 責任共擔模型的標準敘述把世界切成兩句必須一字不差背下的口訣：「Security of the cloud（雲端本身的安全）」與「Security in the cloud（雲端內的安全）」。介系詞就是關鍵。
Security OF the Cloud（雲端本身的安全——AWS 負責）
AWS 負責保護承載所有 AWS 服務的基礎設施，範圍包含：
- 實體資料中心——門禁識別卡、攝影機監控、24/7 警衛、多層周界管制。
- 硬體——伺服器、儲存裝置、網路設備，以及它們的報廢處置。
- 全球網路基礎設施——AWS 私有骨幹網路、Region、Availability Zone、Edge Location。
- 虛擬化層（Hypervisor）——Nitro System、主機韌體、Hypervisor 修補。
- 基礎代管服務軟體——RDS 引擎程式碼、Lambda 執行環境、S3 儲存子系統。
Security OF the cloud refers to AWS's responsibility to operate, manage, and control the components from the host operating system and virtualization layer down to the physical security of the facilities in which AWS services run. AWS provides third-party audit reports through AWS Artifact to prove compliance with this scope. Source: https://aws.amazon.com/compliance/shared-responsibility-model/
Security IN the Cloud（雲端內的安全——客戶負責）
客戶要為所有放在 AWS 基礎設施之上的東西負責，包含：
- 客戶資料——你決定要儲存什麼、放哪裡、要不要加密、保留多久。
- 平台、應用程式、身分與存取管理（IAM）——使用者、群組、角色、政策、MFA、root 帳號保護。
- 作業系統修補（在 EC2 這類 IaaS 服務上）— AWS 不會幫你修補 Guest OS。
- 網路與防火牆組態——Security Groups、Network ACLs、VPC 路由、子網路設計。
- 用戶端資料加密與完整性檢查——自行決定要不要對靜態與傳輸中資料加密。
- 伺服器端加密決策——啟用或停用、選用 KMS 代管金鑰或客戶代管金鑰。
AWS 責任共擔模型的本質其實就是抽象化。每當 AWS 多加一層抽象（Hypervisor、代管資料庫、Serverless 執行環境），責任線就往上移——AWS 吸收得更多，客戶負責的堆疊範圍就越少。這是考試最關鍵的一條原則。
AWS 的責任——AWS 永遠扛的部分
不管你用的是哪一項 AWS 服務，AWS 永遠要負責一組基準責任。在責任共擔題目中，只要看到「資料中心的實體安全」或「網路基礎設施的安全」這類字眼，答案永遠是 AWS。
實體資料中心
AWS 在設施入口採用多因素驗證、員工進入資料廳需要生物辨識、全天候 24/7 監控，並維持實體保全。訪客全程有人陪同。承載資料的硬碟在報廢前會依 NIST 800-88 流程實體銷毀或進行密碼學清除。這項責任永遠不會轉移給客戶——它是 AWS 責任共擔模型中純粹屬於「雲端本身的安全」的部分。
硬體與全球基礎設施
伺服器、路由器、儲存陣列、線材、冷卻系統與電力配送全數由 AWS 擁有並維護。當 EBS 磁碟背後的儲存硬碟故障時，AWS 會在你完全無感的情況下替換——你不用開工單，也看不到硬體。Region、Availability Zone 與 Edge Location 的可用性、電力與冷卻永遠都是 AWS 的領域。
Hypervisor 與主機作業系統
這裡有一個關鍵陷阱。AWS 會修補 Hypervisor（介於裸機與你的 EC2 執行個體之間的那一層）。AWS 不會修補你 EC2 執行個體內的 Guest OS。這條邊界是 CLF-C02 三大最常被考的灰色地帶之一。當你啟動一個 EC2 執行個體的那一刻起，虛擬機內部運行的作業系統就是客戶要負責修補、強化與監控的。
AWS patches the hypervisor. The customer patches the guest operating system on EC2. This is a fixed line in the AWS Shared Responsibility Model that does not move for traditional EC2 workloads. If an exam question asks "who patches the OS on an EC2 instance?"——the answer is the customer, every time. Source: https://docs.aws.amazon.com/whitepapers/latest/aws-overview/security-and-compliance.html
客戶的責任——你永遠要扛的部分
不論是哪一種服務，在 AWS 責任共擔模型中，有一小組責任永遠都屬於客戶。
客戶資料
你的資料從頭到尾都是你的。沒有你明確授權（透過 IAM），AWS 無法存取你的 S3 物件內容、DynamoDB 項目或 RDS 資料表。資料分類、保留、刪除都是你的責任。AWS 會在硬碟退役時實體銷毀它們，但只要資料還活在你的帳號裡，它就是你的資料。
身分與存取管理（IAM）
IAM 永遠是客戶責任。AWS 提供 IAM 這項服務，但使用者、群組、角色、政策、MFA、密碼輪替與 root 帳號保護都由你設定。假設有人從公司離職、而你忘了撤銷他的 access key，那是責任共擔模型下百分之百的客戶端疏失。
應用程式程式碼與組態
任何你在 AWS 上跑的程式碼——不論是 EC2、Lambda、ECS 還是 EKS——都是你的。輸入驗證、機密處理、應用程式函式庫的相依套件修補、SAST/DAST 掃描，全都坐落在 AWS 責任共擔模型的客戶那一側。
資料加密選擇
AWS 到處都提供加密能力，但要不要開、用哪把金鑰（AWS 代管 vs 客戶代管）、何時輪替都是你的決定。S3 伺服器端加密、EBS Volume 加密、RDS 靜態加密、KMS 金鑰政策——在 AWS 責任共擔模型下全都是客戶的選擇。
Three items the customer always owns in the AWS Shared Responsibility Model, regardless of service type: (1) customer data, (2) IAM configuration, (3) application-level firewall and encryption choices such as Security Groups and S3 bucket policies. These never shift to AWS, even for SaaS-style services. Source: https://aws.amazon.com/compliance/shared-responsibility-model/
責任邊界隨服務類型移動——IaaS vs PaaS vs SaaS
AWS 責任共擔模型不是一條固定的線，而是一條滑動式的刻度。服務越代管，AWS 就扛越多，客戶就管越少。CLF-C02 特別愛透過情境題考這種位移，尤其是把服務從 EC2 換成 RDS、再換成 Lambda，問你責任有什麼變化。
IaaS 範例——Amazon EC2
EC2 是經典的 Infrastructure-as-a-Service。在 EC2 的 AWS 責任共擔模型下：
- AWS——實體資料中心、硬體、Hypervisor、AWS 代管的網路骨幹。
- 客戶——Guest OS（修補、強化）、安裝的軟體、Runtime、資料、IAM、Security Groups、Network ACLs、主機防火牆、加密選擇、監控代理程式。
EC2 把最多責任推給客戶。從 OS 往上你全都得負責。這也是為什麼「EC2 的 OS 修補」這類題目的正確答案幾乎一律是客戶。
PaaS 範例——Amazon RDS
Amazon RDS 是 Platform-as-a-Service。RDS 的 AWS 責任共擔模型會把 OS、資料庫引擎安裝與 DB 修補這些事搬給 AWS。
- AWS——IaaS 的所有項目，再加上資料庫主機的 Guest OS、資料庫引擎軟體、自動備份、DB 引擎的修補時段、Multi-AZ 容錯切換。
- 客戶——引擎內的資料庫使用者帳號與權限、Schema 設計、查詢效能、資料、呼叫 RDS API 所需的 IAM、是否啟用靜態加密、RDS 端點周邊的 Security Groups、備份保留期間設定。
SaaS 範例——Amazon DynamoDB 與 AWS Lambda
對於高度代管（有時被稱為 SaaS 類或 Serverless）的服務——例如 DynamoDB、Lambda、S3——AWS 責任共擔模型的天秤更明顯倒向 AWS。
- AWS——所有基礎設施、OS、Runtime、自動擴展、服務本身的修補、可用性以及執行環境。
- 客戶——應用程式程式碼（Lambda）、資料表設計與存取模式（DynamoDB）、資料、IAM 與加密組態。
以 Lambda 來說，AWS 擁有並修補你所選定的 Runtime 版本（例如 Python 3.12）。但一旦 AWS 宣告該 Runtime 即將淘汰，把程式碼遷移到新版本就是你的責任。責任共擔模型可不允許你忽略淘汰公告。
並列比較——EC2 vs RDS vs Lambda 的責任分布
以下是 AWS 責任共擔模型橫跨三種服務典型的考前必備對照表。請記住整體規律，而不是硬背每一格。
| 責任項目 | EC2（IaaS） | RDS（PaaS） | Lambda（SaaS 類） |
|---|---|---|---|
| 實體設施 | AWS | AWS | AWS |
| 硬體 | AWS | AWS | AWS |
| Hypervisor／虛擬化 | AWS | AWS | AWS |
| 主機 OS 修補 | AWS | AWS | AWS |
| Guest OS 修補 | 客戶 | AWS | AWS |
| 資料庫引擎修補 | 客戶（自行安裝時） | AWS | 不適用 |
| 應用程式 Runtime 修補 | 客戶 | 客戶（應用端） | AWS（代管 Runtime） |
| 應用程式程式碼 | 客戶 | 客戶 | 客戶 |
| 資料 | 客戶 | 客戶 | 客戶 |
| IAM | 客戶 | 客戶 | 客戶 |
| 網路控制（SG／NACL） | 客戶 | 客戶 | 客戶（掛進 VPC 的 Lambda） |
| 靜態加密 | 客戶（自選／啟用） | 客戶（自選／啟用） | 客戶（自選／啟用） |
| 傳輸中加密 | 共擔（TLS） | 共擔（TLS） | 共擔（TLS） |
| 備份排程 | 客戶 | AWS（自動）／客戶（設定） | 不適用 |
| 可用性（Multi-AZ） | 客戶自行設計 | 客戶啟用、AWS 執行 | AWS |
注意這個規律：當你從 EC2 移到 RDS 再到 Lambda，一列一列地從客戶翻成 AWS。這就是 AWS 責任共擔模型的實際運作。考試很少真的要你背出每一列——它考的是你有沒有抓到這個規律。
When facing a scenario question about the AWS Shared Responsibility Model, first identify the service model. IaaS like EC2 means the customer owns everything from the OS up. Managed like RDS means AWS takes the OS and engine. Serverless like Lambda means AWS takes the runtime. After fixing the service, list what is below the abstraction (AWS) and what sits above it (customer). This heuristic answers 90 percent of gray-zone questions. Source: https://aws.amazon.com/compliance/shared-responsibility-model/
共擔責任——中間地帶
AWS 責任共擔模型中，有些項目真的是共擔。雙方都有角色，能掌握這點就是 CLF-C02 的得分關鍵。
修補管理（共擔概念）
AWS 修補自己擁有的基礎設施（Hypervisor、代管服務引擎）。客戶修補自己安裝在上面的東西（EC2 上的 Guest OS、應用程式相依套件）。AWS 責任共擔模型把這件事稱為「Patch Management——共擔」，因為這個概念兩邊都適用，只是各自擁有特定的層級。
組態管理（共擔概念）
AWS 依照安全最佳實務設定底層基礎設施（例如 Hypervisor 預設拒絕的隔離機制）。客戶則設定自己的資源（bucket policies、SG 規則、IAM 政策）。兩邊都有組態，兩邊都要正確，端對端安全才成立。
安全意識與教育訓練（共擔概念）
AWS 對員工進行資安訓練，也公開最佳實務文件。客戶則訓練自家工程師與使用者。如果你公司的開發者把 access key 外洩到 GitHub，那是客戶端的訓練失敗。如果 AWS 工程師洩漏內部資料，那是 AWS 的訓練失敗。
傳輸中加密
TLS 是雙方合作的成果。AWS 服務端點提供 TLS；客戶則選擇是否用 bucket policy 強制 HTTPS、是否要求與 RDS 的連線走 TLS、VPN 加密如何設定，或是否啟用 Certificate Manager。兩邊必須合作。
必背關鍵數字與事實
CLF-C02 不會要你背百分比，但會考你這些標準用語。以下是記憶的錨點。
- 「Security of the cloud」 ＝ AWS 的責任（基礎設施）。
- 「Security in the cloud」 ＝ 客戶的責任（資料、組態、身分）。
- 客戶永遠擁有的三樣東西：資料、IAM、網路／加密組態。
- AWS 永遠擁有的三樣東西：實體設施、硬體、Hypervisor。
- EC2 ＝ 客戶修補 Guest OS。就這樣，沒有例外。
- RDS ＝ AWS 修補 Guest OS 與 DB 引擎。客戶修補 Schema 與應用程式。
- Lambda ＝ AWS 修補 Runtime。客戶修補自己的函式程式碼與相依套件。
- S3 ＝ AWS 修補 API 背後的所有東西。客戶負責 bucket policies、物件 ACL、資料分類。
- IAM 永遠是客戶的。沒有任何一項服務 AWS 會幫你設 IAM。
- 加密金鑰的歸屬取決於選擇：AWS-owned keys（AWS 管理）、KMS 中的 AWS-managed keys（AWS 輪替、客戶可稽核）、KMS 中的 customer-managed keys（客戶掌控輪替與刪除）。
常見考題陷阱——灰色地帶與服務類型位移
AWS 責任共擔模型製造了 CLF-C02 最頑強的一批陷阱題。過去十二個月的社群資料顯示，「責任共擔灰色地帶」是安全與合規領域中單一頻率最高的痛點。
Trap 1——Assuming responsibility boundaries are fixed. Many candidates lock in "AWS does infrastructure, customer does everything else" and never update the mental model when the service changes. Wrong. The AWS Shared Responsibility Model slides: EC2 leaves OS patching to you, RDS takes OS and engine patching from you, Lambda takes runtime patching from you. When a scenario says "managed service," expect AWS to own more. Source: https://docs.aws.amazon.com/whitepapers/latest/aws-overview/security-and-compliance.html
Trap 2——IAM is never AWS's job. Some candidates pick AWS as responsible for IAM configuration because "AWS provides the IAM service." Wrong. AWS provides the IAM engine; you configure users, roles, MFA, and policies. In the AWS Shared Responsibility Model, IAM is 100 percent customer responsibility, for every service, every time. Source: https://aws.amazon.com/compliance/shared-responsibility-model/
Trap 3——Encryption-key ownership confusion. If a question says "encryption at rest for S3," the answer is nuanced. AWS provides the encryption capability; the customer chooses whether to enable SSE-S3, SSE-KMS, or SSE-C, and the customer owns key rotation policy for customer-managed keys. The data encryption itself is shared; the decision to encrypt and the key lifecycle are customer. Source: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html
陷阱 4——S3 物件權限
S3 提供 bucket，但物件層級的 ACL、bucket policies、Block Public Access 設定全都是客戶自己的。當 bucket 意外被公開，AWS 責任共擔模型會把 100% 的責任放在客戶頭上。AWS 甚至把 Block Public Access 設成預設值來幫忙，但要不要啟用，仍然是客戶的選擇。
陷阱 5——EC2 OS 修補
考官最愛這題。題目問：「誰要負責修補 EC2 執行個體上的作業系統？」答案永遠是客戶，絕不是 AWS。AWS 只修補 Hypervisor。如果你想自動化，可以用 Systems Manager Patch Manager，但在 AWS 責任共擔模型下，責任仍然屬於客戶。
陷阱 6——共擔 vs 客戶 vs AWS 的措辭
有些題目會問某件事是「只有 AWS」、「只有客戶」還是「共擔」。若問的是「修補管理」這個概念，答案是「共擔」。若問的是「修補 Hypervisor」，答案是 AWS。若問的是「修補 EC2 的 Guest OS」，答案是客戶。看題目時要仔細分辨，它問的是概念還是具體的那一層。
責任共擔模型 vs AWS Well-Architected 安全支柱
兩者都在 AWS 的資安宇宙裡，也都會出現在 CLF-C02，但它們回答的是不同問題。AWS 責任共擔模型告訴你誰負責每一層資安。Well-Architected 的安全支柱則告訴你在自己那一側要怎麼做得好。
AWS 責任共擔模型
- 目的——一份邊界合約。
- 產出——分工定義（「AWS 做 X，我做 Y」）。
- 用途——稽核範圍界定、合規證據收集、事故歸責分析。
Well-Architected 安全支柱
- 目的——客戶那一側的最佳實務框架。
- 產出——設計原則（建立強健的身分基礎、啟用可追蹤性、每一層都加上安全控制、自動化、保護傳輸中與靜態資料、讓人離資料遠一點、為事件預做準備）。
- 用途——架構審查、資安姿態改善、設計指引。
考題可能把兩者並列出現。如果情境問的是「哪一個框架定義了誰負責修補 Hypervisor？」— 答案是 AWS 責任共擔模型。如果情境問的是「哪一條原則建議要把資安最佳實務自動化？」— 答案是安全支柱。兩者互補但不可互換。
實務應用——真實世界的決策流程
把 AWS 責任共擔模型落地實行，大概長這樣。
步驟 1——辨認服務類型
這個工作負載跑在 EC2（IaaS）、RDS／ECS-on-EC2（偏 PaaS），還是 Lambda／DynamoDB／S3（代管／Serverless）？這會先固定基本的責任分割。
步驟 2——套上「永遠屬於客戶」的項目
資料、IAM、網路控制永遠是你的。確認相關政策已經存在。
步驟 3——辨認共擔項目
傳輸中加密、以及修補管理這個概念。定義每一層由誰做什麼。
步驟 4——透過 AWS Artifact 驗證 AWS 那一側
AWS Artifact 提供 SOC 2 報告、ISO 27001 證書、PCI-DSS 合規聲明、HIPAA BAA 等文件。這些文件就是 AWS 證明自己達成 AWS 責任共擔模型那一側的方式。稽核員一定會要。
步驟 5——建立客戶端證據
你要提供 Log（CloudTrail 記錄 API 稽核、CloudWatch Logs 記錄應用程式）、組態快照（AWS Config）、以及 IAM 存取檢閱。這就是責任共擔模型下你這一側的證據。
責任共擔在合規框架中的樣貌
HIPAA、PCI-DSS、GDPR、SOC 2、ISO 27001、FedRAMP——AWS 支援的每一項合規法規都是以 AWS 責任共擔模型為界切分範圍。AWS 幫你拿到基礎設施層級的合規（Security OF the Cloud），你繼承這份合規並在上面疊加自己的控制（Security IN the Cloud）。
以 HIPAA 來說，AWS 會針對 HIPAA-eligible 服務簽署 BAA（Business Associate Agreement）。只要進到你帳號內、會處理 PHI 的東西，通通由你管。以 PCI-DSS 來說，AWS 具備 Level 1 Service Provider 的認證；但你的持卡人資料環境仍然要在那份範圍內自己完成設定。AWS 責任共擔模型畫出了「AWS 已認證」與「你必須自己認證」的分界。
常見問答——AWS 責任共擔模型
Q1：AWS 責任共擔模型最好的一句話摘要是什麼？
A：AWS 負責雲端本身的安全（基礎設施），客戶負責雲端內的安全（資料、身分、組態與應用程式）。這一模一樣的措辭就是 AWS 在每份官方文件中描述責任共擔模型的方式，也是 CLF-C02 期待你一眼認出的說法。
Q2：AWS 會幫我修補 EC2 的作業系統嗎？
A：不會。AWS 修補 Hypervisor 與主機基礎設施，但在 AWS 責任共擔模型下，EC2 執行個體上的 Guest OS 永遠是客戶的責任。你可以用 AWS Systems Manager Patch Manager 自動化 OS 修補——自動化可以跑在 AWS 上，但責任仍然是你的。
Q3：RDS 或 Lambda 這類代管服務下，AWS 責任共擔模型會怎麼變？
A：邊界往上移。RDS 裡，AWS 接手 Guest OS 與資料庫引擎的修補，客戶只負責資料、Schema、資料庫使用者與 IAM。Lambda 裡，AWS 管理 Runtime 與執行環境，客戶只負責函式程式碼與組態。服務越代管，客戶管的越少——但客戶永遠無法放棄資料、IAM 與加密選擇這三項責任。
Q4：AWS 責任共擔模型裡，IAM 組態是誰的責任？
A：永遠是客戶，對每一項服務都一樣。AWS 提供 IAM 這項服務本身（這是 AWS 的基礎設施責任），但組態——使用者、角色、群組、政策、MFA、root 帳號保護——永遠是客戶責任。access key 外洩或政策過度寬鬆，都是客戶端的疏失。
Q5：我要去哪裡找 AWS 證明自己達成責任共擔模型那一側的文件？
A：AWS Artifact 是 AWS 合規報告與協議的官方自助服務入口。裡面有 SOC 報告、ISO 認證、PCI-DSS 合規聲明、HIPAA BAA 等許多文件。客戶用這些證明給稽核員看，AWS 已經完成了 AWS 責任共擔模型中「雲端本身的安全」那一塊。
Q6：如果我的 S3 bucket 不小心被公開，是 AWS 的錯還是我的錯？
A：你的錯。在 AWS 責任共擔模型下，bucket policies 與 Block Public Access 設定是客戶擁有的組態。AWS 有提供安全預設值（自 2023 年 4 月起，新建 bucket 預設啟用 Block Public Access），但最終的組態選擇——以及稽核軌跡——都落在客戶身上。不是 AWS 洩漏你的資料，是你的設定洩漏的。
Q7：傳輸中加密是 AWS 的責任還是客戶的責任？
A：共擔。AWS 在服務端點提供 TLS，內部服務之間的流量也會加密。客戶則決定是否強制 HTTPS-only 存取、連 RDS 時是否要求 TLS、VPN 隧道是否加密，以及是否用 AWS Certificate Manager 管理自訂憑證。要在 AWS 責任共擔模型下做到真正端對端的傳輸中加密，雙方都要盡到自己的份。
延伸閱讀與官方資料
- AWS Shared Responsibility Model——https://aws.amazon.com/compliance/shared-responsibility-model/——權威入口頁。
- AWS Overview Whitepaper——Security and Compliance——https://docs.aws.amazon.com/whitepapers/latest/aws-overview/security-and-compliance.html——附帶範例的深入解析。
- AWS Certified Cloud Practitioner Exam Guide (CLF-C02)——https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf——Task Statement 2.1 細節。
- AWS Artifact——https://aws.amazon.com/artifact/——合規文件中樞。
- AWS Well-Architected Security Pillar——https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html——指引你把自己那一側做好的姊妹框架。
一頁總結——AWS 責任共擔模型
AWS 責任共擔模型回答了每一場 AWS 對話都會問的問題：「到底誰負責保護什麼？」AWS 負責雲端本身：資料中心、硬體、Hypervisor、代管服務引擎。客戶負責雲端內部：資料、IAM、應用程式組態、網路規則、加密選擇。責任線會隨服務類型移動——IaaS 的 EC2 把最多責任推給客戶，RDS 這類代管服務把 OS 與引擎搬回 AWS，Lambda 這類 Serverless 與 DynamoDB 這類代管服務搬得更多。有三樣永遠屬於客戶：資料、IAM、加密組態。有三樣永遠屬於 AWS：實體設施、硬體、Hypervisor。把這些錨點背熟、把位移規則弄懂，CLF-C02 的 AWS 責任共擔模型這一章就是保證入袋的分數。