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

Microsoft Entra ID

Microsoft 365

Office 365

Решение в этой статье позволяет защитить службу обмена сообщениями (Outlook в Интернете или Exchange панель управления) при размещении почтовых ящиков в локальной среде Exchange Online или Exchange.

Архитектура

В этой архитектуре мы разделим решение на две области, описывая безопасность:

Exchange Online справа от схемы.
Локальная среда Exchange в гибридном или не гибридном сценарии в левой части схемы.

Скачайте файл Visio для этой архитектуры.

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

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

Поток пользователя Exchange Online

Пользователь пытается получить доступ к службе Outlook в Интернете через https://outlook.office.com/owa.
Exchange Online перенаправляет пользователя на идентификатор Microsoft Entra для проверки подлинности.

Если домен федеративный, идентификатор Microsoft Entra перенаправляет пользователя на локальный экземпляр AD FS для проверки подлинности. Если проверка подлинности выполнена успешно, пользователь перенаправляется обратно в идентификатор Microsoft Entra. (Чтобы сохранить схему простой, мы оставили этот федеративный сценарий.)
Чтобы применить многофакторную проверку подлинности, идентификатор Microsoft Entra применяет политику условного доступа Azure с требованием многофакторной проверки подлинности для клиентского приложения браузера. Сведения о настройке этой политики см. в разделе развертывания этой статьи.
Политика условного доступа вызывает многофакторную проверку подлинности Microsoft Entra. Пользователь получает запрос на завершение многофакторной проверки подлинности.
Пользователь завершает многофакторную проверку подлинности.
Идентификатор Microsoft Entra перенаправляет прошедший проверку подлинности веб-сеанс в Exchange Online, а пользователь может получить доступ к Outlook.

Поток локального пользователя Exchange

Пользователь пытается получить доступ к службе Outlook в Интернете через https://mail.contoso.com/owa URL-адрес, указывающий на сервер Exchange для внутреннего доступа или на прокси-сервер веб-приложения для внешнего доступа.
Локальная среда Exchange (для внутреннего доступа) или прокси-сервер веб-приложения (для внешнего доступа) перенаправляет пользователя в AD FS для проверки подлинности.
AD FS использует встроенную проверка подлинности Windows для внутреннего доступа или предоставляет веб-форму, в которой пользователь может вводить учетные данные для внешнего доступа.
Отвечая на политику управления доступом AF DS, AD FS вызывает многофакторную проверку подлинности Microsoft Entra для завершения проверки подлинности. Ниже приведен пример политики управления доступом AD FS:

Пользователь получает запрос на завершение многофакторной проверки подлинности.
Пользователь завершает многофакторную проверку подлинности. AD FS перенаправляет прошедший проверку подлинности веб-сеанс в локальную среду Exchange.
Пользователь может получить доступ к Outlook.

Чтобы реализовать этот сценарий для локального пользователя, необходимо настроить Exchange и AD FS, чтобы настроить AD FS для предварительной проверки подлинности запросов веб-доступа. Дополнительные сведения см. в статье Об использовании проверки подлинности на основе утверждений AD FS с Outlook в Интернете.

Кроме того, необходимо включить интеграцию AD FS и многофакторной проверки подлинности Microsoft Entra. Дополнительные сведения см. в статье "Настройка Azure MFA в качестве поставщика проверки подлинности с помощью AD FS". (Для этой интеграции требуется AD FS 2016 или 2019.) Наконец, необходимо синхронизировать пользователей с идентификатором Microsoft Entra и назначить им лицензии для многофакторной проверки подлинности Microsoft Entra.

Компоненты

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

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

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

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

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

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

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

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

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

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

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

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

Начните со службы веб-доступа. Повышение безопасности с помощью политики условного доступа Azure для Exchange Online.
Повышение безопасности веб-доступа для локального EMI с помощью проверки подлинности на основе утверждений AD FS.

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

Чтобы настроить политику условного доступа Microsoft Entra, которая обеспечивает многофакторную проверку подлинности, как описано на шаге 3 потока пользователя в интернете ранее в этой статье:

Настройте Office 365 Exchange Online или Office 365 в качестве облачного приложения:
Настройте браузер в качестве клиентского приложения:
Примените требование многофакторной проверки подлинности в окне Grant :

Соавторы

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

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

Павел Кондрашов | Архитектор облачных решений
Элла Паркум | Главный архитектор решения клиента— проектирование

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

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

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