Начало работы с разрешениями и доступом

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

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

  • Сведения о разрешениях:

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

    • Все пользователи, добавленные в Azure DevOps, назначаются уровню доступа, который предоставляет или ограничивает доступ для выбора функций веб-портала.
    • Существует три основных уровня доступа: заинтересованные лица, базовые и базовые планы тестирования.
    • Доступ заинтересованных лиц предоставляет бесплатный доступ к неограниченному количеству пользователей к ограниченному набору функций. Дополнительные сведения см. в кратком справочнике по правам доступа для заинтересованных лиц.
  • О функциях предварительной версии:
    • Как появились новые функции, пользователи могут включить или отключить их с помощью предварительных версий функций для доступа к ним.
    • Небольшое подмножество новых функций управляется на уровне организации и включается или отключается владелец организации.

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

Администраторы должны быть добавлены в группу "Администраторы коллекции проектов" или "Администраторы проектов". Администратор istrators управляют группами безопасности и разрешениями на веб-портале, в основном из Параметры проекта. Участники также управляют разрешениями для объектов, создаваемых на веб-портале.

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

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

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

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

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

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

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

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

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

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

В следующем списке указаны последние группы, определенные для TFS 2017 и более поздних версий. Для более ранних версий Azure DevOps список может отличаться. Добавьте только учетные записи служб в группы учетных записей служб Azure DevOps. Сведения о допустимых группах пользователей см. далее в этой статье.

Уровень проекта Уровень сбора
— сборка Администратор 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 или рабочей группы.

Вы можете создавать локальные группы или группы Active Directory (AD) для управления пользователями.

Группы безопасности 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, ознакомьтесь со следующими статьями:

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

Сведения о настройке Active Directory для использования с Azure DevOps Server см. в следующих статьях:

Установите Active Directory перед установкой Azure DevOps Server.

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

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

  • Допустимые пользователи в коллекции проектов: все участники, добавленные в группу уровня организации.
  • Допустимые пользователи проекта: все участники, добавленные в группу уровня проекта.
  • Server\Azure DevOps Valid Users: все участники, добавленные в группы уровня сервера.
  • ProjectCollectionName\Project Collection Valid Users: все члены, добавленные в группы уровня коллекции.
  • ProjectName\Project Valid Users: все участники, добавленные в группы уровня проекта.
  • Сервер\Team Foundation Допустимые пользователи: все участники, добавленные в группы уровня сервера.
  • ProjectCollectionName\Project Collection Valid Users: все члены, добавленные в группы уровня коллекции.
  • ProjectName\Project Valid Users: все участники, добавленные в группы уровня проекта.

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

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

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

Группа "Пользователи с областью проекта"

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

Важно!

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

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

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

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

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

Примечание.

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

Примечание.

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

Примечание.

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

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

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

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

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

Разрешения

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

Conceptual image mapping default security groups to permission levels, cloud

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

Conceptual image mapping default security groups to permission levels, on-premises

Conceptual image of security groups and permission levels, TFS-2018 and earlier versions

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

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

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

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

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

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

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

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

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

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

Наследование разрешений и группы безопасности

Некоторые разрешения управляются иерархией. В этой иерархии разрешения можно наследовать от родительского или переопределенного. Группы безопасности назначают набор разрешений для этих членов группы. Например, участникам группы "Участники" или группе "Проект" Администратор istrators назначаются разрешения, заданные в качестве разрешенных для этих групп.

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

  • Пользователи наследуют разрешения от групп, к которым они принадлежат. Если у пользователя есть разрешение на прямое или групповое членство в группе, то разрешение на запрет прямого или группового членствапереопределяет его.

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

  • Разрешения на уровне объекта, назначенные узлам иерархии — областям, итерациям, папкам управления версиями, папкам запросов рабочих элементов — наследуются по иерархии. То есть разрешения пользователя, заданные при area-1 получении наследуемогоarea-1/sub-area-1, если одно и то же разрешение не разрешено или запрещено.area-1/sub-area-1 Если разрешение задано явным образом для объекта, например area-1/sub-area-1, родительский узел не наследуется независимо от того, запрещено или разрешено. Если он не задан, разрешения для этого узла наследуются от ближайшего предка, имеющего явно заданные разрешения. Наконец, в иерархии объектов специфика является наследованием. Например, пользователь, разрешения которого явно заданы как "Запретить" для "area-1", но также явно заданы для параметра Allow for "area-1/sub-area-1", получает разрешение на "area-1/sub-area-1".

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

Примечание.

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

Permissions dialog, preview page, Why link annotated.

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

Пользовательский интерфейс предварительной версии страницы параметров разрешений проекта недоступен для Azure DevOps Server 2020 и более ранних версий.

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

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

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

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

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

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

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

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

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

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

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

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