本頁將概略說明如何以最佳做法，在 Cloud de Confiance 資源上使用客戶自行管理的加密金鑰 (CMEK) 設定靜態資料加密。本指南適用於雲端架構師和安全團隊，概述設計 CMEK 架構時必須採取的最佳做法和決策。
本指南假設您已熟悉 Cloud Key Management Service (Cloud KMS) 和客戶管理加密金鑰。決定是否要使用 CMEK
如果您需要下列任何功能，建議使用 CMEK 加密 Cloud de Confiance服務中的靜態資料：
擁有加密金鑰。
控管及管理加密金鑰，包括選擇位置、保護等級、建立、存取控管、輪替、使用和銷毀。
在 Cloud KMS 中產生金鑰內容，或匯入在 Cloud de Confiance外部維護的金鑰內容。
設定金鑰使用位置的相關政策。
在停用服務時，選擇性刪除金鑰保護的資料，或補救安全性事件 (加密清除)。
建立及使用專屬顧客的金鑰，在資料周圍建立加密界線。
記錄管理員和資料存取權，以加密金鑰。
符合現行或未來法規對這些目標的要求。
設計 CMEK 架構
設計 CMEK 架構時，您必須考量要使用的金鑰設定，以及這些金鑰的管理方式。這些決策會影響您的成本、管理作業負擔，以及實作加密銷毀等功能的便利性。
以下各節將討論每種設計選擇的建議。
為個別環境使用集中式 CMEK 金鑰專案
建議您為每個環境資料夾使用集中式 CMEK 金鑰專案。 請勿在管理 Cloud KMS 金鑰的專案中，建立以 CMEK 加密的資源。這種做法有助於防止在不同環境之間共用加密金鑰，並有助於實現權責劃分。
下圖說明建議設計中的這些概念：
- 每個環境資料夾都有一個 Cloud KMS 金鑰專案，與應用程式專案分開管理。
- Cloud KMS 金鑰環和金鑰是在 Cloud KMS 金鑰專案中佈建，這些金鑰用於加密應用程式專案中的資源。
- 身分與存取權管理 (IAM) 政策會套用至專案或資料夾，以啟用職責分離功能。管理 Cloud KMS 金鑰專案中 Cloud KMS 金鑰的主體，與在應用程式專案中使用加密金鑰的主體不同。
為每個位置建立 Cloud KMS 金鑰環
您必須在部署Cloud de Confiance 以 CMEK 加密資源的位置，建立 Cloud KMS 金鑰環。
- 區域和可用區資源必須使用與資源位於相同區域，或位於
global位置的金鑰環和 CMEK。 - 全域資源必須使用
global位置的金鑰環和 CMEK。
強制執行地區金鑰是資料地區化策略的一環。強制使用特定地區的金鑰環和金鑰，也能確保資源與金鑰環的地區相符。
如果工作負載需要高可用性或跨多個位置的災難復原功能，您有責任評估工作負載在特定區域的 Cloud KMS 無法使用時，是否仍具備復原能力。舉例來說，如果區域 A 無法使用，在災難復原情境中，您就無法在區域 B 中重新建立以區域 A 的 Cloud KMS 金鑰加密的 Compute Engine 永久磁碟。如要降低這種情況的風險，您可以規劃使用 global 金鑰加密資源。
選擇金鑰精細程度策略
精細度是指每個金鑰預期用途的規模和範圍。舉例來說，如果某個金鑰保護多個資源，就表示該金鑰的精細度較低；如果某個金鑰只保護一個資源，就表示該金鑰的精細度較高。
如要建立使用 CMEK 的資源 (例如 Compute Engine 永久磁碟)，必須預先佈建 Cloud KMS 金鑰。 您可以選擇為個別資源建立非常精細的鍵，也可以建立較不精細的鍵，以便在更多資源之間重複使用。
一般來說，我們建議採用下列精細度策略：
- 每把金鑰都會保護單一位置的資源，例如
us-central1。 - 每個金鑰都會保護單一服務或產品中的資源，例如 BigQuery。
- 每組金鑰都會保護單一 Cloud de Confiance 專案中的資源。
這項建議可能不是貴機構最理想的精細度策略。對大多數機構而言，這項策略可妥善平衡維護大量細微金鑰的額外負擔，以及在多個專案、服務或資源之間共用較不細微金鑰的潛在風險。
如要採用不同的精細程度策略，請考量不同模式的下列取捨：
高精細度金鑰：例如，每個資源各有一個金鑰
- 更安全地停用金鑰版本：停用或刪除用於範圍較窄的金鑰版本，對其他資源的影響較小，風險也較低。這也表示，與使用低精細度金鑰相比，使用高精細度金鑰有助於降低金鑰遭盜用的潛在影響。
- 成本：與使用較低精細度金鑰的策略相比，使用精細金鑰需要維護更多有效金鑰版本。 提高金鑰精細度需要更多有效金鑰版本， 這會產生額外費用。
- 作業管理負擔：使用精細程度極高的金鑰可能需要管理工作，或使用自動化工具佈建大量 Cloud KMS 資源，以及管理服務代理程式的存取控管，確保服務代理程式只能使用適當的金鑰。
低精細度金鑰 - 例如每個應用程式、每個區域和每個環境各有一個金鑰：
- 停用金鑰版本時，請務必謹慎操作：停用或刪除用於廣泛範圍的金鑰版本時，請務必比停用或刪除精細金鑰更加謹慎。您必須確保以該金鑰版本加密的所有資源，都已使用新金鑰版本安全地重新加密，才能停用舊金鑰版本。 這也表示，與使用高精細度金鑰相比，使用低精細度金鑰時，金鑰遭盜用可能造成的影響會更大。
- 成本：使用較不精細的金鑰需要建立的金鑰版本較少，因此成本較低。
- 作業負擔：您可以定義及預先佈建已知數量的金鑰，確保適當的存取控管機制，所需的工作量較少。
選擇金鑰的保護等級
建立金鑰時，您有責任根據資料和工作負載需求，為每個金鑰選取適當的保護層級，這些資料和工作負載會使用 CMEK 加密。下列問題有助於評估：
您是否需要任何 CMEK 功能？如要查看相關功能，請參閱本頁面的「決定是否使用 CMEK」一節。
- 如果是，請繼續下一個問題。
- 如果不是，建議使用 S3NS 預設加密。
您是否需要第 2 級或第 3 級的 FIPS 140-2 認證，或是需要將金鑰材料儲存在 Cloud de Confiance以外的位置？
- 如果是，建議您使用 CMEK 和 Cloud External Key Manager。
- 如果不是，建議使用 CMEK 和軟體支援的金鑰。
盡可能使用 Cloud de Confiance產生的金鑰材料
本節不適用於 Cloud EKM 金鑰。
建立金鑰時，您必須允許 Cloud KMS 為您產生金鑰內容，或是手動匯入金鑰內容，這些內容是在 Cloud de Confiance以外產生。建議您盡可能選擇系統生成的選項，這個選項不會在 Cloud KMS 以外的地方公開原始金鑰內容，並會根據您選擇的金鑰輪替週期，自動建立新的金鑰版本。如要匯入自己的金鑰材料，建議您評估下列作業考量事項，以及使用自備金鑰 (BYOK) 方法的風險：
- 您可以導入自動化機制，持續匯入新的金鑰版本嗎？這包括 Cloud KMS 設定 (將金鑰版本限制為只能匯入)，以及 Cloud KMS 以外的自動化作業，可持續產生及匯入金鑰內容。如果自動化程序無法在預期時間建立新的金鑰版本，會有什麼影響？
- 您打算如何安全儲存或託管原始金鑰內容？
- 如何降低程序匯入金鑰時，導致原始金鑰資料外洩的風險？
- 如果原始金鑰內容保留在 Cloud de Confiance外部，重新匯入先前刪除的金鑰會有什麼影響？
- 自行匯入重要素材資源的好處，是否足以抵銷營運成本和風險的增加？
根據需求選擇合適的金鑰用途和演算法
建立金鑰時，您必須選取金鑰的用途和基礎演算法。如果是 CMEK 用途，只能使用具有對稱ENCRYPT_DECRYPT
用途的金鑰。這個金鑰用途一律使用 GOOGLE_SYMMETRIC_ENCRYPTION 演算法，在 Galois 計數器模式 (GCM) 下使用 256 位元進階加密標準 (AES-256) 金鑰，並填補 Cloud KMS 內部中繼資料。使用 Autokey 時，系統會自動套用這些設定。
如為其他用途 (例如用戶端加密)，請查看可用的金鑰用途和演算法，選擇最適合您用途的選項。
選擇輪替週期
建議您評估適合自身需求的金鑰輪替週期。金鑰輪替頻率取決於工作負載的敏感度或法規遵循需求。舉例來說，為符合特定法規標準，您可能每年至少需要金鑰輪替一次，或者您可能會為高度敏感的工作負載選擇更頻繁的輪替週期。
輪替對稱式金鑰後，新版本會標示為主要金鑰版本，並用於所有新要求，以保護資訊。舊金鑰版本仍可用於解密先前以該版本加密的資料。輪替金鑰時，系統不會自動重新加密以舊版金鑰加密的資料。
經常輪替金鑰有助於限制使用相同金鑰版本加密的訊息數量，降低金鑰遭駭的風險和後果。
套用適當的存取權控管機制
規劃存取控管時，建議您考量最小權限原則和權責劃分原則。以下各節將介紹這些建議。
套用最小權限原則
指派管理 CMEK 的權限時，請採用最小權限原則，並授予執行任務所需的最低權限。強烈建議您避免使用基本角色。請改為授予預先定義的 Cloud KMS 角色，以降低權限過高導致安全事件的風險。
規劃職責劃分
為加密金鑰管理員和使用者分別設定身分和權限。NIST SP 800-152 定義了加密編譯人員與使用者之間的職責劃分。加密編譯人員負責啟用及管理加密編譯金鑰管理系統的服務，使用者則負責使用這些金鑰加密或解密資源。
使用 CMEK 管理 Cloud de Confiance 服務的靜態資料加密時，加密金鑰的 IAM 角色會指派給 Cloud de Confiance 服務的服務代理程式，而不是個別使用者。舉例來說，如要在已加密的 Cloud Storage 值區中建立物件，使用者只需要 roles/storage.objectCreator IAM 角色，而同一個專案中的 Cloud Storage 服務代理 (例如 service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.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 的偵測控制項
Cloud de Confiance 提供各種 CMEK 偵測控制項。以下各節將介紹如何啟用及使用這些控制項，以適用於 Cloud KMS。
啟用及彙整稽核記錄
建議您在機構中，集中管理所有資源的Cloud KMS 管理員活動稽核記錄 (以及所有服務的管理員活動記錄)。這可讓安全團隊或稽核人員一次查看所有與建立或修改 Cloud KMS 資源相關的活動。如需設定匯總記錄接收器的指引，請參閱「匯總並儲存貴機構的記錄檔」。
您可以選擇啟用資料存取記錄，記錄使用金鑰的作業，包括加密和解密作業。使用 CMEK 時，這可能會產生大量記錄，並影響您的費用，因為使用 CMEK 的每項服務都會建立資料存取記錄。啟用資料存取記錄前，建議您先明確定義額外記錄的用途，並評估記錄費用會增加多少。
評估法規遵循要求
不同法規遵循架構對加密和金鑰管理有不同的要求。合規架構通常會列出加密金鑰管理的高階原則和目標，但不會規定要使用特定產品或設定才能符合規範。您有責任瞭解法規遵循架構的規定，以及如何透過控制項 (包括金鑰管理) 滿足這些規定。
如要瞭解 Cloud de Confiance 服務如何協助您符合不同法規遵循架構的要求，請參閱下列資源：最佳做法摘要
下表摘要說明本文建議的最佳做法：
| 主題 | 工作 |
|---|---|
| 決定是否要使用 CMEK | 如要啟用 CMEK 提供的任何功能，請使用 CMEK。 |
| Cloud KMS 金鑰專案 | 為個別環境使用單一集中式金鑰專案，請勿在金鑰保護的資源所在專案建立 Cloud KMS 資源。 Cloud de Confiance |
| Cloud KMS 金鑰環 | 為要保護資源的每個位置建立 Cloud KMS 金鑰環。 Cloud de Confiance |
| 金鑰精細程度 | 選擇符合風險容許度、成本和作業負荷需求的金鑰細微程度模式。 |
| 防護等級 | 如果金鑰內容必須儲存在 Cloud de Confiance 以外的位置，或是需要第 2 級或第 3 級的 FIPS 140-2 認證，請選擇 Cloud EKM。否則請選擇軟體金鑰。請參閱選取防護等級的指南。 |
| 金鑰內容 | 如要使用 Cloud de Confiance代管的金鑰內容，請盡可能使用 Cloud de Confiance產生的金鑰內容。如果您使用匯入的金鑰材料，請實作自動化和程序來降低風險。 |
| 金鑰用途與演算法 | 所有 CMEK 金鑰都必須使用對稱式 ENCRYPT_DECRYPT 金鑰用途和 GOOGLE_SYMMETRIC_ENCRYPTION 演算法。 |
| 輪替週期 | 使用自動金鑰輪替功能，確保金鑰會依排程輪替。選擇並套用符合需求的輪替週期，最好每年至少輪替一次。針對機密工作負載，更頻繁地輪替金鑰。 |
| 最低權限 | 授予權限最小的預先定義角色，讓主體完成工作。請勿使用基本角色。 |
| 權責劃分 | 為使用金鑰的重要管理員和主體維持個別權限。 |
| 專案防刪除鎖定 | 使用專案防刪除鎖定，避免重要專案遭到誤刪。 |
| 要求使用 CMEK | 使用 constraints/gcp.restrictNonCmekServices 限制。 |
| 排定刪除時間必須達到下限 | 使用 constraints/cloudkms.minimumDestroyScheduledDuration 限制。 |
| 強制執行 CMEK 適用的保護等級 | 使用 constraints/cloudkms.allowedProtectionLevels 限制。 |
| 啟用及彙整稽核記錄 | 匯總機構中所有資源的管理活動稽核記錄。請考慮是否要啟用使用金鑰的作業記錄。 |
| 評估法規遵循要求 | 檢查 Cloud KMS 架構，並與您必須遵守的任何法規遵循要求進行比較。 |