数据保护概述
Azure DevOps Services
Azure DevOps Services 是用于开发项目的云托管应用程序，从规划到部署。 基于本地功能，通过更多云服务，我们将管理源代码、工作项、生成和测试。 Azure DevOps 使用平台即服务 (PaaS) 基础结构和许多 Azure 服务（包括Azure SQL）为开发项目提供可靠的全球可用服务。
本文讨论 Microsoft 为帮助确保项目安全、可用、安全和私密而采取的步骤。 它描述了你在确保项目安全和安全方面所扮演的角色。
本文适用于每天管理其项目资产的组织管理员和 IT 专业人员。 对于已熟悉 Azure DevOps 并想要详细了解 Microsoft如何保护 Azure DevOps 中存储的资产的个人，这最有用。
我们的承诺
Microsoft 可帮助确保项目保持安全可靠，无一例外。 将项目存储在 Azure DevOps 中时，它们受益于多层安全性和治理技术、操作实践和合规性策略。 我们在静态和传输中强制实施数据隐私和完整性。
面临的威胁分为四种基本类别：数据可用性、服务可用性、服务安全性和数据隐私。 本文探讨每个类别中的特定威胁，并说明 Azure DevOps 如何处理它们。 本文首先介绍了数据的存储方式以及 Azure DevOps 如何管理对数据的访问。
数据保护需要管理员和用户积极参与，他们知道保护资产免受未经授权的泄露和篡改所要采取哪些步骤。 向用户访问点授予权限时，请明确，因此只有适当的人员才能访问 Azure DevOps 中的数据。
无论数据在何处或使用方式，都应考虑所有数据可能处于危险之中。 对于存储在云中的数据和存储在专用数据中心中的数据，此语句都是如此。 必须对数据进行分类、其敏感度和风险，如果数据遭到入侵，可能会造成损害。 此外，根据管理信息安全的总体策略对数据进行分类。
在 Azure 上构建
我们完全在 Azure 数据中心托管 Azure DevOps。 Azure DevOps 使用许多核心 Azure 服务，包括计算、存储、网络、Azure SQL、标识和访问管理以及Azure 服务总线。
Azure DevOps 使用 Azure 存储作为服务元数据和客户数据的主要存储库。 Azure DevOps 使用Azure Blob 存储和Azure SQL 数据库存储，具体取决于数据类型和存储和检索要求。
为了帮助你了解 Azure DevOps Services 数据保护方法，下面是存储服务的一些背景：
Azure Blob 存储存储大量非结构化数据。 所有项目都使用此服务。 数据包括潜在敏感或私密的信息，例如源文件的内容和工作项的附件。 对于大多数项目，大多数正在使用的存储是这种类型的非结构化 Blob 存储。
Azure SQL 数据库存储组织的结构化和事务性方面，包括项目元数据、版本控制的源代码管理历史记录和工作项的详细信息。 数据库存储使你能够快速访问项目的重要元素。 它提供 Blob 存储中的索引来查找文件和附件。
管理员可以通过 授予或限制 对用户标识或组的权限来管理对资源的访问权限。 Azure DevOps 通过 Microsoft Entra ID 和 Microsoft 帐户使用用户标识的联合身份验证。
在身份验证期间，用户将路由到身份验证提供程序，在那里他们提供其凭据。 身份验证提供程序验证用户的凭据后，Azure DevOps 会向用户颁发身份验证 Cookie。 此 Cookie 允许用户对 Azure DevOps 保持身份验证。
这样，用户凭据信息永远不会直接与 Azure DevOps 共享。 对于用户尝试访问的每个 Azure DevOps 资源，权限验证基于用户的显式权限以及用户通过组成员身份继承的权限。
管理员可以使用访问控制来帮助保护 对组织、项目集合、团队项目和团队范围的数据和功能的访问。 管理员还可以对特定资产（例如版本控制和工作项的区域路径）使用访问控制。
数据可用性
Azure DevOps 使用许多Azure 存储功能来帮助确保在发生硬件故障、服务中断或区域性灾难时数据可用性。 此外，Azure DevOps 团队遵循过程来帮助防止意外或恶意删除数据。
数据冗余
为了帮助在硬件或服务故障期间保护数据，Azure 存储在同一地理位置的两个区域之间异地复制客户数据。 例如，Azure 存储可以在北欧和西欧之间或南北美国之间异地复制数据。
对于Azure Blob 存储，客户数据在单个区域中复制三次。 客户数据以异步方式复制到同一地理位置中的第二个区域。 因此，Azure 始终维护数据的六个副本。
如果发生重大中断或灾难，具有多个副本，则可以故障转移到单独的区域，同时对区域中的硬件故障进行本地冗余。 对于Azure SQL数据库存储，如果发生区域性灾难，每日备份将保留在场外。
有关数据冗余和故障转移：
- Microsoft 在主要区域和次要区域之间复制数据时，存在固有的增量（以分钟为单位）。
- 故障转移到次要区域是Microsoft必须集中做出的决定，因为它会影响特定缩放单元上的所有客户。 除非在极端情况下，Microsoft选择避免故障转移，以便不会丢失客户数据。
- Azure DevOps 提供 99.9% 运行时间的服务级别协议（SLA）。 如果 Azure DevOps 在特定月份错过了 SLA，则会退还每月费用的一部分。
- 由于巴西只有一个区域，因此出于灾难恢复目的，巴西的客户数据将复制到美国中南部区域。
发生错误
为了防止意外数据丢失，Microsoft为存储在Azure Blob 存储中的 blob 和Azure SQL 数据库中的数据库使用时间点备份。 每个存储帐户维护所有 Blob 的单独副本，并将更改追加到现有数据。 这些备份是不可变的，无需在备份过程中重写任何现有存储。
Azure SQL 数据库包括 Azure DevOps 使用的标准备份功能。 数据将保留 28 天，这些备份也会在配对区域中复制，以便在区域性中断期间进行恢复。
删除后，可以在 28 天内恢复已删除的组织或项目。 但是，此时间段过后，这些实体将永久删除，无法还原。 虽然这些备份是灾难恢复的关键组成部分，但客户必须实践适当的数据管理和备份策略，以确保全面保护其数据。
重要
- 此处的意外删除 是指因服务发生事件而导致的方案。 它不包括客户意外删除资产（例如存储库、工作项、附件或项目）。
- 我们不支持还原客户意外删除的资产。 这些备份仅用于业务连续性，并有助于从中断或灾难方案中恢复。
- 在极少数情况下，由于后端重试和需要从多个源中删除数据，我们的删除过程可能需要长达 70 天。
实践至关重要
拥有数据的多个备份是好的，但如果没有做法，还原可能会不可预知。 人们说，“备份永远不会失败;还原操作。虽然声明在技术上不正确，但情绪是正确的。
Microsoft定期练习从备份还原数据集。 我们定期测试 Azure 中的异地冗余存储。 灾难和数据损坏方案有许多组合。 我们将继续定期规划和运行这些方案的新测试。
服务可用性
Azure DevOps 提供分布式拒绝服务 (DDoS) 保护和实时站点响应，以帮助确保你有权访问组织和相关资产。
DDoS 保护
在某些情况下，恶意 DDoS 攻击可能会影响服务可用性。 Azure 具有 DDoS 防御系统，可帮助防止针对我们的服务的攻击。 它使用标准检测和缓解技术，例如 SYN Cookie、速率限制和连接限制。 该系统旨在抵御来自外部和来自 Azure 内部的攻击。
对于可以渗透到 Azure 防御系统的应用程序特定攻击，Azure DevOps 会建立应用程序级和组织级配额和限制。 这种做法有助于防止在攻击或意外滥用资源期间过度使用密钥服务资源。
实时网站响应
在极少数情况下，可能需要对服务可用性问题进行实时站点响应。 我们有一个持续可用的运营团队，可以快速识别问题并参与必要的开发团队资源。
然后，开发团队资源可以解决问题。 它们还旨在在检测影响服务的问题后的几分钟内更新服务状态页。 开发团队资源解决问题后，他们确定根本原因并跟踪必要的更改，以防止将来出现类似问题。
用于实时站点管理的 Azure DevOps 流程侧重于体验和服务运行状况。 这些过程可最大程度地减少检测、响应和缓解问题的时间。 所有工程学科都涉及并负责，因此不断改进从直接经验中演变出来。 监视、诊断、复原和质量保证流程，然后随着时间的推移改进。
Azure DevOps 中的实时站点管理有三个不同的轨道：遥测、事件管理和实时站点评审。 以下是这些轨道所需的内容：
运营团队还会监视单个组织的可用性指标。 这些指标提供对可能仅影响部分客户的特定条件的见解。 对此数据的调查通常会导致有针对性的改进，以解决特定于客户的问题。 在某些情况下，Microsoft 甚至可能直接与你联系以了解你的体验，并与你合作改进服务。
Microsoft发布 SLA 并提供财务保证，以确保我们每月都满足这项协议。 有关详细信息，请参阅 Azure DevOps 的 SLA。
有时，合作伙伴团队或依赖项有影响 Azure DevOps 的事件。 所有合作伙伴团队都遵循类似的方法来识别、解决和学习这些服务中断。
服务安全性
从适当的设计和编码技术到操作因素，服务安全性需要始终保持警惕。 Microsoft 在防止安全漏洞和漏洞检测方面积极投入资金。 如果存在漏洞，Microsoft 会使用安全响应计划来最大程度地减少数据泄露、丢失或损坏。 有关详细信息，请参阅 关于安全性、身份验证和授权。
按设计提供安全性
Azure DevOps 设计为安全。 Azure DevOps 使用 Microsoft 安全开发生命周期，这是其开发过程的核心。 Microsoft运营安全保障计划指导 Azure DevOps 中的云操作过程。
Azure DevOps 团队对所有工程师和运营人员都有年度培训要求。 该团队还赞助了由Microsoft工程师主持的非正式会议。 团队解决会议中出现的问题后，它将与其他团队分享学到的教训。
以下方法指定训练要求：
- 服务设计期间的威胁建模
- 遵循设计和代码的最佳做法
- 使用标准工具和测试验证安全性
- 限制对操作和客户数据的访问
- 通过严格的审批过程来限制新功能的推出
云服务仅与主机平台一样安全。 Azure DevOps 将 PaaS 用于其大部分基础结构。 PaaS 自动为已知安全漏洞提供定期更新。
Azure 中托管的虚拟机使用基础结构即服务（IaaS），例如托管 生成服务。 此类映像会定期接收更新，以包括Windows 更新提供的最新安全修补程序。 相同的更新钻机适用于本地计算机，包括用于部署、监视和报告的计算机。
Azure DevOps 团队定期对 Azure DevOps 进行以安全为中心的渗透测试。 渗透测试尝试使用恶意攻击者使用的相同技术和机制来利用 Azure DevOps 的实时生产服务和基础结构。 目标是识别受控进程中的实际漏洞、配置、错误或其他安全漏洞。
团队审查这些测试的结果，以确定其他改进领域，并提高预防系统和培训的质量。 可以在 Microsoft 服务信任门户上查看最近 Azure DevOps 渗透测试的结果。
凭据安全性
Microsoft致力于确保项目保持安全和安全，而不例外。 在 Azure DevOps 中，项目受益于多层安全性和治理技术、操作实践和合规性策略。 我们在静态和传输中强制实施数据隐私和完整性。 此外，我们遵循以下有关 Azure DevOps 存储的凭据或机密的做法。 若要详细了解如何选择正确的身份验证机制，请参阅 身份验证指南。
重要
Azure DevOps 不支持备用凭据身份验证。 如果仍在使用备用凭据，强烈建议切换到更安全的身份验证方法。
个人访问令牌（PAT）
- 我们存储 PAT 的哈希。
- 原始 PAT 在服务器端生成内存中。 32 字节通过 RNGCryptoServiceProvider 随机生成，并作为 base-32 编码字符串与调用方共享。 此值未存储。
- PAT 哈希使用存储在密钥保管库中的 64 字节对称签名密钥作为 原始 PAT 的 HMACSHA256Hash 在服务器端生成内存中。
- 哈希存储在数据库中。
安全外壳 （SSH） 密钥
- 我们将存储封闭组织 ID 和 SSH 公钥的哈希。
- 通过 SSL 直接由调用方提供原始公钥。
- SSH 哈希使用存储在密钥保管库中的 64 字节对称签名密钥作为 组织 ID 和原始公钥的 HMACSHA256Hash 在服务器端生成内存中。
- 哈希存储在数据库中。
OAuth 凭据 （JWT）
- OAuth 凭据问题为完全自我描述的 JSON Web 令牌（JWT），并且不会存储在我们的服务中。
- 颁发并提供给我们的服务的 JWT 中的声明使用密钥保管库中存储的证书进行验证。
报告安全漏洞
如果你认为渗透测试揭示了与 Azure DevOps 服务相关的潜在安全漏洞，请在 24 小时内将其报告给Microsoft。 有关详细信息，请参阅 用于报告计算机安全漏洞的Microsoft网页。
重要
虽然无需通知Microsoft渗透测试活动，但必须遵守 Microsoft渗透测试规则。
悬赏计划
Azure DevOps 参与 Microsoft Bug 赏金计划。 此计划奖励向我们报告问题的安全研究人员，并鼓励更多人帮助保护 Azure DevOps 安全。 有关详细信息，请参阅 Microsoft Azure DevOps 赏金计划。
限制访问
Microsoft 严格控制谁有权访问我们的生产环境和客户数据。 我们仅在验证用户的理由后，才授予所需的最低权限级别的访问权限。 如果团队成员需要访问权限来解决紧急问题或部署配置更改，则必须申请对生产服务的实时访问。 问题解决后，将立即撤销访问权限。
我们在单独的系统中跟踪和监视访问请求和审批。 对系统的所有访问都与这些审批相关联。 如果我们检测到未经批准的访问，我们会提醒运营团队进行调查。
我们将双因素身份验证用于所有远程系统访问。 如果其中一名开发人员或运营人员用户名和密码被盗，则数据将受到保护。 在允许任何远程访问服务之前，必须进行通过智能卡或对预批准的号码的电话呼叫进行更多身份验证检查。
为了管理和维护服务，Microsoft使用 RDP 密码、SSL 证书和加密密钥等机密。 这些机密均通过Azure 门户进行安全管理、存储和传输。 对这些机密的任何访问都需要特定的权限，该权限是安全记录和记录的。 所有机密都定期轮换，如果发生安全事件，我们可以按需轮换这些机密。
Azure DevOps 运营团队使用强化的管理员工作站管理服务。 这些计算机运行最少数量的应用程序，并在逻辑分段的环境中运行。
运营团队成员必须提供具有双重身份验证的特定凭据才能访问工作站。 所有访问都受到监视和安全记录。 为了将服务与外部篡改隔离开来，我们不允许应用程序（如 Outlook 和 Office），因为它们通常是钓鱼和其他类型的攻击的目标。
入侵保护和响应
我们通过 HTTPS 和 SSL 加密数据，以帮助确保在你与 Azure DevOps 之间传输时不会截获或修改数据。 我们代表你存储在 Azure DevOps 中的数据加密如下：
存储在 Azure SQL 数据库中的数据通过 透明数据加密进行加密。 此功能通过对数据库、关联的备份和事务日志文件进行实时加密来帮助防止恶意活动。
Azure Blob 存储连接已加密，以帮助保护传输中的数据。 对于存储在Azure Blob 存储中的静态数据，Azure DevOps 使用服务端加密。
Azure DevOps 团队使用 Azure 基础结构来记录和监视服务的关键方面。 日志记录和监视有助于确保服务中的活动是合法的，它们有助于检测违规或尝试的违规行为。
所有部署和管理员活动都安全记录，操作员也有权访问生产存储。 会自动分析日志信息，任何潜在的恶意或未经授权的行为都会引发实时警报。
当 Azure DevOps 团队确定可能的入侵或高优先级安全漏洞时，它具有明确的响应计划。 此计划概述了责任方、保护客户数据所需的步骤，以及有关如何与Microsoft安全专家接触的说明。 如果数据被泄露或损坏，团队还会通知任何组织所有者，以便他们能够采取适当的步骤来纠正这种情况。
为了帮助应对新兴威胁，Azure DevOps 采用假设 的违规 策略。 Microsoft中高度专业化的安全专家团队扮演了复杂的对手的角色。 此团队测试漏洞检测和响应，以准确衡量实际攻击的准备情况和影响。 此策略可加强服务的威胁检测、响应和防御。 它还允许团队验证和提高整个安全计划的有效性。
勒索软件攻击防护
Azure DevOps 使用 Azure 控件来帮助防止、检测和响应勒索软件攻击。 有关 Azure 如何帮助保护客户免受勒索软件攻击的详细信息，请参阅 Azure 中的勒索软件保护。
数据隐私
你应该有信心，我们正在适当和合法地处理你的数据。 该保证的一部分涉及仔细限制使用情况。
一般数据保护条例
自 1995 年引入欧盟 (欧盟) 数据保护指令 95/46/EC 以来，GDPR) 的一般数据保护条例 (是欧洲数据保护法的最大变化。 有关 GDPR 的详细信息，请参阅 Microsoft 信任中心的概述页。
数据驻留和主权
Azure DevOps 在全球的以下八个地理位置中可用：美国、加拿大、欧洲、英国、印度、澳大利亚、亚太地区和巴西。 默认情况下，组织将分配到最近的位置。 但是，可以在创建组织时选择其他位置。 如果以后改变了主意，则可以在Microsoft支持的帮助下将组织迁移到其他位置。
Azure DevOps 不会在所选位置外移动或复制客户数据。 相反，数据将异地复制到同一位置中的第二个区域。 唯一的例外是巴西，出于灾难恢复目的，将数据复制到美国中南部区域。
注意
对于在Microsoft提供的 macOS 代理上运行的生成和版本，数据将传输到美国中的 GitHub 数据中心。
有关详细信息，请参阅 Azure DevOps 的数据位置。
执法部门访问
在某些情况下，第三方（如执法实体）可能会接近Microsoft来获取对 Azure DevOps 中存储的客户数据的访问权限。 我们尝试将请求重定向到组织所有者以解决问题。 当法院命令迫使Microsoft向第三方披露客户数据时，Microsoft作出合理努力，提前通知组织所有者，除非我们合法禁止这样做。
某些客户要求其数据存储在特定地理位置，以确保任何执法活动的特定法律管辖权。 所有客户数据（如源代码、工作项、测试结果和异地冗余镜像和异地备份）均保留在上述位置之一内。
Microsoft 访问
Microsoft员工需要随时获取对 Azure DevOps 中存储的客户数据的访问权限。 作为预防措施，所有有权（或可能）访问客户数据的员工都必须通过背景检查，其中包括以前的雇佣和刑事定罪。 仅当存在实时站点事件或其他已批准的维护活动（记录和监视）时，我们才允许访问生产系统。
由于系统中并非所有数据都以相同的方式处理，因此我们将数据分类为以下类型：
- 客户数据：上传到 Azure DevOps 的内容。
- 组织数据：注册或管理组织时提交的信息。
- Microsoft数据：通过服务操作或收集所需的信息。
根据分类，我们控制使用方案、地理位置要求、访问限制和保留要求。
Microsoft 促销用途
Microsoft偶尔希望联系客户，让他们了解可能有用的更多功能和服务。 由于并非所有客户都希望就这些产品/服务联系，因此你可以选择加入和退出营销电子邮件通信。
Microsoft 绝不使用客户数据针对特定用户或组织的特定产品/服务。 相反，我们使用组织级别的组织数据和聚合使用情况统计信息来确定应接收特定产品/服务的组。
建立信心
可以确信Microsoft代表 Azure DevOps 进行的其他工作。 这些努力包括Microsoft的内部采用政策、服务状态的透明度，以及接收系统管理信息安全认证的进展。
内部采用
Microsoft团队正在内部采用 Azure DevOps。 Azure DevOps 团队于 2014 年进入组织，并广泛使用它。 我们制定了为其他团队启用采用计划的指导。
大型团队的移动比较小的团队要逐渐移动，因为他们对现有 DevOps 系统的投资。 对于快速移动的团队，我们建立了项目分类方法。 它根据项目特征评估风险容忍度，以确定项目是否适合 Azure DevOps。 对于较大的团队，采用通常分阶段进行，并进行更多规划。
内部项目的更多要求包括将组织与 Microsoft Entra ID 相关联，以确保适当的用户标识生命周期和密码复杂性。 更敏感的项目还需要双重身份验证。
符合性认证
你可能有兴趣了解对数据安全过程的第三方评估。 Azure DevOps 实现了以下认证：
- ISO 27001:2013
- ISO 27018：2019
- ISO 26262：2023
- 健康保险可携性和责任法案 (HIPAA)
- 业务关联协议 （BAA）
- 欧盟示范条款
- 系统和组织控制 （SOC） 1 类型 2
- SOC 2 类型 2
- 德国 C5
- 澳大利亚 IRAP
- ENS-西班牙
Azure DevOps 的 SOC 审核涵盖数据安全性、可用性、处理完整性和保密性的控制。 Azure DevOps 的 SOC 报告可通过 Microsoft 服务信任门户获取。
共识评估计划问卷（CAIQ）可帮助组织评估和评估云服务提供商的安全做法和功能。 根据我们对安全性和透明度的承诺，我们最近完成了 Azure DevOps 的 CAIQ 评估。 我们邀请你查看有关 Microsoft 服务信任门户的完整报告。
可以执行的步骤
适当的数据保护需要你、管理员和用户积极参与。 存储在 Azure DevOps 中的项目数据仅与用户访问点一样安全。 将这些组织的权限严格性和粒度级别与项目的敏感度级别相匹配。
对数据进行分类
第一步是对数据进行分类。 根据敏感度和风险范围对数据进行分类，以及泄露时可能发生的损害。 许多企业具有现有的分类方法，在项目迁移到 Azure DevOps 时，可以重复使用这些方法。 有关详细信息，可以从 Microsoft Trustworthy Computing 下载 云就绪情况 的数据分类。
采用 Microsoft Entra ID
使用 Microsoft Entra ID 管理组织对 Azure DevOps 的访问权限。 Microsoft Entra ID 提供了另一种提高用户凭据安全性的方法。
Microsoft Entra ID 允许 IT 部门在用户离开组织时管理其用户访问策略、密码复杂性、密码刷新和过期。 通过 Active Directory 联合，可以直接将Microsoft Entra ID 链接到组织的中心目录，因此只有一个位置来管理企业这些详细信息。
下表比较了与 Azure DevOps 访问相关的Microsoft帐户和Microsoft Entra 特征：
| properties | Microsoft 帐户 | Microsoft Entra ID |
|---|---|---|
| 标识创建者 | 用户 | 组织 |
| 所有工作资产的单个用户名和密码 | 否 | 是 |
| 密码生存期和复杂性控制 | 用户 | 组织 |
| Azure DevOps 成员身份限制 | 任何Microsoft帐户 | 组织的目录 |
| 可跟踪标识 | 否 | 是 |
| 组织和 IP 所有权 | 清楚 | 组织 |
| 双因素身份验证注册 | 用户 | 组织 |
| 基于设备的条件访问 | 否 | 组织 |
详细了解如何为组织配置此支持。
要求双因素身份验证
你可能希望通过要求多个因素登录来限制对组织的访问。 可以使用 Microsoft Entra ID 来要求多种因素。 例如，对于所有身份验证请求，除了用户名和密码外，还可以要求进行电话身份验证。
使用 BitLocker
对于敏感项目，可以在 Windows 笔记本电脑或台式计算机上使用 BitLocker。 BitLocker 会加密 Windows 和数据所在的整个驱动器。 启用 BitLocker 后，它会自动加密你保存在该驱动器上的任何文件。 如果计算机落入错误之手，BitLocker 会阻止未经授权访问项目中的本地数据副本。
限制使用备用身份验证凭据
与 Git 相关的工具的默认身份验证机制是备用身份验证（有时称为 基本身份验证）。 此机制允许用户设置备用用户名和密码，以便在 Git 命令行操作期间使用。 用户可以使用此用户名/密码组合访问该用户有权访问的任何其他数据。 就其性质而言，备用身份验证凭据的安全性不如默认联合身份验证。
你仍然可以选择提高安全性。 所有通信都通过 HTTPS 发送，并且存在密码复杂性要求。 你的组织应继续评估它是否需要更多策略来满足项目的安全要求。
如果确定它不符合组织的安全要求，则可以禁用备用身份验证凭据。 有关详细信息，请参阅 更改组织的应用程序连接和安全策略。
保护对组织的访问
管理员可以使用 Microsoft Entra ID 来控制对 Azure 资源和应用程序的访问，例如 Azure DevOps。 使用条件访问控制，Microsoft Entra ID 会检查为用户设置以访问应用程序的特定条件。 用户满足访问要求后，将进行身份验证并可以访问应用程序。
Azure DevOps 支持强制实施某些类型的条件访问策略， (例如，自定义 Azure DevOps 身份验证机制的 IP 隔离) 。 这些机制包括个人访问令牌、备用身份验证、OAuth 和安全外壳（SSH）密钥。 如果用户通过第三方客户端访问 Azure DevOps，则仅遵循基于 IPv4 的策略。