從服務帳戶金鑰遷移

服務帳戶金鑰通常用於向Cloud de Confiance by S3NS 服務進行驗證。不過，如果管理不當，也可能造成安全風險，增加您遭受憑證外洩、權限提升、資訊揭露和不可否認等威脅的機率。

在許多情況下，您都可以使用比服務帳戶金鑰更安全的替代方案進行驗證。本指南可協助您從使用服務帳戶金鑰做為主要驗證機制，改用更安全的替代方案，但偶爾仍有必要使用服務帳戶金鑰。

本文適用於安全管理員，他們希望減少服務帳戶金鑰的使用量，改用更安全的驗證機制，以提升安全防護。這些安全管理員可能負責現有正式環境工作負載、開發人員工作流程，以及使用服務帳戶金鑰的內部程序安全。

總覽

從現有工作負載中移除服務帳戶金鑰時，請務必謹慎規劃，以免發生意外中斷。以下移轉計畫旨在讓您強制執行集中式控管，同時盡量減少對開發人員的干擾。

這項遷移計畫包含三個階段：

  • 評估：在這個階段，您會評估現有環境，瞭解服務帳戶金鑰所在位置，以及金鑰是否正在使用中。
  • 規劃：在這個階段，您要決定最終部署哪些控制項，並向利害關係人說明遷移計畫。
  • 部署：在這個階段，您會開始重構工作負載，改用比服務帳戶金鑰更安全的替代方案進行驗證。您也可以建構額外功能，持續監控環境並降低未來風險。

評估服務帳戶金鑰的使用情形

在這個階段，您會評估現有環境，瞭解服務帳戶金鑰的所在位置，以及金鑰是否正在使用中。

下列各節說明您可以收集哪些資料，進一步瞭解貴機構如何使用服務帳戶金鑰。

收集主要使用情況資料

首先，請找出服務帳戶金鑰所在位置，以及使用方式。

您可以使用 Cloud Monitoring 瞭解服務帳戶和金鑰的使用情形。舉例來說，您可以查看服務帳戶金鑰用於驗證的頻率，或是服務帳戶上次驗證的時間。

詳情請參閱「監控服務帳戶和金鑰的使用模式」。

提供額外背景資訊，充實金鑰使用資料

收集金鑰使用情形的資料後，您可以選擇使用其他資料來源來擴充資料。建議您新增已用於追蹤資源管理和出處的資料來源。視現有的管理機制而定，您可能會新增下列額外資料：

  • 來自設定管理資料庫 (CMDB) 或類似系統的擁有權資訊。
  • 在專案標籤中設定的控管資訊，例如負責專案的團隊或成本中心。
  • 環境資訊：用於 Cloud de Confiance外部環境中工作負載的金鑰。

制定減少服務帳戶金鑰用量的計畫

如要部署任何變更來減少服務帳戶金鑰用量，請先判斷哪些工作負載和環境會受到影響，以及如何強制執行這些變更。此外，您也必須在整個商家中傳達這項計畫，並確保工作負載擁有者支援這項計畫。

以下各節將介紹企劃書應涵蓋的重要主題。具體方案會因貴機構的規模和工作負載的具體需求而異。

決定目前工作負載擁有者的責任

雖然中央安全團隊可以評估現有的金鑰，但如要順利遷移，工作負載擁有者必須付出心力。如要遷移範圍內的金鑰，工作負載擁有者必須判斷哪種可用驗證方法適用於自己的用途，然後執行遷移作業。

請考量如何平衡現有安全防護機制的改善措施，以及工作負載擁有者所需付出的心力。以下各節說明兩種範例做法：一種是著重改善安全狀態，另一種是著重盡量減少工作負載擁有者的工作量。實際做法可能因人而異，例如，您可能會決定個別選取範圍內的工作負載。

示例：評估所有目前的工作負載是否適合遷移

其中一種做法是針對所有現有和未來的工作負載，強制執行服務帳戶金鑰控制項。這包括下列步驟：

  • 與工作負載擁有者合作，評估現有工作負載的主要用途。
  • 要求工作負載擁有者遷移所有使用金鑰的現有工作負載，除非已獲得例外情況許可。
  • 禁止所有日後的工作負載使用服務帳戶金鑰，除非已獲得例外狀況授權。

這種做法會優先改善現有的安全防護措施，但短期內需要開發人員和工作負載擁有者投入更多心力。如要順利執行這類計畫，您必須取得工作負載擁有者的承諾，參與工作負載審查和重構。

示例：目前沒有任何工作負載經過評估，可供遷移

另一種做法是允許現有工作負載自動例外，繼續使用服務帳戶金鑰，並只對日後的工作負載套用新控管措施。

這種做法可提升日後工作負載的安全性，並盡量減少目前工作負載擁有者的責任。但無法提升現有工作負載的安全防護機制。

找出速效做法

在評估過程中，您可能會發現可以安全刪除的金鑰，且工作負載擁有者不必進行進一步的補救措施。舉例來說，如果金鑰 90 天內沒有任何活動，或是與不再有效的資源相關聯，您或許可以安全地移除金鑰，無須遷移至其他驗證機制。

列出符合這項條件的鍵。您會在部署階段使用這份清單刪除不必要的金鑰。將金鑰新增至清單前，請確認是否有需要不時使用服務帳戶金鑰的用途，例如依賴服務帳戶金鑰的緊急生產環境存取權。

規劃要在何處強制執行機構政策變更

如要順利停用服務帳戶金鑰，您必須禁止建立新金鑰。在部署階段，您會強制執行 iam.disableServiceAccountKeyCreation 機構政策限制，防止建立新的服務帳戶金鑰。

雖然這項限制不會禁止使用現有金鑰，但可能會中斷定期輪替金鑰的現有工作負載。開始部署階段前，請先決定要在資源階層中強制執行這項政策，盡量減少中斷。

您可能偏好先在專案或資料夾層級強制執行限制，而非機構層級。舉例來說，您可以在將開發環境部署至正式版資料夾之前，先對開發環境使用的資料夾強制執行限制。或者，在擁有許多團隊的大型機構中，您可能會先對單一團隊的資料夾強制執行限制，然後在遷移其他資料夾時，對這些資料夾強制執行限制。

您可以搭配標記使用機構政策，在專案或資料夾層級有條件地強制執行機構政策。

設計例外狀況處理程序

雖然這次遷移的目標是減少或淘汰服務帳戶金鑰的使用，但仍有部分正當用途需要服務帳戶金鑰。即使現有工作負載不需要服務帳戶金鑰，日後的工作負載也可能需要。因此，您必須定義作業程序，評估並核准需要服務帳戶金鑰的使用情境例外狀況。

為工作負載擁有者定義例外狀況要求程序，允許工作負載使用服務帳戶金鑰。請確保負責授予例外的決策者具備技術知識，可驗證用途、諮詢工作負載擁有者，瞭解哪些服務帳戶金鑰的替代方案較安全，並向工作負載擁有者提供管理服務帳戶金鑰的最佳做法。

向工作負載擁有者說明近期異動

設計好計畫後，您需要向整個機構清楚說明該計畫，並確保利害關係人 (尤其是高階領導人) 願意投入遷移作業。

雖然貴機構的具體遷移細節會有所不同，但建議在通訊計畫中納入下列主題：

  • 不安全的服務帳戶金鑰對機構造成的負面影響，以及促使您捨棄服務帳戶金鑰的動機。
  • 防止建立服務帳戶金鑰的新安全控管措施，以及這項措施對現有程序的影響。
  • 為開發人員提供指引，協助他們找出比服務帳戶金鑰更安全的替代方案。
  • 團隊申請服務帳戶金鑰例外狀況的程序，包括重新評估例外狀況的頻率。
  • 強制執行建議變更的時間表。

與工作負載擁有者合作，修正計畫並確保計畫適用於整個機構。

部署控制項並重構工作負載

建立計畫並通知工作負載擁有者後，即可開始從服務帳戶金鑰遷移。

在這個階段，您會開始重構工作負載，改用比服務帳戶金鑰更安全的替代方案進行驗證。您也可以建構其他功能，持續監控環境並降低日後風險。

以下各節說明如何重構工作負載及刪除金鑰，盡量減少中斷。您可以根據貴機構的優先順序和所需工作量，選擇以任何順序執行這些步驟。

強制執行控管措施，禁止建立新的服務帳戶金鑰

如要停止建立新的服務帳戶金鑰，請強制執行iam.disableServiceAccountKeyCreation機構政策限制。

不過，在強制執行這項限制之前，您需要將標記新增至任何不受政策限制的專案或資料夾。對於無法從服務帳戶金鑰遷移的現有工作負載，或是僅以服務帳戶金鑰進行驗證的新工作負載，您或許可以允許例外狀況。

為豁免專案和資料夾新增標記後，您可以設定含有標記的機構政策，針對非豁免專案和資料夾強制執行 iam.disableServiceAccountKeyCreation 限制。

如要禁止在所有非豁免專案和資料夾中建立服務帳戶金鑰，請按照下列步驟操作：

  1. 確認您在機構層級具備代碼管理員角色 (roles/resourcemanager.tagAdmin) 和機構政策管理員角色 (roles/orgpolicy.policyAdmin)。如要瞭解如何在機構層級授予角色，請參閱「管理專案、資料夾和機構的存取權」。

  2. 在機構層級建立標記鍵和標記值，用於定義資源是否應豁免於機構政策。建議您建立含有 disableServiceAccountKeyCreation 鍵和 enforced 與 not_enforced 值的標記。

    如要瞭解如何建立代碼鍵和代碼值，請參閱建立及定義新代碼。

  3. 將 disableServiceAccountKeyCreation 標記附加至機構，並將值設為 enforced。除非以其他標記值覆寫，否則組織中的所有資源都會繼承這個標記值。

    如要瞭解如何將標記附加至資源，請參閱將標記附加至資源。

  4. 如要為專案或資料夾免除機構政策限制，請附加 disableServiceAccountKeyCreation 標記，並將值設為 not_enforced。以這種方式為專案或資料夾設定標記值，會覆寫從機構沿用的標記值。

  5. 建立機構政策，禁止為所有資源 (豁免資源除外) 建立服務帳戶金鑰。這項政策應包含下列規則：

    • 設定 iam.disableServiceAccountKeyCreation 限制，確保系統不會對任何含有 disableServiceAccountKeyCreation: not_enforced 標記的資源強制執行這項限制。這項規則中的條件應如下所示： 

      "resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced')"
    • 設定 iam.disableServiceAccountKeyCreation 限制，以強制執行所有其他資源。

修正現有工作負載

針對使用服務帳戶金鑰的每個工作負載，請與工作負載擁有者合作，選擇並實作替代驗證方法。

使用 Google Cloud CLI、Cloud 用戶端程式庫、支援 應用程式預設憑證 (ADC) 的工具 (例如 Terraform) 或 REST 要求存取服務時，請參考下圖選擇驗證方法： Cloud de Confiance by S3NS

根據用途選擇驗證方法的決策樹

這張圖表會引導您思考下列問題：

  1. 您是否在單一使用者開發環境中執行程式碼，例如自己的工作站、Cloud Shell 或虛擬桌面介面？
    1. 如果是，請繼續進行問題 4。
    2. 如果沒有，請繼續回答問題 2。
  2. 您是否在 Cloud de Confiance by S3NS中執行程式碼？
    1. 如果是，請繼續進行問題 3。
    2. 如果沒有，請繼續進行問題 5。
  3. 您是否在 Google Kubernetes Engine 中執行容器？
    1. 如果是，請使用 Workload Identity Federation for GKE，將服務帳戶附加至 Kubernetes Pod。
    2. 如果沒有，請將服務帳戶附加至資源。

  4. 您的用途是否需要服務帳戶？

    舉例來說，您想為所有環境中的應用程式，設定一致的驗證和授權方式。

    1. 如果沒有，請使用使用者憑證進行驗證。
    2. 如果是，請 使用使用者憑證模擬服務帳戶。
  5. 您的工作負載是否透過支援工作負載身分聯盟的外部識別資訊提供者進行驗證？
    1. 如果是，請 設定 Workload Identity Federation，讓在內部部署或其他雲端服務供應商執行的應用程式使用服務帳戶。
    2. 如果沒有，請建立服務帳戶金鑰。

在某些情況下，您可能只能使用服務帳戶金鑰，無法使用其他驗證方法。以下是服務帳戶金鑰可能是唯一可行選項的範例：

  • 您使用的商用現成產品 (COTS) 或軟體即服務 (SaaS) 應用程式，要求您直接在使用者介面中輸入Cloud de Confiance 服務帳戶金鑰。
  • 您的工作負載在 Cloud de Confiance 以外的環境中執行，且未透過支援工作負載身分同盟的識別資訊提供者進行驗證。

如果必須繼續使用服務帳戶金鑰，請務必遵循管理服務帳戶金鑰的最佳做法。

您也可能評估後認為，繼續使用服務帳戶金鑰的風險，不值得改用其他驗證方法，因此決定不修正特定工作負載。

刪除不必要的金鑰

如果確定不需要服務帳戶金鑰，請刪除金鑰。非必要鍵包括：

  • 近期沒有使用過的金鑰，或是與您在本頁「找出能快速獲效的切入點」一節中找到的未使用資源相關的金鑰。

  • 已遷移至其他驗證方法的工作負載金鑰。

    刪除專案中的所有服務帳戶金鑰後，請確保該專案強制執行 iam.disableServiceAccountKeyCreation 限制。如果專案先前不受這項限制，請移除允許豁免的標記。

為安全刪除金鑰，建議您先停用金鑰，再刪除。刪除後就無法復原，但停用後，如果發現非預期問題，可以快速重新啟用金鑰。停用金鑰後，請等待一段時間，確認永久移除金鑰不會造成問題，再刪除金鑰。如果停用金鑰後發現非預期問題，請重新啟用金鑰、解決問題，然後重複上述程序，直到可以安全刪除金鑰為止。

使用內建控制項回應外洩的金鑰

Cloud de Confiance 提供工具和服務，協助您偵測及回應外洩的服務帳戶金鑰。建議使用下列機制，協助您處理服務帳戶金鑰外洩問題：

持續改善服務帳戶管理功能

請盡可能採用管理服務帳戶金鑰的最佳做法。改善金鑰管理程序有助於降低貴機構中任何剩餘服務帳戶金鑰的風險。

後續步驟