Другие вопросы безопасности для Azure Pipelines

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

При защите Azure Pipelines следует учитывать несколько других аспектов, таких как защита общей инфраструктуры, репозиториев, проектов и т. д.

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

Помимо отдельных ресурсов, важно рассмотреть группы ресурсов в 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, что позволяет повысить контроль над кодом, выполняемым в конвейере. Вы также можете отключить все задачи в поле (за исключением выхода, которое является специальным действием для агента). Рекомендуется не отключать встроенные задачи в большинстве случаев.

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

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

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

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

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