使用 CMEK 的最佳做法

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

本指南假設您已熟悉 Cloud Key Management Service (Cloud KMS)客戶管理加密金鑰

決定是否要使用 CMEK

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

  • 擁有加密金鑰。

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

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

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

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

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

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

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

如果您不需要這些功能,請評估預設的靜止狀態加密功能是否適合您的用途。 Google Cloud-powered keys 如果您選擇只使用預設加密功能,可以停止閱讀本指南。

設計 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 金鑰環

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

  • 區域和區域資源必須使用與資源位於相同區域的金鑰環和 CMEK,或位於 global 位置。
  • 全域資源必須使用 global 位置中的金鑰環和 CMEK。

強制執行地區金鑰是資料區域化策略的一部分。強制在定義的區域中使用金鑰環和金鑰,您也可以強制要求資源必須與金鑰環的區域相符。

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

選擇關鍵精細程度策略

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

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

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

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

  • 提供更多控管功能,可安全停用金鑰版本:與停用或刪除共用金鑰相比,停用或刪除用於較狹小範圍的金鑰版本,對其他資源的影響較小。這也意味著,相較於使用低精細度的金鑰,使用高精細度的金鑰有助於降低金鑰遭到入侵的潛在影響。
  • 成本:相較於使用精細度較低的金鑰,使用精細度較高的金鑰需要維護更多有效的金鑰版本。 較高的金鑰精細度需要更多有效金鑰版本,因此會產生額外費用。
  • 營運額外負擔:使用精細的金鑰可能需要管理人員付出額外心力,或使用額外的自動化工具,才能佈建大量 Cloud KMS 資源,並管理服務代理人的存取權控管機制,讓他們只能使用適當的金鑰。

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

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

選擇金鑰的防護等級

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

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

    • 如果是,請繼續下一個問題。
    • 如果沒有,建議您使用 S3NS 預設加密功能。
  2. 您是否需要 FIPS 140-2 第 2 級或第 3 級認證,或是將金鑰內容儲存在 Trusted Cloud之外?

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

本節不適用於 Cloud EKM 金鑰。

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

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

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

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

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

選擇輪替週期

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

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

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

套用適當的存取控管機制

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

秉持最低權限原則

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

規劃權責劃分

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

使用 CMEK 管理靜態資料加密功能時, Trusted Cloud 服務會將使用加密金鑰的 IAM 角色指派給 Trusted Cloud 服務的服務代理程式,而非個別使用者。舉例來說,如果要在已加密的 Cloud Storage 值區中建立物件,使用者只需要具備 IAM 角色 roles/storage.objectCreator,而同一個專案中的 Cloud Storage 服務代理 (例如 service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.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 作業。 稽核管理員

一律強制執行 CMEK

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

強制執行專案防刪除鎖定

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

需要 CMEK 金鑰

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

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

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

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

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

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

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

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

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

為 CMEK 設定偵測控制項

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

啟用及匯總稽核記錄

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

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

評估法規遵循要求

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

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

最佳做法摘要

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

主題 工作
決定是否要使用 CMEK 如果您需要CMEK 啟用的任何功能,請使用 CMEK。
Cloud KMS 金鑰專案 為每個環境使用一個集中式金鑰專案。請勿在金鑰保護的 Trusted Cloud資源所在專案中建立 Cloud KMS 資源。
Cloud KMS 金鑰環 為每個要保護 Trusted Cloud資源的位置建立 Cloud KMS 金鑰環
按鍵精細程度 選擇符合風險容忍度、成本和營運額外成本需求的主要精細資料模式
防護等級 如果金鑰內容必須儲存在 Trusted Cloud 之外,或是您需要 FIPS 140-2 第 2 級或第 3 級認證,請選擇 Cloud EKM。否則,請選擇軟體鍵。請參閱選取防護等級的指引
金鑰內容 如果金鑰內容託管在 Trusted Cloud上,請盡可能使用 Trusted Cloud產生的金鑰內容。如果您使用匯入的金鑰內容,請實施自動化和程序來降低風險
金鑰用途與演算法 所有 CMEK 金鑰都必須使用對稱 ENCRYPT_DECRYPT 金鑰用途和 GOOGLE_SYMMETRIC_ENCRYPTION 演算法。
輪替週期 使用自動金鑰輪替功能,確保金鑰能依照排程輪替。請選擇並套用符合需求的輪替週期,最好每週至少輪替一次。針對機密工作負載更頻繁地輪替金鑰。
最低權限 授予最受限制的預先定義角色,讓主體完成工作。請勿使用基本角色。
權責劃分 為使用金鑰的管理員和使用者設定不同的權限。
專案防刪除鎖定 使用專案防刪除鎖定,避免重要專案遭到誤刪。
需要 CMEK 使用 constraints/gcp.restrictNonCmekServices 限制。
要求已排定刪除時間的下限 使用 constraints/cloudkms.minimumDestroyScheduledDuration 限制條件。
強制執行 CMEK 的允許防護等級 使用 constraints/cloudkms.allowedProtectionLevels 限制。
啟用及匯總稽核記錄 匯總機構中所有資源的管理活動稽核記錄。考慮是否要啟用使用金鑰的作業記錄功能。
評估法規遵循要求 查看 Cloud KMS 架構,並與您必須遵循的任何法規遵循要求進行比較。