Cloud Key Management Service 深入介紹

作者:Sonal Shah、Il-Sung Lee、Walter Poupore、Hunter Freyer、Honna Segel、Dwight Worley

感謝:Adrian Sears、John Randolph、Tim Dierks、Chris Rezek、Stanley McKenzie、Kevin Plybon、David Hale、Sergey Simakov、David U. Lee、Carrie McDaniel、Anton Chuvakin、Dave Tonisson

上次更新:2020 年 4 月

1. 簡介

Google Cloud 秉持的基本原則是,Google Cloud 客戶擁有自己的資料,且應自行控管資料的使用方式。

如果透過 Google Cloud 儲存資料,資料預設都會經過靜態加密。而當您使用 Google 的 Cloud Key Management Service (Cloud KMS) 平台時,更可進一步掌控靜態資料的加密方式,以及加密金鑰的管理方式。

Cloud KMS 平台可讓 Google Cloud 客戶透過集中式雲端服務管理加密編譯金鑰,以供直接使用,或者供其他雲端資源和應用程式使用。Cloud KMS 針對金鑰來源提供下列選項:

  • Cloud KMS 軟體後端可讓您在加密資料時,自由選擇要使用對稱式金鑰,或是由您單方控管的非對稱式金鑰 (Cloud KMS)。
  • 如果您需要硬體金鑰,則可以使用 Cloud HSM 來確保對稱式金鑰和非對稱式金鑰只會用在經過 FIPS 140-2 第 3 級驗證的硬體安全性模組 (HSM) 中。
  • Cloud KMS 可讓您匯入自己的加密編譯金鑰,在需要即可使用自己產生的金鑰。
  • 您可選擇將 Cloud KMS 產生的金鑰與其他 Google Cloud 服務搭配使用。這類金鑰又稱為「客戶自行管理的加密金鑰」(CMEK)。CMEK 功能可讓您產生、使用、輪替及刪除用於保護其他 Google Cloud 服務中資料的加密金鑰。
  • 有了 Cloud External Key Manager (Cloud EKM),您就可以在 Google Cloud 外的金鑰管理工具中建立和管理金鑰,然後設定 Cloud KMS 平台使用外部金鑰保護靜態資料。您可以將客戶自行管理的加密金鑰與 Cloud EKM 金鑰搭配使用。Cloud EKM 目前不在本白皮書的說明範圍內。

Google 也支援將客戶提供的加密金鑰 (CSEK) 用於 Compute Engine 和 Cloud Storage,其中資料是使用 API 呼叫提供的金鑰進行解密及加密。CSEK 不在本文的說明範圍內。詳情請參閱線上說明文件

「KMS 組合圖表」

Google 提供的 Cloud KMS 重點在於提供一個可擴充、可靠且高效能的解決方案,在簡單易用的平台上提供最廣泛的可控制選項。Cloud KMS 的設計有五大重點:

  • 客戶控管機制:Cloud KMS 可讓您管理軟體和硬體加密金鑰,或是自行提供金鑰。
  • 存取權控管與監控功能:有了 Cloud KMS,您就可以管理個別金鑰的權限,並監控金鑰使用狀況。
  • 區域性:Cloud KMS 提供立即可用的區域化服務。該服務設定為只會在您選取的 Google Cloud 區域中建立、儲存及處理軟體金鑰。
  • 耐用性:Cloud KMS 符合 Google Cloud 的最高耐用性標準。為協助防止資料損毀,以及確認資料可以成功解密,Cloud KMS 會定期掃描並備份所有金鑰內容和中繼資料。
  • 安全性:Cloud KMS 提供強大的保護措施,防止金鑰遭到未經授權的存取,並且已和身分與存取權管理 (IAM) 及 Cloud 稽核記錄控制方法完全整合。

本文將著重說明正式發行版 (GA) 中的 Cloud KMS 平台內部運作方式。這些選項可協助您保護存放在 Google Cloud 中的金鑰和其他機密資料。本文適用於需要 Cloud KMS 架構、基礎架構和功能詳細資料的技術決策者,並假設讀者對加密概念和雲端架構已有基本認識。

2. Google 的加密概念和金鑰管理原則

本節將根據 Google 的多層式金鑰管理基礎架構說明金鑰管理的一些詞彙和定義。

2.1. 金鑰、金鑰版本與金鑰環

本節將說明金鑰、金鑰版本,以及將金鑰分組為金鑰環的方式。下圖說明金鑰的分組方式,圖表之後有相關定義。

「金鑰分組圖表。」

  • 金鑰:一種具名物件,表示用於特定目的的加密編譯金鑰。金鑰內容是用於加密編譯作業的實際位元,可能會在建立新的金鑰版本時隨之變更。

    金鑰用途和金鑰的其他屬性是使用該金鑰來連結和進行管理的。因此,如要瞭解 KMS 使用情形,金鑰是最重要的物件。

    Cloud KMS 同時支援非對稱式金鑰和對稱式金鑰。對稱式金鑰用於對稱式加密以保護部分資料主體,例如在 GCM 模式下使用 AES-256 可加密一段明文。非對稱式金鑰可用於非對稱式加密或建立數位簽名。如需支援的用途和演算法相關說明,請參閱 Cloud KMS 說明文件。

  • 金鑰環:可將金鑰分組,方便使用者管理。金鑰環屬於 Google Cloud 專案,並且會存放在特定位置中。金鑰會繼承其父項金鑰環的 IAM 政策。將金鑰環中具有相關權限的金鑰分組,可讓您在金鑰環層級授予、撤銷及修改這些金鑰的權限,而不必單獨針對每個金鑰執行操作。金鑰環可提供便利性和分類功能,但如果金鑰環的分組功能對您沒有幫助,您可以直接針對金鑰管理權限。

    為了防止資源名稱衝突,請不要刪除金鑰環。金鑰環和金鑰不會收費,也沒有配額限制,因此如果持續存在,也不會對費用或實際工作環境限制造成任何影響。關於如何刪除金鑰和金鑰內容的詳情,請參閱本文稍後的刪除章節。

  • 金鑰中繼資料:資源名稱、KMS 資源的屬性 (例如 IAM 政策、金鑰類型、金鑰大小、金鑰狀態),以及衍生自上述項目的任何資料。金鑰中繼資料的管理方式可以和金鑰內容不同。

  • 金鑰版本:代表在某個時間點與金鑰相關的金鑰內容。金鑰版本是包含實際金鑰內容的資源。系統會從版本 1 開始,依序編號各個版本。金鑰輪替後,系統會建立含新金鑰內容的新金鑰版本。隨著時間的推移,同一個邏輯金鑰可能會有多個版本,因此限制了任何單一版本的使用。對稱式金鑰一律會有一個「主要版本」。根據預設,系統會將此版本用於加密。當 Cloud KMS 使用對稱式金鑰執行解密時,將會自動識別執行解密所需的金鑰版本。

2.2. 金鑰階層

下圖說明 Google 內部金鑰管理服務的金鑰階層。Cloud KMS 利用 Google 內部 KMS 的原因在於 Cloud KMS 加密金鑰是由 Google KMS 包裝的。Cloud KMS 使用與 Google KMS 相同的信任根。圖表之後有相關定義。

「內部金鑰階層的圖表」

  • 資料加密金鑰 (DEK):用來加密資料的金鑰。
  • 金鑰加密金鑰 (KEK)用來加密或「包裝」資料加密金鑰的金鑰。所有 Cloud KMS 平台選項 (軟體、硬體和外部後端) 都可讓您控管金鑰加密金鑰。
  • KMS 主金鑰:用來加密金鑰加密金鑰 (KEK) 的金鑰,會分散在記憶體中。KMS 主金鑰備份在硬體裝置上。這個金鑰負責加密您的金鑰。
  • 根 KMS:Google 的內部金鑰管理服務。

2.3. 作業

  • 專案:Cloud KMS 資源屬於 Google Cloud 專案,就像所有其他 Google Cloud 資源一樣。您可以將資料託管在與 Cloud KMS 金鑰所在專案不同的專案中。這項功能支援金鑰管理員與資料管理員之間的授權區隔最佳做法。
  • 位置:在專案中,系統會在單一位置建立 Cloud KMS 資源。詳情請參閱地理位置與區域一文。

3. Cloud KMS 平台總覽

Cloud KMS 平台支援多種加密編譯演算法,並提供許多方法,讓使用者可以透過硬體和軟體支援的金鑰來進行加密和數位簽署。Cloud KMS 平台整合了身分與存取權管理 (IAM) 和 Cloud 稽核記錄,因此您可以管理個別金鑰的權限,並稽核金鑰的使用狀況。

「Cloud KMS 架構圖。」

上圖顯示 Cloud KMS 平台的主要元件。管理員可以使用 Google Cloud Console 或 gcloud 指令列工具,或是透過實作 REST 或 gRPC API 的應用程式來存取金鑰管理服務。應用程式則可以使用 REST APIgRPC 來存取金鑰管理服務。應用程式可以運用已啟用使用客戶自行管理的加密金鑰 (CMEK) 的 Google 服務。接著 CMEK 會使用 Cloud KMS API。Cloud KMS API 可讓您使用軟體 (Cloud KMS) 或硬體 (Cloud HSM) 金鑰。軟體和硬體型金鑰都會利用 Google 的備援備份保護機制。

透過 Cloud KMS 平台,您可以在建立金鑰時選擇防護等級,以決定要由哪個金鑰後端建立金鑰,並對該金鑰執行所有未來的加密編譯作業。Cloud KMS 平台提供兩個後端 (不含 Cloud EKM),這些後端會在 Cloud KMS API 中顯示為 SOFTWAREHSM 防護等級。防護等級 SOFTWARE 適用於可由軟體安全性模組解除包裝以執行加密編譯作業的金鑰。防護等級 HSM 適用於只能由使用金鑰執行所有加密編譯作業的硬體安全性模組解除包裝的金鑰。

Google Cloud 支援將 CMEK 用於多項服務,包括 Cloud Storage、BigQuery 和 Compute Engine。CMEK 可讓您透過 Cloud KMS 平台來管理這些服務用來保護資料的加密金鑰。

Cloud KMS 加密編譯作業會由通過 FIPS 140-2 驗證的模組執行。防護等級為 SOFTWARE 的金鑰及用其執行的加密編譯作業均符合 FIPS 140-2 第 1 級的規範。防護等級為 HSM 的金鑰及用其執行的加密編譯作業均符合 FIPS 140-2 第 3 級的規範。

3.1. 環境和依附元件

本節將詳細說明 Cloud KMS 平台運作所在的 Google 基礎架構,以及該基礎架構使用的通訊協定。

3.1.1. Cloud KMS Borg 工作

Cloud KMS 平台元素會以實際工作環境 Borg 工作的形式運作。Borg 是 Google 的大規模叢集管理員,用於處理 API 服務工作與批次工作。如要進一步瞭解 Google 實體和實際工作環境基礎架構的安全性,請參閱 Google 基礎架構安全性設計總覽

3.1.1.1. Cloud KMS API 服務工作

Cloud KMS API 服務工作是實際工作環境 Borg 工作,可用來處理客戶管理及使用金鑰的要求。這些服務工作會在每個提供 Cloud KMS 的 Google Cloud 區域執行。每個工作都與單一區域相關聯,而且已設定為僅存取地理位置在相關聯 Google Cloud 區域內的系統資料。如要進一步瞭解金鑰落地,請參閱本文稍後的區域性一節。

3.1.1.2. Cloud KMS 批次工作

Cloud KMS 平台也會保留一些批次工作,並根據不同排程以實際工作環境 Borg 工作的形式執行。批次工作僅限特定區域,而且只會匯總相關聯的 Google Cloud 區域資料並在其中執行。這些工作執行的任務如下:

  • 計算適用於客戶帳單的有效金鑰。
  • 匯總 Cloud KMS 的公開通訊協定緩衝區 API 中的資源,並將中繼資料轉送至 Cloud Asset Inventory。在這種情況下,「資源」是指 Cloud KMS 管理的任何資源,例如金鑰和金鑰環。
  • 匯總所有資源與報表資訊,以進行業務分析。
  • 建立資料的快照以實現高可用性。
  • 驗證基礎資料儲存庫中儲存的所有資料均未損毀。
  • 在輪替 KMS 主金鑰時,重新加密客戶金鑰內容。
3.1.1.3. Cloud KMS 金鑰快照工具

為了維持高可用性,Cloud KMS 平台會在託管 Cloud KMS API 伺服器工作的共用服務的每個執行個體中,保留一個備援資料儲存庫。每項服務都會部署自己的快照工具服務執行個體。這種備援功能使得服務具有高度的獨立性,因此當一個可用區內發生故障時,對其他可用區的影響就很有限。當 Cloud KMS API 工作需要執行加密編譯作業時,將會同時查詢主要資料儲存庫和本機快照工具工作。然後,Cloud KMS API 會使用任何先成功完成要求的工作。為了避免建立快照的管道發生延遲,進而導致可能提供過度陳舊的資料,如果資料存在超過兩個小時,API 伺服器就不會使用快照工具工作產生的結果。系統會針對各區域持續執行的批次工作,建立快照做為輸出內容。那些快照位於與金鑰內容相關聯的雲端區域。

3.1.2. 用戶端與伺服器之間的通訊

Google 使用應用程式層傳輸安全性 (ALTS) 來確保使用 Google 遠端程序呼叫 (RPC) 機制的用戶端與伺服器之間的通訊安全性 (傳輸加密)。ALTS 提供以下項目:

  • 適用於應用程式的點對點驗證通訊協定
  • 記錄加密通訊協定
  • 公開經過驗證的使用者以取得授權的 API

ALTS 握手及記錄加密通訊協定與傳輸層安全標準 (TLS) 握手記錄通訊協定類似。ALTS 會做出不同取捨,以針對 Google 的實際工作環境進行最佳化;ALTS 也已全面整合至整個實際工作環境硬體和軟體堆疊中。詳情請參閱本文稍後的 Cloud KMS 平台作業環境一節。

4. Cloud KMS 平台架構詳細資料

本節將從金鑰內容的安全性資料儲存庫防護機制開始,逐步深入探討架構詳細資料,接著再詳細說明金鑰內容來源的選項:

本節也會說明客戶自行管理的加密金鑰 (CMEK) 選項。

為了針對到目前為止所介紹架構結構的使用方式提供動態檢視,本文將說明 Cloud KMS 要求的生命週期,包括有關刪除金鑰內容的討論。

4.1. 金鑰內容的安全性

在 Cloud KMS 中,無論金鑰內容處於靜態還是傳輸中,一律都會經過加密。只有在下列情況下才會將金鑰內容解密:

  • 在客戶使用金鑰內容時。
  • 在輪替用於保護客戶金鑰內容的 Google 內部金鑰或檢查其完整性時。

客戶對 Cloud KMS 的要求會透過在客戶與 Google Front End (GFE) 之間採用 TLS 來進行傳輸加密。先前在有關用戶端與伺服器之間的通訊的章節中說明的應用程式層傳輸安全性 (ALTS),會用於 Cloud KMS 工作與其在不同資料中心後端之間的加密。本文稍後的 Cloud KMS 要求的生命週期一節將會詳細說明 ALTS 和傳輸加密。

所有 KMS 工作之間都會進行驗證作業,無論是在 Google 資料中心內或是在資料中心之間。

Google 的政策旨在確保工作僅使用以可驗證的方式建構、測試和審查的原始碼。Borg 適用的二進位授權 (BAB) 會在作業層級強制執行這項政策,詳情請參閱這份安全性說明文件

Cloud KMS API 工作可以存取金鑰中繼資料 (例如 IAM 政策或輪替週期)。如果 Google 員工具備正當且有據可查的業務理由 (例如錯誤或客戶問題),也可以存取金鑰中繼資料。存取會在內部記錄,而符合資格的客戶也可以使用與資料存取透明化控管機制所涵蓋資料相關的記錄檔。

但是,Cloud KMS API 工作無法存取金鑰內容,使用者也無法透過 API 介面或其他使用者介面匯出或查看金鑰內容。Google 員工均無法存取未加密的客戶金鑰內容。系統會使用 Root KMS 中的主金鑰將金鑰內容另外加密,任何人都無法直接存取該金鑰。

4.2. 資料儲存庫防護機制

本節說明 Google KMS 如何保護金鑰資料。

4.2.1. 主金鑰

Cloud KMS 會使用主金鑰來包裝所有靜態客戶金鑰。每部 Cloud KMS 伺服器都會在啟動期間擷取一份主金鑰以產生硬相依性,而且每天會擷取一份新的主金鑰。系統會定期重新加密主金鑰。

4.2.2. 輪替政策

金鑰輪替是處理金鑰內容的公認最佳做法的一部分。用於保護 Cloud KMS 資料儲存庫的金鑰均會有輪替政策。金鑰輪替政策也適用於包裝 Cloud KMS 金鑰的 Google 內部 KMS 主金鑰。KMS 主金鑰排定的密文存在時間上限為 90 天,用戶端快取金鑰存在時間上限則為一天。Cloud KMS 每 24 小時會重新整理一次 KMS 工作中的主金鑰,而且每個月會將所有客戶金鑰重新加密一次。

4.2.3. 資料落地

每個 Cloud KMS 資料儲存庫的基礎資料只會保留在與該資料相關聯的 Google Cloud 區域內。這項規則也適用於多區域位置 (例如 us 多區域)。如要進一步瞭解資料落地,請參閱本文稍後的區域性一節。

4.3. 金鑰建立後的可用性

Cloud KMS 允許在 Cloud KMS 資料儲存庫修訂建立金鑰的交易,並在儲存層確認建立金鑰後,立即使用該金鑰。

4.4. Cloud KMS 軟體後端:「軟體」防護等級

防護等級 SOFTWARE 適用於在軟體中執行加密編譯作業的金鑰。本節會詳細說明這個等級的實作方式。

4.4.1. 演算法實作

針對軟體金鑰,Cloud KMS 會使用 Google BoringSSL 實作中的 BoringCryptoKey 模組 (BCM) 進行所有相關的加密編譯工作。BCM 已通過 FIPS 140-2 驗證。Cloud KMS 二進位檔是根據此模組通過 FIPS 140-2 第 1 級驗證的加密編譯基元為基礎建構的。這個模組涵蓋的最新演算法已列在 Google 的說明文件頁面中,其中包含使用 AES256-GCM 對稱式加密編譯金鑰以及 RSA 2048、RSA 3072、RSA 4096、EC P256 和 EC P384 非對稱式加密編譯金鑰進行的加密、解密和簽署作業。

4.4.2. 隨機號碼的產生方式和資訊熵

在產生加密金鑰時,Cloud KMS 會使用 BoringSSL。FIPS 140-2 要求使用自己的 PRNG (也稱為 DRBG)。在 BoringCrypto 中,Cloud KMS 只會使用 CTR-DRBG 搭配 AES-256。這樣做可為 RAND_bytes 提供輸出內容,而 RAND_bytes 是系統的其餘部分用來取得隨機資料的主要介面。這個 PRNG 出自於 Linux 核心的 RNG,後者則出自於多個獨立的資訊熵來源。這種來源關係包含資料中心環境內的資訊熵事件,例如磁碟搜尋與封包抵達間隔時間的精密計算結果,以及 Intel RDRAND 指令 (如有)。如要進一步瞭解 BoringSSL 的隨機號碼產生器行為 (符合 FIPS 規範的模式),請參閱 RNG 設計一節。

4.5. Cloud KMS HSM 後端:「硬體」防護等級

Cloud HSM 服務可為 Cloud KMS 提供硬體支援的金鑰,因此客戶能夠管理及使用受 Google 資料中心內全代管硬體安全性模組 (HSM) 保護的加密編譯金鑰。這項服務不但具備高可用性,而且可以水平自動調整資源配置。那些金鑰會透過加密編譯的方式,與定義金鑰環的 KMS 區域繫結在一起。使用 Cloud HSM 時,您建立和使用的金鑰無法在建立金鑰時指定區域所屬的 HSM 叢集之外具體化。您可以透過 Cloud HSM,以可驗證的方式證明加密編譯金鑰是僅在同一個硬體裝置內建立及使用的。現有的 Cloud KMS 客戶無須變更任何應用程式就能使用 Cloud HSM:使用與 Cloud KMS 軟體後端相同的 API 和用戶端程式庫即可存取 Cloud HSM 服務。

Cloud HSM 使用通過 FIPS 140-2 第 3 級驗證的 HSM,並且一律會在 FIPS 模式下運作。FIPS 標準會指定 HSM 使用的加密編譯演算法和隨機號碼的產生方式。

4.5.1. Cavium HSM

Cavium HSM PCIe 卡已經過供應商驗證符合 FIPS 140-2 第 3 級規範。目前的憑證可應要求提供。

4.5.2. HSM 金鑰階層

您可以在下圖的上半部看到 Cloud KMS。Cloud HSM 會包裝客戶金鑰,然後 Cloud KMS 會包裝傳送至 Google 資料儲存庫的 HSM 金鑰。

「HSM 金鑰階層圖表」

Cloud HSM 有一個金鑰 (未顯示) 可控制 Cloud HSM 管理網域中的內容遷移作業。一個區域可能有多個 HSM 管理網域。

HSM 根金鑰有兩個特性:

  1. 它是在 HSM 中產生的,而且在整個生命週期中都不會離開明確定義的 HSM 界限。您可以將它複製到其他 HSM 或備份 HSM 中。
  2. 它可以做為金鑰加密金鑰,以直接或間接包裝 HSM 使用的客戶金鑰。

由 HSM 根金鑰包裝的客戶金鑰可用在 HSM 中,不過 HSM 永遠不會傳回客戶金鑰的明文;HSM 只會使用客戶金鑰進行作業。

4.5.3. 資料儲存庫防護機制

系統不會將 HSM 做為金鑰的永久儲存空間;HSM 只有在使用期間才會儲存金鑰。由於 HSM 儲存空間受到限制,因此系統會將 HSM 金鑰加密並儲存在 Cloud KMS 金鑰資料儲存庫中。這個主題將於本文稍後的資料儲存庫後端一節詳細說明。

4.5.4. 輪替政策

Cloud HSM 的金鑰保護策略涉及了幾種類型的金鑰。客戶可輪替自己的金鑰,並利用 Cloud KMS 來輪替 HSM 金鑰。

4.5.5. 佈建和處理程序

HSM 的佈建作業會在配備許多實體和邏輯保護措施的研究室內進行,這些保護措施包括多方授權控管機制,以防止單一人員遭駭。

以下是 Cloud HSM 系統層級的不變情形:

  1. 使用者無法以明文的形式擷取客戶金鑰。
  2. 使用者無法將客戶金鑰移到原始區域之外。
  3. 對已佈建 HSM 所做的所有設定變更都會透過多種安全保護措施進行保護。
  4. 系統會記錄管理作業,並遵循 Cloud HSM 管理員和記錄管理員之間的授權區隔規定。
  5. HSM 的設計可防止在整個作業生命週期中遭到竄改 (例如透過插入惡意硬體或軟體修改,或是未經授權擷取密鑰)。

4.5.6. 供應商控管的韌體

HSM 韌體經過 HSM 供應商數位簽署,Google 無法建立或更新 HSM 韌體。供應商提供的所有韌體均經過簽署,包括用於測試的開發韌體。

4.5.7. 區域性

由於客戶金鑰已繫結至特定 HSM 根金鑰,因此系統會將其指派至特定地理區域。例如,專門在 us-west1 區域內建立的金鑰不能遷移至 us-east1 區域或 us 多區域。同樣地,在 us 多區域內建立的金鑰也不能遷入或遷出 us-west1 區域。

4.6. Cloud KMS:金鑰匯入

您可能會想要將自己的金鑰匯入雲端環境。例如,法規可能會要求用於加密雲端資料的金鑰必須以特定方式或是於特定環境中產生。Cloud KMS 可讓您匯入自己在內部部署系統或 External Key Manager 中建立的加密編譯金鑰。金鑰匯入功能可讓您匯入這些金鑰,並滿足這些法規義務。您也可以匯入非對稱式金鑰,以將簽署功能延伸至雲端環境。

在金鑰匯入過程中,Cloud KMS 會使用一種受支援的匯入方法來產生包裝金鑰,該金鑰屬於公開/私密金鑰組。使用這個包裝金鑰來加密金鑰內容,可以保護傳輸中的金鑰內容。

這個 Cloud KMS 公開包裝金鑰可用於在用戶端加密要匯入的金鑰。與這組公開金鑰配對的私密金鑰會儲存在 Google Cloud 中,並在該金鑰抵達 Google Cloud 專案後,用於將其解除包裝。您選擇的匯入方法會決定用於建立包裝金鑰的演算法。金鑰內容經過包裝後,您就可以將其匯入 Cloud KMS 中的新金鑰或金鑰版本。

匯入的金鑰可以和 HSMSOFTWARE 防護等級搭配使用。

就 Cloud HSM 而言,包裝金鑰的私密金鑰部分只能在 Cloud HSM 內使用。將私密金鑰部分限制為只能在 Cloud HSM 內使用,可避免 Google 在 Cloud HSM 以外的地方解除金鑰內容的包裝。

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

根據預設,Google Cloud 會將所有儲存的靜態客戶資料加密,並由 Google 管理用於加密的金鑰。針對某些 Google Cloud 產品,客戶可以改用 Cloud KMS 來管理用於加密的金鑰。CMEK 可用於軟體及硬體支援的金鑰。Cloud KMS 可讓客戶控管金鑰的許多層面 (例如建立、啟用/停用、輪替及刪除金鑰),以及管理這類金鑰適用的 IAM 權限。Cloud KMS 包含多個預先定義的 IAM 角色,這些角色具有特定的權限和限制,可授予特定使用者及服務帳戶,以強制執行建議的授權區隔。

下列主題詳細介紹了與支援 CMEK 的 Cloud KMS 平台整合的產品:

金鑰輪替對所用金鑰版本的影響取決於產品實作 CMEK 的方式。一般來說,輪替 Cloud KMS 金鑰並不會將相關聯的 CMEK 服務中的資料重新加密。例如,當與資料表相關聯的 Cloud KMS 金鑰輪替時,BigQuery 並不會自動輪替資料表加密金鑰。現有的 BigQuery 資料表會繼續使用資料表建立時所使用的金鑰版本。新的 BigQuery 資料表則會使用目前的金鑰版本。詳情請參閱各項產品的說明文件。

如需 CMEK 整合和符合 CMEK 規範服務的完整清單,請參閱這份說明文件。Google 會持續開發其他 Google Cloud 產品的 CMEK 整合功能。

4.8. Cloud KMS 要求的生命週期

為了針對到目前為止所介紹架構結構的使用方式提供動態檢視,本節將說明 Cloud KMS 要求的生命週期,包括有關刪除金鑰內容的討論。

「KMS 要求的生命週期圖表」

這個生命週期中的步驟包括:

  1. 客戶或代表客戶執行的工作撰寫對 Cloud KMS 服務 (https://cloudkms.googleapis.com) 的要求。DNS 將這個位址解析為 Google Front End (GFE) 的 Anycast IP 位址。
  2. GFE 提供其公開 DNS 名稱的公開 IP 託管、阻斷服務 (DoS) 保護,以及 TLS 終止功能。當客戶傳送要求時,無論客戶要求的目標位置為何,系統通常都會將其轉送至客戶附近的 GFE。GFE 會處理 TLS 交涉,並使用要求網址和參數決定要由哪個全球軟體負載平衡器 (GSLB) 轉送該要求。
  3. 每個 Cloud KMS 區域都有個別的 GSLB 目標。如果要求抵達位於 us-east1 的 Google 資料中心,而要求的目的地為 us-west1,系統將會在 us-east1us-west1 資料中心之間轉送該要求。資料中心之間的所有通訊都會使用 ALTS 進行傳輸加密,而 ALTS 會對 GFE 和 Cloud KMS 工作進行雙向驗證。
  4. 當要求抵達 Cloud KMS 工作時,會先由負責處理所有 Google Cloud 服務大部分共同工作的架構進行處理。這個架構會驗證使用者,並執行多項檢查,以驗證下列事項:
    • 客戶擁有有效的憑證,且可供驗證。
    • Google Cloud 專案已啟用 Cloud KMS API,並擁有有效的帳單帳戶。
    • 配額足以執行要求。
    • 客戶列於可使用相關 Google Cloud 區域的許可清單中。
    • VPC Service Controls 不會拒絕該要求。
  5. 通過這些檢查後,該架構便會將要求與憑證轉送至 Cloud KMS。Cloud KMS 會剖析要求,以判斷使用者正在存取的資源,然後向 IAM 確認,以瞭解呼叫者是否有權發出要求。IAM 也會告知 Cloud KMS 是否應將該要求例項寫入稽核記錄。
  6. 當該要求經過驗證和授權後,Cloud KMS 就會呼叫同區域的資料儲存庫後端,以擷取所要求的資源。擷取後,系統就會將客戶金鑰內容解密以供使用。
  7. 取得金鑰內容後,Cloud KMS 即會執行加密編譯作業,並根據該金鑰的防護等級,將金鑰的包裝版本轉送至 Cloud KMS 軟體後端或 Cloud HSM。
  8. 加密編譯作業完成後,系統即會沿著與要求相同類型的 GFE 至 KMS 管道,將回應傳回給客戶。
  9. 傳回回應後,Cloud KMS 也會以非同步方式觸發一些事件:
    • 填寫稽核記錄和要求記錄檔,並排入佇列等待寫入。
    • 傳送報表以進行計費和配額管理。
    • 如果要求更新了資源的中繼資料,系統將會透過批次工作更新將變更傳送至 Cloud Asset Inventory

4.9. 刪除金鑰內容

有關如何刪除 Google Cloud 中的資料,請參閱這本白皮書。系統會將金鑰內容視為客戶資料,因此白皮書說明的方法適用於 Cloud KMS。此外,由於 Google 絕不會在 Cloud KMS 之外共用金鑰內容,因此當 24 小時的待刪除期間結束且備份已到期時,將會根據要求刪除金鑰內容。此程序並不保證適用於在 Cloud KMS 控管範圍之外的匯入金鑰副本。

雖然金鑰內容可以如上所述進行刪除,金鑰和金鑰環則無法刪除。金鑰版本也不得刪除,但金鑰版本內容可以刪除,這樣就無法再使用這些資源。金鑰環和金鑰不會收費,也沒有配額限制,因此如果持續存在,也不會對費用或實際工作環境限制造成任何影響。

排定刪除作業後,金鑰版本即無法用於加密編譯作業。使用者可以在 24 小時的期間內還原金鑰版本,使其不會遭到刪除。

5. Cloud KMS 平台作業環境

Cloud KMS 平台的作業環境包括資料儲存與安全性政策、存取限制和風險控管策略,這些策略可在保護金鑰內容的同時,達到最高的可靠性、耐用性和可用性。本節將探討該服務的作業結構、營運團隊成員的責任、驗證機制,以及稽核與記錄通訊協定。後續討論適用於軟體及硬體支援的金鑰功能。

5.1. 軟體工程師、網站穩定性工程師和系統操作人員

軟體工程師負責與相關人員 (例如產品經理或網站穩定性工程師 (SRE)) 合作來共同設計系統,最終為 Cloud KMS 服務撰寫許多程式碼並進行測試。程式碼包含處理客戶要求的主要工作,以及用於執行資料複製和計費等活動的次要工作。SRE 可能也會撰寫程式碼。不過軟體工程師和 SRE 的職責是各自獨立的;SRE 主要負責維護 Cloud KMS 工作的實際工作環境。SRE 會透過工程和作業成果衡量並實現可靠性。

系統操作人員則負責 Cloud KMS 的建構與發布程序、監控、發出快訊和容量規劃等工作。他們是 Cloud KMS 客戶問題和服務中斷的第一線緊急事件處理人員。舉例來說,系統操作人員可透過工具和自動化作業來盡量減少人工系統的工作,以專注於可創造長期價值的工作上。

5.2. Cloud KMS 資源的區域性

您可以在下列四種類型的 Google Cloud 位置其中之一建立 Cloud KMS 資源:

  • 單一區域位置:「單一區域位置」所包含的可用區位於某個特定地理位置,例如愛荷華州。
  • 雙區域位置:「雙區域位置」所包含的可用區位於兩個特定地理位置,例如愛荷華州與南卡羅來納州。
  • 多區域位置:「多區域位置」所包含的可用區橫跨一個總體地理範圍,例如美國。
  • 全球位置:「全球位置」所包含的可用區分布在世界各地。當您在全球位置建立 Cloud KMS 資源時,即可在世界各地的可用區使用那些資源。

位置代表對 Cloud KMS 發出的特定資源要求會在哪些地理區域處理,以及相對應的加密編譯金鑰會儲存在哪些地理區域。

如要進一步瞭解可用的 Cloud KMS 位置,請參閱 Cloud KMS 說明文件

5.2.1. Cloud 區域與資料中心

Google Cloud 區域包含一間特定的資料中心或一組指定的資料中心,具體取決於指定的是單一區域、雙區域、多區域或全球位置。如要進一步瞭解 Google Cloud 區域,請參閱 Google Cloud 據點一文。

每間資料中心都包含許多機器,用於運算、網路或儲存資料。這些機器會執行 Google 的 Borg 基礎架構。

Google 資料中心設有嚴格的實體安全性要求。任何可能包含使用者資料的實體空間入口通道都必須設置識別證讀取器和/或虹膜掃描器,以用於驗證進入的人員。大門不會敞開以供多人進出;每個人都必須分別進行驗證。任何提袋都不得攜進或攜出這些區域,除非是經過保全人員檢查後明確授權的透明提袋。如要攜進或攜出任何可能傳輸或記錄資料的電子裝置,都必須取得特殊權限。

5.2.2. 區域性

有些產業會要求將加密編譯金鑰存放在特定位置。如上面 Cloud KMS 資源的區域性一節中所述,Cloud KMS 提供四種類型的區域位置來協助您滿足這些要求。

對於單一區域、雙區域或多區域位置,Cloud KMS 只會在該位置建立、儲存及處理您的客戶軟體和硬體支援的金鑰與金鑰內容。Cloud KMS 使用的儲存與資料處理系統已設定為僅使用與金鑰內容相關聯的 Google Cloud 區域內的資源。在雙區域或多區域位置建立的金鑰內容都不會離開所選位置的界限。

對於全球區域,則沒有指定區域性保證。

Cloud KMS 無法保證金鑰中繼資料、使用記錄檔或傳輸中金鑰內容的落地。金鑰中繼資料包括資源名稱;Cloud KMS 資源的屬性,例如金鑰類型、金鑰大小和金鑰狀態;IAM 政策;以及衍生自中繼資料的任何資料。

使用 CMEK 時,無論您在要與 CMEK 搭配使用的其他 Google Cloud 產品中選擇的是自訂區域、雙區域或多區域位置,下列 Cloud KMS 地理限制都適用於您的金鑰:

  • 特定區域:由於客戶自行管理 KMS 金鑰的區域一律必須與其在特定 Google Cloud 服務中保護資源的區域相關聯,因此可以保證單一區域金鑰和資源的落地限制是相容並強制執行的。
  • 雙區域或多區域位置:使用者可為其金鑰和 Google Cloud 資源選擇相關聯的 Google 定義多區域,以保證符合落地規定。如要確保達成這項地理落地規定,請確定您在其他產品中的區域與您所選的 Cloud KMS 區域位置一致。

下表大致列出 Cloud KMS 金鑰內容的落地。

Cloud KMS 資料落地 靜態、使用中
(單一區域)
靜態、使用中
(雙區域/多區域)
軟體金鑰內容 常駐 常駐在構成雙區域/多區域的區域中。
硬體金鑰內容 (HSM) 常駐 常駐在構成雙區域/多區域的區域中。

5.2.3. 區域性監控

Google 的內部資料監控服務會主動監控金鑰落地情形。如果 Cloud KMS 偵測到不慎設定錯誤的情形,或是金鑰內容離開已設定區域的界限、儲存在錯誤的區域,或者從錯誤的區域存取,它就會傳送快訊給 SRE 團隊成員。

5.3. 驗證及授權

Cloud KMS 接受多種驗證機制,例如 OAuth2、JWT 和 ALTS。無論採用哪種機制,Cloud KMS 都會解析所提供的憑證來識別主體 (已通過驗證且正在授權要求的實體),並呼叫 IAM 以瞭解該主體是否有權發出要求,以及是否已寫入稽核記錄。

Cloud KMS 會使用公開 Service Control API 的內部版本來管理服務的許多方面。在 Cloud KMS 工作處理要求之前,它會先傳送檢查要求至 Service Control API,如此將會強制執行所有 Google Cloud 服務共用的許多控管機制,例如:

  • 確認客戶是否已啟用 Cloud KMS API,並具備有效的帳單帳戶。
  • 確認客戶是否未超過其配額,並報告配額用量。
  • 強制執行 VPC Service Controls
  • 確認客戶是否列在適用私人雲端區域的許可清單中。

5.4. 記錄

有三種類型的記錄檔與 Cloud KMS 相關聯:Cloud 稽核記錄的記錄檔、資料存取透明化控管機制記錄檔和內部要求記錄檔。

5.4.1. Cloud 稽核記錄

Cloud KMS 會在 Cloud 稽核記錄的記錄檔中記錄客戶活動。客戶可以在 Cloud Console 中查看這些記錄檔。所有管理員活動 (例如建立或刪除金鑰) 都會記錄在這些記錄檔中。客戶也可以選擇為使用金鑰的所有其他動作 (例如使用金鑰來加密或解密資料) 啟用記錄功能。客戶可以控管記錄檔的保留期間,以及有權查看記錄檔的人員。

5.4.2. 資料存取透明化控管機制記錄檔

符合資格的客戶可以選擇啟用資料存取透明化控管機制記錄檔,那些記錄檔可為客戶提供 Google 員工在您的 Google Cloud 機構中所採取動作的記錄。資料存取透明化控管機制記錄檔,以及 Cloud 稽核記錄的記錄檔,都可協助您瞭解從事活動的人員、內容、地點及時間。

您可以將資料存取透明化控管機制記錄檔與現有的安全性資訊和事件管理 (SIEM) 工具整合,來自動化這些動作的稽核程序。這些記錄檔會在 Cloud Console 中與您的 Cloud 稽核記錄的記錄檔一起提供。

資料存取透明化控管機制記錄項目包含下列類型的詳細資訊:

  • 受影響的資源與動作。
  • 動作的時間。
  • 動作的原因。原因的範例包括客戶發起的客服要求 (包括客服案件編號)、Google 發起的客服要求、第三方資料要求,以及 Google 發起的審查要求。
  • 處理資料的人員相關資料 (例如,Google 工作人員的位置)。

5.4.3. 內部要求記錄檔

要求記錄檔會為傳送至 Cloud KMS 平台的每個要求儲存一筆記錄。此記錄包含有關要求類型 (例如 API 方法或通訊協定),以及正在存取的資源 (例如資源名稱、金鑰演算法或金鑰防護等級) 的詳細資料。這些記錄檔不會儲存客戶明文、密文或金鑰內容。在將新類型的資料加入這些記錄檔之前,專門負責隱私權審查的團隊必須先核准對已記錄資料所做的變更。

當設定的存留時間 (TTL) 過期之後,系統就會將記錄項目永久刪除。

值班待命輪替中的 Cloud KMS SRE 和工程師均可存取要求記錄檔。人工存取記錄檔和任何會傳回客戶資料的存取動作,都需要具備正當且有據可查的業務理由。除了某些特定的例外狀況外,系統都會記錄人工存取動作,而符合資格的客戶可以在資料存取透明化控管機制記錄檔中存取這些記錄。

5.5. 資料儲存庫後端

Cloud KMS 的資料儲存庫不但具備高可用性和耐用性,而且還受到嚴格的保護。

可用性:Cloud KMS 使用 Google 的內部資料儲存庫,該儲存庫不但具備高可用性,還支援 Google 的許多重要系統。

耐用性:Cloud KMS 會使用經過驗證的加密功能,將客戶金鑰內容儲存在資料儲存庫中。此外,所有中繼資料都會使用雜湊式訊息驗證碼 (HMAC) 進行驗證,以確保該資料未在靜態狀況下遭到修改或損毀。批次工作每小時會掃描一次所有金鑰內容和中繼資料,並驗證 HMAC 是否有效,以及金鑰內容是否可以成功解密。如果有任何資料毀損,Cloud KMS 工程師會立即收到快訊,以便他們採取行動。

Cloud KMS 會針對資料儲存庫進行以下幾種類型的備份作業:

  • 根據預設,資料儲存庫會將每個資料列的變更記錄保留幾個小時。在緊急情況下,這個生命週期可以延長,以提供更多時間來修正問題。
  • 資料儲存庫每小時會記錄一次快照。如有需要,使用者可以驗證快照並將其用於還原作業。這些快照會保留四天。
  • 系統每天都會將完整備份複製到磁碟和磁帶中。

Cloud KMS 團隊已記錄了在緊急情況下還原備份的程序。

落地:Cloud KMS 資料儲存庫備份會存放在其相關聯的 Google Cloud 區域中。這些備份全都已經過靜態加密。系統會根據存取事由 (例如您向 Google 支援小組提交的票證號碼) 限制對備份資料的存取,而且人工存取動作也會記錄在資料存取透明化控管機制記錄檔中。

防護措施:在 Cloud KMS 應用程式層,客戶金鑰內容會在儲存之前先經過加密。資料儲存庫工程師無法存取明文的客戶金鑰內容。此外,資料儲存庫會在將其管理的所有資料寫入永久儲存空間之前先進行加密,因此如果沒有資料儲存庫加密金鑰 (儲存在 Google 的內部 KMS 中) 的存取權,在存取基礎儲存層 (包括磁碟或磁帶) 時,將不允許存取已加密的 Cloud KMS 資料。

6. 延伸閱讀

如要進一步瞭解,請參閱下列資源:

白皮書:

其他說明文件: