使用 CMEK 的最佳做法

本頁面概略說明在 Google Cloud 資源上使用客戶管理的加密金鑰 (CMEK) 設定靜態資料加密的最佳做法。本指南適用於雲端架構師和安全性團隊,並概略說明設計 CMEK 架構時必須做出的最佳做法和決策。

本指南假設您已熟悉 Cloud Key Management Service (Cloud KMS)客戶代管的加密金鑰,並已閱讀 Cloud KMS 深入解析

初步決定

本頁的建議適用於使用 CMEK 加密資料的客戶。如果您不確定要使用手動建立或自動建立的 CMEK 做為安全策略的一部分,請參閱本節的初步決策指南。

決定是否要使用 CMEK

如果您需要下列任何功能,建議您使用 CMEK 加密 Google Cloud服務中的靜態資料:

  • 擁有加密金鑰。

  • 控管及管理加密金鑰,包括選擇位置、保護等級、建立、存取控制、輪替、使用和銷毀。

  • 在 Cloud KMS 中產生金鑰內容,或匯入在 Google Cloud以外維護的金鑰內容。

  • 設定金鑰的使用地點政策。

  • 在離職或因應安全性事件 (加密碎片) 時,選擇性刪除由金鑰保護的資料。

  • 建立及使用專屬於客戶的金鑰,為資料建立加密邊界。

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

  • 符合現行或未來法規要求的任何目標。

如果您不需要這些功能,請評估預設的靜態資料加密功能 (搭配Google-owned and managed keys)是否適合您的用途。 如果您選擇只使用預設加密功能,可以停止閱讀本指南。

選擇手動或自動建立金鑰

本指南將概略說明您在自行佈建 CMEK 時,必須做出的最佳做法決策。Cloud KMS Autokey 會為您做出部分決策,並自動執行本指南中的許多建議。使用 Autokey 比自行佈建金鑰更簡單,如果 Autokey 建立的金鑰符合所有需求,建議您採用 Autokey。

Autokey 會為您佈建 CMEK。Autokey 佈建的 CMEK 具有下列特性:

  • 防護等級:HSM。
  • 演算法:AES-256 GCM。
  • 輪替週期:一年。

    由 Autokey 建立金鑰後,Cloud KMS 管理員可以編輯輪替週期,以取代預設值。

  • 權責劃分:
    • 系統會自動授予服務的服務帳戶該金鑰的加密和解密權限。
    • Cloud KMS 管理員權限會一如往常套用至 Autokey 建立的金鑰。Cloud KMS 管理員可以查看、更新、啟用或停用 Autokey 建立的金鑰,也可以銷毀這些金鑰。不會授予 Cloud KMS 管理員加密和解密權限。
    • Autokey 開發人員只能要求建立及指派金鑰。他們無法查看或管理車鑰。
  • 金鑰專屬性或精細程度Autokey 建立的金鑰精細程度會因資源類型而異。如要進一步瞭解金鑰精細程度的服務專屬細節,請參閱「相容的服務」。
  • 位置:Autokey 會在要保護的資源所在位置建立金鑰。

    如果您需要在 Cloud HSM 無法使用的地區建立受 CMEK 保護的資源,就必須手動建立 CMEK。

  • 金鑰版本狀態:使用 Autokey 要求的新建立金鑰會以啟用狀態建立為主要金鑰版本。
  • 金鑰環命名:Autokey 建立的所有金鑰,都會在所選位置的 Autokey 專案中,以名為 autokey 的金鑰環建立。Autokey 開發人員在特定位置要求第一個金鑰時,Autokey 專案中的金鑰環就會建立。
  • 鍵命名:Autokey 建立的鍵會遵循以下命名慣例:PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • 金鑰匯出:與所有 Cloud KMS 金鑰一樣,Autokey 建立的金鑰無法匯出。
  • 金鑰追蹤:與 CMEK 整合服務中使用的所有 Cloud KMS 金鑰一樣,Autokey 建立的金鑰也支援金鑰追蹤,因此會在 Cloud KMS 資訊主頁中追蹤。

如果 Autokey 建立的金鑰無法滿足您的需求 (例如防護等級不是 HSM,或是服務與 Autokey 不相容),建議您使用手動建立的 CMEK 而非 Autokey。

設計 CMEK 架構

設計 CMEK 架構時,您必須考量要使用的金鑰設定,以及這些金鑰的管理方式。這些決策會影響您的成本、作業負擔,以及加密碎裂等功能的實作難易度。

以下各節將討論每個設計選項的建議。

為每個環境使用集中式 CMEK 金鑰專案

建議您為每個環境資料夾使用集中式 CMEK 金鑰專案。請勿在管理 Cloud KMS 金鑰的專案中,建立以 CMEK 加密的資源。這項做法有助於避免在不同環境中共用加密金鑰,並有助於實施職責分離。

下圖說明建議設計中的這些概念:

  • 每個環境資料夾都有一個 Cloud KMS 金鑰專案,並與應用程式專案分開管理。
  • Cloud KMS 金鑰環和金鑰會在 Cloud KMS 金鑰專案中佈建,這些金鑰會用於加密應用程式專案中的資源。
  • 將 Identity and Access Management (IAM) 政策套用至專案或資料夾,以便實施職責分離。在 Cloud KMS 金鑰專案中,管理 Cloud KMS 金鑰的使用者主體,與應用程式專案中使用加密編譯金鑰的使用者主體不同。

建議的 Cloud KMS 資料夾和專案結構

如果您使用 Cloud KMS Autokey,則每個已啟用 Autokey 的資料夾都必須有專屬的 Cloud KMS 金鑰專案。

為每個位置建立 Cloud KMS 金鑰環

您必須在部署以 CMEK 加密的Google Cloud 資源的位置建立 Cloud KMS 金鑰環。

  • 區域和區域資源必須使用與資源位於相同區域的金鑰環和 CMEK,或位於 global 位置。 單一區域和區域資源無法使用 global 以外的多區域金鑰環。
  • 多地區資源 (例如 us 多地區中的 BigQuery 資料集) 必須使用位於相同多地區或雙地區的鑰匙圈和 CMEK。多地區資源無法使用區域性金鑰環。
  • 全域資源必須使用 global 位置中的金鑰環和 CMEK。

強制執行地區金鑰是資料區域化策略的一部分。強制在定義的區域中使用金鑰環和金鑰,您也可以強制要求資源必須與金鑰環的區域相符。 如需資料落地設定的相關指引,請參閱「控管資料落地設定」。

如果工作負載需要跨多個地點提供高可用性或災難復原功能,您有責任評估在 Cloud KMS 於特定地區無法使用時,工作負載是否具備復原能力。舉例來說,如果在區域 A 發生災難時,您無法在區域 B 中重建使用區域 A 的 Cloud KMS 金鑰加密的 Compute Engine 永久磁碟,為降低這種情況的風險,您可以規劃使用 global 金鑰來加密資源。

詳情請參閱「選擇最佳位置類型」。

如果您使用 Cloud KMS Autokey,系統會在您要保護的資源所在位置建立金鑰環。

選擇關鍵精細程度策略

「精細度」是指每個鍵的預期用途規模和範圍。舉例來說,相較於只保護單一資源的金鑰,用於保護多個資源的金鑰較不精細

您必須先為 CMEK 手動佈建 Cloud KMS 金鑰,才能建立要使用該金鑰加密的資源,例如 Compute Engine 永久磁碟。 您可以為個別資源建立非常精細的索引鍵,也可以建立較不精細的索引鍵,以便在資源之間廣泛重複使用。

雖然沒有普遍正確的模式,但請考慮下列不同模式的取捨:

高精細度鍵值,例如每個個別資源一個鍵值

  • 提供更多控管功能,可安全停用金鑰版本:與停用或刪除共用金鑰相比,停用或刪除用於較狹小範圍的金鑰版本,對其他資源的影響較小。這也意味著,相較於使用低精細度的金鑰,使用高精細度的金鑰有助於降低金鑰遭到入侵的潛在影響。
  • 成本:相較於使用精細度較低的金鑰,使用精細度較高的金鑰需要維護更多有效的金鑰版本。 由於 Cloud KMS 定價取決於有效金鑰版本的數量,因此選擇較高金鑰精細度會導致成本增加。
  • 營運額外負擔:使用精細的金鑰可能需要管理人員付出額外心力,或使用額外的自動化工具,才能佈建大量 Cloud KMS 資源,並管理服務代理人的存取權控管機制,讓他們只能使用適當的金鑰。如果您需要高精細度的金鑰,Autokey 可能會是自動佈建的理想選擇。如要進一步瞭解每項服務的 Autokey 鍵精細程度,請參閱「相容的服務」。

低精細度索引鍵,例如每個應用程式、每個區域和每個環境各一個

  • 請謹慎停用金鑰版本:與停用或刪除精細的金鑰相比,停用或刪除用於廣泛範圍的金鑰版本需要更加謹慎。您必須確保使用該金鑰版本加密的所有資源,在停用舊金鑰版本前,都已安全地使用新金鑰版本重新加密。 對於許多資源類型,您可以查看金鑰用途,瞭解金鑰的使用位置。 這也意味著,相較於使用高精細度的金鑰,使用低精細度的金鑰可能會增加金鑰遭到入侵的潛在影響。
  • 成本:使用較不精細的金鑰,就需要建立較少的金鑰版本,而 Cloud KMS 的價格取決於有效金鑰版本的數量。
  • 作業負擔:您可以定義並預先配置已知數量的金鑰,這樣就能減少確保適當存取權控管的作業負擔。

選擇金鑰的防護等級

建立金鑰時,您必須根據使用 CMEK 加密的資料和工作負載需求,為每個金鑰選取適當的保護等級。以下問題可協助您進行評估:

  1. 您是否需要任何 CMEK 功能?您可以參閱本頁「決定是否使用 CMEK」一節列出的功能。

  2. 您是否需要將金鑰內容保留在硬體安全性模組 (HSM) 的實體邊界內?

    • 如果是,請繼續進行下一個問題。
    • 如果沒有,建議您使用 CMEK 搭配軟體支援的金鑰
  3. 您是否需要將金鑰內容儲存在 Google Cloud外?

Autokey 僅支援 HSM 防護等級。如果您需要其他防護等級,則必須自行佈建金鑰。

盡可能使用 Google Cloud產生的金鑰內容

本節不適用於 Cloud EKM 金鑰。

建立金鑰時,您必須允許 Cloud KMS 為您產生金鑰內容,或是手動匯入金鑰內容,而這項內容是在 Google Cloud之外產生。建議您盡可能選擇產生的選項。這個選項不會在 Cloud KMS 外部揭露原始金鑰內容,並根據您選擇的金鑰輪替週期自動建立新的金鑰版本。如果您需要匯入自己的金鑰素材資源,建議您評估以下使用自有金鑰 (BYOK) 方法的作業考量因素和風險:

  • 您可以實施自動化功能,以便持續匯入新的金鑰版本嗎?這包括 Cloud KMS 設定,可限制金鑰版本只匯入,以及 Cloud KMS 以外的自動化功能,可持續產生及匯入金鑰內容。如果自動化動作無法在預期時間內建立新的金鑰版本,會有什麼影響?
  • 您打算如何安全儲存或託管原始金鑰內容?
  • 如何降低匯入金鑰程序洩漏原始金鑰素材的風險?
  • 由於原始金鑰內容已保留在 Google Cloud之外,因此重新匯入先前刪除的金鑰會造成什麼影響?
  • 自行匯入重要素材資源的效益,是否足以抵銷增加的營運額外成本和風險?

根據需求選擇適當的金鑰用途和演算法

建立金鑰時,您必須選取金鑰的用途和基礎演算法。針對 CMEK 用途,您只能使用具有對稱 ENCRYPT_DECRYPT 用途的金鑰。這個金鑰用途一律會使用 GOOGLE_SYMMETRIC_ENCRYPTION 演算法,該演算法會在 Galois 計數器模式 (GCM) 下使用 256 位元進階加密標準 (AES-256) 金鑰,且會填補 Cloud KMS 內部中繼資料。使用 Autokey 時,系統會自動套用這些設定。

如要使用其他用途 (例如用戶端加密),請查看可用的金鑰用途和演算法,選擇最適合您用途的選項。

選擇輪替週期

建議您評估適合自身需求的金鑰輪替期。依據敏感度或法規遵循情況,鍵輪替的頻率取決於工作負載需求。舉例來說,您可能需要至少每年輪替一次金鑰,才能符合特定法規遵循標準,或是您可能會選擇更頻繁的輪替週期,用於高度敏感的工作負載。

輪替對稱式金鑰後,系統會將新版本標示為主要金鑰版本,並用於保護資訊的所有新要求。舊版金鑰仍可用於解密先前以該版本保護的任何已加密資料。輪替金鑰時,系統不會自動重新加密先前金鑰版本所加密的資料。

定期輪替金鑰有助於限制使用相同金鑰版本加密的訊息數量,進而降低金鑰遭駭的風險和後果。

如果您使用 Autokey,系統會以預設的金鑰輪替週期 (一年) 建立金鑰。您可以在建立金鑰後變更輪替週期

套用適當的存取控管機制

規劃存取權控管機制時,建議您考量最低權限原則和權責劃分原則。以下各節將介紹這些建議。

秉持最低權限原則

指派管理 CMEK 的權限時,請考量最小權限原則,並授予執行工作所需的最小權限。我們強烈建議您避免使用基本角色。請改為授予預先定義的 Cloud KMS 角色,以降低因過度授權存取權而導致的安全事件風險。

違反這項原則和相關問題,可由 Security Command Center 的 IAM 安全漏洞調查結果自動偵測。

規劃權責劃分

請為管理加密金鑰和使用加密金鑰的使用者,保留不同的身分和權限。NIST SP 800-152 定義了職責分工,將啟用及管理加密編譯金鑰管理系統服務的加密編譯官,與使用這些金鑰加密或解密資源的使用者區分開來處理。

使用 CMEK 管理靜態資料加密功能時, Google Cloud 服務會將使用加密金鑰的 IAM 角色指派給 Google Cloud 服務的服務代理程式,而非個別使用者。舉例來說,如果要在已加密的 Cloud Storage 值區中建立物件,使用者只需要具備 IAM 角色 roles/storage.objectCreator,而同一個專案中的 Cloud Storage 服務代理 (例如 service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) 則需要具備 IAM 角色 roles/cloudkms.cryptoKeyEncrypterDecrypter

下表列出哪些 IAM 角色通常與哪些工作職能相關聯:

IAM 角色 說明 NIST SP 800-152 標示
roles/cloudkms.admin 提供 Cloud KMS 資源的存取權,但不含存取受限資源類型和加密編譯作業。 密碼編譯人員
roles/cloudkms.cryptoKeyEncrypterDecrypter 可以使用 Cloud KMS 資源,但只限用於 encryptdecrypt 作業。 加密編譯金鑰管理系統使用者
roles/cloudkms.viewer 啟用 getlist 作業。 稽核管理員
您可以透過 Cloud KMS 的 Security Command 漏洞調查結果,自動偵測違反這項原則的行為和相關問題。

一律強制執行 CMEK

下列各節將說明其他控管機制,協助您降低風險,例如不一致的金鑰使用情形、意外刪除或毀損。

強制執行專案防刪除鎖定

建議您使用防刪除鎖定功能保護專案,以免意外刪除。強制執行專案防刪除鎖定後,系統會禁止刪除 Cloud KMS 金鑰專案,直到移除防刪除鎖定為止。

需要 CMEK 金鑰

建議您使用機構政策限制,在環境中強制使用 CMEK。

使用 constraints/gcp.restrictNonCmekServices 封鎖未指定 CMEK 金鑰的特定資源類型建立要求。

要求已排定刪除時間的下限

建議您至少設定已安排刪除的時間長度。金鑰銷毀是無法復原的作業,可能導致資料遺失。根據預設,Cloud KMS 會在金鑰內容遭到永久銷毀前,先使用 30 天的銷毀時間表 (有時稱為軟性刪除期)。這樣一來,萬一金鑰不小心遭到銷毀,您還有一點時間可以還原金鑰。不過,具有 Cloud KMS 管理員角色的使用者可以建立預定刪除日數低至 24 小時的金鑰,這可能不足以讓您偵測問題並還原金鑰。預定銷毀時間長度只能在建立金鑰時設定。

金鑰已排定刪除時,就無法用於加密編譯作業,且任何使用金鑰的要求都會失敗。在此期間,請監控稽核記錄,確認金鑰未在使用中。如果您想再次使用金鑰,必須在預定銷毀期間結束前還原金鑰。

為確保所有建立的金鑰都遵守最短的預定刪除時間,建議您將機構政策限制 constraints/cloudkms.minimumDestroyScheduledDuration 設為最短 30 天,或您偏好的時間長度。這項機構政策可防止使用者建立預定刪除時間長度低於政策中指定值的金鑰。

強制執行 CMEK 的允許防護等級

建議您使用機構政策限制,在整個環境中一律強制執行關鍵保護層級的規定。

使用 constraints/cloudkms.allowedProtectionLevels 強制執行新金鑰、金鑰版本和匯入工作必須使用您允許的防護等級。

為 CMEK 設定偵測控制項

Google Cloud 為 CMEK 提供各種偵測控制項。以下各節將介紹如何啟用及使用 Cloud KMS 相關的控制項。

啟用及匯總稽核記錄

建議您將 Cloud KMS 管理員活動稽核記錄 (以及所有服務的管理員活動記錄) 匯入機構內所有資源的集中位置。這可讓安全團隊或稽核人員一次查看所有與建立或修改 Cloud KMS 資源相關的活動。如要瞭解如何設定匯總記錄接收器,請參閱「匯總並儲存貴機構的記錄檔」。

您可以選擇啟用資料存取記錄,記錄使用金鑰的作業,包括加密和解密作業。使用 CMEK 時,每個使用 CMEK 的服務的每項作業都會產生資料存取記錄,因此可能會產生大量記錄,並影響您的成本。啟用資料存取記錄之前,建議您先明確定義額外記錄的用途,並評估記錄成本的增加幅度。

監控按鍵使用情形

您可以使用 Cloud KMS 存貨 API 查看金鑰用途,找出貴機構中依賴 Cloud KMS 金鑰並受其保護的資源。 Google Cloud 這個資訊主頁可用來監控主版本和相關保護資源的狀態、用量和可用性。資訊主頁也會指出因金鑰遭停用或刪除而無法存取的資料,方便您採取相關行動,例如清除無法存取的資料或重新啟用金鑰。

您可以使用 Cloud Monitoring 搭配 Cloud KMS,針對重要事件 (例如排定金鑰銷毀時間) 設定快訊。您可以透過 Cloud Monitoring 瞭解為何執行這類作業,並觸發可選的後續程序來還原金鑰 (如有需要)。

建議您建立營運計畫,自動偵測您認為重要的事件,並定期查看重點使用資訊主頁。

啟用 Security Command Center 來查看 Cloud KMS 安全漏洞

Security Command Center 會產生安全漏洞發現項目,突顯與 Cloud KMS 和其他資源相關的設定錯誤。建議您啟用 Security Command Center,並將這些發現結果整合至現有的安全性作業。這些檢測結果包括可公開存取的 Cloud KMS 金鑰、具有過度寬鬆 owner 角色的 Cloud KMS 專案,或是違反職責區隔的 IAM 角色。

評估法規遵循要求

不同的法規遵循架構對於加密和金鑰管理的要求也不盡相同。法規遵循架構通常會概述加密金鑰管理的總體原則和目標,但不會明文規定達成法規遵循的特定產品或設定。您有責任瞭解法規遵循架構的規定,以及您的控制項 (包括金鑰管理) 如何滿足這些規定。

如需有關 Google Cloud 服務如何協助您符合不同法規遵循架構規定的指引,請參閱下列資源:

最佳做法摘要

下表總結了本文件中建議的最佳做法:

主題 工作
決定是否要使用 CMEK 如果您需要CMEK 啟用的任何功能,請使用 CMEK。
選擇手動或自動建立金鑰 如果 Autokey 建立的金鑰特性符合您的需求,請使用 Cloud KMS Autokey。
Cloud KMS 金鑰專案 為每個環境使用一個集中式金鑰專案。請勿在金鑰保護的 Google Cloud資源所在專案中建立 Cloud KMS 資源。
Cloud KMS 金鑰環 為每個要保護 Google Cloud資源的位置建立 Cloud KMS 金鑰環
按鍵精細程度 選擇符合需求的金鑰細節模式,或使用 Autokey 自動為每項服務提供建議的細節金鑰。
防護等級 如果金鑰內容必須儲存在 Google Cloud之外,請選擇 Cloud EKM。如果金鑰素材資源可託管於 Google Cloud擁有的硬體安全性模組 (HSM),請選擇 Cloud HSM。如果您不需要 Cloud HSM 或 Cloud EKM,請選擇軟體金鑰。請參閱選取防護等級的指引
金鑰內容 如果金鑰內容託管在 Google Cloud上,請盡可能使用 Google Cloud產生的金鑰內容。如果您使用匯入的金鑰內容,請實施自動化和程序來降低風險
金鑰用途與演算法 所有 CMEK 金鑰都必須使用對稱 ENCRYPT_DECRYPT 金鑰用途和 GOOGLE_SYMMETRIC_ENCRYPTION 演算法。
輪替週期 使用自動金鑰輪替功能,確保金鑰能依照排程輪替。請選擇並套用符合需求的輪替週期,最好每週至少輪替一次。針對機密工作負載更頻繁地輪替金鑰。
最低權限 授予最受限制的預先定義角色,讓主體完成工作。請勿使用基本角色。
權責劃分 為使用金鑰的管理員和使用者設定不同的權限。
專案防刪除鎖定 使用專案防刪除鎖定,避免重要專案遭到誤刪。
需要 CMEK 使用 constraints/gcp.restrictNonCmekServices 限制。
要求已排定刪除時間的下限 使用 constraints/cloudkms.minimumDestroyScheduledDuration 限制條件。
強制執行 CMEK 的允許防護等級 使用 constraints/cloudkms.allowedProtectionLevels 限制。
啟用及匯總稽核記錄 匯總機構中所有資源的管理活動稽核記錄。考慮是否要啟用使用金鑰的作業記錄功能。
監控按鍵使用情形 使用 Cloud KMS 清單 API 或 Google Cloud 控制台,瞭解金鑰使用情形。您可以選擇使用 Cloud Monitoring 為敏感作業 (例如安排金鑰刪除作業) 設定快訊。
為 Cloud KMS 啟用 Security Command Center 檢閱安全漏洞發現結果,並將安全漏洞發現結果納入安全作業。
評估法規遵循要求 查看 Cloud KMS 架構,並與您必須遵循的任何法規遵循要求進行比較。

後續步驟