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

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

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

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


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

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

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

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

Авторизация

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

Политики

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


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

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

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

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

Авторизация

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

Политики

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

Важно!

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

Как наша облачная служба, Azure DevOps Services, так и локальный сервер, Azure DevOps Server, поддерживают проекты разработки программного обеспечения, от планирования до развертывания. Azure DevOps использует платформу Microsoft Azure как инфраструктуру службы и многие службы 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 для поддержки внутренних операций.
  • Агенты заданий: внутренние учетные записи, используемые для выполнения определенных заданий в обычном расписании.
  • Сторонние учетные записи: учетные записи, требующие доступа к веб-перехватчикам, подключениям к службам или другим сторонним приложениям.

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

Примечание.

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

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

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

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

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

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

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

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

  • Личные маркеры доступа для создания маркеров от собственного имени для:

    • доступа к определенным ресурсам или действиям, таким как сборки или рабочие элементы;
    • работы с Xcode, NuGet и другими клиентами, которые используют в качестве базовых учетных данных имена пользователей и пароли и не поддерживают учетную запись Майкрософт, многофакторную проверку подлинности и другие возможности Microsoft Entra.
    • Доступ к Azure DevOps REST API
  • Azure DevOps OAuth для создания маркеров от имени пользователей для доступа к REST API. API учетных записей и профилей поддерживают только OAuth.

  • Проверка подлинности SSH для создания ключей шифрования при использовании Linux, macOS или Windows под управлением Git для Windows, когда нельзя использовать диспетчеры учетных данных Git или личные маркеры доступа для проверки подлинности HTTPS.

  • Субъекты-службы или управляемые удостоверения для создания маркеров Microsoft Entra от имени приложения или службы, которые обычно автоматизируют некоторый рабочий процесс, необходимый для доступа к ресурсам Azure DevOps. Большинство действий, традиционно выполняемых учетной записью службы и PAT, можно выполнить с помощью субъекта-службы или управляемого удостоверения.

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

Дополнительные сведения о хранении учетных данных см. в разделе "Хранилище учетных данных" для Azure DevOps.

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

Авторизация

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

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

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

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

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

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

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

Общие

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

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

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

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

  • Внешний гостевой доступ (только если организация подключена к идентификатору Microsoft Entra ID.): при включении приглашения можно отправлять в учетные записи электронной почты пользователей, которые не являются членами идентификатора Microsoft Entra клиента через страницу "Пользователи ". Дополнительные сведения см. в разделе "Добавление внешних пользователей в организацию".
  • Разрешить администраторам групп и проектов приглашать новых пользователей: только если организация подключена к идентификатору Microsoft Entra. При включении администраторы команд и проектов могут добавлять пользователей на страницу "Пользователи ". Дополнительные сведения см. в разделе "Ограничение новых приглашений пользователей" из проектов и командных Администратор istratorов.
  • Доступ к запросу: только если организация подключена к идентификатору 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

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

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