Бөлісу құралы:

Сведения о безопасности, проверке подлинности и авторизации

  • Мақала

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

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

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

Типы учетных записей

  • Пользователи
  • Владелец организации
  • учетные записи служб;
  • Субъекты-службы или управляемые удостоверения
  • Агенты заданий

Аутентификация

  • Учетные данные пользователя
  • Проверка подлинности Windows
  • Двухфакторная проверка подлинности (2FA)
  • Проверка подлинности ключа SSH
  • Личные маркеры доступа
  • Конфигурация Oauth
  • Библиотека проверки подлинности Active Directory

Авторизация

  • Членство в группе безопасности
  • Управление доступом на основе ролей
  • Уровни доступа
  • Флаги функций
  • Пространства имен и разрешения, связанные с безопасностью

Политики

  • URL-адрес политики конфиденциальности
  • Политики подключения и безопасности приложений
  • Политики пользователей
  • Репозиторий Git и политики ветвей

Типы учетных записей

  • Пользователи
  • учетные записи служб;
  • Субъекты-службы или управляемые удостоверения
  • Агенты заданий

Аутентификация

  • Учетные данные пользователя
  • Проверка подлинности Windows
  • Двухфакторная проверка подлинности (2FA)
  • Проверка подлинности ключа SSH
  • Личные маркеры доступа
  • Конфигурация Oauth
  • Библиотека проверки подлинности Active Directory

Авторизация

  • Членство в группе безопасности
  • Разрешения на основе ролей
  • Уровни доступа
  • Флаги функций
  • Пространства имен и разрешения, связанные с безопасностью

Политики

  • Репозиторий Git и политики ветвей

Внимание

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

Azure DevOps Services (облако) и Azure DevOps Server (локальный) поддерживают разработку программного обеспечения от планирования развертывания. Они используют платформу Microsoft Azure как инфраструктуру и службы, включая базы данных SQL Azure, для обеспечения надежной, глобально доступной службы для ваших проектов.

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

Организация

Хотя учетные записи пользователей человека являются основной задачей, Azure DevOps также поддерживает различные другие типы учетных записей для различных операций. К ним относятся следующие типы учетных записей:

  • Владелец организации: создатель организации Azure DevOps Services или назначенный владелец. Чтобы найти владельца вашей организации, ознакомьтесь с владелец организации.
  • Учетные записи служб: внутренняя организация Azure DevOps, используемая для поддержки определенной службы, например службы пула агентов, PipelinesSDK. Описание учетных записей служб см. в разделе "Группы безопасности", "Учетные записи служб" и "Разрешения".
  • Субъекты-службы или управляемые удостоверения: приложения Microsoft Entra или управляемые удостоверения, добавленные в организацию для выполнения действий от имени стороннего приложения. Некоторые субъекты-службы относятся к внутренней организации Azure DevOps для поддержки внутренних операций.
  • Агенты заданий: внутренние учетные записи, используемые для выполнения определенных заданий в обычном расписании.
  • Сторонние учетные записи: учетные записи, требующие доступа к веб-перехватчикам, подключениям к службам или другим сторонним приложениям.

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

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

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

Примечание.

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

Проверка подлинности

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

  • Microsoft Entra ID
  • Учетная запись Майкрософт (MSA)
  • Active Directory (AD)

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

Для локальных развертываний AD рекомендуется управлять большой группой пользователей. Дополнительные сведения см. в разделе "Настройка групп для использования в локальных развертываниях".

Методы проверки подлинности, интеграция с другими службами и приложениями

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

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

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

Авторизация

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

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

Пространства имен безопасности и разрешения

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

  • У каждого семейства ресурсов, например рабочих элементов или репозиториев Git, есть уникальное пространство имен.
  • Каждое пространство имен содержит ноль или несколько списков управления доступом (ACL).
    • Каждый ACL включает маркер, флаг наследования и записи управления доступом (ACEs).
    • Каждый ACE имеет дескриптор удостоверения, разрешенную битовую маску разрешений и битовую маску запрещенных разрешений.

Дополнительные сведения см. в разделе "Пространства имен безопасности" и справочник по разрешениям.

Политики безопасности

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

Общие

Политики подключения и безопасности приложений

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

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

Политики пользователей

  • Внешний гостевой доступ (только если организация подключена к идентификатору Microsoft Entra ID.): при включении приглашения можно отправлять в учетные записи электронной почты пользователей, которые не являются членами идентификатора Microsoft Entra клиента на странице "Пользователи". Дополнительные сведения см. в разделе "Добавление внешних пользователей в организацию".
  • Разрешить администраторам групп и проектов приглашать новых пользователей: только если организация подключена к идентификатору Microsoft Entra. При включении администраторы команд и проектов могут добавлять пользователей на страницу "Пользователи ". Дополнительные сведения см. в разделе "Ограничение новых приглашений пользователей" от администраторов проектов и групп.
  • Доступ к запросу: только если организация подключена к идентификатору Microsoft Entra. При включении пользователи могут запрашивать доступ к ресурсу. Запрос приводит к отправке уведомления по электронной почте администраторам, запрашивающих проверку и доступ по мере необходимости. Дополнительные сведения см. в разделе "Добавление внешних пользователей в организацию".
  • Пригласите пользователей GitHub: только если организация не подключена к идентификатору Microsoft Entra. При включении администраторы могут добавлять пользователей на основе учетных записей пользователей GitHub на странице "Пользователи ". Дополнительные сведения см. в разделе "Подключение к GitHub/часто задаваемые вопросы".

Группа "Пользователи с доступом только к данным проекта"

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

Внимание

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

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

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

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

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

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

Репозиторий Git и политики ветвей

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

Безопасность Azure Repos и Azure Pipelines

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

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

Справочник по разрешениям и группам