「授權區隔」的概念可確保單一主體不會擁有完成惡意行為的所有必要權限。在 Cloud Key Management Service 中，這可能是指使用金鑰存取及解密資料，但使用者沒有正當理由存取這些資料。
授權區隔是一種業務控管措施，通常用於較大的機構，旨在協助避免發生安全性或隱私權事件與錯誤。 我們將這視為最佳做法。
在 Cloud KMS 中，職責區隔需要嚴格區分下列角色：
- 金鑰管理員：有權管理金鑰生命週期的主體，包括建立、刪除、輪替和狀態變更，例如具有 Cloud KMS 管理員角色的使用者。
- 金鑰使用者：獲授權可使用金鑰的主體，包括加密、解密、簽署或簽章驗證，例如具有「Cloud KMS 加密編譯金鑰加密者/解密者」角色的使用者。
使用 Cloud KMS 金鑰做為客戶自行管理的加密金鑰時，建議您只授權服務帳戶使用金鑰進行加密和解密。如要進一步瞭解 CMEK 整合服務如何處理資源存取權，請參閱「CMEK 整合服務如何處理資源存取權」。
為防止職責分離機制遭到規避，請勿授予主體廣泛的基本角色，例如「擁有者」 (roles/owner)，因為這類角色同時包含管理和加密權限。您可以使用「加密指標」資訊主頁 (搶先版)，找出不符合職責分離建議的金鑰。詳情請參閱「查看加密指標」。
如要進一步瞭解如何安全地使用 IAM 角色，請參閱「安全地使用 IAM」。
金鑰管理模型
Cloud KMS 支援兩種主要模型，可強制執行職責分離：集中式金鑰管理和委派式金鑰管理。這些金鑰管理模型可單獨或合併使用。舉例來說，機構可以選擇為實際執行環境使用集中式金鑰管理模型，並為用於開發和測試的較低環境使用專屬金鑰管理模型。
下表比較集中式和委派式金鑰管理模型，協助您決定哪種最符合需求。
| 區 | 集中式 (資料夾層級) | 委派型 (專案層級) |
|---|---|---|
| 金鑰位置 | 儲存在專屬金鑰專案中，通常是每個資料夾一個專案。 | 儲存在金鑰保護的資源所在專案中。 |
| 分離方法 | 專案界線：金鑰和受保護的資源位於不同專案。 | 角色分離：嚴格劃分 IAM 角色，確保任何主體都無法同時管理及使用金鑰。 |
| 企業文化 | 適合設有專屬中央安全或加密團隊的高度監管機構。 | 適合優先考量開發人員敏捷度和去中心化授權的機構。 |
| 主要因素 | 高度隔離和集中監管。 | 簡化配額管理作業，減少作業負擔。 |
委派金鑰管理
如果貴機構優先考量開發人員的敏捷度，並希望減少中央安全團隊與開發人員之間的「迴圈」，建議採用委派或「同專案」金鑰管理模式。
在委派模型中，CMEK 和其他金鑰會與受保護的資源儲存在同一個專案中。如要在委派金鑰管理中強制執行職責區隔，必須嚴格區隔 IAM 角色。
您可以在專案或資料夾中啟用專案的 Autokey (預覽版)，允許使用委派金鑰管理模型自動建立金鑰。詳情請參閱「啟用 Autokey 進行委派金鑰管理」。
集中式金鑰管理
如果貴機構有集中式安全團隊，或需要嚴格隔離應用程式環境中的金鑰資料，建議採用集中式或「專屬專案」金鑰管理模式。
在集中式模型中，您的 CMEK 和其他金鑰會儲存在專屬金鑰專案中，與受保護的資源分開存放。通常這表示每個資料夾都有專屬的金鑰專案，內含保護整個資料夾中資源的金鑰。這個專屬金鑰專案由中央安全團隊管理，該團隊在金鑰專案中擁有金鑰管理權限，但無法存取含有受這些金鑰保護資源的專案。
您可以在資料夾中啟用 Autokey，透過集中式金鑰管理模型自動建立金鑰。詳情請參閱「設定 Autokey，集中管理金鑰」。
自動化及監控法規遵循
Google Cloud 提供下列工具，自動化及監控安全邊界：
- Cloud KMS Autokey：Autokey 支援集中式和委派式 (預先發布版) 金鑰管理模型。這兩種方法都會自動將金鑰使用角色授予必要的服務代理，而非要求金鑰的人員，藉此自動劃分職責。Autokey 旨在支援基礎架構即程式碼管道，不需要提升金鑰建立權限。
- Security Command Center：監控 KMS 角色分離發現項目，偵測任何主體 (包括專案擁有者或 Google 服務帳戶) 是否同時擁有單一金鑰的管理和加密權限。
CMEK 加密指標：使用資訊主頁，確認整個機構是否符合職責分離做法。