Secret Manager 最佳做法

本指南介紹使用 Secret Manager 的幾項最佳做法。指南內容並非詳盡的建議清單。建議您先參閱平台總覽，瞭解整體 Google Cloud 環境和 Secret Manager 總覽，再閱讀本指南。

存取權控管

Secret Manager API 的存取權受到 IAM 保護。 授予密鑰權限時，請遵循最低權限原則。

您必須提供憑證，才能向 Secret Manager API 進行驗證。所有用戶端程式庫都使用類似策略來尋找憑證，也就是應用程式預設憑證。

  • 在本機開發時，請使用 gcloud auth application-default login。這會建立含有憑證的檔案，用戶端程式庫會自動擷取憑證。

  • 在 Compute Engine 和其他 Google Cloud 運算平台 (例如 Cloud Run 函式) 上，用戶端程式庫會透過執行個體中繼資料伺服器取得憑證。

  • 在 GKE 上，工作負載身分也會透過中繼資料服務提供憑證。

  • 在 Amazon Web Services 或 Microsoft Azure 等其他平台上，請考慮設定工作負載身分聯盟，這項功能會使用現有的身分機制向 API 進行驗證。 Google Cloud

相較於匯出服務帳戶憑證，這些方法更為理想，因為不需要在 Secret Manager API 以外安全地儲存及存取額外的密鑰。

程式設計實務

請避免透過檔案系統或環境變數將密鑰傳遞至應用程式。以下是使用其他密鑰處理方法的部分原因：

  • 如果機密資訊可透過檔案系統存取，應用程式安全漏洞 (例如目錄遍歷攻擊) 的嚴重程度可能會提高，因為攻擊者可能因此取得讀取機密資料的能力。

  • 透過環境變數使用密鑰時，如果設定錯誤 (例如啟用偵錯端點或加入會記錄程序環境詳細資料的依附元件)，可能會導致密鑰外洩。

  • 將密鑰資料同步至其他資料存放區 (例如 Kubernetes Secrets) 時，請評估該資料存放區提供的存取權控管設定。請考量下列事項：

    • 資料儲存區是否會擴大密鑰的存取權？

    • 可以稽核密鑰的存取權嗎？

    • 資料儲存區是否符合您的待用資料加密和區域化需求？

建議您使用我們提供的其中一個用戶端程式庫，直接使用 Secret Manager API，或參閱 REST 或 GRPC 文件。

管理

請使用版本號碼參照密鑰，而非使用最新別名。使用現有的發布程序，將更新部署至版本號碼。這通常是指使用啟動時讀取的特定密鑰版本設定應用程式。雖然使用最新別名可能很方便，但如果新版密鑰發生問題，工作負載可能就無法使用密鑰版本。將設定固定至特定版本號碼後，即可使用現有的發布程序驗證及回溯設定。

請先停用密鑰版本，再刪除密鑰或銷毀密鑰版本。這項功能會將密鑰設為與銷毀相同的狀態，但可還原，有助於避免服務中斷。也就是說，您可以先停用資料並等待一週，確認沒有任何未解決的依附元件，再永久刪除資料。

除非確定要永久刪除，否則請勿為正式環境密鑰設定到期時間。這項功能最適合自動清除臨時環境。建議您考慮使用以時間為依據的 IAM 條件，取代會過期的密鑰。

定期輪替密鑰，以達到下列目的：

  • 如果密鑰外洩，可將影響降至最低。

  • 確保不再需要存取密鑰的使用者無法繼續使用先前存取的密鑰。

  • 降低服務中斷的可能性。

基於下列原因，請使用 Cloud Asset Inventory 監控整個機構的密碼：

  • 協助找出貴機構的密鑰。

  • 找出不符合機構需求的項目，例如輪替、加密設定和位置。

啟用資料存取記錄，即可取得並分析 AccessSecretVersion 要求資訊。在資料夾或機構層級啟用這項功能，即可強制執行記錄，不必在每個密鑰或專案中設定。

除了 IAM 控制項，您也可以為機構設定 VPC Service Controls 範圍，透過網路控管功能限制 Secret Manager API 的存取權。

constraints/iam.allowedPolicyMemberDomains機構政策可用於限制可新增至密碼 IAM 政策的身分。

預估密鑰用量尖峰 (考量到因應用程式並行部署或服務自動調度資源而導致的大量請求)，並確保專案有足夠配額可處理這類事件。如需更多配額，請申請提高配額。

資料落地法規遵循

如果您有嚴格的資料落地和資料主權需求，請選擇區域性密鑰。區域性密鑰可讓您將私密資料儲存在特定地理位置，並提供完整的靜態、使用中及傳輸中保證，協助您遵守資料落地相關的法律、法規或機構規定。