Cloud Key Management Service 加密

本文上次更新於 2025 年 1 月，內容反映截至撰文時的情況。我們會持續改善保護客戶的方式，因此 Google 的安全性政策和系統未來可能會改變。

本文說明 Cloud Key Management Service (Cloud KMS) 如何在 Google Cloud 中提供靜態資料加密的金鑰管理服務。Google Cloud 秉持的基本原則是， Google Cloud 客戶擁有自己的資料，且應自行控管資料的使用方式。

如果透過 Google Cloud儲存資料，資料預設都會經過靜態加密。使用 Cloud KMS 平台時，您可以進一步控管靜態資料的加密方式，以及加密金鑰的管理方式。

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

「 Google Cloud」中的金鑰

下表說明 Google Cloud中的不同類型金鑰。

驗證碼類型 Cloud KMS Autokey Cloud KMS 客戶管理 (手動) Google-owned and Google-managed encryption key (Google 預設加密機制)

可查看重要中繼資料

是

是

否

金鑰擁有權1

客戶

客戶

Google

可管理2及控管3金鑰

系統會自動建立及指派金鑰。完全支援客戶手動控制。

客戶，僅限手動控制

Google

支援客戶管理金鑰的法規要求

是

是

否

車鑰共用

客戶專屬

客戶專屬

多位客戶的資料通常會受到共用金鑰加密金鑰 (KEK) 保護。

金鑰輪替控制項

是

是

否

CMEK 機構政策

是

是

 否

記錄加密金鑰的管理和資料存取權

是

是

否

透過加密進行邏輯資料分離

是

是

否

定價

多樣性

 多樣性

免費

1 金鑰擁有者：表示金鑰的權利持有人。您擁有的金鑰存取權受到嚴格限制，或 Google 無法存取。

2 金鑰管理包括下列工作：

  • 建立金鑰。
  • 選擇金鑰的保護等級。
  • 指派金鑰管理權限。
  • 控管金鑰存取權。
  • 控管金鑰的使用權限。
  • 設定及修改金鑰的輪替週期，或觸發金鑰輪替。
  • 變更金鑰狀態。
  • 刪除金鑰版本。

3 控管按鍵是指設定按鍵類型和使用方式的控制項、偵測差異，以及視需要規劃修正措施。您可以控管金鑰，但將金鑰管理權委派給第三方。

Cloud KMS 原則

Google 提供的 Cloud KMS 重點在於提供一個可擴充、可靠且高效能的解決方案，並提供最廣泛的可控制選項。Cloud KMS 遵循下列原則：

  • 客戶控管：Cloud KMS 可讓您控管自己的軟體和硬體金鑰，用於加密和簽署。這個支柱包括支援自備金鑰 (BYOK) 和自持金鑰 (HYOK)。
  • 存取權控管和監控：有了 Cloud KMS，您就可以管理個別金鑰的權限，並監控金鑰使用狀況。
  • 區域性：Cloud KMS 提供立即可用的區域化服務。該服務設定為只會在您選取的 Google Cloud 位置建立、儲存及處理金鑰。
  • 備份：為協助防止資料損毀，以及確認資料可以成功解密，Cloud KMS 會定期掃描並備份所有金鑰內容和中繼資料。
  • 安全性：Cloud KMS 提供強大的保護措施，防止金鑰遭到未經授權的存取，並且已和身分與存取權管理 (IAM) 及 Cloud 稽核記錄控制方法完全整合。
  • 邏輯資料分離：Cloud KMS 加密功能可透過加密提供邏輯資料分離。邏輯資料分隔是指資料擁有者不會共用加密金鑰 (KEK 和 DEK)。

加密金鑰的來源和管理選項

Cloud KMS 平台可讓您透過集中式雲端服務管理加密編譯金鑰，以供直接使用，或者供其他雲端資源和應用程式使用。

金鑰的 Google Cloud 組合包括：

  • 預設加密：Google 儲存的所有資料都會在儲存層使用進階加密標準 (AES) 演算法 (AES-256) 加密。我們會產生及管理預設加密金鑰，客戶無法存取金鑰，也無法控制金鑰輪替和管理作業。預設加密金鑰可能會由多位客戶共用。詳情請參閱預設靜態加密。

  • Cloud KMS 搭配軟體保護金鑰：您可以控管在 Cloud KMS 中產生的金鑰。Cloud KMS 軟體後端可讓您在加密或簽署資料時，自由選擇要使用對稱式金鑰，或是由您單方控管的非對稱式金鑰。

  • 使用硬體保護金鑰的 Cloud KMS (Cloud HSM)： 使用 Cloud KMS 和 Cloud HSM 後端，您可以擁有在 Google 自有及營運的硬體安全性模組 (HSM) 中產生和儲存的金鑰。如果您需要受硬體保護的金鑰，可以使用 Cloud HSM 後端來確保金鑰只會用在經過 FIPS 140-2 第 3 級驗證的 HSM 中。您可以透過手動方式佈建硬體保護金鑰，這需要 Cloud KMS 管理員，也可以使用 Cloud KMS Autokey 自動佈建。Autokey 可自動執行客戶自行管理的加密金鑰 (CMEK) 的金鑰佈建和指派程序。傳統 HSM 金鑰需要 KMS 管理員應要求建立金鑰。

  • Cloud KMS 搭配金鑰匯入功能：如要符合 BYOK 規定，您可以匯入自己產生的加密編譯金鑰。您可以在Google Cloud外部使用及管理這些金鑰，並在 Cloud KMS 中使用金鑰內容，加密或簽署您儲存在 Google Cloud中的資料。

  • 搭配外部金鑰管理員的 Cloud KMS (Cloud EKM)： 如要符合 HYOK 規定，您可以建立及控管儲存在 Google Cloud外部金鑰管理員中的金鑰。接著，設定 Cloud KMS 平台，使用外部金鑰保護靜態資料。您可以將這些加密金鑰與 Cloud EKM 金鑰搭配使用。如要進一步瞭解外部金鑰管理和 Cloud EKM，請參閱 Cloud EKM 參考架構。

您可以選擇將 Cloud KMS 產生的金鑰與其他Google Cloud 服務搭配使用。這類金鑰又稱為「CMEK」。CMEK 功能可讓您產生、使用、輪替及刪除用於保護其他 Google Cloud服務中資料的加密金鑰。搭配 Google Cloud 服務使用 CMEK 時，系統會為您管理金鑰存取權和追蹤作業。

Google 的加密和金鑰管理

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

金鑰環、金鑰和金鑰版本

下圖說明金鑰的分組方式，並顯示金鑰環，以及具有單一主要版本和多個先前版本的金鑰。

金鑰分組圖表。

上圖顯示的概念如下：

  • 金鑰：一種具名物件，表示用於特定目的的加密編譯金鑰。金鑰內容是用於加密編譯作業的實際位元，可能會在建立新的金鑰版本時隨之變更。您可以在資源階層中，於金鑰層級指派 IAM 允許政策。

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

    Cloud KMS 同時支援非對稱式金鑰和對稱式金鑰。對稱式金鑰用於建立或驗證 MAC 簽章，或用於對稱式加密以保護部分資料主體。舉例來說，您可以在 GCM 模式下使用 AES-256 加密一段明文。非對稱金鑰可用於非對稱加密或非對稱簽署。詳情請參閱「支援的用途和演算法」。

  • 金鑰環：可將金鑰分組，方便使用者管理。金鑰環屬於 Google Cloud 專案，並且會存放在特定位置中。金鑰會繼承金鑰環的允許政策。將金鑰環中具有相關權限的金鑰分組，可讓您在金鑰環層級授予、撤銷及修改這些金鑰的權限，而不必單獨針對每個金鑰執行操作。金鑰環可提供便利性和分類功能，但如果金鑰環的分組功能對您沒有幫助，您可以直接針對金鑰管理權限。標記可讓您根據資源是否具備特定標記，有條件地允許或拒絕政策。您可以在資源階層的鑰匙圈層級套用標記。

    為防止資源名稱衝突，您無法刪除金鑰環或金鑰。金鑰環和金鑰不會收費，也沒有配額限制，因此如果持續存在，也不會對費用或實際工作環境限制造成任何影響。

  • 金鑰中繼資料：資源名稱、KMS 資源的屬性 (例如允許政策、金鑰類型、金鑰大小、金鑰狀態)，以及衍生自金鑰和金鑰環的任何資料。

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

金鑰階層

下圖說明 Cloud KMS 和 Google 內部 Keystore 的金鑰階層和信封加密。「信封式加密」就是為了要能夠安全地儲存金鑰，或是透過不受信任的管道傳送金鑰，因而利用另一個金鑰來為該金鑰加密的程序。本圖中的所有金鑰都是對稱金鑰。

內部金鑰階層圖。

在金鑰階層中，資料加密金鑰 (DEK) 會加密資料區塊。金鑰加密金鑰 (KEK) 用於加密或「包裝」 DEK。所有 Cloud KMS 平台選項 (軟體、硬體和外部後端) 都可讓您控管 KEK。KEK 儲存在 Cloud KMS 中。金鑰內容絕不會離開 Cloud KMS 系統邊界。

如果是軟體保護的金鑰，則會由特定位置的 KMS 主金鑰加密 KEK。KMS 主金鑰儲存在 Keystore 中。Keystore 中每個 Cloud KMS 位置都有個別的 KMS 主金鑰。每部 Cloud KMS 伺服器都會在啟動期間擷取一份 KMS 主金鑰以產生硬相依性，而且每天會擷取一份新的 KMS 主金鑰。系統會定期使用 Keystore 中的 Keystore 主金鑰，重新加密 KMS 主金鑰。Keystore 主金鑰受到根 Keystore 主金鑰保護。

如果是受硬體保護的金鑰，系統會使用特定位置的 HSM 包裝金鑰加密 KEK，然後使用 KMS 主金鑰加密 HSM 包裝金鑰。詳情請參閱建立金鑰。如果是外部金鑰，EKM 包裝金鑰會加密包裝的 DEK，然後以 KMS 主金鑰加密 EKM 包裝金鑰。

Cloud KMS 會使用 Keystore (Google 內部金鑰管理服務) 包裝 Cloud KMS 加密金鑰。Cloud KMS 使用與 Keystore 相同的信任根。如要進一步瞭解 Keystore，請參閱靜態資料加密文章中的「金鑰管理」一節。

營運限制

Cloud KMS 的運作方式受下列限制：

  • 專案：Cloud KMS 資源屬於 Google Cloud專案，就像所有其他 Google Cloud資源一樣。Cloud KMS 金鑰可與金鑰保護的資料位於不同專案。如果金鑰與資源保護的資料位於同一個專案，您可以從專案中移除擁有者角色，以支援金鑰管理員與資料管理員之間的授權區隔最佳做法。
  • 位置：在專案中，系統會在單一位置建立 Cloud KMS 資源。如要進一步瞭解位置，請參閱地理位置與地區。
  • 一致性：Cloud KMS 會使用強一致性或最終一致性，傳播金鑰、金鑰環和金鑰版本的作業。詳情請參閱 Cloud KMS 資源一致性。

客戶管理的加密金鑰

根據預設， Google Cloud 會將所有儲存的靜態客戶資料加密，並由 Google 管理用於加密的金鑰。對於會持續儲存客戶內容的相容 Google Cloud產品 (例如 Cloud Storage)，您可以改用 Cloud KMS 管理客戶自行管理的加密金鑰 (CMEK)。CMEK 是您擁有的加密金鑰，可搭配外部金鑰、軟體保護的金鑰和硬體保護的金鑰使用。

CMEK 可讓您進一步控管用於加密相容 Google Cloud 服務中靜態資料的金鑰，並為資料提供加密範圍。您可以直接在 Cloud KMS 中管理 CMEK，也可以使用 Autokey 自動佈建及指派 CMEK。服務使用 CMEK 時，工作負載存取資源的方式與僅使用預設加密時相同。

Cloud KMS 可讓您控管金鑰的許多層面 (例如建立、啟用、停用、輪替及刪除金鑰)，以及管理這類金鑰適用的 IAM 權限。為強制執行建議的職責分離措施，Cloud KMS 包含多個預先定義的 IAM 角色，這些角色具有特定的權限和限制，可授予特定使用者及服務帳戶。

由於 Cloud KMS 使用信封式加密，CMEK 是用來加密 DEK 的 KEK。詳情請參閱「金鑰階層」。

CMEK 輪替的運作方式取決於金鑰保護的資源類型。請見以下範例：

  • 在 Spanner 中，新金鑰版本會重新加密 DEK。
  • 如果是其他資源類型 (例如 Cloud Storage 值區)，只有新建立的資源會使用新版金鑰加密，也就是說，不同版本的金鑰會保護不同的資料子集。
  • 在某些情況下，您必須使用新金鑰版本重新建立雲端資源。舉例來說，當與資料表相關聯的 Cloud KMS 金鑰輪替時，BigQuery 預設不會自動輪替資料表加密金鑰。現有的 BigQuery 資料表會繼續使用資料表建立時所使用的金鑰版本。

如要進一步瞭解金鑰輪替，請參閱各項產品的說明文件。

CMEK 組織政策可讓您進一步控管專案中 CMEK 的使用方式。您可以透過這些政策，控管允許使用 CMEK 的金鑰所屬的服務和專案，以及金鑰的保護等級。

Google Cloud 支援將 CMEK 用於多項服務，包括 Cloud Storage、BigQuery 和 Compute Engine。如需 CMEK 整合和符合 CMEK 規範服務的完整清單，請參閱「CMEK 整合」。Google 會持續開發其他 Google Cloud 產品的 CMEK 整合功能。

Cloud KMS Autokey

Autokey 可簡化 CMEK 佈建程序。在手動佈建 CMEK 的過程中，Cloud KMS 管理員必須事先規劃金鑰環、金鑰和服務帳戶的類型，並與開發人員協調佈建金鑰。使用 Autokey 時，Cloud KMS 管理員會將權限委派給專案中的 Cloud KMS 服務代理。啟用 Autokey 後，開發人員可以向 Cloud KMS 要求金鑰，服務代理程式會根據開發人員的意圖提供適當的金鑰。Autokey 可視需要提供金鑰，且金鑰一致性高，並遵循業界標準做法。

開發人員建立雲端資源時，Autokey 會視需要佈建及指派金鑰環、金鑰和服務帳戶，同時遵守職責分離原則。金鑰佈建和指派作業遵循資料安全性的業界標準做法和建議，包括：

  • HSM 防護等級：使用 Autokey 建立的金鑰一律為 HSM 金鑰，因此會儲存在 Cloud HSM 後端。這些是 AES-256 GCM 加密金鑰。
  • 職責分離：為維持職責分離，可使用金鑰加密及解密的 ID，與管理金鑰 (包括輪替、銷毀或狀態變更) 的 ID 不同。
  • 金鑰輪替：金鑰每年都會輪替。
  • 金鑰與資源共用位置：金鑰與受保護的資源位於相同位置。
  • 金鑰專一性：金鑰的專一性適合金鑰保護的資源類型 (以資源類型為準)。具體性是指您不必手動審查各項服務的資源類型，也不必決定單一金鑰應保護多少資源類型。

使用 Autokey 要求的金鑰，與設定相同的其他 Cloud HSM 金鑰運作方式相同。Autokey 可簡化 Terraform 用法，因為您不必以提升的金鑰建立權限執行基礎架構即程式碼。Autokey 適用於所有Google Cloud 提供 Cloud HSM 的地區。

Autokey 僅適用於特定 Google Cloud 資源。詳情請參閱「Autokey 總覽」。

Cloud KMS 平台架構和元件

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

Cloud KMS 架構圖。

上圖顯示 Cloud KMS 平台的主要元件，包括：

  • 管理員可以使用 Cloud 控制台或 Google Cloud CLI 存取金鑰管理服務。

  • 應用程式可以實作 REST API、gRPC 或用戶端程式庫，藉此存取金鑰管理服務。應用程式可以運用已啟用使用 CMEK 的 Google 服務。接著 CMEK 會使用 Cloud Key Management Service API。如果您的應用程式使用 PKCS #11，可以透過 PKCS #11 程式庫與 Cloud KMS 整合。

  • Cloud KMS API 可讓您使用軟體、硬體或外部金鑰。您可以使用 Cloud KMS 服務端點，產生及管理軟體保護和硬體保護的金鑰。軟體保護和硬體保護的金鑰都會使用 Google 的備援備份保護機制。

  • 如果您使用硬體保護的金鑰，則會將金鑰儲存在通過 FIPS 140-2 第 3 級認證的 HSM 中。Google Cloud 如要進一步瞭解我們的認證，請參閱認證編號 4399。

  • Cloud KMS 會使用 Google 的內部資料儲存庫，儲存加密的客戶金鑰內容。這個資料儲存庫具備高可用性，並支援許多 Google 重要系統。請參閱資料儲存區保護措施。

  • 獨立備份系統會定期將整個資料存放區備份到線上和封存儲存空間。這項備份作業可協助 Cloud KMS 達成耐用性目標。請參閱「資料儲存庫保護」。

FIPS 140-2 驗證

Cloud KMS 加密編譯作業會由通過 FIPS 140-2 驗證的模組執行。防護等級為 SOFTWARE 的金鑰及用其執行的加密編譯作業均符合 FIPS 140-2 第 1 級的規範。這些密碼編譯作業會使用 BoringCrypto，這是由 Google 維護的開放原始碼密碼編譯程式庫。防護等級為 HSM 的金鑰及用其執行的加密編譯作業均符合 FIPS 140-2 第 3 級的規範。

金鑰內容的安全性

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

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

客戶對 Cloud KMS 的要求會透過在客戶與 Google Front End (GFE) 之間採用 TLS 來進行傳輸加密。

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

Google 的政策旨在確保工作僅使用以可驗證的方式建構、測試和審查的原始碼。Borg 適用的二進位授權 (BAB) 會在作業層級強制執行這項政策。

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

使用者無法透過 API 介面或其他使用者介面匯出或查看解密金鑰內容。Google 員工均無法存取未加密的客戶金鑰內容。此外，系統會使用 Keystore 中的主金鑰將金鑰內容加密，任何人都無法直接存取該金鑰。在 HSM 上，Cloud KMS API 工作絕不會以解密狀態存取金鑰內容。

資料儲存庫防護機制

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

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

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

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

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

Cloud KMS 團隊已記錄還原備份的程序，以便在發生服務端緊急情況時，盡量減少資料損失。

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

防護措施：在 Cloud KMS 應用程式層，您的金鑰內容會在儲存之前先經過加密。有權存取資料儲存庫的工程師，無法存取明文的客戶金鑰內容。此外，Datastore 會先將管理的所有資料加密，再寫入永久儲存空間。因此，即使能存取基礎儲存層 (包括磁碟或封存儲存空間)，只要無法存取儲存在 Keystore 中的資料儲存庫加密金鑰，就無法存取加密的 Cloud KMS 資料。

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

資料落地。每個 Cloud KMS 資料儲存庫的基礎資料只會保留在與該資料相關聯的 Google Cloud 區域內。這項規則也適用於多區域位置 (例如 us 多區域)。

金鑰建立後的可用性

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

主要後端和保護等級

使用 Cloud KMS 建立金鑰時，您可以選擇防護等級，決定要由哪個金鑰後端建立金鑰，並對該金鑰執行所有未來的加密編譯作業。後端會在 Cloud KMS API 中顯示為下列防護等級：

  • SOFTWARE：適用於可由軟體安全性模組解除包裝以執行加密編譯作業的金鑰。
  • HSM：適用於只能由 HSM 解除包裝的金鑰，HSM 會使用金鑰執行所有加密編譯作業。
  • EXTERNAL 或 EXTERNAL-VPC：套用至外部金鑰管理工具 (EKM)。EXTERNAL-VPC可讓您透過虛擬私有雲網路連線至 EKM。 Google Cloud

Cloud KMS 軟體後端：「軟體」防護等級

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

演算法實作

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

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

在產生加密金鑰時，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 設計一節。

Cloud HSM 後端：「硬體」防護等級

Cloud HSM 可為 Cloud KMS 提供硬體保護的金鑰，您可以使用受 Google 資料中心內全代管 FIPS 140-2 第 3 級認證 HSM 保護的加密金鑰。Cloud HSM 具備高可用性，並提供彈性擴充功能，與 Cloud KMS 相同。您可以使用與 Cloud KMS 相同的 API 和用戶端程式庫，存取 Cloud HSM 後端。如要進一步瞭解 Cloud HSM 後端，請參閱 Cloud HSM 架構。

Cloud EKM：「外部」防護等級

Cloud EKM 可讓您使用自己控管的雲端外加密金鑰加密資料。

保護等級為 EXTERNAL 和 EXTERNAL_VPC 的金鑰會儲存在外部金鑰管理系統中並受到管理。詳情請參閱 Cloud EKM 參考架構。

金鑰建立程序

下圖說明不同金鑰後端和防護等級的金鑰建立程序。

金鑰建立程序圖。

金鑰建立程序包括下列步驟：

  1. 使用者透過 Cloud KMS API 要求 Cloud KMS 建立金鑰。這項要求包含保護等級 (金鑰是否受軟體、硬體或外部保護)。
  2. Cloud KMS 會驗證使用者身分，以及使用者是否具備建立金鑰的權限。
  3. 產生的金鑰如下：
    • 如果是軟體保護的金鑰，Cloud KMS 會產生客戶金鑰。
    • 如果是受硬體保護的金鑰，Cloud KMS 會向 Cloud HSM 傳送要求。Cloud HSM 會將要求傳送至 HSM，以產生新金鑰。HSM 會產生客戶金鑰，並使用 HSM 區域包裝金鑰加密 (包裝) 這個金鑰。Cloud HSM 會將包裝金鑰傳回 Cloud KMS。
    • 如果是外部金鑰，Cloud KMS 會將要求傳送至 Cloud EKM。Cloud EKM 會將要求傳送至外部金鑰管理工具，以產生新金鑰。EKM 會產生新金鑰，並使用 EKM 包裝金鑰加密。Cloud EKM 會將包裝金鑰傳回 Cloud KMS。
  4. Cloud KMS 會使用 KMS 主金鑰加密包裝的客戶金鑰，然後傳送至 KMS 資料儲存庫進行儲存。
  5. Cloud KMS 會向使用者傳送成功回應，其中包含金鑰版本的完整 URI。

金鑰匯入

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

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

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

匯入的金鑰可以和 HSM 或 SOFTWARE 防護等級搭配使用。就 Cloud HSM 而言，包裝金鑰的私密金鑰部分只能在 Cloud HSM 內使用。限制私密金鑰部分在 Cloud HSM 中才能使用，能避免讓 Google 在 Cloud HSM 以外的地方解除您金鑰內容的包裝。

Cloud KMS 要求的生命週期

本節將說明 Cloud KMS 要求的生命週期，包括有關刪除金鑰內容的討論。下圖顯示用戶端要求存取 us-east1 和 us-west1 中的 Cloud KMS 服務執行個體，以及如何使用 Google Front End (GFE) 轉送要求。

KMS 要求的生命週期圖表。

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

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

端對端資料完整性

Cloud KMS 可讓您計算金鑰和金鑰內容的總和檢查碼，確保這些內容未損毀。這些檢查碼可協助您避免因硬體或軟體損毀而導致資料遺失。輔助程式庫可讓您驗證金鑰完整性。您可以透過輔助程式庫，將檢查碼提供給 Cloud KMS，由伺服器驗證，藉此驗證金鑰完整性。此外，您也可以透過這些程式庫接收檢查碼，在用戶端驗證回應資料。

端對端資料完整性有助於保護環境，防範下列威脅：

  • 傳輸期間發生損毀，例如在資料傳送和 TLS 保護之間，堆疊中發生損毀。
  • 端點與 KMS 之間的任何中繼 Proxy 發生問題 (例如傳入要求)。
  • Cloud KMS 架構中的加密作業錯誤、機器記憶體損毀或 HSM 損毀。
  • 與外部 EKM 通訊時發生損毀。

詳情請參閱「驗證端對端資料完整性」。

刪除金鑰內容

系統會將金鑰內容視為客戶資料，因此「資料刪除 Google Cloud」一文說明的方法也適用於 Cloud KMS。當「預定銷毀」期間結束且備份到期時，系統會根據要求銷毀金鑰內容。在排定刪除的期限過後，備份中仍存在的金鑰材料只能用於區域災害復原，無法用於還原個別金鑰。此程序並不保證適用於在 Cloud KMS 控管範圍之外的匯入金鑰副本。

根據預設，Cloud KMS 中的金鑰會先進入「已安排刪除」(軟刪除) 狀態 30 天，然後系統才會邏輯刪除金鑰內容。你可以變更這段時間。詳情請參閱預定銷毀狀態的變動時間長度。

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

排定刪除作業後，金鑰版本即無法用於加密編譯作業。在待刪除期間，您可以還原金鑰版本，使其不會遭到刪除。

如果不小心刪除匯入的金鑰，可以重新匯入。詳情請參閱重新匯入已毀損的金鑰。

為避免誤刪金鑰，請考慮採用下列最佳做法：

  • 將「每個金鑰的最短刪除排程時長」限制設為較長的時間。這項限制定義新金鑰預定刪除期間的最短時間。
  • 強制執行「將金鑰刪除限制為已停用的金鑰」限制，確保只有已停用的金鑰可以刪除。詳情請參閱「要求在銷毀前停用金鑰」。
  • 建立不含 cloudkms.cryptoKeyVersions.destroy 權限的自訂 KMS 角色。
  • 將 destroy_scheduled_duration 欄位變更為較長的時間範圍。

  • 監控金鑰銷毀事件並新增快訊。舉例來說，請建立下列 Cloud Logging 篩選器：

      resource.type="cloudkms_cryptokeyversion"
  protoPayload.methodName="DestroyCryptoKeyVersion"

  • 建立程序，在刪除金鑰前幾天停用金鑰。

Google 基礎架構依附元件

Cloud KMS 平台元素會以實際工作環境 Borg 工作的形式運作。Borg 是 Google 的大規模叢集管理員，用於處理 API 服務工作與批次工作。

如要瞭解 Google 實體和實際工作環境基礎架構的安全性，請參閱 Google 基礎架構安全性設計總覽。

Cloud KMS API 服務工作

Cloud KMS API 服務工作是實際工作環境 Borg 工作，可用來處理客戶管理及使用金鑰的要求。Cloud KMS API 服務工作也會處理客戶要求中的延後動作，例如依排程輪替金鑰、建立非對稱金鑰，以及匯入金鑰。這些服務工作會在每個Google Cloud 提供 Cloud KMS 的區域執行。每個工作都與單一區域相關聯，而且已設定為僅存取地理位置在相關聯Google Cloud 區域內的系統資料。

Cloud KMS 批次工作

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

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

Cloud KMS 金鑰快照工具

為了維持高可用性，Cloud KMS 平台會在託管 Cloud KMS API 伺服器工作的共用服務的每個執行個體中，保留一個備援資料儲存庫。每項共用服務都會部署自己的快照工具服務執行個體。這種備援功能使得服務具有高度的獨立性，因此當一個可用區內發生故障時，對其他可用區的影響就很有限。當 Cloud KMS API 工作需要執行加密編譯作業時，將會同時查詢主要資料儲存庫和本機快照工具工作。如果主要資料儲存空間速度緩慢或無法使用，系統可能會從快照提供回應 (如果快照存在時間不超過兩小時)。系統會針對各區域持續執行的批次工作，建立快照做為輸出內容。那些快照位於與金鑰內容相關聯的雲端區域。

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

Google 使用應用程式層傳輸安全性 (ALTS)，確保使用 Google 遠端程序呼叫 (RPC) 機制的用戶端與伺服器之間的通訊安全。

詳情請參閱「服務對服務的驗證、完整性和加密機制」。

Cloud KMS 平台作業環境

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

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

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

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

系統操作員的職責定義於標準作業程序中。系統營運人員執行職務時，不會存取客戶金鑰內容。

Cloud KMS 資源的區域性

為協助您滿足任何金鑰駐留要求，您可以在下列四種類型的Google Cloud 位置建立 Cloud KMS 資源：

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

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

如要進一步瞭解可用的 Cloud KMS 位置，請參閱「Cloud KMS 位置」。

Cloud 區域與資料中心

Google Cloud 區域包含一間特定的資料中心或一組指定的資料中心，具體取決於指定的是單一區域、雙區域、多區域或全球。如要進一步瞭解 Google Cloud 區域，請參閱「Google Cloud 位置」的相關說明。

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

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

金鑰落地

有些產業會要求將加密編譯金鑰存放在特定位置。Cloud KMS 具有資料位置條款，可確保資料落地。如「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 金鑰內容的落地。

區域類型 靜態、使用中
單一區域 常駐
雙區域或多區域 常駐在構成雙區域或多區域的區域中

區域性監控

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

高可用性

Cloud KMS 可根據您選取的區域，簡化可用性需求。位置越精細，您就必須建構越多備援。對於可用性較高的應用程式，請使用多區域位置，而不是嘗試建構自己的金鑰複製系統。您必須根據資料區域化需求，平衡內建的備援功能。

驗證及授權

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。
  • 確認您是否列在適用私人雲端區域的許可清單中。

配額管理

Cloud KMS 對服務要求設有用量限制，稱為「配額」。Cloud KMS 包含下列配額：

  • 加密、解密或簽署等作業的密碼編譯要求配額。
  • 讀取要求配額，適用於取得金鑰中繼資料或身分與存取權管理政策等作業。
  • 建立金鑰或設定 IAM 政策等作業的寫入要求配額。

這些配額會計入與呼叫端相關聯的專案。這些配額也是全域配額，也就是說，系統會針對呼叫者在所有區域和多區域的 KMS 用量套用配額。系統會評估所有防護等級的配額。

Cloud HSM 和 Cloud EKM 的密碼編譯作業有額外配額。除了密碼編譯要求配額外，也必須滿足這些配額。Cloud HSM 和 Cloud EKM 配額會向金鑰所在的專案收費，且每個位置都會強制執行配額。

請見以下範例：

  • 在 asia-northeast1 中使用軟體金鑰呼叫解密時，需要一單位的 (全域) 密碼編譯要求配額。
  • 在 us-central1 中建立 HSM 金鑰需要一單位的寫入要求配額，不需要 HSM 配額。
  • 在 europe 中使用 EKM 金鑰呼叫加密作業，需要一單位的 (全域) 密碼編譯要求配額，以及 europe 中一單位的外部 KMS 要求配額。

如要進一步瞭解可用的配額類型，請參閱「Cloud KMS 資源用量配額」。您可以在 Cloud 控制台中查看配額限制。初始配額限制是軟性限制，您可以根據工作負載需求調整。

記錄

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

Cloud 稽核記錄

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

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

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

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

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

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

內部要求記錄檔

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

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

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

監控

Cloud KMS 可與 Cloud Monitoring 整合。整合後，您就能監控許多 Cloud KMS 作業、建構資訊主頁，以及建立快訊。舉例來說，您可以監控金鑰何時遭到安排刪除，或在加密作業超過您定義的門檻時，監控及調整 Cloud KMS 配額。如要進一步瞭解可用的 Cloud KMS 指標，請參閱「將 Cloud Monitoring 與 Cloud KMS 搭配使用」一文。

此外，Security Command Center 內建 KMS 安全漏洞偵測工具。這些偵測器可確保包含金鑰的專案遵循建議的最佳做法。如要進一步瞭解 KMS 弱點偵測器，請參閱「Cloud KMS 的弱點發現」。

後續步驟