Google Cloud 中的靜態資料加密
根據預設，Google Cloud 會使用 Google 管理的金鑰加密所有靜態的客戶資料。然而，對於具有嚴格監管或安全要求的組織，Google 提供了兩種控管加密金鑰的方法：CMEK 和 CSEK。
對於 專業雲端安全工程師 (PSE) 而言，了解何時以及如何實作這些金鑰對於滿足 HIPAA、PCI-DSS 或 GDPR 等合規標準至關重要。
白話文解釋
比喻一：飯店保險箱（預設 vs CMEK vs CSEK）
想像在飯店保管貴重物品的三種方式：
- 預設 Google 管理加密就像房內的保險箱——飯店替你設定、輪替並稽核密碼。你完全不用操心，但必須完全信任飯店。
- CMEK 就像你自備一把掛鎖（Cloud KMS key）扣上保險箱。飯店人員（GCS、BigQuery、Compute Engine 的 service agent）仍可開箱，但前提是你把主鑰匙的使用權授予他們——而你隨時可以撤回授權。
- CSEK 則像把唯一的鑰匙放在自家鑰匙圈上。每次想開保險箱，都必須親自把鑰匙帶到現場交給櫃台。一旦鑰匙圈遺失，飯店也救不了你——箱內物品就永遠封死了。
比喻二：圖書館的逐櫃上鎖（CMEK 是 per-resource）
使用 CMEK 的圖書館不會用一把鑰匙鎖住整棟建築。每一個書櫃（一個 GCS bucket、一個 BigQuery dataset、一顆 Persistent Disk）都有自己的掛鎖，鎖頭引用自中央鑰匙櫃（Cloud KMS key ring）。當你撤銷「財務」書櫃的金鑰時，只有財務書櫃變得不可讀——歷史書櫃照樣可以翻閱。這就是 CMEK 被稱為**per-resource（逐資源）**的原因：加密在建立資源那一刻就綁定到該資源，輪替或停用某把金鑰也絕不會波及其他不相關的資源。
比喻三：保安快遞（CSEK 必須隨每次請求提供）
CSEK 運作起來就像保安快遞服務：每一次寄送（每一次 GCS 或 Compute Engine 的 API 呼叫）你都必須當場提交一張手寫的授權單（也就是放在 x-goog-encryption-key HTTP header 中的原始 256-bit 金鑰）。快遞員從不留底——一旦運送完成，那張授權單就從記憶體中銷毀。這也是為什麼 CSEK 只支援 Cloud Storage 和 Compute Engine：像 BigQuery 或 Dataflow 這類會跑長時間背景任務的服務，沒辦法在每次讀取時暫停下來向你索取金鑰。
客戶管理加密金鑰 (CMEK)
CMEK 使用 Cloud KMS 金鑰來保護您的資料。您負責管理金鑰（輪替、IAM 權限、銷毀），但金鑰本身儲存在 Google Cloud 內部。
CMEK 工作流程：
- 在 Cloud KMS 中建立金鑰環 (Key Ring) 和金鑰 (Key)。
- 將
cloudkms.cryptoKeyEncrypterDecrypter角色授予目標服務（例如 GCS 或 BigQuery）的服務代理 (Service Agent)。 - 設定該資源（儲存桶、資料集或磁碟）以使用該 KMS 金鑰。
客戶管理加密金鑰 (CMEK) 是由您在 Cloud KMS 中建立並管理，但由其他 Google Cloud 服務用來保護您資料的金鑰。
CMEK 是 per-resource（逐資源綁定）：KMS 金鑰會在建立資源那一刻就綁定到特定的 GCS bucket、BigQuery table 或 Compute Engine disk。您無法回頭把既有的 bucket 重新換成另一把 CMEK 金鑰加密——必須建立一個指定新金鑰的新 bucket / dataset / disk，再把資料搬過去。請務必在佈建資源之前就把金鑰指派規劃好。
將 CMEK 與服務整合
Cloud Storage (GCS)
- 您可以為儲存桶設定預設的 KMS 金鑰。
- 上傳到該儲存桶的所有新物件都會自動使用該 CMEK 進行加密。
BigQuery
- 您可以在建立資料表或執行將結果輸出到新資料表的查詢時指定 CMEK。
- CMEK 保護磁碟上的資料，但不保護元數據（如欄位名稱）。
Compute Engine (GCE)
- CMEK 可用於加密永久磁碟 (Persistent Disks, PD)。
- 每當磁碟掛載到 VM 或建立快照時，都需要使用該金鑰。
客戶提供加密金鑰 (CSEK)
CSEK 適用於最極端的安全要求。您在 Google Cloud 外部產生金鑰素材，並在每次 API 呼叫時提供該金鑰。
CSEK 的特性：
- Google 絕不會將您的 CSEK 金鑰素材儲存在磁碟上。它僅在處理您的資料時保留在記憶體中。
- 如果您遺失了金鑰，Google 無法協助您復原資料。
- 僅由 Cloud Storage 和 Compute Engine 支援。
CSEK 要求您自行管理金鑰的可用性。如果您的金鑰管理系統故障，且您無法在 API 呼叫期間提供金鑰，您將無法存取資料。
考試最常見的陷阱就是把兩種模型搞混。請牢記：CSEK 必須隨每一次請求提供（在每一次 GCS 讀寫、或每一次 Compute Engine disk attach 的 API 呼叫上，於 x-goog-encryption-key HTTP header 帶入那把 256-bit 原始金鑰）。一旦遺失 CSEK 金鑰，資料就永久毀滅——Google 沒有任何備份。CMEK 則完全相反：Google 將金鑰保存於 Cloud KMS，因此失去 IAM 身分並不會毀掉資料，而被排程銷毀的 KMS key version 還可以在 24 小時的等待視窗內救回。此外，CSEK 不支援 BigQuery、Dataflow、Dataproc、Pub/Sub——只支援 GCS 與 Compute Engine。如果題目把 CSEK 跟 BigQuery 配在一起，那一定是錯誤選項。
金鑰撤銷對資料可用性的影響
使用 CMEK 或 CSEK 的主要原因之一是具備「隨時切斷存取」的能力。
- 撤銷 CMEK： 如果您停用 KMS 金鑰或移除服務代理的 IAM 權限，該服務將無法再解密資料。存取權限會在幾分鐘內失效。
- 撤銷 CSEK： 只要停止在 API 標頭中提供金鑰即可。
CMEK 的服務代理 (Service Agent) 角色
每個 Google Cloud 服務都有一個服務代理（由 Google 管理的服務帳戶），代表您執行操作。
- 範例： GCS 的服務代理格式為
service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com。 - 關鍵步驟： 您必須手動授予此代理存取您 KMS 金鑰的權限。否則，CMEK 整合將會失敗。
強制執行 CMEK 的組織政策
為了防止出現使用 Google 管理金鑰加密的「影子資料」，請使用組織政策 (Organization Policies)：
constraints/gcp.restrictNonCmekServices：防止建立未受 CMEK 保護的資源。constraints/gcp.restrictCmekCryptoKeyProjects：限制可用於提供金鑰的 KMS 專案。
CMEK 與 CSEK 使用情境比較
| 特性 | CMEK | CSEK |
|---|---|---|
| 金鑰儲存位置 | Cloud KMS | 地端 (On-Premises) / 外部 |
| 管理複雜度 | 中等 | 非常高 |
| 支援的 GCP 服務 | 大多數服務 | 僅限 GCS, GCE |
| 金鑰輪替 | 在 KMS 中自動執行 | 僅能手動執行 |
| 資料遺失風險 | 低 (Google 管理 KMS) | 高 (如果您遺失金鑰) |
排除加密錯誤
- 對 CMEK 資源顯示「權限遭拒」： 通常意味著服務代理失去了在 KMS 金鑰上的
加密者/解密者角色。 - 對 CSEK 顯示「金鑰無效」： 標頭中提供的原始 256 位元字串與用於加密資料的字串不符。
- KMS 金鑰已停用： 金鑰存在，但狀態為
DISABLED。您必須在 KMS 控制台中重新啟用它。
預設靜態加密 vs. 管理金鑰
請記住，預設加密（Google 管理）始終處於啟用狀態。CMEK 和 CSEK 是額外的控制層。
- 預設加密： 無管理開銷，符合 FIPS 140-2 標準。
- CMEK： 可控管輪替與撤銷，具備金鑰使用稽核記錄。
- CSEK： 完全掌控，金鑰絕不會存在於 Google 管理的儲存空間中。
對於 99% 的企業客戶而言，CMEK 是安全與易管理性之間的最佳平衡。僅在法律有明確強制要求時才使用 CSEK。
PSE 考試加密模型速記表：
| 屬性 | 預設加密 | CMEK | CSEK |
|---|---|---|---|
| 金鑰來源 | 您在 Cloud KMS 中建立 | 您在 GCP 外部自行產生 | |
| 金鑰儲存 | Cloud KMS（搭配 HSM 達 FIPS 140-2 L3） | 絕不儲存——僅暫存記憶體 | |
| 金鑰輪替 | 自動（Google） | KMS 自動輪替（例如 30 / 90 天）或手動 | 僅能手動（重寫物件） |
| 撤銷後資料是否無法存取 | 否 | 是——停用 KMS 金鑰或撤掉 Service Agent IAM | 是——停止帶入金鑰 header |
| 支援的服務 | 全部 | BigQuery、GCS、Compute Engine、Dataflow、Pub/Sub、Composer、Spanner 等 | 僅 GCS 與 Compute Engine |
| Per-resource 綁定 | N/A | 是——於建立時綁定 | 隨每次請求帶入（header） |
| 金鑰遺失資料損失 | N/A | 低（Google 管理 KMS） | 全毀——永久遺失 |
| 組織政策強制 | N/A | constraints/gcp.restrictNonCmekServices |
無——由您的 KMS 自行控管 |
關鍵字觸發口訣：「每 N 天輪替」→ 啟用自動輪替的 CMEK；「金鑰絕不落地於 Google」→ CSEK；「緊急撤銷加密磁碟存取」→ 停用對應的 KMS 金鑰（CMEK）。
PSE 考試情境
情境 1：強制執行合規性
「某公司必須確保在 Finance 資料夾中建立的所有 BigQuery 資料集都使用他們可以每 30 天輪替一次的金鑰進行加密。您該如何實作？」
解答： 1. 建立一個具備 30 天自動輪替排程的 KMS 金鑰。 2. 在 Finance 資料夾層級設定組織政策，要求強制使用 CMEK。 3. 授予 BigQuery 服務代理存取該 KMS 金鑰的權限。
情境 2：緊急撤銷存取
「偵測到某個特定專案發生安全漏洞。您需要立即停止對該專案中所有加密磁碟的存取。最快的方法是什麼？」
解答： 如果使用的是 CMEK，請停用該 KMS 金鑰或移除 Compute Engine 服務代理的 IAM 加密者/解密者 角色。
總結檢查表
- 解釋服務代理在 CMEK 中的角色。
- 列出支援 CSEK 的兩項服務。
- 比較 CMEK 與 CSEK 的金鑰儲存位置。
- 識別用於強制要求 CMEK 的組織政策。
- 描述停用 KMS 金鑰對受 CMEK 保護資源的影響。