本頁面列出建議做法，說明如何在 Cloud de Confiance 資源上設定靜態資料加密，並使用客戶自行管理的加密金鑰 (CMEK)。本指南適用於雲端架構師和安全團隊，說明設計 CMEK 架構時建議採取的做法和決策。
本指南假設您已熟悉 Cloud Key Management Service (Cloud KMS) 和客戶管理加密金鑰。選擇要使用 CMEK 的位置
如果您希望在雲端中，為自己或客戶的資料建立加密邊界，建議使用客戶自行管理的加密金鑰。詳情請參閱「客戶自行管理的加密金鑰 (CMEK)」。
您可以在相容服務中使用 CMEK，達成下列目標：擁有加密金鑰。
控管及管理加密金鑰，包括選擇位置、保護等級、建立、存取控制、輪替、使用和銷毀。
在 Cloud KMS 中產生金鑰內容，或匯入在 Cloud de Confiance外部維護的金鑰內容。
設定金鑰的使用位置政策。
在停用服務或補救安全性事件 (加密清除) 時，選擇性刪除受金鑰保護的資料。
建立及使用專屬顧客的金鑰，在資料周圍建立加密界線。
記錄管理員和資料存取權，以加密金鑰。
符合目前或日後要求達成這些目標的法規。
Google 也建議您考慮適用於業務需求的法規遵循架構。不同的法規遵循架構對加密和金鑰管理有不同的要求。法規遵循架構通常會列出加密金鑰管理的高階原則和目標，但不會規定要使用哪個特定產品或設定才能符合法規。您有責任瞭解法規遵循架構的要求，以及控管措施 (包括金鑰管理) 如何協助您滿足這些要求。
如要瞭解 Cloud de Confiance 服務如何協助您符合不同法規遵循架構的要求，請參閱下列資源：
選擇金鑰素材來源
建立金鑰時，您必須允許 Cloud KMS 為您產生金鑰內容，或是手動匯入金鑰內容，這類內容是在 Cloud de Confiance外部產生。建議您盡可能選擇在 Cloud KMS 中產生金鑰內容。這個選項不會有將原始金鑰內容暴露在 Cloud KMS 外部的風險，且會根據您選擇的金鑰輪替週期，自動建立新的金鑰版本。如果必須匯入自己的金鑰材料，建議您評估下列作業考量事項，以及使用自備金鑰 (BYOK) 方法的風險：
您可以導入自動化機制，持續匯入新的金鑰版本嗎？這包括 Cloud KMS 設定，可將金鑰版本限制為僅供匯入，以及 Cloud KMS 外部的自動化功能，可持續產生及匯入金鑰內容。如果自動化動作無法在預期時間建立新的金鑰版本，會有什麼影響？
您打算如何安全儲存或託管原始金鑰內容？
如何降低金鑰匯入程序洩漏原始金鑰內容的風險？
如果原始金鑰內容保留在 Cloud de Confiance外部，重新匯入先前刪除的金鑰會有什麼影響？
自行匯入重要素材資源的優點是否值得承擔營運成本和風險？
選擇金鑰控管和金鑰儲存模型
設計 CMEK 架構時，您必須決定金鑰的管理位置和方式。理想情況下，您會選擇相互配合的金鑰控管和金鑰儲存模型。您選擇的控管和儲存空間模型會影響重要設定，例如強制執行分散權責。
金鑰管理
金鑰控管是指機構中負責管理 Cloud KMS 資源生命週期，以及維護防護措施的人員，以控管 Cloud KMS 的使用方式。金鑰控管方法可分為集中式控管和委派式控管：
- 集中式管理：專屬安全或平台團隊負責管理整個機構的所有加密金鑰生命週期。這個模型通常是受到高度監管、必須嚴格遵守法規的企業首選。
- 委派式控管：中央安全團隊使用防護措施強制執行加密標準，但將金鑰生命週期作業的責任委派給專案中的應用程式擁有者。這些防護措施可包括使用代管限制和自訂限制的組織政策，以及 IAM 授權和拒絕政策。這可消除中央作業瓶頸。
金鑰儲存
金鑰儲存空間說明在機構內建立 Cloud KMS 資源的位置。金鑰儲存方式主要有兩種：專屬專案金鑰儲存功能和同專案金鑰儲存功能。
專屬專案金鑰儲存功能：專屬金鑰專案包含用於多個應用程式的金鑰。通常每個環境資料夾都有自己的金鑰專案。您可以搭配專屬專案金鑰儲存功能使用 Autokey。 如要進一步瞭解專屬專案金鑰儲存模型，請參閱「專屬專案金鑰儲存功能」。
同專案金鑰儲存功能：金鑰會儲存在與受保護資源相同的Cloud de Confiance 專案中。有時會將此描述為「金鑰會跟隨資料」。您可以搭配同專案金鑰儲存功能使用 Autokey。如要進一步瞭解同專案金鑰儲存模型，請參閱「同專案金鑰儲存功能」。
配合治理和儲存空間
下表提供範例，說明如何結合這些控管和儲存空間模型，以滿足不同機構的需求：
| 管理模型 | 專屬專案金鑰儲存功能 | 同專案金鑰儲存功能 |
|---|---|---|
| 集中式管理 | 完全集中式做法 建議用途：有嚴格法規要求，必須隔離專案邊界的機構。 作業影響：設定複雜度高。需要強大的自動化功能 (例如「專案工廠」)，才能避免開發團隊的營運作業延遲。 |
受管理的擁有權 建議用途：需要集中控管安全，但希望盡量提升開發人員速度的機構。 作業影響：設定複雜度低。中央安全防護會使用防護措施強制執行政策，而金鑰則與受保護的資源位於同一位置，方便管理。 |
| 委派治理 | 不建議使用 導入跨專案 IAM 複雜度，會導致將金鑰管理作業委派給應用程式團隊的用意失效。 |
自主開發運作 建議用途：適合步調快速、去中心化的機構，且具備強大的開發運作文化。 作業影響：設定複雜度最低。應用程式團隊在專案界線內，對資源和金鑰擁有完全自主權。 |
在各個環境中使用一致的架構
建議您針對任何應用程式，在開發、測試和實際工作環境中使用相同的金鑰儲存模式。這種架構一致性有助於確保 IAM 權限、部署管道和安全控管措施在部署至正式環境前，已在較低環境中經過完整測試。如果為環境選擇不同的架構，可能會導致設定漂移，進而造成部署失敗。
專屬專案金鑰儲存功能
在專屬專案金鑰儲存模式中，特定環境資料夾 (例如「Production」) 的所有金鑰都會儲存在集中式共用金鑰專案中。金鑰管理權限會授予共用的安全團隊，他們通常也會管理金鑰生命週期作業和防護措施，例如 CMEK 機構政策、IAM 政策和角色授權。
用途
如果貴機構優先考量對加密金鑰的嚴格集中控管 (通常是受到法規要求)，或是金鑰託管於外部 HSM，建議使用專案專屬的金鑰儲存模型。
如果貴機構受限於需要密碼長官或金鑰管理員的法規遵循架構 (例如 PCI DSS 或 BSI C5)，則這個模型是不錯的選擇。將應用程式的所有金鑰隔離在單一專屬金鑰專案中，您就能只將 Cloud KMS 管理員角色授予一小群經過稽核的安全管理員。這樣一來，您只需要檢查少數專案的主要管理存取權政策，即可簡化法規遵循稽核程序。
注意事項
這種做法可能會導致跨專案 IAM 複雜化，並為開發團隊帶來潛在瓶頸。 為協助減輕這類問題，您可以實作自動專案佈建 (有時稱為「專案工廠」)，自動建立重要項目及指派權限。
範例
下圖顯示實際工作環境的資源階層範例，其中使用專案專屬的金鑰儲存模型：
- Prod 資料夾包含不同應用程式的個別資料夾和專案，以及 Shared 資料夾。
- 應用程式專案包含各種不同的資源，例如 Compute Engine 執行個體和 Cloud Storage 值區，但不含任何 Cloud KMS 金鑰。
- 「Shared」資料夾包含不同應用程式之間共用的資源。
- 在共用資料夾中，有一個專屬的金鑰專案，其中已啟用 Cloud KMS API。這個專案包含用於保護 Prod 資料夾內資源的所有金鑰。
- 機構層級和資料夾層級的防護措施 (例如機構政策限制和 IAM 政策) 會強制執行分散權責和其他做法。
- 開發人員可以在個別應用程式資料夾或專案中擁有進階權限 (例如專案擁有者角色)，但不會獲得主要專案的權限。
同專案金鑰儲存功能
在這個模型中，金鑰會儲存在與受保護資源相同的專案中。即使開發人員管理自家應用程式的金鑰生命週期，核心安全團隊通常也會實作金鑰管理防護措施。
用途
如果您的首要目標是提升開發人員速度、靈活度和明確責任，建議使用同專案金鑰儲存模型。將金鑰與受保護的資源放在一起，可讓金鑰擁有權與資料擁有權保持一致：金鑰會隨著資料移動。這個模式可將重要管理責任委派給工作負載擁有者，由他們負責遵守 CMEK 機構政策，並在專案中管理金鑰生命週期作業。
注意事項
雖然這個模型可賦予應用程式團隊權限，但必須認真稽核每個專案中的 IAM 角色，才能強制執行最小權限原則。如果機構導入自備金鑰 (BYOK) 或使用 Cloud EKM 金鑰，這個模型可能會增加營運複雜度，因為需要協調各個系統的作業。
範例
下圖顯示實際工作環境的資源階層範例，該環境使用同專案金鑰儲存模型：
- Prod 資料夾包含不同應用程式的個別資料夾和專案。
- 應用程式專案包含各種不同的資源，例如 Compute Engine 執行個體和 Cloud Storage 值區，包括保護這些資源的任何 Cloud KMS 金鑰。
- 機構層級和資料夾層級的防護措施 (例如組織政策限制和 IAM 政策) 會強制執行分散權責和其他做法，但強制執行分散權責可能需要更謹慎的設定。
- 開發人員必須在資源專案中擁有 Cloud KMS 的進階權限，才能建立及管理金鑰。
強制執行分散權責
無論採用哪種儲存空間模型，您都必須為加密金鑰管理員和使用者分別設定主體和權限。為落實最低權限原則和嚴格的職責分離，請根據特定作業責任授予 IAM 角色。
下表概略說明 Cloud KMS 的建議角色區隔：
| 責任 | 建議角色 | 權限摘要 |
|---|---|---|
金鑰管理，例如金鑰生命週期和控管 這可以包括需要進階權限的人類系統管理員和 IaC 主體。 |
Cloud KMS 管理員 (roles/cloudkms.admin) |
|
資源佈建，例如建立受 CMEK 保護的資源 這包括沒有權限提升的人類開發人員和 IaC 主體。 |
服務專屬的管理員或編輯者角色，例如：
|
在建立資源時選取金鑰。 |
金鑰用途，例如加密和解密 請只將這個角色授予服務代理。如果是用於 CMEK 整合的金鑰，則不需要這些權限。 |
Cloud KMS CryptoKey 加密者/解密者
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
使用金鑰加密及解密資料。 |
為 IaC 管道套用最低權限提權
許多機構會使用基礎架構即程式碼 (IaC) 管道 (例如 Terraform 執行器)，自動佈建資源。您如何設計金鑰儲存空間，會直接影響這些管道的資安態勢。
如要自動佈建 Cloud KMS 金鑰，必須授予 IaC 管道高權限的管理角色，才能產生金鑰及修改 IAM 政策。如果攻擊者入侵 IaC 管道，就能全面控管金鑰管理層。
- 如果您使用專屬專案金鑰儲存空間，管道就必須具備中央 Cloud KMS 專案的管理存取權。如果管道遭到入侵，整個機構的金鑰管理平面就可能暴露在風險中。
- 如果您使用同專案金鑰儲存功能，管道只需要資源專案的管理存取權。這樣做可將潛在風險範圍限制在特定應用程式，但仍須管理專案中的進階權限。
Cloud KMS Autokey 會將金鑰佈建作業委派給安全的 Google 代管服務代理，藉此解決這項風險，讓您為持續進行的金鑰佈建作業實作最低權限管道：
- 低權限管道：IaC 管道只需要低權限的 Cloud KMS Autokey 使用者角色 (
roles/cloudkms.autokeyUser)，即可透過建立KeyHandle資源要求金鑰。 - 自動佈建：實際的金鑰建立和 IAM 政策更新作業，會在幕後由 Google 管理的 Cloud KMS 服務代理程式處理。
- 降低風險範圍：這個設計會盡量減少授予管道的權限，避免授予部署管道高階金鑰建立或安全管理員權限，或指派輔助角色，大幅降低管道遭入侵的風險。
啟用 Autokey 的 IaC 管道需要 Cloud KMS Autokey 管理員 (roles/cloudkms.autokeyAdmin) 等權限較寬鬆的角色，因此如果您使用 IaC 管道管理 Autokey 啟用作業，也必須對個別 IaC 主體套用分散權責原則。
採用建議的金鑰管理做法
Google 建議您遵循金鑰位置、防護等級、輪替時間表、精細度和權限的最佳做法。 您可以使用加密指標資訊主頁，瞭解金鑰是否符合這些做法。您可以使用 Security Command Center 安全漏洞發現項目，偵測分散權責的違規行為。
金鑰位置
您必須在計畫部署 Cloud de Confiance 資源的位置建立 Cloud KMS 金鑰環，這些資源會以 CMEK 加密。 您必須先完成這項操作，才能建立金鑰。- 區域和可用區資源必須使用與資源位於相同區域或
global位置的金鑰環和金鑰。 - 全域資源必須使用
global位置的金鑰環和金鑰。
在大多數情況下，這些限制是由 Cloud de Confiance服務強制執行。
強制使用地區金鑰是成功實施資料區域化策略的一環。強制使用特定區域的金鑰環和金鑰，也能確保資源與金鑰環的區域相符。
選擇金鑰精細程度策略
精細度是指每個金鑰預期用途的規模和範圍。舉例來說，如果某個金鑰保護多個資源，就表示該金鑰的精細度較低；如果金鑰只保護一個資源，則精細度較高。選擇合適的鍵粒度策略，有助於遵循 NIST 建議，為每個金鑰設定特定用途。
一般來說，我們建議每個金鑰的用途如下：
- 用於單一 Cloud de Confiance 專案。
- 用於單一位置，例如
us-central1。 - 用於單一服務或產品，例如 BigQuery。
- 盡可能用於單一資源，例如單一 Cloud Storage bucket。
對大多數機構而言，這項策略可妥善平衡維護大量精細金鑰的額外負擔，以及在多個專案、服務或資源之間共用精細度較低的金鑰所帶來的潛在風險。
遵循這些細微程度指南，可輕鬆安全地停用或銷毀金鑰版本，並限制意外或惡意銷毀金鑰的風險。
選擇金鑰的防護等級
建立金鑰時，您有責任根據以 CMEK 加密資料和工作負載的需求，為每個金鑰選取適當的保護等級。
* 如要將金鑰內容儲存在 Cloud de Confiance以外的位置，請使用 Cloud EKM 金鑰。建議您使用 EXTERNAL_VPC 保護層級，以提高可用性。* 如果不需要在 Cloud de Confiance以外的位置儲存金鑰材料，建議使用軟體支援的金鑰。
選擇輪替週期
Cloud KMS 支援軟體支援和採用專屬硬體的對稱金鑰自動金鑰輪替，例如用於 CMEK 的金鑰。如果是軟體支援的金鑰，建議您採用業界標準的 90 天輪替週期。如果是 Cloud HSM 金鑰，建議採用業界標準的 365 天輪替週期。您必須按照所選時間表手動輪替外部金鑰。
建議您評估適合自身需求的金鑰輪替週期。金鑰輪替頻率取決於工作負載的敏感度或法規遵循需求。舉例來說，為符合特定法規標準，您可能每年至少需要金鑰輪替一次，或者您可能會為高度敏感的工作負載選擇更頻繁的輪替週期。
經常輪替金鑰有助於限制以相同金鑰版本加密的訊息數量，進而降低金鑰遭駭的風險和後果。
套用最小權限原則
授予 IAM 角色時，請遵循最小權限原則。強烈建議您避免使用「擁有者」、「編輯者」和「檢視者」等基本角色。請改為授予預先定義的 Cloud KMS 角色，降低過度授權存取權導致安全事件的風險。舉例來說，如果主體只需要匯入金鑰材料，請授予 Cloud KMS 匯入者角色 (roles/cloudkms.importer)，而非權限較寬鬆的 Cloud KMS 管理員角色 (roles/cloudkms.admin)。
設定作業防護機制
下列各節說明可採取的控管措施，有助於降低不一致的金鑰使用情形，或意外刪除或毀損等風險。
強制執行專案防刪除鎖定
建議您使用防刪除鎖定功能保護專案 (搶先版)，避免 Cloud KMS 專案和其中的金鑰遭到誤刪。專案設有防刪除鎖定時，必須先移除防刪除鎖定，才能刪除專案。對於含有 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 KMS 金鑰專案 | 為個別環境使用單一集中式金鑰專案，請勿在金鑰保護的資源 Cloud de Confiance所在專案建立 Cloud KMS 資源。 |
| Cloud KMS 金鑰環 | 為要保護 Cloud de Confiance資源的每個位置建立 Cloud KMS 金鑰環。 |
| 索引鍵精細程度 | 選擇符合風險容許度、成本和作業負荷需求的金鑰細微程度模式。 |
| 防護等級 | 如果金鑰內容必須儲存在 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 架構，並與您必須遵守的任何法規遵循要求進行比較。 |