安全最佳做法
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
处理信息和数据时，安全性应始终是最关心的问题，尤其是在基于云的解决方案（如Azure DevOps Services）中工作时。 Microsoft 使底层云基础结构保持安全，但配置Azure DevOps的安全性由你决定。
使用 Azure Devops 时，无需实现最佳做法，但这样做可能会帮助你获得更好的更安全的体验。 我们收集了一些最佳做法，以确保Azure DevOps环境安全，并考虑到以下目标：
- 正确限定服务帐户、服务连接和权限的范围
- 保持对管理员和服务帐户组的严格控制
- 使用组织/集合、项目或对象级别的安全组、策略和设置管理安全性
- 安全服务，例如Azure Artifacts、Azure Boards、Azure Pipelines、Azure Repos、Azure Test Plans和Azure DevOps。
范围服务帐户
- 确保 服务帐户 具有零交互式登录权限。
- 将服务帐户特权限制为所需的最低权限。
- 如果对服务帐户使用域帐户，则为报表读取者帐户使用不同的标识。 有关详细信息，请参阅 服务帐户和依赖项。
- 如果要在工作组中安装组件，请使用用户帐户的本地帐户。 有关详细信息，请参阅 服务帐户要求。
- 尽可能使用 服务连接 。 服务连接提供一种安全机制，用于连接到分类服务，而无需将机密变量直接传递到生成。 - 将这些连接限制为应使用的特定位置，并只使用其他任何连接。
- 监视服务帐户活动并创建 审核流式处理。 通过审核，可以检测和响应可疑登录和活动。
有关详细信息，请参阅 常见服务连接类型。
范围服务连接
- 将 Azure 资源管理器和其他服务连接范围限定为仅适用于需要访问的资源和组。 服务连接不应对整个 Azure 订阅拥有广泛的参与者权限。
- 不要向用户提供 Azure 订阅上的通用或广泛的参与者权限。
- 请勿使用 Azure 经典服务连接，因为无法限定权限的范围。
- 请确保资源组仅包含虚拟机 (VM) 或生成需要访问的资源。
- 使用特定于目的的团队服务帐户对服务连接进行身份验证。
有关详细信息，请参阅 常见服务连接类型。
GitHub
- 禁用个人访问令牌 (基于 PAT) 身份验证，因此 OAuth 流将用于GitHub服务连接。
- 从不GitHub服务连接进行身份验证，作为任何存储库的管理员或所有者的标识。 检查策略。
- 从不使用全范围GitHub PAT (个人访问令牌) 对GitHub服务连接进行身份验证。
- 不要使用个人GitHub帐户作为与Azure DevOps的服务连接。
范围权限
系统管理不同级别的权限 -单个、外部、服务器、集合、项目、对象和 - 并默认将其分配给一个或多个内置组。
个人权限
有关详细信息，请参阅 设置单个权限。
外部来宾访问
- 通过禁用 “允许将邀请发送到任何域”策略来完全阻止外部来宾访问。 如果不需要业务，最好这样做。
- 对个人和企业帐户使用不同的电子邮件或用户主体名称 (UPN) ，即使允许。 当电子邮件/UPN 相同时，此操作消除了企业和个人帐户之间消除歧义的挑战。
- 将所有外部来宾用户放在单个Azure AD组中，并相应地管理该组的权限。 可以通过这种方式轻松管理和审核。
- 删除直接分配，以便组规则应用于这些用户。 有关详细信息，请参阅 添加组规则以分配访问级别。
- 定期在“用户”页的“组规则”选项卡上重新评估规则。 阐明Azure AD中的任何组成员身份更改是否可能会影响你的组织。 Azure AD最多可能需要 24 小时才能更新动态组成员身份。 每 24 小时，每当组规则发生更改时，系统会自动重新评估规则。
有关详细信息，请参阅Azure AD中的 B2B 来宾。
管理安全组、策略和设置
安全性和用户组
有关向安全组和用户组分配权限，请参阅以下建议。
Do
|
不要
|
|---|---|
| 管理大量用户时，请使用Azure Active Directory、Active Directory 或Windows安全组。 | 请勿更改Project有效用户组的默认权限。 此组可以访问和查看项目信息。 |
| 添加团队时，请考虑要分配给团队潜在顾客、scrum 主节点和其他可能需要创建和修改区域路径、迭代路径和查询的权限。 | 不要将用户添加到包含不同权限级别的多个安全组。 在某些情况下， “拒绝 ”权限级别可能会替代 “允许 ”权限级别。 |
| 添加多个团队时，请考虑创建团队管理员自定义组，在其中分配Project管理员可用的权限子集。 | 不要更改对有效用户组进行的默认分配。 如果删除或设置 “查看实例级信息 ”权限以 拒绝 某个 有效用户组 ，则组中的用户不能访问项目、集合或部署，具体取决于你设置的组。 |
| 请考虑向需要为项目创建和共享工作项查询的用户或组授予工作项查询文件夹 “参与 ”权限。 | 不要将“ 仅分配给服务帐户” 的权限分配给用户帐户。 |
| 尽可能小地保留组。 应限制访问，并且应经常审核组。 | |
| 利用内置角色，并且开发人员的角色默认为参与者。 管理员会被分配到项目管理员安全组以获得提升的权限，使他们能够配置安全权限。 |
服务器级组
请参阅下表，其中包含要添加的内置安全组，以及最佳做法提示。
内置安全组
添加这些用户
最佳做法提示
Team Foundation Administrators
需要执行所有服务器级操作的人员。
此组应限制为需要对服务器级操作进行总管理控制的用户数最小。 如果部署使用SharePoint或报告，请考虑将此组的成员添加到SharePoint和 Team Foundation 中的场管理员和网站集管理员组。
Team Foundation 有效用户
需要查看服务器实例级信息的人员。
此组包含已知存在于服务器实例中的所有用户。 无法修改此组的成员身份。
项目级别的权限
- 限制对项目和存储库的访问，以减少泄露敏感信息并将不安全的代码部署到生产环境的风险。
- 使用内置安全组或自定义安全组来管理权限。 有关详细信息，请参阅 授予或限制对选择任务的权限。
内置安全组
添加这些用户
最佳做法
Project Collection Administrators
需要对集合进行完全管理控制的人员。
在本组中，应将需要对集合进行总体管理控制的用户数限制为可能的最小值。 对于Azure DevOps，请分配给自定义工作跟踪的管理员。
如果部署使用Reporting Services，请考虑将此组的成员添加到 Reporting Services 中的 Team Foundation 内容管理器组
Project Collection Build Administrators
需要管理集合的生成资源和权限的人员。
尽可能将本组需要对生成服务器和本集合的服务进行总体管理控制的用户的数量限制为最少。
Project范围的用户
需要有限访问权限的人员可以查看组织设置和项目，而不是他们专门添加到的项目。
如果要限制用户对显式向其添加的这些项目的可见性和访问权限，请将其添加到此组。 如果未将用户添加到Project集合管理员组，请不要将其添加到此组。
删除用户
- 如果你的组织使用 MSA 帐户，则直接从组织中删除非活动用户，因为没有其他方法阻止访问。 执行此操作时，无法为分配给已删除用户帐户的工作项创建查询。 有关详细信息，请参阅从Azure DevOps中删除用户。
- 如果组织由Azure AD提供支持，则可以禁用或删除Azure AD用户帐户，同时将其Azure DevOps帐户保持活动状态。 这样，就可以继续使用其帐户名称查询其工作项历史记录。
- 撤销用户 PAT。
- 撤销可能已授予单个用户帐户的任何特殊权限。
- 将正在删除的用户重新分配给当前团队成员的工作。
选择正确的身份验证方法
从以下源中选择 身份验证方法 ：
需要多重身份验证
要求所有用户使用多重身份验证 (MFA) 作为基本安全功能。 多重身份验证需要使用多于验证方法，这将为所有Azure DevOps事务添加第二层安全性。
使用 Azure AD
将Azure DevOps与Azure AD集成，以便具有一个标识平面。 一致性和单个权威源可提高清晰度，并减少人为错误和配置复杂性的安全风险。 端到端治理的关键是具有多个角色分配， (具有不同的角色定义，以及同一Azure AD组的不同资源范围) 。 如果没有Azure AD，你只负责控制组织访问。
有关详细信息，请参阅以下文章：
很少使用 PAT
始终使用标识服务（如果可用）而不是加密密钥进行身份验证。 安全地使用应用程序代码来管理密钥非常困难，并且通常会导致出错，例如意外地将敏感的访问密钥发布到 GitHub 等代码存储库。 但是，如果使用 PAT，请参阅以下建议：
管理员应使用 REST API 审核所有 PAT，并撤销未满足以下使用 PAT 条件的任何 PAT：
- 应始终 (角色) 作用域。
- 不应是全局 (可以访问多个组织) 。
- 不应允许对生成或发布写入或管理权限。
- 应具有到期日期。
- 应保密。 令牌与密码一样重要。
- 应具有到期日期。
- 不应硬编码。 简化代码以长时间获取令牌并将其存储在应用程序中，但这样做可能很诱人。 它们最终可能以可能被盗的源代码结尾。
使 PAT 保持机密。 令牌与密码一样重要。
将令牌存储在安全的位置。
不要在应用程序中硬编码令牌。 简化代码以长时间获取令牌并将其存储在应用程序中，但这样做可能很诱人。
为令牌提供到期日期。
有关详细信息，请查看以下文章：
按位置限制访问
使用Azure AD条件访问策略验证限制对特定 IP (Internet 协议) 地址范围的访问权限。 例如，可以配置位置，以便内部 IP 地址不需要 MFA。
有关详细信息，请参阅 在条件访问策略中使用位置条件。
保护网络
设置 允许列表。
使用 Web 应用程序防火墙
实现 Web 应用程序防火墙 (WAF) ，以便他们可以筛选、监视和阻止来自Azure DevOps的任何基于 Web 的恶意流量。
- 始终使用加密。
- 验证证书。
- 这不应是唯一计划的安全机制，以减少应用程序中安全 bug 的数量和严重性。
有关详细信息，请参阅 应用程序管理最佳做法
保护项目
- 为组织的项目预览功能启用 “限制用户可见性 ”，该功能仅限制你向其添加用户的那些项目的访问权限。
- 将用户添加到Project范围的用户组，以便他们只能从人员选取器查看和选择项目中的用户和组。
- 在组织的策略设置中禁用“允许公共项目”，以防止每个组织用户创建公共项目。 Azure DevOps Services允许将项目的可见性从公共更改为专用项目，反之亦然。 如果用户尚未登录到组织，则他们对公共项目具有只读访问权限。 如果用户已登录，则可以向其授予对专用项目的访问权限，并对其进行任何允许的更改。
- 不允许用户创建新项目。 使用 EasyStart“治理项目”，在提交后需要批准。
- 有关设置子项目权限的详细信息，请查看以下文章。
保护 Azure Artifacts
请确保了解源、项目和项目集合管理员之间的差异。 有关详细信息，请参阅配置Azure Artifacts设置。 有关详细信息，请参阅 设置源权限。
保护 Azure Boards
- 在自定义流程之前，请查看配置和自定义Azure Boards。
- 请参阅以下文章：
保护 Azure Pipelines
使用扩展模板。 有关如何为管道设置权限级别的详细信息，请参阅 “设置管道权限”。
策略
- 在原始请求者之外至少需要一个审阅者。 审批者共同拥有更改，应同样负责其可能产生的任何影响。
- 需要 CI 生成才能通过，这对于建立基线代码质量非常有用，例如代码 linting、单元测试，甚至病毒和凭据扫描等安全检查。
- 确保原始拉取请求程序无法批准更改。
- 禁止完成 PR (拉取请求) ，即使某些审阅者投票等待或拒绝。
- 在推送最近的更改时重置代码审阅者投票。
- 仅在特定生产分支上运行发布管道来锁定发布管道。
- 在组织的管道设置中为变量启用“在队列时强制设置变量”。
- 对于编辑器中设置的变量，不允许“允许用户在运行此管道时重写此值”。
代理
- 向尽可能少的帐户授予权限。
- 具有限制性最高的防火墙，使代理可用。
- 定期更新池，以确保生成群未运行可由恶意参与者利用的易受攻击代码。
- 使用单独的代理池生成交付或部署到生产环境的项目。
- 将“敏感”池与非敏感池分段，并且只允许在锁定到该池的生成定义中使用凭据。
定义
- 使用 YAML 管理管道定义 (另一种标记语言) 。 YAML 是管理管道定义的首选方法，因为它提供更改的可跟踪性，并且可以遵循审批准则。
- 保护管道定义 “编辑 对最小帐户数的访问”。
输入
- 在生成脚本中包含变量的理智检查。 理智检查可以通过可设置的变量缓解命令注入攻击。
- 将尽可能少的生成变量设置为“发布时可设置”。
任务
- 避免远程提取资源，但如有必要，请使用版本控制和哈希检查。
- 不要记录机密。
- 不要将机密存储在管道变量中，请使用 Azure KeyVault。 定期扫描生成管道，以确保机密不会存储在生成管道变量中。
- 不要允许用户针对安全关键管道上的任意分支或标记运行生成。
- 在管道上禁用继承，因为继承的权限很广泛，并且无法准确反映对权限的需求。
- 在所有情况下限制作业授权范围。
存储库和分支
- 将“需要最少数量的审阅者”设置为 启用策略，以便每个拉取请求至少由两个审批者审阅。
- 配置特定于每个存储库或分支的安全策略，而不是项目范围。 安全策略可降低风险，强制实施变更管理标准，并提高团队的代码质量。
- 将生产机密存储在单独的 KeyVault 中，并确保仅根据需要知道的方式授予访问权限，以使非生产版本保持独立。
- 不要将测试环境与生产环境混合使用，包括使用凭据。
- 禁用分支。 那里的分支越多，跟踪每个分支的安全性就越困难。 此外，用户可以轻松地将存储库的副本分叉到自己的专用帐户。
- 不要为分支生成提供机密。
- 请考虑手动触发分叉生成。
- 使用 Microsoft 托管的代理进行分支生成。
- 对于 Git，请检查项目的 git 存储库中的生产生成定义，以便扫描这些定义以获取凭据。
- 配置分支控制检查，以便只有分支上下文
production中运行的管道可以使用 。prod-connection
有关详细信息，请参阅 其他安全注意事项。
有关可以根据项目需求配置的精细权限控制的详细信息，请参阅Azure DevOps中的安全组、服务帐户和权限。
保护 Azure Repos
使用分支策略提高代码质量。 有关分支权限和策略的详细信息，请参阅 “设置分支权限”。
保护 Azure Test Plans
请查看以下文章：
安全Azure DevOps - 常规
- 尽可能禁用继承。 由于继承的允许默认性质，意外用户可以获得访问权限或权限。 有关详细信息，请阅读有关 继承的信息。
- 仅向用户和服务提供执行其业务功能所需的最低访问权限。
- 定期 查看审核事件 ，以监视和响应管理员和其他用户的意外使用模式。
- 请查看以下文章：