本頁面中的部分或全部資訊可能不適用於 Trusted Cloud by S3NS。
服務帳戶金鑰輪替
服務帳戶金鑰是私密金鑰,可讓您以服務帳戶身分進行驗證。金鑰輪替是指以新金鑰取代現有金鑰,然後使取代的金鑰失效。建議您定期輪替管理的所有金鑰,包括服務帳戶金鑰。
輪替服務帳戶金鑰有助於降低金鑰外洩或遭竊帶來的風險。如果金鑰外洩,惡意行為者可能要過幾天或幾週才會發現。定期輪替服務帳戶金鑰,可提高遭外洩金鑰失效的機率,避免遭到惡意人士利用。
建立服務帳戶金鑰輪替程序,也有助於在懷疑服務帳戶金鑰遭盜用時迅速採取行動。
金鑰輪替頻率
建議您至少每 90 天輪替一次金鑰,以降低金鑰外洩帶來的風險。
如果您認為服務帳戶金鑰遭到盜用,建議立即輪替金鑰。
金鑰輪替程序
如要輪替服務帳戶金鑰,請按照下列步驟操作:
- 找出需要輪替的服務帳戶金鑰。
- 為相同服務帳戶建立新金鑰。
- 在所有應用程式中,以新金鑰取代現有金鑰。
- 停用已替換的金鑰,並監控應用程式,確認應用程式是否正常運作。
- 刪除已取代的服務帳戶金鑰。
您可以透過集中式密鑰管理服務或自訂通知系統完成這些步驟。
集中式密鑰管理服務
許多集中式密鑰管理服務 (例如 HashiCorp Vault) 都提供自動密鑰輪替功能。您可以使用這些服務儲存及輪替服務帳戶金鑰。
我們不建議使用 Azure KeyVault 和 AWS Secret Manager 等雲端式密鑰管理服務,儲存及輪替服務帳戶金鑰。這是因為應用程式需要雲端供應商可辨識的身分,才能存取這些儲存的密鑰。如果應用程式已有雲端供應商可辨識的身分,應用程式就能使用該身分進行驗證,不必使用服務帳戶金鑰。
自訂通知系統
服務帳戶金鑰輪替的另一種做法是建立系統,在需要輪替金鑰時傳送通知。舉例來說,您可以建立系統,在偵測到超過 90 天前建立的金鑰時傳送快訊。
首先,您需要找出需要輪替的金鑰。如要找出這些金鑰,建議使用 Cloud Asset Inventory 搜尋特定時間前建立的所有服務帳戶金鑰。
舉例來說,下列指令會列出 ID 為 123456789012
的機構中,在 2023-03-10 00:00:00 UTC
之前建立的所有服務帳戶金鑰:
gcloud asset search-all-resources \
--scope="organizations/123456789012" \
--query="createTime < 2023-03-10" \
--asset-types="iam.googleapis.com/ServiceAccountKey" \
--order-by="createTime"
如要進一步瞭解如何在 Cloud Asset Inventory 中搜尋資源,請參閱「搜尋資源」。找出需要輪替的金鑰後,您可以向適當的團隊傳送通知。
收到輪替金鑰通知的使用者應採取下列行動:
- 為同一個服務帳戶建立新金鑰。
- 在所有應用程式中,以新金鑰取代現有金鑰。
- 停用取代的金鑰,並監控應用程式,確認應用程式是否正常運作。
- 確認應用程式運作正常後,刪除已替換的金鑰。
服務帳戶金鑰到期
我們不建議使用會過期的服務帳戶金鑰進行金鑰輪替。這是因為如果未適當輪替金鑰,過期的金鑰可能會導致服務中斷。如要進一步瞭解服務帳戶金鑰到期的用途,請參閱使用者代管金鑰的到期時間。
後續步驟
建立、停用及刪除服務帳戶金鑰。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-21 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-08-21 (世界標準時間)。"],[[["Service account keys should be rotated regularly, ideally at least every 90 days, to mitigate the risks associated with leaked or stolen keys."],["Rotating service account keys involves creating new keys, replacing existing ones in applications, disabling the old keys, and then deleting the replaced keys after confirmation that the applications are working correctly."],["Centralized secret management services like HashiCorp Vault can be used for automatic key rotation, but cloud-based secret managers are not recommended if the application already has an identity."],["A custom notification system can be implemented to alert teams when service account keys need rotation, leveraging Cloud Asset Inventory to identify keys based on their creation time."],["Expiring service account keys are not advised for key rotation due to the potential for outages if not managed properly; instead, using the rotation process is preferred."]]],[]]