通过

确保 Azure DevOps 安全

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

处理信息和数据时，尤其是在基于云的解决方案（如 Azure DevOps Services）中，安全性应是首要任务。 虽然Microsoft确保底层云基础结构的安全性，但你有责任在 Azure DevOps 中配置安全性。 本文概述了必要的安全相关配置，以保护 Azure DevOps 环境免受威胁和漏洞的影响。

保护网络和数据

使用 Azure DevOps 保护数据和资源免受未经授权的访问和潜在威胁时，保护网络至关重要。 实施网络安全和数据保护措施，以帮助确保只有受信任的源才能访问 Azure DevOps 环境。 若要在使用 Azure DevOps 时保护网络，请执行以下作：

  • 设置 IP 允许列表： 限制对特定 IP 地址的访问，以仅允许来自受信任源的流量，从而减少攻击面。 如果组织使用防火墙或代理服务器进行保护，请将 IP 和 URL 添加到允许列表。
  • 使用数据加密： 使用加密、备份和恢复策略保护数据。 始终加密传输中的数据和静止状态的数据。 使用 HTTPS 等协议保护信道的安全。 详细了解 Azure 加密。
  • 验证证书： 在建立连接时，请确保证书有效且由受信任的颁发机构颁发。
  • 实现 Web 应用程序防火墙（WAF）： 使用 WAF 筛选、监视和阻止基于 Web 的恶意流量，以额外的保护层来防范常见攻击。
  • 网络安全组（NSG）概述： 使用 NSG 控制发到 Azure 资源的入站和出站流量，确保只允许授权流量。
  • 使用 Azure 防火墙： 部署 Azure 防火墙，以跨多个 Azure 订阅和虚拟网络提供集中式网络安全策略。
  • 使用 Azure 网络观察程序监视网络流量： 使用 Azure 网络观察程序监视和诊断网络问题，确保网络的安全性和性能。
  • 使用 Azure DDoS 防护实现 DDoS 保护： 启用 Azure DDoS 防护来保护应用程序免受分布式拒绝服务 （DDoS） 攻击。

有关详细信息，请参阅 应用程序管理最佳做法。

实现零信任

在 DevOps 流程中采用 零信任 原则，以确保无论其来源如何，都会彻底验证每个访问请求。 零信任以“永不信任，始终验证”的原则进行作，这意味着默认情况下，无论网络内部还是外部，都不会信任任何实体。 通过实现零信任，可以显著降低安全漏洞的风险，并确保只有经过授权的用户和设备才能访问资源。

零信任有助于防护网络内的横向移动，确保即使网络存在受损部分，威胁也会被控制且无法传播。 有关详细信息，请参阅 零信任评估指南。

符合行业标准

确保 Azure DevOps 环境符合保护环境的行业标准和法规，并保持对用户的信任。

  • 确保符合行业标准： Azure DevOps 符合各种行业标准和法规，例如 ISO/IEC 27001、SOC 1/2/3 和 GDPR。 确保环境遵守这些标准。
  • 强制实施符合性策略： 为管道实施 分支策略 和 符合性策略。
  • 启用 CI/CD 组件治理功能，可提供以下优势：
    • 安全漏洞检测：提醒你了解开源组件中的已知漏洞。
    • 许可证符合性：确保组件符合组织的许可策略。
    • 策略强制实施：确保仅使用已批准的版本。
    • 跟踪可见性：提供跨存储库的组件可见性，以便更轻松地进行管理。

控制和限制访问

查看可供管理员使用的所有安全策略，以限制和控制谁有权访问组织。 通过防止不必要的项目创建来保持对组织的控制。

  • 禁用 “允许公共项目”： 禁用 用于创建公共项目的选项。 根据需要将项目可见性从公共切换到专用。 从未登录的用户对公共项目具有只读访问权限，而登录用户可被授予对专用项目的访问权限并进行更改。
  • 限制不必要的身份验证机制 ，并限制谁有权访问允许的身份验证。
  • 使用条件访问策略限制访问：定义 Microsoft Entra 上的条件访问策略（CAP），它能对登录事件作出反应，并在授予用户访问权限之前要求执行额外步骤来保护您的组织。

管理外部来宾

如果未正确管理，外部来宾访问可能会带来潜在的安全风险。 尽量减少这些风险，并确保外部来宾具有适当的访问权限级别，而不会损害环境的安全性。

  • 阻止外部来宾访问： 禁用 “允许将邀请发送到任何域”策略 ，以防止外部来宾访问（如果不需要它）。
  • 使用不同的电子邮件或 UPN： 对个人和业务帐户使用不同的电子邮件地址或用户主体名称（UPN），以消除与工作相关的帐户之间的歧义。
  • 组外部来宾用户： 将所有外部来宾用户放在单个Microsoft Entra 组中，并 相应地管理此组的权限。 删除直接分配，确保组规则适用于这些用户。
  • 定期重新评估规则： 定期查看“用户”页的“组规则”选项卡上的规则。 请考虑Microsoft可能影响组织的 Entra ID 中的任何组成员身份更改。 Microsoft Entra ID 最多可能需要 24 小时才能更新动态组成员身份，每当组规则发生更改时，规则都会每隔 24 小时自动重新计算一次。

有关详细信息，请参阅 Microsoft Entra ID 中的 B2B 来宾。

删除不必要的用户

从组织中删除非活动或未经授权的用户 有助于维护安全环境，并降低潜在安全漏洞的风险。

  • 直接删除非活动Microsoft帐户用户（MSA）： 如果组织使用 MSA，则直接从组织中删除非活动用户。 无法为分配给已删除 MSA 帐户的工作项创建查询。
  • 禁用或删除Microsoft Entra 用户帐户： 如果连接到 Microsoft Entra ID，请在使 Azure DevOps 用户帐户保持活动状态的同时禁用或删除 Microsoft Entra 用户帐户。 可以使用其 Azure DevOps 用户 ID 继续查询工作项历史记录。
  • 撤销管理员的用户 PAT： 通过定期查看和撤销任何现有用户 PAT，确保对这些关键身份验证令牌进行安全管理。
  • 撤销授予单个用户的特殊权限： 审核并撤销授予单个用户的任何特殊权限，以确保与最低权限原则保持一致。
  • 从已删除的用户重新分配工作： 删除用户之前，请将其工作项重新分配给当前团队成员，以有效地分发负载。

范围权限

提供所需的最低 权限 和 访问级别 ，以确保只有经过授权的个人和服务才能访问敏感信息并执行关键作。 这种做法有助于最大程度地降低未经授权的访问和潜在数据泄露的风险。

定期查看和更新这些设置，以适应组织中的更改，例如角色更改、新员工或离职。 实施对权限和访问级别的定期 审核 有助于识别和纠正任何差异，确保安全状况保持可靠且符合最佳做法。

详细了解权限：

为了确保对权限的安全高效管理，请在 Azure DevOps 环境中正确限定 权限 范围。 范围权限涉及根据用户和职责定义和分配对用户和组的适当访问权限级别。 这种做法通过确保只有授权的个人有权访问敏感信息和关键作，从而最大程度地降低未经授权的访问和潜在数据泄露的风险。

若要有效地限定权限范围，请执行以下作：

  • 禁用继承： 避免 权限继承 并防止意外访问。 由于默认允许的性质，继承可能会无意中向不应拥有这些权限的用户授予权限。 仔细管理和显式设置权限，以确保只有预期用户才有权访问。
  • 分段环境： 为不同的环境（例如开发、测试和生产）使用单独的 Azure 帐户来增强安全性和防止冲突。 此方法可最大程度地减少环境之间的资源冲突和数据污染的风险，从而更好地管理和隔离资源。 有关详细信息，请参阅 Azure 登陆区域。
  • 控制访问并确保符合性： 使用 Azure Policy 限制对未使用的 Azure 区域和服务的访问权限，确保符合组织标准。 此作通过防止未经授权的访问和使用，帮助实施最佳做法和维护安全环境。
  • 实现 Azure 基于角色的控制（ABAC）：将 ABAC 与正确标记的资源配合使用，以限制未经授权的访问。 此作可确保根据特定属性授予访问权限，通过防止未经授权的资源创建和访问来提高安全性。
  • 使用安全组： 使用 安全组 有效地管理多个用户的权限。 与单独分配权限相比，此方法简化了授予和撤消访问权限，并确保整个组织的一致性和管理更加轻松。
    • 管理大量用户时 ，请使用 Microsoft Entra ID、Active Directory 或 Windows 安全组。
    • 通过将 项目和存储库的访问权限限制 为内置或自定义安全组，降低泄露敏感信息和部署不安全代码的风险。
    • 利用内置角色，并且开发人员的角色默认为参与者。 管理员会被分配到项目管理员安全组以获得提升的权限，使他们能够配置安全权限。
    • 尽量保持小组规模尽可能小，限制访问。
    • 使用 Microsoft Entra Privileged Identity Management （PIM） 组实现实时访问。 仅在需要时授予提升的权限，从而减少与永久访问相关的风险。

放弃服务帐户

从历史上看，服务帐户与 个人访问令牌（PAT） 结合使用，以生成运行自动化进程和服务的工具。 因此，它们通常具有提升的权限。 在选择继续使用服务帐户进行开发之前，请考虑探索该方法是否仍然是适合您的身份验证方式。

  • 放弃使用 PAT，改用 Microsoft Entra 令牌：Microsoft Entra 令牌是短期有效（一小时）的令牌， 可用于替代大多数 PAT。 PAT 之所以受欢迎，是因为其易于使用，但它们也是一种常见的攻击途径，因为它们容易泄漏。
  • 在选择一个身份验证机制之前，请先阅读所有 可用的身份验证机制 。
  • 改用服务主体：服务主体表示Microsoft Entra 应用程序的标识，并具有自己的权限来定义应用程序在给定租户中可以执行的作。 建议选择服务主体来管理应用所需的权限。 将任何服务帐户的 PAT 替换为为服务主体获取的 Microsoft Entra 令牌。
    • 如果您在 Azure 资源上进行构建，可以通过使用托管身份进行身份验证，使您的项目更进一步。 托管身份为您处理所有凭据管理。
  • 使用服务连接： 服务连接允许在管道中使用服务主体。 尽可能使用服务连接器安全地连接到各种服务，避免将机密变量直接传递给构建。 限制与特定用例的连接。 有关详细信息，请参阅本文中的 “范围服务连接 ”部分。
    • 通过具有应用注册或托管标识的 工作负载标识联合 对 Azure 资源进行身份验证，而不是使用附带机密的应用注册。

服务帐户仍在使用中：

  • 创建单一用途服务帐户： 每个服务都应具有其专用帐户，以最大程度地降低风险。 避免使用常规用户帐户作为 服务帐户。
  • 识别和禁用未使用的服务帐户： 定期查看和标识不再使用的帐户。 在考虑删除之前禁用未使用的帐户。
  • 限制特权： 将服务帐户特权限制为所需的最低权限。 避免服务帐户的交互式登录权限。
  • 对报表读取者使用单独的标识： 如果对服务帐户使用域帐户，请为报表读取者使用不同的标识来 隔离权限并防止不必要的访问。
  • 将本地帐户用于工作组安装： 在工作组中安装组件时，对用户帐户使用本地帐户。 避免在此方案中使用域帐户。
  • 监视服务帐户活动： 实现审核并创建 审核流 来监视服务帐户活动。

范围服务连接

若要确保对 Azure 资源的安全和高效访问，请正确确定服务连接的范围。 服务连接允许 Azure DevOps 连接到外部服务和资源，通过限定这些连接，可以限制对必要资源的访问，并降低未经授权的访问风险。

  • 限制访问：通过将 Azure 资源管理器 服务连接的范围限定于特定资源和组。 不要在整个 Azure 订阅中授予广泛的参与者权限。
  • 使用 Azure 资源管理器： 使用工作负载身份联合，通过应用注册或托管身份标识对 Azure 资源进行身份验证，而不是通过应用注册和机密。 有关详细信息，请参阅 创建使用工作负荷标识联合的 Azure 资源管理器服务连接。
  • 范围资源组：确保资源组仅包含生成过程所需的虚拟机（VM）或资源。
  • 避免经典服务连接： 选择新式 Azure 资源管理器服务连接，而不是经典连接，这缺少范围选项。
  • 使用特定于用途的团队服务帐户： 使用特定于用途的团队服务帐户对服务连接进行身份验证，以维护安全性和控制。

有关详细信息，请参阅 常见服务连接类型。

查看审核事件

审核可用于跟踪组织中的用户作、权限更改和使用模式。 使用这些工具及时识别和解决潜在的安全事件。

  • 启用审核： 跟踪和查看与用户作、权限、更改和安全事件相关的事件。
  • 定期查看审核日志和流： 定期查看审核日志以监视用户活动并检测任何可疑行为。 查找意外的使用模式，尤其是管理员和其他用户。 此作有助于识别潜在的安全漏洞并采取纠正措施。 详细了解 我们跟踪的审核事件。
  • 配置安全警报： 配置警报以通知你任何安全事件或策略冲突。 此作可确保及时响应潜在威胁。

确保您的服务安全

若要确保 Azure DevOps 中的服务的安全性和完整性，请为每个服务实施安全措施。 这些措施包括设置权限、管理访问权限和使用特定于每个服务的安全功能。

自动执行安全扫描

使用以下合作伙伴团队构建的自动化安全工具监视代码和机密漏洞：

  • 使用代码扫描和分析： 利用 Microsoft Defender 等工具扫描代码中的漏洞、机密和配置错误。 此作有助于在开发过程中尽早识别和修正安全问题。
  • 将 Azure DevOps 凭据扫描程序（CredScan）用于 GitHub： 使用托管标识时不是一个选项，请确保凭据存储在安全位置（例如 Azure Key Vault），而不是将它们嵌入代码和配置文件中。 实现 Azure DevOps 凭据扫描程序以标识代码中的凭据。 有关详细信息，请参阅 CredScan 入门。
  • 在 GitHub 中使用原生机密扫描： 如果无法使用托管标识，请确保将机密存储在安全位置，例如 Azure Key Vault，而不是将它们嵌入到代码和配置文件中。 使用本机机密扫描功能标识代码中的机密。 有关详细信息，请参阅 关于机密扫描。

有关详细信息，请参阅 GitHub 高级安全概述。