Share via

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

  • Статья

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

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

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

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

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

  • Если в организации используются учетные записи MSA, удалите неактивных пользователей непосредственно из организации, так как у вас нет другого способа запретить доступ. При этом невозможно создать запрос для рабочих элементов, назначенных удаленной учетной записи пользователя. Дополнительные сведения см. в статье "Удаление пользователей из Azure DevOps".
  • Если ваша организация подключена к идентификатору Microsoft Entra, вы можете отключить или удалить учетную запись пользователя Microsoft Entra и оставить учетную запись пользователя Azure DevOps активной. Таким образом, вы можете продолжать запрашивать журнал рабочих элементов с помощью идентификатора пользователя Azure DevOps.
  • Отмена pats пользователей.
  • Отмените все специальные разрешения, которые, возможно, были предоставлены отдельным учетным записям пользователей.
  • Переназначьте работу пользователей, которые вы удаляете на текущих участников команды.

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

Интеграция Azure DevOps с идентификатором Microsoft Entra id, чтобы иметь один уровень для удостоверения. Согласованность и один авторитетный источник повышают ясность и снижают риски безопасности от человеческих ошибок и сложности конфигурации. Ключом для конечного управления является несколько назначений ролей (с различными определениями ролей и различными область ресурсов в одних и том же группах Microsoft Entra). Без идентификатора Microsoft Entra вы несете ответственность за управление доступом организации.

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

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

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

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

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

Это можно сделать несколькими способами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Примечание.

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

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

  • Убедитесь, что у учетных записей служб нет прав интерактивного входа.
  • Ограничьте права учетной записи службы минимальным необходимым.
  • Используйте другое удостоверение для учетной записи чтения отчетов, если вы используете учетные записи домена для учетных записей служб. Дополнительные сведения см. в разделе "Учетные записи службы" и "Зависимости".
  • Используйте локальные учетные записи для учетных записей пользователей, если вы устанавливаете компонент в рабочей группе. Дополнительные сведения см. в разделе "Требования к учетной записи службы".
  • По возможности используйте подключения к службам. Подключения службы предоставляют безопасный механизм для подключения к службам assorted без необходимости передавать секретные переменные в сборку напрямую. — ограничить эти подключения определенным местом, которое они должны использоваться, и ничего больше.
  • Мониторинг действий учетной записи службы и создание потоковой передачи аудита. Аудит позволяет обнаруживать и реагировать на подозрительные входы и действия.
  • Дополнительные сведения см. в разделе "Типы подключений Common Service".

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

  • Область Azure Resource Manager и другие подключения служб только к ресурсам и группам, к которым им требуется доступ. Подключения к службам не должны иметь широких участник прав на всю подписку Azure.
  • Используйте федерацию удостоверений рабочей нагрузки для подключений службы Azure Resource Manager (ARM). Федерация удостоверений рабочей нагрузки позволяет создавать подключения к службам без секретов в Azure Pipelines.
  • Не предоставляйте пользователям универсальные или широкие участник права на подписку Azure.
  • Не используйте подключения к классической службе Azure, так как нет способа область разрешений.
  • Убедитесь, что группа ресурсов содержит только Виртуальные машины (виртуальные машины) или ресурсы, к которым требуется доступ сборки.
  • Используйте учетную запись службы группы для проверки подлинности подключения к службе.
  • Дополнительные сведения см. в разделе "Типы подключений Common Service".

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

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

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

Изучите альтернативные варианты, такие как субъекты-службы и управляемые удостоверения , которые позволяют использовать маркеры Microsoft Entra для доступа к ресурсам Azure DevOps. Такие токены несут меньший риск при утечке по сравнению с PATs и содержат преимущества, такие как простое управление учетными данными.

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

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

  • PaTs всегда должны быть область для определенных ролей.

  • PaTs не должны предоставлять глобальный доступ к нескольким организациям.

  • PaTs не должны предоставлять разрешения на запись или управление ими в сборках или выпусках.

  • PaTs должны иметь дату окончания срока действия и хранить секрет, так как они так важны, как пароли.

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

  • Администратор istrator должны регулярно проверять все PAT с помощью ИНТЕРФЕЙСы REST API и отменяют все, которые не соответствуют приведенным выше критериям.

  • Сохраняйте секрет PATS. Ваши маркеры так же важны, как пароли.

  • Храните маркеры в безопасном месте.

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

  • Присвойте маркерам дату окончания срока действия.

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

Защита Azure Artifacts

Защита Azure Boards

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

Политики

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

Агенты

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

Определения

  • Управление определениями конвейера с помощью YAML (еще один язык разметки). YAML — это предпочтительный метод для управления определениями конвейеров, так как он обеспечивает трассировку изменений и может следовать рекомендациям по утверждению.
  • Защита доступа к минимальному количеству учетных записей для определения конвейера.

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

  • Включите в скрипты сборки проверка sanity для переменных. Проверка разумности может снизить атаки на внедрение команд с помощью переменных набора.
  • Задайте как можно меньше переменных сборки "Settable во время выпуска".

Задачи

  • Избегайте удаленного получения ресурсов, но при необходимости используйте управление версиями и хэш-проверка.
  • Не регистрайте секреты.
  • Не сохраняйте секреты в переменных конвейера, используйте Azure Key Vault. Регулярно сканируйте конвейеры сборки, чтобы убедиться, что секреты не хранятся в переменных конвейера сборки.
  • Не позволяйте пользователям запускать сборки в произвольных ветвях или тегах в критически важных для безопасности конвейерах.
  • Отключите наследование в конвейере, так как унаследованные разрешения являются широкими и не точно отражают потребности в разрешениях.
  • Ограничение авторизации задания область во всех случаях.

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

  • Задайте для политики "Требовать минимальное количество рецензентов", чтобы каждый запрос на вытягивание проверялся по крайней мере двумя утверждающими.
  • Настройте политики безопасности, относящиеся к каждому репозиторию или ветви, вместо расширения проекта. Политики безопасности снижают риск, применяют стандарты управления изменениями и улучшают качество кода вашей команды.
  • Храните секреты рабочей среды в отдельном хранилище ключей и убедитесь, что доступ предоставляется только на основе необходимости знать, чтобы непроизводственные сборки были разделены.
  • Не смешивайте тестовые среды с рабочей средой, включая использование учетных данных.
  • Отключите вилку. Чем больше вилок есть, тем труднее следить за безопасностью каждого вилки. Кроме того, пользователь может легко вставить копию репозитория в собственную частную учетную запись.
  • Не предоставляйте секреты для вилки сборок.
  • Рекомендуется вручную активировать сборки вилки.
  • Используйте размещенные корпорацией Майкрософт агенты для сборки вилки.
  • Для Git проверка определения рабочей сборки в репозитории git проекта, чтобы их можно было сканировать для учетных данных.
  • Настройте элемент управления ветвью проверка, чтобы использовать только конвейеры, выполняемые в контексте production ветвиprod-connection.
  • Дополнительные сведения см. в разделе "Другие вопросы безопасности".

Защита Azure Repos

Защита Azure Test Plans

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

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