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