最佳做法：減輕 Google Cloud CLI 的 OAuth 權杖遭到入侵的影響

Last reviewed 2025-03-10 UTC

本文說明如何減輕攻擊者入侵 gcloud CLI 所使用的 OAuth 權杖憑證的影響。

如果攻擊者取得端點存取權，且該端點的有效使用者帳戶或服務帳戶已透過 gcloud CLI 進行驗證，攻擊者就能入侵這些 OAuth 權杖。攻擊者接著可以將這些權杖複製到他們控制的其他端點，藉此提出冒用合法身分的請求。即使您已移除攻擊者對受攻擊端點的存取權，攻擊者仍可繼續使用複製的憑證，發出經過驗證的 API 要求。為降低這類風險，您可以使用生命週期短且具情境感知功能的憑證，控管系統存取權。

本文件適用於負責保護雲端資源免於遭到不當存取的安全團隊或雲端架構師。本文件將介紹可用控管機制，協助您主動降低遭到入侵的 gcloud CLI OAuth 權杖所造成的影響，並在端點遭到入侵後修復環境。

總覽

如要瞭解這項威脅的運作方式，您必須瞭解 gcloud CLI 如何儲存 OAuth 2.0 憑證，以及這些憑證在遭到攻擊者濫用時，可能會發生什麼情況。

gcloud CLI 儲存的憑證類型

gcloud CLI 會使用 OAuth 2.0 存取權杖來驗證 Google Cloud API 要求。OAuth 流程會因所使用的憑證類型而異，但通常存取權杖和其他憑證可在本機存取。在每個情況下，存取權存證會在 60 分鐘後到期，但其他憑證類型可能會持續存在。

當您使用使用者帳戶授權 gcloud CLI 時，gcloud CLI 會啟動三足式 OAuth 同意聲明流程，代表使用者存取Google Cloud API。使用者完成同意流程後，gcloud CLI 會收到存取權權杖和重新整理權杖，讓它可以要求新的存取權權杖。長效的重新整理權杖會持續存在，直到符合到期條件為止。

使用服務帳戶授權 gcloud CLI 後，gcloud CLI 會啟動雙方 OAuth 流程，以服務帳戶身分存取Google Cloud API。從私密金鑰檔案啟用服務帳戶後，系統會使用這個金鑰定期要求存取權杖。長效型私密金鑰會儲存在 gcloud CLI 設定中，並在您刪除服務帳戶金鑰前保持有效。

當您在 Google Cloud環境 (例如 Compute Engine 或 Cloud Shell) 中執行 gcloud CLI 時，應用程式可以自動尋找憑證，並以服務帳戶身分進行驗證。舉例來說，在 Compute Engine 中，gcloud CLI 等應用程式可以查詢中繼資料伺服器，取得存取權杖。Google 會管理及輪替用於建立存取權權杖的私密簽署金鑰，且不會將長期憑證公開給應用程式。

使用工作負載身分聯盟進行驗證時，應用程式會根據外部身分提供者的憑證進行驗證，並收到聯合短期存取權杖。如要進一步瞭解如何儲存及管理外部身分提供者使用的長期憑證，請參閱使用 Workload Identity 聯盟的最佳做法。

攻擊者如何使用遭到入侵的 OAuth 權杖

如果攻擊者成功入侵端點，OAuth 權杖等憑證就會成為攻擊目標，因為攻擊者可以利用這些憑證持續或提升存取權。

開發人員在編寫及偵錯程式碼時，可能有正當理由需要查看自己的憑證。舉例來說，如果開發人員使用不支援的用戶端程式庫，可能需要驗證使用 REST 要求來存取 Google Cloud 服務。開發人員可以透過多種方法查看憑證，包括：

不過，攻擊者可能會在入侵端點後，使用這些相同的技術。

如果攻擊者入侵端點 (例如開發人員工作站)，主要威脅是攻擊者可以使用已驗證身分的有效憑證，執行 gcloud CLI 指令或其他程式碼。此外，攻擊者可能會將 OAuth 權杖複製到他們控制的其他端點，以便持續存取權。發生這種憑證竊盜事件時，攻擊者仍可使用長期 OAuth 權杖，即使您已移除遭入侵端點的存取權，仍可持續存取資料，這就是次要威脅。

如果攻擊者成功取得 OAuth 權杖，他們可以執行下列操作：

  • 攻擊者可以冒用遭到入侵的使用者或服務帳戶。使用遭到入侵權杖的 API 流量會記錄為來自遭到入侵的使用者或服務帳戶，因此很難在記錄中區分正常和惡意活動。
  • 攻擊者可以使用與使用者相關聯的永久更新憑證，或與服務帳戶相關聯的私密金鑰，無限期地更新存取權杖。
  • 攻擊者可以使用使用者的密碼或 2 步驟驗證，略過驗證程序，因為憑證是在登入流程後才會核發。

風險緩解的最佳做法

請實施下列各節所述的控管措施，以降低 gcloud CLI 權杖遭到入侵的風險。如果您遵循企業基礎架構藍圖或 Google Cloud中的到達區域設計所述的安全性最佳做法，可能已設有這些控管措施。

設定 Google Cloud 服務的工作階段長度

如要縮短攻擊者可利用遭盜權杖的時間，請設定 Google Cloud 服務的工作階段長度。對於新客戶，系統會自動強制執行預設的 16 小時工作階段長度。如果客戶是在 2023 年前建立 Google Cloud 機構，則預設設定可能會一律不要求重新驗證。請檢查這項設定，確保您有重新驗證政策，且工作階段長度介於 1 到 24 小時之間。重新驗證政策會使重新整理權杖失效，並強制使用者定期使用密碼或安全金鑰重新驗證 gcloud 指令列介面。

Google Cloud 服務的工作階段長度與Google 服務的工作階段長度不同，後者會控管 Google Workspace 服務的登入網路工作階段，但不會控管 Google Cloud的重新驗證。如果您使用 Google Workspace 服務，請為這兩項服務設定工作階段長度。

設定 VPC Service Controls

在整個環境中設定 VPC Service Controls，確保只有 Google Cloud 源自您定義範圍內的 API 流量才能存取支援的資源。服務範圍會封鎖來自環境外攻擊者控制的端點的受限制服務要求，因此可限制遭到入侵憑證的效用。

設定 Chrome Enterprise 進階版

設定 Chrome Enterprise 進階版政策，以便保護 Google Cloud 控制台和 Google Cloud API。設定 Chrome Enterprise 進階版的存取層級和繫結，以便有選擇性地允許在每項 API 要求中評估的屬性，包括 IP 存取權或以憑證為基礎的雙向 TLS 存取權。如果要求使用遭到入侵的授權憑證，但不符合 Chrome Enterprise 進階版政策中定義的條件，系統會拒絕該要求。

Chrome Enterprise 進階版是一項以使用者為中心的控管機制，可拒絕不符合定義條件的使用者 API 流量。VPC Service Controls 是資源導向的控管機制，可定義資源可通訊的範圍。VPC Service Controls 適用於所有使用者身分和服務帳戶身分，但 Chrome Enterprise Premium 只適用於貴機構內的使用者身分。搭配使用 Chrome Enterprise Premium 和 VPC Service Controls，可降低在攻擊者控制的裝置 (位於環境之外) 上，遭入侵憑證的效用。

強制要求使用者執行兩步驟驗證，才能存取遠端伺服器

如果您允許開發人員使用 SSH 存取 Compute Engine 資源，請設定採用 2 步驟驗證的 OS 登入。這會強制執行額外檢查點，要求使用者使用密碼或安全金鑰重新驗證。如果攻擊者擁有遭到盜用的 OAuth 權杖，但沒有密碼或安全金鑰，這項功能就會封鎖攻擊者。

透過遠端桌面通訊協定 (RDP) 存取 Compute Engine 上的 Windows 執行個體不支援 OS 登入服務，因此無法針對 RDP 工作階段細部強制執行兩步驟驗證。使用 IAP Desktop 或 Google Chrome 版 RDP 外掛程式時，請為使用者的網路工作階段設定粗略控制項，例如Google 服務的工作階段長度和兩步驟驗證設定，並停用兩步驟驗證下的允許使用者信任裝置設定。

限制服務帳戶金鑰的使用

使用服務帳戶金鑰進行驗證時，金鑰值會儲存在 gcloud CLI 設定檔中，與下載的金鑰檔案分開。有權存取您環境的攻擊者，可以從 gcloud CLI 設定複製金鑰，或從本機檔案系統或內部程式碼存放區複製金鑰檔案。因此，除了因應遭到入侵的存取權權杖的因應措施外，請考慮如何管理下載的服務帳戶金鑰檔案。

請查看更安全的驗證替代方案，減少或移除依賴服務帳戶金鑰的用途，並套用機構政策限制 iam.disableServiceAccountKeyCreation 來停用服務帳戶金鑰建立功能。

考量最低權限原則

設計 IAM 政策時，請考慮採用最低權限。授予使用者完成工作所需的角色，並以最小範圍授予。請勿授予不必要的角色。查看並套用角色建議，避免在環境中設定含有未使用的角色和多餘角色的 IAM 政策。

保護端點

請考量攻擊者如何取得端點 (例如開發人員工作站或 Compute Engine 執行個體) 的實體存取權或遠端存取權。雖然您必須設法因應 OAuth 權杖遭到入侵的威脅，但也應考量如何因應攻擊者入侵信任端點的威脅。如果攻擊者可以存取您信任的端點，他們就能直接在端點上執行 gcloud CLI 指令或其他程式碼。

雖然開發人員工作站的全面防護措施超出本文的範圍，但請評估安全工具和作業如何協助保護端點並監控端點是否遭到入侵。請考慮以下問題：

  • 開發人員工作站的實體安全性如何受到保護？
  • 您如何識別及因應網路侵害事件？
  • 使用者如何透過遠端方式存取 SSH 或 RDP 工作階段？
  • 其他持續性憑證 (例如 SSH 金鑰或服務帳戶金鑰) 可能會如何遭到入侵？
  • 是否有使用持續性憑證的工作流程，可以改用短期憑證？
  • 是否有共用裝置，可讓其他人讀取其他使用者的快取 gcloud CLI 憑證？
  • 使用者是否可以透過不受信任的裝置使用 gcloud CLI 進行驗證？
  • 已核准的流量如何連線至 VPC Service Control 範圍內的資源？

請確保安全作業能回答下列每個問題。

協調回應團隊

請事先確認負責事件回應的安全團隊，是否已在 Google Cloud 控制台和管理控制台中取得適當的存取權。如果由不同的團隊管理 Google Cloud 控制台和管理控制台，您可能會在事件發生時延遲回應。

如要移除遭入侵使用者帳戶的存取權，事件回應團隊需要具備管理控制台角色，例如使用者管理員。如要評估 Google Cloud資源是否發生可疑活動，這個團隊可能也需要IAM 角色，例如所有專案的安全審查者，或是集中式記錄匯入器的記錄檢視器。安全性團隊所需的角色會因環境的設計和運作方式而異。

安全事件發生後的最佳修復做法

端點遭到入侵後，您可以參考事件管理計畫，決定如何回應遭入侵端點的主要威脅，以及如何減輕來自遭盜用權杖的次要威脅所造成的持續性損害。如果攻擊者持續存取開發人員工作站，他們可能會在合法使用者重新驗證後，再次複製權杖。如果您懷疑 gcloud CLI 權杖可能遭到入侵，請向 Cloud Customer Care 開立支援單，並完成下列各節中的建議。這些動作有助於限制這類事件對貴 Google Cloud機構的影響。

本節的建議與處理遭到入侵的 Google Cloud 憑證的一般指引重疊，但特別著重於從遭到入侵的端點複製的 gcloud CLI 權杖所帶來的威脅。

使用 Google Cloud 工作階段控制項，讓所有使用者帳戶的有效權杖失效

如果您尚未強制執行 Google Cloud 工作階段控管功能，請立即啟用這項功能，並設定較短的重新驗證頻率。這項控制項可確保所有重新整理權杖在您定義的時間長度結束時到期，進而限制攻擊者可使用遭到入侵權杖的時間長度。

手動讓遭駭使用者帳戶的權杖失效

請查看處理遭盜用憑證的相關指南，瞭解如何處理任何可能遭到盜用的使用者身分。特別是，移除 gcloud CLI 憑證是安全團隊處理使用者身分遭到盜用的 OAuth 權杖最有效的方法。如要立即讓 gcloud CLI 的重新整理權杖和存取權杖失效，並強制使用者使用密碼或安全金鑰重新驗證，請從使用者的已連結應用程式清單中移除 gcloud CLI。

個人使用者也可以移除個人帳戶的 gcloud CLI 憑證。

其他方法 (例如將使用者停權、重設使用者密碼或重設登入 Cookie) 並無法具體解決 OAuth 權杖遭到入侵的威脅。這些方法通常可用於事件回應，但不會使攻擊者已控制的存取權權杖失效。舉例來說，如果您在調查期間選擇暫停使用者，但未撤銷 gcloud CLI 權杖，則在權杖到期前，如果暫停的使用者已還原，權杖仍可能有效。

以程式輔助方式讓多個使用者帳戶的權杖失效

如果您懷疑發生違規行為，但無法找出受影響的使用者，請考慮比重新驗證政策允許的更快，撤銷機構中所有使用者的執行中工作階段。

這種做法可能會對合法使用者造成干擾，並終止依賴使用者憑證的長時間執行程序。如果您選擇採用這種做法，請為資安營運中心 (SOC) 準備指令碼解決方案，並提前執行及測試少數使用者。

以下範例程式碼使用 Workspace Admin SDK，找出 Google Workspace 或 Cloud Identity 帳戶中，有權存取 gcloud CLI 的所有使用者身分。如果使用者已授權 gcloud CLI，指令碼會撤銷更新憑證和存取憑證，並強制使用者使用密碼或安全金鑰重新驗證。如要瞭解如何啟用 Admin SDK API 並執行這段程式碼，請參閱 Google Apps 指令碼快速入門指南。

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

讓服務帳戶的憑證失效並輪替

與授予使用者身分的存取權杖不同，授予服務帳戶的存取權杖無法透過管理控制台或 gcloud auth revoke 等指令失效。此外，您在 Google Cloud 工作階段控制項中指定的工作階段時間長度，適用於 Cloud Identity 或 Google Workspace 目錄中的使用者帳戶，但不適用於服務帳戶。因此，針對遭到入侵的服務帳戶，事件回應作業必須同時處理持續性金鑰檔案和短效存取權權杖。

如果您懷疑服務帳戶的憑證遭到入侵，請停用服務帳戶，刪除服務帳戶金鑰 (如果有)，然後在 60 分鐘後啟用服務帳戶。刪除服務帳戶金鑰可能會使長效憑證失效，因此攻擊者無法要求新的存取權存取權，但不會使已授予的存取權失效。為確保存取權杖不會在 60 分鐘的有效期間內遭到濫用，您必須停用服務帳戶 60 分鐘。

您也可以刪除及取代服務帳戶，立即撤銷所有短期和長期憑證，但這可能會造成應用程式中服務帳戶的作業中斷。

後續步驟