Обеспечение безопасности Azure Pipelines

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

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

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

Предпосылки

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

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

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

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

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

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

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

• YAML предлагает преимущества инфраструктуры в виде кода: обрабатывать конвейеры YAML как любой другой код, так как шаги и зависимости определены в коде. Кроме того, существует четкое представление о конфигурациях конвейера и снижен риск случайной неправильной настройки.
• Конвейеры YAML можно объединить с расширенными мерами безопасности: с помощью проверок кода и pull запросов используйте политику ветвей для настройки процесса ревью pull запросов, чтобы предотвратить неудачные слияния.
• Управление доступом к ресурсам. Владельцы ресурсов контролируют, может ли конвейер 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 для дополнительных проверок безопасности.
• Реализуйте политики безопасности, чтобы предотвратить эскалацию привилегий и обеспечить выполнение контейнеров с минимальным количеством необходимых привилегий: например, Служба Azure Kubernetes (AKS),управление доступом на основе ролей и функция безопасности Pod позволяют применять политики, ограничивающие привилегии контейнеров, обеспечить выполнение без прав root и ограничить доступ к критически важным ресурсам.
• Использование политик сети: политики сети можно использовать для ограничения связи между контейнерами, гарантируя, что только авторизованные контейнеры могут получать доступ к конфиденциальным ресурсам в сети. Кроме того, политика Azure для AKS может применяться для применения рекомендаций по обеспечению безопасности контейнеров, таких как обеспечение развертывания только доверенных образов контейнеров.

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

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

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

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

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