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

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

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

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

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

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

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

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

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

Разрешения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Члены групп администраторов коллекции проектов или администраторов 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, необходимо предоставить базовые и тестовые планы или расширенный доступ.

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

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

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

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

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

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

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, выйдите и войдите в систему или активируйте обновление, чтобы повторно оценить свое разрешение.

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

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

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

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

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

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

Группа пользователей с областью действия проекта

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

Внимание

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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