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

Важно!

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

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

Предварительные требования

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

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

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

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

  2. Выберите параметры организации значка шестеренки.

    Снимок экрана: кнопка

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

Снимок экрана: выбор политики, а затем включение или отключение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При входе на веб-портал организации, поддерживаемой Azure AD, Azure AD проверяет, можно ли перейти вперед, проверив все ЦС, заданные администраторами клиентов.

Azure DevOps также может выполнять дополнительную проверку CAP после входа и перехода по Azure DevOps.

  • Если включена политика проверки включения Azure AD CAP, веб-потоки учитываются на 100 % для всех политик условного доступа. Если политика отключена, Azure DevOps не выполняет дополнительную проверку CAP, но Azure AD всегда проверяет наличие ЦС при входе.
  • Для потоков сторонних клиентов, таких как использование PAT с git.exe, мы поддерживаем только политики ограждения IP-адресов. Пользователи могут обнаружить, что политика входа также может применяться для PAT. Использование PAT для Azure AD вызовов требует от пользователя придерживаться всех установленных политик входа. Например, если политика входа требует, чтобы пользователь входить каждые семь дней, необходимо также войти каждые семь дней, если вы хотите продолжать использовать PAT для выполнения запросов к Azure AD.

Для этих сторонних клиентских потоков мы не поддерживаем политики MFA, заданные после проверки CAP. См. следующие примеры.

  • Политика 1. Блокировать доступ из-за пределов диапазона IP-адресов x, y и z.
    • Доступ к Azure DevOps через Интернет, пользователь может получить доступ к IP-адресу x, y и z. Если он не входит в этот список, пользователь заблокирован.
    • Доступ к Azure DevOps с помощью alt-auth, разрешенного пользователю с IP-адреса x, y и z. Если он не входит в этот список, пользователь заблокирован.
  • Политика 2. Требовать многофакторную проверку подлинности при выходе за пределы диапазона IP-адресов x, y и z.
    • Доступ к Azure DevOps через Интернет, пользователь может получить доступ к IP-адресу x, y и z. Пользователю предлагается многофакторная проверка подлинности, если она не входит в этот список.
    • Доступ к Azure DevOps с помощью alt-auth, разрешенного пользователю с IP-адреса x, y и z. Если он не входит в этот список, пользователь заблокирован.

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

Мы поддерживаем политики условного доступа для IP-ограждения как для IPv4-адресов, так и для IPv6-адресов.

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

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