長效金鑰是資安團隊最不想承認的未爆彈

一組 Service Account JSON 金鑰檔，預設沒有過期時間。它可能被下載到某個工程師的筆電、貼進某個 CI/CD 腳本、甚至意外 commit 進版本控制系統——而且很多時候，即使外洩了也不會有任何警訊，因為它「本來就能正常運作」，沒有異常登入通知這種機制會主動提醒你。

這也是為什麼 Day3 提到的 Org Policy Constraint constraints/iam.disableServiceAccountKeyCreation 值得認真考慮全組織強制啟用——但在真正做到「完全不用金鑰檔」（Day9 的 Workload Identity Federation）之前，多數企業還是會有一段過渡期需要管理金鑰。

如果還離不開金鑰檔，至少做到這幾件事

強制輪替週期：金鑰不該無限期存在，建議設定 90 天輪替一次，並在輪替前後有一段重疊期（新舊金鑰並存），避免服務中斷。

絕不落地明碼儲存：金鑰檔不該出現在程式碼倉庫、CI/CD 環境變數的明碼欄位，或是筆電的下載資料夾。統一存進 Secret Manager，服務啟動時動態讀取。

监控金鑰的最後使用時間：

# 列出某個 Service Account 的所有金鑰與最後使用時間

gcloud iam service-accounts keys list \

--iam-account=SERVICE_ACCOUNT_EMAIL \

--format="table(name, validAfterTime, keyType)"

待實測提醒：gcloud iam service-accounts keys list 的輸出欄位是否包含明確的「最後使用時間」，會依 gcloud 版本與 API 而定，建議實際跑一次確認目前版本輸出格式，正式發布時附上真實輸出截圖。

找出從未被使用的殭屍金鑰：很多金鑰是專案初期建立後就沒人記得刪除。定期盤點「建立超過 90 天但從未在 Cloud Audit Logs 出現呼叫紀錄」的金鑰，這類金鑰通常代表可以直接停用。

金鑰外洩後的止血順序

如果真的發生金鑰外洩，止血順序建議是：先停用（disable）金鑰而不是直接刪除，確認停用後沒有預期外的服務中斷，再正式刪除；同時檢查 Cloud Audit Logs 裡這組憑證在外洩期間的所有 API 呼叫紀錄，確認有沒有異常行為。

這篇的檢查清單

• [ ] 是否已設定金鑰輪替週期（建議 90 天）？
• [ ] 金鑰是否統一存放在 Secret Manager，而非程式碼或明碼環境變數？
• [ ] 是否定期盤點並清除長期未使用的殭屍金鑰？

明天要講的 Workload Identity Federation，是徹底解決這個問題的方式——讓外部系統完全不需要下載金鑰檔就能存取 GCP 資源。