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

  • Статья

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

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

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

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

В список приложений, из которого вы можете выбрать, входят многие из существующих облачных приложений корпорации 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.

Администратор istrator может исключить весь набор 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 Log Analytics

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

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

Примечание.

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

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

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

Примечание.

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

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

Все облачные приложения

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

В некоторых случаях политика Все облачные приложения может случайно заблокировать доступ пользователей. Эти случаи исключены из области применения политики и включают:

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

  • Вызовы Azure AD Graph и Microsoft Graph для доступа к профилям пользователей, членству в группах и сведениям о отношениях, которые обычно используются приложениями, исключенными из политики. Исключенные область перечислены следующим образом. Для использования этих разрешений приложениями по-прежнему требуется согласие.

    • Для собственных клиентов:
      • Azure AD Graph: электронная почта, offline_access, openid, профиль, User.Read
      • Microsoft Graph: электронная почта, offline_access, openid, профиль, User.Read, Люди. Прочитать
    • Для конфиденциальных и прошедших проверку подлинности клиентов:
      • Azure AD Graph: электронная почта, offline_access, openid, profile, User.Read.All и User.ReadBasic.All
      • Microsoft Graph: электронная почта, offline_access, openid, profile, User.Read.All, User.ReadBasic.All, Люди. Чтение, Люди. Read.All, GroupMember.Read.All, Member.Read.Hidden

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

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

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

Примечание.

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

  • Регистрация или присоединение устройств. Это действие пользователя позволяет администраторам применять политику условного доступа при регистрации или присоединении устройств к идентификатору Microsoft Entra. Она обеспечивает детализацию при настройке многофакторной проверки подлинности для регистрации или присоединения устройств вместо политики на уровне клиента, которая в настоящее время существует. В этом действии пользователя рассматриваются три основных аспекта:
    • Require multifactor authentication доступен только для контроля доступа с этим действием пользователя, и все остальные отключены. Это ограничение предотвращает конфликты с элементами управления доступом, которые зависят от регистрации устройства Microsoft Entra или не применимы к регистрации устройств Microsoft Entra.
    • Client apps, Filters for devicesи Device state условия недоступны для этого действия пользователя, так как они зависят от регистрации устройства Microsoft Entra для принудительного применения политик условного доступа.
    • Если политика условного доступа включена с помощью этого действия пользователя, необходимо задать для устройства>обзора>удостоверений>Параметры - Devices to be Microsoft Entra joined or Microsoft Entra registered require multifactor authentication значение "Нет". В противном случае политика условного доступа с этим действием пользователя будет применена неправильно. Дополнительные сведения об этом параметре устройства можно найти в окне Настройка параметров устройства.

Профили пересылки трафика

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

Дополнительные сведения об этих профилях см. в статье "Глобальный безопасный трафик пересылки трафика".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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