Azure Pipelines 的其他安全性考慮
Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020
在保護 Azure Pipelines 方面，有數個其他考慮要牢記在心，例如保護共用基礎結構、存放庫、專案等等。
保護共用基礎結構
Azure Pipelines 中的受保護資源是真實基礎結構的抽象概念。 請遵循這些建議來保護基礎結構。
使用Microsoft裝載集區
Microsoft裝載的集區會針對管線的每個執行提供隔離和乾淨的虛擬機。 可能的話，請使用Microsoft裝載的集區，而不是自我裝載集區。
每個專案的個別代理程式
代理程式只能與單一集區相關聯。 您可以將集區與多個專案建立關聯，以跨專案共用代理程式。 實際上，多個專案可能會連續使用相同的代理程式。 雖然符合成本效益，但這種方法可能會帶來橫向移動風險。
若要減輕橫向移動並防止專案之間的交叉污染，請維護個別的代理集區，每個集區都專用於特定專案。
使用低許可權帳戶來執行代理程式
雖然您可能很想，在直接存取 Azure DevOps 資源的身分識別下執行代理程式可能會有風險。 此設定在組織使用 Microsoft Entra ID 時很普遍，但會造成風險。 如果您在Microsoft Entra標識符支援的身分識別下執行代理程式，則可以直接存取 Azure DevOps API，而不需要依賴作業的存取令牌。 為了獲得更好的安全性，請考慮使用非特殊許可權的本機帳戶來執行代理程式，例如網路服務。
重要
在 Azure DevOps 中，有一個名為 Project Collection Service Accounts 的群組，可能會產生誤導。 藉由繼承，Project Collection Service 帳戶的成員也會被視為 Project Collection Administrators 的成員。 有些客戶會使用Microsoft Entra標識符支援的身分識別來執行其組建代理程式，而這些身分識別可能是專案集合服務帳戶的一部分。 但是，如果敵人在這些組建代理程式之一上執行管線，他們可能會控制整個 Azure DevOps 組織。
在某些情況下，自我裝載代理程式會以高許可權帳戶運作。 這些代理程式通常會使用這些特殊許可權帳戶來存取秘密或生產環境。 但是，如果敵人在其中一個組建代理程式上執行遭入侵的管線，他們就會取得這些秘密的存取權。 然後，敵人可以透過這些帳戶存取的其他系統橫向移動。
若要增強系統安全性，建議您使用最低許可權帳戶來執行自我裝載代理程式。 例如，請考慮使用您的電腦帳戶或受控服務識別。 此外，請委託 Azure Pipelines 管理秘密和環境的存取權。
將服務連線的範圍降到最低
請確定服務連線只能存取必要的資源。 只要可行，請考慮使用 工作負載身分識別同盟 來取代 Azure 服務連線的服務主體。 工作負載身分識別同盟會使用 Open ID Connect （OIDC），這是業界標準技術，可協助 Azure 與 Azure DevOps 之間的驗證，而不需要依賴秘密。
請確定您的 Azure 服務連線 範圍僅限於存取必要的資源。 避免將整個 Azure 訂用帳戶的廣泛參與者許可權授與使用者。
當您建立新的 Azure Resource Manager 服務連線時，請一律選擇特定的資源群組。 請確定資源群組只包含組建所需的 VM 或資源。 同樣地，當您設定 GitHub 應用程式時，請僅將存取權授與您想要使用 Azure Pipelines 建置的存放庫。
保護專案
除了個別資源之外，請務必考慮 Azure DevOps 中的資源群組。 資源會依小組項目組織，並瞭解您的管線可以根據專案設定和內含專案存取的內容至關重要。
管線中的每個作業都會接收具有讀取開啟資源許可權的存取令牌。 在某些情況下，管線也可能更新這些資源。 這表示，雖然您的用戶帳戶可能無法直接存取管線中執行的特定資源、腳本和工作，但仍可以存取它。 此外，Azure DevOps 的安全性模型允許從組織內的其他專案存取這些資源。 如果您決定限制特定資源的管線存取，此決策會套用至專案內的所有管線，特定管線無法選擇性地授與對開啟資源的存取權。
個別專案
考慮到開放資源的本質，請考慮在不同的專案中管理每個產品和小組。 如此一來，您就可以防止管線從某個產品意外存取另一個產品的開放資源，從而將橫向暴露降至最低。 但是，當多個小組或產品共享專案時，其資源的細微隔離會變得具有挑戰性。
如果您的 Azure DevOps 組織是在 2019 年 8 月之前建立的，執行可能仍可存取所有組織的專案開啟資源。 您的組織系統管理員應該檢閱 Azure Pipelines 中啟用管線項目隔離的重要安全性設定。
您可以在 [組織設定>管線設定>] 中找到此設定，或直接找到：。 https://dev.azure.com/Organization_Name/_settings/pipelinessettings
保護存放庫
在版本控制存放庫中，您可以儲存原始程式碼、管線的 YAML 檔案，以及必要的腳本和工具。 為了確保程式代碼和管線的安全變更，套用許可權和分支原則非常重要。 此外，請考慮 將管線許可權和檢查新增至存放庫。
此外，請檢閱 存放庫的預設訪問控制設定 。
請記住，Git 的設計表示分支層級保護有限制。 具有存放庫推送存取權的使用者通常可以建立新的分支。 如果您正在使用 GitHub 開放原始碼專案，任何具有 GitHub 帳戶的任何人都可以派生您的存放庫，並提出貢獻。 由於管線與存放庫相關聯（不是特定的分支），因此請務必將程序代碼和 YAML 檔案視為可能不受信任。
分支
當您從 GitHub 使用公用存放庫時，請務必仔細考慮您的分支組建方法。 分支源自組織外部，構成特定風險。 若要保護您的產品免於可能不受信任的參與程序代碼，請將下列建議納入考慮
注意
這些建議主要適用於從 GitHub 建置公用存放庫。
請勿提供分支組建的秘密
根據預設，您的管線會設定為建置分叉，但秘密和受保護的資源不會自動公開至這些管線中的作業。 請務必不要停用此保護來維護安全性。
注意
當您啟用分支組建來存取秘密時，Azure Pipelines 會限制預設使用的存取令牌。 相較於一般存取令牌，此令牌對開啟資源的存取有限。 若要授與分叉組建與一般組建相同的許可權，請啟用 Make fork 組建與一般組建 設定相同的許可權。
注意
當您啟用分支組建來存取秘密時，Azure Pipelines 會限制預設使用的存取令牌。 其存取權比一般存取令牌還有限。 您無法停用此保護。
請考慮手動觸發分支組建
您可以關閉自動分叉組建 ，並改用提取要求批註作為手動建置這些貢獻的方式。 此設定可讓您在觸發組建之前先檢閱程式代碼。
使用Microsoft裝載的代理程式分支組建
避免在自我裝載代理程式上從分支執行組建。 這樣做可讓外部組織在公司網路內的機器上執行外部程序代碼。 盡可能使用Microsoft裝載的代理程式。 針對自我裝載代理程式，請實作網路隔離，並確保代理程式不會在作業之間保存其狀態。
檢閱程式代碼變更
在分岔提取要求上執行管線之前，請仔細檢閱建議的變更，並確定您已熟悉執行該變更。
您執行的 YAML 管線版本是提取要求中的 YAML 管線版本。 因此，請特別注意 YAML 程式碼的變更，以及管線執行時所執行的程式碼，例如命令列指令碼或單元測試。
GitHub 令牌範圍限制
當您建置 GitHub 分支提取要求時，Azure Pipelines 可確保管線無法變更任何 GitHub 存放庫內容。 只有在您使用 Azure Pipelines GitHub 應用程式與 GitHub 整合時，才適用這項限制。 例如，如果您使用其他形式的 GitHub 整合，則 OAuth 應用程式不會強制執行限制。
使用者分支
您組織中具有適當許可權的使用者可以建立包含新或更新程式代碼的新分支。 此程式代碼可以透過與受保護分支相同的管線執行。 如果新分支中的 YAML 檔案已變更，則會使用更新的 YAML 來執行管線。 雖然這種設計提供極大的彈性和自助功能，但並非所有變更都是安全的 (無論是否有惡意)。
如果您的管線取用原始程式碼或在 Azure Repos 中定義，您必須完全瞭解 Azure Repos 許可權模型。 特別是，在存放庫層級具有 建立分支 許可權的使用者，即使該使用者缺少 參與 許可權，也會將程式代碼引入存放庫。
其他安全性考量
保護管線時，您應該考慮下列幾個其他事項。
依賴PATH
依賴代理程序的 PATH 設定很危險。 它可能不會指出您認為它的位置，因為它可能由先前的腳本或工具改變。 針對安全性關鍵腳本和二進位檔，請一律使用程式的完整路徑。
記錄秘密
Azure Pipelines 會盡可能嘗試從記錄中清除祕密。 此篩選作業係盡力而為，無法攔截祕密可能洩漏的每個方式。 避免將祕密回應至主控台、在命令列參數中使用祕密，或將其記錄到檔案。
鎖定容器
容器在與主機代理程序通訊所需的工作、工作區和外部元件中，有一些系統提供的磁碟區掛接對應。 您可以標示這些磁碟區的任何或全部唯讀。
resources:
containers:
- container: example
image: ubuntu:22.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false # the default; shown here for completeness
一般而言，大多數人應該將前三個目錄設定為唯讀，並保留 work 為讀寫。
如果您未在特定作業或步驟中寫入 work 目錄，您也可以隨意進行 work 唯讀。 但是，如果您的管線工作涉及自我修改，您可能需要保留 tasks 為讀寫。
控制可用的工作
您可以停用從 Marketplace 安裝和執行工作的能力，這可讓您更充分掌控管線中執行的程式碼。 您也可以停用所有現成的工作（除了簽出以外，這是代理程式的特殊動作）。 我們建議您在大部分情況下不要停用現用的工作。
直接安裝的工作 tfx 一律可供使用。
啟用這兩項功能后， 只有 這些工作可供使用。
使用稽核服務
稽核服務中會記錄許多管線事件。
定期檢閱稽核記錄檔，以確保不會有任何惡意變更滑過。
請造訪 https://dev.azure.com/ORG-NAME/_settings/audit 以開始使用。