在 Azure Pipelines 中保护共享基础结构的建议

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines 中的受保护资源是真实基础结构的抽象。 请遵循以下建议来保护底层基础结构。

使用 Microsoft 托管池

Microsoft 托管池为管道的每次运行提供隔离以及干净的虚拟机。 如果可能，请使用 Microsoft 托管池而非自托管池。

每个项目单独使用代理

一个代理只能绑定到一个池。 你可能希望通过与多个项目共享池来跨项目共享代理。 换句话说，多个项目可以在同一代理上一个接一个地运行作业。 尽管这种做法节省了基础结构成本，但它可以允许横向移动。

若要消除这种形式的横向移动并防止一个项目“毒害”另一个项目的代理，请为每个项目保留单独的代理池和单独的代理。

使用低特权帐户运行代理

以可以直接访问 Azure DevOps 资源的身份运行代理这种做法很有吸引力，但很危险。 这种有问题的设置在使用 Microsoft Entra ID 的组织中很常见。 如果你以 Microsoft Entra ID 所支持的身份运行代理，则它可以直接访问 Azure DevOps API，无需使用作业的访问令牌。 应该改将代理作为非特权本地帐户运行，网络服务就是这样的例子。

Azure DevOps 有一个名称为“项目集合服务帐户”的组，该名称有误导性。 由于继承的关系，项目集合服务帐户的成员也是项目集合管理员的成员。 客户有时会使用某个受 Microsoft Entra ID 支持并且是项目集合服务帐户成员的身份来运行其生成代理。 如果攻击者在其中一个生成代理上运行管道，那么他们就可以接管整个 Azure DevOps 组织。

我们还看到自托管代理在高特权帐户下运行。 通常情况下，这些代理使用特权帐户来访问机密或生产环境。 但是，如果攻击者在这些生成代理之一上运行已遭入侵的管道，那么他们就可以访问这些机密。 然后，攻击者就可以在可通过这些帐户访问的其他系统中横向移动。

为了确保系统安全，请使用最低特权帐户来运行自托管代理。 例如，使用计算机帐户或托管服务标识。 让 Azure Pipelines 管理对机密和环境的访问。

最小化服务连接的范围

服务连接只能访问其所需的资源。 如果可能，请使用工作负载标识联合，而不是 Azure 服务连接的服务主体。 工作负载联合身份验证使用行业标准技术 Open ID Connect (OIDC) 来简化 Azure 和 Azure DevOps 之间的身份验证，不使用密钥。

Azure 服务连接的范围应限定为服务连接需要访问的资源。 用户不应该有针对整个 Azure 订阅的广泛参与者权利。

创建新的 Azure 资源管理器服务连接时，请始终选择一个资源组。 确保资源组仅包含生成所需的 VM 或资源。 同样，在配置 GitHub 应用时，请仅授予对你要使用 Azure Pipelines 来生成的存储库的访问权限。

后续步骤

考虑一些关于安全性的常规建议。