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 DevOps 完全托管在 Azure 数据中心中。 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 在服务器端的内存中生成。 通过 RNGCryptoServiceProvider 随机生成 32 字节，并以 base-32 编码字符串的形式与调用方共享。 此值不会存储。
- PAT 哈希会在服务器端的内存中生成，以作为原始 PAT 的 HMACSHA256Hash，而该哈希会使用存储在我们密钥保管库中的 64 字节对称签名密钥。
- 哈希值存储在我们的数据库中。
安全外壳 (SSH) 密钥
- 我们存储封闭组织 ID 和 SSH 公钥的哈希值。
- 原始公钥由调用方通过 SSL 直接提供。
- SSH 哈希会在服务器端的内存中生成，以作为组织 ID 和原始公钥的 HMACSHA256Hash，而该哈希会使用存储在我们密钥保管库中的 64 字节对称签名密钥。
- 哈希值存储在我们的数据库中。
OAuth 凭据 (JWT)
- OAuth 凭据作为完全自描述的 JSON 网络令牌 (JWT) 颁发，不会存储在我们的服务中。
- 颁发并提交给我们服务的 JWT 中的声明使用存储在我们密钥保管库中的证书进行验证。
报告安全漏洞
如果你认为自己的渗透测试揭示了与 Azure DevOps Services 相关的潜在安全漏洞，请在 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 绝不使用客户数据针对特定用户或组织的特定产品/服务。 相反，我们使用组织级别的组织数据和聚合使用情况统计信息来确定应接收特定产品/服务的组。
为管理员管理隐私策略以控制用户反馈收集
反馈切换功能允许 Azure DevOps 组织所有者控制是否提示用户提供反馈并提交。 此功能对于确保反馈做法与组织的隐私和治理策略保持一致至关重要。
建立信心
可确信 Microsoft 代表 Azure DevOps 开展的其他工作。 这些工作包括 Microsoft 的内部采用政策、我们服务状态的透明度水平以及在获得我们信息安全管理系统认证方面的进展。
内部采用
Microsoft 团队正在内部采用 Azure DevOps。 Azure DevOps 团队于 2014 年进入组织，并广泛使用它。 我们制定了指导方针，以支持其他团队的采用计划。
大型团队的变化比小型团队更为缓慢，因为它们在现有 DevOps 系统中的投资会施加影响。 对于快速迁移的团队，我们制定了项目分类方法。 它根据项目特征评估风险容忍度，以确定项目是否适合 Azure DevOps。 对于较大的团队，采用通常分阶段进行，并进行更多规划。
内部项目的更多要求包括将组织与 Microsoft Entra ID 相关联，以确保适当的用户标识生命周期和密码复杂性。 更敏感的项目还需要双重身份验证。
符合性认证
你可能有兴趣了解第三方对我们数据安全流程的评估。 Azure DevOps 获得了以下认证：
- ISO 27001：2022
- 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 可信计算下载云就绪数据分类。
采用 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 的特征：
| 属性 | Microsoft 帐户 | Microsoft Entra 身份识别系统 |
|---|---|---|
| 标识创建者 | 用户 | 组织 |
| 所有工作资产的单一用户名和密码 | 否 | 是 |
| 密码生存期和复杂性控制 | 用户 | 组织 |
| 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 的策略。