Сделайте ваши Azure Pipelines безопасными

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

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

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

Предпосылки

Ограничение доступа к проекту, репозиторию и подключению к службе

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

• Отдельные проекты: управление каждым продуктом и командой в отдельных проектах. Это запрещает конвейерам одного продукта непреднамеренно получать доступ к открытым ресурсам из другого продукта, минимизируя боковое воздействие.
• Используйте удостоверения уровня проекта: используйте удостоверение сборки на основе проекта для конвейеров вместо удостоверения уровня коллекции. Идентификаторы проектного уровня могут получать доступ только к ресурсам в соответствующем проекте, минимизируя риск несанкционированного доступа со стороны злоумышленников. Для получения дополнительной информации см. в разделе идентификаторы сборок с областью видимости и область авторизации задания.
• Используйте политики ветвей. Чтобы обеспечить безопасные изменения кода и конвейера, примените разрешения и политики ветви. Кроме того, рассмотрите возможность добавления разрешений конвейера и проверок в репозитории.
• Добавьте дополнительную безопасность для форков: при работе с общедоступными репозиториями из GitHub тщательно рассмотрите свой подход к сборкам форков. Вилки, исходящие извне вашей организации, представляют определенные риски.
  • Не предоставляйте секреты для форков сборок: По умолчанию конвейеры настроены на выполнение форков, но секреты и защищенные ресурсы не предоставляются автоматически заданиям в этих конвейерах. Важно не отключить эту защиту для обеспечения безопасности.
  • Попробуйте вручную инициировать сборки форков: отключите автоматические сборки форков и используйте комментарии пулл-реквеста для ручной сборки этих изменений. Этот параметр позволяет просмотреть код перед активацией сборки. Дополнительную информацию см. в разделе "Отключение автоматической сборки форков".
  • Не предоставляйте секреты для сборок ответвлений. По умолчанию секреты, связанные с конвейером, недоступны для проверки pull request’ов из ответвлений. Не включайте параметр "Сделать секрет доступным для сборок вилок". Для получения инструкций по поиску и проверке этого параметра см. раздел "Вклады из форков".
  • Попробуйте вручную активировать сборки форков: отключите автоматические сборки форков и используйте комментарии к запросу на внесение изменений для ручной сборки этих вкладов. Этот параметр позволяет просмотреть код перед активацией сборки. Инструкции по этому способу см. в разделе "Отключить автоматические сборки вилки".
  • Используйте агентов, размещенных корпорацией Microsoft, для сборки форков. Избегайте выполнения сборок форков на локальных агентах. Это может позволить внешним организациям выполнять внешний код на компьютерах в корпоративной сети. По возможности используйте агенты, размещенные корпорацией Майкрософт.
  • Используйте приложение Azure Pipelines GitHub для ограничения области действия токенов. Когда вы обрабатываете форкнутый pull request в GitHub, Azure Pipelines гарантирует, что конвейер не может изменить содержимое репозитория GitHub. Это ограничение применяется только в том случае, если вы используете приложение GitHub Azure Pipelines для интеграции с GitHub.

Безопасные подключения к службе

• Свести к минимуму область служебных подключений: служебные подключения должны иметь доступ только к необходимым ресурсам. При создании подключения службы Azure Resource Manager всегда выбирайте определенную группу ресурсов. Убедитесь, что группа ресурсов содержит только необходимые виртуальные машины или ресурсы, необходимые для сборки. Инструкции по настройке подключений к службе см. в статье "Использование подключения службы Azure Resource Manager".
• Используйте федерацию удостоверений рабочей нагрузки для проверки подлинности. По возможности используйте федерацию удостоверений рабочей нагрузки вместо субъекта-службы для подключения к службе Azure. Федерация удостоверений рабочей нагрузки использует Open ID Connect (OIDC), стандартную в отрасли технологию, чтобы упростить проверку подлинности между Azure и Azure DevOps без использования секретов. Для получения инструкций о том, как это сделать, см. «Создание подключения к службе с федерацией удостоверений рабочей нагрузки (автоматически)».
• Свести к минимуму доступ к приложению GitHub. При настройке приложения GitHub в Azure DevOps предоставьте доступ только к репозиториям, которые планируется создать с помощью конвейеров.

Использование конвейеров YAML вместо классических конвейеров

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

• YAML предлагает преимущества инфраструктуры в виде кода: обрабатывать конвейеры YAML как любой другой код, так как шаги и зависимости определены в коде. Кроме того, существует четкое представление о конфигурациях конвейера и снижен риск случайной неправильной настройки.
• Конвейеры YAML можно объединить с расширенными мерами безопасности: с помощью проверок кода и пул-реквестов используйте политики веток для настройки процесса их проверки, для предотвращения неудачных слияний.
• Управление доступом к ресурсам. Владельцы ресурсов контролируют, может ли конвейер YAML получить доступ к определенным ресурсам. Эта функция безопасности предотвращает атаки, такие как кража другого репозитория. Используйте утверждения и проверки , чтобы обеспечить управление доступом для каждого запуска конвейера.
  • Проверка защищенной ветви. Если у вас есть процессы проверки кода вручную для определенных ветвей, вы можете расширить эту защиту на конвейеры. Проверка защищенной ветки для ресурса предотвращает автоматический запуск процессов в неавторизованных ветках.
  • Проверка одобрения вручную: Используйте проверку одобрения вручную, чтобы заблокировать запросы в конвейере от использования защищённого ресурса до тех пор, пока они не будут одобрены вручную указанными пользователями или группами.
  • Проверка рабочих часов. Используйте эту проверку, чтобы убедиться, что развертывание конвейера начинается в течение указанного дня и периода времени.
• Отключить создание классических конвейеров: независимо отключать создание как классических конвейеров сборки, так и классических конвейеров выпуска. При отключении обоих — классического конвейера сборки и классического конвейера выпуска — нельзя создавать группы задач или группы развертывания через пользовательский интерфейс или REST API. Дополнительные сведения см. в разделе "Отключение создания классических конвейеров".

Безопасные агенты

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

• Используйте размещенные корпорацией Майкрософт агенты вместо локальных агентов: агенты, размещенные корпорацией Майкрософт, обеспечивают изоляцию и чистую виртуальную машину для каждого запуска конвейера. Используйте размещенные корпорацией Майкрософт агенты вместо локальных агентов. Дополнительные сведения см. в разделе "Размещенные корпорацией Майкрософт агенты".
• Отдельные агенты для каждого проекта: чтобы уменьшить боковое перемещение и предотвратить перекрестное загрязнение между проектами, поддерживать отдельные пулы агентов, каждый из которых выделен для конкретного проекта.
• Используйте учетные записи с низким уровнем привилегий для запуска агентов: чтобы повысить безопасность системы, используйте учетную запись с низким уровнем привилегий для запуска локальных агентов. Например, рассмотрите возможность использования учетной записи системы или управляемой идентификации службы. Не запускайте агент под удостоверением с прямым доступом к ресурсам Azure DevOps.
• Изоляция производственных артефактов и пулов агентов, содержащих конфиденциальные данные: Используйте различные пулы агентов, чтобы предотвратить проблемы с безопасностью.
  • Используйте отдельный пул агентов для продуктовых артефактов: изолируйте продуктовые артефакты с помощью отдельного пула агентов, предотвращая случайное развертывание из непродуктовых ветвей.
  • Сегментированные конфиденциальные пулы: Создайте отдельные пулы для конфиденциальных и нечувствительных рабочих нагрузок. Разрешить учетные данные только в определениях сборки, связанных с соответствующим пулом.
• Настройте ограничивающие брандмауэры для локальных агентов: настройте брандмауэры как можно более строгими, позволяя агентам функционировать, балансировать безопасность и удобство использования.
• Регулярно обновляйте пулы агентов с собственным хостингом: Постоянные обновления ваших агентов с собственным хостингом помогут гарантировать, что уязвимый код не запущен, что снижает риск его эксплуатации.

Безопасное использование переменных и параметров

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

• Ограничение доступа к секретам: удалите все секреты или ключи из конвейеров. Перейдите к методам без секретной проверки подлинности, таким как федерация удостоверений рабочей нагрузки или задайте секреты в пользовательском интерфейсе, группе переменных или группе переменных, исходной из Azure Key Vault.
• Включить проверку параметров оболочки: Когда настройка Включить проверку аргументов параметров задач оболочки включена, добавляется проверка символов, таких как точка с запятой, кавычки и скобки. Включите валидацию аргументов задач оболочки на уровне организации или проекта в разделе Настройки>Конвейеры>Настройки.
• Ограничить переменные, которые можно задать при постановке в очередь: запретите пользователям определять новые переменные при постановке в очередь, включив настройку ограничить переменные, которые можно задать при постановке в очередь в настройках>Конвейеры> организации.
• Используйте параметры вместо переменных: в отличие от переменных, выполняющийся конвейер не может изменять параметры конвейера. Параметры имеют такие типы данных, как number и string, и они могут быть ограничены определенными подмножествами значений. Это ограничение полезно, если настраиваемый пользователем аспект конвейера должен принимать только значения из предопределенного списка, гарантируя, что конвейер не принимает произвольные данные.
• Справочные секреты из шаблонов: вместо включения встроенных скриптов, содержащих секретные параметры, непосредственно в YAML конвейера используйте шаблоны для сокрытия конфиденциальной информации от основного конвейера. Чтобы реализовать этот подход, создайте отдельный файл YAML для скрипта, а затем сохраните этот скрипт в отдельном безопасном репозитории. Затем вы можете ссылаться на шаблон и передать секретную переменную в YAML в качестве параметра. Безопасная переменная должна поступать из Azure Key Vault, группы переменных или пользовательского интерфейса конвейера. Дополнительные сведения см. в статье "Использование шаблонов".
• Ограничить секреты с помощью политик ветвей и разрешений на группы переменных. Вы можете использовать сочетание разрешений на группы переменных, условного включения заданий и политик ветвей, чтобы обеспечить привязку секретов к main ветви. Дополнительные сведения см. в разделе "Защита секретов".
• Используйте setvariable для ограничения установки переменных: используйтеsettableVariables атрибут, чтобы настроить, какие переменные авторы конвейера могут устанавливать в конвейере. Без этого параметра авторы конвейера могут объявлять неограниченное количество новых переменных с помощью команды логирования setvariable. При указании пустого списка with settableVariables все операции установки переменных запрещены. Дополнительные сведения см. в атрибуте settableVariables схемы YAML.

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

• Избегайте использования секретов, когда это возможно: проверьте, может ли конвейер использовать другой метод, отличный от использования секрета для выполнения задачи, например подключения к службе с федерацией удостоверений рабочей нагрузки или управляемым удостоверением. Управляемые удостоверения позволяют приложениям и службам проходить проверку подлинности в Azure без необходимости явных учетных данных. Дополнительные сведения см. в разделе Использование субъектов-служб и управляемых удостоверений. Не помещайте секреты в YAML: никогда не сохраняйте конфиденциальные значения в виде обычного текста в файле Azure Pipelines .yml .
• Не выводите и не логируйте секреты: избегайте выводить секреты в консоль, использовать их в качестве параметров командной строки или логировать в файлы. Azure Pipelines пытается сцефровать секреты из журналов, где это возможно, но не может перехватывать все способы утечки секретов.
• Не используйте структурированные данные, такие как JSON, как секреты: создайте отдельные секреты для каждого конфиденциального значения. Этот подход обеспечивает более высокую точность редактирования и сокращает риск предоставления конфиденциальных данных непреднамеренно.

Аудит и смена секретов

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

• Аудит обработки секретов в задачах и журналах: Проверяет задачи, чтобы убедиться, что секреты не отправляются узлам и не печатаются в журналы. Убедитесь, что в файлах журнала нет секретов, включая журналы ошибок.
• Проверьте зарегистрированные секреты: убедитесь, что секреты в конвейере по-прежнему необходимы, и удалите все, что больше не требуется для уменьшения загромождений и потенциальных рисков безопасности.
• Смена секретов: регулярно поворачивайте секреты, чтобы свести к минимуму период времени, в течение которого скомпрометированный секрет может быть использован.

Предотвращение выполнения вредоносного кода

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

• Сканирование кода: экранирование специальных символов в аргументах для предотвращения внедрения команд оболочки. Для автоматизации сканирования кода можно использовать GitHub Advanced Security для Azure DevOps .
• Проверьте входные данные и используйте параметры: проверьте входные параметры и аргументы, чтобы предотвратить непреднамеренное поведение. Используйте параметризованные запросы в скриптах, чтобы предотвратить внедрение SQL. Параметры среды выполнения помогают избежать проблем безопасности, связанных с переменными, такими как внедрение аргументов.
• Не используйте PATH в сценариях: использование параметра агента PATH опасно, так как оно может быть изменено предыдущим скриптом или средством. Всегда используйте вместо этого полностью определённый путь.
• Управление доступными задачами. Отключите возможность устанавливать и запускать задачи из Marketplace, что обеспечивает более широкий контроль над кодом, выполняемым в конвейере.

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

Узнайте, как защитить контейнеры с помощью изменений конфигурации, сканирования и политик.

• Помечайте тома только для чтения: контейнеры включают подключения томов, предоставляемые системой, для задач, инструментов и внешних компонентов, необходимых для работы с агентом узла. Установите externals, tasks и tools в режиме "только для чтения" для повышения безопасности.
• Задайте ограничения ресурсов для конкретного контейнера: установите ограничения на ЦП и память, чтобы предотвратить использование контейнеров чрезмерными ресурсами, что может привести к уязвимостям в обслуживании или безопасности.
• Используйте надежные образы: используйте официальные и проверенные образы из надежных источников, таких как Реестр контейнеров Azure или Docker Hub. Всегда указывайте конкретную версию или тег для обеспечения согласованности и надежности, вместо того чтобы полагаться на тег latest. Регулярно обновляйте базовые образы, чтобы включить последние исправления системы безопасности и исправления ошибок.
• Сканирование контейнеров для уязвимостей и применение защиты от угроз среды выполнения. Используйте такие средства, как Microsoft Defender для облака, для мониторинга и обнаружения рисков безопасности. Кроме того, Реестр контейнеров Azure предлагает встроенную проверку уязвимостей , чтобы обеспечить безопасность образов контейнеров перед развертыванием. Вы также можете интегрировать сторонние средства сканирования с помощью расширений Azure DevOps для дополнительных проверок безопасности.
• Реализуйте политики безопасности, чтобы предотвратить эскалацию привилегий и обеспечить выполнение контейнеров с минимальным количеством необходимых привилегий: например, Служба Kubernetes Azure (AKS), управление доступом на основе ролей и контроль доступа Pods позволяют применять политики, ограничивающие привилегии контейнера, обеспечить выполнение без прав суперпользователя и ограничить доступ к критически важным ресурсам.
• Использование политик сети: политики сети можно использовать для ограничения связи между контейнерами, гарантируя, что только авторизованные контейнеры могут получать доступ к конфиденциальным ресурсам в сети. Кроме того, политика Azure для AKS может применяться для применения рекомендаций по обеспечению безопасности контейнеров, таких как обеспечение развертывания только доверенных образов контейнеров.

Использование шаблонов для применения рекомендаций

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

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

Связанные статьи

• Жизненный цикл разработки безопасности Майкрософт
• Центр управления безопасностью Azure