examlab .net 用最有效率的方法，考取最有價值的證照
支持
本篇導覽 約 19 分鐘

金鑰管理與加密

3,800 字 · 約 19 分鐘閱讀 ·

保護靜態與傳輸中的數據：Cloud KMS、Cloud HSM、客戶管理的加密金鑰 (CMEK) 以及架構師適用的封套加密。

立即做 20 題練習 → 免費 · 不用註冊 · PCA

Google Cloud 加密簡介

對於 Professional Cloud Architect 而言，數據保護是不可妥協的。Google Cloud 預設會加密所有靜態 (at rest) 和傳輸中 (in transit) 的客戶數據。然而，許多企業為了滿足監管或合規標準，需要更高層級的控制。

了解金鑰管理的光譜——從 Google 管理到客戶管理——對於通過 PCA 考試至關重要。

一種雲端代管的金鑰管理服務，可讓你像在地端一樣管理雲端服務的加密金鑰。你可以生成、使用、輪換和銷毀 AES256、RSA 2048, 3072, 4096 以及橢圓曲線 (Elliptic Curve) 加密金鑰。參考資料：https://cloud.google.com/kms/docs/overview

白話文解釋加密與金鑰管理

加密就像是將秘密藏在腦袋裡與將其放入高科技保險箱之間的區別。

類比 1 — 俄羅斯娃娃（封套加密 - Envelope Encryption）

封套加密 (Envelope Encryption) 就像是 俄羅斯娃娃。你將秘密（數據）放入一個小娃娃中（數據加密金鑰 - DEK）。但小娃娃很脆弱。因此，你將小娃娃放入一個更大、更強壯的娃娃中（金鑰加密金鑰 - KEK）。你將大娃娃鎖在保險箱裡 (Cloud KMS)。要獲取秘密，你必須首先獲得開啟大娃娃的權限。

類比 2 — 飯店保險箱 (CMEK)

Google 管理的金鑰 (Google-Managed Keys) 就像飯店提供的保險箱。他們擁有主金鑰，並負責處理一切。客戶管理的加密金鑰 (CMEK) 則像是你帶著自己的 高科技掛鎖 來鎖飯店保險箱。飯店提供保險箱（儲存空間），但 你 持有掛鎖的唯一鑰匙。如果你丟失了鑰匙或將其扔掉，即使是飯店工作人員也無法打開保險箱。

類比 3 — 裝甲地庫 (Cloud HSM)

Cloud HSM (硬體安全模組) 就像將你的黃金從標準銀行保險箱移至一個物理上具備防篡改保護的 地下裝甲地庫。如果有人試圖鑽探進入地庫，它會立即自我毀滅或封鎖。這適用於當你需要最高層級的物理安全和認證（FIPS 140-2 Level 3）時。

靜態加密：三個層級

GCP 提供三種管理加密金鑰的方式：

1. Google 預設加密 (Google-Default Encryption)

  • 管理者： Google。
  • 管理心力： 零。
  • 成本： 免費。
  • 使用情境： 絕大多數客戶的預設選擇。Google 處理金鑰生成和輪換。

2. 客戶管理的加密金鑰 (CMEK)

  • 管理者： 你（透過 Cloud KMS）。
  • 管理心力： 低（你必須創建金鑰並授予權限）。
  • 使用情境： 合規性需求（例如 HIPAA, PCI-DSS）。你可以停用金鑰以立即「粉碎」你的數據（加密粉碎 - Crypto-shredding）。
  • 整合： 適用於 GCS、BigQuery、Compute Engine (PD) 等多項服務。

3. 客戶提供的加密金鑰 (CSEK)

  • 管理者： 你（在 GCP 之外）。
  • 管理心力： 高（你必須在每次 API 調用時提供金鑰）。
  • 使用情境： 極端安全性需求，金鑰絕不能以未加密的形式觸及 Google 磁碟。
  • 限制： 僅由 Compute Engine 和 Cloud Storage 支援。

架構師必備的 KMS 核心概念

1. 金鑰階層

  • 金鑰環 (Key Ring)： 為了組織管理目的而對金鑰進行的邏輯分組。
  • 加密金鑰 (CryptoKey)： 代表邏輯金鑰的具名資源。
  • 加密金鑰版本 (CryptoKey Version)： 用於加密的實際材質。一個金鑰可以有多個版本（用於輪換）。

2. 封套加密 (DEK 與 KEK)

  • DEK (Data Encryption Key)： 速度快，用於加密實際數據。存儲在數據 旁，但由 KEK 加密。
  • KEK (Key Encryption Key)： 用於加密 DEK。存儲在 Cloud KMS 中。

3. 金鑰輪換 (Key Rotation)

  • Cloud KMS 支援 自動輪換（例如每 90 天）。
  • 舊版本會保留，以便舊數據仍可解密，但所有新數據都會使用最新版本進行加密。

外部金鑰管理工具 (EKM)

對於需要將金鑰 實體保留在雲端之外 的組織，Google 提供 Cloud EKM。

  • 工作原理： Cloud KMS 透過安全橋接器與外部金鑰管理器（例如 Thales, Fortanix）通訊。
  • 架構師提示： 這是「最終」的控制手段，但會增加延遲並對外部提供者產生依賴性。如果 EKM 發生故障，你的 GCP 服務將無法存取數據。

Cloud EKM via Internet 與 Cloud EKM via VPC：VPC 版本會把 encrypt/decrypt RPC 改走 Private Service Connect 端點而非公開網際網路，這是許多受管制工作負載的硬性要求。但兩種模式都依賴外部 KMS 必須可用——一旦 Thales CipherTrust 或 Fortanix DSM 無法連線，BigQuery 任務、GCE 磁碟掛載以及對 EKM 保護資源的 GCS 物件讀取都會以 FAILED_PRECONDITION 失敗。

Cloud HSM 支援金鑰與 FIPS 140-2 Level 3

Cloud HSM 是一項由 Google 操作的代管 HSM 服務，金鑰絕不離開 FIPS 140-2 Level 3 認證的硬體模組叢集。它透過同一組 Cloud KMS API 介面公開使用——在建立 CryptoKey 時把 protectionLevel 從 SOFTWARE 換成 HSM 即可。

何時必須用 HSM（而不只是錦上添花）

  • 受管制工作負載：PCI-DSS、FedRAMP High 與許多金融監管機構明確要求保護持卡人資料或主權記錄的金鑰必須使用 Level 3 模組。
  • 防篡改保證：Level 3 代表模組會實際偵測物理入侵企圖並把金鑰材質清零。Cloud KMS 中軟體保護的金鑰僅達 FIPS 140-2 Level 1。
  • Attestation 證明：HSM 支援金鑰會回傳一份已簽章的 attestation 聲明，你可以在離線情境下驗證，以證明某把金鑰確實是在真實的 Cloud HSM 設備內產生。

與軟體保護金鑰的實務差異

  • 延遲：HSM 操作每次 encrypt/decrypt 呼叫比軟體金鑰多約 10-30 ms。對高吞吐串流管線，務必透過 封套加密 讓 HSM 保護的 KEK 只負責包裝 DEK。
  • 演算法涵蓋：Cloud HSM 支援 AES-256-GCM 對稱、RSA 2048/3072/4096 以及 EC P-256/P-384 非對稱。部分較新的 KMS 演算法（例如 RAW AES）僅限軟體版本。
  • 成本：HSM 金鑰按每月有效金鑰版本以及操作次數計費，遠高於軟體金鑰。把它保留給 KEK 層，而不是 DEK 層。

常見的考題陷阱會把「FIPS 140-2 Level 3」與「使用 Customer-Supplied Encryption Keys (CSEK)」配對。這是錯誤的。CSEK 只要求你在 API 請求中夾帶一把原始的 256-bit 金鑰，並未對 Google 暫存它的方式提出任何保證。Level 3 的正確答案是 Cloud HSM（protectionLevel: HSM），或用 Cloud EKM 橋接到地端的已認證 HSM。

Key Access Justifications (KAJ) 與可證明的控制權

Key Access Justifications 構築在 Cloud EKM（以及部分 EKM via VPC 部署）之上，能讓你以加密方式取得證據，得知 Google 為何要求你的外部金鑰管理器解封某把金鑰。

KAJ 工作原理

  1. 某項 GCP 服務（例如 BigQuery）需要解密一筆受 CMEK 保護、且金鑰存放在你的外部 EKM 的資料。
  2. Cloud KMS 把解封請求轉發到你的 EKM，並附上一個已簽章的 justification 代碼——值包括 CUSTOMER_INITIATED_ACCESS、GOOGLE_INITIATED_SYSTEM_OPERATION 或 THIRD_PARTY_DATA_REQUEST。
  3. 你的外部 KMS 策略引擎檢視這個 justification，然後決定核准或拒絕解封。決策會在 你這一端 記錄，落在 Google 的影響範圍之外。

為什麼架構師會在意

  • 內部風險控管：你可以設定 EKM 在敏感合規期間拒絕任何 GOOGLE_INITIATED_* 理由，這意味著即使是擁有有效 IAM 的失控 Google 操作員，也無法讀取資料。
  • 法遵舉證：KAJ 紀錄構成可稽核的拒絕證據，足以應付要求「雲端供應商不得能存取明文」的監管機關。
  • 與 Assured Workloads 搭配：KAJ 是受管制區域（例如 eu.gcp.example.com 主權控制）Assured Workloads 背後的基礎模組之一，提供 Bring-Your-Own-Key 加 Bring-Your-Own-Decision。

KAJ 觸發對照表：CUSTOMER_INITIATED_ACCESS = 你的 IAM principal 查詢了 BigQuery；GOOGLE_INITIATED_SERVICE = 自動化平台健康任務；GOOGLE_INITIATED_REVIEW = Google 支援人員正在排除故障；THIRD_PARTY_DATA_REQUEST = 傳票或執法請求；REASON_NOT_EXPECTED = 缺少 justification，你的 EKM 預設就該全數拒絕。

Cloud KMS 中的非對稱金鑰與對稱金鑰

Cloud KMS 支援三種金鑰用途——挑錯就會在執行期碰上 INVALID_ARGUMENT。

對稱加密（ENCRYPT_DECRYPT）

  • 演算法：AES-256-GCM。
  • 用同一把金鑰加密與解密。所有整合（GCS、BigQuery、PD、Spanner、Pub/Sub 上的 CMEK）底層用的都是這種。
  • 支援自動輪換：新版本依排程建立，舊版本仍可用於解密。
  • API：projects.locations.keyRings.cryptoKeys.encrypt / decrypt。

非對稱加密（ASYMMETRIC_DECRYPT）

  • 演算法：RSA-OAEP 2048/3072/4096，搭配 SHA-256 或 SHA-512。
  • 公鑰 可匯出供外部客戶端加密；私鑰 絕不離開 KMS，並透過 asymmetricDecrypt 使用。
  • 使用情境：合作夥伴上傳以你公鑰加密的檔案；只有在該 KMS 資源上擁有 cryptoKeyDecrypter 的服務才能讀取。
  • 無自動輪換——必須手動建立新金鑰版本並重新公布公鑰。

非對稱簽章（ASYMMETRIC_SIGN）

  • 演算法：RSA-PSS、RSA-PKCS1、EC P-256、EC P-384。
  • 使用情境：簽署服務間驗證用的 JWT、簽署軟體成品（Binary Authorization attestation），或為供應鏈完整性簽署容器映像。
  • asymmetricSign API 回傳簽章；驗證方透過 cryptoKeyVersions.getPublicKey 取得公鑰並在本地驗證——每次驗證不必再多打一次 KMS。

MAC 金鑰（MAC）

  • 演算法：HMAC-SHA-256。
  • 使用情境：權杖驗證、webhook 簽章驗證。macSign 與 macVerify 皆在 KMS 伺服器端執行。

GKE 上的 Binary Authorization 永遠應該選用 EC P-256 的 ASYMMETRIC_SIGN 金鑰，而非 RSA。EC 簽章比 RSA 小一個數量級，可確保 attestation payload 落在 Kubernetes 64 KB annotation 限制之內，並避免在繁忙叢集上 admission webhook 逾時。

Confidential VM 與 Confidential GKE Nodes

CMEK 保護的是 靜態 資料。Confidential Computing 把最後一道缺口補上：使用中 的 RAM 內資料。

Confidential VM

  • 底層為支援的 n2d、c2d、c3、n2d-confidential 機型上的 AMD SEV（Secure Encrypted Virtualization）或 Intel TDX。
  • Hypervisor 無法讀取 guest RAM——每一頁都由嵌在 AMD/Intel 硬體中、屬於該 VM 專屬的金鑰加密。
  • 效能負擔通常落在 2-7%，大多體現在記憶體密集的工作負載上。
  • 與 PD 上的 CMEK 以及 Cloud Storage 上的 CMEK 搭配，就能讓資料在客戶金鑰下端到端加密：磁碟靜態、TLS 傳輸、RAM 使用三段皆然。

Confidential GKE Nodes

  • 在節點池上設定 --enable-confidential-nodes。每個節點都會變成一台 Confidential VM；排程上來的 Pod 透明繼承保護——無需修改應用程式。
  • 可與 Workload Identity 以及 CMEK 保護的節點開機磁碟 結合，提供監管機關最愛的組合：硬體記憶體隔離 + 客戶控管磁碟加密 + workload 級 IAM。
  • 限制：並非所有機型家族都支援 Confidential Nodes；GPU 節點池與部分加速器被排除在外。

在 PCA 考試何時該選它

  • 「多租戶 SaaS 處理競爭對手資料，雲端供應商不得在記憶體中看到」→ Confidential VM。
  • 「在病患基因組上做 ML 訓練，且資料贊助方須驗證硬體隔離」→ Confidential GKE Nodes + 訓練資料儲存桶的 CMEK + Assured Workloads。
  • 「縮短單次短批次任務的記憶體曝險」→ 若資料已在上傳前用客戶端加密，Confidential VM 過頭了；改用 Tink 的客戶端 AEAD 更合適。

Confidential Computing 保護 使用中 的資料，但它 不能 取代 CMEK。正確的架構是三層疊加：Confidential VM/GKE 處理 RAM、Cloud Storage 與 Persistent Disk 上的 CMEK 處理靜態資料、再加上 TLS 1.3（搭配 gcloud compute ssl-policies 強制現代化的設定檔）處理傳輸。「Confidential VM 已經加密記憶體所以可以省掉 CMEK」是常見但錯誤的簡化——加密過的磁碟映像若沒有明確掛上 CMEK，仍是由 Google 管理的金鑰解密。

BigQuery 欄位層級加密的 CMEK 用法

標準 CMEK 是針對整個 BigQuery 資料集或資料表加密。如果要對個別敏感欄位做更細的控制，BigQuery 提供 AEAD 加密函式，並可吃 Cloud KMS（或 Tink）發出的 keyset。

欄位層級 CMEK 如何運作

  1. 建立 Cloud KMS 對稱 金鑰，例如 projects/p/locations/us/keyRings/pii/cryptoKeys/ssn-col。
  2. 把 roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation 授權給資料所在專案的 BigQuery service agent。
  3. 在查詢中使用 AEAD.ENCRYPT(KEYS.KEYSET_CHAIN(...), plaintext, aad) 與 AEAD.DECRYPT_STRING(...) 之類的 SQL 函式。Keyset 會在查詢編譯期才從 KMS 延遲載入。
  4. 搭配 policy tag（Data Catalog），只有在該標籤上具備 fineGrainedReader 的 IAM principal 才能呼叫 AEAD.DECRYPT_STRING——其他人只看得到密文或 NULL。

架構師該知道的模式

  • 確定性欄位：使用 DETERMINISTIC_ENCRYPT，同樣的明文永遠對應同樣的密文——可在不揭露明文的情況下對加密欄位做 JOIN。
  • 以租戶為單位的加密粉碎：把每位租戶的 keyset 放在不同的 KMS 金鑰下。停用某位租戶的金鑰（gcloud kms keys versions disable ...），就能讓該租戶的 PII 在所有 BigQuery 資料表、materialized view 與 BI 快取中瞬間無法讀取——不必改寫任何一列。
  • 效能：欄位層級 AEAD 每列會增加可觀的 CPU 成本。對非常寬的事實表，請優先採用 資料表級 CMEK + DLP 去識別化，而非把每個欄位都加密。

KMS 的安全性與 IAM

  • 職責分離 (Separation of Duties)： 「安全性管理員 (Security Admin)」應管理金鑰，而「儲存管理員 (Storage Admin)」應僅能 使用 金鑰。
  • 授予存取權： 你必須授予資源的服務帳戶（例如 GCS 服務帳戶）roles/cloudkms.cryptoKeyEncrypterDecrypter 角色。
  • 審計日誌： Cloud KMS 會記錄每次使用金鑰的情況，為合規性提供詳細的追蹤記錄。

常見問題 — 金鑰管理與加密

Q1. 什麼是「加密粉碎」(Crypto-shredding)？

這是透過 刪除用於保護數據的加密金鑰，使數據變得無法讀取的過程。即使加密數據仍存在於磁碟上，沒有金鑰它也是毫無用處的。

Q2. CMEK 會減慢我的應用程式速度嗎？

通常 不會。由於使用了封套加密，KMS 中的 KEK 僅用於解密 DEK。一旦 DEK 進入記憶體，加密/解密就會以本地速度進行。

Q3. 我可以在 GCP 中使用我自己的 HSM 嗎？

可以，透過 Cloud EKM，你可以將 GCP 連結到你地端的 HSM。

Q4. 如果我丟失了我的 CSEK（客戶提供金鑰）會怎樣？

數據將永遠消失。 Google 不會存儲你的 CSEK 副本。沒有任何恢復程序。

Q5. 數據在 GCP 內部傳輸時會加密嗎？

會。Google 會自動使用 TLS/SSL 加密 Google 數據中心之間，以及使用者與 Google 服務之間傳輸的數據。

最後的架構師提示

在 PCA 考試中，重點關注 CMEK 與 CSEK 的區別。請記住，CMEK 是符合合規性的標準企業推薦方案。如果題目提到 "FIPS 140-2 Level 3"，答案是 Cloud HSM。如果提到「對實體保存在地端的金鑰擁有完全控制權」，答案是 Cloud EKM。此外，務必確認調用服務的 服務帳戶 (Service Account) 擁有使用 KMS 金鑰的權限。

官方資料來源

更多 PCA 主題