Cloud KMS Autokey 會自動佈建及指派客戶自行管理的加密金鑰 (CMEK),簡化建立和使用流程。Autokey 會視需求產生金鑰環和金鑰。系統會視需要建立使用金鑰加密及解密資源的服務帳戶,並授予 Identity and Access Management (IAM) 角色。Cloud KMS 管理員可全權控管及查看 Autokey 建立的金鑰,無需事先規劃及建立各項資源。使用 Autokey 比自行佈建金鑰更簡單,如果 Autokey 建立的金鑰符合您的所有需求,建議您選擇這個選項。
使用 Autokey 產生的金鑰,可協助您持續遵循資料安全性的業界標準和建議做法,包括多租戶 Cloud HSM 保護等級、分散權責、金鑰輪替、位置和金鑰專用原則。Autokey 建立的金鑰會遵循一般指南,以及與 Cloud KMS Autokey 整合的Cloud de Confiance 服務資源類型專屬指南。建立後,使用 Autokey 要求的金鑰與其他設定相同的 Cloud HSM 金鑰功能相同。
使用 Autokey 時,要求新金鑰所需的權限極少,且包含在授予資源建立權限的預設角色中。這表示開發人員和基礎架構即程式碼 (IaC) 管道不需要進階權限。Autokey 可簡化使用 Terraform 管理金鑰的作業,並支援最小權限原則。
Autokey 可搭配專屬專案金鑰儲存功能 (舊稱集中式金鑰管理) 或同專案金鑰儲存功能 (舊稱委派金鑰管理) 使用。如要搭配使用 Autokey 和專用專案金鑰儲存空間,您必須擁有包含資料夾資源的組織資源。使用專用專案金鑰儲存空間時,您會為資料夾中的專案啟用 Autokey,而 Autokey 建立的金鑰會儲存在該資料夾的指定金鑰專案中。使用同專案金鑰儲存功能時,您可以在資料夾或專案啟用 Autokey,讓 Autokey 在受保護資源所在的專案建立金鑰。
如要進一步瞭解組織和資料夾資源,請參閱「資源階層」。
Cloud KMS Autokey 適用於所有提供 Cloud HSM 的 Cloud de Confiance 位置。如要進一步瞭解 Cloud KMS 位置,請參閱「Cloud KMS 位置」。使用 Cloud KMS Autokey 不會產生額外費用。使用 Autokey 建立的金鑰,定價與其他 Cloud HSM 金鑰相同。如要進一步瞭解定價,請參閱「Cloud Key Management Service 定價」。
Autokey 的運作方式
本節說明 Cloud KMS Autokey 的運作方式。參與這項程序的使用者角色如下:
- 管理員
- 管理員是負責管理資料夾或組織層級安全性的使用者。具備較高權限的 IaC 管道可做為管理員。
- 開發人員
- 應用程式開發人員負責使用 Cloud KMS Autokey 建立資源。IaC 管道可以扮演開發人員的角色。
- Cloud KMS 管理員
- Cloud KMS 管理員是負責管理 Cloud KMS 資源的使用者。使用 Autokey 時,這個角色的責任比使用手動建立的金鑰時少。
下列服務代理也會參與這項程序:
- Cloud KMS 服務代理
- 特定金鑰專案中 Cloud KMS 的服務代理。Autokey 仰賴這個服務代理,具備進階權限,可建立 Cloud KMS 金鑰和金鑰環,並設定金鑰的 IAM 政策,為各個資源服務代理授予加密和解密權限。
- 資源服務代理
- 指定資源專案中指定服務的服務代理。這個服務代理必須具備任何 Cloud KMS 金鑰的加密和解密權限,才能使用該金鑰對資源進行 CMEK 保護。Autokey 會視需要建立資源服務代理,並授予使用 Cloud KMS 金鑰的必要權限。
管理員啟用 Cloud KMS Autokey
如要啟用 Autokey,請根據您選擇的金鑰儲存模型,選擇下列其中一個路徑:
- 專屬專案金鑰儲存功能:在資料夾啟用專屬專案金鑰儲存功能。您需要指定專屬金鑰專案,用於存放金鑰,保護在資料夾內其他專案中建立的資源。
- 同專案金鑰儲存功能:在個別專案或資料夾內的所有專案啟用同專案金鑰儲存功能,在受保護資源所在的專案建立金鑰。
啟用專屬專案金鑰儲存功能
如要在資料夾中使用 Autokey,並將金鑰儲存在專屬專案,管理員必須先完成下列一次性設定工作:
在資料夾上啟用 Autokey,並使用專用專案金鑰儲存空間,然後找出要存放該資料夾 Autokey 資源的 Cloud KMS 專案。
建立 Cloud KMS 服務代理,然後授予金鑰建立和指派權限。
完成這項設定後,開發人員只要能在該資料夾的任何專案中,建立與 Autokey 相容的資源,即可隨選觸發多租戶 Cloud HSM 金鑰建立作業。如要查看 Cloud KMS Autokey 的完整設定操作說明,請參閱「啟用 Cloud KMS Autokey」。
啟用 Autokey,並將金鑰儲存在相同專案
如要使用 Autokey 並將金鑰儲存在相同專案,管理員必須先完成下列一次性設定工作:
- 在專案或資料夾啟用 Autokey,並使用同專案金鑰儲存功能。
- 在該專案或資料夾中的專案啟用 Cloud KMS API。
在專案啟用 Autokey 並設定將金鑰儲存在相同專案後,系統會視需要建立 Cloud KMS 服務代理。您不必手動建立服務代理。凡是有權建立 Autokey 相容資源的使用者,都能視需要要求新的金鑰。如要查看 Cloud KMS Autokey 的完整設定操作說明,請參閱「啟用 Cloud KMS Autokey」。
Autokey 開發人員使用 Cloud KMS Autokey
成功為專案啟用 Autokey 後,開發人員和 IaC 管道就能建立資源,並使用依需求建立的金鑰保護資源。這項設定適用於已啟用 Autokey 且使用專屬專案金鑰儲存空間的資料夾中的專案,以及已啟用 Autokey 且使用同專案金鑰儲存空間的專案。資源建立程序的詳細資料取決於您建立的資源,但程序會遵循下列流程:
開發人員開始在相容的 Cloud de Confiance服務中建立資源。建立資源時,開發人員會向 Autokey 服務代理要求新的金鑰。
Autokey 服務代理會收到開發人員的要求,並完成下列步驟:
- 在專案的指定位置建立金鑰環,除非該金鑰環已存在。
- 在金鑰環中建立金鑰,並根據資源類型設定適當的精細程度,除非這類金鑰已存在。
- 為每個專案和服務建立服務帳戶,除非該服務帳戶已存在。
- 為各專案、各服務的服務帳戶授予金鑰的加密和解密權限。
- 請將金鑰詳細資料提供給開發人員,以便他們完成資源建立作業。
Autokey 服務代理成功傳回金鑰詳細資料後,開發人員就能立即完成建立受保護資源。
Cloud KMS Autokey 建立的金鑰具有下一節所述的屬性。這個金鑰建立流程會保留分散權責。Cloud KMS 管理員仍可完整查看及控管 Autokey 建立的金鑰。
如要在啟用 Autokey 後開始使用,請參閱「使用 Cloud KMS Autokey 建立受保護的資源」。
關於 Autokey 建立的金鑰
Cloud KMS Autokey 建立的金鑰具有下列屬性:
- 防護等級: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-RESOURCE_TYPE_DESCRIPTOR_NAME-RANDOM_HEX - 金鑰匯出:與所有 Cloud KMS 金鑰一樣,Autokey 建立的金鑰無法匯出。
- 金鑰追蹤:與 CMEK 整合服務中使用的所有 Cloud KMS 金鑰一樣,Autokey 建立的金鑰也會在 Cloud KMS 資訊主頁中追蹤,前提是該服務與金鑰追蹤功能相容。
控管 Autokey 的使用
您可以使用下列控制項,控管組織使用 Autokey 的方式:
- Autokey 設定:在要使用 Autokey 的資料夾或專案上啟用 Autokey。子項資源會沿用 Autokey 設定,但可以覆寫較低層級的設定,例如專案的 Autokey 設定會優先於上層資料夾的設定。這樣一來,您就能由下而上控管 Autokey。如要進一步瞭解如何啟用及停用 Autokey,請參閱「啟用 Cloud KMS Autokey」。
- IAM:您可以透過 IAM 角色授予和拒絕政策,控管哪些使用者可以建立及更新 Autokey 設定,以及哪些使用者可以建立受 Autokey 保護的資源。這些 IAM 控制項可在組織、資料夾或專案層級設定。授予 IAM 角色後,主體就能執行角色允許的操作。IAM 拒絕政策會封鎖個別權限,即使主體獲派的角色包含這些權限也一樣。在父項資源設定的 IAM 拒絕政策,無法由較低層級設定的寬鬆政策覆寫,因此您可以由上而下控管哪些人能啟用及使用 Autokey。如要進一步瞭解如何使用 IAM 拒絕政策控管組織中的 Autokey 使用情形,請參閱「使用 IAM 拒絕政策控管 Autokey」。
- 組織政策:您可以使用自訂組織政策限制,控管 Autokey 的設定位置和方式。您可以在組織、資料夾或專案層級,強制執行組織政策限制。組織政策會由子資源繼承,但可由較低層級強制執行的政策覆寫。如要進一步瞭解如何使用自訂組織政策限制,控管組織中的 Autokey 使用情形,請參閱「使用自訂組織政策限制控管 Autokey」。
相容服務
下表列出與 Cloud KMS Autokey 相容的服務:
| 服務 | 受保護的資源 | 金鑰精細程度 |
|---|---|---|
| AlloyDB for PostgreSQL |
AlloyDB for PostgreSQL 與 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Apigee |
Apigee 與 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Apigee API 中心 |
Apigee API 中心與 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Artifact Registry |
Autokey 會在建立存放區時建立金鑰,用於所有儲存的構件。 |
每項資源一個金鑰 |
| 備份和災難復原服務 |
|
每項資源一個金鑰 |
| GKE 備份 |
只有使用 Terraform 或 REST API 建立的資源,才能整合 GKE 備份和 Cloud KMS Autokey。 |
每項資源一個金鑰 |
| BigQuery |
Autokey 會為資料集建立預設金鑰。資料集內的資料表、模型、查詢和臨時資料表會使用資料集預設金鑰。 Autokey 不會為資料集以外的 BigQuery 資源建立金鑰。如要保護不屬於資料集的資源,您必須在專案或組織層級建立自己的預設金鑰。 |
每項資源一個金鑰 |
| Bigtable |
Autokey 會為叢集建立金鑰。 Autokey 不會為叢集以外的 Bigtable 資源建立金鑰。 Bigtable 與 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 Google Cloud SDK 建立的資源。 |
每個叢集一個金鑰 |
| Cloud Run |
|
專案中每個位置一個金鑰 |
| Cloud SQL |
Autokey 不會為 Cloud SQL Cloud SQL 和 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Cloud Storage |
儲存空間 bucket 中的物件會使用 bucket 預設金鑰。Autokey 不會為 |
每個值區一個鍵 |
| Compute Engine |
快照會使用您要建立快照的磁碟金鑰。
Autokey 不會為 |
每項資源一個金鑰 |
| Google Kubernetes Engine |
Google Kubernetes Engine 和 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每個叢集一個金鑰 |
| Dataflow |
|
每項資源一個金鑰 |
| Datastream |
Datastream 和 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Document AI |
保護處理器的金鑰必須與處理器位於相同位置,但多區域除外: |
每項資源一個金鑰 |
| Managed Service for Apache Airflow |
|
每項資源一個金鑰 |
| Managed Service for Apache Spark |
|
Cluster、SessionTemplate 和 WorkflowTemplate 資源:每項資源一個金鑰 批次和工作階段資源:專案中每個位置一個金鑰 |
| Memorystore for Redis |
只有使用 Terraform 或 REST API 建立的資源,才能整合 Memorystore for Redis 和 Cloud KMS Autokey。 |
每項資源一個金鑰 |
| Memorystore for Valkey |
只有使用 Terraform 或 REST API 建立的資源,才能整合 Memorystore for Valkey 和 Cloud KMS Autokey。 |
每項資源一個金鑰 |
| Migrate to Virtual Machines |
Migrate to Virtual Machines 與 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Pub/Sub |
|
每項資源一個金鑰 |
| Secret Manager |
Secret Manager 和 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
專案中每個位置一個金鑰 |
| Secure Source Manager |
|
每項資源一個金鑰 |
| Spanner |
Spanner 和 Cloud KMS Autokey 之間的整合功能,僅適用於使用 Terraform 或 REST API 建立的資源。 |
每項資源一個金鑰 |
| Filestore |
|
每項資源一個金鑰 |
| Workflows |
只有使用 Terraform 或 REST API 建立的資源,才能整合 Workflows 和 Cloud KMS Autokey。 |
每項資源一個金鑰 |
後續步驟
- 如要開始使用 Cloud KMS Autokey,管理員必須啟用 Cloud KMS Autokey。
- 啟用 Cloud KMS Autokey 後,開發人員可以使用 Autokey 建立受 CMEK 保護的資源。
- 瞭解 CMEK 建議做法。