Защита репозиториев и конвейеров

Завершено

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

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

Что необходимо защищать	Пример уязвимости
Ваша организация Azure DevOps или репозиторий GitHub, в том числе доступ к ним и разрешенные действия	Уволенный сотрудник может отомстить, удалив репозиторий кода.
Важные ветви в репозитории и действия, требуемые для изменения кода в этих ветвях	Кто-то может случайно зафиксировать небезопасный код Bicep в главной ветви репозитория.
Код в репозитории, в том числе определения инфраструктуры, тесты и код приложения.	Кто-то забывает тестировать написанный код, и он не работает правильно, когда он выпущен в рабочую среду.
Определение конвейера	Кто-то может по неосторожности добавить в конвейер этап, который сохранит в журнал строку подключения к базе данных.
Агенты или средства, которые выполняют конвейер.	Выполнение конвейера с черновым вариантом запроса на вытягивание может создать на агенте уязвимость безопасности, которая далее сохранится при развертывании в рабочей среде.
Любые сторонние задачи или компоненты, которые могут выполняться в конвейере	При выполнении сторонней задачи в конвейере учетные данные субъекта-службы могут быть отправлены на вредоносный веб-сайт.
Субъекты-службы, которые конвейер использует для доступа к Azure	Субъект-служба непроизводства случайно вносит изменения в рабочую среду.
Секреты, которые конвейер использует для доступа к внешним системам	Сотрудник из команды может записать новый файл определения конвейера для прототипа и случайно подключить его к рабочей среде.

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

Управление пользователями и разрешениями

Рассмотрим, как предоставить доступ к организации Azure DevOps или репозиторию GitHub. Определите, у кого кто должен быть доступ и какие действия смогут выполнять эти люди.

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

Примечание.

Чтобы использовать интеграцию Microsoft Entra с GitHub, вашей организации требуется лицензия GitHub Enterprise.

Вы также можете создавать команды (в GitHub) или группы (в Azure DevOps), чтобы совокупно предоставлять разрешения ряду пользователей. Так вам не придется назначать разрешения по отдельности. Вы можете легко изменять разрешения пользователей, добавляя их в команду или группу и удаляя их из нее.

Совет

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

Тщательно изучите правила назначения разрешений, особенно для групп.

Защита важных ветвей кода

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

Рассмотрите использование правил защиты ветвей (в GitHub) или политик ветвей (в Azure Repos), чтобы предотвращать прямые фиксации в важных ветвях кода. Вы также можете потребовать, чтобы команда использовала запросы на вытягивание для слияния любых изменений. Перед слиянием вы можете применять автоматические и ручные проверки, чтобы убедиться в допустимости изменений.

Тестирование и проверка кода

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

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

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

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

Конвейер выполняется на агентах (для Azure Pipelines) или на средствах выполнения (для GitHub Actions). Агенты и средства выполнения можно рассматривать как виртуальные машины. Определение конвейера обеспечивает управление этими виртуальными машинами, активируя выполнение на них указанных задач и скриптов.

Как Azure Pipelines, так и GitHub Actions предоставляют размещенные агенты и средства выполнения, которые настраиваются и поддерживаются корпорацией Майкрософт или GitHub, соответственно. Владелец платформы настраивает компьютеры в соответствии с требованиями к безопасности. Обязанности владельца платформы включают в себя исправление уязвимостей операционной системы.

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

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

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

Оценка сторонних компонентов, работающих в конвейере

Если вы используете расширения GitHub Actions или Azure DevOps из сообщества, выясните, кто их создал и какие действия они выполняют. У сторонних компонентов в конвейере может быть доступ к учетным данным субъекта-службы и, следовательно, ко всей среде в Azure.

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

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

Защита субъектов-служб конвейера

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

Сначала вы можете защитить учетные данные для субъектов-служб.

• По возможности используйте управляемые удостоверения или удостоверения рабочей нагрузки, чтобы полностью избежать хранения учетных данных. Если вы не можете использовать управляемые удостоверения или удостоверения рабочей нагрузки со всеми конвейерами, следует использовать их везде, где это возможно.
• Создайте план регулярного изменения учетных данных для субъекта-службы. Например, в вашей организации может существовать политика смены учетных данных каждые 90 или 120 дней. Определите, кто будет за нее отвечать и как будут обновляться расположения, в которых используются эти учетные данные.
• Вы можете назначить хранителя секретов, чья роль заключается в управлении секретами, ключами и сертификатами, чтобы они не предоставлялись другим компонентам организации.

Подумайте, какие разрешения необходимо предоставить субъектам-службам:

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

Защита подключений и секретов служб

Подключение к службе (в Azure Pipelines) или секрет (в GitHub) содержат учетные данные субъекта-службы, используемого конвейером для доступа к среде Azure. Важно защищать подключения и секреты служб, а также отслеживать, какие конвейеры используют каждое из них. В противном случае можно случайно включить непроизводную среду для использования субъекта-службы, имеющего доступ к рабочим ресурсам.

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

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

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

Использование функций безопасности GitHub

GitHub предоставляет функции безопасности, которые следует оценить и использовать. К этим функциям относятся:

• Dependabot — проверяет зависимости исходного кода на наличие известных уязвимостей.
• Проверка секретов — идентифицирует в репозитории текст, который выглядит как ключи или учетные данные. Секреты не рекомендуется хранить в репозитории. Если появилось оповещение о наличии секрета в репозитории, значение секрета следует считать скомпрометированным, то есть незамедлительно отозвать или изменить его.
• Аудит — позволяет узнать, кто внес изменения в конфигурацию GitHub.
• Обзор безопасности — объединяет все оповещения системы безопасности в отношении всех репозиториев вашей организации.

Использование журналов аудита Azure DevOps

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

Защита репозитория и конвейера

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

Что необходимо защищать	Применяемый элемент управления
Ваша организация Azure DevOps или репозиторий GitHub, в том числе доступ к ним и разрешенные действия	Используйте идентификатор Microsoft Entra для проверки подлинности. Используйте команды и группы, чтобы назначать разрешения. Включите ведение журналов аудита и регулярно проверяйте их.
Важные ветви в репозитории и действия, требуемые для изменения кода в этих ветвях	Применяйте правила защиты ветвей или политики ветвей.
Код в репозитории, в том числе определения инфраструктуры, тесты и код приложения.	Принудительно примените требования к проверке кода. Добавьте автоматические или ручные тесты. В GitHub используйте Dependabot и проверку секретов.
Определение конвейера	Принудительно примените требования к проверке кода.
Агенты или средства, которые выполняют конвейер.	В Azure Pipelines используйте агенты, размещенные корпорацией Майкрософт. В GitHub Actions используйте средства выполнения, размещенные в GitHub.
Любые сторонние задачи или компоненты, которые могут выполняться в конвейере	Учитывайте угрозы безопасности, связанные со всеми сторонними расширениями и задачами.
Субъекты-службы, которые конвейер использует для доступа к Azure	Используйте удостоверения рабочей нагрузки в GitHub Actions. Для Azure Pipelines используйте субъекты-службы и регулярно меняйте учетные данные. Используйте отдельные субъекты-службы для каждой среды. Применяйте политики условного доступа.
Секреты, которые конвейер использует для доступа к внешним системам	В Azure DevOps используйте утверждения и проверки подключений к службам. В GitHub используйте секреты для конкретных сред и удостоверения рабочей нагрузки.