部署管道可自動執行程序，將程式碼或預先建構的構件部署至 Google Cloud 環境，並可做為 Google Cloud 控制台或 Google Cloud CLI 等互動式工具的替代方案。
部署管道與 Google Cloud 主控台 或 gcloud CLI 等互動式工具與 Identity and Access Management 互動的方式不同，因此保護 Google Cloud 資源時，請務必考量這些差異。
在您存取資源前， Google Cloud 會先執行存取檢查。 為執行這項檢查，IAM 通常會考量：
- 您的身分和任何相關聯的主體存取邊界政策
- 您嘗試存取的資源，以及該資源的身分與存取權管理允許和拒絕政策
- 要求內容 (可能包括時間和地點)
在部署管道中，您很少會直接呼叫 Google Cloud API。而是使用工具存取 Google Cloud 資源。使用主控台或 gcloud CLI 等工具時，您必須先授權工具代表您存取資源。 Google Cloud 提供這項授權後，工具就能在發出 API 呼叫時使用您的身分。
與 Google Cloud 控制台或 gcloud CLI 類似，部署管道會代表您執行動作：管道會取得以原始碼表示的變更，並將這些變更部署至 Google Cloud。但與 Google Cloud 控制台或 gcloud CLI 不同，部署管道通常不會使用您的身分來執行部署作業：
使用者通常不會直接與部署管道互動。您會與原始碼控管系統 (SCM) 互動，將程式碼變更推送至原始碼存放區，或核准程式碼審查。
部署管道會從 SCM 系統讀取提交的程式碼變更，並將這些變更部署至 Google Cloud。
如要執行部署作業，部署管道通常無法使用您的身分，原因如下：
- 原始碼和中繼資料可能未指出您是作者，或作者資訊無法防竄改 (例如未簽署的 Git 提交)
- 您用來提交原始碼的身分可能與 Google Cloud的身分不同，且這兩個身分無法對應
因此，大多數部署管道都會使用服務帳戶，以自己的身分執行部署作業。
部署管道存取 Google Cloud時，IAM 會根據管道使用的服務帳戶身分允許或拒絕存取，而不是根據使用者帳戶身分。
讓部署管道使用服務帳戶存取 Google Cloud有以下優點：
- 服務帳戶的生命週期與使用者帳戶的生命週期無關。將管道設定為使用服務帳戶，可確保即使程式碼作者已離開貴機構，程式碼仍可部署。
- 使用部署管道管理資源時，您不需要授予使用者任何資源存取權，也可以將權限限制為唯讀存取權。這種做法可簡化 IAM 允許和拒絕政策的管理作業，並強制使用者透過部署管道執行所有修改作業。
不過，使用服務帳戶也會帶來新的威脅。包括：
- 冒用：惡意人士可能會試圖冒用部署管道的身分，或竊取其憑證來存取資源。
- 權限提升：管道可能會受到欺騙，進而執行不該執行的動作，有效成為混淆的代理人。
- 不可否認性：管道執行作業後，可能難以重建原因，以及觸發作業的開發人員或程式碼變更。
- 竄改：管道可能遭到濫用，導致雲端環境的完整性或安全控管機制遭到破壞。
- 資訊外洩：惡意人士可能會嘗試使用部署管道，外洩機密資料。
防範網路釣魚威脅
如要授予部署管道 Google Cloud的存取權，一般來說，您需要執行下列事項：
- 建立服務帳戶
- 授予服務帳戶存取必要資源的權限
- 設定部署管道以使用服務帳戶
從 IAM 的角度來看，服務帳戶代表部署管道，但部署管道和服務帳戶是兩個不同的實體。如果未妥善保護，惡意行為者可能會使用相同的服務帳戶，藉此「偽造」部署管道的身分。
以下章節將說明最佳做法，協助您降低這類威脅的風險。
最佳做法：
請避免將服務帳戶附加至 CI/CD 系統使用的 VM 執行個體。為每個部署管道使用專用服務帳戶。
盡可能使用 Workload Identity 聯盟。
使用 VPC Service Controls 降低憑證外洩的影響。
避免將服務帳戶附加至 CI/CD 系統使用的 VM 執行個體
如要讓部署在 Compute Engine 上的應用程式存取資源，通常最好是將服務帳戶附加至基礎 VM 執行個體。 Google Cloud如果 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 位址或來源 Google Cloud 專案納入考量。因此，遭竊的憑證可能會在任何地方使用。
您可以將專案放在 VPC 服務範圍中，並使用輸入規則，限制可存取 Google Cloud資源的來源：
- 如果部署管道在 Google Cloud上執行，您可以設定輸入規則，只允許從包含 CI/CD 系統的專案存取。
- 如果部署管道在 Google Cloud以外的位置執行，您可以建立存取層級，只允許來自特定地理位置或 IP 範圍的存取要求。然後建立允許存取的連入規則，讓符合這個存取層級的用戶端存取。
防範竄改威脅
您儲存在 Google Cloud的部分資料可能特別重要，因此必須防止未經授權的修改或刪除。如果特別擔心未經授權的修改或刪除行為，則可將資料歸類為高完整性資料。
為維護資料完整性，您必須確保用於儲存及管理資料的資源已安全設定，並維持完整性。 Google Cloud
部署管道可協助您維護資料和資源的完整性，但也可能造成風險：如果某個元件的管道不符合所管理資源的完整性要求，部署管道就會變成弱點，可能讓惡意行為人竄改您的資料或資源。
下一節將說明最佳做法，協助您降低竄改威脅的風險。
限制安全控管功能的存取權
為確保 Google Cloud上的資料和資源安全無虞，請使用下列安全控管措施：
- 允許政策和拒絕政策
- 機構政策限制
- VPC Service Controls 範圍、存取層級和 Ingress 政策
這些安全控管措施本身就是資源。竄改安全控制選項會危及安全控制選項所套用資源的完整性。因此，您必須將安全控管措施的完整性視為與所套用資源的完整性同等重要。
如果允許部署管道管理安全控管機制，則部署管道有責任維護安全控管機制的完整性。因此，您必須將部署管道本身的完整性，視為至少與其管理的安全性控制項完整性同等重要，以及這些控制項適用的資源。
您可以採取下列措施，限制部署管道對資源完整性的影響：
- 不授予部署管道存取權，允許政策、拒絕政策和其他安全控管措施，並限制其存取其他資源
- 僅授予特定安全性控制項的存取權，例如特定資源或專案的允許政策和拒絕政策，但不授予影響多個資源或專案的廣泛控制項存取權
如果部署管道、其元件和基礎架構無法滿足特定安全控管措施的完整性需求，最好避免讓部署管道管理這些安全控管措施。
防範不可否認性威脅
有時您可能會發現 Google Cloud上的某個資源出現可疑活動。在這種情況下，您必須能夠進一步瞭解活動，最好還能重構導致活動發生的事件鏈。
透過 Cloud 稽核記錄，您可以瞭解資源的存取或修改時間，以及相關使用者。雖然 Cloud 稽核記錄可做為分析可疑活動的起點，但這些記錄提供的資訊可能不夠充分：如果您使用部署管道，也必須能夠將 Cloud 稽核記錄與部署管道產生的記錄相互關聯。
本節提供最佳做法，協助您在部署管道中維護稽核追蹤記錄。 Google Cloud
確保您可以將部署管道記錄與 Cloud 稽核記錄相互關聯
Cloud 稽核記錄包含時間戳記，以及啟動活動的使用者相關資訊。如果您為每個部署管道使用專屬服務帳戶，這項資訊可協助您找出啟動活動的部署管道，並縮小範圍，找出可能導致問題的程式碼變更和管道執行作業。但如果沒有更多資訊可供您將 Cloud 稽核記錄與部署管道的記錄建立關聯，就難以找出導致活動的確切管道執行和程式碼變更。
您可以透過多種方式擴充 Cloud 稽核記錄，使其包含更多資訊，包括：
- 使用 Terraform 時，請指定要求原因，指出 CI/CD 管道執行。
- 在 API 要求中新增
X-Goog-Request-ReasonHTTP 標頭，並傳遞部署管道執行的 ID。 - 使用自訂
User-Agent，內嵌部署管道執行的 ID。
您也可以擴充部署管道發出的記錄：
- 記錄每次 CI/CD 管道執行作業的 API 要求。
- 每當 API 傳回作業 ID 時，請在 CI/CD 系統的記錄中記錄該 ID。
調整部署管道記錄和 Cloud 稽核記錄的保留期限
如要分析與部署管道相關的可疑活動，通常需要多種類型的記錄，包括管理員活動稽核記錄、資料存取稽核記錄，以及部署管道的記錄。
Cloud Logging 只會將記錄保留一段時間。根據預設，資料存取稽核記錄的保留期限比管理員活動稽核記錄短。執行部署管道的系統也可能會在一段時間後捨棄記錄。視部署管道的性質，以及部署管道所管理資源的重要性而定，這些預設保留期限可能不足或不符需求。
為確保需要時可存取記錄檔，請確認不同系統使用的記錄檔保留期限一致且夠長。
如有需要，請自訂資料存取稽核記錄的保留期限，或設定自訂接收器，將記錄檔傳送至自訂儲存位置。
防範資訊揭露威脅
如果部署管道的服務帳戶可以存取機密資料，惡意行為人可能會嘗試使用部署管道竊取該資料。部署管道可直接或間接存取資料：
直接：部署管道的服務帳戶可能有權從 Cloud Storage、BigQuery 或其他位置讀取機密資料。這項存取權可能是刻意授予，但也可能是授予過多存取權時意外造成的結果。
如果惡意行為者取得部署管道的存取權，並直接存取機密資料，他們可能會嘗試使用服務帳戶的存取權杖來存取及外洩資料。
間接：如要部署設定或新版軟體，部署管道的服務帳戶可能需要有權建立或重新部署運算資源，例如 Compute Engine VM 執行個體。其中部分資源可能附加了服務帳戶，可授予機密資料的存取權。
在這種情況下，不肖人士可能會嘗試入侵部署管道，以便將惡意程式碼部署至其中一個運算資源，並讓該程式碼竊取機密資料。
本節提供最佳做法，協助您降低揭露機密資料的風險。
避免直接授予機密資料的存取權
部署基礎架構、設定或新版軟體時，部署管道通常不需要存取現有資料。因此，限制存取不含任何資料的資源，或至少不含機密資料的資源，通常就已足夠。
如要盡量減少對現有潛在機密資料的存取權，可以採取下列做法：
- 請只授予特定資源的存取權，而不是授予部署管道服務帳戶整個專案的存取權。
- 授予建立權限，但不允許讀取權限。舉例來說，您可以授予儲存空間物件建立者角色 (
roles/storage.objectCreator)，允許服務帳戶將新物件上傳至 Cloud Storage 值區，但無權讀取現有資料。 - 將基礎架構即程式碼 (IaC) 限制在機密程度較低的資源，例如使用 IaC 管理 VM 執行個體或網路，但不要管理機密 BigQuery 資料集。
使用 VPC Service Controls 防範資料竊取
您可以在 VPC Service Controls perimeter 中部署資源 Google Cloud ，降低間接資料竊取風險。
如果部署管道在 Google Cloud之外執行，或是屬於其他範圍，您可以設定輸入規則，將範圍的存取權授予管道的服務帳戶。如有可能，請設定 Ingress 規則，只允許部署管道使用的 IP 位址存取，並只允許部署管道真正需要的服務存取。
防範權限提升威脅
部署管道使用服務帳戶存取資源時，無論是哪位開發人員或使用者撰寫程式碼或設定變更，都會使用服務帳戶。 Google Cloud管道的服務帳戶與開發人員身分之間的連結中斷，導致部署管道容易遭受混淆副手攻擊。在這種情況下，惡意行為者會誘騙管道執行自己無權執行的動作，而管道甚至可能不應執行該動作。
本節提供最佳做法，協助您降低部署管道遭濫用而導致權限提升的風險。
限制部署管道和所有輸入內容的存取權
大多數部署管道會使用原始碼存放區做為主要輸入來源，並在偵測到特定分支 (例如 main 分支) 的程式碼變更時，自動觸發管道。部署管道通常無法驗證在原始碼存放區中找到的程式碼和設定是否真實可靠。因此，這項架構的安全性取決於：
- 控管誰可以將程式碼和設定提交至部署管道使用的存放區和分支。
- 強制執行變更前必須符合的條件，例如通過程式碼審查、靜態分析或自動測試。
如要確保這些控管措施有效，請務必採取下列行動，防止不肖分子規避：
- 修改原始碼存放區或部署管道的設定。
- 竄改部署管道的基礎架構 (例如 VM 和儲存空間)。
- 在原始碼存放區外部修改或替換輸入內容，例如套件、容器映像檔或程式庫。
如果資源是由部署管道管理， Google Cloud 上的資源安全性只會與部署管道、其設定、基礎架構和輸入內容一樣安全。因此，您必須保護這些元件，確保資源受到妥善保護。Google Cloud
避免讓部署管道修改政策
對於大多數類型的資源，IAM 會定義 RESOURCE_TYPE.setIamPolicy 權限。這項權限可讓使用者修改資源的允許政策，授予其他使用者存取權，或修改及延長自己的存取權。除非受到拒絕政策限制，否則授予使用者或服務帳戶 *.setIamPolicy 權限，就等於授予資源的完整存取權。
請盡可能避免讓部署管道修改資源存取權。將管道的服務帳戶存取權授予 Google Cloud 資源時，請使用不含任何 *.setIamPolicy 權限的角色，並避免使用「編輯者」和「擁有者」基本角色。
在某些部署管道中，可能無法避免授予修改允許政策或拒絕政策的權限。舉例來說，部署管道的用途可能是建立新資源，或是管理現有資源的存取權。在這些情況下，您仍可透過下列方式限制部署作業修改存取權的程度：
- 僅授予特定資源的
*.setIamPolicy權限，而非整個專案的權限。 - 使用 IAM 拒絕政策來限制可授予的權限組合，或限制可授予權限的主體。
- 使用 IAM Conditions 限制管道可授予的角色，且只允許不含
*.setIamPolicy權限的角色。
請勿在記錄中揭露服務帳戶憑證
部署管道產生的記錄通常可供更多使用者存取，包括沒有權限修改管道設定的使用者。這些記錄可能會透過回應下列內容，意外揭露憑證：
- 環境變數內容
- 指令列引數
- 診斷輸出
如果記錄意外揭露存取權杖等憑證，不肖人士可能會濫用這些憑證來提權。如要避免記錄檔洩漏憑證，請採取下列措施：
- 避免將存取權杖或其他憑證做為指令列引數傳遞
- 避免將憑證儲存在環境變數中
- 盡可能設定 CI/CD 系統，自動偵測及遮蓋權杖和其他憑證
後續步驟
- 進一步瞭解 Workload Identity 聯盟，以及使用 Workload Identity 聯盟的最佳做法。
- 請參閱企業基礎藍圖，以及驗證和授權相關指南。
- 進一步瞭解使用服務帳戶的最佳做法。