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

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 и политики ветвей

---

Внимание

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. Эти системы интегрируются и используют функции безопасности следующих других систем:

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

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

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

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

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

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

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

• Azure DevOps OAuth для создания маркеров от имени пользователей для доступа к REST API. API учетных записей и профилей поддерживают только OAuth.

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

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

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

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

• Хранилище учетных данных для Azure DevOps.
• Руководство по проверке подлинности.

Авторизация

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

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

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

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

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

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

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

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

Общие

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

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

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

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

• Доступ к сторонним приложениям через OAuth.
• Доступ к проверке подлинности SSH.
• Разрешить общедоступные проекты: при включении пользователи могут создавать общедоступные проекты, которые позволяют немемблеры проекта и пользователей, которые не вошли только для чтения, ограниченный доступ к артефактам и службам проекта. Дополнительные сведения см. в разделе "Сделать проект общедоступным".
• События аудита журнала. Включите возможность отслеживания событий аудита и потоков для вашей организации.
• Включите проверку политики условного доступа (CAP) 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 и политики ветвей

• Настройка параметров и политик репозитория
• Настройка политик ветви
• Настройка политики ветви для внешней службы
• Использование Функций Azure для создания пользовательских политик ветвей

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

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

• Защита Azure Pipelines
• Планирование защиты конвейеров YAML
• Защита репозитория
• Ресурсы конвейера
• Рекомендации по безопасной структуре проектов в конвейере
• Безопасность с помощью шаблонов
• Безопасное использование переменных и параметров в конвейере
• Рекомендации по защите общей инфраструктуры в Azure Pipelines
• Другие вопросы безопасности

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

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

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

• Разрешения и назначения доступа по умолчанию
• Добавляйте или удаляйте пользователей, используя Microsoft Entra ID
• Настройка групп для использования в локальных развертываниях
• Настройка HTTPS с помощью уровня безопасных сокетов (SSL)
• Разрешения и назначения доступа по умолчанию