安全性最佳做法

  • 發行項

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

當您使用資訊和數據時，特別是在 Azure DevOps Services 之類的雲端式解決方案中，優先順序安全性應該一律是您的主要考慮。 雖然 Microsoft 維護基礎雲端基礎結構的安全性，但您必須負責在 Azure DevOps 中設定安全性。

雖然這不是強制性的，但在使用 Azure DevOps 時納入最佳做法可以增強您的體驗，並使其更安全。 我們已編譯下列最佳做法，以保護您的 Azure DevOps 環境安全：

保護 Azure DevOps 環境

移除使用者

  • 如果您的組織使用 MSA 帳戶，則直接從組織移除非使用中使用者，因為您沒有其他方法可避免存取。 當您這樣做時，無法建立指派給已移除用戶帳戶之工作項目的查詢。 如需詳細資訊，請參閱 從 Azure DevOps 刪除使用者。
  • 如果您的組織已連線到 Microsoft Entra 識別符，您可以停用或刪除 Microsoft Entra 使用者帳戶，並讓 Azure DevOps 使用者帳戶保持作用中。 如此一來，您就可以使用 Azure DevOps 使用者識別碼繼續查詢工作專案歷程記錄。
  • 撤銷使用者 PAT。
  • 撤銷可能已授與給個別用戶帳戶的任何特殊許可權。
  • 將您移除的使用者重新指派給目前小組成員的工作。

使用 Microsoft Entra ID

整合 Azure DevOps 與 Microsoft Entra ID，以具有單一平面進行身分識別。 一致性和單一授權來源可提高清晰度，並降低人為錯誤和設定複雜性的安全性風險。 端控管的關鍵是有多個角色指派（具有不同角色定義和相同 Microsoft Entra 群組的不同資源範圍）。 如果沒有 Microsoft Entra 識別符，您就完全負責控制組織存取權。

使用 Microsoft Entra ID 也可讓您存取其他安全性功能，例如多重要素驗證或其他條件式存取原則。

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

檢閱稽核事件

擁有 Microsoft Entra 支援的組織之後，您就可以在安全策略中開啟稽核。 定期 檢閱稽核事件 ，以監視和響應系統管理員和其他使用者的非預期使用模式。

保護網路安全

執行此動作的一些方式可能包括：

  • 設定 允許清單 以限制特定IP。
  • 一律使用加密。
  • 驗證憑證。
  • 實作 Web 應用程式防火牆 （WAF），以便篩選、監視和封鎖任何來自 Azure DevOps 的惡意 Web 型流量。
  • 如需詳細資訊，請參閱有關應用程式管理最佳做法的本指南

範圍許可權

系統會管理不同層級的許可權 --個別、集合、項目和物件，並預設將它們指派給一或多個內建群組。

專案層級權限

  • 限制對專案和存放庫的存取，以減少洩漏敏感性資訊並將不安全的程式代碼部署到生產環境的風險。
  • 使用內建安全組或自定義安全組來管理許可權。 如需詳細資訊，請參閱 授與或限制選取工作的許可權。
  • 停用 貴組織原則設定中的「允許公用專案」 ，以防止每個組織使用者建立公用專案。 Azure DevOps Services 可讓您將項目的可見度從公用變更為私人，反之亦然。 如果使用者尚未登入您的組織，他們具有公用專案的唯讀存取權。 如果使用者已登入，可以授與私人專案的存取權，並對其進行任何允許的變更。
  • 不允許使用者建立新的專案。

外部來賓存取

  • 藉由停用 [允許傳送邀請到任何網域] 原則，完全封鎖外部來賓存取。 如果沒有商務需求，最好這樣做。
  • 針對個人和商務帳戶使用不同的電子郵件或用戶主體名稱 （UPN），即使允許的話也一樣。 當電子郵件/UPN 相同時，此動作可消除企業和個人帳戶之間的混淆挑戰。
  • 將所有外部來賓使用者放在單一 Microsoft Entra 群組中，並適當地管理該群組的許可權。 您可以輕鬆地以這種方式管理和稽核。
    • 拿掉直接指派，讓群組規則套用至這些使用者。 如需詳細資訊，請參閱 新增群組規則以指派存取層級。
    • 在 [使用者] 頁面的 [群組規則] 索引標籤上定期重新評估規則。 釐清 Microsoft Entra ID 中是否有任何群組成員資格變更可能會影響您的組織。 Microsoft Entra 識別碼最多可能需要 24 小時才能更新動態群組成員資格。 每 24 小時且每當群組規則變更時，規則就會在系統中自動重新評估。
  • 如需詳細資訊，請參閱 Microsoft Entra ID 中的 B2B 來賓。

管理安全組

安全性和使用者群組

請參閱下列建議，以將許可權指派給安全組和使用者群組。

Do 不要
當您管理大量使用者時，請使用 Microsoft Entra ID、Active Directory 或 Windows 安全組。 請勿變更專案有效使用者群組的默認許可權。 此群組可以存取和檢視項目資訊。
當您新增小組時，請考慮您想要指派給需要建立和修改區域路徑、反覆專案路徑和查詢的小組成員的許可權。 請勿將使用者新增至包含不同權限等級的多個安全性群組。 在某些情況下，[拒絕] 權限等級可能會覆寫 [允許] 權限等級。
當您新增許多小組時，請考慮建立Team管理員istrators 自定義群組，在其中配置 Project 管理員 istrators 可用的許可權子集。 請勿變更對 專案有效使用者 群組所做的預設指派。 如果您移除或設定 [檢視其中一個專案有效使用者] 群組的 [拒絕] 實例層級資訊，群組中沒有任何使用者可以存取您設定許可權的任何專案、集合或部署。
請考慮將工作專案查詢資料夾 [參與 ] 許可權授與需要為專案建立和共用工作專案查詢的使用者或群組。 請勿將 [僅指派給服務帳戶] 的許可權指派給用戶帳戶。
盡可能縮小群組。 存取應該受到限制，而且應該經常稽核群組。
利用內建角色，並預設為開發人員的參與者。 管理員 會指派給 Project 管理員 istrator 安全組以取得更高許可權，讓他們能夠設定安全性許可權。

如需詳細資訊，請參閱 有效的使用者群組。

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

如果您有 Project Collection 管理員 istrator 和 Project 管理員 istrator 存取權，您可以變更組織或項目的組態。 若要保護對這些內建系統管理員群組的存取，需要使用 Microsoft Entra Privileged Identity Management （PIM） 群組進行 Just-In-Time 存取。

設定存取權

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

注意

請確定任何使用 PIM 群組提高存取權的使用者也具有組織的標準存取權，以便檢視頁面以重新整理其許可權。

使用存取

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

注意

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

範圍服務帳戶

  • 請確定 服務帳戶 具有零的互動式登入許可權。
  • 將服務帳戶許可權限限為最基本的必要許可權。
  • 如果您使用服務帳戶的網域帳戶，請針對報表讀取者帳戶使用不同的身分識別。 如需詳細資訊，請參閱 服務帳戶和相依性。
  • 如果您要在工作組中安裝元件，請使用使用者帳戶的本機帳戶。 如需詳細資訊，請參閱 服務帳戶需求。
  • 盡可能使用 服務連線 。 服務連線提供安全的機制，以連線到各種服務，而不需要直接將秘密變數傳入組建。 - 將這些連線限制為應該使用的特定位置，而不要再使用這些連線。
  • 監視服務帳戶活動並建立 稽核串流。 稽核可讓您偵測並回應可疑的登入和活動。
  • 如需詳細資訊，請參閱 一般服務連線類型。

範圍服務連線

  • 將 Azure Resource Manager 和其他服務連線範圍限定在需要存取的資源和群組。 服務連線不應在整個 Azure 訂用帳戶上擁有廣泛的參與者許可權。
  • 針對 Azure Resource Manager （ARM） 服務連線使用工作負載身分識別同盟。 工作負載身分識別同盟可讓您在 Azure Pipelines 中建立無秘密的服務連線至 Azure。
  • 請勿在 Azure 訂用帳戶上為使用者提供一般或廣泛的參與者許可權。
  • 請勿使用 Azure 傳統服務連線，因為無法設定許可權的範圍。
  • 請確定資源群組只包含建置需要存取 虛擬機器 （VM） 或資源。
  • 使用特定用途的小組服務帳戶來驗證服務連線。
  • 如需詳細資訊，請參閱 一般服務連線類型。

選擇正確的驗證方法

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

考慮服務主體

探索服務主體和受控識別等替代方案，讓您能夠使用 Microsoft Entra 令牌來存取 Azure DevOps 資源。 相較於 PAT 外泄，這類令牌的風險較低，且包含簡單認證管理等優點。

謹慎使用 PAT

如果可能的話，建議您一律使用身分識別服務進行驗證，而不是使用密碼編譯密鑰，因為使用應用程式程式代碼安全地管理密鑰是一項挑戰，而且可能會導致不小心將敏感性存取密鑰發佈至 GitHub 等公用程式代碼存放庫的錯誤。 不過，如果您必須使用個人存取令牌 （PAT），請考慮下列指導方針：

  • PAT 應一律設定為特定角色的範圍。

  • PAT 不應該為多個組織提供全域存取權。

  • PAT 不應該授與組建或發行的寫入或管理許可權。

  • PAT 應該有到期日，並保密，因為它們和密碼一樣重要。

  • 即使想要這麼做以簡化程式碼，PAT 也不應該在應用程式程式代碼中硬式編碼。

  • 管理員 istrators 應該定期使用 稽核所有 PATREST API 並撤銷任何不符合上述準則的 API。

  • 讓您的 PAT 保持秘密。 您的令牌與密碼一樣重要。

  • 將您的令牌儲存在安全的地方。

  • 不要在應用程式中硬式編碼令牌。 簡化程式代碼來取得令牌很長一段時間，並將其儲存在應用程式中，但不要這麼做，可能很誘人。

  • 提供令牌到期日。

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

保護 Azure Artifacts

保護 Azure Boards

保護 Azure Pipelines

原則

  • 在原始要求者之外至少需要一個檢閱者。 核准者會共同擁有這些變更，並應同樣負責任何潛在影響。
  • 要求 CI 組建通過。 這項需求適用於建立基準程式代碼品質，透過程式碼Linting、單元測試和安全性檢查，例如病毒和認證掃描。
  • 請確定原始提取要求者無法核准變更。
  • 即使某些檢閱者投票等候或拒絕，也不允許完成PR （提取要求）。
  • 在推送最近的變更時重設程式代碼檢閱者投票。
  • 只在特定生產分支上執行發行管線，以鎖定發行管線。
  • 在組織的管線設定中啟用「在佇列時間強制設定變數」。
  • 不允許在編輯器中設定的變數「讓使用者在執行這個管線時覆寫此值」。

客服專員

  • 將許可權授與最小的帳戶數目。
  • 具有最嚴格的防火牆，讓您的代理程式可供使用。
  • 定期更新集區，以確保組建機隊不會執行惡意執行者可惡意探索的易受攻擊程序代碼。
  • 針對已出貨或部署到生產環境的組建成品，請使用個別的代理程式集區。
  • 區段不區分集區的「敏感性」集區，只允許在該集區鎖定的組建定義中使用認證。

定義

  • 使用 YAML 管理管線定義（又一種標記語言）。 YAML 是管理管線定義的慣用方法，因為它提供變更的可追蹤性，並可遵循核准指導方針。
  • 保護管線定義 編輯 帳戶數目下限的存取權。

輸入

  • 在組建腳本中包含變數的理智檢查。 理智檢查可透過可設定的變數減輕命令插入式攻擊。
  • 將盡可能少的組建變數設定為 「在發行時間設定數據表」。

工作

  • 請避免從遠端擷取的資源，但如有必要，請使用版本設定和哈希檢查。
  • 請勿記錄秘密。
  • 請勿將秘密儲存在管線變數中，請使用 Azure 金鑰保存庫。 定期掃描組建管線，以確保秘密不會儲存在組建管線變數中。
  • 請勿讓使用者對安全性關鍵管線上的任意分支或標籤執行組建。
  • 停用管線上的繼承，因為繼承的許可權很廣泛，而且無法準確地反映您對許可權的需求。
  • 在所有情況下限制作業授權範圍。

存放庫和分支

  • 將 [需要最少的檢閱者數目] 原則設定為 [開啟]，讓每個提取要求至少由兩個核准者檢閱。
  • 設定每個存放庫或分支特有的安全策略，而不是整個專案。 安全策略可降低風險、強制執行變更管理標準，以及改善小組的程式代碼品質。
  • 將生產秘密儲存在個別 金鑰保存庫，並確保只有需要知道的存取權才能將非生產組建分開。
  • 請勿混合測試環境與生產環境，包括使用認證。
  • 停用分叉。 越是分叉，就越難追蹤每個叉子的安全性。 此外，用戶可以輕鬆地將存放庫的複本分叉至自己的私人帳戶。
  • 請勿提供分支組建的秘密。
  • 請考慮手動觸發分叉組建。
  • 使用 Microsoft 裝載的代理程式 fork 組建。
  • 針對 Git，請檢查專案 Git 存放庫中的生產組建定義，以便掃描認證。
  • 設定分支控制項檢查，讓只有在分支內容 production 中執行的管線可以使用 prod-connection。
  • 如需詳細資訊，請參閱 其他安全性考慮。

保護 Azure Repos

保護 Azure 測試計劃

保護 GitHub 整合

  • 停用以個人存取令牌 （PAT） 為基礎的驗證，因此 OAuth 流程會與 GitHub 服務連線搭配使用。
  • 永遠不要將 GitHub 服務連線驗證為身分識別，該身分識別是任何存放庫的系統管理員或擁有者。
  • 請勿使用完整的 GitHub PAT（個人存取令牌）來驗證 GitHub 服務連線。
  • 請勿使用個人 GitHub 帳戶作為 Azure DevOps 的服務連線。