Безопасные агенты, проекты и контейнеры

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

При защите Azure Pipelines рекомендуется защитить общую инфраструктуру, репозитории, проекты и многое другое.

Эта статья является частью серии, которая помогает реализовать меры безопасности для Azure Pipelines. Дополнительные сведения см. в статье "Защита Azure Pipelines".

Предпосылки

Категория	Требования
Azure DevOps	— Реализуйте рекомендации, изложенные в Make your Azure DevOps secure и Secure Azure Pipelines. — Базовые знания о YAML и Azure Pipelines. Дополнительные сведения см. в статье "Создание первого конвейера".
Разрешения	— Изменение разрешений конвейеров: Член группы "Администраторы проектов". — Чтобы изменить разрешения организации, нужно быть членом группы администраторов коллекции проектов.

Защита общей инфраструктуры

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

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

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

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

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

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

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

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

Почему этот риск имеет значение:

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

Рекомендации: Запустите агент с помощью непривилегированных локальных учетных записей:

• Агенты Windows: используйте сетевую службу (NT AUTHORITY\NETWORK SERVICE), локальную службу или учетную запись управляемой группы (gMSA).
• Агенты Linux и агенты macOS: создание выделенной учетной записи пользователя, отличной от корневого каталога (например, svc_azuredevops). Эта учетная запись не должна иметь доступ к sudo или sudoers для обеспечения максимальной безопасности.

Внимание

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

Риски высоко привилегированных агентов:

Локальные агенты иногда работают под учетными записями с высоким уровнем привилегий для доступа к секретам или рабочим средам. Если злоумышленники выполняют скомпрометированную цепочку процессов на одном из данных агентов сборки, они могут:

• Получение доступа к этим секретам
• Перемещение через другие системы, доступные с помощью этих учетных записей

Рекомендации по безопасности агента:

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

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

Подключения к службе должны иметь доступ только к необходимым ресурсам.

Рекомендации по проверке подлинности:

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

Рекомендации по области:

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

Защита проектов

Помимо отдельных ресурсов, важно рассмотреть группы ресурсов в Azure DevOps. Ресурсы организованы проектами команды, и вам нужно понять, к чему может получить доступ конвейер на основе параметров проекта и их ограничений.

Каждое задание в конвейере получает маркер доступа с разрешениями на чтение открытых ресурсов. В некоторых случаях конвейеры также могут обновлять эти ресурсы. Эта модель разрешений означает, что в то время как учетная запись пользователя может не иметь прямого доступа к определенному ресурсу, скриптам и задачам, выполняемым в конвейере, по-прежнему может получить доступ к нему. Кроме того, модель безопасности Azure DevOps позволяет получить доступ к этим ресурсам из других проектов в организации. Если вы решите ограничить доступ конвейера к определенным ресурсам, это решение применяется ко всем конвейерам в проекте. Определенные конвейеры не могут быть выборочно предоставлены доступ к открытым ресурсам.

Отдельные проекты

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

Если ваша организация Azure DevOps была создана до августа 2019 года, запуски могут по-прежнему иметь доступ к открытым ресурсам во всех проектах вашей организации. Администратор организации должен проверить критически важный параметр безопасности в Azure Pipelines, который обеспечивает изоляцию проекта для конвейеров.

Этот параметр можно найти в параметрах конвейеров>> организации или напрямую: https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Защита репозиториев

В репозиториях управления версиями можно хранить исходный код, файл YAML конвейера и необходимые скрипты и средства. Чтобы обеспечить безопасные изменения кода и конвейера, важно применить разрешения и политики ветви. Кроме того, рассмотрите возможность добавления разрешений конвейера и проверок в репозитории.

Кроме того, просмотрите параметры управления доступом по умолчанию для репозиториев.

Помните, что дизайн Git означает, что защита на уровне ветви имеет ограничения. Пользователи с доступ на отправку в репозиторий обычно могут создавать новые ветви. Если вы работаете с проектами с открытым кодом GitHub, любой пользователь с учетной записью GitHub может ввести свой репозиторий и предложить вклад. Так как конвейеры связаны с репозиторием (не определенными ветвями), важно рассматривать код и файлы YAML как потенциально ненадежные.

Вилки

При работе с общедоступными репозиториями из GitHub тщательно подумайте о подходе к сборкам форков. Вилки, поступающие извне вашей организации, представляют определенные риски. Чтобы защитить продукты от потенциально ненадежного кода, следуйте этим рекомендациям.

Примечание.

Эти рекомендации в основном применяются к созданию общедоступных репозиториев из GitHub.

Не предоставляйте секреты для вилки сборок

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

Примечание.

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

Рассмотрите возможность активации сборки вилки вручную

Отключите автоматические сборки форков и вместо этого используйте комментарии к запросу на слияние в качестве способа вручную выполнять сборку этих изменений. Этот параметр позволяет просмотреть код перед активацией сборки.

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

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

Просмотр изменений кода

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

Версия выполняемого конвейера YAML — это версия запроса на вытягивание. Обратите особое внимание на изменения в коде YAML и в коде, который выполняется при запуске конвейера, например, скрипты командной строки или модульные тесты.

Ограничение области маркера GitHub

При создании запроса на вытягивание GitHub вилки Azure Pipelines гарантирует, что конвейер не может изменять содержимое репозитория GitHub. Это ограничение применяется только в том случае, если вы используете приложение GitHub Azure Pipelines для интеграции с GitHub. Если вы используете другие формы интеграции GitHub, например приложение OAuth, ограничение не применяется.

Ветви пользователей

Пользователи в организации с правильными разрешениями могут создавать новые ветви, содержащие новый или обновленный код. Этот код может выполняться через тот же конвейер, что и защищенная ветвь. Если файл YAML в новой ветви изменен, обновленный YAML запускает конвейер. Хотя эта конструкция обеспечивает большую гибкость и самообслуживание, не все изменения безопасны (будь то вредоносные или нет).

Если конвейер использует исходный код или определен в Azure Repos, необходимо полностью понять модель разрешений Azure Repos. В частности, пользователь с разрешением Create Branch на уровне репозитория может ввести код в репозиторий, даже если этот пользователь не имеет разрешения на участие.

Прочие вопросы по безопасности

При защите конвейеров следует учитывать следующие аспекты безопасности.

Использование PATH

Использование параметра агента PATH опасно. Это может не указывать туда, куда вы думаете, поскольку предыдущий скрипт или инструмент могли его изменить. Для критически важных для безопасности сценариев и двоичных файлов всегда используйте полный путь к программе.

Секреты журнала

Azure Pipelines пытается удалить секреты из журналов по возможности. Эта фильтрация выполняется на основе лучших усилий и не может перехватывать все способы утечки секретов. Избегайте повторения секретов в консоли, используя их в параметрах командной строки или регистрируя их в файлах.

Блокировка контейнеров

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

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Как правило, большинство пользователей устанавливают первые три каталога только для чтения и оставляют work с доступом для чтения и записи. Если вы не записываете work в каталог в определенном задании или шаге, вы также можете сделать work только для чтения. Но если задачи конвейера включают самостоятельное изменение, может потребоваться сохранить tasks как чтение и запись.

Управление доступными задачами

Вы можете отключить возможность установки и запуска задач из Marketplace. Этот подход обеспечивает более широкий контроль над кодом, который выполняется в конвейере. Вы также можете отключить все встроенные задачи, за исключением задачи Checkout, которая является специальным действием для агента. Не отключайте предустановленные задачи в большинстве случаев.

Задачи, устанавливаемые непосредственно с помощью tfx , всегда доступны. При включении обоих этих функций доступны только эти задачи.

Использование службы аудита

Служба аудита записывает множество событий конвейера. Периодически просматривайте журнал аудита, чтобы не было пропущено вредоносных изменений. Чтобы приступить к работе, посетите https://dev.azure.com/ORG-NAME/_settings/audit.

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

Обзор системы безопасности