服務帳戶金鑰通常用於向Google Cloud 服務進行驗證。不過,如果管理不當,也可能造成安全風險,增加您遭受憑證外洩、權限提升、資訊揭露和不可否認等威脅的機率。
在許多情況下,您都可以使用比服務帳戶金鑰更安全的替代方案進行驗證。本指南可協助您從使用服務帳戶金鑰做為主要驗證機制,改用更安全的替代方案,但偶爾仍有必要使用服務帳戶金鑰。
本文適用於安全管理員,他們希望減少服務帳戶金鑰的使用量,改用更安全的驗證機制,以提升安全防護。這些安全管理員可能負責現有正式環境工作負載、開發人員工作流程,以及使用服務帳戶金鑰的內部程序安全。
總覽
從現有工作負載中移除服務帳戶金鑰時,請務必謹慎規劃,以免發生意外中斷。以下移轉計畫旨在讓您強制執行集中式控管,同時盡量減少對開發人員的干擾。
這項遷移計畫包含三個階段:
- 評估:在這個階段,您會評估現有環境,瞭解服務帳戶金鑰所在位置,以及金鑰是否正在使用中。
- 規劃:在這個階段,您要決定最終部署哪些控制項,並向利害關係人說明遷移計畫。
- 部署:在這個階段,您會開始重構工作負載,改用比服務帳戶金鑰更安全的替代方案進行驗證。您也可以建構額外功能,持續監控環境並降低未來風險。
評估服務帳戶金鑰的使用情形
在這個階段,您會評估現有環境,瞭解服務帳戶金鑰的所在位置,以及金鑰是否正在使用中。
下列各節說明您可以收集哪些資料,進一步瞭解貴機構如何使用服務帳戶金鑰。
收集主要使用情況資料
首先,請找出服務帳戶金鑰所在位置,以及使用方式。
Google Cloud 提供工具,協助您瞭解服務帳戶用量。這些工具可協助您判斷最近用於驗證的服務帳戶和金鑰、過去 90 天內未使用的服務帳戶,以及具有過多權限角色的服務帳戶。
您可以結合所有這些工具的資訊,進一步瞭解貴機構的服務帳戶和金鑰使用情形。 如要查看如何整合整個機構中各種來源的資訊,請參閱 GitHub 上的可部署的參考架構。這個參考架構會匯總各種工具的資料,並定期匯出至 BigQuery 資料表以供分析。
參考架構會部署資料管道,查詢 Cloud Asset Inventory,找出您機構中的服務帳戶金鑰。然後,資料管道會將這些資料與相關聯帳戶的金鑰和權限使用情況資料合併。產生的資料表 (sa_key_usage
) 可協助您回答下列問題:
- 已建立多少個持續性金鑰?這個數字可做為高階指標,追蹤您從金鑰遷移的進度。
- 哪些專案和服務帳戶使用金鑰?這項資訊有助於找出使用服務帳戶金鑰的工作負載擁有者。
- 哪些車鑰已停用?您可能可以刪除這些金鑰,而不需工作負載擁有者進一步評估。
- 哪些金鑰與服務帳戶相關聯,且這些服務帳戶有權限過多的建議?如果服務帳戶金鑰與權限過高的服務帳戶 (尤其是具備「擁有者」、「編輯者」或「檢視者」角色的帳戶) 相關聯,該金鑰的風險可能特別高。尋找有角色建議的服務帳戶,有助於找出權限過多的服務帳戶。找出這些服務帳戶後,您可能會決定優先移轉這些工作負載。您也可以選擇套用角色建議,主動減少多餘權限。
這個資料管道每天都會執行,並將資料寫入以日期為分區的 BigQuery 資料表。您可以使用這個表格調查特定服務帳戶或金鑰,也可以使用 Looker Studio 等資訊主頁工具追蹤補救進度。
提供額外背景資訊,充實金鑰使用資料
收集金鑰使用情形的資料後,您可以選擇使用其他資料來源來擴充資料。建議您新增已用於追蹤資源管理和出處的資料來源。視現有的管理機制而定,您可能會新增下列額外資料:
- 來自設定管理資料庫 (CMDB) 或類似系統的擁有權資訊。
- 在專案標籤中設定的控管資訊,例如負責專案的團隊或成本中心。
- 環境資訊:用於 Google Cloud外部環境中工作負載的金鑰。
制定減少服務帳戶金鑰用量的計畫
如要部署任何變更來減少服務帳戶金鑰用量,請先判斷哪些工作負載和環境會受到影響,以及如何強制執行這些變更。此外,您也必須在整個商家中傳達這項計畫,並確保工作負載擁有者支援這項計畫。
以下各節將介紹企劃書應涵蓋的重要主題。具體方案會因貴機構的規模和工作負載的具體需求而異。
決定目前工作負載擁有者的責任
雖然中央安全團隊可以評估現有的金鑰,但如要順利遷移,工作負載擁有者必須付出心力。如要遷移範圍內的金鑰,工作負載擁有者必須判斷哪種可用驗證方法適用於自己的用途,然後執行遷移作業。
請考量如何平衡現有安全防護機制的改善措施,以及工作負載擁有者所需付出的心力。以下各節說明兩種範例做法:一種是著重改善安全狀態,另一種是著重盡量減少工作負載擁有者的工作量。實際做法可能因人而異,例如,您可能會決定個別選取範圍內的工作負載。
示例:評估所有目前的工作負載是否適合遷移
其中一種做法是針對所有現有和未來的工作負載,強制執行服務帳戶金鑰控制項。這包括下列步驟:
- 與工作負載擁有者合作,評估現有工作負載的主要用途。
- 要求工作負載擁有者遷移所有使用金鑰的現有工作負載,除非已獲得例外情況許可。
- 禁止所有日後的工作負載使用服務帳戶金鑰,除非已獲得例外狀況授權。
這種做法會優先改善現有的安全防護措施,但短期內需要開發人員和工作負載擁有者投入更多心力。如要順利執行這類計畫,您必須取得工作負載擁有者的承諾,參與工作負載審查和重構。
示例:目前沒有任何工作負載經過評估,可供遷移
另一種做法是允許現有工作負載自動例外,繼續使用服務帳戶金鑰,並只對日後的工作負載套用新控管措施。
這種做法可提升日後工作負載的安全性,並盡量減少目前工作負載擁有者的責任。但無法提升現有工作負載的安全防護機制。
找出速效做法
在評估過程中,您可能會發現可以安全刪除的金鑰,且工作負載擁有者不必進行進一步的補救措施。舉例來說,如果金鑰 90 天內沒有任何活動,或是與不再有效的資源相關聯,您或許可以安全地移除金鑰,無須遷移至其他驗證機制。
列出符合這項條件的鍵。您會在部署階段使用這份清單刪除不必要的金鑰。將金鑰新增至清單前,請確認是否有需要不時使用服務帳戶金鑰的用途,例如依賴服務帳戶金鑰的緊急生產環境存取權。
規劃要在何處強制執行機構政策變更
如要順利停用服務帳戶金鑰,您必須禁止建立新金鑰。在部署階段,您會強制執行 iam.disableServiceAccountKeyCreation
機構政策限制,防止建立新的服務帳戶金鑰。
雖然這項限制不會禁止使用現有金鑰,但可能會中斷定期輪替金鑰的現有工作負載。開始部署階段前,請先決定要在資源階層中強制執行這項政策,盡量減少中斷。
您可能偏好先在專案或資料夾層級強制執行限制,而非機構層級。舉例來說,您可以在將開發環境部署至正式版資料夾之前,先對開發環境使用的資料夾強制執行限制。或者,在擁有許多團隊的大型機構中,您可能會先對單一團隊的資料夾強制執行限制,然後在遷移其他資料夾時,對這些資料夾強制執行限制。
您可以搭配標記使用機構政策,在專案或資料夾層級有條件地強制執行機構政策。
設計例外狀況處理程序
雖然這次遷移的目標是減少或淘汰服務帳戶金鑰的使用,但仍有部分正當用途需要服務帳戶金鑰。即使現有工作負載不需要服務帳戶金鑰,日後的工作負載也可能需要。因此,您必須定義作業程序,評估並核准需要服務帳戶金鑰的使用情境例外狀況。
為工作負載擁有者定義例外狀況要求程序,允許工作負載使用服務帳戶金鑰。請確保負責授予例外的決策者具備技術知識,可驗證用途、諮詢工作負載擁有者,瞭解哪些服務帳戶金鑰的替代方案較安全,並向工作負載擁有者提供管理服務帳戶金鑰的最佳做法。
向工作負載擁有者說明近期異動
設計好計畫後,您需要向整個機構清楚說明該計畫,並確保利害關係人 (尤其是高階領導人) 願意投入遷移作業。
雖然貴機構的具體遷移細節會有所不同,但建議在通訊計畫中納入下列主題:
- 不安全的服務帳戶金鑰對機構造成的負面影響,以及促使您捨棄服務帳戶金鑰的動機。
- 防止建立服務帳戶金鑰的新安全控管措施,以及這項措施對現有程序的影響。
- 為開發人員提供指引,協助他們找出比服務帳戶金鑰更安全的替代方案。
- 團隊申請服務帳戶金鑰例外狀況的程序,包括重新評估例外狀況的頻率。
- 強制執行建議變更的時間表。
與工作負載擁有者合作,修正計畫並確保計畫適用於整個機構。
部署控制項並重構工作負載
建立計畫並通知工作負載擁有者後,即可開始從服務帳戶金鑰遷移。
在這個階段,您會開始重構工作負載,改用比服務帳戶金鑰更安全的替代方案進行驗證。您也可以建構其他功能,持續監控環境並降低日後風險。
以下各節說明如何重構工作負載及刪除金鑰,盡量減少中斷。您可以根據貴機構的優先順序和所需工作量,選擇以任何順序執行這些步驟。
強制執行控管措施,禁止建立新的服務帳戶金鑰
如要停止建立新的服務帳戶金鑰,請強制執行iam.disableServiceAccountKeyCreation
機構政策限制。
不過,在強制執行這項限制之前,您需要將標記新增至任何不受政策限制的專案或資料夾。對於無法從服務帳戶金鑰遷移的現有工作負載,或是僅以服務帳戶金鑰進行驗證的新工作負載,您或許可以允許例外狀況。
為豁免專案和資料夾新增標記後,您可以設定含有標記的機構政策,針對非豁免專案和資料夾強制執行 iam.disableServiceAccountKeyCreation
限制。
如要禁止在所有非豁免專案和資料夾中建立服務帳戶金鑰,請按照下列步驟操作:
-
確認您在機構層級具備代碼管理員角色 (
roles/resourcemanager.tagAdmin
) 和機構政策管理員角色 (roles/orgpolicy.policyAdmin
)。如要瞭解如何在機構層級授予角色,請參閱「管理專案、資料夾和機構的存取權」。 -
在機構層級建立標記鍵和標記值,用於定義資源是否應豁免於機構政策。建議您建立含有
disableServiceAccountKeyCreation
鍵和enforced
與not_enforced
值的標記。如要瞭解如何建立代碼鍵和代碼值,請參閱建立及定義新代碼。
-
將
disableServiceAccountKeyCreation
標記附加至機構,並將值設為enforced
。除非以其他標記值覆寫,否則組織中的所有資源都會繼承這個標記值。如要瞭解如何將標記附加至資源,請參閱將標記附加至資源。
-
如要為專案或資料夾免除機構政策限制,請附加
disableServiceAccountKeyCreation
標記,並將值設為not_enforced
。以這種方式為專案或資料夾設定標記值,會覆寫從機構沿用的標記值。 -
建立機構政策,禁止為所有資源 (豁免資源除外) 建立服務帳戶金鑰。這項政策應包含下列規則:
-
設定
iam.disableServiceAccountKeyCreation
限制,確保系統不會對任何含有disableServiceAccountKeyCreation: not_enforced
標記的資源強制執行這項限制。這項規則中的條件應如下所示:"resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced')"
-
設定
iam.disableServiceAccountKeyCreation
限制,以強制執行所有其他資源。
-
修正現有工作負載
針對使用服務帳戶金鑰的每個工作負載,請與工作負載擁有者合作,選擇並實作替代驗證方法。
使用 Google Cloud CLI、Cloud 用戶端程式庫、支援 應用程式預設憑證 (ADC) 的工具 (例如 Terraform) 或 REST 要求存取服務時,請參考下圖選擇驗證方法: Google Cloud
這張圖表會引導您思考下列問題:
-
您是否在單一使用者開發環境中執行程式碼,例如自己的工作站、Cloud Shell 或虛擬桌面介面?
- 如果是,請繼續進行問題 4。
- 如果沒有,請繼續回答問題 2。
- 您是否在 Google Cloud中執行程式碼?
- 如果是,請繼續進行問題 3。
- 如果沒有,請繼續進行問題 5。
- 您是否在 Google Kubernetes Engine 中執行容器?
- 如果是,請使用 Workload Identity Federation for GKE,將服務帳戶附加至 Kubernetes Pod。
- 如果沒有,請將服務帳戶附加至資源。
-
您的用途是否需要服務帳戶?
舉例來說,您想為所有環境中的應用程式,設定一致的驗證和授權方式。
- 如果沒有,請使用使用者憑證進行驗證。
- 如果是,請 使用使用者憑證模擬服務帳戶。
-
您的工作負載是否透過支援工作負載身分聯盟的外部識別資訊提供者進行驗證?
- 如果是,請 設定 Workload Identity Federation,讓在內部部署或其他雲端服務供應商執行的應用程式使用服務帳戶。
- 如果沒有,請建立服務帳戶金鑰。
在某些情況下,您可能只能使用服務帳戶金鑰,無法使用其他驗證方法。以下是服務帳戶金鑰可能是唯一可行選項的範例:
- 您使用的商用現成產品 (COTS) 或軟體即服務 (SaaS) 應用程式,要求您直接在使用者介面中輸入Google Cloud 服務帳戶金鑰。
- 您的工作負載在 Google Cloud 以外的環境中執行,且未透過支援工作負載身分同盟的識別資訊提供者進行驗證。
如果必須繼續使用服務帳戶金鑰,請務必遵循管理服務帳戶金鑰的最佳做法。
您也可能評估後認為,繼續使用服務帳戶金鑰的風險,不值得改用其他驗證方法,因此決定不修正特定工作負載。
刪除不必要的金鑰
如果確定不需要服務帳戶金鑰,請刪除金鑰。非必要鍵包括:
近期沒有使用過的金鑰,或是與您在本頁「找出能快速獲效的切入點」一節中找到的未使用資源相關的金鑰。
已遷移至其他驗證方法的工作負載金鑰。
刪除專案中的所有服務帳戶金鑰後,請確保該專案強制執行
iam.disableServiceAccountKeyCreation
限制。如果專案先前不受這項限制,請移除允許豁免的標記。
為安全刪除金鑰,建議您先停用金鑰,再刪除。刪除後就無法復原,但停用後,如果發現非預期問題,可以快速重新啟用金鑰。停用金鑰後,請等待一段時間,確認永久移除金鑰不會造成問題,再刪除金鑰。如果停用金鑰後發現非預期問題,請重新啟用金鑰、解決問題,然後重複上述程序,直到可以安全刪除金鑰為止。
使用內建控制項回應外洩的金鑰
Google Cloud 提供工具和服務,協助您偵測及回應外洩的服務帳戶金鑰。建議使用下列機制,協助您處理服務帳戶金鑰外洩問題:
- 服務帳戶金鑰外洩因應措施限制可讓您自動停用偵測到的外洩金鑰。 Google Cloud
持續改善服務帳戶管理功能
請盡可能採用管理服務帳戶金鑰的最佳做法。改善金鑰管理程序有助於降低貴機構中任何剩餘服務帳戶金鑰的風險。