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

Статья
08/13/2024

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

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

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

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

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

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

Удалите неактивных пользователей из учетных записей Майкрософт (MSAs): непосредственно удалите неактивных пользователей из организации при использовании MSAs. Невозможно создавать запросы для рабочих элементов, назначенных удаленным учетным записям MSA.
Отключите или удалите учетные записи пользователей Microsoft Entra: если подключено к идентификатору Microsoft Entra, отключите или удалите учетную запись пользователя Microsoft Entra при сохранении активной учетной записи пользователя Azure DevOps. Это действие позволяет продолжать запрашивать журнал рабочих элементов с помощью идентификатора пользователя Azure DevOps.
Отмена pats пользователей: регулярно просматривайте и отменяйте существующие пользовательские PAT, чтобы обеспечить безопасное управление этими критически важными маркерами проверки подлинности.
Отмена специальных разрешений, предоставленных отдельным пользователям: аудит и отмена всех специальных разрешений, предоставленных отдельным пользователям, чтобы обеспечить соответствие принципу наименьших привилегий.
Переназначьте работу удаленных пользователей: перед удалением пользователей переназначьте рабочие элементы текущим участникам группы, чтобы эффективно распределять нагрузку.

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

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

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

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

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

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

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

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

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

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

Разрешения области

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

Рассмотрите возможность использования субъектов-служб и управляемых удостоверений
Использование личных маркеров доступа (PATS) смешно

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

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

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

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

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

Дополнительные сведения см. в разделе "Управление PATs с помощью политик" для администраторов и использования PATS.

Защита Azure Artifacts

Убедитесь, что вы понимаете разницу между веб-каналами, проектами и администраторами коллекции проектов. Дополнительные сведения см. в разделе "Настройка параметров артефактов Azure".
Задайте разрешения веб-канала.

Защита Azure Boards

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

Политики

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

Агенты

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

Определения

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

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

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

Задачи

Избегайте удаленного получения ресурсов: по возможности избегайте извлечения ресурсов из внешних URL-адресов во время процесса сборки. Если необходимы удаленные ресурсы, используйте проверку версий и хэша, чтобы обеспечить целостность.
Избегайте ведения журнала секретов: никогда не регистрируйте конфиденциальную информацию, например секреты или учетные данные, в журналах сборки, чтобы предотвратить непреднамеренное воздействие и компрометацию безопасности.
Используйте Azure Key Vault для секретов: вместо хранения секретов непосредственно в переменных конвейера используйте Azure 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. Вместо этого создайте выделенные учетные записи служб или используйте учетные записи уровня организации.

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