共用方式為


存放庫保護

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020

原始碼、管線的 YAML 檔案和必要的腳本和工具全都儲存在版本控制存放庫中。 必須採用許可權和分支原則,以確保對程式代碼和管線的變更是安全的。 您也可以 將管線許可權和檢查新增至存放庫

此外,您應該檢閱 存放庫的預設訪問控制

由於 Git 的設計,分支層級的保護只能到此為止。 具有存放庫推送存取權的使用者通常可以建立新的分支。 如果您使用 GitHub 開放原始碼專案,任何具有 GitHub 帳戶的使用者都可以將您的存放庫進行分支,並提出貢獻。 由於管線是與存放庫建立關聯,而不是與特定分支建立關聯,因此您必須假設程式碼和 YAML 檔案不受信任。

分支

如果您從 GitHub 建置公用存放庫,就必須考慮分支組建的立場。 分支尤其危險,因為它們來自組織外部。 若要保護您的產品免於參與的程式代碼,請考慮下列建議。

注意

下列建議主要適用於從 GitHub 建置公用存放庫。

請勿提供分支組建的秘密

根據預設,您的管線會設定為建置分叉,但根據預設,這些管線中的作業不會提供秘密和受保護的資源。 請勿關閉後者的保護。

Screenshot of fork build protection UI.

注意

當您啟用分支組建來存取秘密時,Azure Pipelines 預設會限制用於分支組建的存取令牌。 其存取權比一般存取令牌還有限。 若要為分支組建提供與一般組建相同的許可權,請啟用 Make fork 組建與一般組建 設定相同的許可權。

Screenshot of fork build protection UI in Azure DevOps Server 2020 and lower.

注意

即使您啟用分支組建來存取秘密,Azure Pipelines 仍會限制用於分支組建的存取令牌。 其存取權比一般存取令牌還有限。 您無法停用此保護。

請考慮手動觸發分支組建

您可以關閉自動分叉組建 ,並改用提取要求批註作為手動建置這些貢獻的方式。 此設定可讓您在觸發組建之前檢閱程式碼。

使用 Microsoft 裝載的代理程式 fork 組建

請勿在自我裝載代理程式上執行分叉的組建。 如此一來,您就可以有效地提供外部組織的路徑,以便在公司網路內的機器上執行外部程式碼。 盡可能使用 Microsoft 裝載的代理程式。 針對自我裝載式代理程式,請使用某種形式的網路隔離,並確保代理程式不會在作業之間保存其狀態。

檢閱程式代碼變更

在分岔提取要求上執行管線之前,請仔細檢閱建議的變更,並確定您已熟悉執行該變更。

您將執行的 YAML 管線版本是提取要求中的管線版本。 因此,請特別注意 YAML 程式碼的變更,以及管線執行時所執行的程式碼,例如命令列指令碼或單元測試。

GitHub 令牌範圍限制

當您建置 GitHub 分支提取要求時,Azure Pipelines 可確保管線無法變更任何 GitHub 存放庫內容。 只有在您使用 Azure Pipelines GitHub 應用程式與 GitHub 整合時,才適用這項限制。 例如,如果您使用其他形式的 GitHub 整合,則 OAuth 應用程式不會強制執行限制。

使用者分支

您組織中具有適當許可權的使用者可以建立包含新或更新程式代碼的新分支。 該程式碼可以透過與受保護分支相同的管線執行。 此外,如果新分支中的 YAML 檔案已變更,則會使用更新的 YAML 來執行管線。 雖然這種設計提供極大的彈性和自助功能,但並非所有變更都是安全的 (無論是否有惡意)。

如果您的管線取用原始程式碼或在 Azure Repos 中定義,您必須完全瞭解 Azure Repos 許可權模型。 特別是,在存放庫層級具有 建立分支 許可權的使用者,即使該使用者缺少 參與 許可權,也會將程式代碼引入存放庫。

下一步

接下來,瞭解檢查 受保護資源所提供的更多保護。