保護開發人員憑證的最佳做法

瞭解保護開發人員工作站的最佳做法，防止 Google Cloud 憑證遭竊和濫用，包括 Google Cloud CLI OAuth 持有人權杖、應用程式預設憑證和本機金鑰。

本文適用於負責保護雲端資源，避免遭到非法存取的安全團隊或雲端架構師。瞭解可用的控制項，主動減少遭入侵的開發人員憑證造成的影響，並在端點遭入侵後修復環境。

憑證遭駭的風險

如果攻擊者存取已透過Google Cloud 或 gcloud CLI 驗證的端點，就能盜用憑證。然後，攻擊者可以將這些權杖複製到自己控制的其他端點，以冒用合法身分提出要求。即使您移除攻擊者對遭入侵端點的存取權，攻擊者仍可使用複製的權杖，繼續發出經過驗證的 API 要求。為降低這項風險，您可以透過存留時間短暫且情境感知的憑證，控管系統存取權。

開發人員憑證總覽

開發人員工作站通常會找到下列 Google Cloud 憑證：

以下各節說明如何儲存及使用各類憑證。

gcloud CLI OAuth 權杖

gcloud CLI 會使用 OAuth 2.0 存取權杖，驗證對Google Cloud API 的要求。OAuth 流程會因使用的憑證類型而異，但一般來說，存取權杖和其他憑證都可在本機存取。在上述兩種情況下，存取權杖預設會在 60 分鐘後失效，但如果符合延長存續時間限制，則最長可維持 12 小時。但其他憑證類型可能會持續存在。

使用使用者帳戶授權 gcloud CLI 時，gcloud CLI 會啟動三足式 OAuth 同意流程，代表使用者存取Google Cloud API。使用者完成同意流程後，gcloud CLI 會收到存取權杖和更新權杖，以便要求新的存取權杖。長期更新權杖會持續有效，直到符合到期條件為止。

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

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

應用程式預設憑證

應用程式會使用應用程式預設憑證向Google Cloud API 進行驗證。開發人員可以執行 gcloud auth application-default login，產生應用程式預設憑證。這個指令會寫入純文字 JSON 檔案 ($HOME/.config/gcloud/application_default_credentials.json 或 %APPDATA%\gcloud\application_default_credentials.json)，其中包含 OAuth 2.0 重新整理權杖和用戶端程式庫的用戶端憑證。

任何用戶端程式庫或自訂指令碼都能使用這些憑證呼叫Google Cloud API。

由於應用程式預設憑證是以純文字形式儲存，因此在使用者環境中執行的任何不受信任的程序或指令碼，都可以直接存取該檔案，或使用 gcloud auth application-default print-access-token 等指令擷取有效存取權杖。

一般惡意軟體通常會以 ~/.config/gcloud/ 目錄為目標，以收集 application_default_credentials.json。

詳情請參閱「應用程式預設憑證」。

服務帳戶金鑰

服務帳戶金鑰是從Google Cloud 控制台下載的私密 JSON 金鑰檔案。應用程式會使用這些金鑰向Google Cloud API 進行驗證。服務帳戶金鑰可儲存在下列位置：

  • 執行 gcloud auth activate-service-account 後的 gcloud CLI 設定目錄
  • 本機檔案系統
  • 內部程式碼存放區

開發人員端點上的服務帳戶金鑰不受兩步驟驗證限制，沒有工作階段限制，也不會自動過期。

如果攻擊者竊取服務帳戶金鑰，就能建立服務帳戶存取權杖，以維持持續存取權。

詳情請參閱「管理服務帳戶金鑰的最佳做法」。

安全殼層金鑰

安全殼層金鑰用於向 Compute Engine 執行個體驗證身分。開發人員可以使用 gcloud compute ssh 產生安全殼層金鑰。這個指令會在 ~/.ssh/google_compute_engine 中產生本機私密金鑰。SSH 金鑰的效期很長。

攻擊者可以利用竊取的 SSH 金鑰存取 VM，然後查詢中繼資料伺服器，擷取附加的服務帳戶權杖。這類攻擊會繞過外部周邊防火牆。

建議您改用採用兩步驟驗證機制的 OS 登入，詳情請參閱「強制執行兩步驟驗證，以存取遠端伺服器」。

瀏覽器 Cookie

瀏覽器 Cookie 會驗證傳送至 Google Cloud 控制台和 Cloud Shell 的網頁 HTTP 要求。使用者登入 Google Cloud 控制台時，系統會自動建立瀏覽器 Cookie。

Cookie 會儲存在本機工作站的瀏覽器設定檔目錄中。舉例來說，Google Chrome 會將 Cookie 儲存在 Linux 的 ~/.config/google-chrome/ 或 Windows 的 %LOCALAPPDATA%\Google\Chrome\User Data。

瀏覽器 Cookie 是長期有效的憑證，只有在使用者登出、工作階段逾時，或管理員在管理控制台中重設使用者工作階段時，才會失效。

攻擊者竊取這些 Cookie 後，可以匯入其他瀏覽器，劫持有效的 Google Cloud 控制台工作階段，略過驗證程序。

為降低工作階段 Cookie 遭竊的風險，請設定服務的工作階段長度Google Cloud 。

員工身分聯盟存取權杖

開發人員可透過員工身分聯盟，透過外部識別資訊提供者驗證身分，以便存取 Google Cloud 資源。

如要使用聯合身分登入，開發人員必須使用登入設定檔 (透過 gcloud iam workforce-pools create-login-config 指令建立)，並登入 gcloud CLI。透過外部身分識別提供者完成驗證後，安全權杖服務會將授權碼換成時效短暫的同盟存取權杖和 OAuth 更新權杖。

gcloud CLI 會將憑證中繼資料和更新權杖儲存在本機憑證資料庫中，並將有效存取權杖快取到 gcloud CLI 設定目錄。同盟存取權杖是短期憑證，會在一段時間後失效 (預設為 60 分鐘)。

如果攻擊者入侵端點，就能擷取有效的同盟存取權杖，或使用 gcloud auth print-access-token 模擬員工主體。如果工作人員身分有模擬權限，攻擊者也可以要求服務帳戶存取權權杖，藉此提升權限。

為降低風險，請在工作團隊身分集區中設定工作階段持續時間，將時間設為必要的最短時間，並配合外部身分提供者的重新驗證和工作階段逾時政策。如要進一步瞭解如何儲存及管理憑證，請參閱「使用 Workload Identity Federation 的最佳做法」。

憑證遭駭的影響

如果攻擊者成功入侵端點，OAuth 權杖等憑證就會成為有價值的目標，因為攻擊者可以藉此維持或擴大存取權。

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

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

如果攻擊者入侵端點，主要威脅是攻擊者可以使用已驗證身分的合法憑證，執行 gcloud CLI 指令或其他程式碼。此外，攻擊者可能會將憑證複製到他們控制的其他端點，以維持存取權。發生這類憑證竊取事件時，就會出現次要威脅。即使您移除遭入侵端點的存取權，攻擊者仍可使用長期憑證持續存取。

如果攻擊者成功盜用開發人員憑證，就能完成下列動作：

  • 模擬遭入侵的使用者或服務帳戶。使用遭盜用權杖的 API 流量會記錄為來自遭盜用使用者或服務帳戶，因此很難在記錄中區分正常和惡意活動。
  • 使用持續性 OAuth 更新權杖 (來自 gcloud CLI 或應用程式預設憑證)，或與服務帳戶相關聯的私密金鑰，無限期要求存取權杖。
  • 由於權杖是在登入流程後授予，因此可略過使用者的密碼或兩步驟驗證。
  • 使用遭竊的安全殼層金鑰存取 Compute Engine 執行個體，並查詢中繼資料伺服器，竊取附加的服務帳戶權杖。
  • 利用竊取的瀏覽器 Cookie 劫持有效的 Google Cloud 控制台工作階段，不必輸入使用者密碼或兩步驟驗證碼。
  • 使用遭竊的聯合存取權杖存取授予員工身分集區的資源，或模擬服務帳戶來提升權限。

降低風險的最佳做法

請實作下列各節所述的控管措施，協助降低開發人員憑證遭盜用的風險。如果您遵循企業基礎藍圖或Google Cloud中的登陸區設計所述安全最佳做法，可能已導入這些控制項。

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

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

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

設定 VPC Service Controls

在環境中設定 VPC Service Controls，確保只有源自指定範圍內的 Google Cloud API 流量，才能存取支援的資源。服務範圍會限制遭盜用憑證的用途，因為範圍會封鎖來自攻擊者控制端點的要求，防止這些端點存取您環境外部的受限服務。

設定 Chrome Enterprise 進階版

設定 Chrome Enterprise 進階版政策，協助確保控制台和 API 安全無虞 Google Cloud Google Cloud。設定 Chrome Enterprise 進階版存取層級和繫結，有選擇性地允許在每個 API 要求中評估的屬性，包括 IP 型存取權或以憑證為基礎的存取權，適用於相互 TLS。如果要求使用遭盜用的授權憑證，但未符合 Chrome Enterprise 進階版政策中定義的條件，系統就會拒絕要求。

Chrome Enterprise 進階版以使用者為中心，可拒絕不符合定義條件的使用者 API 流量。VPC Service Controls 是以資源為中心的控制項，可定義資源可通訊的範圍。VPC Service Controls 適用於所有使用者身分和服務帳戶身分，但 Chrome Enterprise 進階版僅適用於貴機構內的使用者身分。如果同時使用 Chrome Enterprise 進階版 和 VPC Service Controls，當攻擊者控制的電腦位於環境外部，即使憑證遭盜用，也無法發揮效用。

強制執行兩步驟驗證，才能存取遠端伺服器

如果您允許開發人員使用 SSH 存取 Compute Engine 資源，請設定 OS 登入並啟用兩步驟驗證。這項設定會強制執行額外的檢查點，使用者必須使用密碼或安全金鑰重新驗證，這項功能可防止攻擊者在 OAuth 權杖遭盜用，但沒有密碼或安全金鑰的情況下，存取您的帳戶。

透過遠端桌面通訊協定 (RDP) 存取 Compute Engine 上的 Windows 執行個體時，系統不支援 OS 登入服務，因此無法針對 RDP 工作階段細部強制執行兩步驟驗證。使用 Identity-Aware Proxy (IAP) Desktop 或以 Google Chrome 為基礎的 RDP 外掛程式時，請完成下列步驟：

限制服務帳戶金鑰的使用

使用服務帳戶金鑰進行驗證時，金鑰值會儲存在 gcloud CLI 設定檔中，與下載的金鑰檔案分開。如果攻擊者有權存取您的環境，就能從 gcloud CLI 設定複製金鑰，或從本機檔案系統或內部程式碼存放區複製金鑰檔案。因此，除了規劃如何減輕遭盜用存取權杖的影響，也請考慮如何管理下載的服務帳戶金鑰檔案。

請參閱更安全的驗證替代方案，減少或避免使用依賴服務帳戶金鑰的用途。此外，請強制執行 constraints/iam.disableServiceAccountKeyCreation 和 constraints/iam.disableServiceAccountKeyUpload 機構政策限制，停用服務帳戶金鑰建立功能。

套用最小權限原則

設計身分與存取權管理 (IAM) 政策時，請考慮最小權限。僅在最小範圍內授予使用者完成工作所需的角色。查看並套用角色建議，避免環境中出現未使用的過多角色，導致 IAM 政策過於複雜。

保護端點

請考量攻擊者可能如何取得端點的實體存取權或遠端存取權，例如開發人員工作站或 Compute Engine 執行個體。雖然制定計畫來防範憑證遭盜用十分重要，但也要考量攻擊者入侵受信任端點的風險。如果攻擊者有權存取您信任的端點，就能直接在端點上執行 gcloud CLI 指令或其他程式碼。

雖然本文件不涵蓋開發人員工作站的全面防護，但請評估您的安全工具和作業如何協助保護及監控端點，防範遭到入侵。請思考以下幾個問題：

  • 如何保護開發人員工作站的實體安全？
  • 您如何識別及因應網路入侵事件？
  • 使用者如何遠端存取 SSH 或 RDP 工作階段？
  • SSH 金鑰或服務帳戶金鑰等永久憑證可能遭到盜用的原因為何？
  • 是否有使用永久憑證的工作流程可以改用短期憑證？
  • 是否有共用裝置，可讓使用者讀取其他使用者的 gcloud CLI 快取憑證？
  • 使用者可以從不受信任的裝置，透過 gcloud CLI 進行驗證嗎？
  • 獲准的流量如何連線至 VPC Service Controls perimeter 內的資源？

請確保安全營運團隊能回答上述每個問題。

整合回應團隊

請事先確認負責事件應變的安全團隊，在 Google Cloud 控制台和管理控制台中擁有適當的存取權。如果 Google Cloud 控制台和管理控制台由不同團隊管理，事件發生時的回應速度可能會較慢。

如要評估及應對入侵行為，請參閱「應對遭盜用的憑證 Google Cloud 」。

監控憑證是否遭到盜用

如要監控潛在的遭入侵情形，請考慮下列做法：

  • 使用異常偵測或密鑰掃描等工具，掃描程式碼存放區中的密鑰。

  • 在 Cloud 稽核記錄中，為下列項目設定快訊：

    • iamcredentials.googleapis.com 方法 (例如 GenerateAccessToken、GenerateIdToken、SignJwt)，稽核服務帳戶權杖產生作業

      如要取得這些記錄，您必須啟用資料存取記錄。

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail 稽核使用者和服務帳戶模擬作業

    • sts.googleapis.com 針對異常身分主張交換要求

  • 在 Security Command Center 中，監控 Event Threat Detection 的下列威脅發現項目：

    • 保留設定：新地理區域
    • 持續性：新使用者代理程式
    • 保留設定：新 API 方法
    • 規避防禦機制：來自匿名 Proxy 的存取
    • 權限提升：有人冒用服務帳戶，並出現異常的管理員活動
    • 權限提升：管理員活動的異常服務帳戶模擬者
    • 初始存取：使用外洩的服務帳戶金鑰
    • Persistence: Service Account Key Created
    • 初始存取權：已封鎖可疑的登入活動
    • 初始存取權：帳戶已停用遭入侵

    針對每項威脅，系統都會提供建議的調查步驟，協助您採取應對措施。

  • 在 Google Workspace 和 Cloud Identity 中監控使用者登入情形。為方便追蹤問題，建議您將記錄檔匯出至 Cloud Logging。

  • 監控 Chrome Enterprise 進階版和 VPC Service Controls 的記錄，找出有人嘗試使用遭竊權杖從 perimeter 存取資源。

  • 使用 Cloud Monitoring 監控服務帳戶金鑰用量是否異常。

確保資安營運中心 (SOC) 收到即時通知，並具備快速應對疑似憑證遭盜用事件所需的劇本、工具和存取權。您也可以將 Security Command Center 與現有的 SIEM 整合，或將記錄匯入 Google Security Operations，以供進一步分析。

後續步驟