本頁將概略說明如何以最佳做法，在 Google Cloud 資源上使用客戶自行管理的加密金鑰 (CMEK) 設定靜態資料加密。本指南適用於雲端架構師和安全團隊，說明設計 CMEK 架構時必須採取的最佳做法和決策。
本指南假設您已熟悉 Cloud Key Management Service (Cloud KMS) 和客戶代管的加密金鑰，並已閱讀 Cloud KMS 深入探討。初步決定
本頁的建議適用於使用 CMEK 加密資料的客戶。如果您不確定要在安全策略中採用手動或自動建立的 CMEK，請參閱本節的指引，做出初步決策。
決定是否要使用 CMEK
如果您需要下列任一功能，建議使用 CMEK 加密 Google Cloud服務中的靜態資料：
擁有加密金鑰。
控管及管理加密金鑰，包括選擇位置、保護等級、建立、存取權控管、輪換、使用和銷毀。
在 Cloud KMS 中產生金鑰內容，或匯入在 Google Cloud外部維護的金鑰內容。
設定金鑰的使用地點政策。
在停用服務或補救安全性事件 (加密清除) 時，選擇性刪除受金鑰保護的資料。
建立及使用專屬顧客的金鑰，在資料周圍建立加密界線。
記錄管理員和資料存取權，以加密金鑰。
符合現行或未來法規對這些目標的要求。
選擇手動或自動建立金鑰
本指南將說明自行佈建 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 金鑰專案中佈建，這些金鑰用於加密應用程式專案中的資源。
- 身分與存取權管理 (IAM) 政策會套用至專案或資料夾，以啟用職責分離功能。管理 Cloud KMS 金鑰專案中 Cloud KMS 金鑰的主體，與在應用程式專案中使用加密金鑰的主體不同。
為每個位置建立 Cloud KMS 金鑰環
您必須在部署以 CMEK 加密Google Cloud 資源的位置建立 Cloud KMS 金鑰環。
- 區域和可用區資源必須使用與資源位於相同區域，或位於
global位置的金鑰環和 CMEK。 單一區域和區域資源無法使用global以外的多區域金鑰環。 - 多區域資源 (例如
us多區域中的 BigQuery 資料集) 必須使用相同多區域或雙區域中的金鑰環和 CMEK。多區域資源無法使用區域金鑰環。 - 全域資源必須使用
global位置的金鑰環和 CMEK。
強制執行地區金鑰是資料地區化策略的一環。強制使用特定地區的金鑰環和金鑰，也能確保資源與金鑰環的地區相符。 如需資料落地權相關指引，請參閱「控管資料落地權」。
對於需要高可用性或跨多個位置的災害復原功能的工作負載，您有責任評估工作負載是否具備復原能力，以防 Cloud KMS 在特定區域無法使用。舉例來說，如果區域 A 無法使用，在災害復原情境中，您就無法在區域 B 中重新建立以區域 A 的 Cloud KMS 金鑰加密的 Compute Engine 永久磁碟。如要降低這種情況的風險，您可以規劃使用 global 金鑰加密資源。
詳情請參閱「選擇最佳位置類型」。
如果您使用 Cloud KMS Autokey，系統會在您保護的資源所在位置建立金鑰環。
選擇金鑰精細程度策略
精細度是指每個金鑰預期用途的規模和範圍。舉例來說，如果某個金鑰保護多個資源，就表示該金鑰的精細度較低；如果金鑰只保護一個資源，則表示精細度較高。
如要使用 CMEK，您必須先手動佈建 Cloud KMS 金鑰，才能建立要以該金鑰加密的資源，例如 Compute Engine 永久磁碟。 您可以選擇為個別資源建立非常精細的鍵，也可以建立較不精細的鍵，以便在更多資源之間重複使用。
一般來說，我們建議採用下列精細度策略：
- 每把金鑰都會保護單一位置的資源，例如
us-central1。 - 每個金鑰都會保護單一服務或產品中的資源，例如 BigQuery。
- 每組金鑰都會保護單一 Google Cloud 專案中的資源。
這項建議可能不是貴機構最理想的精細度策略。對大多數機構而言，這項策略可妥善平衡維護許多精細金鑰的額外負擔，以及在多個專案、服務或資源之間共用精細度較低的金鑰時，可能產生的風險。
使用 Cloud KMS Autokey 建立的金鑰會遵循這項建議。
如要採用不同的精細程度策略，請考量不同模式的下列取捨：
精細程度高的金鑰，例如每個資源各有一個金鑰
- 更安全地停用金鑰版本：停用或刪除用於特定範圍的金鑰版本，對其他資源的影響風險較低，不像停用或刪除共用金鑰。這也表示，與使用低精細度金鑰相比，使用高精細度金鑰有助於降低金鑰遭盜用的潛在影響。
- 費用：與使用較低精細度金鑰的策略相比，使用精細金鑰需要維護更多有效金鑰版本。 由於 Cloud KMS 定價取決於有效金鑰版本的數量，因此選擇較高的金鑰細微程度會導致成本增加。
- 作業負擔：使用精細程度高的金鑰可能需要管理工作，或使用自動化工具佈建大量 Cloud KMS 資源，以及管理服務代理程式的存取權控管，確保服務代理程式只能使用適當的金鑰。如果需要高精細度的金鑰，Autokey 可能是自動佈建金鑰的好選擇。如要進一步瞭解各項服務的 Autokey 金鑰精細度，請參閱「相容服務」。
低精細度金鑰 - 例如每個應用程式、每個區域和每個環境各有一個金鑰：
- 停用金鑰版本時，請務必謹慎操作：停用或刪除用於廣泛範圍的金鑰版本時，請務必比停用或刪除精細金鑰更加謹慎。您必須確保以該金鑰版本加密的所有資源，都已使用新金鑰版本安全地重新加密，才能停用舊金鑰版本。 對於許多資源類型，您可以查看金鑰使用情形，協助找出金鑰的使用位置。 這也表示，與使用高精細度金鑰相比，使用低精細度金鑰時，金鑰遭盜用可能造成的影響會更大。
- 費用：使用較不精細的金鑰時，需要建立的金鑰版本較少，而 Cloud KMS 定價是根據有效金鑰版本的數量計算。
- 作業負擔：您可以定義及預先佈建已知數量的金鑰，確保適當的存取控管機制，所需的工作量較少。
選擇金鑰的保護等級
建立金鑰時，您有責任根據資料和工作負載的 CMEK 加密需求，為每個金鑰選取適當的保護層級。下列問題有助於評估：
您是否需要任何 CMEK 功能？您可以在這個頁面的「決定是否使用 CMEK」部分，查看相關功能。
- 如果是，請繼續下一個問題。
- 如果不是，建議使用Google 預設加密。
您是否要求金鑰內容必須留在硬體安全模組 (HSM) 的實體界線內？
- 如果是，請繼續下一個問題。
- 如果不是，建議使用 CMEK 和軟體支援的金鑰。
您是否要求金鑰內容儲存在 Google Cloud外部？
- 如果是，建議您使用 CMEK 和 Cloud External Key Manager。
- 否則，建議您使用 CMEK 和 Cloud 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 值區中建立物件，使用者只需要 roles/storage.objectCreator IAM 角色，而同一個專案中的 Cloud Storage 服務代理 (例如 service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) 則需要 roles/cloudkms.cryptoKeyEncrypterDecrypter IAM 角色。
下表列出通常與各職務相關聯的 IAM 角色：
| IAM 角色 | 說明 | NIST SP 800-152 認證 |
|---|---|---|
roles/cloudkms.admin |
提供 Cloud KMS 資源的存取權，但受限資源類型和加密作業除外。 | 密碼編譯人員 |
roles/cloudkms.cryptoKeyEncrypterDecrypter |
可使用 Cloud KMS 資源，但僅限於 encrypt 和 decrypt 作業。 |
加密編譯金鑰管理系統使用者 |
roles/cloudkms.viewer |
啟用 get 和 list 作業。 |
稽核管理員 |
持續強制執行 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 KMS 使用 Cloud Monitoring，針對重要事件設定快訊，例如排定金鑰銷毀時間。 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 金鑰專案 | 為個別環境使用單一集中式金鑰專案，請勿在金鑰保護的資源所在專案建立 Cloud KMS 資源。 Google Cloud |
| Cloud KMS 金鑰環 | 為要保護資源的每個位置建立 Cloud KMS 金鑰環。 Google Cloud |
| 金鑰精細程度 | 選擇符合需求的金鑰細微程度模式，或使用 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 架構，並與您必須遵守的任何法規遵循要求進行比較。 |
後續步驟
- 進一步瞭解 Cloud KMS Autokey 如何減少您持續使用 CMEK 的工作量。