Изменение политик подключения и безопасности приложений для вашей организации

Важно!

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

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

Необходимые компоненты

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

Управление политикой

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

  1. Войдите в свою организацию (https://dev.azure.com/{yourorganization}).

  2. Выберите gear iconПараметры организации.

    Screenshot of Organization settings button, preview page.

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

Screenshot of select policy, and then turn On or Off.

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

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

  • OAuth для создания маркеров для доступа к REST API для Azure DevOps. Все интерфейсы REST API принимают маркеры OAuth, и это предпочтительный метод интеграции с личными маркерами доступа (PATs). API управления организациями, профилями и PAT поддерживают только OAuth.

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

  • PaTs для создания маркеров для:

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

По умолчанию ваша организация предоставляет доступ ко всем методам проверки подлинности.

Доступ к ключам OAuth и SSH можно ограничить, отключив доступ к этим политикам подключения приложения:

  • Стороннее приложение через OAuth — предоставление сторонним приложениям доступа к ресурсам в организации через OAuth. Эта политика по умолчанию отключена для всех новых организаций. Если вы хотите получить доступ к сторонним приложениям, включите эту политику, чтобы эти приложения могли получить доступ к ресурсам в вашей организации.
  • Проверка подлинности SSH— включение подключения приложений к репозиториям Git организации через SSH.

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

Чтобы удалить доступ для PATs, их необходимо отозвать.

Политики условного доступа

Идентификатор Microsoft Entra позволяет клиентам определять, какие пользователи могут получить доступ к ресурсам Майкрософт с помощью функции политики условного доступа (CAP). С помощью этих параметров администратор клиента может требовать, чтобы члены должны соответствовать любому из следующих условий, например пользователю:

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

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

Поддержка CAP в Azure DevOps

Если вы войдете на веб-портал организации с поддержкой идентификатора Microsoft Entra, идентификатор Microsoft Entra всегда будет проверка, которые можно перейти вперед, выполнив проверку для всех ЦС, установленных администраторами клиента.

Azure DevOps также может выполнять дополнительную проверку CAP после входа и перехода через Azure DevOps в организации, поддерживаемой идентификатором Microsoft Entra:

  • Если включена политика проверки политики условного доступа IP- адресов, мы будем проверка политики ограждения IP-адресов как в веб-, так и в неинтерактивных потоках, таких как сторонние потоки cient, такие как использование PAT с операциями git.
  • Политики входа также могут применяться для PATs. Использование PATs для вызова идентификатора Microsoft Entra требует, чтобы пользователь придерживался всех установленных политик входа. Например, если политика входа требует, чтобы пользователь входить каждые семь дней, необходимо также войти каждые семь дней, если вы хотите продолжать использовать PATs для выполнения запросов к идентификатору Microsoft Entra.
  • Если вы не хотите применять какие-либо ЦС к Azure DevOps, удалите Azure DevOps в качестве ресурса для CAP. Мы не будем выполнять принудительное применение ЦС организации в Azure DevOps.

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

Условия на основе IP-адресов

Мы поддерживаем политики условного доступа для IP-ограждения как для IPv4, так и для IPv6-адресов. Если вы обнаружите, что ip-адрес IPv6 заблокирован, рекомендуется проверка, чтобы администратор клиента настроил ЦС, которые разрешают доступ к IPv6-адресу. Аналогичным образом он может помочь включить сопоставленный IPv4-адрес для любого адреса IPv6 по умолчанию во всех условиях CAP.

Если пользователи получают доступ к странице входа Microsoft Entra с помощью другого IP-адреса, отличного от используемого для доступа к ресурсам Azure DevOps (обычно с туннелированием VPN), проверка конфигурацию VPN или сетевую инфраструктуру, чтобы убедиться, что все используемые IP-адреса включены в ЦС администратора клиента.