Поделиться через

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

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

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

Снимок экрана: политика условного доступа и панель целевых ресурсов.

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

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

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
  • 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

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

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

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

Примечание.

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

Некоторые приложения вообще не отображаются в средстве выбора. Единственным способом включения этих приложений в политику условного доступа является включение всех ресурсов (ранее "Все облачные приложения") или добавление отсутствующего субъекта-службы с помощью командлета PowerShell New-MgServicePrincipal или с помощью API Microsoft Graph.

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

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

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

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

  1. Войдите в Центр администрирования Microsoft Entra в качестве не менее чем читателя отчетов.
  2. Перейдите к Entra ID>Мониторинг и здоровье>Журналы входа.
  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, openidprofileUser.Read
    • Microsoft Graph: email, , offline_accessopenidprofile, User.ReadPeople.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, User.ReadBasic.AllPeople.ReadPeople.Read.AllGroupMember.Read.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. Перейдите к Entra ID>настраиваемым атрибутам безопасности.
  3. Создайте новый набор атрибутов и определение атрибутов. Дополнительные сведения см. в разделе "Добавление или отключение определений настраиваемых атрибутов безопасности" в идентификаторе Microsoft Entra.
  4. Перейдите к Entra ID>Корпоративные приложения.
  5. Удалите фильтр типа приложения и найдите идентификатор приложения , который начинается с 00000002-0000-0000-c000-0000000000000000000.
  6. Выберите Windows Azure Active Directory>настраиваемые атрибуты безопасности>Добавить назначение.
  7. Выберите набор атрибутов и значение атрибута, которое планируется использовать в политике.
  8. Перейдите к Entra ID>условного доступа>политикам.
  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 для принудительного применения политик условного доступа.

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

Если политика условного доступа настроена с помощью действия "Регистрация или присоединение устройств", необходимо задать Entra ID Устройства Обзор Параметры устройства в положение "Нет". В противном случае политики условного доступа с этим действием пользователя не применяются должным образом. Дополнительные сведения об этом параметре устройства см. в разделе "Настройка параметров устройства".

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

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

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

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

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

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

Снимок экрана: управление контекстами проверки подлинности.

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

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

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

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

Снимок экрана: добавление контекста проверки подлинности условного доступа в политику

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

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

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

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

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

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