在管道中使用服務帳戶的最佳做法

部署管道可自動執行程式碼或預先建構構件的部署程序，將這些項目部署至 Cloud de Confiance by S3NS 環境，因此可做為 Cloud de Confiance 控制台或 Google Cloud CLI 等互動式工具的替代方案。

部署管道與互動式工具 (例如 Cloud de Confiance 主控台 或 gcloud CLI) 與 Identity and Access Management 互動的方式不同，因此保護 Cloud de Confiance 資源時，請務必考量這些差異。

在 Cloud de Confiance 允許存取資源前，會先執行存取檢查。 為執行這項檢查，IAM 通常會考量：

  • 您的身分和任何相關聯的主體存取邊界政策
  • 您嘗試存取的資源，以及該資源的身分與存取權管理允許和拒絕政策
  • 要求內容 (可能包括時間和地點)

在部署管道中，您很少會直接呼叫 Cloud de Confiance API。而是使用工具存取 Cloud de Confiance 資源。使用 Cloud de Confiance 主控台或 gcloud CLI 等工具時，必須先授權工具代表您存取資源。提供這項授權後，工具就能在發出 API 呼叫時使用您的身分。

與 Cloud de Confiance 控制台或 gcloud CLI 類似，部署管道會代表您執行動作：擷取以原始碼表示的變更，並將這些變更部署至 Cloud de Confiance。但與 Cloud de Confiance 控制台或 gcloud CLI 不同，部署管道通常不會使用您的身分執行部署作業：

  1. 使用者通常不會直接與部署管道互動。您會改為與來源控制系統 (SCM) 互動，將程式碼變更推送至來源存放區，或核准程式碼審查。

  2. 部署管道會從 SCM 系統讀取提交的程式碼變更，並將這些變更部署至 Cloud de Confiance。

    如要執行部署作業，部署管道通常無法使用您的身分，原因如下：

    1. 原始碼和中繼資料可能未指出您是作者，或是作者資訊無法防範竄改 (例如未簽署的 Git 提交)
    2. 您用來提交原始碼的身分可能與 Cloud de Confiance的身分不同，且這兩個身分無法對應

    因此，大多數部署管道都會使用服務帳戶，以自己的身分執行部署作業。

  3. 部署管道存取 Cloud de Confiance時，IAM 只會根據管道使用的服務帳戶身分允許或拒絕存取，不會根據使用者帳戶身分。

部署管道

讓部署管道使用服務帳戶存取 Cloud de Confiance有以下優點：

  • 服務帳戶的生命週期與使用者帳戶的生命週期無關。將管道設定為使用服務帳戶，即可確保即使程式碼作者已離開貴機構，程式碼仍可部署。
  • 使用部署管道管理資源時，您不需要授予使用者任何資源存取權，也可以將權限限制為唯讀存取權。這種做法可讓您更輕鬆地管理 IAM 允許和拒絕政策，並強制使用者透過部署管道執行所有修改。

不過，使用服務帳戶也會帶來新的威脅。包括：

  • 詐欺：惡意行為人可能會試圖冒用部署管道的身分，或竊取其憑證來存取資源。
  • 提權：管道可能會受到欺騙，執行不該執行的動作，實際上成為混淆的代理人。
  • 不可否認性：管道執行作業後，可能難以重建原因，以及觸發作業的開發人員或程式碼變更。
  • 竄改：管道可能遭到濫用，導致雲端環境的完整性或安全控管機制遭到破壞。
  • 資訊外洩：惡意人士可能會嘗試使用部署管道，外洩機密資料。

防範網路釣魚威脅

如要授予部署管道 Cloud de Confiance的存取權，一般來說，您需要執行下列事項：

  1. 建立服務帳戶
  2. 授予服務帳戶必要資源的存取權
  3. 設定部署管道以使用服務帳戶

從 IAM 的角度來看，服務帳戶代表部署管道，但部署管道和服務帳戶是兩個不同的實體。如果未妥善保護，惡意行為人可能會使用相同的服務帳戶，藉此「假冒」部署管道的身分。

以下章節將說明最佳做法，協助您降低這類威脅的風險。

最佳做法：

避免將服務帳戶附加至 CI/CD 系統使用的 VM 執行個體。
為每個部署管道使用專用服務帳戶。
盡可能使用 Workload Identity 聯盟。
使用 VPC Service Controls 降低憑證外洩的影響。

避免將服務帳戶附加至 CI/CD 系統使用的 VM 執行個體

對於部署在 Compute Engine 上且需要存取 Cloud de Confiance資源的應用程式，通常最好是將服務帳戶附加至基礎 VM 執行個體。如果 CI/CD 系統使用 Compute Engine VM 執行不同的部署管道，而同一個 VM 執行個體可能用於執行不同的部署管道，且每個管道都需要存取不同的資源，這種做法可能會造成問題。

不要使用附加的服務帳戶，讓部署管道存取資源，請讓每個部署管道使用個別的服務帳戶。請避免將服務帳戶附加至 CI/CD 系統使用的 VM 執行個體，或附加僅限存取 Cloud Logging 等必要服務的服務帳戶。

為每個部署管道使用專屬服務帳戶

如果允許多個部署管道使用同一個服務帳戶，IAM 就無法區分管道。這些管道會存取相同資源，而稽核記錄可能沒有足夠資訊，可判斷是哪個部署管道觸發資源存取或變更。

為避免這類模稜兩可的情況，請在部署管道和服務帳戶之間維持 1:1 的關係。為每個部署管道建立專屬服務帳戶，並確保執行下列操作：

  • 將部署管道的名稱或 ID 併入服務帳戶的電子郵件地址。遵循一致的命名架構，有助於判斷哪些服務帳戶連結至哪些部署管道。
  • 只授予服務帳戶特定部署管道所需的資源存取權。

盡可能使用 Workload Identity 聯盟

部分 CI/CD 系統 (例如 GitHub Actions 或 GitLab) 可讓部署管道取得符合 OpenID Connect 標準的權杖，用來聲明部署管道的身分。您可以使用 Workload Identity 聯盟，讓部署管道使用這些權杖模擬服務帳戶。

使用 Workload Identity 聯盟可避免使用服務帳戶金鑰時的相關風險。

使用 VPC Service Controls 降低憑證外洩的影響

如果惡意行為人從其中一個部署管道竊取存取權權杖或服務帳戶金鑰，他們可能會嘗試使用這項憑證，從他們控制的其他機器存取您的資源。

根據預設，IAM 在做出存取決策時，不會將地理位置、來源 IP 位址 或來源 Cloud de Confiance 專案納入考量。 因此，遭竊的憑證可能在任何地方都能使用。

您可以將專案放在 VPC service perimeter 中，並使用輸入規則，限制可存取 Cloud de Confiance資源的來源：

  • 如果部署管道在 Cloud de Confiance上執行，您可以設定輸入規則，只允許來自含有 CI/CD 系統的專案存取。
  • 如果部署管道在 Cloud de Confiance外部執行，您可以建立存取層級，只允許來自特定地理位置或 IP 範圍的存取要求。然後建立輸入規則，允許符合此存取層級的用戶端存取。

防範竄改威脅

對於儲存在 Cloud de Confiance的部分資料，您可能特別希望防止未經授權的修改或刪除。如果特別擔心未經授權的修改或刪除行為，則可將資料歸類為高完整性資料。

為維護資料完整性，您必須確保用於儲存及管理資料的 Cloud de Confiance資源已安全設定，並維持完整性。

部署管道有助於維護資料和資源的完整性，但也可能帶來風險：如果某個元件的管道不符合所管理資源的完整性要求，部署管道就會變成弱點，可能讓惡意行為人竄改資料或資源。

下一節將說明最佳做法，協助您降低竄改威脅的風險。

最佳做法：

避免讓部署管道管理安全控管措施。

限制安全控管功能的存取權

如要確保 Cloud de Confiance上的資料和資源安全無虞，請使用下列安全控管措施：

  • 允許政策和拒絕政策
  • 組織政策限制
  • VPC Service Controls 服務範圍、存取層級和輸入政策

這些安全控管措施本身就是資源。竄改安全控管機制會危及安全控管機制所套用資源的完整性。因此，您必須將安全控管措施的完整性視為與所套用資源的完整性同等重要。

如果讓部署管道管理安全控管措施，就必須由部署管道維護安全控管措施的完整性。因此，您必須將部署管道本身的完整性，視為至少與其管理的安全性控制措施完整性同等重要，以及這些控制措施適用的資源。

您可以採取下列措施，限制部署管道對資源完整性的影響：

  • 不授予部署管道存取權，允許政策、拒絕政策和其他安全控管措施，並限制其對其他資源的存取權
  • 僅授予特定安全控管措施的存取權，例如特定資源或專案的允許政策和拒絕政策，但不授予影響多個資源或專案的廣泛控管措施存取權

如果部署管道、元件和基礎架構無法滿足特定安全控管措施的完整性需求，最好避免讓部署管道管理這些安全控管措施。

防範不可否認性威脅

有時您可能會發現 Cloud de Confiance上的某項資源出現可疑活動。在這種情況下，您必須能夠進一步瞭解活動，最好還能重構導致活動發生的事件鏈。

透過 Cloud 稽核記錄，您可以瞭解資源的存取或修改時間，以及相關使用者。雖然 Cloud 稽核記錄可做為分析可疑活動的起點，但這些記錄提供的資訊可能不夠充分：如果您使用部署管道，也必須能夠將 Cloud 稽核記錄與部署管道產生的記錄相互關聯。

本節提供最佳做法，協助您在 Cloud de Confiance 和部署管道中維護稽核追蹤記錄。

最佳做法：

確認您可以將部署管道記錄與 Cloud 稽核記錄相互關聯。
調整部署管道記錄和 Cloud 稽核記錄的保留期限。

確保您可以將部署管道記錄與 Cloud 稽核記錄相互關聯

Cloud 稽核記錄包含時間戳記，以及啟動活動的使用者相關資訊。如果您為每個部署管道使用專屬服務帳戶，這項資訊可協助您找出啟動活動的部署管道，並縮小可能導致問題的程式碼變更和管道執行作業範圍。但如果沒有更多資訊可供您將 Cloud 稽核記錄與部署管道的記錄建立關聯，就難以找出導致活動的確切管道執行和程式碼變更。

您可以透過多種方式擴充 Cloud 稽核記錄，加入更多資訊，包括：

  • 使用 Terraform 時，請指定要求原因，指出 CI/CD 管道執行。
  • 在 API 要求中新增 X-Goog-Request-Reason HTTP 標頭，並傳遞部署管道執行的 ID。
  • 使用自訂 User-Agent，內嵌部署管道執行的 ID。

您也可以擴充部署管道發出的記錄：

  • 記錄每次 CI/CD 管道執行作業的 API 要求。
  • 每當 API 傳回作業 ID 時，請在 CI/CD 系統的記錄中記錄該 ID。

調整部署管道記錄和 Cloud 稽核記錄的保留期限

如要分析與部署管道相關的可疑活動，通常需要多種類型的記錄，包括管理員活動稽核記錄、資料存取稽核記錄，以及部署管道的記錄。

Cloud Logging 只會保留記錄一段時間。根據預設，資料存取稽核記錄的保留期限比管理員活動稽核記錄短。執行部署管道的系統也可能會在一段時間後捨棄記錄。視部署管道的性質，以及部署管道所管理資源的重要性而定，這些預設保留期限可能不足或不符需求。

為確保需要時可存取記錄檔，請確認不同系統使用的記錄檔保留期限一致且夠長。

如有需要，請自訂資料存取稽核記錄的保留期限，或設定自訂接收器，將記錄檔傳送至自訂儲存位置。

最佳做法：

避免直接授予機密資料的存取權。
使用 VPC Service Controls 防範資料竊取。

防範資訊揭露威脅

如果部署管道的服務帳戶可以存取機密資料，惡意行為人可能會嘗試使用部署管道竊取該資料。部署管道的資料存取權可以是直接或間接：

  • 直接：部署管道的服務帳戶可能有權從 Cloud Storage、BigQuery 或其他位置讀取機密資料。這項存取權可能是刻意授予，但也可能是授予過多存取權時意外造成的結果。

    如果惡意行為人取得部署管道的存取權，並直接存取機密資料，可能會嘗試使用服務帳戶的存取權杖來存取及外洩資料。

  • 間接：如要部署設定或新版軟體，部署管道的服務帳戶可能具備建立或重新部署運算資源的權限，例如 Compute Engine VM 執行個體。其中部分資源可能附加服務帳戶，可授予機密資料的存取權。

    在這種情況下，惡意行為人可能會嘗試入侵部署管道，將惡意程式碼部署至其中一個運算資源，並讓該程式碼竊取機密資料。

本節提供最佳做法，協助您降低揭露機密資料的風險。

避免直接授予機密資料的存取權

部署基礎架構、設定或新版軟體時，部署管道通常不需要存取現有資料。因此，限制存取不含任何資料的資源，或至少不含機密資料的資源，通常就已足夠。

如要盡量減少對現有潛在機密資料的存取，可以採取下列做法：

  • 請只授予特定資源的存取權，而不是授予整個專案的存取權給部署管道的服務帳戶。
  • 授予建立權限，但不允許讀取權限。舉例來說，您可以授予儲存空間物件建立者角色 (roles/storage.objectCreator)，允許服務帳戶將新物件上傳至 Cloud Storage 值區，但不必授予讀取現有資料的權限。
  • 將基礎架構即程式碼 (IaC) 限制在機密程度較低的資源，例如使用 IaC 管理 VM 執行個體或網路，但不要管理機密 BigQuery 資料集。

使用 VPC Service Controls 防範資料竊取

如要降低間接資料竊取風險，請在 VPC Service Controls 範圍內部署 Cloud de Confiance 資源。

如果部署管道在 Cloud de Confiance外部執行，或屬於不同的範圍，您可以設定輸入規則，將範圍的存取權授予管道的服務帳戶。如有可能，請設定輸入規則，只允許部署管道使用的 IP 位址存取，並只允許部署管道真正需要的服務存取。

防範提權威脅

部署管道使用服務帳戶存取資源時，無論是哪位開發人員或使用者撰寫程式碼或設定變更，都會使用服務帳戶。 Cloud de Confiance管道的服務帳戶與開發人員的身分不一致，導致部署管道容易遭受混淆副手攻擊。在這種情況下，惡意行為人會誘騙管道執行自己無權執行的動作，而管道甚至可能不應執行該動作。

本節提供最佳做法，協助您降低部署管道遭濫用，導致提權的風險。

最佳做法：

限制部署管道和所有輸入內容的存取權。
避免讓部署管道修改政策。
請勿在記錄中揭露服務帳戶憑證。

限制部署管道和所有輸入內容的存取權

大多數部署管道會使用原始碼存放區做為主要輸入來源，並在偵測到特定分支 (例如 main 分支) 的程式碼變更時，自動觸發管道。部署管道通常無法驗證在原始碼存放區中找到的程式碼和設定是否真實可靠。因此，這項架構的安全性取決於：

  • 控管誰可以將程式碼和設定提交至部署管道使用的存放區和分支。
  • 強制執行變更提交前必須符合的條件，例如通過程式碼審查、靜態分析或自動化測試。

如要確保這些控管機制有效運作，請務必採取下列措施，防止不肖分子規避：

  • 修改程式碼存放區或部署管道的設定。
  • 竄改部署管道的基礎架構 (例如 VM 和儲存空間)。
  • 在原始碼存放區外修改或替換輸入內容，例如套件、容器映像檔或程式庫。

如果資源是由部署管道管理，則 Cloud de Confiance 的安全性只能與部署管道、其設定、基礎架構和輸入內容的安全性相提並論。因此，您必須保護這些元件，確保Cloud de Confiance 資源受到保護。

避免部署管道修改政策

對於大多數資源類型，IAM 會定義 RESOURCE_TYPE.setIamPolicy 權限。這項權限可讓使用者修改資源的允許政策，授予其他使用者存取權，或修改及延長自己的存取權。除非受到拒絕政策限制，否則授予使用者或服務帳戶 *.setIamPolicy 權限，就等於授予他們資源的完整存取權。

請盡可能避免讓部署管道修改資源存取權。授予管道服務帳戶存取 Cloud de Confiance 資源的權限時，請使用不含任何 *.setIamPolicy 權限的角色，並避免使用「編輯者」和「擁有者」基本角色。

對於某些部署管道，授予修改允許政策或拒絕政策的權限可能無法避免：舉例來說，部署管道的用途可能是建立新資源或管理現有資源的存取權。在這些情況下，您仍可透過下列方式限制部署作業修改存取權的程度：

  • 只授予特定資源的 *.setIamPolicy 權限，而非整個專案。
  • 使用 IAM 拒絕政策，限制可授予的權限組合，或限制可授予權限的主體。
  • 使用 IAM 條件限制管道可授予的角色，且只允許不含 *.setIamPolicy 權限的角色。

不要在記錄中揭露服務帳戶憑證

部署管道產生的記錄通常可供更多使用者存取，包括沒有權限修改管道設定的使用者。這些記錄可能會透過回應下列內容，意外揭露憑證：

  • 環境變數內容
  • 指令列引數
  • 診斷輸出內容

如果記錄意外揭露存取權杖等憑證，不肖人士可能會濫用這些憑證來提權。如要避免記錄檔洩漏憑證，請採取下列措施：

  • 避免將存取權杖或其他憑證做為指令列引數傳遞
  • 避免將憑證儲存在環境變數中
  • 盡可能設定 CI/CD 系統，自動偵測及遮蓋權杖和其他憑證

後續步驟