Рекомендации для защиты общей инфраструктуры в Azure Pipelines

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

Защищенные ресурсы в Azure Pipelines — это абстракция реальной инфраструктуры. Следуйте этим рекомендациям, чтобы защитить базовую инфраструктуру.

Использование размещенных корпорацией Майкрософт пулов

Размещенные корпорацией Майкрософт пулы обеспечивают изоляцию и чистую виртуальную машину для каждого запуска конвейера. По возможности используйте размещенные корпорацией Майкрософт пулы, а не локальные пулы.

Отдельные агенты для каждого проекта

Агент может быть привязан только к одному пулу. Возможно, вы хотите предоставить общий доступ к агентам между проектами, предоставив пулу несколько проектов. Другими словами, несколько проектов могут выполнять задания в одном агенте, один за другим. Хотя эта практика экономит затраты на инфраструктуру, она может разрешить боковое перемещение.

Чтобы устранить эту форму бокового перемещения и предотвратить "отравление" одного проекта агентом для другого проекта, сохраняйте отдельные пулы агентов с отдельными агентами для каждого проекта.

Использование учетных записей с низким уровнем привилегий для запуска агентов

Это заманчиво, но опасно запустить агент под удостоверением, которое может напрямую получить доступ к ресурсам Azure DevOps. Эта проблематичная настройка распространена в организациях, использующих идентификатор Microsoft Entra. Если вы запускаете агент под удостоверением, которое поддерживается идентификатором Microsoft Entra, то он может напрямую получить доступ к API Azure DevOps без использования маркера доступа задания. Вместо этого следует запустить агент как не привилегированную локальную учетную запись, например сетевую службу.

Azure DevOps содержит группу, которая вводит в заблуждение учетные записи службы сбора проектов. По наследованию члены учетных записей службы коллекции проектов также являются членами Администратор istratorов коллекции проектов. Иногда клиенты запускают агенты сборки с помощью удостоверения, поддерживаемого идентификатором Microsoft Entra ID, и это член учетных записей службы сбора проектов. Если злоумышленники выполняют конвейер на одном из этих агентов сборки, они могут взять на себя всю организацию Azure DevOps.

Мы также видели, как локальные агенты выполняются под учетными записями с высоким уровнем привилегий. Часто эти агенты используют привилегированные учетные записи для доступа к секретам или рабочим средам. Но если злоумышленники запускают скомпрометированный конвейер на одном из этих агентов сборки, они могут получить доступ к этим секретам. Затем злоумышленники могут перемещаться по другим системам, которые доступны через эти учетные записи.

Чтобы обеспечить безопасность систем, используйте учетную запись с наименьшими привилегиями для запуска локальных агентов. Например, используйте учетную запись компьютера или управляемое удостоверение службы. Разрешить Azure Pipelines управлять доступом к секретам и средам.

Свести к минимуму область подключений к службе

Подключения службы должны иметь доступ только к нужным ресурсам. По возможности используйте федерацию удостоверений рабочей нагрузки вместо субъекта-службы для подключения к службе Azure. Федерация удостоверений рабочей нагрузки использует стандартную в отрасли технологию Open ID Подключение (OIDC) для упрощения проверки подлинности между Azure и Azure DevOps и не использует секреты.

Подключение к службе Azure должно быть область к ресурсам, к которым необходимо получить доступ. У пользователей не должно быть широких участник прав для всей подписки Azure.

При создании подключения службы Azure Resource Manager всегда выберите группу ресурсов. Убедитесь, что группа ресурсов содержит только виртуальные машины или ресурсы, необходимые для сборки. Аналогичным образом при настройке приложения GitHub предоставьте доступ только к репозиториям, которые требуется создать с помощью Azure Pipelines.

Следующие шаги

Рассмотрим несколько общих рекомендаций по обеспечению безопасности.