Условный доступ: целевые ресурсы

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

• Администраторы могут выбирать из списка приложений или служб, которые включают встроенные приложения Майкрософт и любые интегрированные приложения Microsoft Entra, включая галерейные, не галерейные приложения и приложения, опубликованные с помощью Application Proxy.
• Администраторы могут выбрать определение политики не на основе облачного приложения, а на действиях пользователя, таких как Регистрация сведений о безопасности или регистрация или присоединение устройств, что позволяет условному доступу применять элементы управления вокруг этих действий.
• Администраторы могут нацеливать профили перенаправления трафика из системы Global Secure Access для обеспечения расширенной функциональности.
• Администраторы могут использовать контекст проверки подлинности для обеспечения дополнительного уровня безопасности внутри приложений.

Облачные приложения Майкрософт

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

Администраторы могут назначать политику условного доступа этим облачным приложениям Майкрософт. Некоторые приложения, такие как Office 365 и API управления службами Windows Azure, включают несколько связанных приложений или служб.

Внимание

Приложения, доступные для условного доступа, проходят процесс подключения и проверки. Эти приложения не включают все приложения Майкрософт. Многие приложения — это серверные службы, которые не предназначены для непосредственного применения политики к ним. Если вы ищете отсутствующее приложение, вы можете обратиться к группе конкретного приложения или создать запрос на UserVoice.

Office 365

Microsoft 365 предоставляет облачные службы для повышения производительности и совместной работы, такие как Exchange, SharePoint и Microsoft Teams. Облачные службы Microsoft 365 тесно интегрированы, что позволяет организовать беспроблемное взаимодействие и совместную работу. Такая интеграция может приводить к путанице при создании политик, так как Microsoft Teams и некоторые другие приложения имеют зависимости от SharePoint, Exchange и т. д.

Пакет Office 365 позволяет выбрать одновременно все такие службы. Мы рекомендуем использовать новый пакет Office 365, а не отдельные облачные приложения, так как это позволит сразу избежать всех проблем с зависимостями служб.

Целевой выбор этой группы приложений помогает избежать проблем, которые могут возникнуть из-за непоследовательных политик и зависимостей. Например, приложение Exchange Online привязано к традиционным данным Exchange Online, таким как почта, календарь и контактная информация. Связанные метаданные могут предоставляться с помощью различных ресурсов, таких как поиск. Чтобы обеспечить надлежащую защиту всех метаданных, администраторы должны назначить политики для приложения Office 365.

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

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

API управления службами Windows Azure

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

• Azure Resource Manager
• Портал Azure, в состав которого также входит центр администрирования Microsoft Entra.
• Azure Data Lake
• API для Application Insights
• API для аналитики логов

Так как политика применяется к порталу управления Azure и API, любые службы или клиенты, зависящие от API Azure, могут быть косвенно затронуты. Например:

• Azure CLI
• Портал Фабрики данных Azure
• Azure DevOps
• Центры событий Azure
• Azure PowerShell
• Служебная шина Azure
• База данных SQL Azure
• Azure Synapse
• API классической модели развертывания
• Центр администрирования Microsoft 365
• Microsoft IoT Central
• Управляемый экземпляр SQL
• Портал администрирования для подписок Visual Studio

Примечание.

Приложение API управления службами Windows Azure применяется к Azure PowerShell, которое вызывает API Azure Resource Manager. Он не применяется к Microsoft Graph PowerShell, который вызывает API Microsoft Graph.

Дополнительные сведения о настройке образца политики для приложения "API управления службами Windows Azure" см. в разделе Условный доступ: запрос на MFA для управления Azure.

Совет

Для Azure для государственных организаций следует ориентироваться на приложение API "Управление облаком Azure для государственных организаций".

Порталы администрирования Microsoft

Если политика условного доступа предназначена для облачного приложения порталов администрирования Microsoft, политика применяется для маркеров, выданных идентификаторам приложений на следующих административных порталах Microsoft:

• Портал Azure
• Центр администрирования Exchange
• Центр администрирования Microsoft 365
• Портал Microsoft 365 Defender
• Центр администрирования Microsoft Entra
• Центр администрирования Microsoft Intune
• Портал соответствия требованиям Microsoft Purview
• Центр администрирования Microsoft Teams

Мы постоянно добавляем в список дополнительные административные порталы.

Примечание.

Приложение "Порталы администрирования Майкрософт" применяется только к интерактивным входам на перечисленные порталы администрирования. Входы в базовые ресурсы или службы, такие как API Microsoft Graph или Azure Resource Manager, не охватываются этим приложением. Эти ресурсы защищены приложением API управления службами Windows Azure. Эта группировка позволяет клиентам перемещаться по пути внедрения MFA для администраторов, не влияя на автоматизацию, которая зависит от API и PowerShell. Когда вы будете готовы, корпорация Майкрософт рекомендует использовать политику, требующую от администраторов, всегда выполнять многофакторную проверку подлинности для комплексной защиты.

Другие приложения

Администраторы могут добавить в политики условного доступа любое зарегистрированное приложение Microsoft Entra. Эти приложения могут включать:

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

Примечание.

Поскольку политика условного доступа задает требования для доступа к службе, вы не можете применить его к клиентскому (общедоступному или собственному) приложению. Другими словами, политика не устанавливается непосредственно в клиентском (общедоступном или собственном) приложении, но применяется при вызове клиентом службы. Например, набор политик в службе SharePoint применяется ко всем клиентам, вызывающим SharePoint. Политика, заданная для Exchange, применяется к любой попытке доступа к электронной почте из клиента Outlook. Поэтому клиентские (общедоступные или собственные) приложения недоступны для выбора в селекторе приложений, а также параметры Условного доступа недоступны в настройках приложения для клиентского (общедоступного или собственного) приложения, зарегистрированного в вашем арендаторе.

Некоторые приложения вообще не отображаются в средстве выбора. Единственным способом включения этих приложений в политику условного доступа является включение всех ресурсов (ранее "Все облачные приложения").

Общие сведения об условном доступе для различных типов клиентов

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

• Общедоступный клиент
  • Общедоступные клиенты — это те, которые работают локально на таких устройствах, как Microsoft Outlook на настольных компьютерах или мобильных приложениях, таких как Microsoft Teams.
  • Политики условного доступа не применяются к самому общедоступному клиенту, но применяются на основе ресурсов, запрошенных общедоступными клиентами.
• Конфиденциальный клиент
  • Условный доступ применяется к ресурсам, запрашиваемым клиентом, и самому конфиденциальному клиенту, если он запрашивает маркер идентификатора.
  • Например, если Outlook Web запрашивает токен для областей Mail.Read и Files.Read, условный доступ применяет политики для Exchange и SharePoint. Кроме того, если Outlook Web запрашивает токен идентификации, условный доступ применяет политики для Outlook Web.

Чтобы просмотреть журналы входа для этих типов клиентов из Центра администрирования Microsoft Entra:

1. Войдите в Центр администрирования Microsoft Entra как минимум с правами Просмотрщика отчетов.
2. Перейдите к Идентификация>Мониторинг и работоспособность>Журналы входа.
3. Добавьте фильтр для типа учетных данных клиента.
4. Настройте фильтр, чтобы просмотреть определенный набор журналов на основе учетных данных клиента, используемых в входе.

Дополнительные сведения см. в статье "Общедоступный клиент" и конфиденциальные клиентские приложения.

Все ресурсы

Применение политики условного доступа ко всем ресурсам (ранее "Все облачные приложения") без исключений приложений приводит к принудительному применению политики для всех запросов маркеров с веб-сайтов и служб, включая профили пересылки трафика глобального безопасного доступа. Этот параметр включает в себя программные приложения, которые не могут быть индивидуально нацелены в политике условного доступа, например, Windows Azure Active Directory (00000002-0000-0000-c000-000000000000).

Внимание

Корпорация Майкрософт рекомендует создать базовую политику многофакторной проверки подлинности, предназначенную для всех пользователей и всех ресурсов (без исключений приложений), как описано в разделе "Требовать многофакторную проверку подлинности для всех пользователей".

Поведение условного доступа, когда политика для всех ресурсов имеет исключение для приложения

Если любое приложение исключается из политики, чтобы не случайно заблокировать доступ пользователей, некоторые области с низкими привилегиями исключены из применения политики. Эти области позволяют вызывать базовые API Graph, например Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) и Microsoft Graph (00000003-0000-0000-c000-000000000000), для доступа к данным профиля пользователя и членства в группах, часто используемых приложениями в рамках проверки подлинности. Например, когда Outlook запрашивает маркер для Exchange, он также запрашивает User.Read область для отображения основных сведений об учетной записи текущего пользователя.

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

• Встроенные клиенты и одностраничные приложения имеют доступ к следующим сферам с низким уровнем привилегий:
  • Azure AD Graph: email, offline_access, openid, profile, User.Read
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read
• Конфиденциальные клиенты имеют доступ к следующим областям с низким уровнем привилегий, если они исключены из политики всех ресурсов :
  • Azure AD Graph: email, offline_access, openidprofile, User.Read, User.Read.AllUser.ReadBasic.All
  • Microsoft Graph: email, offline_accessopenidprofileUser.ReadUser.Read.AllUser.ReadBasic.AllPeople.ReadPeople.Read.AllGroupMember.Read.AllMember.Read.Hidden

Дополнительные сведения об указанных областях см. в справочнике по разрешениям Microsoft Graph и областям и разрешениям на платформе удостоверений Майкрософт.

Защита сведений о каталоге

Если рекомендуемая базовая политика MFA без исключений приложений не может быть настроена из-за бизнес-причин, а политика безопасности вашей организации должна включать области, связанные с каталогами с низкими привилегиями (User.Read, User.Read.All, People.Read.AllPeople.ReadGroupMember.Read.AllUser.ReadBasic.All), Member.Read.Hiddenальтернативой является создание отдельной политики Windows Azure Active Directory условного доступа (00000002-00000-0000-c0000-0000000000000). Windows Azure Active Directory (также называемый Azure AD Graph) — это ресурс, представляющий данные, хранящиеся в каталоге, например пользователи, группы и приложения. Ресурс Windows Azure Active Directory включен в все ресурсы, но может быть индивидуально нацелен в политиках условного доступа, используя следующие шаги.

1. Войдите в Центр администрирования Microsoft Entra в качестве администратора определения атрибутов и администратора назначения атрибутов.
2. Перейдите к Защита>Настраиваемые атрибуты безопасности.
3. Создайте новый набор атрибутов и определение атрибутов. Дополнительные сведения см. в разделе "Добавление или отключение определений настраиваемых атрибутов безопасности" в идентификаторе Microsoft Entra.
4. Перейдите к Identity>Приложения>Корпоративные приложения.
5. Удалите фильтр типа приложения и найдите идентификатор приложения , который начинается с 00000002-0000-0000-c000-0000000000000000000.
6. Выберите Windows Azure Active Directory>настраиваемые атрибуты безопасности>Добавить назначение.
7. Выберите набор атрибутов и значение атрибута, которое планируется использовать в политике.
8. Перейдите к Защита>Условный доступ>Политики.
9. Создайте или измените существующую политику.
10. В разделе Целевые ресурсы>Ресурсы (ранее облачные приложения)>Включите, выберите >Выбрать ресурсы>Редактировать фильтр.
11. Настройте фильтр, чтобы включить набор атрибутов и определение из более ранних версий.
12. Сохранение политики

Все интернет-ресурсы с глобальным безопасным доступом

Опция «Глобальный безопасный доступ для всех интернет-ресурсов» позволяет администраторам нацеливаться на профиль перенаправления интернет-трафика из Microsoft Entra Internet Access.

Эти профили в Global Secure Access позволяют администраторам определять и контролировать маршрутизацию трафика через Интернет-доступ Microsoft Entra и Частный доступ Microsoft Entra. Профили пересылки трафика можно назначать устройствам и удаленным сетям. Пример применения политики условного доступа к этим профилям трафика см. в статье "Применение политик условного доступа к профилю трафика Microsoft 365".

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

Действия пользователя

Действия пользователей — это задачи, выполняемые пользователем. В настоящее время условный доступ поддерживает два действия пользователя.

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

Примечание.

Если администраторы применяют политику, предназначенную для действий пользователей, чтобы зарегистрировать сведения о безопасности, и если учетная запись пользователя является гостем из личной учетной записи Майкрософт (MSA), при использовании контроля "Требовать многофакторную аутентификацию", пользователю MSA потребуется зарегистрировать сведения о безопасности в организации. Если гостевой пользователь находится у другого поставщика, например Google, доступ блокируется.

• Регистрация или присоединение устройств. Это действие пользователя позволяет администраторам применять политику условного доступа при регистрации или присоединении устройств к идентификатору Microsoft Entra. Она обеспечивает детализацию при настройке многофакторной проверки подлинности для регистрации или присоединения устройств вместо политики на уровне клиента, которая в настоящее время существует. В этом действии пользователя рассматриваются три основных аспекта:
  • Require multifactor authentication доступен только для контроля доступа с этим действием пользователя, и все остальные отключены. Это ограничение предотвращает конфликты с элементами управления доступом, которые зависят от регистрации устройства Microsoft Entra или не применимы к регистрации устройств Microsoft Entra.
  • Client apps, Filters for devicesи Device state условия недоступны для этого действия пользователя, так как они зависят от регистрации устройства Microsoft Entra для принудительного применения политик условного доступа.

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

Если политика условного доступа настроена с помощью действия пользователя "Регистрация или присоединение устройств", необходимо задать Удостоверения>Устройства>Обзор>Параметры устройств - Require Multifactor Authentication to register or join devices with Microsoft Entra в значение Нет. В противном случае политики условного доступа с этим действием пользователя не применяются должным образом. Дополнительные сведения об этом параметре устройства можно найти в окне Настройка параметров устройства.

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

Контекст проверки подлинности можно использовать для дополнительной защиты данных и действий в приложениях. Эти приложения могут быть собственными пользовательскими приложениями, настраиваемыми бизнес-приложениями, такими приложениями, как SharePoint, или приложениями, защищаемыми Microsoft Defender for Cloud Apps.

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

Контекст аутентификации работает с пользователями или идентификациями рабочих нагрузок, но не в одной и той же политике условного доступа.

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

Контексты проверки подлинности управляются в разделе Защита>Условный доступ>Контекст проверки подлинности.

Создайте новые определения контекста проверки подлинности, выбрав новый контекст проверки подлинности. Организации ограничены в общей сложности 99 определений контекста проверки подлинности c1-c99. Настройте следующие атрибуты:

• Отображаемое имя — это имя, которое используется для идентификации контекста проверки подлинности в Microsoft Entra ID и в приложениях, применяющих их. Мы рекомендуем использовать имена, которые можно использовать в ресурсах, например доверенных устройствах, чтобы уменьшить количество необходимых контекстов проверки подлинности. Ограниченный набор уменьшает количество перенаправлений и обеспечивает лучший пользовательский опыт.
• Описание содержит дополнительные сведения о политиках, используемых администраторами и применением контекстов проверки подлинности к ресурсам.
• Если установлен флажок Публикация в приложениях, контекст проверки подлинности объявляется приложениям и делается доступным для назначения. Если не проверен контекст проверки подлинности недоступен для подчиненных ресурсов.
• Параметр Идентификатор доступен только для чтения и используется в токенах и приложениях для определений контекста проверки подлинности для конкретного запроса. Приведено здесь для устранения неполадок и сценариев использования в разработке.

Добавьте в политику условного доступа.

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

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

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

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

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

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

• Использование меток конфиденциальности для защиты содержимого в Microsoft Teams, группах Microsoft 365 и на сайтах SharePoint
• Microsoft Defender for Cloud Apps
• Пользовательские приложения

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

• Условный доступ. Условия
• Распространенные политики условного доступа
• Зависимости клиентского приложения