共用方式為

安全性最佳做法

  • 發行項

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

當您處理資訊和數據時，特別是在 Azure DevOps Services 之類的雲端式解決方案中，安全性應該是您的首要任務。 雖然Microsoft可確保基礎雲端基礎結構的安全性，但設定 Azure DevOps 內的安全性是您的責任。

雖然不是強制性的，但納入最佳做法可以大幅增強您的體驗並增強安全性。 下列建議旨在協助您維護安全的 Azure DevOps 環境。

保護您的 Azure DevOps 環境

採用下列最佳做法來 移除使用者、 檢閱稽核事件，以及 與 Microsoft Entra 識別符整合。

移除使用者

  • 從Microsoft帳戶移除非使用中使用者（MSA）：如果使用 MSA，請直接從您的組織移除非使用中的使用者。 您無法為指派給已移除 MSA 帳戶的工作專案建立查詢。
  • 停用或刪除Microsoft Entra 用戶帳戶： 如果聯機到 Microsoft Entra 標識符，請在讓 Azure DevOps 使用者帳戶保持作用中時停用或刪除 Microsoft Entra 使用者帳戶。 此動作可讓您使用 Azure DevOps 使用者識別碼繼續查詢工作專案歷程記錄。
  • 撤銷使用者 PAT： 定期檢閱和撤銷任何現有的使用者 PAT，以確保這些重要驗證令牌的安全管理。
  • 撤銷授與個別使用者的特殊許可權： 稽核並撤銷授與個別使用者的任何特殊許可權，以確保與最低許可權原則一致。
  • 從移除的使用者重新指派工作： 移除使用者之前，請先將其工作專案重新指派給目前的小組成員，以有效地分散負載。

使用 Microsoft Entra ID

  • 建立統一身分識別系統： 將 Azure DevOps 連線至 Microsoft Entra ID，以建立身分識別的單一平面。 此一致性可減少混淆，並將手動設定錯誤的安全性風險降到最低。
  • 實作更細緻的治理： 使用Microsoft Entra ID 將不同的角色和許可權指派給各種資源範圍的特定群組。 此動作可確保受控存取，並符合安全性最佳做法。
  • 增強安全性功能： 使用Microsoft Entra 識別碼啟用其他安全性功能，例如：
    • 多重要素驗證 （MFA）： 需要多種因素，例如使用者驗證的密碼和電話驗證。 條件式存取原則： 根據位置、裝置或風險層級等條件定義存取規則。

如需詳細資訊，請參閱下列文章：

檢閱稽核事件

如果您的組織連線到 Microsoft Entra，請執行下列工作來增強安全性和監視使用模式：

  • 啟用稽核： 追蹤和檢視與用戶動作、許可權和變更相關的事件。
  • 定期檢閱稽核事件： 尋找非預期的使用模式，特別是系統管理員和其他使用者。

保護網路安全

當您使用 Azure DevOps 時，下列函式是增強網路安全性的有效方式。

  • 設定IP允許清單： 限制對特定IP位址的存取，只允許來自受信任來源的流量，以減少受攻擊面。
  • 使用加密： 一律加密傳輸中的數據和待用數據。 使用 HTTPS 等通訊協定保護通道的安全。
  • 驗證憑證： 確定憑證有效，並在建立聯機時由信任授權單位發行。
  • 實作 Web 應用程式防火牆 （WAFs）： 使用 WAF 篩選、監視和封鎖惡意的 Web 型流量，以防範常見攻擊的額外保護層。

如需詳細資訊，請參閱 應用程式管理最佳做法。

範圍許可權

系統會處理各種層級的許可權，也就是個別、集合、項目和物件，並預設將它們指派給一或多個內建群組。 若要增強安全性，請執行下列動作：

  • 提供最低許可權存取： 為使用者和服務提供執行其商務功能所需的最低存取權。
  • 停用繼承： 盡可能停用繼承。 繼承可能會因為默認允許的性質，不小心將存取權或許可權授與非預期的使用者。 如需詳細資訊，請參閱許可權繼承一 節

如需許可權的詳細資訊，請參閱下列文章：

專案層級權限

  • 限制專案和存放庫的存取： 藉由 限制專案和存放庫的存取，降低洩漏敏感性資訊並部署不安全程式碼的風險。 使用內建或自定義安全組管理許可權。
  • 停用 [允許公用專案]： 在貴組織的原則設定中，停用建立公用項目的選項。 視需要將項目可見性從公用切換為私人。 尚未登入的使用者具有公用專案的唯讀存取權，而登入的使用者可以授與私人專案的存取權，並進行允許的變更。
  • 限制專案建立： 防止使用者建立新專案，以維持對環境的控制。

外部來賓存取

  • 封鎖外部來賓存取： 停用「 允許將邀請傳送至任何網域」原則 ，以防止外部來賓存取，如果沒有商務需求。
  • 使用不同的電子郵件或 UPN： 針對個人和商務帳戶使用不同的電子郵件地址或使用者主體名稱（UPN），以消除個人與工作相關帳戶之間的模棱兩可。
  • 群組外部來賓使用者： 將所有外部來賓使用者放在單一Microsoft Entra 群組中，並 適當地管理此群組的許可權。 拿掉直接指派，以確保群組規則適用於這些使用者。
  • 定期重新評估規則： 定期檢閱 [使用者] 頁面的 [群組規則] 索引標籤上的規則。 請考慮Microsoft可能會影響您組織的 Entra 標識碼中的任何群組成員資格變更。 Microsoft Entra 識別符最多可能需要 24 小時才能更新動態群組成員資格，而且每當群組規則變更時，都會自動重新評估規則。

如需詳細資訊，請參閱 Microsoft Entra ID 中的 B2B 來賓。

管理安全組

安全性和使用者群組

下表顯示將許可權指派給安全組和使用者群組的建議。

做 不要
當您管理大量使用者時，請使用Microsoft Entra ID、Active Directory 或 Windows 安全組。 請勿變更專案有效使用者群組的默認許可權。 此群組可以存取和檢視項目資訊。 如需詳細資訊，請參閱 有效的使用者群組。
當您新增小組時，請考慮您想要指派給需要建立和修改區域路徑、反覆專案路徑和查詢的小組成員的許可權。 請勿將使用者新增至包含不同權限等級的多個安全性群組。 在某些情況下， [拒絕 ] 許可權等級可能會覆寫 [允許 ] 許可權等級。 例如，假設您在 Azure DevOps 專案中有兩個安全組： 開發人員 和 測試人員。 開發人員群組有權編輯設定為 [允許] 的工作專案。 但是，請確定除了少數重要人員之外，任何人都不會編輯某些敏感性工作專案。 若要這樣做，請建立名為 [敏感性專案編輯器] 的新安全組，並將編輯工作專案的許可權設定為 [拒絕] 此群組。 如果使用者是 [開發人員] 群組和 [敏感性專案編輯器] 群組的成員，[敏感性專案編輯器] 群組的 [拒絕] 許可權優先於 [開發人員] 群組的 [允許] 許可權。 因此，即使此使用者具有開發人員群組中的 [允許] 許可權，也無法編輯敏感性工作專案。 此行為可確保 嚴格強制執行拒絕 許可權，以提供較高層級的安全性和控制 Azure DevOps 環境內的敏感性動作。
當您新增許多小組時，請考慮建立 Team Administrators 自定義群組，在其中配置專案管理員可用的許可權子集。 請勿變更對 專案有效使用者 群組所做的預設指派。 如果您移除或設定 [檢視其中一個專案有效使用者] 群組的 [拒絕] 實例層級資訊，群組中沒有任何使用者可以存取您設定許可權的任何專案、集合或部署。
請考慮將工作專案查詢資料夾 [參與 ] 許可權授與需要為專案建立和共用工作專案查詢的使用者或群組。 請勿將 [僅指派給服務帳戶] 的許可權指派給用戶帳戶。
盡可能縮小群組。 存取應該受到限制，而且應該經常稽核群組。
利用內建角色，並預設為開發人員的參與者。 系統管理員會獲指派給 Project Administrator 安全組以取得提升的許可權，讓他們能夠設定安全性許可權。

系統管理群組的 Just-In-Time 存取

如果您有 [專案集合管理員 ] 和 [專案管理員 ] 存取權，您可以修改組織或項目的組態。 若要增強這些內建系統管理員群組的安全性，請考慮使用 Microsoft Entra Privileged Identity Management （PIM） 群組實作 Just-In-Time 存取。 這種方法可讓您只在需要時授與提高的許可權，降低與永久存取相關聯的風險。

設定存取權

  1. 在 Microsoft Entra ID 中建立可指派角色的群組。
  2. 將Microsoft Entra 群組新增至 Azure DevOps 群組。

注意

當您使用 Microsoft Entra Privileged Identity Management （PIM） 群組設定 Just-In-Time 存取時，請確定任何具有提高許可權的使用者也會保留對組織的標準存取權。 如此一來，他們可以檢視必要的頁面，並視需要重新整理其許可權。

使用存取

  1. 啟用您的存取權。
  2. 在 Azure DevOps 中重新整理您的許可權 。
  3. 採取需要系統管理員存取權的動作。

注意

在停用 PIM 群組存取之後，使用者已將 Azure DevOps 中的存取權提高到 1 小時。

範圍服務帳戶

  • 建立單一用途服務帳戶： 每個服務都應該有其專用帳戶，以將風險降到最低。 避免使用一般用戶帳戶作為 服務帳戶。
  • 遵循命名和檔慣例： 針對服務帳戶使用清楚的描述性名稱，並記錄其用途和相關聯的服務。
  • 識別和停用未使用的服務帳戶： 定期檢閱並識別不再使用的帳戶。 考慮刪除之前，請先停用未使用的帳戶。
  • 限制許可權： 將服務帳戶許可權限制為所需的最低許可權。 避免服務帳戶的互動式登入許可權。
  • 針對報表讀取者使用不同的身分識別： 如果使用服務帳戶的網域帳戶，請針對報表讀取者使用不同的身分識別來 隔離許可權，並防止不必要的存取。
  • 使用本機帳戶進行工作組安裝： 在工作組中安裝元件時，請使用本機帳戶作為用戶帳戶。 在此案例中避免網域帳戶。
  • 利用服務連線： 盡可能使用服務連線，安全地聯機到服務，而不需將秘密變數直接傳遞至組建。 限制特定使用案例的連線。
  • 監視服務帳戶活動： 實作稽核並建立 稽核串流 來監視服務帳戶活動。

如需詳細資訊，請參閱 一般服務連線類型。

範圍服務連線

  • 範圍服務連線： 限制 Azure Resource Manager 服務連線到特定資源和群組的存取範圍。 避免在整個 Azure 訂用帳戶中授與廣泛的參與者許可權。
  • 使用工作負載身分識別同盟： 使用沒有秘密的 OpenID Connect （OIDC） 向 Azure 資源進行驗證。 如果您有 Azure 訂用帳戶的擁有者角色、未連線到 Azure Stack 或 Azure 美國政府環境，以及您使用的任何 Marketplace 擴充功能工作，則自動或手動建立工作負載身分識別同盟。
  • 範圍資源群組：確定資源群組只包含建置程式所需的 虛擬機器 （VM） 或資源。
  • 避免傳統服務連線： 選擇新式 Azure Resource Manager 服務連線，而不是缺少範圍選項的傳統連線。
  • 使用特定用途的小組服務帳戶： 使用特定用途的小組服務帳戶來驗證服務連線，以維護安全性和控制。

如需詳細資訊，請參閱 一般服務連線類型。

選擇正確的驗證方法

從下列來源選取您的 驗證方法 ：

考慮服務主體

探索服務主體和受控識別等 替代方案：

  • 使用服務主體： 代表Microsoft Entra 應用程式內的安全性物件。 定義應用程式可在指定租用戶中執行的動作。 在應用程式註冊期間設定 Azure 入口網站。 設定 以存取 Azure 資源，包括 Azure DevOps。 適用於需要特定存取和控制的應用程式。
  • 使用受控識別： 類似於應用程式的服務主體。 提供 Azure 資源的身分識別。 允許支援Microsoft Entra 驗證的服務共享認證。 Azure 會自動處理認證管理和輪替。 適合用於順暢的登入詳細數據管理。

謹慎使用 PAT

  • 將 PAT 範圍設定為特定角色： 僅將 PAT 指派給特定工作的必要許可權。 避免將全域存取權授與多個組織或存放庫，以將意外誤用的風險降到最低。
  • 避免 在組建和發行上寫入 或 管理 許可權： PAT 不應該有組建、發行或其他重要資源的寫入或管理許可權。 限制這些許可權有助於防止可能影響管線或部署的意外動作。
  • 設定到期日並保留 PAT 秘密： 一律設定 PAT 的到期日。 請視需要定期檢閱並更新它們。 將 PAT 視為重要的密碼，使其保持機密，並避免在應用程式程式代碼中公開共用或硬式編碼。
  • 避免在應用程式程式代碼中硬式編碼 PAT： 不要直接在程式代碼中內嵌 PAT，而是使用安全的組態檔或環境變數，以動態方式儲存和擷取 PAT。 動態。
  • 定期稽核和撤銷未使用的 PAT： 系統管理員應該使用 REST API 定期檢閱所有 PAT。 撤銷不再需要或不符合建議準則的任何 PAT。

如需詳細資訊，請參閱 使用原則管理 PAT - 適用於系統管理員 和使用 PAT。

保護 Azure Artifacts

保護 Azure Boards

保護 Azure Pipelines

原則

  • 需要外部檢閱者： 請確定在原始要求者之外至少有一個檢閱者可以進行徹底的檢閱程式。 核准者會共同擁有任何潛在影響的變更和責任。
  • 要求 CI 組建通過： 藉由要求持續整合 （CI） 組建在合併 PR 之前通過，以建立程式代碼品質的基準。 CI 檢查包括程式代碼 Linting、單元測試和安全性掃描。
  • 不允許自我核准： 防止原始PR要求者核准自己的變更，以確保不偏不倚的檢閱程式，並避免利益衝突。
  • 不允許PR完成並出現「等候」或「拒絕」投票： 即使某些檢閱者投票等候或拒絕，也禁止PR完成，鼓勵在合併之前處理所有意見反應。
  • 重設檢閱者對變更的投票： 將最近的變更推送至PR時重設檢閱者投票，以確保檢閱者重新評估更新的程序代碼。
  • 鎖定發行管線： 將發行管線限制為特定分支（通常是生產或主要），以避免從其他分支意外部署。
  • 在佇列時間強制執行可設定變數： 啟用管線變數的 [在佇列時間強制執行 settable] 選項，以防止使用者在管線執行期間覆寫變數值。
  • 不允許編輯器中的變數覆寫： 對於在管線編輯器中設定的變數，不允許使用者覆寫以維護一致性，並防止非預期的變更。

客服專員

  • 謹慎授與許可權： 將許可權限制為最小必要帳戶集，以減少受攻擊面。
  • 設定代理程式的限制性防火牆： 將防火牆設定為盡可能限制，同時仍允許代理程序運作、平衡安全性和可用性。
  • 定期更新代理程式集區： 定期更新代理程式，讓您的代理程式車隊保持最新狀態，以確保易受攻擊的程式代碼未執行，降低惡意探索的風險。
  • 將個別的代理程式集區用於生產成品： 使用不同的代理程式集區隔離生產成品，防止意外部署非生產分支。
  • 區段敏感性集區： 為敏感性和非區分工作負載建立個別的集區。 只允許與適當集區相關聯的組建定義中的認證。

定義

  • 使用 YAML 進行管線定義： 使用 YAML 定義管線（然而另一種標記語言），以取得更佳的可追蹤性和遵循核准指導方針和版本控制做法。
  • 限制對管線定義的編輯存取： 將編輯管線定義的存取限制為最低必要帳戶，以減少意外或未經授權的變更風險。

輸入

  • 在組建腳本中包含變數的檢查： 在您的組建腳本內實作檢查，以降低透過可設定變數的潛在命令插入式攻擊。 驗證輸入值，並防止非預期的或惡意命令。
  • 限制「在發行時間設定」組建變數： 將發行時間可設定的組建變數數目降至最低，以減少受攻擊面並簡化組態管理。

工作

  • 避免從遠端擷取的資源：盡可能避免在建置程式期間從外部 URL 擷取資源。 如果需要遠端資源，請使用版本設定和哈希檢查來確保完整性。
  • 避免記錄秘密：請勿在組建記錄檔中記錄機密資訊，例如秘密或認證，以避免意外暴露和安全性危害。
  • 針對秘密使用 Azure 金鑰保存庫：不要直接將秘密儲存在管線變數中，而是使用 Azure 金鑰保存庫 安全地管理和擷取秘密。
  • 針對任意分支或標籤限制執行組建：針對安全性關鍵管線，限制使用者針對任何分支或標記執行組建。 定義特定的授權分支或標籤，以防止意外或未經授權的執行。
  • 停用管線許可權的繼承：繼承的許可權可能過於廣泛，且可能無法正確反映您的需求。 停用繼承並明確設定許可權，以符合您的安全性需求。
  • 限制作業授權範圍：一律將作業授權範圍限制為所需的最低需求。 根據每個作業所執行的特定工作微調許可權。

存放庫和分支

  • 需要最少的檢閱者數目：啟用原則以確保每個提取要求至少會收到兩個核准者的檢閱，以促進完整的程式碼檢閱和責任。
  • 設定存放庫特定的安全策略：針對每個存放庫或分支量身打造安全策略，而不是全項目原則，以降低風險、強制執行變更管理標準，以及增強程式代碼品質。
  • 隔離個別密鑰保存庫中的生產秘密：將生產秘密分別儲存在 Azure 金鑰保存庫，並限制存取需要知道的基礎，以維持與非生產組建的分離。
  • 將測試環境與生產環境隔離：避免將測試環境與生產環境混合，以確保認證和秘密不會用於非生產環境中。
  • 停用分叉：停用分叉有助於管理安全性，方法是防止分叉擴散，讓您更輕鬆地追蹤所有複本的安全性。
  • 避免將秘密提供給分叉組建：避免與分叉組建共用秘密，使其保密，而不會公開給分叉。
  • 請考慮手動觸發分支組建：手動觸發分支組建，而不是允許自動觸發程式更妥善地控制安全性檢查。
  • 使用Microsoft裝載的代理程式分支組建：使用Microsoft裝載的代理程式分支組建，因為它們是維護且安全的。
  • 掃描 Git 存放庫中的生產組建定義：定期檢查儲存在專案 Git 存放庫中的生產組建定義是否有任何認證或敏感性資訊。
  • 設定生產內容的分支控制檢查：設定分支控制檢查，以限制在生產分支內容中執行的管線使用敏感性連線（例如 prod-connection），確保適當的授權並防止意外誤用。

如需詳細資訊，請參閱 其他安全性考慮。

保護 Azure Repos

保護 Azure 測試計劃

保護 GitHub 整合

  • 使用 OAuth 流程而非 PAT：停用 GitHub 服務連線的 PAT 型驗證，並選擇 OAuth 流程以取得更佳的安全性和整合。
  • 避免系統管理員或擁有者身分識別：永遠不要使用身分識別來驗證 GitHub 服務連線，該身分識別是任何存放庫的系統管理員或擁有者。 將許可權限制為必要的層級。
  • 避免完整範圍的 GitHub PAT：避免使用完整範圍的 GitHub PAT 來驗證服務連線。 使用具有最低必要許可權的令牌。
  • 避免個人 GitHub 帳戶作為服務連線：請勿在 Azure DevOps 中使用個人 GitHub 帳戶作為服務連線。 請改為建立專用的服務帳戶或使用組織層級帳戶。