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

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

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

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

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

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

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

Существует три основных уровня доступа: Сотрудник, Базовый и Базовый + планы тестирования.

Доступ к заинтересованным лицам предоставляет бесплатный доступ к неограниченному количеству пользователей с ограниченным набором функций. Используйте этот уровень доступа для пользователей, которым не нужен платный доступ. Не используйте доступ заинтересованных лиц вместо более ограниченных разрешений. Пользователи с подпиской Visual Studio или лицензией GitHub Enterprise автоматически переводятся с уровня доступа заинтресованных сторон на базовый уровень доступа при входе. Дополнительные сведения см. в кратком справочнике по правам доступа для заинтересованных лиц.

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

Разрешения

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

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

Управление разрешениями в Azure DevOps включает две ключевые группы: администраторы коллекции проектов и администраторы проектов.

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

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

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

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

Статусы разрешений

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

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

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

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

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

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

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

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

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

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

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

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

Наследование группы:

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

Наследование на уровне объекта:

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

Правила наследования разрешений и конкретности:

• Явные разрешения всегда имеют приоритет над унаследованными.
• Разрешения, заданные на узле более высокого уровня, наследуются всеми подузлами, если явно не переопределяются.
• Если разрешение явно не разрешено или запрещено для подузла, оно наследует разрешение от родительского узла.
• Если разрешение явно задано для поднодера, разрешение родительского элемента не наследуется независимо от того, разрешено ли или запрещено.

Специфичность:

В иерархии объектов специфика превосходит наследование. Наиболее конкретное разрешение имеет приоритет, если существуют конфликтующие разрешения.

Пример:

• Явно запретить на "area-1" (родительский узел).
• Явным образом разрешить "area-1/sub-area-1" (дочерний узел).
• В этом случае пользователь получает разрешение на "area-1/sub-area-1", переопределяя унаследованный запрет от родительского узла.

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Управление членством поддерживает добавление отдельных учетных записей пользователей и групп Windows в группы безопасности по умолчанию. Каждая группа по умолчанию связана с набором разрешений по умолчанию. Все пользователи, добавленные в любую группу безопасности, добавляются в группу допустимых пользователей. Допустимый пользователь — это любой пользователь, который может подключаться к проекту, коллекции или организации.
• Управление разрешениями контролирует доступ к определенным функциональным задачам на различных уровнях системы. Разрешения на уровне объекта задают разрешения для файла, папки, конвейера сборки или общего запроса. Параметры разрешений соответствуют значениям Разрешить, Запретить, Наследуемое разрешение, Наследуемый запрет, Системное разрешение, Системный запрет и Не установлено.
• Управление уровнем доступа управляет доступом к функциям веб-портала. На основе приобретенного для пользователя администраторы устанавливают уровень доступа пользователя как Участник, Базовый, Базовый + 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, выйдите и войдите в систему или активируйте обновление, чтобы повторно оценить свое разрешение.

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

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

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

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

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

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

Группа пользователей в рамках проекта

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

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

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

При использовании этой функции предварительной версии следует учитывать следующие ограничения:

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

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

Примечание.

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

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

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

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

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

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

Участники групп "Администраторы проектов" или "Администраторы коллекции проектов" могут управлять всеми средствами команды для всех команд.

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

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

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

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

Связанный контент

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