Поделиться через

Рекомендации по обеспечению безопасности

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

Защита среды Azure DevOps

Используйте следующие рекомендации по удалению пользователей, просмотру событий аудита и интеграции с идентификатором Microsoft Entra.

Удаление пользователей

  • Удалите неактивных пользователей из учетных записей MSA:
  • Отключите или удалите учетные записи пользователей Microsoft Entra:
    • Если ваша организация подключена к идентификатору Microsoft Entra, вы можете отключить или удалить учетную запись пользователя Microsoft Entra при сохранении активной учетной записи пользователя Azure DevOps.
    • Этот подход позволяет продолжать запрашивать журнал рабочих элементов с помощью идентификатора пользователя Azure DevOps.
  • Отмена пользовательских PATS:
    • Регулярно просматривайте и отменяйте существующие пользовательские PATS.
    • PaTs — это критически важные маркеры проверки подлинности, и безопасное управление ими является важным.
  • Отмена специальных разрешений, предоставленных отдельным пользователям:
    • Аудит и отмена специальных разрешений, предоставленных отдельным учетным записям пользователей.
    • Убедитесь, что разрешения соответствуют принципу наименьших привилегий.
  • Переназначьте работу удаленных пользователей:
    • Перед удалением пользователей переназначьте все рабочие элементы, которые они обрабатывали.
    • Распределите рабочую нагрузку между текущими участниками команды.

Использование идентификатора Microsoft Entra

  • Единая плоскость для удостоверения:
    • Подключив Azure DevOps к идентификатору Microsoft Entra, вы устанавливаете единую систему удостоверений.
    • Согласованность между службами снижает путаницу и сводит к минимуму риски безопасности, возникающие из-за ошибок конфигурации вручную.
  • Комплексное управление:
    • Использование идентификатора Microsoft Entra позволяет реализовать точное управление.
    • Назначение различных ролей и разрешений определенным группам Microsoft Entra в различных областях ресурсов.
    • Этот подход обеспечивает контролируемый доступ и соответствует рекомендациям по обеспечению безопасности.
  • Функции безопасности:
    • Идентификатор Microsoft Entra включает дополнительные функции безопасности, такие как:
      • Многофакторная проверка подлинности (MFA): повышение проверки подлинности пользователей путем применения нескольких факторов (например, проверки пароля и телефона).
      • Политики условного доступа: определение правил доступа на основе условий (например, расположения, устройства или уровня риска).

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

Просмотр событий аудита

После поддержки вашей организации Microsoft Entra выполните следующие задачи, чтобы повысить безопасность и отслеживать шаблоны использования:

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

Защита вашей сети

Следующие функции являются эффективными способами повышения безопасности сети при работе с Azure DevOps.

  • Список разрешенных IP-адресов:
    • Настройте список разрешений, чтобы ограничить доступ к определенным IP-адресам.
    • Разрешать трафик только из надежных источников, уменьшая область атаки.
  • Шифрование.
    • Всегда используйте шифрование для передаваемых и неактивных данных.
    • Безопасные каналы связи с помощью протоколов, таких как HTTPS.
  • Проверка сертификата:
    • Проверьте сертификаты при установке подключений.
    • Убедитесь, что сертификаты действительны и выданы доверенными центрами.
  • Брандмауэры веб-приложений (WAFs):
    • Реализуйте WAFs для фильтрации, мониторинга и блокировки вредоносного веб-трафика.
    • WAFs обеспечивают дополнительный уровень защиты от распространенных атак.

Дополнительные сведения см. в рекомендациях по управлению приложениями.

Разрешения с областью действия

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

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

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

Разрешения на уровне проекта

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

Внешний гостевой доступ

  • Блокировать внешний гостевой доступ:
    • Отключите политику "Разрешить отправку приглашений в любой домен", чтобы запретить внешний гостевой доступ.
    • Рассмотрите этот шаг, если нет бизнес-потребности внешних гостей.
  • Используйте другую электронную почту или имя участника-пользователя для личных и бизнес-учетных записей:
    • Даже если это разрешено, используйте отдельные адреса электронной почты или имена субъектов-пользователей (UPN) для личных и бизнес-учетных записей.
    • Эта практика устраняет неоднозначность при диамбигации между личными и рабочими учетными записями.
  • Группировать внешних гостевых пользователей:
    • Поместите всех внешних гостевых пользователей в одну группу Microsoft Entra.
    • Правильное управление разрешениями для этой группы.
    • Удалите прямые назначения, чтобы обеспечить применение правил группы к этим пользователям. Дополнительные сведения см. в разделе "Добавление правила группы" для назначения уровней доступа.
    • Регулярно переоценка правил на вкладке "Правила группы" страницы "Пользователи". Рассмотрите любые изменения членства в группах в идентификаторе Microsoft Entra, которые могут повлиять на вашу организацию. Идентификатор Microsoft Entra может занять до 24 часов для обновления динамического членства в группах. Правила автоматически переоцениваются каждые 24 часа и всякий раз при изменении правила группы.

Дополнительные сведения см. в разделе "Гости B2B" в идентификаторе Microsoft Entra.

Управление группами безопасности

Группы безопасности и пользователей

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

Делать Не надо
Используйте идентификатор Microsoft Entra, Active Directory или группы безопасности Windows при управлении большим количеством пользователей. Не изменяйте разрешения по умолчанию для группы допустимых пользователей project. Эта группа может получать доступ к сведениям о проекте и просматривать их.
При добавлении команд рассмотрите разрешения, которые необходимо назначить участникам группы, которым необходимо создать и изменить пути к областям, пути итерации и запросы. Не добавляйте пользователей в несколько групп безопасности, содержащих разные уровни разрешений. В некоторых случаях уровень разрешений "Запретить " может переопределить уровень разрешений Allow .
При добавлении множества команд рассмотрите возможность создания настраиваемой группы "Администраторы команд" , в которой вы выделяете подмножество разрешений, доступных администраторам проектов. Не изменяйте назначения по умолчанию, сделанные в группы допустимых пользователей project. Если вы удаляете или задаете сведения на уровне экземпляра, чтобы запретить для одной из групп допустимых пользователей проекта, пользователи в группе не смогут получить доступ к любым проектам, коллекции или развертыванию, на которые вы задали разрешение.
Рекомендуется предоставить папкам запросов рабочих элементов разрешение на участие пользователей или групп, которым требуется возможность создавать и совместно использовать запросы рабочих элементов для проекта. Не назначайте разрешения, которые отмечены как "Назначить только учетным записям служб" учетным записям пользователей.
Как можно меньше групп. Доступ должен быть ограничен, и группы должны часто проверяться.
Воспользуйтесь встроенными ролями и по умолчанию предоставьте разработчикам роль Участник. Администраторы назначаются в группу безопасности Администратор проекта, чтобы получить более высокий уровень разрешений и настраивать разрешения безопасности.

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

JIT-доступ для групп администрирования

Если у вас есть доступ администратора коллекции проектов и администратора проекта, можно изменить конфигурацию организации или проекта. Чтобы повысить безопасность для этих встроенных групп администраторов, рекомендуется реализовать JIT-доступ с помощью группы Microsoft Entra управление привилегированными пользователями (PIM). Этот подход позволяет предоставлять повышенные разрешения только при необходимости, уменьшая риск, связанный с постоянным доступом.

Настройка доступа

  1. Создайте группу с возможностью назначения ролей в идентификаторе Microsoft Entra.
  2. Добавьте группу Microsoft Entra в группу Azure DevOps.

Примечание.

При настройке JIT-доступа с помощью группы Microsoft Entra управление привилегированными пользователями (PIM) убедитесь, что любой пользователь с повышенным уровнем доступа также сохраняет стандартный доступ к организации. Таким образом, они могут просматривать необходимые страницы и обновлять их разрешения по мере необходимости.

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

  1. Активируйте доступ.
  2. Обновите разрешения в Azure DevOps.
  3. Выполните действия, требующие доступа администратора.

Примечание.

Пользователи имеют повышенный доступ в Azure DevOps до 1 часа после отключения доступа к группе PIM.

Учетные записи службы области

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

Дополнительные сведения см. в разделе "Типы подключений Common Service".

Подключения службы области

  • Область подключений к службе Azure Resource Manager :
    • Чтобы ограничить доступ, настройте область подключения службы к определенным ресурсам и группам. Избегайте предоставления широких прав участника во всей подписке Azure.
    • Используйте федерацию удостоверений рабочей нагрузки для проверки подлинности. Это позволяет подключаться к службам без секретов в Azure Pipelines.
  • Используйте федерацию удостоверений рабочей нагрузки:
    • Федерация удостоверений рабочей нагрузки использует OpenID Connect (OIDC) для проверки подлинности с помощью ресурсов Azure без использования секретов.
    • Федерацию удостоверений рабочей нагрузки можно создать автоматически или вручную. Рассмотрите этот подход, если:
      • У вас роль владельца или участника в подписке Azure.
      • Вы не подключаетесь к средам Azure Stack или Azure для государственных организаций США.
      • Все задачи расширений Marketplace, которые вы используете, поддерживают федерацию удостоверений рабочей нагрузки1.
  • Определение группы ресурсов:
    • Убедитесь, что группа ресурсов содержит только Виртуальные машины (виртуальные машины) или ресурсы, необходимые для процесса сборки.
  • Избегайте подключений классической службы Azure:
    • Классические подключения службы не имеют параметров области. Вместо этого выберите современные подключения службы Azure Resource Manager.
  • Используйте учетные записи службы группы для конкретных целей:
    • Проверка подлинности подключений служб с помощью учетных записей служб для конкретного назначения для обеспечения безопасности и контроля.

Дополнительные сведения см. в разделе "Типы подключений Common Service".

Выбор правильного метода проверки подлинности

Выберите методы проверки подлинности из следующих источников:

Рассмотрим субъекты-службы

Изучите альтернативные варианты, такие как субъекты-службы и управляемые удостоверения:

  • Субъекты-службы:
    • Представляет объекты безопасности в приложении Microsoft Entra.
    • Определите, что может сделать приложение в данном клиенте.
    • Настройка во время регистрации приложения в портал Azure.
    • Настроен доступ к ресурсам Azure, включая Azure DevOps.
    • Полезно для приложений, требующих определенного доступа и контроля.
  • Управляемые удостоверения:
    • Аналогично субъекту-службе приложения.
    • Укажите удостоверения для ресурсов Azure.
    • Разрешить службам, поддерживающим проверку подлинности Microsoft Entra, для предоставления общего доступа к учетным данным.
    • Azure автоматически обрабатывает управление учетными данными и смену.
    • Идеально подходит, когда требуется простое управление сведениями о входе.

Использование PATs с разреженным

  • Область PATs для определенных ролей:
    • Назначьте paTs только необходимые разрешения, необходимые для определенных задач. Избегайте предоставления глобального доступа нескольким организациям или репозиториям.
    • Области PATs гарантирует, что у них есть минимальные привилегии, что снижает риск случайного неправильного использования.
  • Избегайте записи и управления разрешениями на сборки и выпуски:
    • PaTs не должны иметь разрешения на запись или управление ими в сборках, выпусках или других критически важных ресурсах.
    • Ограничение этих разрешений помогает предотвратить непредвиденные действия, которые могут повлиять на конвейеры или развертывания.
  • Задайте даты окончания срока действия и сохраните секрет PATs:
    • Всегда устанавливайте дату окончания срока действия для PATs. Регулярно просматривайте и обновляйте их по мере необходимости.
    • Обрабатывать PATs как критически важные, как пароли. Сохраняйте их конфиденциальность и избегайте общего доступа к ним или жесткого кода в коде приложения.
  • Избегайте жесткого кода PAT в коде приложения:
    • Хотя это может показаться удобным, избегайте внедрения PATS непосредственно в код.
    • Вместо этого используйте безопасные файлы конфигурации или переменные среды для динамического хранения и извлечения PAT.
  • Регулярно проверяйте и отменяйте неиспользуемые PAT:
    • Администраторы должны периодически просматривать все PAT с помощью REST API.
    • Отмените все paTs, которые больше не нужны или не соответствуют рекомендуемому критерию.

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

Защита Azure Artifacts

Защита Azure Boards

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

Политики

  • Требовать рецензентов за пределами исходного запрашивающего средства:
    • Наличие по крайней мере одного рецензента за пределами исходного запрашивающего средства обеспечивает более тщательный процесс проверки.
    • Утверждающий разделяет совместное владение изменениями и должен быть в равной степени подотчетен любому потенциальному влиянию.
  • Требовать передачу сборки CI:
    • Требование передачи сборки непрерывной интеграции (CI) перед слиянием PR устанавливает базовый план для качества кода.
    • Проверки CI включают в себя подкладку кода, модульные тесты и проверки безопасности (например, проверки вирусов и учетных данных).
  • Запретить самостоятельное утверждение исходного запрашивающего средства:
    • Запретить исходному запросу на pr утверждение собственных изменений.
    • Это действие гарантирует неустранимый процесс проверки и избегает потенциальных конфликтов интересов.
  • Запретить завершение PR даже с "ожиданием" или "отклонить" голоса:
    • Даже если некоторые рецензенты голосуют за ожидание или отклонение, предотвратить завершение pr.
    • Это действие рекомендует обращаться ко всем отзывам перед слиянием.
  • Сброс голосов рецензента кода при отправке изменений:
    • Когда последние изменения отправляются в PR, сброс голосов рецензента.
    • Это действие гарантирует повторное вычисление обновленного кода рецензентами.
  • Блокировка конвейеров выпуска для определенных рабочая ветвь:
    • Ограничить конвейеры выпуска определенными ветвями (обычно рабочей или основной).
    • Избегайте случайных развертываний из других ветвей.
  • Принудительное применение наборных переменных во время очереди:
    • Включите параметр "Принудительно установить набор во время очереди" для переменных конвейера.
    • Это действие запрещает пользователям переопределять значения переменных во время выполнения конвейера.
  • Запретить переопределение переменной в редакторе:
    • Для переменных, заданных в редакторе конвейера, запретить переопределение пользователем.
    • Это действие поддерживает согласованность и предотвращает непредвиденные изменения.

Агенты

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

Определения

  • Используйте YAML для определений конвейера:
    • YamL (еще один язык разметки) — это рекомендуемый подход для определения конвейеров.
    • Она обеспечивает возможность трассировки изменений, что упрощает отслеживание изменений с течением времени.
    • Кроме того, конвейеры YAML могут соответствовать рекомендациям по утверждению и методам управления версиями.
  • Ограничение правки доступа к определениям конвейера:
    • Ограничить доступ к редактированию определений конвейера минимальным необходимым учетным записям.
    • При этом вы снижаете риск случайных или неавторизованных изменений.

Входные данные

  • Включите проверки работоспособности переменных в скрипты сборки:
    • Реализуйте проверки работоспособности в скриптах сборки, чтобы устранить потенциальные атаки на внедрение команд с помощью наборных переменных.
    • Эти проверки могут проверять входные значения и предотвращать непреднамеренные или вредоносные команды.
  • Ограничить количество переменных сборки settable во время выпуска:
    • Задайте как можно меньше переменных сборки, чтобы быть "settable во время выпуска".
    • Минимизация числа таких переменных уменьшает область атаки и упрощает управление конфигурацией.

Задачи

  • Избегайте удаленного получения ресурсов:
    • По возможности не используйте ресурсы из внешних URL-адресов во время сборки.
    • Если необходимы удаленные ресурсы, используйте проверку версий и хэша, чтобы обеспечить целостность.
  • Избегайте ведения журнала секретов:
    • Никогда не регистрируйте конфиденциальную информацию, например секреты или учетные данные, в журналах сборки.
    • Секреты ведения журнала могут предоставлять их непреднамеренно и компрометации безопасности.
  • Используйте Azure Key Vault для секретов:
    • Вместо хранения секретов непосредственно в переменных конвейера используйте Azure Key Vault.
    • Key Vault предоставляет безопасный способ централизованного управления секретами и получения секретов.
  • Ограничить выполнение сборки произвольными ветвями или тегами:
    • Для критически важных для безопасности конвейеров ограничьте выполнение сборок пользователями в любой ветви или теге.
    • Определите определенные авторизованные ветви или теги, чтобы предотвратить случайное или несанкционированное выполнение.
  • Отключите наследование для разрешений конвейера:
    • Унаследованные разрешения могут быть чрезмерно широкими и могут не точно отражать ваши потребности.
    • Отключите наследование и задайте разрешения явным образом, чтобы соответствовать вашим требованиям безопасности.
  • Ограничение областей авторизации задания:
    • Всегда ограничивайте области авторизации задания минимальными необходимыми.
    • Точно настройте разрешения на основе конкретных задач, выполняемых каждым заданием.

Репозитории и ветви

  • Требуется минимальное количество рецензентов:
    • Включите политику "Требовать минимальное количество рецензентов", чтобы убедиться, что каждый запрос на вытягивание получает проверки от по крайней мере двух утверждающих.
    • Это способствует тщательному анализу кода и подотчетности.
  • Настройте политики безопасности для конкретного репозитория:
    • Вместо политик на уровне проекта настраивайте политики безопасности для каждого репозитория или ветви.
    • Настраиваемые политики снижают риск, применяют стандарты управления изменениями и повышают качество кода.
  • Изоляция рабочих секретов в отдельном хранилище ключей:
    • Храните секреты рабочей среды отдельно в Azure Key Vault.
    • Ограничение доступа к базе данных, необходимой для того, чтобы обеспечить разделение от непроизводственных сборок.
  • Разделение тестовых сред от рабочей среды:
    • Избегайте смешивания тестовых сред с рабочей средой.
    • Убедитесь, что учетные данные и секреты не используются в непроизводственных контекстах.
  • Отключение вилки:
    • Отключение вилки помогает управлять безопасностью.
    • Вилки могут распространяться, что затрудняет отслеживание безопасности во всех копиях.
  • Избегайте предоставления секретов для сборки вилки:
    • Воздержаться от совместного использования секретов с вилками сборки.
    • Секреты должны оставаться конфиденциальными и не подвергаться вилкам.
  • Попробуйте вручную активировать сборки вилки:
    • Вручную активируют сборки для вилок, а не разрешают автоматические триггеры.
    • Это обеспечивает более полный контроль над проверками безопасности.
  • Используйте размещенные корпорацией Майкрософт агенты для сборок вилки:
    • Используйте размещенные корпорацией Майкрософт агенты для вилированных сборок.
    • Эти агенты поддерживаются и защищаются.
  • Сканирование определений рабочей сборки в репозиториях Git:
    • Регулярно проверяйте определения сборки рабочей среды, хранящиеся в репозитории Git проекта.
    • Проверьте наличие учетных данных или конфиденциальной информации.
  • Настройка проверок управления ветвью для рабочего контекста:
    • Настройте проверки управления ветвями, чтобы ограничить использование конфиденциальных подключений (например, prod-connection) конвейерами, работающими в контексте рабочая ветвь.
    • Это гарантирует правильную авторизацию и предотвращает случайное неправильное использование.

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

Защита Azure Repos

Защита Azure Test Plans

Безопасные интеграции GitHub

  • Используйте поток OAuth вместо PATS:
    • Отключите проверку подлинности на основе PAT для подключений службы GitHub.
    • Выберите поток OAuth, который обеспечивает лучшую безопасность и интеграцию.
  • Избегайте удостоверений администратора или владельца:
    • Никогда не проверяйте подлинность подключений службы GitHub с помощью удостоверения, являющегося администратором или владельцем любых репозиториев.
    • Ограничить разрешения на необходимый уровень.
  • Избегайте полноуровневых GitHub PATs:
    • Воздерживайтесь от использования полноуровневого GitHub PAT для проверки подлинности подключений к службам.
    • Используйте маркеры с минимальными необходимыми разрешениями.
  • Избегайте личных учетных записей GitHub в качестве подключений к службе:
    • Не используйте личные учетные записи GitHub в качестве подключений к службам в Azure DevOps.
    • Вместо этого создайте выделенные учетные записи служб или используйте учетные записи уровня организации.