Изменить

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

Инфраструктура гибридного обмена сообщениями с расширенной безопасностью — мобильный доступ

Microsoft Entra ID
Microsoft 365
Office 365

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

Архитектура (Exchange Online)

Схема, на котором показана архитектура для повышения безопасности в сценарии мобильного доступа Outlook. Почтовый ящик пользователя находится в Exchange Online.

В этом сценарии пользователям необходимо использовать мобильный клиент, поддерживающий современную проверку подлинности. Мы рекомендуем Outlook mobile (Outlook для iOS или Outlook для Android), который поддерживается корпорацией Майкрософт. Следующий рабочий процесс использует Outlook Mobile.

Скачайте файл Visio всех схем в этой статье.

Рабочий процесс (Exchange Online)

  1. Пользователь запускает конфигурацию профиля Outlook, введя адрес электронной почты. Outlook mobile подключается к службе Автодетекта.
  2. Служба автообнаружения выполняет анонимный запрос автообнаружения версии 2 в Exchange Online, чтобы получить почтовый ящик. Exchange Online отвечает с ответом перенаправления 302, который содержит URL-адрес ActiveSync для почтового ящика, указывающий на Exchange Online. Пример этого типа запроса можно увидеть здесь.
  3. Теперь, когда служба autoDetect содержит сведения о конечной точке содержимого почтового ящика, она может вызывать ActiveSync без проверки подлинности.
  4. Как описано в потоке подключения, Exchange отвечает на запрос 401. Он содержит URL-адрес авторизации, определяющий конечную точку Microsoft Entra, которую клиент должен использовать для получения маркера доступа.
  5. Служба autoDetect возвращает конечную точку авторизации Microsoft Entra клиенту.
  6. Клиент подключается к идентификатору Microsoft Entra для завершения проверки подлинности и ввода сведений о входе (электронная почта).
  7. Если домен федеративный, запрос перенаправляется на прокси веб-приложения.
  8. Прокси-сервер веб-приложения выполняет запрос проверки подлинности в AD FS. Пользователь видит страницу входа.
  9. Пользователь вводит учетные данные для завершения проверки подлинности.
  10. Пользователь перенаправляется обратно в идентификатор Microsoft Entra.
  11. Идентификатор Microsoft Entra применяет политику условного доступа Azure.
  12. Политика может применять ограничения на основе состояния устройства пользователя, если устройство зарегистрировано в Microsoft Endpoint Manager, применяет политики защиты приложений и (или) применяет многофакторную проверку подлинности. Подробный пример этой политики можно найти в шагах реализации, описанных здесь.
  13. Пользователь реализует все требования политики и завершает запрос многофакторной проверки подлинности.
  14. Идентификатор Microsoft Entra возвращает маркеры доступа и обновления клиенту.
  15. Клиент использует маркер доступа для подключения к Exchange Online и получения содержимого почтового ящика.

Конфигурация (Exchange Online)

Чтобы заблокировать попытки доступа к Exchange Online ActiveSync с помощью устаревшей проверки подлинности (красная дефисовая строка на схеме), необходимо создать политику проверки подлинности, которая отключает устаревшую проверку подлинности для протоколов, используемых мобильной службой Outlook. В частности, необходимо отключить автообнаружения, ActiveSync и службу Outlook. Ниже приведена соответствующая конфигурация политики проверки подлинности:

AllowBasicAuthAutodiscover: False

AllowBasicAuthActiveSync : False

AllowBasicAuthOutlookService : False

После создания политики проверки подлинности ее можно назначить пилотной группе пользователей. Затем после тестирования можно развернуть политику для всех пользователей. Чтобы применить политику на уровне организации, используйте Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> команду. Для этой конфигурации необходимо использовать Exchange Online PowerShell.

Для федеративных доменов можно настроить AD FS для активации многофакторной проверки подлинности вместо использования политики условного доступа. Однако рекомендуется управлять подключением и применять ограничения на уровне политики условного доступа.

Архитектура (локальная среда Exchange)

Схема, на котором показана архитектура для повышения безопасности в сценарии мобильного доступа Outlook. Почтовый ящик пользователя находится в локальной среде Exchange.

Скачайте файл Visio всех схем в этой статье.

В этом сценарии пользователям необходимо использовать мобильный клиент, поддерживающий современную проверку подлинности, как описано в статье "Использование гибридной современной проверки подлинности". Мы рекомендуем Outlook mobile (Outlook для iOS или Outlook для Android), который поддерживается корпорацией Майкрософт. Следующий рабочий процесс использует Outlook Mobile.

Рабочий процесс (локальная среда Exchange)

  1. Пользователь запускает конфигурацию профиля Outlook, введя адрес электронной почты. Outlook mobile подключается к службе Автодетекта.
  2. Служба автообнаружения выполняет анонимный запрос автообнаружения версии 2 в Exchange Online, чтобы получить почтовый ящик.
  3. После того как почтовый ящик находится в локальной среде, Exchange Online отвечает с ответом перенаправления 302, который содержит локальный URL-адрес автообнаружения, который может использовать для получения URL-адреса ActiveSync для почтового ящика.
  4. AutoDetect использует локальный URL-адрес, полученный на предыдущем шаге, чтобы сделать анонимный запрос автообнаружения версии 2 в Локальной среде Exchange для получения почтового ящика. Локальная служба Exchange возвращает URL-адрес ActiveSync для почтового ящика, указывающий на локальную среду Exchange. Пример этого типа запроса можно увидеть здесь.
  5. Теперь, когда служба autoDetect содержит сведения о конечной точке содержимого почтового ящика, она может вызывать локальную конечную точку ActiveSync без проверки подлинности. Как описано в потоке подключения, Exchange отвечает на запрос 401. Он содержит URL-адрес авторизации, определяющий конечную точку Microsoft Entra, которую клиент должен использовать для получения маркера доступа.
  6. Служба autoDetect возвращает конечную точку авторизации Microsoft Entra клиенту.
  7. Клиент подключается к идентификатору Microsoft Entra для завершения проверки подлинности и ввода сведений о входе (электронная почта).
  8. Если домен федеративный, запрос перенаправляется на прокси веб-приложения.
  9. Прокси-сервер веб-приложения выполняет запрос проверки подлинности в AD FS. Пользователь видит страницу входа.
  10. Пользователь вводит учетные данные для завершения проверки подлинности.
  11. Пользователь перенаправляется обратно в идентификатор Microsoft Entra.
  12. Идентификатор Microsoft Entra применяет политику условного доступа Azure.
  13. Политика может применять ограничения на основе состояния устройства пользователя, если устройство зарегистрировано в Microsoft Endpoint Manager, применяет политики защиты приложений и (или) применяет многофакторную проверку подлинности. Подробный пример этой политики можно найти в шагах реализации, описанных здесь.
  14. Пользователь реализует все требования политики и завершает запрос многофакторной проверки подлинности.
  15. Идентификатор Microsoft Entra возвращает маркеры доступа и обновления клиенту.
  16. Клиент использует маркер доступа для подключения к Exchange Online и получения содержимого локального почтового ящика. Содержимое должно быть предоставлено из кэша , как описано здесь. Для этого клиент выдает запрос на подготовку, включающий маркер доступа пользователя и локальную конечную точку ActiveSync.
  17. API подготовки в Exchange Online принимает предоставленный маркер в качестве входных данных. API получает вторую пару маркеров доступа и обновления для доступа к локальному почтовому ящику через вызов Active Directory от имени. Этот второй маркер доступа ограничен клиентом как Exchange Online и аудиторией локальной конечной точки пространства имен ActiveSync.
  18. Если почтовый ящик не подготовлен, API подготовки создает почтовый ящик.
  19. API подготовки устанавливает безопасное подключение к локальной конечной точке ActiveSync. API синхронизирует данные обмена сообщениями пользователя с помощью второго маркера доступа в качестве механизма проверки подлинности. Маркер обновления периодически используется для создания нового маркера доступа, чтобы данные могли синхронизироваться в фоновом режиме без вмешательства пользователя.
  20. Данные возвращаются клиенту.

Конфигурация (локальная среда Exchange)

Чтобы заблокировать попытки доступа к локальной службе Exchange ActiveSync с помощью устаревшей проверки подлинности (красные дефисированные строки на схеме), необходимо создать политику проверки подлинности, которая отключает устаревшую проверку подлинности для протоколов, используемых мобильной службой Outlook. В частности, необходимо отключить автообнаружения и ActiveSync. Ниже приведена соответствующая конфигурация политики проверки подлинности:

BlockLegacyAuthAutodiscover: True

BlockLegacyAuthActiveSync: True

Ниже приведен пример команды для создания этой политики проверки подлинности:

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

После создания политики проверки подлинности вы можете сначала назначить ее пилотной группе пользователей с помощью Set-User user01 -AuthenticationPolicy <name_of_policy> команды. После тестирования можно развернуть политику, чтобы включить всех пользователей. Чтобы применить политику на уровне организации, используйте Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> команду. Для этой конфигурации необходимо использовать Локальную среду Exchange PowerShell.

Кроме того, необходимо выполнить шаги по обеспечению согласованности и разрешить доступ только из клиента Outlook. Чтобы разрешить Outlook mobile в качестве единственного утвержденного клиента в организации, необходимо заблокировать попытки подключения от клиентов, которые не являются мобильными клиентами Outlook, поддерживающими современную проверку подлинности. Чтобы заблокировать эти попытки на локальном уровне Exchange, выполните следующие действия:

  • Блокировать другие клиенты мобильных устройств:

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Разрешить Exchange Online подключаться к локальной среде:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • Блокировать базовую проверку подлинности для Outlook для iOS и Android:

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

Дополнительные сведения об этих шагах см. в статье "Использование гибридной современной проверки подлинности" с Outlook для iOS и Android.

Для федеративных доменов можно настроить AD FS для активации многофакторной проверки подлинности вместо использования политики условного доступа. Однако рекомендуется управлять подключением и применять ограничения на уровне политики условного доступа.

Компоненты

  • Идентификатор Microsoft Entra. Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом Майкрософт. Она обеспечивает современную проверку подлинности, которая, по сути, основана на EvoSTS (службе маркеров безопасности, используемой идентификатором Microsoft Entra). Он используется в качестве сервера проверки подлинности для локальной среды Exchange Server.
  • Многофакторная проверка подлинности Microsoft Entra. Многофакторная проверка подлинности — это процесс, в котором пользователи запрашиваются во время входа в другую форму идентификации, например код на мобильном телефоне или сканирование отпечатков пальцев.
  • Условный доступ Microsoft Entra. Условный доступ — это функция, которую идентификатор Microsoft Entra использует для применения политик организации, таких как многофакторная проверка подлинности.
  • AD FS. AD FS обеспечивает федеративное управление удостоверениями и доступом путем совместного использования цифровых удостоверений и прав на права в пределах безопасности и корпоративных границ с улучшенной безопасностью. В этих архитектурах используется для упрощения входа для пользователей с федеративными удостоверениями.
  • Прокси веб-приложения. Прокси-сервер веб-приложения предварительно проверяет подлинность доступа к веб-приложениям с помощью AD FS. Он также работает в качестве прокси-сервера AD FS.
  • Microsoft Intune. Intune — это облачное управление унифицированных конечных точек, управление конечными точками в операционных системах Windows, Android, Mac, iOS и Linux.
  • Exchange Server. Exchange Server размещает почтовые ящики пользователей в локальной среде. В этих архитектурах используется маркеры, выданные пользователю идентификатором Microsoft Entra, для авторизации доступа к почтовым ящикам.
  • Службы Active Directory. Службы Active Directory хранят сведения о членах домена, включая устройства и пользователей. В этих архитектурах учетные записи пользователей принадлежат службам Active Directory и синхронизируются с идентификатором Microsoft Entra.

Альтернативные варианты

Вы можете использовать сторонние мобильные клиенты, поддерживающие современную проверку подлинности в качестве альтернативы Outlook mobile. Если вы выберете эту альтернативу, сторонний поставщик отвечает за поддержку клиентов.

Подробности сценария

Корпоративная инфраструктура обмена сообщениями (EMI) — это ключевая служба для организаций. Переход от более старых, менее безопасных методов проверки подлинности и авторизации к современной проверке подлинности является критической проблемой в мире, в котором распространена удаленная работа. Реализация требований к многофакторной проверке подлинности для доступа к службе обмена сообщениями является одним из наиболее эффективных способов удовлетворения этой проблемы.

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

Эти сценарии описаны в этой статье:

  • Мобильный доступ Outlook, когда почтовый ящик пользователя находится в Exchange Online
  • Мобильный доступ Outlook, когда почтовый ящик пользователя находится в локальной среде Exchange

Обе архитектуры охватывают Outlook для iOS и Outlook для Android.

Сведения о применении многофакторной проверки подлинности в других сценариях гибридного обмена сообщениями см. в следующих статьях:

В этой статье не рассматриваются другие протоколы, такие как IMAP или POP. Как правило, эти сценарии не используют эти протоколы.

Общие примечания

  • Эти архитектуры используют федеративную модель удостоверений Microsoft Entra. Для синхронизации хэша паролей и моделей сквозной проверки подлинности логика и поток одинаковы. Единственное различие связано с тем, что идентификатор Microsoft Entra id не перенаправляет запрос проверки подлинности на локальная служба Active Directory службы федерации (AD FS).
  • На схемах черные дефисы отображают основные взаимодействия между локальными компонентами Active Directory, Microsoft Entra Connect, Идентификатором Microsoft Entra, AD FS и прокси-сервером веб-приложения. Вы можете узнать об этих взаимодействиях в гибридных удостоверениях, необходимых портам и протоколам.
  • В локальной среде Exchange мы имеем в виду Exchange 2019 с последними обновлениями и ролью почтового ящика.
  • В реальной среде у вас не будет только одного сервера. У вас будет массив серверов Exchange с балансировкой нагрузки для обеспечения высокой доступности. Описанные здесь сценарии подходят для этой конфигурации.

Потенциальные варианты использования

Эта архитектура относится к следующим сценариям:

  • Повышение безопасности EMI.
  • Примите стратегию безопасности нулевого доверия.
  • Примените стандартный высокий уровень защиты для локальной службы обмена сообщениями во время перехода к Exchange Online или сосуществования.
  • Применение строгих требований к безопасности или соответствию требованиям в закрытых или высокозащищенных организациях, таких как в финансовом секторе.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".

Availability

Общая доступность зависит от доступности участвующих компонентов. Сведения о доступности см. в следующих ресурсах:

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

Чтобы использовать гибридную современную проверку подлинности, необходимо убедиться, что все клиенты в сети могут получить доступ к идентификатору Microsoft Entra. Кроме того, необходимо постоянно поддерживать порты брандмауэра Office 365 и открытия диапазона IP-адресов.

Требования к протоколам и портам для Exchange Server см. в статье "Требования к клиенту и протоколу Exchange" в обзоре гибридной современной проверки подлинности для использования с локальными Skype для бизнеса и серверами Exchange.

Диапазоны и порты IP-адресов Office 365 см. в разделе URL-адреса и диапазоны IP-адресов Office 365.

Дополнительные сведения о гибридной современной проверке подлинности и мобильных устройствах см. в статье о конечной точке AutoDetect в других конечных точках, не включенных в веб-службу IP-адреса и URL-адреса Office 365.

Устойчивость

Сведения о устойчивости компонентов в этой архитектуре см. в следующих ресурсах.

Безопасность

Общие рекомендации по обеспечению безопасности на мобильных устройствах см. в статье "Защита данных и устройств с помощью Microsoft Intune".

Дополнительные сведения о безопасности и гибридной современной проверке подлинности см. в статье "Подробное руководство. Как работает гибридная проверка подлинности".

Для закрытых организаций, имеющих традиционную надежную защиту периметра, существуют проблемы безопасности, связанные с гибридными классическими конфигурациями Exchange. Гибридная конфигурация Exchange Hybrid Modern не поддерживает гибридную современную проверку подлинности.

Сведения об идентификаторе Microsoft Entra см . в руководстве по операциям безопасности Microsoft Entra.

Сведения о сценариях, использующих безопасность AD FS, см. в следующих статьях:

Оптимизация затрат

Стоимость реализации зависит от стоимости лицензии Microsoft Entra ID и лицензий Microsoft 365. Общая стоимость также включает затраты на программное обеспечение и оборудование для локальных компонентов, ИТ-операций, обучения и образования, а также реализации проектов.

Для этих решений требуется по крайней мере идентификатор Microsoft Entra ID P1. Сведения о ценах см. в разделе о ценах Microsoft Entra.

Дополнительные сведения о AD FS и прокси-сервере веб-приложения см. в разделе "Цены и лицензирование" для Windows Server 2022.

Дополнительные сведения о ценах см. в следующих ресурсах:

Оптимизация производительности

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

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

Масштабируемость

Сведения о масштабируемости AD FS см. в разделе "Планирование емкости сервера AD FS".

Сведения о локальной масштабируемости Exchange Server см . в статье Об предпочтительной архитектуре Exchange 2019.

Развертывание этого сценария

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

  1. Защита мобильного доступа Outlook, как описано в этих шагах реализации для современной проверки подлинности.
  2. Блокировать все остальные попытки проверки подлинности прежних версий на уровне идентификатора Microsoft Entra.
  3. Блокировать устаревшие попытки проверки подлинности на уровне служб обмена сообщениями с помощью политики проверки подлинности.

Соавторы

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

Основные авторы:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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