安全最佳做法

  • 项目

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 ID，则可以禁用或删除 Microsoft Entra 用户帐户，并使 Azure DevOps 用户帐户保持活动状态。 通过这种方式，可以使用 Azure DevOps 用户 ID 继续查询工作项历史记录。
  • 撤销用户 PAC。
  • 撤销可能已授予单个用户帐户的任何特殊权限。
  • 将删除的用户的工作重新分配给当前团队成员。

使用 Microsoft Entra ID

将 Azure DevOps 与 Microsoft Entra ID 集成，以便具有一个标识平面。 一致性和单个权威源可提高清晰度，并降低人为错误和配置复杂性的安全风险。 最终治理的关键是具有多个角色分配（具有不同的角色定义和相同的 Microsoft Entra 组的不同资源范围）。 如果没有 Microsoft Entra ID，你只负责控制组织访问权限。

使用 Microsoft Entra ID 还可以访问其他安全功能，例如多重身份验证或其他条件访问策略。

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

查看审核事件

拥有 Microsoft Entra 支持的组织后，可以在安全策略中启用审核。 定期 查看审核事件 ，以监视管理员和其他用户的意外使用模式并做出反应。

保护网络

执行此操作的几种方法可能包括：

  • 设置 允许列表 以限制特定 IP。
  • 始终使用加密。
  • 验证证书。
  • (WAF) 实现 Web 应用程序防火墙，以便它们可以筛选、监视和阻止传入和传出 Azure DevOps 的任何基于 Web 的恶意流量。
  • 有关详细信息，请参阅此应用程序管理最佳做法指南

限定范围的权限

系统管理不同级别（个人、集合、项目和对象）的权限，并默认将它们分配给一个或多个内置组。

项目级别的权限

  • 限制对项目和存储库的访问，以降低泄露敏感信息和将不安全的代码部署到生产环境的风险。
  • 使用内置安全组或自定义安全组来管理权限。 有关详细信息，请参阅 “授予或限制权限”以选择任务。
  • 在组织的策略设置中禁用 “允许公共项目” ，以防止每个组织用户创建公共项目。 Azure DevOps Services允许将项目的可见性从公共更改为专用，反之亦然。 如果用户尚未登录到你的组织，则他们对你的公共项目具有只读访问权限。 如果用户已登录，则可以向其授予对专用项目的访问权限，并对其进行任何允许的更改。
  • 不允许用户创建新项目。

外部来宾访问

  • 通过禁用 “允许将邀请发送到任何域”策略，完全阻止外部来宾访问。 如果没有业务需要，最好这样做。
  • 为个人和企业帐户使用不同的电子邮件或用户主体名称 (UPN) ，即使允许也是如此。 此操作消除了在电子邮件/UPN 相同时消除企业帐户和个人帐户之间的歧义的挑战。
  • 将所有外部来宾用户放在单个 Microsoft Entra 组中，并相应地管理该组的权限。 可以通过这种方式轻松管理和审核。
    • 删除直接分配，以便组规则应用于这些用户。 有关详细信息，请参阅 添加组规则以分配访问级别。
    • 在“用户”页的“组规则”选项卡上定期重新评估规则。 阐明 Microsoft Entra ID 中的任何组成员身份更改是否可能会影响你的组织。 Microsoft Entra ID 最多可能需要 24 小时才能更新动态组成员身份。 每 24 小时，每当组规则更改时，系统都会自动重新计算规则。
  • 有关详细信息，请参阅 Microsoft Entra ID 中的 B2B 来宾。

管理安全组

安全和用户组

请参阅以下有关向安全组和用户组分配权限的建议。

Do 不要
管理大量用户时，请使用 Microsoft Entra ID、Active Directory 或 Windows 安全组。 请勿更改 “项目有效用户组 ”的默认权限。 此组可以访问和查看项目信息。
添加团队时，请考虑要为需要创建和修改区域路径、迭代路径和查询的团队成员分配哪些权限。 不要将用户添加到包含不同权限级别的多个安全组。 在某些情况下， “拒绝” 权限级别可能会覆盖 “允许” 权限级别。
添加多个团队时，请考虑创建 一个团队管理员 自定义组，在其中分配可供 项目管理员使用的权限子集。 不要更改对 “项目有效用户组” 进行的默认分配。 如果删除某个项目有效用户组的“查看实例级信息”或将其设置为“拒绝”，则组中的任何用户都无法访问你设置权限的任何项目、集合或部署。
考虑向需要为项目创建和共享工作项查询的用户或组授予工作项查询文件夹 “参与参与 ”权限。 不要将标记为 “仅分配给服务帐户”的权限分配给 用户帐户。
使组尽可能小。 应限制访问，并且应经常审核组。
利用内置角色，并且开发人员的角色默认为参与者。 管理员会被分配到项目管理员安全组以获得提升的权限，使他们能够配置安全权限。

有关详细信息，请参阅 “有效用户组”。

管理员组的实时访问

如果你有 Project Collection 管理员istrator 和 Project 管理员istrator 访问权限，则可以更改组织或项目的配置。 若要保护对这些内置管理员组的访问，需要使用 Microsoft Entra Privileged Identity Management （PIM） 组进行实时访问。

配置访问权限

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

注意

确保使用 PIM 组具有提升访问权限的任何用户也具有对组织的标准访问权限，以便他们可以查看页面以刷新其权限。

使用访问权限

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

注意

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

作用域服务帐户

  • 确保 服务帐户 没有交互式登录权限。
  • 将服务帐户权限限制为所需的最低权限。
  • 如果对服务帐户使用域帐户，则对报表读取者帐户使用不同的标识。 有关详细信息，请参阅 服务帐户和依赖项。
  • 如果要在工作组中安装组件，请使用用户帐户的本地帐户。 有关详细信息，请参阅 服务帐户要求。
  • 尽可能使用 服务连接 。 服务连接提供了一种安全机制来连接到各种服务，而无需将机密变量直接传递到生成。 - 将这些连接限制为应使用它们的特定位置，仅此而已。
  • 监视服务帐户活动并创建 审核流式处理。 通过审核，可以检测可疑的登录和活动并做出反应。
  • 有关详细信息，请参阅 常见服务连接类型。

范围服务连接

  • 将 Azure 资源管理器和其他服务连接的范围限定为需要访问的资源和组。 服务连接不应对整个 Azure 订阅具有广泛的参与者权限。
  • 对 Azure 资源管理器（ARM） 服务连接使用工作负荷标识联合身份验证。 工作负荷标识联合允许在 Azure Pipelines 到 Azure 中创建无机密服务连接。
  • 不要授予用户对 Azure 订阅的通用或广泛参与者权限。
  • 请勿使用 Azure 经典服务连接，因为无法限定权限范围。
  • 确保资源组仅包含虚拟机 (VM) 或生成需要访问的资源。
  • 使用特定于用途的团队服务帐户对服务连接进行身份验证。
  • 有关详细信息，请参阅 常见服务连接类型。

选择正确的身份验证方法

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

考虑服务主体

探索使用 Microsoft Entra 令牌访问 Azure DevOps 资源的替代项，例如 服务主体和托管标识 。 与 PAT 相比，此类令牌在泄露时的风险较低，并且包含简单的凭据管理等优点。

请谨慎使用 PAT

如果可能，我们建议始终使用标识服务进行身份验证而不是加密密钥，因为使用应用程序代码安全地管理密钥具有挑战性，并可能导致错误，例如意外将敏感访问密钥发布到 GitHub 等公共代码存储库。 但是，如果必须使用个人访问令牌 (PAC) ，请考虑以下准则：

  • PAT 应始终限定为特定角色。

  • PAT 不应提供对多个组织的全局访问。

  • PAT 不应授予对生成或发布的写入或管理权限。

  • PAT 应具有过期日期并保密，因为它们与密码一样重要。

  • 不应在应用程序代码中对 PAT 进行硬编码，即使这样做会简化代码。

  • 管理员管理员应定期审核所有使用REST API 并撤销不符合上述条件的任何 API。

  • 将 PAT 保留为机密。 令牌与密码一样重要。

  • 将令牌存储在安全的位置。

  • 不要在应用程序中对令牌进行硬编码。 简化代码以长时间获取令牌并将其存储在应用程序中可能会很诱人，但不要这样做。

  • 为令牌提供到期日期。

  • 有关详细信息，检查以下文章：

保护 Azure Artifacts

保护 Azure Boards

保护 Azure Pipelines

策略

  • 要求在原始请求者之外至少一个审阅者。 审批者共同拥有变更，并应对任何潜在影响承担同等责任。
  • 要求传递 CI 生成。 此要求可用于通过代码 linting、单元测试和安全检查（如病毒和凭据扫描）建立基线代码质量。
  • 确保原始拉取请求者无法批准更改。
  • 不允许完成 PR (拉取请求) ，即使某些审阅者投票等待或拒绝。
  • 在推送最新更改时重置代码审阅者投票。
  • 仅在特定生产分支上运行发布管道来锁定发布管道。
  • 在组织的管道设置中启用“在队列时对变量强制设置”。
  • 对于编辑器中设置的变量，请勿允许“允许用户在运行此管道时重写此值”。

代理

  • 向尽可能少的帐户授予权限。
  • 拥有限制最严格的防火墙，使代理可用。
  • 定期更新池，以确保生成群不会运行恶意参与者可以利用的易受攻击的代码。
  • 对交付或部署到生产环境的生成项目使用单独的代理池。
  • 将“敏感”池与非敏感池进行分段，并且仅允许在锁定到该池的生成定义中使用凭据。

定义

  • 使用 YAML (另一种标记语言) 管理管道定义。 YAML 是管理管道定义的首选方法，因为它提供更改的可跟踪性，并且可以遵循审批准则。
  • 保护管道定义 编辑 对最小帐户数的访问。

输入

  • 在生成脚本中包含变量的健全性检查。 健全检查可以通过可设置的变量缓解命令注入攻击。
  • 将尽可能少的生成变量设置为“在发布时可设置”。

任务

  • 避免远程提取资源，但如有必要，请使用版本控制与哈希检查。
  • 不要记录机密。
  • 不要将机密存储在管道变量中，请使用 Azure 密钥库。 定期扫描生成管道，确保机密不会存储在生成管道变量中。
  • 不要允许用户针对安全关键管道上的任意分支或标记运行生成。
  • 禁用管道上的继承，因为继承的权限很广泛，无法准确反映你对权限的需求。
  • 在所有情况下限制作业授权范围。

存储库和分支

  • 将“需要最少数量的审阅者”策略设置为“打开”，以便每个拉取请求至少由两个审批者审阅。
  • 配置特定于每个存储库或分支的安全策略，而不是项目范围。 安全策略可降低风险、强制实施变更管理标准并提高团队的代码质量。
  • 将生产机密存储在单独的密钥库中，并确保仅根据需要知道的方式授予访问权限，以保持非生产生成独立。
  • 不要将测试环境与生产环境混合使用，包括使用凭据。
  • 禁用分叉。 分叉越多，就越难跟踪每个分叉的安全性。 此外，用户可以轻松地将存储库的副本分叉到自己的专用帐户。
  • 不要为分叉生成提供机密。
  • 请考虑手动触发分叉生成。
  • 使用 Microsoft 托管的代理进行分支生成。
  • 对于 Git，检查项目的 git 存储库中的生产生成定义，以便可以扫描这些定义以获取凭据。
  • 配置分支控件检查，以便只有分支上下文production中运行的管道才能使用 prod-connection。
  • 有关详细信息，请参阅 其他安全注意事项。

保护 Azure Repos

保护 Azure Test Plans

安全 GitHub 集成

  • 禁用个人访问令牌 (PAT) 的身份验证，以便 OAuth 流与 GitHub 服务连接一起使用。
  • 切勿将 GitHub 服务连接作为任何存储库的管理员或所有者的标识进行身份验证。
  • 切勿使用全范围的 GitHub PAT (个人访问令牌) 对 GitHub 服务连接进行身份验证。
  • 不要将个人 GitHub 帐户用作 Azure DevOps 的服务连接。