部署管道是自動化程序，可將程式碼或預先建構的構件部署至測試環境或實際工作環境。部署管道通常用於部署應用程式、設定或雲端基礎架構 (基礎架構即程式碼)，並可在雲端部署的整體安全防護機制中扮演重要角色。
本指南適用於 DevOps 和安全性工程師，並說明如何根據機密性、完整性和可用性需求，設計安全的部署管道。
架構
下圖顯示部署管道中的資料流程。說明如何將構件轉換為資源。
部署管道通常是更大規模的持續整合/持續部署 (CI/CD) 工作流程的一部分，通常會使用下列其中一種模型實作：
推送模型：在這個模型中，您會使用集中式 CI/CD 系統 (例如 Jenkins 或 GitLab) 實作部署管道。這個持續整合/持續推送系統可能會在 Google Cloud、內部部署環境或其他雲端環境中執行。通常會使用相同的 CI/CD 系統來管理多個部署管道。
推送模式會導致集中式架構，其中包含一些 CI/CD 系統，用於管理可能大量的資源或應用程式。舉例來說，您可以使用單一 Jenkins 或 GitLab 執行個體來管理整個實際工作環境，包括所有專案和應用程式。
拉取模型：在這個模型中，部署程序是由與資源一併部署的代理程式實作，例如在同一個 Kubernetes 叢集中。代理程式會從集中位置提取構件或原始碼，並在本機上部署這些項目。每個代理程式都會管理一或兩個資源。
使用拉取模式可建立更去中心化的架構，並可能包含大量單一用途的代理程式。
與手動部署相比，持續使用部署管道可帶來下列優點：
- 提高效率，因為不需要手動操作。
- 可提高可靠性，因為這項程序完全自動化且可重複執行。
- 可追溯性更高，因為您可以追蹤所有部署作業，以便查看程式碼或輸入構件中的變更。
部署管道必須具備管理的資源存取權，才能執行：
- 使用 Terraform 等工具部署基礎架構的管道，可能需要建立、修改，甚至刪除 VM 執行個體、子網路或 Cloud Storage 值區等資源。
- 部署應用程式的管道可能需要將新的容器映像檔上傳至 Artifact Registry，並將新的應用程式版本部署至 App Engine、Cloud Run 或 Google Kubernetes Engine (GKE)。
- 管理設定或部署設定檔的管道可能需要修改 VM 執行個體中繼資料、Kubernetes 設定，或修改 Cloud Storage 中的資料。
如果部署管道未妥善防護，其對Google Cloud 資源的存取權可能會成為安全防護機制的弱點。安全性降低可能導致多種攻擊，包括：
管道中毒攻擊：惡意行為人可能不會直接攻擊資源，而是試圖入侵部署管道、其設定或基礎架構。惡意人士可利用管道對 Google Cloud的存取權，讓管道對 Cloud 資源執行惡意動作，如以下圖表所示：
供應鏈攻擊：惡意人士可能不會攻擊部署管道，而是嘗試入侵或取代管道輸入內容，包括原始碼、程式庫或容器映像檔，如以下圖表所示：
如要判斷部署管道是否有適當的安全防護，單獨檢視 Google Cloud 資源的允許政策和拒絕政策是不夠的。相反地，您必須考量直接或間接授予資源存取權的整個系統圖。這張圖表包含以下資訊：
- 部署管道、其底層 CI/CD 系統，以及底層基礎架構
- 原始碼存放區、其底層伺服器和基礎架構
- 輸入構件、儲存位置和基礎架構
- 產生輸入構件及底層基礎架構的系統
複雜的輸入圖表會讓您難以識別使用者對資源的存取權和系統性弱點。
以下各節將說明設計部署管道時的最佳做法，協助您管理圖表大小，並降低橫向移動和供應鏈攻擊的風險。
評估安全目標
Google Cloud 上的資源可能會因敏感度而異。某些資源可能極為機密，因為它們對業務至關重要或屬於機密資料。其他資源可能較不敏感，因為它們是暫時性的，或僅供測試之用。
如要設計安全的部署管道，您必須先瞭解管道需要存取的資源，以及這些資源的敏感程度。資源的敏感程度越高，您就越應該專注於保護管道。
部署管道存取的資源可能包括：
- 應用程式，例如 Cloud Run 或 App Engine
- 雲端資源，例如 VM 執行個體或 Cloud Storage 值區
- 資料，例如 Cloud Storage 物件、BigQuery 記錄或檔案
其中有些資源可能會依附其他資源，例如：
- 應用程式可能會存取資料、雲端資源和其他應用程式。
雲端資源 (例如 VM 執行個體或 Cloud Storage 值區) 可能包含應用程式或資料。
如上圖所示，依附元件會影響資源的機密程度。舉例來說，如果您使用的應用程式會存取高度機密資料，通常應將該應用程式視為高度機密。同樣地，如果 Cloud Storage 值區等雲端資源含有機密資料，通常應將該值區視為機密資料。
由於這些依附元件，建議您先評估資料的機密性。評估完資料後，您可以檢查依附元件鏈結，並評估 Cloud 資源和應用程式的敏感度。
將資料敏感度分類
如要瞭解部署管道中的資料敏感度，請考量下列三個目標：
- 機密性：您必須保護資料，避免他人未經授權存取。
- 完整性：您必須保護資料，避免遭到未經授權的修改或刪除。
- 可用性：您必須確保授權人員和系統可以存取部署管道中的資料。
針對每個目標，請思考如果管道遭到入侵，會發生什麼情況：
- 機密性：如果資料洩漏給不肖人士或公開，會造成多大的損害？
- 完整性：如果資料遭到惡意人士修改或刪除，會造成多大的損害？
- 可用性：如果不肖人士中斷您的資料存取權，會造成多大的損害？
為了讓不同資源的結果可相互比較，建議您引入安全性類別。安全性分類標準 (FIPS-199) 建議使用下列四個類別：
- 高：損害嚴重或災難性
- 中度：損害嚴重
- 低：損害有限
- 不適用：標準不適用
視環境和情境而定，您可能會需要使用其他類別。
管道資料的機密性和完整性會根據剛才討論的安全性類別而有所不同。以下各節包含不同機密性和完整性評估指標的資源範例：
機密性低，但完整性為低、中和高資源
以下資源範例的機密度皆偏低：
- 低完整性：測試資料
- 審查完整性：公開網路伺服器內容、貴機構的政策限制
- 高完整性：容器映像檔、磁碟映像檔、應用程式設定、存取權政策 (允許和拒絕清單)、留置、存取層級資料
機密性為中等，但完整性為低、中和高資源
以下資源範例的機密程度皆為中等：
- 低完整性：內部網路伺服器內容
- 中等完整性：稽核記錄
- 高完整性：應用程式設定檔
機密性高但完整性低、中、高的資源
以下資源範例都具有高度機密性：
- 低完整性：使用資料和個人識別資訊
- 中等完整性：機密資訊
- 高完整性：財務資料、KMS 金鑰
根據應用程式存取的資料將其分類
當應用程式存取機密資料時，應用程式和管理應用程式的部署管道也可能會變成機密資料。如要判斷敏感度，請查看應用程式和管道需要存取的資料。
在您識別並分類應用程式存取的所有資料後，您可以使用下列類別，在設計安全部署管道之前，先將應用程式分類：
- 機密性：存取的資料最高類別
- 完整性：存取的任何資料最高類別
- 可用性：存取的任何資料最高類別
這項初步評估可提供指引，但可能還有其他因素需要考量，例如：
- 兩組資料在個別情況下可能具有較低的機密性。但如果將兩者結合，就能發掘新的洞察資料。如果應用程式可存取這兩組資料，您可能需要將其歸類為中等或高機密。
- 如果應用程式可存取高完整性資料，通常應將應用程式歸類為高完整性。但如果該存取權為唯讀，則高完整度的分類可能太嚴格。
如要進一步瞭解如何以正式方法將應用程式分類，請參閱「Guide for Mapping Types of Information and Information Systems to Security Categories (NIST SP 800-60 Vol. 2 Rev1)」(資訊和資訊系統類型對應至安全性類別的指南)。
根據雲端資源所託管的資料和應用程式進行分類
您在 Google Cloud 上部署的任何資料或應用程式，都會由Google Cloud 資源代管：
- 應用程式可能由 App Engine 服務、VM 執行個體或 GKE 叢集代管。
- 您的資料可能由永久磁碟、Cloud Storage 值區或 BigQuery 資料集代管。
當雲端資源代管敏感資料或應用程式時，資源和管理資源的部署管道也可能會變成敏感資源。舉例來說，您應將 Cloud Run 服務及其部署管道視為與其代管的應用程式同樣敏感。
分類資料和應用程式後，請為應用程式建立初始安全性類別。如要這樣做，請從下列類別中決定等級：
- 機密性：代管的任何資料或應用程式最高類別
- 完整性：代管的任何資料或應用程式最高類別
- 可用性：代管的任何資料或應用程式最高類別
進行初步評估時，請不要過於嚴格，例如：
- 如果您加密高度機密資料，請將加密金鑰視為高度機密資料。不過，您可以為含有資料的資源使用較低的安全性類別。
- 如果您儲存資料的備份副本，或在多個資源中執行相同應用程式的備用執行個體，您可以將資源類別設為低於其代管資料或應用程式的類別。
限制部署管道的使用
如果部署管道需要存取機密資源，您必須考量其安全性。 Google Cloud資源越敏感，您就越需要嘗試保護管道。不過，您可能會遇到下列實際限制：
- 使用現有基礎架構或現有的 CI/CD 系統時，該基礎架構可能會限制您實際可達到的安全性等級。舉例來說，您的 CI/CD 系統可能只支援有限的安全控管機制，或是在您認為不如部分正式版環境安全的基礎架構上執行。
- 設定新的基礎架構和系統來執行部署管道時，如果要以符合最嚴格安全性要求的方式保護所有元件，可能就會造成成本效益不佳的情況。
為了因應這些限制，您可以針對哪些情況應使用、不應使用部署管道和特定 CI/CD 系統，設定限制。舉例來說，最機密的部署作業通常會在部署管道之外處理。這些部署作業可以是手動作業，使用特殊權限工作階段管理系統或特殊權限存取管理系統，或是其他工具代理程式。
如要設定限制，請根據資源類別定義要強制執行的存取權控管機制。請參考下表提供的指引：
| 資源類別 | 存取權控管設定 |
|---|---|
| 低 | 無須獲得核准 |
| 中 | 團隊主管必須核准 |
| 高 | 多位業務人員必須核准，且必須記錄相關動作 |
請比較這些需求與原始碼管理 (SCM) 和 CI/CD 系統的功能，並回答下列問題：
- 您的 SCM 或 CI/CD 系統是否支援必要的存取權控管和核准機制？
- 如果惡意行為人攻擊基礎設施，控制項是否能防範破壞行為？
- 定義控制項的設定是否已妥善加密？
接著，視 SCM 或 CI/CD 系統的功能和限制而定，您可以為部署管道定義資料和應用程式限制。請參考下表提供的指引：
| 資源類別 | 限制 |
|---|---|
| 低 | 可使用部署管道，開發人員可以自行核准部署作業。 |
| 中 | 可以使用部署管道，但團隊主管必須核准每個提交和部署作業。 |
| 高 | 請勿使用部署管道。管理員必須改用特權存取管理系統和工作階段錄製功能。 |
維持資源可用性
使用部署管道管理資源可能會影響這些資源的可用性，並引入新風險：
- 導致服務中斷：部署管道可能會推送有瑕疵的程式碼或設定檔，導致先前運作正常的系統中斷，或資料無法使用。
- 延長服務中斷時間：如要修正服務中斷問題，您可能需要重新執行部署管道。如果部署管道發生問題或因其他原因無法使用，可能會導致服務中斷時間延長。
可能會導致或延長服務中斷情形的管道，會帶來拒絕服務風險：不肖人士可能會利用部署管道故意造成服務中斷。
建立緊急存取程序
如果部署管道是部署或設定應用程式或資源的唯一方式，管道可用性就會變得至關重要。在極端情況下，如果部署管道是管理重要業務應用程式的唯一方法，您可能也需要將部署管道視為重要業務。
由於部署管道通常由多個系統和工具組成，因此要維持高可用性可能很困難，或不符合經濟效益。
您可以建立緊急存取程序，減少部署管道對可用性造成的影響。舉例來說，您可以建立替代存取路徑，以便在部署管道無法運作時使用。
建立緊急存取程序通常需要執行下列大部分程序：
- 維護一個或多個使用者帳戶，並授予該帳戶存取相關Google Cloud 資源的權限。
- 將緊急存取權使用者帳戶的憑證儲存在安全位置，或使用特權存取權管理系統來仲介存取權。
- 建立程序，讓獲授權的員工可以按照程序存取憑證。
- 稽核及審查緊急存取使用者帳戶的使用情形。
確保輸入構件符合可用性需求
部署管道通常需要先從中央原始碼存放區下載原始碼，才能執行部署作業。如果原始碼存放區無法使用，執行部署管道可能會失敗。
許多部署管道也依賴第三方構件。這些構件可能包含來自 npm、Maven Central 或 NuGet Gallery 等來源的程式庫，以及容器基礎映像檔、.deb 和 .rpm 套件。如果其中一個第三方來源無法使用，執行部署管道可能會失敗。
為了維持一定的可用性，您必須確保部署管道的輸入構件都符合相同或更高的可用性要求。以下清單可協助您確保輸入構件可用：
- 限制輸入構件 (尤其是第三方來源) 的來源數量
- 維持輸入構件快取，以便部署管道在來源系統無法使用時使用
將部署管道及其基礎架構視為實際工作環境系統
部署管道通常是開發、測試與實際工作環境之間的連結點。視環境而定，可能會實作多個階段：
- 在第一階段，部署管道會更新開發環境。
- 在下一階段，部署管道會更新測試環境。
- 在最後階段，部署管道會更新實際工作環境。
在多個環境中使用部署管道時，請確保管道符合各環境的可用性需求。由於正式環境通常有最高的可用性需求，因此您應將部署管道及其基礎結構視為正式系統。換句話說，請將相同的存取權控管、安全性和品質標準套用至執行部署管道的基礎架構，就像您為實際運作系統所做的那樣。
限制部署管道的範圍
部署管道可存取的資源越多，如果遭到入侵，可能造成的損害就越大。遭到入侵的部署管道可存取多個專案，甚至是整個機構，在最糟的情況下，可能會對Google Cloud上的所有資料和應用程式造成永久性的損害。
為避免發生這種最糟糕的情況，請限制部署管道的範圍。定義每個部署管道的範圍，讓它只需要存取 Google Cloud上相對較少數量的資源：
- 請勿在專案層級授予存取權，而是只將個別資源的存取權授予部署管道。
- 請勿授予跨多個 Google Cloud 專案的資源存取權。
- 如果部署管道需要存取多個專案或環境，請將其分割成多個階段。接著，個別保護各個階段。
保密
部署管道必須維護所管理資料的機密性。資料外洩是機密性相關的主要風險之一。
不肖人士可能會嘗試透過多種方式，使用部署管道從您的 Google Cloud 資源中竊取資料。這些方式包括：
- 直接：惡意人士可能會修改部署管道或其設定，讓該管道從 Google Cloud資源中擷取資料，然後複製到其他位置。
- 間接：惡意人士可能會使用部署管道部署遭到入侵的程式碼，然後從 Google Cloud環境竊取資料。
您可以盡量減少機密資源的存取權，降低機密性風險。不過，移除所有機密資源的存取權可能不切實際。因此，您必須設計部署管道，以符合所管理資源的機密性需求。如要判斷這些需求，您可以使用下列方法：
- 判斷部署管道需要存取的資料、應用程式和資源，並加以分類。
- 找出機密性最高的資源，並將其用作部署管道的初始類別。
與應用程式和雲端資源的分類程序類似，這項初步評估不一定適合所有情況。舉例來說，您可以使用部署管道建立最終會包含高度機密資訊的資源。如果您限制部署管道，讓它可以建立但無法讀取這些資源，則較低的機密性類別可能就足夠了。
為確保機密性，Bell-LaPadula 模型建議部署管道不得：
- 使用機密性較高的輸入構件
- 將資料寫入機密性較低的資源
根據 Bell-LaPadula 模型，上圖顯示資料應如何在管道中流動，以確保資料機密性。
不要讓部署管道讀取不需要的資料
部署管道通常不需要存取資料，但可能仍會存取資料。這類過度授予存取權的情況可能源自：
- 授予錯誤的存取權限。例如，部署管道可能會在專案層級授予 Cloud Storage 存取權。因此，部署管道可以存取專案中的所有 Cloud Storage 值區，但存取單一值區可能就足夠了。
- 使用權限過高的角色。例如，部署管道可能會授予可提供 Cloud Storage 完整存取權的角色。不過，只要具備建立新資料夾的權限即可。
管道可存取的資料越多，遭竊取資料的風險就越高。為盡量降低這類風險，請勿將不必要的資料存取權授予部署管道。許多部署管道根本不需要資料存取權，因為它們的唯一目的是管理設定或軟體部署作業。
避免部署管道寫入不必要的位置
如要移除資料，惡意人士必須具備存取權，並能將資料從您的環境中轉移。部署管道可傳送資料的儲存空間和網路位置越多，惡意人士就越有可能利用其中一個位置進行資料外洩。
您可以限制管道可傳送資料的網路和儲存位置數量，以降低風險：
- 撤銷管道不需要的資源寫入權限，即使這些資源不含任何機密資料也一樣。
- 封鎖網際網路存取權，或限制連線至許可清單中的網路位置。
對於您歸類為「中度機密」或「高度機密」的管道而言，限制外出存取權尤其重要，因為這些管道可存取機密資料或加密編譯金鑰內容。
使用 VPC Service Controls 防範遭到入侵的部署作業竊取資料
惡意人士可能會嘗試使用部署管道部署遭到入侵的程式碼，而非讓部署管道執行資料外洩作業。遭到入侵的程式碼隨後可能會從您的 Google Cloud環境中竊取資料。
您可以使用 VPC Service Controls 降低這類資料竊取威脅的風險。您可以使用 VPC Service Controls 限制從特定Google Cloud 專案存取的資源和 API 組合。
維持完整性
為確保 Google Cloud 環境安全，您必須保護其完整性。包括：
- 防止未經授權的資料或設定修改或刪除行為
- 防止部署不受信任的程式碼或設定
- 確保所有變更都會留下清楚的稽核追蹤
部署管道可讓您執行下列操作，協助維持環境完整性：
- 實施核准程序，例如程式碼審查
- 針對所有設定或程式碼變更，強制執行一致的程序
- 在每次部署前執行自動化測試或快速檢查
為確保成效，您必須盡力確保不肖分子無法破壞或規避這些措施。為避免發生這類活動，您必須保護下列項目的完整性：
- 部署管道及其設定
- 基礎架構
- 部署管道使用的所有輸入
為避免部署管道遭到入侵，請盡量確保部署管道的完整性標準符合或超越所管理資源的完整性需求。如要判斷這些需求，您可以使用下列方法：
- 判斷部署管道需要存取的資料、應用程式和資源，並加以分類。
- 找出完整性類別最高的資源，並將其用作部署管道的類別。
為維持部署管道的完整性，Biba 模型建議：
- 部署管道不得使用完整性較低的輸入構件。
- 部署管道不得將資料寫入完整性較高的資源。
根據 Biba 模型，上圖顯示資料應如何在管道中流動，以確保資料完整性。
驗證輸入構件是否正確
許多部署管道都會使用第三方來源的構件。這類構件可能包括：
- Docker 基本映像檔
.rpm或.deb套件- Maven、
.npm或 NuGet 程式庫
不肖人士可能會嘗試修改部署管道，以便使用第三方構件遭到入侵的版本，方法如下：
- 存放構件的存放區遭到入侵
- 修改部署管道的設定，改用其他來源存放區
- 上傳名稱相似或含有錯字的惡意套件
許多套件管理工具都支援程式碼簽署，可讓您驗證套件的真實性。舉例來說，您可以使用 PGP 為 RPM 和 Maven 套件簽署。您可以使用 Authenticode 簽署 NuGet 套件。
您可以使用程式碼簽署功能，降低遭受第三方套件入侵的風險，方法如下：
- 要求所有第三方構件都已簽署
- 維護可信任的發布者憑證或公開金鑰清單
- 讓部署管道驗證第三方構件與信任的發布商清單的簽名
或者，您也可以驗證構件雜湊。您可以將這種方法用於不支援程式碼簽署且變更頻率不高的構件。
確保基礎架構符合完整性需求
不肖分子可能會嘗試破壞基礎架構，而非破壞部署管道本身，包括：
- 執行部署管道的 CI/CD 軟體
- 管道使用的工具，例如 Terraform、kubectl 或 Docker
- 作業系統及其所有元件
由於部署管道基礎架構通常相當複雜，且可能包含來自不同供應商或來源的元件，因此這類安全違規很難偵測。
您可以採取以下做法，降低基礎架構遭到入侵的風險：
- 基礎架構和所有元件都必須符合部署管道和所管理的 Google Cloud 資源的完整性標準
- 確認工具來自可信任的來源，並驗證其真實性
- 定期從頭重建基礎架構
- 在防護 VM 上執行部署管道
在管道中套用完整性控制項
雖然不肖人士是威脅，但他們並非唯一可能導致軟體或設定變更，進而損害Google Cloud 環境完整性的來源。這類變更也可能來自開發人員，可能是因為他們不瞭解相關規定，或是輸入錯誤或其他錯誤而導致意外變更。
您可以設定部署管道，套用額外的完整性控管措施，藉此降低不慎套用風險性變更的風險。這類控制措施可能包括：
- 對程式碼和設定執行靜態分析
- 要求所有變更都必須通過一組規則 (政策做為程式碼)
- 限制可同時進行的變更數量
後續步驟
- 瞭解在部署管道中使用服務帳戶的最佳做法。
- 請參閱保護服務帳戶的最佳做法。
- 進一步瞭解如何調查及回應威脅。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。