進階金鑰管理簡介
對於有嚴格監管要求或在高度受限產業（如金融或政府）運作的組織，標準的軟體架構金鑰可能不足以滿足需求。
Google Cloud 提供兩條主要路徑來增強金鑰安全性：Cloud HSM（將金鑰保留在 Google 管理的硬體中）以及 Cloud EKM（將金鑰完全保留在 Google Cloud 外部）。
白話文解釋
比喻一：飯店房內保險箱 vs. 自家銀行金庫
想像您入住一家豪華飯店（Google Cloud）並需要存放貴重物品。Cloud HSM 就像房內的保險箱——飯店打造、飯店維護（通過 FIPS 140-2 Level 3 認證），但只有您知道密碼。它便利且低延遲，但保險箱仍位於飯店建築物內。Cloud EKM 則像把貴重物品存在城市另一端您自己的銀行金庫（Fortanix、Thales、Equinix 或 Virtru）。每當飯店服務生想從您的金庫取東西，必須打電話給您，明確說明理由（Key Access Justifications (KAJ) 代碼），然後等銀行透過專線臨時遞出金鑰。如果您的銀行關門，飯店就打不開保險箱——這就是 kill switch 機制。
比喻二：每一次請求都附公證章
把 Key Access Justifications (KAJ) 想像成附帶公證理由單的快遞服務。當 BigQuery 向您的 EKM 索取金鑰時，請求會蓋上 CUSTOMER_INITIATED_ACCESS、GOOGLE_INITIATED_SERVICE_MAINTENANCE 或其他預先定義的理由代碼。您的外部金鑰管理員就是讀理由單、決定要不要遞出金鑰的公證人。沒理由單，沒金鑰；理由不對，也沒金鑰。這就是為什麼瑞士銀行能自信地說「即使 Google 支援人員想看，也讀不到我們的資料」——因為公證人（您的 EKM）會直接拒絕為 GOOGLE_INITIATED_SERVICE_MAINTENANCE 蓋章。
比喻三：以臍帶相連的太空船
Cloud HSM 像一艘自帶維生系統的太空船——自給自足、低延遲、高可用性（Google 負責叢集運作）。Cloud EKM 則像一艘以臍帶纜線連接到您地面站的太空船。把纜線剪斷（撤銷 EKM 存取）後，太空船（您在 BigQuery、GCS、Compute Engine 中的加密資料）便無法呼吸——所有讀寫都會失敗。這對 Schrems II 與 ITAR 合規極為有力，但也代表您 EKM 的可用性直接決定了資料的可用性。臍帶要綁好：透過 Service Directory 走 VPC 連線勝過裸網際網路，多區域 EKM 部署也是底線。
Cloud HSM：基於硬體的安全性
Cloud HSM 是一項託管服務，允許您將加密金鑰託管在經過 FIPS 140-2 第 3 級 認證的硬體安全模組 (Hardware Security Module) 中。
Cloud HSM 的主要特性：
- 無需基礎架構管理： Google 管理 HSM 叢集，確保高可用性與自動擴展。
- FIPS 140-2 第 3 級： 此級別要求具備實體防篡改性以及基於身分的身份驗證。
- 整合性： 與支援 CMEK 的服務（如 Cloud Storage、BigQuery、Compute Engine）無縫協作。
- 區域與多區域： 您可以在特定區域建立 HSM 金鑰，以滿足資料駐留要求。
與軟體金鑰不同，Cloud HSM 金鑰確保加密素材絕不會以明文形式離開 HSM 邊界，即使在使用過程中也是如此。Cloud HSM 背後的 HSM 叢集通過 FIPS 140-2 Level 3 認證，要求具備實體防篡改證跡、基於身分的操作者驗證，以及在偵測到篡改時將明文金鑰歸零銷毀——這是純軟體金鑰（FIPS 140-2 Level 1/2）無法達到的標準。
PSE 考試 FIPS 140-2 等級速記： Level 1 = 基本軟體；Level 2 = 角色驗證 + 防篡改封條；Level 3 = 身分驗證 + 防篡改硬體（Cloud HSM）；Level 4 = 抗環境攻擊。情境提到「FIPS 140-2 Level 3」或「金鑰需植根於 Google 內部硬體」→ 答案是 Cloud KMS 搭配 HSM 保護層級。若再加上「金鑰必須留在 Google 之外」→ 升級為 Cloud EKM。
Cloud EKM：外部金鑰控制與主權
Cloud 外部金鑰管理員 (EKM) 允許您使用駐留在由您管理的外部系統（位於 Google 基礎架構之外）中的金鑰來保護 Google Cloud 中的資料。
為什麼使用 Cloud EKM？
- 資料主權： 您對金鑰保有實體控制權。
- 外部授權： 每當 Google Cloud 需要加密或解密資料時，必須向您的外部金鑰管理員請求許可。
- 切斷開關 (Kill Switch)： 如果您撤銷存取權限或關閉 EKM，Google Cloud 將無法再存取您加密的資料。
連線選項：
- 透過網際網路的 EKM： 通訊透過公用網際網路進行（由 TLS 加密）。
- 透過 VPC 的 EKM： 透過使用 Service Directory 的私有 VPC 連線進行通訊，提供較低的延遲並避免暴露於公用網際網路，從而提高安全性。
Cloud EKM 是一項服務，使 Google Cloud 能夠使用儲存在第三方外部金鑰管理系統（如 Thales、Fortanix）中的金鑰來保護靜態資料。
Cloud EKM 只能搭配 Google 認證的合作夥伴金鑰管理員：Fortanix Data Security Manager、Thales CipherTrust Manager、Equinix SmartKey，以及 Virtru。您無法把 Cloud EKM 指向任意一個 REST 端點——合作夥伴必須實作 EKM API 合約（包含 KAJ 理由驗證與 wrapped-DEK 協定）並通過 Google 認證。挑選合作夥伴時，請依據資料主權需求對應部署模式：Equinix SmartKey 適合在 Google PoP 旁的 colocation HSM；Fortanix／Thales 適合自有機房或自家 colo；Virtru 則偏向協作導向情境。
金鑰存取理由 (Key Access Justifications, KAJ)
金鑰存取理由 (KAJ) 是 Cloud EKM 的一項獨特功能，為每次金鑰請求提供「理由代碼」。
KAJ 的運作方式：
- 當 Google Cloud 服務（如 BigQuery）需要解密資料時，它會向您的 EKM 發送請求。
- 該請求包含一個理由 (Justification)（例如
CUSTOMER_INITIATED_ACCESS或GOOGLE_INITIATED_SERVICE_MAINTENANCE）。 - 您的 EKM 會根據您定義的策略評估此理由。
- 如果理由被拒絕，EKM 將拒絕提供金鑰素材，資料仍保持加密狀態。
KAJ 是實現管理隱私 (Administrative Privacy) 的終極工具。它允許您以程式化方式阻止 Google 人員存取您的資料（即使是為了支援或維護目的），除非您明確允許。
不要把「EKM over VPC」誤認為走您一般的 VPC peering。 Cloud EKM over VPC 需要把外部金鑰管理員（例如 Fortanix DSM、Thales CipherTrust、Equinix SmartKey）註冊為 Service Directory 端點，流量走 Google 託管的私有路徑——並非您一般的 VPC peering 或 Cloud Interconnect。另一個常見誤答：當情境說「金鑰絕不能駐留在雲端供應商的實體基礎架構中」，考生常選 Cloud HSM——但 Cloud HSM 金鑰仍位於 Google 經營的 HSM 內。只有 Cloud EKM 才能真正讓金鑰素材完全外部化。
保護層級比較
| 功能 | 軟體金鑰 (Software) | Cloud HSM | Cloud EKM |
|---|---|---|---|
| 儲存位置 | Google 軟體 | Google HSM | 您的外部 HSM |
| 合規性 | FIPS 140-2 L2 (內部) | FIPS 140-2 L3 | 取決於 EKM 供應商 |
| 控制權 | Google 管理 | Google 管理 | 客戶管理 |
| 延遲 | 最低 | 低 | 較高（取決於網路） |
| 可用性 | 最高 | 非常高 | 取決於您的 EKM |
管理外部金鑰的可用性與延遲
使用 EKM 會引入對外部基礎架構的依賴。
- 可用性： 如果您的 EKM 離線，使用這些金鑰的 Google Cloud 服務將會失敗。您必須確保您的 EKM 在多個區域具備高可用性。
- 延遲： Google Cloud 與您的 EKM 之間的往返時間會增加操作時間。建議使用 VPC 連線以最小化此影響。
監管要求與合規性
- ITAR/EAR： Cloud EKM 常被用於滿足美國出口管制要求。
- Schrems II / GDPR： 對於歐洲客戶，EKM 提供了一種機制，確保資料受到保護，免受外國政府的資料存取請求。
稽核 EKM 請求
可稽核性是 EKM 的核心組成部分。
- Cloud Audit Logs： Google 會記錄發送的請求以及對應的理由。
- EKM 記錄： 您的外部管理員會記錄收到請求的情況以及您的決定（允許/拒絕）。
- 比對： 您可以將 Google 的記錄與您的 EKM 記錄進行比對，以確保沒有未經授權的請求企圖。
合作夥伴整合
Google Cloud EKM 與業界領先的供應商整合：
- Thales (CipherTrust Manager)
- Fortanix (Data Security Manager)
- Equinix (SmartKey)
- Virtru
PSE 考試情境
情境 1：嚴格的監管合規性
「瑞士的一家銀行要求其加密金鑰絕不能駐留在雲端供應商的實體基礎架構中，且他們必須能夠以任何理由拒絕 Google 的存取。他們應該使用哪種解決方案？」 解答： 使用具備金鑰存取理由 (KAJ) 的 Cloud EKM。這確保金鑰位於外部，並對每次存取請求提供精細控制。
情境 2：FIPS 140-2 第 3 級要求
「一家政府機構要求所有靜態資料必須使用儲存在符合 FIPS 140-2 第 3 級要求的硬體模組中的金鑰進行加密。他們偏好 Google Cloud 內的完全託管解決方案，以最小化維運開銷。您應該推薦什麼？」 解答： 使用保護層級設定為硬體 (HSM) 的 Cloud KMS。
總結檢查表
- 區分 Cloud HSM 與 Cloud EKM 保護層級。
- 解釋金鑰存取理由 (KAJ) 在管理隱私中的作用。
- 描述 Cloud EKM 的兩種連線選項（網際網路 vs. VPC）。
- 列出與 EKM 相關的風險（延遲與可用性）。
- 識別與 Cloud HSM 關聯的 FIPS 級別。