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

Сервисы Azure DevOps | 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, чтобы получить доступ только к необходимым ресурсам.
  • Избегайте предоставления широких прав участника для всей подписки Azure.
  • При создании подключения службы Azure Resource Manager всегда выбирайте определенную группу ресурсов.
  • Убедитесь, что группа ресурсов содержит только необходимые виртуальные машины или ресурсы, необходимые для сборки.
  • При настройке приложения GitHub предоставьте доступ только к репозиториям, которые планируется создать.
  • Регулярно просматривайте журнал использования подключений к службе и удаляйте или отключаете подключения, которые больше не нужны. Служебные подключения имеют постоянный доступ к службам, к которым они подключаются, поэтому неиспользуемые подключения не должны оставаться активными дольше, чем это необходимо. Azure Pipelines начинает автоматически отключать неактивные подключения службы через 100 дней бездействия.

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

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

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

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

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

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

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

Снимок экрана: пользовательский интерфейс области авторизации задания

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

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

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

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

Вилки

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

Примечание.

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

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

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

Снимок экрана: интерфейс защиты сборки форков.

Примечание.

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

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

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

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

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

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

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

Версия конвейера 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.

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

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

  • Последнее обновление: