Сведения о разрешениях и группах безопасности

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

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

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

Уровни доступа

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

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

Чтобы предоставить пользователю доступ к функциям управления портфелями Agile или тестовых вариантов, измените уровни доступа, а не разрешения. Дополнительные сведения см. в разделе "О уровнях доступа".

Разрешения

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

• Члены группы безопасности наследуют разрешения, назначенные группе.
• Разрешения определяются на разных уровнях: организация или коллекция, проект или объект.
• Другие разрешения управляются с помощью назначений на основе ролей, таких как администратор группы, управление расширениями и различные роли ресурсов конвейера.
• Администратор istrator может определять пользовательские группы безопасности для управления разрешениями для различных функциональных областей.

Когда дело доходит до управления разрешениями в Azure DevOps, существует две ключевые группы: коллекции проектов Администратор istrators и Project Администратор istrator. Давайте разберемся:

Администратор истаторы коллекции проектов:

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

Администратор истаторы проекта:

• Проектные Администратор istrator работают на уровне проекта.
• Они управляют группами безопасности и разрешениями в основном с параметров проекта веб-портала.
• Участники, с другой стороны, обрабатывают разрешения для определенных объектов, которые они создают в проекте.

Состояния разрешений

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

У пользователя или группы есть разрешения на выполнение задачи:

• Разрешить
• Разрешить (наследуется)
• Разрешить (система)

У пользователя или группы нет разрешения на выполнение задачи:

• Запретить
• Запрет (унаследованный)
• Запрет (система)
• Не задано

Состояние разрешения	Description
Разрешить	Явным образом предоставляет пользователям возможность выполнять определенные задачи и не наследуется от членства в группах.
Разрешить (наследуется)	Предоставляет членам группы выполнение определенных задач.
Разрешить (система)	Предоставляет разрешение, которое имеет приоритет перед разрешениями пользователей. Невидимый и сохраненный в базе данных конфигурации невидимый для пользователей.
Запретить	Явным образом ограничивает пользователей выполнение конкретных задач и не наследуется от членства в группах. Для большинства групп и почти всех разрешений запрет переопределяет разрешить. Если пользователь принадлежит двум группам, а у одного из них есть определенный набор разрешений для запрета, этот пользователь не может выполнять задачи, требующие разрешения, даже если они принадлежат группе с таким разрешением, для которой задано значение Allow.
Запрет (унаследованный)	Ограничивает выполнение определенных задач участниками группы. Переопределяет явное разрешение.
Запрет (система)	Ограничивает разрешение, которое имеет приоритет перед разрешениями пользователей. Невидимый и сохраненный в базе данных конфигурации невидимый для пользователей.
Не задано	Неявно запрещает пользователям возможность выполнять задачи, требующие этого разрешения, но разрешает членство в группе, которая имеет это разрешение на приоритет, также известное как Allow (унаследованное) или Deny (наследуемое).

В некоторых случаях члены группы Администратор istrator или Team Foundation Администратор istrators могут всегда получать разрешение, даже если они отказано в этом разрешении в другой группе. В других случаях, таких как удаление рабочих элементов или конвейеров, член группы Администратор istratorов коллекции проектов не обходит запретить разрешения, заданные в другом месте.

Предупреждение

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

Наследование разрешений

Разрешения следуют иерархии, разрешая наследование от родительского или переопределяя.

• Наследование групп: пользователи наследуют разрешения от групп, к которому они принадлежат. Если у пользователя есть разрешение "Разрешить" непосредственно или через членство в группах, но также есть разрешение "Запретить" через другую группу, разрешение "Запрет" имеет приоритет. Однако члены коллекции проектов Администратор istrator или Team Foundation Администратор istrator сохраняют большинство разрешенных разрешений, даже если они принадлежат другим группам, которые запрещают эти разрешения (за исключением операций рабочих элементов).
• Наследование на уровне объекта: разрешения на уровне объекта (назначенные узлам, таким как области, итерации, папки управления версиями и папки запросов рабочих элементов) наследуются по иерархии.

Например, давайте разберем правила наследования разрешений и помните, что явные разрешения всегда имеют приоритет над унаследованными:

• Если разрешения пользователя задаются на узле более высокого уровня (область-1), эти разрешения наследуются всеми поднодами (area-1/sub-area-1), если явно не переопределяется.
• Если разрешение не разрешено или запрещено для поднодера, оно наследует разрешение от родительского элемента.
• Однако если разрешение явно задано для подноды (area-1/sub-area-1), разрешение родительского объекта не наследуется независимо от того, разрешено ли или запрещено. Специфика:
• В иерархии объектов специфика является наследованием. Это означает, что если существуют конфликтующие разрешения, наиболее конкретные разрешения имеют приоритет.
• Например, рассмотрим пользователя:
  • Явным образом запретить на "area-1" (родительский узел).
  • Явным образом разрешить "area-1/sub-area-1" (дочерний узел).
• В этом случае пользователь получает разрешение на "area-1/sub-area-1", переопределяя унаследованный запрет от родительского узла.

Чтобы понять, почему наследуется разрешение, можно приостановить настройку разрешений, а затем выбрать "Почему?" Чтобы открыть страницу "Безопасность ", см . статью "Просмотр разрешений".

Примечание.

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

Страница предварительного просмотра

Откроется новое диалоговое окно, в котором отображаются сведения о наследовании для этого разрешения.

Текущая страница

В новом окне отображаются сведения о наследовании для этого разрешения.

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

Группы безопасности назначают определенные разрешения своим членам.

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

• При создании пользовательских групп безопасности на следующих уровнях:
  • Уровень проекта
  • Уровень организации или коллекции
  • Уровень сервера (только в локальной среде)
• При добавлении команды создается группа безопасности группы

Нельзя создать группу безопасности уровня объекта, но можно назначить настраиваемую группу на уровне объекта и назначить разрешения на этот уровень. Дополнительные сведения см. в разделе "Настройка разрешений на уровне объекта".

Группы безопасности по умолчанию

Большинство пользователей Azure DevOps добавляются в группу безопасности участников и предоставляют базовый уровень доступа. Группа участников предоставляет доступ для чтения и записи к репозиториям , отслеживанию работы, конвейерам и т. д. Базовый доступ предоставляет доступ ко всем функциям и задачам для использования Azure Boards, Azure Repos, Azure Pipelines и Артефактов Azure. Пользователям, которым требуется доступ к управлению планами тестирования Azure, необходимо предоставить базовые и тестовые планы или расширенный доступ.

Следующие группы безопасности определяются по умолчанию для каждого проекта и организации. Обычно пользователи или группы добавляются в группы читателей, участников или проектов Администратор istrator.

Project	Организация или коллекция
— сборка Администратор istrators -Участников — Администратор истаторы проекта — Допустимые пользователи проекта -Читателей — выпуски Администратор istrator - Команда TeamName	— коллекции проектов Администратор istrator — сборщики сборок проекта Администратор istrator — Учетные записи службы сборки сборок проектов — Учетные записи службы прокси-службы коллекции проектов — Учетные записи службы сбора проектов — Учетные записи службы тестирования коллекции проектов — Допустимые пользователи коллекции проектов — Пользователи с область проекта — Группа служб безопасности

Описание каждой из этих групп см. в разделе "Группы безопасности", учетные записи служб и разрешения. Сведения о назначениях разрешений по умолчанию, сделанных в наиболее распространенных группах безопасности по умолчанию, см. в разделе "Разрешения по умолчанию" и "Доступ".

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

Для пользователей, которым требуется управлять функциями организации или уровня коллекции( например, проектами, политиками, процессами, политиками хранения, пулами агентов и пулами развертывания и расширениями), добавьте их в группу Администратор istratorов коллекции проектов. Дополнительные сведения см. в разделе "Сведения о пользователях, команде, проекте и параметрах уровня организации".

Членство, разрешение и управление уровнем доступа

Azure DevOps управляет доступом с помощью следующих трех взаимосвязанных функциональных областей:

• Управление членством поддерживает добавление отдельных учетных записей пользователей и групп Windows в группы безопасности по умолчанию. Каждая группа по умолчанию связана с набором разрешений по умолчанию. Все пользователи, добавленные в любую группу безопасности, добавляются в группу допустимых пользователей. Допустимый пользователь — это любой пользователь, который может подключаться к проекту, коллекции или организации.
• Управление разрешениями контролирует доступ к определенным функциональным задачам на различных уровнях системы. Разрешения на уровне объекта задают разрешения для файла, папки, конвейера сборки или общего запроса. Параметры разрешений соответствуют параметру Allow, Deny, Inherited allow, Inherited allow, System Allow, System Deny, System Deny и Not Set.
• Управление уровнем доступа управляет доступом к функциям веб-портала. На основе приобретенных для пользователя администраторы устанавливают уровень доступа пользователя к заинтересованным лицам, basic, Basic+ Test или Visual Studio Enterprise (ранее Advanced).

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

Членами группы безопасности могут быть пользователи, другие группы и группы Microsoft Entra в произвольных комбинациях.

Группы безопасности Active Directory и Microsoft Entra

Группы безопасности можно заполнить, добавив отдельных пользователей. Но для удобства управления более эффективно заполнять эти группы с помощью идентификатора Microsoft Entra для Azure DevOps Services и Active Directory (AD) или групп пользователей Windows для Azure DevOps Server. Такой подход позволяет эффективнее управлять членством в группах и разрешениями на нескольких компьютерах.

Если вам нужно управлять только небольшим набором пользователей, этот шаг можно пропустить. Но если вы ожидаете, что ваша организация может расти, рассмотрите возможность настройки Идентификатора Active Directory или Microsoft Entra. Кроме того, если вы планируете использовать дополнительные службы, необходимо настроить идентификатор Microsoft Entra для использования с Azure DevOps для поддержки выставления счетов.

Примечание.

Без идентификатора Microsoft Entra все пользователи Azure DevOps должны войти с помощью учетных записей Майкрософт и управлять доступом к учетной записи с помощью отдельных учетных записей пользователей. Даже если вы управляете доступом к учетной записи Майкрософт, настройте подписку Azure для управления выставлением счетов.

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

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

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

• Добавляйте или удаляйте пользователей, используя Microsoft Entra ID
• Устранение неполадок с доступом с помощью идентификатора Microsoft Entra

Azure DevOps регистрирует изменения, внесенные в группу Microsoft Entra в течение часа после этого изменения в идентификаторе Microsoft Entra. Все унаследованные разрешения через членство в группах обновляются. Чтобы обновить членство в Microsoft Entra и унаследованные разрешения в Azure DevOps, выйдите и войдите в систему или активируйте обновление, чтобы повторно оценить свое разрешение.

Допустимые группы пользователей

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

• Допустимые пользователи в коллекции проектов: все участники, добавленные в группу уровня организации.
• Допустимые пользователи проекта: все участники, добавленные в группу уровня проекта.

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

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

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

Группа пользователей project-область

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

Внимание

• Функции ограниченной видимости, описанные в этом разделе, применяются только к взаимодействиям через веб-портал. С помощью команд REST API или azure devops CLI члены проекта могут получить доступ к ограниченным данным.
• Гостевые пользователи, являющиеся членами ограниченной группы с доступом по умолчанию в идентификаторе Microsoft Entra ID, не могут искать пользователей с помощью средства выбора людей. Если функция предварительной версии отключена для организации или когда гостевые пользователи не являются членами ограниченной группы, гостевые пользователи могут выполнять поиск всех пользователей Microsoft Entra, как ожидалось.

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

Предупреждение

Если для организации включена функция "Ограничить видимость пользователей и совместная работа с определенными проектами", пользователи область проекта не могут искать пользователей, которые были добавлены в организацию через членство в группах Microsoft Entra, а не через явное приглашение пользователя. Это непредвиденное поведение, и решение работает. Чтобы самостоятельно устранить эту проблему, отключите функцию ограничения видимости пользователей и совместной работы в определенных проектах предварительной версии для организации.

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

Примечание.

Группы безопасности относятся к уровню организации, даже если они обращаются только к конкретному проекту. Некоторые группы могут быть скрыты на веб-портале в зависимости от разрешений пользователя. Все имена групп можно найти в организации с помощью средства командной строки Azure devops или интерфейсов REST API. Дополнительные сведения см. в разделе "Добавление групп безопасности и управление ими".

Разрешения на основе ролей

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

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

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

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

Члены групп Администратор istrator или Project Collection Администратор istrators могут управлять всеми средствами команды для всех команд.

Рекомендации по разрешениям

Сделайте следующее:

• Используйте идентификатор Microsoft Entra, Active Directory или группы безопасности Windows при управлении большим количеством пользователей.
• При добавлении команды рассмотрите разрешения, которые необходимо назначить участникам группы, мастерам scrum и другим участникам команды. Рассмотрим, кто создает и изменяет пути к областям, пути итерации и запросы.
• При добавлении многих команд рассмотрите возможность создания настраиваемой группы Администратор istrators, где можно выделить подмножество разрешений, доступных для проектов Администратор istrator.
• Рекомендуется предоставить папкам запросов рабочих элементов разрешение на участие пользователей или групп, которым требуется возможность создавать и совместно использовать запросы рабочих элементов для проекта.

Не делайте следующего:

• Не добавляйте пользователей в несколько групп безопасности, которые содержат разные уровни разрешений. В некоторых случаях уровень разрешений "Запретить " может переопределить уровень разрешений Allow .
• Не изменяйте назначения по умолчанию, внесенные в группы допустимых пользователей. Если вы удаляете или задаете разрешение "Просмотр сведений на уровне экземпляра", чтобы запретить для одной из групп допустимых пользователей, пользователи в группе не смогут получить доступ к проекту, коллекции или развертыванию в зависимости от заданной группы.
• Не назначайте разрешения, которые отмечены как "Назначение только учетным записям служб" учетным записям пользователей.

Предварительная версия функций

Флаги функций управляют доступом к выбору, новым функциям. Периодически Azure DevOps предоставляет новые функции, помещая их за флагом функции. Участники проекта и владелец организации могут включать или отключать предварительные версии функций. Дополнительные сведения см. в разделе "Управление и включение функций".

Следующие шаги

Разрешения и доступ по умолчанию

Связанные статьи

• Устранение неполадок с доступом и разрешениями
• Сведения о безопасности, проверке подлинности и авторизации
• Справочник по разрешениям и группам
• Средства управления безопасностью и разрешениями
• Добавление групп безопасности и управление ими