共同責任模型

什麼是共同責任模型？

共同責任模型是一份概念性的契約，精確定義了在 Google Cloud 上執行工作負載時，哪些安全控制由 Google 負責、哪些由客戶負責。對於 Cloud Digital Leader（CDL）考試而言，共同責任模型是檢視所有其他安全章節的基礎框架——IAM、加密、合規、網路安全，都應透過這個框架來理解。若缺乏此模型，客戶要麼過度信任雲端供應商（誤以為 Google 能神奇地保護所有資料），要麼過度不信任（重新實作 Google 已免費提供的安全控制）。兩種極端都會導致資源浪費、專案延誤，以及真實的安全漏洞。

共同責任模型的存在，是因為雲端並非單一的東西。當客戶在 Compute Engine 上執行虛擬機器時，他們租用的是原始基礎設施：硬體、Hypervisor 以及乾淨的作業系統映像檔。當同一位客戶在 BigQuery 執行查詢時，他們租用的是全受管的分析服務，從磁碟加密到查詢最佳化，一切都由 Google 處理。這兩種情境中，Google 與客戶之間的安全工作分配方式有根本性的差異——但兩者都是「Google Cloud」。共同責任模型提供了一個有結構的方式，讓領導者能夠清楚辨別這兩者的差異。

CDL 考生無需撰寫雲端安全政策，也不需要稽核強化後的映像檔。考試測驗的是候選人能否以業務領導者的視角來理解：「如果我們採用這個 Google Cloud 服務，哪些問題仍是我們公司的責任，哪些問題會轉移給 Google 負責？」答案會因服務屬於基礎設施即服務（IaaS）、平台即服務（PaaS） 或軟體即服務（SaaS） 而有所不同——CDL 考試非常喜歡測驗哪些控制項位於責任界線的哪一側。

模型的兩個部分

最簡單的說，共同責任模型將雲端安全分為兩個部分：雲端的安全性（Security OF the cloud）（Google 的責任）以及雲端中的安全性（Security IN the cloud）（客戶的責任）。

雲端的安全性 — Google 的部分

無論客戶使用哪種服務，Google 都負責 Google Cloud 的實體與基礎層安全。這一部分永遠不會轉移給客戶。包含：

• 資料中心實體安全 — 生物辨識門禁、周界圍欄、現場警衛、雙路供電、溫控系統。
• 硬體 — 自研 Titan 安全晶片、伺服器生命週期管理、安全硬體報廢流程。
• Hypervisor 與主機作業系統 — 負責在共享硬體上隔離不同租戶工作負載的軟體層。
• 全球私有網路 — Google 骨幹網路，包含資料中心之間傳輸時的加密。
• 預設 DDoS 防護 — Google Front End 在攻擊抵達客戶工作負載之前，即可吸收並過濾大流量攻擊。
• 受管服務的作業系統修補 — 客戶永遠不需要看到或修補 BigQuery、Cloud Run 或 Cloud Functions 底層的主機作業系統。

雲端中的安全性 — 客戶的部分

客戶負責他們放入 Google Cloud 的內容，以及他們如何設定。這一部分永遠不會轉移給 Google。包含：

• 資料分類 — 決定哪些資料屬於敏感、受規範或公開。
• 身分識別與存取管理 — 哪些人員擁有哪些資源的哪些角色。請參閱身分識別與存取管理（IAM）了解主體—角色—資源模型。
• 應用程式程式碼安全性 — 消除 SQL 注入漏洞、修復相依套件中的漏洞、驗證輸入值。
• 驗證選擇 — 是否要求兩步驟驗證、是否與外部身分提供者聯合、是否使用硬體安全金鑰。
• 雲端資源的組態設定 — 確保 Cloud Storage 儲存桶不會意外公開、防火牆不允許 0.0.0.0/0 開放 22 埠。

白話文解釋

共同責任模型有時感覺很抽象，因為那條分界線是看不見的——Google Cloud 主控台中沒有任何路標寫著「Google 的責任到此為止」。但透過現實生活的比喻，這個模型就容易多了。以下三個類比分別呈現共同責任的不同面向。

類比 1 — 租公寓、住飯店與訂民宿

想像您要在台北住一個月，有三種住宿選擇。每種選擇對您與房東之間的**「管理這個地方」的工作**分配方式都不同。這正是 IaaS、PaaS 與 SaaS 的差異所在。

選項 A — 租一間空屋（IaaS，如 Compute Engine）。 房東擁有這棟大樓、負責修電梯、繳房屋稅，並在夜間上鎖大門。但您要自己搬入床鋪、餐具和網路分享器。如果您的房間凌晨兩點突然漏水，房東可能負責修繕結構問題，但被水淋濕的筆電是您的損失。在 Compute Engine 上，Google 處理建築物（硬體、Hypervisor、網路），但您負責家具（作業系統修補、應用程式程式碼、防火牆規則、軟體相依套件）。

選項 B — 住一間飯店（PaaS，如 GKE 或 Cloud Run）。 飯店員工每天打掃房間、補充盥洗用品、修好壞掉的電視，並在安全更新後修補 WiFi 路由器。您仍然決定把什麼放進保險箱，以及把房卡交給誰。在 Cloud Run 上，Google 修補底層作業系統和容器執行環境；您決定要部署哪個容器映像檔、服務帳號擁有哪些 IAM 角色，以及哪些端點可以公開存取。

選項 C — 訂一間有早餐的民宿（SaaS，如 BigQuery 或 Cloud Functions）。 早餐有人煮、床有人鋪、浴室有人打掃、送洗衣物有人取走。幾乎所有事情都有人幫您處理。您只需要決定點什麼，以及要和誰共享早餐桌。在 BigQuery 上，Google 處理運算擴展、儲存複寫、磁碟加密、作業系統修補、查詢最佳化與硬體更新。您只需管理載入哪些資料、誰能查詢，以及要執行哪些查詢。

CDL 考試喜歡問「在某個服務上，哪些控制項是 Google 的責任？」——公寓—飯店—民宿的思維模型能讓您快速得出答案。

類比 2 — 搭機、住宿、用餐的出國旅行安全分工

當您出國旅行時，您的人身安全仰賴一連串的服務提供者——每位提供者的責任界線都不同。

在飛機上（IaaS）。 航空公司負責飛機的適航性、飛行員的訓練、航管協調與座艙氣壓。您負責不攜帶違禁物品、繫好安全帶、遵從機組人員指示。航空公司無法阻止您把超過液體限額的瓶裝香水放進隨身行李——那是您的決定。在 Compute Engine 上，Google 確保底層虛擬機器平台健全，但無法阻止您執行含有易受攻擊 PHP 版本的未修補 WordPress。

在旅館（PaaS）。 旅館負責大樓、門鎖、監視攝影機、員工背景調查與客房清潔。您負責正確使用保險箱、不把貴重物品留在桌上，以及不替陌生人撐開大門。在 GKE Autopilot 上，Google 管理控制平面、節點集區、作業系統修補和 Kubernetes 升級；您負責容器映像檔中的漏洞、工作負載身分綁定，以及只公開真正需要對外流量的服務。

在餐廳（SaaS）。 餐廳挑選食材、料理食物、清洗餐盤，並遵守食品安全法規。您負責告知過敏資訊，以及選擇要吃什麼。在 Cloud Functions 上，Google 負責執行環境的擴展、語言版本的修補、每次呼叫的隔離以及服務可用性；您只負責函式程式碼的行為，以及誰可以呼叫它。

服務越靠近 SaaS 端，Google 替您做的事就越多——這也使得您必須將剩餘的有限責任（資料與 IAM）集中管理好，這一點反而更加重要。

類比 3 — 建案工地與總承包商

一個更具企業感的類比：想像您的公司正在台中興建新總部大樓，多層承包商共同分擔最終建築的責任。

土地開發商（Google 的基礎層）。 他們整地、打地基、埋設地下管線、建設周界圍欄。他們保證大樓不會倒塌。這對應到 Google 資料中心的實體安全、硬體、Hypervisor 與全球網路——客戶永遠看不到、也無法修改的那些控制項。

總承包商（Google 的受管服務層）。 對於 Cloud SQL 或 GKE Autopilot 等 PaaS 服務，Google 扮演總承包商的角色——他們組裝結構、安裝電梯、佈線，並認證一切符合法規。您指定平面配置和裝潢風格（哪個容器、哪個資料庫引擎版本），但您不需要親自砌磚或拉電線。

室內設計師與租戶（客戶）。 大樓交屋後，您的公司決定哪些房間作為辦公室、哪些人拿哪些樓層的鑰匙、什麼貴重物品放進保險箱，以及哪些門要在夜間上鎖。無論大樓建得多好，如果您的公司把萬能鑰匙交給陌生人，或把保險箱敞開不鎖，大樓的結構品質也救不了您。 這正是為什麼，即使是 Google Cloud 管理程度最高的服務——例如 BigQuery——客戶仍然百分之百負責 IAM 和資料分類。Google 建好了一座完美的金庫，您決定誰能走進去。

在真實的客戶專案中，同樣的三個層次堆疊起來。Cloud Storage 給您 S 級鋼筋牆壁，但您設定門禁政策。Cloud SQL 給您一個強化的資料庫引擎，但您決定誰能執行 DROP TABLE。共同責任模型，就是「在這個工地上，誰蓋什麼」的正式版本。

責任界線如何隨 IaaS、PaaS、SaaS 移動

CDL 考試中關於共同責任最重要的概念，就是工作分配會隨服務層級而移動。客戶使用的服務越往「堆疊上層」移動——從 IaaS 到 PaaS 到 SaaS——Google 承擔的責任越多，客戶剩餘的責任越少。

Compute Engine（IaaS）

Compute Engine 是最接近傳統地端基礎設施的 Google Cloud 服務。客戶租用原始虛擬機器，並負責虛擬機器內部幾乎所有的事項。

• Google 負責： 實體硬體、Hypervisor 隔離、主機作業系統修補、區域電力與網路、預設 DDoS 防護、永久磁碟的靜態加密。
• 客戶負責： 客體作業系統修補（虛擬機器內部的 Linux 或 Windows）、防火牆規則（VPC 防火牆設定）、應用程式程式碼、安裝在虛擬機器上的第三方軟體、已安裝套件的漏洞掃描、虛擬機器上的作業系統層級使用者帳號、端點防護（如有需要）。

對於 CDL 考試，請記住這句話：「在 Compute Engine 上，作業系統是客戶的問題。」這是最常考的 IaaS 區分點。請參閱 Google Cloud 運算選項 了解 Compute Engine 與 GKE 和 Cloud Run 的比較。

Google Kubernetes Engine 和 Cloud Run（接近 PaaS）

GKE Autopilot 和 Cloud Run 是受管平台。Google 負責底層基礎設施和大部分執行環境層；客戶專注於容器映像檔和應用程式程式碼。

• Google 負責： 硬體、Hypervisor、主機作業系統、Kubernetes 控制平面（適用於 GKE）、節點作業系統修補（適用於 GKE Autopilot）、Cloud Run 執行環境、自動擴展、負載平衡、網路隔離。
• 客戶負責： 容器映像檔安全性（不使用未修補的基礎映像檔、無已知易受攻擊的函式庫）、應用程式程式碼、服務帳號的 IAM 綁定、密鑰管理、哪些端點可以公開、業務邏輯正確性。

與 Compute Engine 相比，關鍵的轉變在於作業系統不再屬於客戶管理範圍。在 GKE Autopilot 上，您無法 SSH 進入節點——您根本不能，因為 Google 已代為管理。您的責任從容器映像檔開始。

BigQuery、Cloud Functions、Cloud SQL（接近 SaaS）

BigQuery、Cloud Functions 和 Cloud SQL 是全受管服務。客戶的責任大幅縮減——資料層以下幾乎所有事情都是 Google 的工作。

• Google 負責： 硬體、Hypervisor、作業系統、服務執行環境、擴展、複寫、備份（適用於 Cloud SQL）、靜態與傳輸中的加密、查詢引擎最佳化、服務本身的軟體修補。
• 客戶負責： 資料分類、資料集／資料表／資料庫執行個體的 IAM、查詢模式與成本、結構描述設計、函式程式碼（適用於 Cloud Functions）、輸入值驗證。

對於 CDL 考試：在全受管服務上，客戶剩餘的工作大約是「資料與存取管理」。這也是為什麼IAM 和資料分類永遠是客戶的責任，不論服務層級為何——它們是 Google 無法替客戶做決定的不可簡化核心。

永遠由 Google 負責的控制項

有一些控制項永遠不會成為客戶的責任，無論使用哪個 Google Cloud 服務。CDL 考試常以「Google 永遠負責 X」的清單形式來測驗這些項目。

資料中心實體安全

Google 自行營運資料中心，配備多層實體安全措施：高牆周界圍欄、車輛門禁管制、生物辨識識別讀卡機、雙門禁氣閘、24 小時巡邏、保存錄影的視訊監控系統，以及上鎖的伺服器機架。沒有任何客戶——即使是全球最大企業——能夠實體進入 Google 的設施。這是雲端採用最有力的論據之一：大多數的地端資料中心無法比擬 Google 的實體控制水準。

自研硬體（Titan）

Google 自行設計伺服器硬體，並在每台主機中內建 Titan 安全晶片。Titan 提供加密驗證的硬體信任根——每台機器只能啟動由 Google 簽署的軟體。客戶看不見這一點，但它支撐著每個 Compute Engine 虛擬機器、每個 BigQuery 運算插槽以及每個 Cloud Run 容器的完整性。

Hypervisor

Hypervisor 是負責在共享硬體上隔離不同租戶工作負載的軟體層。Google 的 Hypervisor 經過強化、稽核，並由 Google 安全團隊持續更新。客戶無需設定，也無需擔心。

靜態資料預設加密

Google Cloud 中儲存的每一位元組客戶資料，預設都會在靜態時進行加密。 這適用於 Cloud Storage、Persistent Disk、BigQuery 儲存空間、Cloud SQL 資料庫、Spanner、Firestore 以及任何其他儲存服務。客戶無需啟用，也無法關閉。請參閱資料加密與保護了解完整的金鑰管理說明，包括客戶管理的加密金鑰（CMEK）。

全球網路與 DDoS 防護

Google 的私有光纖骨幹網路連接全球各地的資料中心。跨區域的流量在此私有網路上傳輸，而非公開網際網路。Google Front End 也提供預設的 DDoS 防護——大流量攻擊在抵達客戶的負載平衡器或虛擬機器之前即被吸收。客戶可在上方疊加 Cloud Armor 以獲得應用程式層的 WAF 防護，但底層的網路層 DDoS 防護盾始終存在。

永遠由客戶負責的控制項

反之，有一些控制項永遠不會轉移給 Google。這些是客戶責任不可簡化的核心。

資料分類與敏感性標記

Google 無法得知您上傳到 Cloud Storage 的試算表，其中裝的是行銷標語還是未加密的信用卡卡號。客戶必須自行分類資料（公開／內部／機密／限制），並套用適當的控制措施。Sensitive Data Protection（前身為 Cloud DLP）等工具可協助探索並標記敏感資料，但分類政策屬於客戶的責任。

身分識別與存取管理決策

Google 提供 IAM 服務，但哪些主體在哪些資源上擁有哪些角色，完全由客戶決定。如果您將 roles/owner 授予廠商的服務帳號，而該廠商的 GitHub 洩漏了金鑰，那不是 Google 的安全事件——那是客戶的 IAM 失誤。

應用程式程式碼安全性

如果您的 Cloud Run 服務含有 SQL 注入漏洞，或您的 Cloud Functions 處理器將信用卡號記錄到 Cloud Logging，那是客戶的程式碼問題。Google 保護執行環境，而非在其中執行的程式碼。

選擇驗證態勢

客戶決定是否要求兩步驟驗證、是否為管理員強制使用硬體安全金鑰、是否與 Active Directory 或 Okta 聯合驗證，以及是否啟用 Access Context Manager 條件（例如「只允許從受管裝置存取」）。Google 提供每個選項；客戶選擇態勢。

Google 的共同命運（Shared Fate）延伸

2021 年，Google 推出共同命運（Shared Fate），作為傳統共同責任模型的延伸。動機在於：業界的共同責任模型歷來是「我們畫出了界線，剩下的就是您的問題」。客戶往往在界線那端感到孤立無援。共同命運說的是：Google 不只是畫出界線——Google 還會主動協助客戶在自己的那一側成功。

共同命運新增了什麼

共同命運提供三大類別的協助，超越了單純的責任分工：

1. 預建最佳實踐與藍圖 — Google 發布參考架構、Terraform 模組以及 Cloud Architecture Framework，讓客戶無需從零開始發明安全模式。
2. 內建安全工具 — Security Command Center、Sensitive Data Protection、Risk Manager 和 Assured Workloads 等服務，協助客戶監控、分類與限制其環境，無需購買第三方工具。
3. 合規證據與認證 — Google 發布稽核報告（SOC 2、ISO 27001、PCI DSS、FedRAMP 等），客戶可作為向自己的稽核人員提交的證據。請參閱合規與隱私了解憑證生態系統。

Security Command Center

Security Command Center（SCC） 是 Google Cloud 的集中式安全與風險管理平台。它會掃描整個組織中的錯誤設定、易受攻擊的工作負載和主動威脅。SCC Premium 增加了威脅偵測（Event Threat Detection、Container Threat Detection）、漏洞掃描和合規儀表板。對於 CDL 而言，SCC 是共同命運的旗艦工具——Google 不只是告訴您「請保護您的環境」，而是給您一個儀表板，告訴您哪些地方目前不安全。

Assured Workloads

Assured Workloads 是 Google Cloud 的功能，可在資源層級強制執行法規控制——例如「只允許此工作負載在美國區域執行，且只允許美國公民的人員操作」。Assured Workloads 被受監管產業（美國政府、醫療保健、金融服務）的客戶使用，這些客戶需要加密證明控制措施已被執行，而非只是記錄在文件中。這是共同命運的另一個範例：Google 不只是告訴您 FedRAMP 的要求是什麼，而是直接將控制措施嵌入平台。

實際範例：對應真實服務

內化共同責任模型最快的方式，是逐一檢視特定服務並找出責任界線。

範例 1 — 在 Compute Engine 上架設電子商務網站

一家零售公司在一批 Compute Engine 虛擬機器上執行其電子商務平台。

• Google 的工作： 硬體、Hypervisor、區域可用性、網路邊緣的 DDoS 防護、預設磁碟加密。
• 客戶的工作： 每台虛擬機器的 Linux 作業系統修補、防火牆規則（只對外開放 443 埠）、應用程式程式碼安全性（無 SQL 注入）、TLS 憑證管理、資料庫密碼輪換、虛擬機器使用的服務帳號之 IAM。

如果客戶六個月未進行 Linux 修補，攻擊者利用未修補的 OpenSSL 漏洞，那是客戶的失敗，不是 Google 的失敗。

範例 2 — 將同一個網站遷移至 Cloud Run

同一家電子商務公司遷移至 Cloud Run。

• Google 的工作： 以上所有，再加上作業系統修補、執行環境修補、容器自動擴展、區域故障轉移。
• 客戶的工作： 容器映像檔品質（使用最新的 Distroless 基礎映像檔、透過 Artifact Registry 漏洞掃描）、應用程式程式碼安全性、Cloud Run 服務帳號的 IAM、決定服務是否可公開呼叫或需要驗證後才能呼叫。

客戶的責任範圍在 Cloud Run 上比在 Compute Engine 上更小——Google 已承擔作業系統修補的責任。但不可簡化的核心（IAM、應用程式程式碼）仍是客戶的責任。

範例 3 — 在 BigQuery 上執行分析

同一家公司將訂單資料載入 BigQuery 進行分析。

• Google 的工作： 幾乎一切，除了資料和 IAM。儲存複寫、加密、查詢引擎維護、硬體更新、作業系統修補、擴展、備份。
• 客戶的工作： 哪些資料集存在、每個資料集的 IAM 綁定為何、執行哪些 SQL 查詢、查詢允許花費多少費用、是否對敏感欄位進行遮罩。

如果客戶將 roles/bigquery.dataOwner 授予一個被入侵的服務帳號，導致的資料外洩是客戶端的 IAM 失敗——不是 BigQuery 的安全失敗。

常見誤解

對於 CDL 考試，請在情境題中辨識以下錯誤的思維模型：

1. 「Google 幫我加密資料，所以我不需要擔心誰能讀取它。」 錯誤。加密可防止磁碟被實體竊取。它無法防止擁有合法 IAM 主體的人讀取他們本不應有權存取的資料。加密和 IAM 解決的是不同的問題。
2. 「我使用的是 SaaS 服務，所以 Google 處理所有安全事項。」 錯誤。即使是管理程度最高的服務，資料分類和 IAM 仍是客戶的責任。
3. 「DDoS 防護需要我訂閱付費產品。」 部分錯誤。預設網路層 DDoS 防護透過 Google Front End 免費提供。Cloud Armor 在上方增加付費的應用程式層 WAF 功能。
4. 「Compute Engine 比 Cloud Run 更安全，因為我控制作業系統。」 錯誤。控制權並不等於安全性。在 Cloud Run 上，Google 修補作業系統的速度和一致性，比大多數客戶能做到的更快、更好。正確的框架是：控制與便利性的取捨，而非控制與安全性的取捨。
5. 「共同責任意味著 Google 和我各承擔 50%。」 錯誤。分工是不對稱的，且會隨服務層級移動。在 Compute Engine 上，客戶承擔大部分作業系統及以上的工作。在 BigQuery 上，客戶只需做很少的事。

模型如何與其他 CDL 章節連結

共同責任模型是串聯所有其他 Google Cloud 安全章節的框架。

• 身分識別與存取管理 — IAM 是客戶在自己那一側的主要工具。請參閱身分識別與存取管理（IAM）。
• 資料加密與保護 — 靜態加密預設是 Google 那一側的責任；金鑰管理（CMEK／CSEK）是希望獲得更多控制的客戶可使用的共同命運選項。請參閱資料加密與保護。
• 合規與隱私 — Google 的合規認證涵蓋 Google 的那一半；客戶仍必須為自己的那一半提供證據。請參閱合規與隱私。
• 雲端價值主張 — 清晰的共同責任模型是雲端比地端更快的部分原因：客戶花較少時間在硬體與 Hypervisor 的工作上，而將更多時間用於業務邏輯。

常見問題

共同責任與共同命運有什麼差異？

共同責任是靜態契約，定義 Google 與客戶之間各自擁有哪些安全控制項。共同命運是 Google 承諾主動協助客戶在契約的自己那一側成功——提供藍圖、Security Command Center 等內建工具以及合規證據，讓客戶不必獨自摸索一切。共同責任說的是「這裡是界線」，共同命運說的是「我們還會幫助您在自己那一側站穩腳跟」。

Google 是否對設定錯誤的 Cloud Storage 儲存桶負責？

不。Google 提供安全的預設值（新儲存桶預設為私有）、工具（Security Command Center 的錯誤設定發現功能）以及警告提示（主控台在將儲存桶設為公開前會出現警告）。但將儲存桶的 IAM 政策設定為 allUsers 的決定是客戶的，由此造成的資料暴露是客戶端的失敗。CDL 考試每次都將儲存桶設定錯誤視為客戶責任。

如果我使用 BigQuery，我需要負責修補任何東西嗎？

不需要。BigQuery 是全受管服務。Google 處理所有作業系統修補、執行環境修補、儲存層維護和引擎升級。您剩餘的責任是資料分類（資料表中有什麼）、IAM（誰能查詢資料表），以及查詢模式（成本與效能）。您永遠不會 SSH 進入 BigQuery 主機，因為從客戶的角度來看，根本沒有 BigQuery 主機這個概念。

誰負責防護 DDoS 攻擊？

Google 透過 Google Front End 提供預設的網路層 DDoS 防護——這是自動的、免費的，適用於每個 Google Cloud 工作負載。客戶負責應用程式層的防護，如果其工作負載需要 WAF 規則、速率限制或地理封鎖。Cloud Armor 是 Google Cloud 的付費產品，提供應用程式層的 DDoS 防護和 WAF 功能。CDL 考試常測驗這個分工：網路層 DDoS 防護預設是 Google 的責任；應用程式層 WAF 是客戶設定的 Cloud Armor 功能。

從 Compute Engine 遷移至 GKE Autopilot，共同責任模型是否會改變？

會，而且改變顯著。在 Compute Engine 上，客戶擁有作業系統修補、套件管理和主機層級漏洞修復的責任。在 GKE Autopilot 上，Google 接管節點作業系統修補、Kubernetes 控制平面操作和節點生命週期管理。客戶的責任縮減為容器映像檔品質、工作負載身分綁定、網路政策以及應用程式程式碼本身。CDL 考生應將此視為「往堆疊上層移動會將更多責任轉移給 Google」的典型範例。

Google 是否會讀取我的資料以提供雲端服務？

不。Google 的條款承諾不將客戶資料用於廣告，也不在未經同意的情況下用於訓練通用 AI 模型。在正常操作下，Google 人員無法讀取傳輸中或靜態的客戶資料——所有資料都已加密，人員存取受到記錄在 Access Transparency 中的稽核管理員操作所管制。希望獲得更強保證的客戶，可以啟用 Access Approval，這要求 Google 支援人員在合法排障期間存取客戶資料時，必須獲得客戶的明確授權。請參閱合規與隱私了解隱私承諾的詳細說明。

摘要：共同責任模型作為安全基礎

對於 Cloud Digital Leader 考試，共同責任模型是其他所有安全章節賴以建立的基礎思維模型。請記住兩個部分——Google 保護雲端的安全性（實體、硬體、Hypervisor、全球網路、預設加密、受管服務的作業系統），客戶保護雲端中的安全性（資料分類、IAM、應用程式程式碼、驗證態勢）。記住界線會隨服務層級移動——在 Compute Engine（IaaS）上，客戶擁有作業系統；在 GKE Autopilot 或 Cloud Run（接近 PaaS）上，Google 擁有作業系統；在 BigQuery 或 Cloud Functions（接近 SaaS）上，Google 幾乎擁有資料層以下的一切。並記住IAM 和資料分類永遠是客戶的工作，不論服務的受管程度。

最後，請認識**共同命運（Shared Fate）**是 Google 超越靜態契約的延伸——Security Command Center、Assured Workloads、Sensitive Data Protection 和 Cloud Architecture Framework 等工具的存在，正是為了讓客戶不必獨自操作自己的那一半。一位能夠用業務語言解釋共同責任的 CDL——「Google 負責大樓和電梯；我們負責決定誰拿到辦公室鑰匙，以及我們把什麼放進保險箱」——就已準備好為利害關係人提供建議，說明哪些 Google Cloud 服務適合哪種風險概況，以及組織需要在哪些自身的安全能力上投入資源。