通过

关于身份验证、授权和安全策略

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

Azure DevOps 采用各种安全概念来确保只有授权用户才能访问功能、功能和数据。 用户通过对其安全凭据的身份验证及其帐户权利授权来访问 Azure DevOps。 这两者的组合决定了用户对特定功能或功能的访问权限。

本文基于 权限、访问权限和安全组入门中提供的信息。 管理员可以从了解用于保护 Azure DevOps 的帐户类型、身份验证方法、授权方法和策略中获益。

帐户类型

  • 用户
  • 组织所有者
  • 服务帐户
  • 服务主体或托管标识
  • 作业代理

身份验证

  • 用户凭据
  • Windows 身份验证
  • 双因素身份验证 (2FA)
  • SSH 密钥身份验证
  • 个人访问令牌
  • Oauth 配置
  • Active Directory 身份验证库

授权

  • 安全组成员身份
  • 基于角色的访问控制
  • 访问级别
  • 特性标志
  • 安全性命名空间和权限

策略

  • 隐私策略 URL
  • 应用程序连接和安全策略
  • 用户策略
  • Git 存储库和分支策略

帐户类型

  • 用户
  • 服务帐户
  • 服务主体或托管标识
  • 作业代理

身份验证

  • 用户凭据
  • Windows 身份验证
  • 双因素身份验证 (2FA)
  • SSH 密钥身份验证
  • 个人访问令牌
  • Oauth 配置
  • Active Directory 身份验证库

授权

  • 安全组成员身份
  • 基于角色的权限
  • 访问级别
  • 特性标志
  • 安全性命名空间和权限

策略

  • Git 存储库和分支策略

重要

Azure DevOps 不支持备用凭据身份验证。 如果仍在使用备用凭据，强烈建议切换到更安全的身份验证方法。

Azure DevOps Services（云）和 Azure DevOps Server（本地）都支持从规划到部署的软件开发。 每个平台利用Microsoft Azure 的平台即服务基础结构和服务（包括 Azure SQL 数据库）为项目提供可靠的全局可用服务。

有关如何Microsoft确保 Azure DevOps Services 项目安全、可用、安全和专用的详细信息，请参阅 Azure DevOps Services 数据保护概述。

帐户

虽然人工用户帐户是主要关注点，但 Azure DevOps 还支持各种其他帐户类型以执行不同的作：

  • 组织所有者：Azure DevOps Services组织的创建者或分配的所有者。 若要查找组织的所有者，请参阅查找组织所有者。
  • 服务帐户：用于支持特定服务的内部 Azure DevOps 组织，例如代理池服务、PipelinesSDK。 有关服务帐户的说明，请参阅 安全组、服务帐户和权限。
  • 服务主体或托管标识： Microsoft添加到组织的 Entra 应用程序或托管标识 ，代表第三方应用程序执行操作。 某些服务主体是指内部 Azure DevOps 组织来支持内部操作。
  • 作业代理：用于定期运行特定作业的内部帐户。
  • 第三方帐户：需要访问才能支持 Web 挂钩、服务连接或其他第三方应用程序的帐户。

在整个安全相关文章中，“用户”是指添加到用户中心的所有标识，其中包括人类用户和服务主体。

  • 服务帐户：用于支持特定服务的内部 Azure DevOps 组织，例如代理池服务、PipelinesSDK。 有关服务帐户的说明，请参阅 安全组、服务帐户和权限。
  • 服务主体或托管标识：Microsoft添加到组织的 Entra 应用程序或托管标识，代表第三方应用程序执行操作。 某些服务主体是指内部 Azure DevOps 组织来支持内部操作。
  • 作业代理：用于定期运行特定作业的内部帐户。
  • 第三方帐户：需要访问才能支持 Web 挂钩、服务连接或其他第三方应用程序的帐户。

管理帐户 的最有效方法是将其添加到安全组。

注意

项目集合管理员组的组织所有者和成员有权完全访问几乎所有的功能和功能。

身份验证

身份验证基于登录到 Azure DevOps 期间提供的凭据验证帐户的标识。 这些系统集成并依赖于以下其他系统的安全功能：

  • Microsoft Entra 身份识别系统
  • Microsoft 帐户 (MSA)
  • Active Directory （AD）

Microsoft Entra ID 和 MSA 支持云身份验证。 建议使用 Microsoft Entra ID 来管理大量用户。 对于访问 Azure DevOps 组织的小型用户群，Microsoft帐户已足够。 有关详细信息，请参阅 关于使用 Microsoft Entra ID 访问 Azure DevOps。

对于本地部署，建议使用 AD 来管理大量用户。 有关详细信息，请参阅 设置用于本地部署的组。

身份验证

若要在不重复请求用户名和密码的情况下访问帐户，可以使用任何可用的 身份验证方法。 这有助于以编程方式访问您的帐户，而不是通过网站访问，或者如果您是利用 Azure DevOps REST API 构建应用程序的开发人员。 一些最常用的身份验证机制包括：

  • OAuth 用于构建应用程序，以代表应用用户执行操作。 用户必须向应用提供许可。 推荐为新应用使用Microsoft Entra OAuth。
  • 服务主体 可用于创建自动化定期访问组织资源的工作流的应用程序或工具。 使用此应用标识代表应用程序本身颁发Microsoft Entra 令牌。
  • 个人访问令牌 （PAT）可用于即席请求或早期原型制作。 由于在泄露后很容易被滥用，故不推荐用于长期的应用程序开发。 某些客户仍依赖于 PAT，现在已经如此

小窍门

请记住始终 安全地存储凭据！

默认情况下，组织允许访问所有身份验证方法。 组织管理员可以 通过禁用安全策略来限制对这些身份验证方法的访问。 租户管理员可以通过限制 PAT 的创建方式来进一步降低 PAT 风险。

授权

授权验证尝试连接的标识是否具有访问服务、功能、函数、对象或方法所需的权限。 仅在身份验证成功之后才进行授权。 如果未对连接进行身份验证，则会在执行任何授权检查之前失败。 即使身份验证成功，如果用户或组缺少授权，仍可能不允许执行特定操作。

授权取决于分配给用户的权限，无论是直接还是通过安全组或安全角色的成员身份。 访问级别和功能标志还可以管理对特定功能的访问。 有关这些授权方法的详细信息，请参阅 权限、访问权限和安全组入门。

安全命名空间和权限

安全命名空间确定针对资源的特定操作的用户访问级别。

  • 每个资源系列（如工作项或 Git 存储库）都有唯一的命名空间。
  • 每个命名空间都包含零个或多个访问控制列表（ACL）。
    • 每个 ACL 都包含一个令牌、一个继承标志和访问控制条目（ACE）。
    • 每个 ACE 都有一个标识描述符、允许的权限位掩码和一个被拒绝的权限位掩码。

有关详细信息，请参阅 安全命名空间和权限参考。

安全策略

若要保护组织和代码，如果你是组织级（项目集合管理员 或租户级（Azure DevOps 管理员）管理员，则根据策略，可以启用或禁用各种策略。 值得注意的有以下几点：

如果组织已连接到 Microsoft Entra ID，则组织可以使用更多安全功能。

Project-Scoped用户组

默认情况下，添加到组织的用户可以查看所有组织和项目信息和设置，包括用户列表、项目列表、计费详细信息、使用情况数据等。

若要限制某些用户（如利益干系人、Microsoft Entra 来宾用户或特定安全组的成员），可以启用 “限制用户可见性和协作”功能，使其适用于组织的特定项目 预览功能。 启用后，以以下方式限制添加到 Project-Scoped 用户 组的任何用户或组：

  • 只能访问组织设置的“概述”和“项目”页。
  • 只能连接和查看他们显式添加到的项目。
  • 只能选择显式添加到他们连接到的项目的用户和组标识。

有关详细信息，请参阅“管理组织”、“限制项目的用户可见性”和“管理预览”功能。

警告

使用此预览功能时，请考虑以下限制：

  • 本部分所述的有限可见性功能仅适用于通过 Web 门户的交互。 使用 REST API 或 azure devops CLI 命令，项目成员可以访问受限数据。
  • 受限用户组中的用户只能选择那些明确添加到 Azure DevOps 的用户，而不能选择那些通过 Microsoft Entra 组成员身份获得访问权限的用户。
  • 在Microsoft Entra ID 中具有默认访问权限的受限组中具有成员的来宾用户无法搜索具有人员选取器的用户。

Git 存储库和分支策略

若要保护代码，可以设置各种 Git 存储库和分支策略。 有关详细信息，请参阅以下文章。

Azure Repos和 Azure Pipelines 安全性

由于存储库和生成和发布管道带来了独特的安全挑战，因此本文中讨论的功能以外的其他功能也受到使用。 有关详细信息，请参阅以下文章。

后续步骤

权限和组引用