安全最佳做法

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

处理信息和数据时，尤其是在基于云的解决方案（如 Azure DevOps Services）中，安全性应是首要任务。 虽然Microsoft确保底层云基础结构的安全性，但需负责在 Azure DevOps 中配置安全性。

虽然不是强制性的，但整合最佳做法可以显著增强你的体验并增强安全性。 以下建议旨在帮助维护安全的 Azure DevOps 环境。

保护 Azure DevOps 环境

使用以下最佳做法 删除用户、 查看审核事件以及 与 Microsoft Entra ID 集成。

删除用户

• 从 Microsoft 帐户中删除非活动用户（MSA）：如果使用 MSA，请直接从组织中删除非活动用户。 无法为分配给已删除 MSA 帐户的工作项创建查询。
• 禁用或删除Microsoft Entra 用户帐户： 如果连接到 Microsoft Entra ID，请在使 Azure DevOps 用户帐户保持活动状态的同时禁用或删除 Microsoft Entra 用户帐户。 此操作允许你使用 Azure DevOps 用户 ID 继续查询工作项历史记录。
• 撤销用户 PAT： 定期查看和撤销任何现有用户 PAT，以确保对这些关键身份验证令牌进行安全管理。
• 撤销授予单个用户的特殊权限： 审核并撤销授予单个用户的任何特殊权限，以确保与最低权限原则保持一致。
• 从已删除的用户重新分配工作： 删除用户之前，请将其工作项重新分配给当前团队成员，以有效地分发负载。

使用 Microsoft Entra ID

• 建立统一标识系统： 将 Azure DevOps 连接到 Microsoft Entra ID，以便为标识创建单平面。 此一致性可减少混淆，并最大限度地减少手动配置错误带来的安全风险。
• 实现精细治理： 使用 Microsoft Entra ID 为各种资源范围内的特定组分配不同的角色和权限。 此操作可确保受控访问并与安全最佳做法保持一致。
• 增强安全功能： 使用 Microsoft Entra ID 启用其他安全功能，例如：
  • 多重身份验证（MFA）： 需要多种因素，例如密码和电话验证，以便进行用户身份验证。 条件访问策略： 根据位置、设备或风险级别等条件定义访问规则。

有关详细信息，请参阅以下文章：

• 关于使用 Microsoft Entra ID 访问组织
• 将 Active Directory/Microsoft Entra 用户或组添加到内置安全组
• 按位置或 IP 地址限制访问
• 管理条件访问
• 要求所有用户使用多重身份验证（MFA）

查看审核事件

将组织连接到 Microsoft Entra 后，执行以下任务来增强安全性和监视使用模式：

• 启用审核： 跟踪和查看与用户操作、权限和更改相关的事件。
• 定期查看审核事件： 查找意外的使用模式，尤其是管理员和其他用户。

保护网络

以下函数是使用 Azure DevOps 时增强网络安全性的有效方法。

• 设置 IP 允许列表： 限制对特定 IP 地址的访问，以仅允许来自受信任源的流量，从而减少攻击面。
• 使用加密： 始终加密传输中的数据和静态数据。 使用 HTTPS 等协议保护信道的安全。
• 验证证书： 在建立连接时，确保证书有效并由受信任的颁发机构颁发。
• 实现 Web 应用程序防火墙（WAF）： 使用 WAF 筛选、监视和阻止基于 Web 的恶意流量，以增加针对常见攻击的保护层。

有关详细信息，请参阅 应用程序管理最佳做法。

---

范围权限

系统处理各个级别（单个、集合、项目和对象）的权限，并默认将其分配给一个或多个内置组。 若要增强安全性，请执行以下操作：

• 提供最低特权访问权限： 为用户和服务提供执行其业务功能所需的最低访问权限。
• 禁用继承： 尽可能禁用继承。 由于默认允许的性质，继承可能会无意中向意外用户授予访问权限或权限。 有关详细信息，请参阅 有关权限继承的部分

有关权限的详细信息，请参阅以下文章：

• 权限和角色查找指南
• 权限、安全组和服务帐户参考
• 设置单个权限。

项目级别的权限

• 限制对项目和存储库的访问： 通过 限制对项目和存储库的访问，降低泄露敏感信息和部署不安全代码的风险。 使用内置安全组或自定义安全组管理权限。
• 禁用 “允许公共项目”： 在组织的策略设置中，禁用创建公共项目的选项。 根据需要将项目可见性从公共切换到专用。 未登录的用户对公共项目具有只读访问权限，而登录的用户可以授予对专用项目的访问权限并进行更改。
• 限制项目创建： 防止用户创建新项目，以保持对环境的控制。

外部来宾访问

• 阻止外部来宾访问： 禁用 “允许将邀请发送到任何域”策略 ，以防止外部来宾访问（如果不需要它）。
• 使用不同的电子邮件或 UPN： 对个人和业务帐户使用不同的电子邮件地址或用户主体名称（UPN），以消除与工作相关的帐户之间的歧义。
• 组外部来宾用户： 将所有外部来宾用户放在单个Microsoft Entra 组中，并 相应地管理此组的权限。 删除直接分配，确保组规则适用于这些用户。
• 定期重新评估规则： 定期查看“用户”页的“组规则”选项卡上的规则。 请考虑Microsoft可能影响组织的 Entra ID 中的任何组成员身份更改。 Microsoft Entra ID 最多可能需要 24 小时才能更新动态组成员身份，每当组规则发生更改时，规则都会每隔 24 小时自动重新计算一次。

有关详细信息，请参阅 Microsoft Entra ID 中的 B2B 来宾。

---

管理安全组

安全和用户组

下表显示了向安全组和用户组分配权限的建议。

做	不要
在管理大量用户时，请使用 Microsoft Entra ID、Active Directory 或 Windows 安全组。	请勿更改 “项目有效用户组 ”的默认权限。 此组可以访问和查看项目信息。 有关详细信息，请参阅 “有效用户组”。
添加团队时，请考虑要为需要创建和修改区域路径、迭代路径和查询的团队成员分配哪些权限。	不要将用户添加到包含不同权限级别的多个安全组。 在某些情况下， “拒绝 ”权限级别可能会替代 “允许 ”权限级别。 例如，假设 Azure DevOps 项目中有两个安全组： 开发人员 和 测试人员。 开发人员组有权编辑设置为“允许”的工作项。 但是，请确保除几个关键个人之外，任何人都不会编辑某些敏感工作项。 为此，请创建一个名为 “敏感项编辑器 ”的新安全组，并将编辑 工作项 的权限设置为 “拒绝 ”此组。 如果用户是开发人员组和敏感项目编辑器组的成员，则“敏感项目编辑器”组中的“拒绝”权限优先于开发人员组的“允许”权限。 因此，此用户无法编辑敏感工作项，即使他们在“开发人员”组中具有“允许”权限。 此行为可确保 严格执行拒绝 权限，从而在 Azure DevOps 环境中提供更高级别的安全性和控制敏感操作。
添加多个团队时，请考虑创建 一个团队管理员 自定义组，在其中分配可供 项目管理员使用的权限子集。	不要更改对 “项目有效用户组” 进行的默认分配。 如果删除某个项目有效用户组的“查看实例级信息”或将其设置为“拒绝”，则组中的任何用户都无法访问你设置权限的任何项目、集合或部署。
考虑向需要为项目创建和共享工作项查询的用户或组授予工作项查询文件夹 “参与参与 ”权限。	不要将 “仅分配给服务帐户 ”的权限分配给用户帐户。
使组尽可能小。 应限制访问，并且应经常审核组。
利用内置角色，并且开发人员的角色默认为参与者。 管理员会被分配到项目管理员安全组以获得提升的权限，使他们能够配置安全权限。

管理员组的实时访问

如果具有 项目集合管理员 和 项目管理员 访问权限，则可以修改组织或项目的配置。 若要增强这些内置管理员组的安全性，请考虑使用 Microsoft Entra Privileged Identity Management （PIM） 组实现实时访问。 此方法允许仅在需要时授予提升的权限，从而减少与永久访问相关的风险。

配置访问权限

1. 在 Microsoft Entra ID 中创建可分配角色的组。
2. 将Microsoft Entra 组添加到 Azure DevOps 组。

注意

使用 Microsoft Entra Privileged Identity Management （PIM） 组配置实时访问时，请确保具有提升访问权限的任何用户也会保留对组织的标准访问权限。 这样，他们就可以查看所需的页面并根据需要刷新其权限。

使用访问权限

1. 激活访问权限。
2. 在 Azure DevOps 中刷新权限 。
3. 执行需要管理员访问权限的操作。

注意

用户在其 PIM 组访问停用后，在 Azure DevOps 中提升访问权限长达 1 小时。

作用域服务帐户

• 创建单一用途服务帐户： 每个服务都应具有其专用帐户，以最大程度地降低风险。 避免使用常规用户帐户作为 服务帐户。
• 遵循命名和文档约定： 对服务帐户使用清晰的描述性名称，并记录其用途和关联服务。
• 识别和禁用未使用的服务帐户： 定期查看和标识不再使用的帐户。 在考虑删除之前禁用未使用的帐户。
• 限制特权： 将服务帐户特权限制为所需的最低权限。 避免服务帐户的交互式登录权限。
• 对报表读取者使用单独的标识： 如果对服务帐户使用域帐户，请为报表读取者使用不同的标识来 隔离权限并防止不必要的访问。
• 将本地帐户用于工作组安装： 在工作组中安装组件时，对用户帐户使用本地帐户。 避免在此方案中使用域帐户。
• 利用服务连接： 尽可能使用服务连接安全地连接到服务，而无需直接将机密变量传递给生成。 限制与特定用例的连接。
• 监视服务帐户活动： 实现审核并创建 审核流 来监视服务帐户活动。

有关详细信息，请参阅 常见服务连接类型。

范围服务连接

• 范围服务连接：通过将 Azure 资源管理器服务连接的范围限定为特定资源和组来限制访问。 避免在整个 Azure 订阅中授予广泛的参与者权限。
• 使用工作负荷标识联合： 使用 OpenID Connect（OIDC）对 Azure 资源进行身份验证，而无需机密。 如果拥有 Azure 订阅的“所有者”角色，则自动或手动创建工作负荷标识联合身份验证，不会连接到 Azure Stack 或 Azure 美国政府环境，以及你使用的任何市场扩展任务。
• 范围资源组：确保资源组仅包含生成过程所需的虚拟机（VM）或资源。
• 避免经典服务连接：选择新式 Azure 资源管理器服务连接而不是经典连接，这缺少范围选项。
• 使用特定于用途的团队服务帐户： 使用特定于用途的团队服务帐户对服务连接进行身份验证，以维护安全性和控制。

有关详细信息，请参阅 常见服务连接类型。

---

选择正确的身份验证方法

从以下源中选择 身份验证方法 ：

• 考虑服务主体和托管标识
• ) 谨慎使用个人访问令牌 (PA

考虑服务主体

探索服务主体和托管标识等 替代项：

• 使用服务主体： 表示Microsoft Entra 应用程序中的安全对象。 定义应用程序可在给定租户中执行的操作。 在Azure 门户中的应用程序注册期间设置。 配置为访问 Azure 资源，包括 Azure DevOps。 适用于需要特定访问和控制的应用。
• 使用托管标识： 类似于应用程序的服务主体。 提供 Azure 资源的标识。 允许支持Microsoft Entra 身份验证的服务共享凭据。 Azure 会自动处理凭据管理和轮换。 非常适合无缝登录详细信息管理。

请谨慎使用 PAT

• 将 PAT 限定为特定角色： 仅分配特定任务所需的权限。 避免向多个组织或存储库授予全局访问权限，以最大程度地降低意外滥用的风险。
• 避免 对生成和发布写入 或 管理 权限： PAT 不应对生成、发布或其他关键资源具有写入或管理权限。 限制这些权限有助于防止可能影响管道或部署的意外操作。
• 设置过期日期并保留 PAT 机密： 始终为 PAT 设置到期日期。 根据需要定期查看和续订它们。 将 PAT 视为关键密码，使其保密，避免在应用程序代码中公开共享或硬编码。
• 避免在应用程序代码中硬编码 PAT： 不要直接在代码中嵌入 PAT，而是使用安全配置文件或环境变量来动态存储和检索 PAT。 动态。
• 定期审核和撤销未使用的 PAT： 管理员应定期使用 REST API 审查所有 PAT。 撤销不再需要或不符合建议条件的任何 PAT。

有关详细信息，请参阅 使用策略管理 PAT - 适用于管理员 和使用 PAT。

---

保护 Azure Artifacts

• 确保了解源、项目和项目集合管理员之间的差异。 有关详细信息，请参阅 配置 Azure 项目设置。
• 设置源权限。

保护 Azure Boards

• 在自定义流程之前配置和自定义 Azure Boards 。
• 设置工作跟踪和计划权限
• 了解对 Azure Boards 的默认权限和访问权限
• 设置查询权限

保护 Azure Pipelines

• 使用扩展模板。
• 设置管道权限
• 保护 Azure Pipelines 概述。

策略

• 需要外部审阅者： 确保原始请求者外部至少有一个审阅者进行彻底评审过程。 审批者共享更改的共同所有权，并追究任何潜在影响的责任。
• 要求 CI 生成通过： 要求持续集成 （CI） 生成在合并 PR 之前通过代码质量建立基线。 CI 检查包括代码 linting、单元测试和安全扫描。
• 禁止自我批准： 防止原始 PR 请求者批准自己的更改，以确保无偏见的审查过程并避免利益冲突。
• 禁止使用“等待”或“拒绝”投票完成 PR： 即使某些审阅者投票等待或拒绝，也阻止 PR 完成，鼓励在合并之前解决所有反馈。
• 重置审阅者对更改的投票： 将最近更改推送到 PR 时重置审阅者投票，以确保审阅者重新评估更新的代码。
• 锁定发布管道： 将发布管道限制为特定分支（通常是生产或主分支），以避免从其他分支意外部署。
• 在队列时强制实施可设置变量： 为管道变量启用“在队列时间强制设置”选项，以防止用户在管道执行期间重写变量值。
• 禁止编辑器中的变量替代： 对于在管道编辑器中设置的变量，禁止用户替代以保持一致性并防止意外更改。

代理

• 请谨慎授予权限： 将权限限制为最小的必要帐户集，以减少攻击面。
• 为代理配置限制性防火墙： 将防火墙设置为尽可能限制，同时仍允许代理正常运行、平衡安全性和可用性。
• 定期更新代理池： 通过定期更新代理来使代理群保持最新状态，以确保易受攻击的代码未运行，从而降低开发风险。
• 对生产项目使用单独的代理池：使用不同的代理池隔离生产项目，防止意外部署非生产分支。
• 分段敏感池： 为敏感和非敏感工作负荷创建单独的池。 仅允许与相应池关联的生成定义中的凭据。

定义

• 将 YAML 用于管道定义： 使用 YAML 定义管道（还有另一种标记语言），以便更好地跟踪和遵守审批准则和版本控制做法。
• 限制对管道定义的编辑访问： 将编辑管道定义的访问权限限制为必要的最低帐户，以减少意外或未经授权的更改的风险。

Input

• 在生成脚本中包含变量的检查： 在生成脚本中实现检查，以通过可设置的变量缓解潜在的命令注入攻击。 验证输入值并防止意外或恶意命令。
• 限制“在发布时设置的可设置”生成变量数： 最大程度地减少发布时可设置的生成变量数，以减少攻击面并简化配置管理。

任务

• 避免远程提取资源：尽可能避免在生成过程中从外部 URL 提取资源。 如果需要远程资源，请使用版本控制和哈希检查来确保完整性。
• 避免记录机密：切勿在生成日志中记录敏感信息（如机密或凭据），以防止无意中泄露和泄露安全。
• 对机密使用 Azure 密钥库：不使用直接在管道变量中存储机密，而是使用 Azure 密钥库安全地管理和检索机密。
• 限制针对任意分支或标记运行生成：对于安全关键管道，限制用户针对任何分支或标记运行生成。 定义特定的授权分支或标记，以防止意外或未经授权的执行。
• 禁用管道权限的继承：继承的权限可能过于广泛，可能无法准确反映你的需求。 禁用继承并显式设置权限，以符合安全要求。
• 限制作业授权范围：始终将作业授权范围限制为所需的最低范围。 根据每个作业执行的特定任务微调权限。

存储库和分支

• 需要最少数量的审阅者：启用策略以确保每个拉取请求至少从两个审批者那里接收评审，促进彻底的代码评审和问责。
• 配置特定于存储库的安全策略：为每个存储库或分支定制安全策略，而不是项目范围的策略，以降低风险，强制实施变更管理标准，并提高代码质量。
• 在单独的密钥保管库中隔离生产机密：将生产机密单独存储在 Azure 密钥库中，并限制对需要了解的基础的访问，以保持与非生产版本的分离。
• 将测试环境与生产环境隔离：避免将测试环境与生产环境混合，以确保凭据和机密不在非生产上下文中使用。
• 禁用分叉：禁用分叉有助于管理安全性，防止分支激增，从而更轻松地跟踪所有副本的安全性。
• 避免向分叉版本提供机密：避免与分叉生成共享机密，以将其保密，而不向分叉公开。
• 请考虑手动触发分叉生成：手动触发分叉生成，而不是允许自动触发器更好地控制安全检查。
• 使用分支版本的Microsoft托管代理：使用Microsoft托管的代理分支生成，因为它们是维护和安全的。
• 扫描 Git 存储库中的生产生成定义：定期检查存储在项目的 Git 存储库中的生产生成定义，了解任何凭据或敏感信息。
• 配置生产上下文的分支控制检查：设置分支控制检查，以将敏感连接（例如 prod-connection）的使用限制为在生产分支上下文中运行的管道，确保适当的授权并防止意外滥用。

有关详细信息，请参阅 其他安全注意事项。

保护 Azure Repos

• 使用分支策略提升代码质量
• 设置分支权限

保护 Azure Test Plans

• 为测试设置权限和访问权限
• 支持的方案和访问要求

安全 GitHub 集成

• 使用 OAuth 流而不是 PAT：为 GitHub 服务连接禁用基于 PAT 的身份验证，并选择 OAuth 流以提高安全性和集成。
• 避免管理员或所有者标识：从不使用任何存储库的管理员或所有者的标识对 GitHub 服务连接进行身份验证。 将权限限制为必要的级别。
• 避免完整范围的 GitHub PAT：避免使用完整范围的 GitHub PAT 对服务连接进行身份验证。 使用具有最低所需权限的令牌。
• 避免将个人 GitHub 帐户用作服务连接：请勿在 Azure DevOps 中使用个人 GitHub 帐户作为服务连接。 而是创建专用服务帐户或使用组织级帐户。