Использование Брандмауэр Azure для управления средами Windows 365 и защиты

В этой статье объясняется, как упростить и защитить среду Windows 365 с помощью Брандмауэр Azure. Пример архитектуры, описанный здесь, обеспечивает низкий уровень обслуживания и автоматический доступ к требуемым конечным точкам через прямой и оптимизированный путь подключения. Для репликации этого примера архитектуры в среде можно использовать правила сети Брандмауэр Azure и теги полного доменного имени (FQDN).

Служба Windows 365 требует оптимизированного и непроксимированного подключения к критически важным конечным точкам служб, многие из которых находятся в инфраструктуре Майкрософт. Подключение к этим ресурсам с помощью локальных сетей через Интернет является неэффективным и не рекомендуется. Такие подключения также могут быть сложными для настройки и управления.

Например, некоторые клиенты Windows 365, использующие модель развертывания ANC, могут иметь прямое подключение к локальной среде, которая использует ExpressRoute или VPN типа "сеть — сеть". Исходящий трафик может маршрутизироваться с помощью существующего прокси-сервера так же, как и локальный трафик. Эта стратегия подключения не оптимизирована для Windows 365 сред и может оказать значительное влияние на производительность.

Вместо этого можно использовать Брандмауэр Azure со средами WINDOWS 365 ANC, чтобы обеспечить оптимизированный, безопасный, низкий уровень обслуживания и автоматический доступ. Вы также можете использовать прямой путь для оптимизации трафика RDP и других длительных подключений, например к защищенному веб-шлюзу.

Необходимые конечные точки для Windows 365

Windows 365 требуется доступ к следующим конечным точкам:

1. Windows 365
2. Виртуальный рабочий стол Azure
3. Intune

Вы также можете рассмотреть возможность доступа к другим службам Майкрософт (например, Office 365) при настройке оптимизированного подключения из среды.

Теги FQDN для определенных служб доступны для Брандмауэр Azure, чтобы помочь в настройке и обслуживании этих правил простым способом, и они рассматриваются далее в этом документе.

Пример архитектуры с использованием тегов Брандмауэр Azure и FQDN

Существует множество способов настройки сети в Azure. Здесь мы используем:

• Одна виртуальная сеть с Брандмауэр Azure управления исходящим доступом.
• Оптимизация трафика RDP для отправки его напрямую в Корпорацию Майкрософт.
• Канал ExpressRoute для подключения виртуальной сети к локальной среде.

Поток трафика на этой схеме:

1. По умолчанию весь трафик из подсети Windows 365 отправляется в брандмауэр Azure через определяемый пользователем маршрут (UDR) 0.0.0.0/0. В качестве IP-адреса следующего прыжка задается частный IP-адрес Брандмауэр Azure.
2. Более конкретный UDR указывает на тег службы "WindowsVirtualDesktop", который содержит диапазоны IP-адресов для подключения по протоколу RDP, для которого для следующего прыжка задано значение "Интернет". Этот UDR не позволяет трафику RDP проходить через брандмауэр и помещается непосредственно в сеть Майкрософт.
3. Корпоративная сеть Contoso. Эта локальная IP-подсеть объявляется в виртуальной сети через шлюз ExpressRoute. Весь трафик в этот диапазон (10.0.0.0/8) отправляется через канал ExpressRoute, так как он более специфичен, чем правило 1.
4. Брандмауэр содержит правила приложений (и теги FQDN) и сетевые правила, настроенные для Windows 365 необходимых конечных точек. Трафик, соответствующий правилам, разрешен. Любой другой трафик, явно не разрешенный, блокируется.

Оптимизация подключения RDP

В этом примере конфигурации RDP настраивается с определенным UDR, чтобы указать тег службы "WindowsVirtualDesktop" на "интернет". Такая конфигурация означает, что этот трафик с высоким объемом и задержкой имеет прямой и высокоэффективный путь к инфраструктуре и позволяет избежать ненужной нагрузки на брандмауэр. Рекомендуется реализовать эту конфигурацию для предоставления наиболее эффективного и надежного пути для RDP. Хотя назначением для этого UDR является Интернет, так как этот трафик направляется к конечным точкам Майкрософт, этот трафик с облачного компьютера в инфраструктуру RDP не попадает в Интернет, а остается в магистрали Майкрософт.

правила приложений Брандмауэр Azure

Среда на схеме была настроена с помощью следующих Брандмауэр Azure правил приложения (примененных в выноске 3). Весь трафик, не предназначенный для локальной подсети Contoso, направляется в брандмауэр. Эти правила разрешают определенному трафику исходящий трафик к месту назначения. Дополнительные сведения о развертывании Брандмауэр Azure см. в статье Развертывание и настройка Брандмауэр Azure с помощью портал Azure.

Брандмауэр Azure можно связать с общедоступными IP-адресами для обеспечения исходящего подключения к Интернету. Первый общедоступный IP-адрес выбирается случайным образом для предоставления исходящего преобразования сетевых адресов источника (SNAT). Следующий доступный общедоступный IP-адрес будет использоваться после исчерпания всех портов SNAT из первого IP-адреса. В сценариях, требующих высокой пропускной способности, рекомендуется использовать шлюз Azure NAT. Шлюз NAT динамически масштабирует исходящие подключения и может быть интегрирован с Брандмауэр Azure. Дополнительные сведения см. в руководстве по интеграции шлюза NAT с Брандмауэр Azure.

Тег Windows365

Тег Windows365 включает необходимые конечные точки Виртуального рабочего стола Azure (AVD), за исключением конечных точек с нестандартными портами, которые необходимо ввести вручную (см. раздел Сетевые правила).

Тег Windows365 не включает Intune. Тег MicrosoftIntune можно использовать отдельно.

Тег FQDN Windows365 включает все необходимые конечные точки, кроме конечных точек, перечисленных как обязательные в отдельных строках этого документа, которые необходимо настроить отдельно. Теги FQDN отличаются от тега службы. Например, тег службы WindowsVirtualDesktop включает только IP-адреса, по которым разрешается *.wvd.microsoft.com.

Правила сети

Брандмауэр Azure в настоящее время не обрабатывает нестандартные порты в теге FQDN. Windows 365 имеет несколько нестандартных требований к портам, поэтому следующие правила необходимо добавить вручную в качестве сетевых правил в дополнение к тегам FQDN.

Варианты решений для обеспечения безопасности партнеров

Другие способы защиты среды Windows 365 — это варианты решений для обеспечения безопасности партнеров, которые предоставляют автоматические наборы правил для доступа к необходимым конечным точкам для службы Windows 365. К таким вариантам относятся:

• Обновляемые объекты Check Point Software Technologies

Дальнейшие действия

Дополнительные сведения об архитектуре Windows 365.

Дополнительные сведения о FQDNS см. в статье Общие сведения о тегах FQDN.

Дополнительные сведения о тегах служб см. в статье Теги службы виртуальной сети.