Безопасные репозитории и пул-реквесты

Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

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

Угрозы и элементы управления

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

Prerequisites

Перед настройкой любой политики ветви:

• Убедитесь, что целевой репозиторий и ветвь уже существуют.
• Определите, какие группы могут управлять разрешениями, обходить политики и утверждать запросы на включение изменений.
• Если вы планируете сделать обязательными проверки сборки или проверки состояния GitHub Advanced Security, сначала создайте конвейер сборки.

Базовые показатели безопасности для большинства команд

Для типичной рабочей ветки, например main, начните с этого базового варианта:

Шаг 1. Ограничение доступа к репозиторию и ветви

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

Просмотр разрешений репозитория

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

Используйте следующий шаблон:

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

Ограничить разрешения ветки

Для защищенных ветвей внимательно просмотрите и ограничьте эти разрешения:

• Обход правил при завершении pull-запросов
• Обход политик при отправке
• Принудительная отправка (перезапись истории, удаление ветвей и тегов)
• Изменение политик
• Управление разрешениями

Используйте Задать разрешения для ветки, чтобы настроить эти параметры.

Рекомендуемый шаблон для main:

Шаг 2. Требовать проверку строгого запроса на вытягивание

Требовать минимальное количество рецензентов

Используйте минимальное количество рецензентов в важных ветвях, таких как main и ветви выпуска.

Рекомендуемые параметры:

• Минимальное число рецензентов: 2 для особо важных общих веток
• Требовать по крайней мере одно утверждение для последней итерации
• Разрешить запрашивателям утвердить свои собственные изменения: Off
• Запретить пользователю, последним отправившему изменения, утверждать собственные изменения: On когда требуется более строгое разделение обязанностей

Настройка минимальной политики рецензента

az repos policy approver-count create \
  --blocking true \
  --branch main \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --reset-on-source-push true \
  --repository-id <repository-id>

Проверьте результат:

• В списке политик ветки показано, что политика рецензента включена.
• Запросы на включение изменений в ветку не могут быть завершены, пока не будет получено требуемое количество одобрений.

Сведения о политике см. в разделе "Политики ветви" и "Параметры".

Автоматическое включение рецензентов для конфиденциальных файлов

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

Подходящие кандидаты включают:

• код развертывания и инфраструктуры
• код проверки подлинности и авторизации
• Папки, критичные для соответствия требованиям
• общие шаблоны конвейеров

Настройка политики автоматически включенных рецензентов

az repos policy required-reviewer create \
  --blocking true \
  --branch main \
  --enabled true \
  --message "Security review required for protected paths." \
  --path-filter "/.azure/*;/infra/*;/pipelines/*" \
  --repository-id <repository-id> \
  --required-reviewer-ids <reviewer-email-or-emails>

Проверьте результат:

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

Дополнительные сведения см. в разделе "Автоматическое включение рецензентов кода".

Шаг 3. Применение трассировки и проверки

Проверять наличие связанных рабочих элементов

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

Настройка политики связанных рабочих элементов

az repos policy work-item-linking create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

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

Дополнительные сведения см. в разделе "Проверка связанных рабочих элементов".

Проверка сборки

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

Рекомендуемые параметры защищенных ветвей:

• Триггер: автоматический
• Требование политики: Required
• Срок действия сборки: выберите значение, соответствующее частоте изменений защищенной ветви.

Настройка политики проверки сборки

az repos policy build create \
  --blocking true \
  --branch main \
  --build-definition-id <pipeline-id> \
  --display-name "PR validation" \
  --enabled true \
  --manual-queue-only false \
  --queue-on-source-update-only true \
  --repository-id <repository-id> \
  --valid-duration 0

Проверьте результат:

• При открытии или обновлении запроса на включение изменений в очередь ставится настроенная проверочная сборка.
• Запрос на включение изменений не может быть завершён, пока обязательная сборка не завершится успешно.

Дополнительные сведения см. в разделе "Проверка сборки".

Проверка устранения комментария

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

Настройка политики разрешения комментариев

az repos policy comment-required create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Проверьте результат: pull request’ы с неразрешёнными обсуждениями будут оставаться заблокированными, пока рецензенты или авторы не пометят цепочки обсуждений как решённые.

Дополнительные сведения см. в разделе "Проверка разрешения комментариев".

Ограничение типов слияний

Используйте Ограничение типов слияния в качестве параметра управления историей репозитория. Эта политика помогает стандартизировать, как коммиты в pull request выглядят после слияния, но не является прямой мерой безопасности.

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

Пример использования:

• Требовать сквош-слияния для недолговечных веток функций.
• Запретите rebase или squash для веток, в которых ваш процесс аудита предполагает коммиты слияния.

Соображения по вопросам аудита и прослеживаемости:

• Squash создает более чистую историю целевой ветви, но при слиянии объединяет несколько коммитов исходной ветви в один коммит.
• Если ваша модель аудита зависит от сохранения точной последовательности коммитов из ветки функциональности, предпочитайте стратегии с коммитом слияния вместо squash.
• Поддерживайте политику в соответствии с тем, как разработчики проверяют и отлаживают историю в запросах на включение изменений и в целевой ветви.

Пример CLI для Azure DevOps:

az repos policy merge-strategy create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id> \
  --allow-no-fast-forward true \
  --allow-rebase false \
  --allow-rebase-merge false \
  --allow-squash false

Дополнительные сведения см. в разделе "Ограничение типов слияний".

Шаг 4. Добавление проверок состояния расширенной безопасности GitHub

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

Перед добавлением политики проверки состояния:

1. Включите GitHub Advanced Security для репозитория.
2. Настройте необходимые задачи конвейера расширенной безопасности.
3. Добавьте политику проверки сборки для ветки запроса на включение изменений.
4. Включите Wait for Processing: true для выполнения описанных задач расширенной безопасности.
5. Успешно выполните конвейер по крайней мере один раз, чтобы проверка статуса появилась в списке «Статус для проверки».

Начните с AdvancedSecurity/NewHighAndCritical, если в репозитории уже есть неустранённые предупреждения. После сокращения отставания рассмотрите возможность перехода на AdvancedSecurity/AllHighAndCritical.

Путь к браузеру:

1. Откройте целевую ветвь в разделе политика ветвей.
2. В разделе "Проверки состояния" выберите +.
3. Задайте состояние для проверки в значение AdvancedSecurity/NewHighAndCritical.
4. Оставьте дополнительные параметры по умолчанию.
5. Сохраните политику.

Расширенные проверки состояния безопасности настраиваются из проверок состояния в браузере после включения расширенной проверки безопасности и проверки сборки для репозитория. Сведения о требуемой настройке см. в разделе "Настройка проверок состояния запроса на вытягивание".

Проверьте результат:

• Pull request'ы с новыми проблемами высокого или критического уровня отмечаются как не прошедшие проверку состояния.
• Политика ветки не позволяет завершить операцию до тех пор, пока замечания не будут устранены или пока политика не будет сделана необязательной.

Дополнительные сведения о настройке см. в следующей статье:

• Настройка проверок состояния запроса на вытягивание
• Доступные проверки статуса запроса на включение изменений

Примеры планов развертывания

Базовый уровень репозитория с низкой чувствительностью

Если репозиторий имеет более низкую чувствительность и требуется управляемая начальная точка:

1. Ограничить разрешения на обход ветки в main.
2. Требовать по крайней мере одного или двух рецензентов.
3. Включите связанные рабочие элементы.
4. Добавьте проверку сборки.
5. Включите разрешение комментариев.

Репозиторий с высокой конфиденциальностью

Если репозиторий содержит ресурсы, связанные с развертыванием, идентификацией или критически важные для соответствия требованиям:

1. Ограничение разрешений на обход политики администраторам.
2. Требовать двух рецензентов для main.
3. Добавьте автоматически включенных рецензентов для защищенных путей.
4. Требовать наличия связанных рабочих элементов.
5. Добавьте проверку сборки.
6. Добавьте проверки состояния GitHub Advanced Security, если вы используете Azure DevOps Services.

Необязательно. Использование помощника по использованию ИИ для проверки конфигурации политики ветви

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

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

Используйте такие подсказки, как приведённые ниже, чтобы начать работу:

Всегда проверяйте созданные команды и рекомендации в отношении разрешений репозитория, параметров ветви и текущей документации по Azure DevOps перед их применением.

Советы по устранению неполадок

Связанные материалы

• Установите разрешения для репозитория Git
• Настройка разрешений ветви
• Политики и параметры ветви
• Доступные проверки статуса запроса на включение изменений
• Настройка расширенной безопасности GitHub
• Сведения о pull-запросах