Брандмауэр Azure и шлюз приложений для виртуальных сетей

Шлюз приложений Azure

Брандмауэр Azure

Azure Front Door

Виртуальная сеть Azure

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

Чтобы защитить рабочие нагрузки приложений Azure, используйте такие защитные меры, как проверка подлинности и шифрование в самих приложениях. Вы можете добавить уровни безопасности в виртуальные сети, в которых размещаются приложения. Эти уровни безопасности помогают защитить входящие потоки приложения от непреднамеренного использования. Они также ограничивают исходящие потоки в Интернет только тем конечным точкам, которые требует ваше приложение. В этой статье описаны службы безопасности виртуальной сети Azure , такие как защита от атак DDoS Azure, брандмауэр Azure и шлюз приложений Azure. В нем также описывается, когда следует использовать каждую службу и параметры проектирования сети, которые объединяют их.

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

• Брандмауэр Azure — это управляемый брандмауэр следующего поколения, предоставляющий возможности преобразования сетевых адресов (NAT ). Брандмауэр Azure фильтрует пакеты на основе IP-адресов и tcp-адресов или портов протокола UDP. Он может фильтровать трафик с помощью атрибутов на основе приложений, таких как HTTP(S) и SQL. Брандмауэр Azure также применяет аналитику угроз Майкрософт для выявления вредоносных IP-адресов. Дополнительные сведения см. в документации по брандмауэру Azure.

• Брандмауэр Azure Premium включает все функциональные возможности брандмауэра Azure Уровня "Стандартный", помимо таких функций, как проверка уровня транспорта (TLS) и система обнаружения вторжений и предотвращения вторжений (IDPS).

• Шлюз приложений — это подсистема балансировки нагрузки управляемого веб-трафика и полный обратный прокси-сервер HTTP(S), который может выполнять шифрование и расшифровку ssl. Шлюз приложений сохраняет исходный IP-адрес клиента в заголовке X-Forwarded-For HTTP. Шлюз приложений также использует брандмауэр веб-приложения Azure для проверки веб-трафика и обнаружения атак на уровне HTTP. Дополнительные сведения см. в документации по Шлюзу приложений.

• Брандмауэр веб-приложения является необязательным дополнением к Шлюзу приложений. Он проверяет HTTP-запросы и предотвращает атаки веб-слоя, такие как внедрение SQL и межсайтовые скрипты. Дополнительные сведения см. в документации по брандмауэру веб-приложений.

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

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

Блок-схема приложения	Может быть отфильтрован брандмауэром Azure	Можно фильтровать по брандмауэру веб-приложения в шлюзе приложений
Трафик HTTP(S) из локальной среды или Интернета в Azure (входящий трафик)	Да	Да
Трафик HTTP(S) из Azure в локальную среду или Интернет (исходящий)	Да	Нет
Трафик, отличный от HTTP(S) (входящий или исходящий)	Да	Нет

Дизайн может отличаться для каждого приложения в зависимости от необходимых сетевых потоков. На следующей схеме представлено упрощенное дерево принятия решений, которое помогает выбрать рекомендуемый подход для приложения. Этот выбор зависит от того, публикуется ли приложение через ПРОТОКОЛ HTTP(S) или другой протокол.

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

• Только брандмауэр Azure: Используйте эту структуру, если в виртуальной сети нет веб-приложений. Он управляет входящий трафик приложениями и исходящим трафиком.

• Только шлюз приложений. Используйте эту структуру, если только веб-приложения находятся в виртуальной сети и группах безопасности сети (NSG) обеспечивают достаточную фильтрацию выходных данных. Брандмауэр Azure предоставляет функциональные возможности, которые могут помочь предотвратить несколько сценариев атаки, таких как утечка данных и поставщики удостоверений. В результате дизайн шлюза приложений обычно не рекомендуется, поэтому он не включен в предыдущую блок-диаграмму.

• Брандмауэр Azure и шлюз приложений параллельно: Используйте эту структуру, если требуется, чтобы шлюз приложений защищал приложения HTTP(S) от веб-атак и брандмауэра Azure для защиты всех других рабочих нагрузок и фильтрации исходящего трафика. Брандмауэр Azure и шлюз приложений параллельно являются общим проектом.

• Шлюз приложений перед брандмауэром Azure: Используйте эту структуру, если требуется, чтобы брандмауэр Azure проверял весь трафик, брандмауэр веб-приложений для защиты веб-трафика и приложения, чтобы определить исходный IP-адрес клиента. При проверке брандмауэра Azure Premium и TLS эта конструкция также поддерживает комплексный сценарий SSL.

• Брандмауэр Azure перед шлюзом приложений: Используйте эту структуру, если требуется, чтобы брандмауэр Azure проверял и фильтрировал трафик, прежде чем он достигнет шлюза приложений. Так как брандмауэр Azure не расшифровывает трафик HTTPS, его добавленная функциональность в шлюз приложений ограничена. Этот сценарий не описан в предыдущей блок-диаграмме.

Варианты этих фундаментальных конструкций описаны далее в этой статье и включают:

• локальные клиенты приложений.
• Центральные и периферийные сети.
• реализации службы Azure Kubernetes (AKS).

Вы можете добавить другие обратные прокси-службы, такие как шлюз управления API Azure или Azure Front Door. Вы также можете заменить ресурсы Azure виртуальными устройствами, отличными от Майкрософт(NVAs).

Заметка

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

Проектирование только брандмауэра Azure

Если в виртуальной сети нет веб-рабочих нагрузок, которые могут воспользоваться брандмауэром веб-приложений, можно использовать проект брандмауэра Azure только для брандмауэра. Дизайн в этом примере прост, но можно просмотреть поток пакетов, чтобы лучше понять более сложные проекты. В этой структуре весь входящий трафик отправляется в брандмауэр Azure через определяемые пользователем маршруты (UDR) для подключений из локальной среды или других виртуальных сетей Azure. Он обращается к общедоступному IP-адресу брандмауэра Azure для подключений из общедоступного Интернета, как показано на следующей схеме. Определяемые пользователем трафик направляют исходящий трафик из виртуальных сетей Azure в брандмауэр Azure, как показано в следующем диалоговом окне.

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Не применимо	Да
Трафик HTTP(S) из Azure в Интернет или локальную среду	Не применимо	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Не применимо	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Не применимо	Да

Брандмауэр Azure не проверяет входящий трафик HTTP(S). Но он может применять правила приложения уровня 3 и уровня 4 и полное доменное имя (FQDN). Брандмауэр Azure проверяет исходящий трафик HTTP(S) в зависимости от уровня брандмауэра Azure и настройки проверки TLS:

• Брандмауэр Azure Standard проверяет только атрибуты уровня 3 и 4 пакетов в правилах сети и заголовок HTTP узла в правилах приложения.

• Брандмауэр Azure Premium добавляет возможности, такие как проверка других заголовков HTTP (например, агента пользователя) и включение проверки TLS для более глубокого анализа пакетов. Однако брандмауэр Azure не совпадает с брандмауэром веб-приложения. Если у вас есть веб-рабочие нагрузки в виртуальной сети, рекомендуется использовать брандмауэр веб-приложения.

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

• В этом примере брандмауэр Azure автоматически развертывает несколько экземпляров с внешним IP-адресом 192.168.100.4 и внутренними адресами в диапазоне 192.168.100.0/26. Как правило, эти экземпляры не отображаются администратору Azure. Тем не менее, учитывая их, может быть полезно для устранения проблем с сетью.

• Если трафик поступает из локальной виртуальной частной сети (VPN) или шлюза Azure ExpressRoute вместо Интернета, клиент запускает подключение к IP-адресу виртуальной машины. Он не запускает подключение к IP-адресу брандмауэра, и брандмауэр по умолчанию не выполняет исходный NAT.

Архитектура

На следующей схеме показан поток трафика и предполагается, что IP-адрес экземпляра является 192.168.100.7.

Рабочий процесс

1. Клиент запускает подключение к общедоступному IP-адресу брандмауэра Azure.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AzFwPIP

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

   • Исходный IP-адрес: 192.168.100.7
   • IP-адрес назначения: 192.168.1.4

3. Виртуальная машина отвечает на запрос приложения, который изменяет ip-адреса источника и назначения. Для входящего потока не требуется UDR, так как исходный IP-адрес является IP-адресом брандмауэра Azure. UDR на схеме 0.0.0.0/0 предназначен для исходящих подключений, чтобы гарантировать, что пакеты в общедоступный Интернет проходят через брандмауэр Azure.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.100.7

4. Брандмауэр Azure отменяет операции SNAT и DNAT и передает ответ клиенту.

   • Исходный IP-адрес: AzFwPIP
   • IP-адрес назначения: ClientPIP

Проектирование только шлюза приложений

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

Заметка

Мы не рекомендуем эту структуру, так как с помощью брандмауэра Azure для управления исходящими потоками вместо того, чтобы полагаться исключительно на группы безопасности сети, помогает предотвратить атаки, такие как утечка данных. С помощью брандмауэра Azure вы можете убедиться, что рабочие нагрузки отправляют данные только в утвержденный список URL-адресов. Кроме того, группы безопасности сети работают только на уровне 3 и уровне 4 и не поддерживают полные доменные имена.

Ключевое отличие от предыдущей структуры брандмауэра Azure заключается в том, что шлюз приложений не служит устройством маршрутизации с помощью NAT. Вместо этого он работает как полный обратный прокси приложения. Этот подход означает, что шлюз приложений останавливает веб-сеанс от клиента и устанавливает отдельный сеанс с одним из серверных серверов. Входящие ПОДКЛЮЧЕНИЯ HTTP(S) из Интернета отправляются на общедоступный IP-адрес шлюза приложений, а подключения из Azure или локальной среды используют частный IP-адрес шлюза. Возврат трафика с виртуальных машин Azure следует стандартной маршрутизации виртуальной сети обратно в Шлюз приложений. Дополнительные сведения см. далее в этой статье. Исходящие интернет-потоки из виртуальных машин Azure отправляются непосредственно в Интернет.

В следующей таблице перечислены потоки трафика.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Не применимо
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Не применимо
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Не применимо
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Не применимо

Архитектура

В следующем примере пошагового руководства по пакету показано, как клиент обращается к размещенной виртуальной машине приложению из общедоступного Интернета.

Рабочий процесс

1. Клиент запускает подключение к общедоступному IP-адресу шлюза приложений.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AppGwPIP

2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, который находится 192.168.200.7 в этом примере. Экземпляр шлюза приложений, который получает запрос, останавливает подключение от клиента и устанавливает новое соединение с одним из внутренних серверов. Серверная часть отображает экземпляр Шлюза приложений в качестве исходного IP-адреса. Шлюз приложений X-Forwarded-For вставляет заголовок HTTP с IP-адресом исходного клиента.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра шлюза приложений: 192.168.200.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: ClientPIP

3. Виртуальная машина отвечает на запрос приложения и изменяет исходные и конечные IP-адреса. Виртуальная машина может получить доступ к шлюзу приложений, поэтому для нее не требуется UDR.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

4. Экземпляр шлюза приложений отвечает клиенту.

   • Исходный IP-адрес: AppGwPIP
   • IP-адрес назначения: ClientPIP

Шлюз приложений добавляет метаданные в заголовки HTTP пакета, например X-Forwarded-For заголовок, содержащий IP-адрес исходного клиента. Некоторые серверы приложений нуждаются в IP-адресе исходного клиента для обслуживания содержимого, зависящее от географического расположения, или для ведения журнала. Дополнительные сведения см. в статье Принцип работы шлюза приложений.

• В этом примере IP-адрес 192.168.200.7 является одним из экземпляров, развернутых службой шлюза приложений автоматически. Он имеет внутренний, частный внешний IP-адрес 192.168.200.4. Эти отдельные экземпляры обычно невидимы для администратора Azure. Но выяснять разницу могут быть полезными, например при устранении неполадок в сети.

• Поток аналогичен, если клиент поступает из локальной сети через VPN или шлюз ExpressRoute. Разница заключается в том, что клиент обращается к частному IP-адресу шлюза приложений вместо общедоступного IP-адреса.

Заметка

Дополнительные сведения о X-Forwarded-For заголовке и сохранении имени узла в запросе см. в разделе "Сохранение исходного узла HTTP".

Брандмауэр Azure и шлюз приложений в параллельном проектировании

Благодаря простоте и гибкости часто рекомендуется параллельно запускать шлюз приложений и брандмауэр Azure.

Реализуйте эту структуру, если в виртуальной сети есть как веб-, так и не веб-рабочие нагрузки. Брандмауэр веб-приложения в Шлюзе приложений помогает защитить входящий трафик к веб-рабочим нагрузкам. Брандмауэр Azure проверяет входящий трафик для других приложений. Брандмауэр Azure охватывает исходящие потоки из обоих типов рабочих нагрузок.

Входящий HTTP(S) подключения из Интернета должны отправляться на общедоступный IP-адрес шлюза приложений. Подключения HTTP(S) из Azure или локальной среды должны отправляться в частный IP-адрес. Маршрутизация стандартной виртуальной сети отправляет пакеты из шлюза приложений на конечные виртуальные машины и из конечных виртуальных машин обратно в шлюз приложений. Дополнительные сведения см. далее в этой статье.

Для входящих подключений, отличных от HTTP(S), трафик должен быть направлен на общедоступный IP-адрес брандмауэра Azure, если он поступает из общедоступного Интернета. Трафик должен отправляться через брандмауэр Azure определяемыми пользователями, если он поступает из других виртуальных сетей Azure или локальных сетей. Все исходящие потоки из виртуальных машин Azure перенаправляются в брандмауэр Azure с помощью определяемых пользователем пользователей.

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Нет
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Да

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

Архитектуры

На следующей схеме показан поток трафика для входящих подключений HTTP(S) из внешнего клиента.

На следующей схеме показан поток трафика для исходящих подключений из сетевых виртуальных машин в Интернет. Одним из примеров является подключение к внутренним системам или получение обновлений операционной системы.

Шаги потока пакетов для каждой службы совпадают с предыдущими автономными параметрами проектирования.

Шлюз приложений перед проектированием брандмауэра Azure

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

С помощью брандмауэра Azure Premium эта конструкция может поддерживать комплексные сценарии, в которых брандмауэр Azure применяет проверку TLS для выполнения проверки IDPS на зашифрованном трафике между шлюзом приложений и веб-серверной частью.

Эта конструкция подходит для приложений, которые должны определять входящие IP-адреса источника клиента. Например, его можно использовать для обслуживания содержимого, зависяющего от географического расположения, или для ведения журнала. Шлюз приложений перед конструктором брандмауэра Azure записывает исходный IP-адрес входящего пакета в заголовке X-Forwarded-For , поэтому веб-сервер может видеть исходный IP-адрес в этом заголовке. Дополнительные сведения см. в статье Принцип работы шлюза приложений.

Для входящих ПОДКЛЮЧЕНИй HTTP(S) из Интернета необходимо отправить общедоступный IP-адрес шлюза приложений. Подключения HTTP(S) из Azure или локальной среды должны отправляться в частный IP-адрес. Из шлюза приложений определяемые пользователем UDR гарантируют, что пакеты направляются через брандмауэр Azure. Дополнительные сведения см. далее в этой статье.

Для входящих подключений, отличных от HTTP(S), трафик должен быть направлен на общедоступный IP-адрес брандмауэра Azure, если он поступает из общедоступного Интернета. Трафик должен отправляться через брандмауэр Azure определяемыми пользователями, если он поступает из других виртуальных сетей Azure или локальных сетей. Все исходящие потоки из виртуальных машин Azure перенаправляются в брандмауэр Azure с помощью определяемых пользователем пользователей.

Важным аспектом этой структуры является то, что брандмауэр Azure Premium видит трафик с исходным IP-адресом из подсети шлюза приложений. Если эта подсеть настроена с частным IP-адресом (в 10.0.0.0/8, 192.168.0.0/16172.16.0.0/12или100.64.0.0/10) Брандмауэр Azure Premium обрабатывает трафик из шлюза приложений как внутренний и не применяет правила IDPS для входящего трафика. В результате рекомендуется изменить частные префиксы IDPS в политике брандмауэра Azure. Это изменение гарантирует, что подсеть шлюза приложений не считается внутренним источником, что позволяет применять к трафику сигнатуры входящих и исходящих поставщиков удостоверений. Дополнительные сведения о направлениях правил поставщика удостоверений брандмауэра Azure и префиксах частных IP-адресов для поставщиков удостоверений брандмауэра Azure см. в правилах поставщиков удостоверений брандмауэра Azure.

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Да
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Да

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

• Шлюз приложений шифрует трафик, следуя принципам нулевого доверия, таким как сквозное шифрование TLS, и брандмауэр Azure получает зашифрованный трафик. Брандмауэр Azure "Стандартный" по-прежнему может применять правила проверки, такие как фильтрация уровня 3 и уровня 4 в правилах сети или полное доменное имя в правилах приложений с помощью заголовка "Указание имени сервера TLS" (SNI). Брандмауэр Azure Premium обеспечивает более глубокую видимость с проверкой TLS, например фильтрацией на основе URL-адресов.

• Если шлюз приложений отправляет незашифрованный трафик на серверы приложений, брандмауэр Azure видит входящий трафик в виде ясного текста. Проверка TLS не требуется в брандмауэре Azure.

• Если поставщик удостоверений включен в брандмауэре Azure, он проверяет, соответствует ли заголовок узла HTTP целевому IP-адресу. Для выполнения этой проверки требуется разрешение имен для полного доменного имени, указанного в заголовке узла. Это разрешение имен можно выполнить с помощью частных зон Azure DNS и параметров DNS брандмауэра Azure по умолчанию. Его также можно достичь с помощью пользовательских DNS-серверов, которые необходимо настроить в параметрах брандмауэра Azure. Если у вас нет административного доступа к виртуальной сети, в которой развернут брандмауэр Azure, последний метод является единственным вариантом. Одним из примеров является развертывание экземпляров брандмауэра Azure в центрах, защищенных виртуальной глобальной сетью Azure.

Архитектура

Для остальных потоков, которые включают входящий трафик, отличный от HTTP(S) и любой исходящий трафик, Брандмауэр Azure предоставляет проверку idPS и проверку TLS, где это подходит. Он также предоставляет фильтрацию на основе FQDN в правилах сети на основе DNS.

Рабочий процесс

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

1. Клиент запускает подключение к общедоступному IP-адресу шлюза приложений.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AppGwPIP

2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, который находится 192.168.200.7 в этом примере. Экземпляр шлюза приложений останавливает подключение от клиента и устанавливает новое подключение с одной из внутренних серверов. UDR 192.168.1.0/24 в подсети шлюза приложений перенаправит пакет в брандмауэр Azure и сохраняет целевой IP-адрес в веб-приложение.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра шлюза приложений: 192.168.200.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: ClientPIP

3. Брандмауэр Azure не применяет SNAT к трафику, так как трафик переходит к частному IP-адресу. Он перенаправит трафик на виртуальную машину приложения, если это разрешено правилами. Дополнительные сведения см. в статье об использовании SNAT для диапазонов частных IP-адресов в Брандмауэре Azure. Однако если трафик попадает в правило приложения в брандмауэре, рабочая нагрузка видит исходный IP-адрес конкретного экземпляра брандмауэра, который обработал пакет, так как брандмауэр Azure прокси-серверы подключения.

   • Исходный IP-адрес, если трафик разрешен правилом сети брандмауэра Azure и является частным IP-адресом одного из экземпляров шлюза приложений: 192.168.200.7
   • Исходный IP-адрес, если трафик разрешен правилом приложения брандмауэра Azure и является частным IP-адресом одного из экземпляров брандмауэра Azure: 192.168.100.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: ClientPIP

4. Виртуальная машина отвечает на запрос, который изменяет ip-адреса источника и назначения. UDR для 192.168.200.0/24 записи пакета, отправленного шлюзу приложений, перенаправляет его в брандмауэр Azure и сохраняет целевой IP-адрес к шлюзу приложений.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

5. Опять же, брандмауэр Azure не применяет SNAT к трафику, так как он переходит к частному IP-адресу и пересылает трафик в шлюз приложений.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

6. Экземпляр шлюза приложений отвечает клиенту.

   • Исходный IP-адрес: AppGwPIP
   • IP-адрес назначения: ClientPIP

Исходящие потоки из виртуальных машин в общедоступный Интернет проходят через брандмауэр Azure, который определяет UDR 0.0.0.0/0 .

В качестве варианта этой структуры вы можете настроить частный DNAT в брандмауэре Azure, чтобы рабочая нагрузка приложения видела IP-адреса экземпляров брандмауэра Azure в качестве источника, и не требуются определяемые пользователем UDR. Исходный IP-адрес клиентов приложения уже сохраняется в заголовке X-Forwarded-For HTTP шлюзом приложений. Поэтому, если брандмауэр Azure применяет DNAT к трафику, информация не будет потеряна. Дополнительные сведения см. в статье "Фильтрация входящего трафика в Интернете или интрасети с помощью политики брандмауэра Azure DNAT" с помощью портала Azure.

Брандмауэр Azure перед проектированием шлюза приложений

Эта схема позволяет брандмауэру Azure фильтровать и удалять вредоносный трафик, прежде чем он достигнет шлюза приложений. Например, он может применять такие функции, как фильтрация на основе аналитики угроз. Еще одним преимуществом является то, что приложение получает один и тот же общедоступный IP-адрес для входящего и исходящего трафика независимо от протокола. Существует три режима, в которых можно теоретически настроить брандмауэр Azure:

• Брандмауэр Azure с правилами DNAT: Брандмауэр Azure переключает IP-адреса только на уровне IP-адресов, но не обрабатывает полезные данные. В результате он не изменяет ни один из заголовков HTTP.

• Брандмауэр Azure с правилами приложения и проверкой TLS отключен: Брандмауэр Azure может просмотреть заголовок SNI в TLS, но он не расшифровывает его. Новое TCP-подключение создается из брандмауэра к следующему прыжку. В этом примере это шлюз приложений.

• Брандмауэр Azure с включенными правилами приложений и проверкой TLS: Брандмауэр Azure просматривает содержимое пакета и расшифровывает их. Он служит прокси-сервером HTTP и может задать заголовки X-Forwarded-For HTTP для сохранения IP-адреса. Однако он представляет самогенерированный сертификат клиенту. Для интернет-приложений использование самогенерированного сертификата не является вариантом, так как предупреждение системы безопасности отправляется клиентам приложений из браузера.

В первых двух вариантах, которые являются единственными допустимыми параметрами для интернет-приложений, брандмауэр Azure применяет SNAT к входящего трафика без задания заголовка X-Forwarded-For . В результате приложение не может видеть исходный IP-адрес HTTP-запросов. Для административных задач, таких как устранение неполадок, можно получить фактический IP-адрес клиента для конкретного подключения, связав его с журналами SNAT брандмауэра Azure.

Преимущества этого сценария ограничены, так как если вы не используете проверку TLS и предоставляете самогенерированные сертификаты клиентам, брандмауэр Azure видит только зашифрованный трафик, который переходит в шлюз приложений. Этот сценарий обычно возможен только для внутренних приложений. Однако могут возникнуть сценарии, в которых эта конструкция предпочтительна. Один из сценариев заключается в том, что другой брандмауэр веб-приложения существует ранее в сети (например, с Azure Front Door), который может записать исходный IP-адрес в заголовке X-Forwarded-For HTTP. Вы также можете предпочесть эту структуру, если требуется много общедоступных IP-адресов, так как Шлюз приложений поддерживает один IP-адрес.

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

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Да
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Да

Для входящего трафика HTTP(S) брандмауэр Azure обычно не расшифровывает трафик. Вместо этого применяются политики IDPS, для которых не требуется проверка TLS, например фильтрация IP-адресов или использование заголовков HTTP.

Архитектура

Приложение не может видеть исходный IP-адрес веб-трафика. Брандмауэр Azure применяет SNAT к пакетам по мере их входа в виртуальную сеть. Чтобы избежать этой проблемы, используйте Azure Front Door перед брандмауэром. Azure Front Door внедряет IP-адрес клиента в качестве заголовка HTTP перед вводом виртуальной сети Azure.

схема

Рабочий процесс

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

1. Клиент запускает подключение к общедоступному IP-адресу брандмауэра Azure.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AzFWPIP

2. Запрос к общедоступному IP-адресу брандмауэра Azure распространяется на внутренний экземпляр брандмауэра, который находится 192.168.100.7 в этом примере. Брандмауэр Azure применяет DNAT к веб-порту, обычно TCP 443, к частному IP-адресу экземпляра шлюза приложений. Брандмауэр Azure также применяет SNAT при выполнении DNAT. Дополнительные сведения см. в статье известных проблем брандмауэра Azure.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра брандмауэра Azure: 192.168.100.7
   • IP-адрес назначения: 192.168.200.4

3. Шлюз приложений устанавливает новый сеанс между экземпляром, обрабатывающим подключение и один из внутренних серверов. Исходный IP-адрес клиента не в пакете.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра шлюза приложений: 192.168.200.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: 192.168.100.7

4. Виртуальная машина отвечает на шлюз приложений, который изменяет ip-адреса источника и назначения:

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

5. Шлюз приложений отвечает на IP-адрес источника SNAT экземпляра брандмауэра Azure. Брандмауэр Azure видит внутренний IP-адрес шлюза приложений, .4как исходный IP-адрес, даже если подключение поступает из определенного экземпляра шлюза приложений, например .7.

   • Исходный IP-адрес: 192.168.200.4
   • IP-адрес назначения: 192.168.100.7

6. Брандмауэр Azure отменяет SNAT и DNAT и отвечает клиенту.

   • Исходный IP-адрес: AzFwPIP
   • IP-адрес назначения: ClientPIP

Шлюз приложений должен иметь общедоступный IP-адрес, чтобы корпорация Майкрософт ей управляла, даже если у нее нет прослушивателей, настроенных для приложений.

Заметка

Маршрут 0.0.0.0/0 по умолчанию в подсети шлюза приложений, указывающей на брандмауэр Azure, не поддерживается, так как он нарушает трафик плоскости управления, необходимый шлюзу приложений для правильной работы.

Локальные клиенты

Предыдущие проекты отображают все входящие клиенты приложений из общедоступного Интернета. Локальные сети также обращаются к приложениям. Большинство предыдущих данных и потоков трафика совпадают с интернет-клиентами, но существуют некоторые заметные различия:

• VPN-шлюз или шлюз ExpressRoute находится перед брандмауэром Azure или шлюзом приложений.

• Брандмауэр веб-приложения использует частный IP-адрес шлюза приложений.

• Брандмауэр Azure не поддерживает DNAT для частных IP-адресов, поэтому необходимо использовать UDR для отправки входящего трафика в брандмауэр Azure из VPN или шлюзов ExpressRoute.

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

Архитектура

На следующей схеме показана параллельная конструкция шлюза приложений и брандмауэра Azure. Клиенты приложений приходят из локальной сети, подключенной к Azure через VPN или ExpressRoute:

Даже если все клиенты находятся в локальной среде или в Azure, шлюзе приложений и брандмауэре Azure должны иметь общедоступные IP-адреса. Эти общедоступные IP-адреса позволяют корпорации Майкрософт управлять службами.

Топология концентратора и периферийной топологии

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

Архитектура

• Брандмауэр Azure развертывается в центральной виртуальной сети концентратора. На предыдущей схеме показано, как развернуть шлюз приложений в концентраторе. Команды приложений часто управляют такими компонентами, как шлюзы приложений или шлюзы управления API. В этом сценарии эти компоненты развертываются в периферийных виртуальных сетях.

• Обратите особое внимание на определяемые пользователем пользовательский тип в периферийных сетях. Когда сервер приложений в периферии получает трафик от определенного экземпляра брандмауэра Azure, например 192.168.100.7 IP-адреса в предыдущих примерах, он должен отправлять трафик обратно в тот же экземпляр. Если UDR в периферийной части задает следующий прыжок трафика, адресованного концентратору, к IP-адресу брандмауэра Azure (192.168.100.4 на предыдущих схемах), возвращаемые пакеты могут оказаться в другом экземпляре брандмауэра Azure. Эта ситуация приводит к асимметричной маршрутизации. Если у вас есть UDR в периферийных виртуальных сетях, обязательно отправьте трафик в общие службы в концентраторе через брандмауэр Azure. Эти определяемые пользователем правила не включают префикс подсети брандмауэра Azure.

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

• Невозможно задать следующий прыжок для подсетей шлюза приложений или брандмауэра Azure через статические маршруты с типом следующего прыжка Virtual Network. Этот тип следующего прыжка действителен только в локальной виртуальной сети, а не в пирингах виртуальных сетей. Дополнительные сведения о типах определяемых пользователем пользователей и следующих прыжков см. в разделе "Маршрутизация трафика виртуальной сети".

Асимметричная маршрутизация

На следующей схеме показано, как периферийный сервер отправляет трафик SNAT обратно в подсистему балансировки нагрузки Azure брандмауэра Azure. Эта настройка приводит к асимметричной маршрутизации.

Чтобы решить эту проблему, определите UDR в периферийной сети без подсети брандмауэра Azure и только подсети, в которых находятся общие службы. На предыдущей схеме правильный UDR в периферии должен содержать 192.168.1.0/24только . Он не должен содержать весь диапазон 192.168.0.0/16, помеченный красным цветом.

Интеграция с другими продуктами Azure

Брандмауэр Azure и шлюз приложений можно интегрировать с другими продуктами и службами Azure.

Шлюз управления API

Интеграция обратных прокси-служб, таких как шлюз управления API в предыдущие проекты, чтобы обеспечить такие функции, как регулирование API или прокси-сервер проверки подлинности. Интеграция шлюза управления API значительно не влияет на проекты. Ключевое различие заключается в том, что вместо одного обратного прокси-сервера шлюза приложений есть два обратных прокси-сервера, цепочки друг за другом.

Дополнительные сведения см. в руководстве по проектированию для интеграции управления API и шлюза приложений в виртуальной сети ишлюзов API шаблонов приложений для микрослужб.

AKС

Для рабочих нагрузок, работающих в кластере AKS, можно развернуть шлюз приложений независимо от кластера. Кроме того, вы можете интегрировать его с кластером AKS с помощью контроллера входящего трафика шлюза приложений. При настройке определенных объектов на уровнях Kubernetes, таких как службы и входящий трафик, шлюз приложений автоматически адаптируется без дополнительных действий вручную.

Брандмауэр Azure играет важную роль в безопасности кластера AKS. Он предоставляет необходимые функции для фильтрации исходящего трафика из кластера AKS на основе полного доменного имени, а не только IP-адреса. Дополнительные сведения см. в разделе "Ограничение сетевого трафика с помощью брандмауэра Azure" в AKS.

При объединении шлюза приложений и брандмауэра Azure для защиты кластера AKS рекомендуется использовать вариант параллельного проектирования. Шлюз приложений с брандмауэром веб-приложения обрабатывает входящие запросы на подключение к веб-приложениям в кластере. Брандмауэр Azure разрешает только явно разрешенные исходящие подключения. Дополнительные сведения о параметре параллельного проектирования см. в разделе "Базовая архитектура" для кластера AKS.

Azure Front Door (облачное сетевое решение от Microsoft)

Azure Front Door имеет функциональные возможности, которые перекрываются с Шлюзом приложений в нескольких областях. Обе службы обеспечивают брандмауэр веб-приложения, разгрузку SSL и маршрутизацию на основе URL-адресов. Однако ключевым отличием является то, что в то время как шлюз приложений работает в виртуальной сети, Azure Front Door является глобальной, децентрализованной службой.

Иногда можно упростить проектирование виртуальной сети, заменив Шлюз приложений децентрализованной службой Azure Front Door. Большинство проектов, описанных в этой статье, по-прежнему применяются, за исключением возможности разместить брандмауэр Azure перед Azure Front Door.

Один из сценариев — использовать брандмауэр Azure перед шлюзом приложений в виртуальной сети. Шлюз приложений вводит X-Forwarded-For заголовок с IP-адресом экземпляра брандмауэра, а не IP-адресом клиента. Обходным решением является использование Azure Front Door перед брандмауэром X-Forwarded-For для внедрения IP-адреса клиента в качестве заголовка, прежде чем трафик входит в виртуальную сеть и достигает брандмауэра Azure. Вы также можете защитить источник с помощью Приватного канала Azure в Azure Front Door Premium.

Дополнительные сведения о различиях между двумя службами или о том, когда они используются, см. в разделе часто задаваемые вопросы о Azure Front Door.

Другие NVAs

Продукты Майкрософт не являются единственным выбором для реализации брандмауэра веб-приложения или функций брандмауэра следующего поколения в Azure. Широкий спектр партнеров Майкрософт предоставляет NVA. Основные понятия и конструкции, как и в этой статье, но существуют некоторые важные аспекты.

• Сетевые сети партнеров для брандмауэра следующего поколения могут обеспечить больший контроль и гибкость конфигураций NAT, которые не поддерживают брандмауэр Azure. Примеры включают DNAT из локальной среды или DNAT из Интернета без SNAT.

• Управляемые Azure NVAs, такие как Шлюз приложений и брандмауэр Azure, снижают сложность по сравнению с NVAs, где пользователям необходимо обрабатывать масштабируемость и устойчивость во многих устройствах.

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

Участников

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Автор субъекта:

• Хосе Морено | Главный инженер клиента

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

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

Дополнительные сведения о технологиях компонентов:

• Что такое Шлюз приложений?
• Что такое брандмауэр Azure?
• Что такое Azure Front Door?
• AKS
• Что такое виртуальная сеть?
• Что такое брандмауэр веб-приложения?
• Базовая архитектура кластера AKS

Связанные ресурсы

Изучите связанные архитектуры:

• Реализация безопасной гибридной сети
• безопасно управляемых веб-приложений
• Мультитенантное программное обеспечение как услуга в Azure
• Корпоративное развертывание с помощью среды службы приложений
• Высокодоступное корпоративное развертывание с помощью среды службы приложений

Чтобы защитить рабочие нагрузки приложений Azure, используйте такие защитные меры, как проверка подлинности и шифрование в самих приложениях. Вы можете добавить уровни безопасности в виртуальные сети, в которых размещаются приложения. Эти уровни безопасности помогают защитить входящие потоки приложения от непреднамеренного использования. Они также ограничивают исходящие потоки в Интернет только тем конечным точкам, которые требует ваше приложение. В этой статье описаны службы безопасности виртуальной сети Azure , такие как защита от атак DDoS Azure, брандмауэр Azure и шлюз приложений Azure. В нем также описывается, когда следует использовать каждую службу и параметры проектирования сети, которые объединяют их.

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

• Брандмауэр Azure — это управляемый брандмауэр следующего поколения, предоставляющий возможности преобразования сетевых адресов (NAT ). Брандмауэр Azure фильтрует пакеты на основе IP-адресов и tcp-адресов или портов протокола UDP. Он может фильтровать трафик с помощью атрибутов на основе приложений, таких как HTTP(S) и SQL. Брандмауэр Azure также применяет аналитику угроз Майкрософт для выявления вредоносных IP-адресов. Дополнительные сведения см. в документации по брандмауэру Azure.

• Брандмауэр Azure Premium включает все функциональные возможности брандмауэра Azure Уровня "Стандартный", помимо таких функций, как проверка уровня транспорта (TLS) и система обнаружения вторжений и предотвращения вторжений (IDPS).

• Шлюз приложений — это подсистема балансировки нагрузки управляемого веб-трафика и полный обратный прокси-сервер HTTP(S), который может выполнять шифрование и расшифровку ssl. Шлюз приложений сохраняет исходный IP-адрес клиента в заголовке X-Forwarded-For HTTP. Шлюз приложений также использует брандмауэр веб-приложения Azure для проверки веб-трафика и обнаружения атак на уровне HTTP. Дополнительные сведения см. в документации по Шлюзу приложений.

• Брандмауэр веб-приложения является необязательным дополнением к Шлюзу приложений. Он проверяет HTTP-запросы и предотвращает атаки веб-слоя, такие как внедрение SQL и межсайтовые скрипты. Дополнительные сведения см. в документации по брандмауэру веб-приложений.

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

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

Блок-схема приложения	Может быть отфильтрован брандмауэром Azure	Можно фильтровать по брандмауэру веб-приложения в шлюзе приложений
Трафик HTTP(S) из локальной среды или Интернета в Azure (входящий трафик)	Да	Да
Трафик HTTP(S) из Azure в локальную среду или Интернет (исходящий)	Да	Нет
Трафик, отличный от HTTP(S) (входящий или исходящий)	Да	Нет

Дизайн может отличаться для каждого приложения в зависимости от необходимых сетевых потоков. На следующей схеме представлено упрощенное дерево принятия решений, которое помогает выбрать рекомендуемый подход для приложения. Этот выбор зависит от того, публикуется ли приложение через ПРОТОКОЛ HTTP(S) или другой протокол.

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

• Только брандмауэр Azure: Используйте эту структуру, если в виртуальной сети нет веб-приложений. Он управляет входящий трафик приложениями и исходящим трафиком.

• Только шлюз приложений. Используйте эту структуру, если только веб-приложения находятся в виртуальной сети и группах безопасности сети (NSG) обеспечивают достаточную фильтрацию выходных данных. Брандмауэр Azure предоставляет функциональные возможности, которые могут помочь предотвратить несколько сценариев атаки, таких как утечка данных и поставщики удостоверений. В результате дизайн шлюза приложений обычно не рекомендуется, поэтому он не включен в предыдущую блок-диаграмму.

• Брандмауэр Azure и шлюз приложений параллельно: Используйте эту структуру, если требуется, чтобы шлюз приложений защищал приложения HTTP(S) от веб-атак и брандмауэра Azure для защиты всех других рабочих нагрузок и фильтрации исходящего трафика. Брандмауэр Azure и шлюз приложений параллельно являются общим проектом.

• Шлюз приложений перед брандмауэром Azure: Используйте эту структуру, если требуется, чтобы брандмауэр Azure проверял весь трафик, брандмауэр веб-приложений для защиты веб-трафика и приложения, чтобы определить исходный IP-адрес клиента. При проверке брандмауэра Azure Premium и TLS эта конструкция также поддерживает комплексный сценарий SSL.

• Брандмауэр Azure перед шлюзом приложений: Используйте эту структуру, если требуется, чтобы брандмауэр Azure проверял и фильтрировал трафик, прежде чем он достигнет шлюза приложений. Так как брандмауэр Azure не расшифровывает трафик HTTPS, его добавленная функциональность в шлюз приложений ограничена. Этот сценарий не описан в предыдущей блок-диаграмме.

Варианты этих фундаментальных конструкций описаны далее в этой статье и включают:

• локальные клиенты приложений.
• Центральные и периферийные сети.
• реализации службы Azure Kubernetes (AKS).

Вы можете добавить другие обратные прокси-службы, такие как шлюз управления API Azure или Azure Front Door. Вы также можете заменить ресурсы Azure виртуальными устройствами, отличными от Майкрософт(NVAs).

Заметка

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

Проектирование только брандмауэра Azure

Если в виртуальной сети нет веб-рабочих нагрузок, которые могут воспользоваться брандмауэром веб-приложений, можно использовать проект брандмауэра Azure только для брандмауэра. Дизайн в этом примере прост, но можно просмотреть поток пакетов, чтобы лучше понять более сложные проекты. В этой структуре весь входящий трафик отправляется в брандмауэр Azure через определяемые пользователем маршруты (UDR) для подключений из локальной среды или других виртуальных сетей Azure. Он обращается к общедоступному IP-адресу брандмауэра Azure для подключений из общедоступного Интернета, как показано на следующей схеме. Определяемые пользователем трафик направляют исходящий трафик из виртуальных сетей Azure в брандмауэр Azure, как показано в следующем диалоговом окне.

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Не применимо	Да
Трафик HTTP(S) из Azure в Интернет или локальную среду	Не применимо	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Не применимо	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Не применимо	Да

Брандмауэр Azure не проверяет входящий трафик HTTP(S). Но он может применять правила приложения уровня 3 и уровня 4 и полное доменное имя (FQDN). Брандмауэр Azure проверяет исходящий трафик HTTP(S) в зависимости от уровня брандмауэра Azure и настройки проверки TLS:

• Брандмауэр Azure Standard проверяет только атрибуты уровня 3 и 4 пакетов в правилах сети и заголовок HTTP узла в правилах приложения.

• Брандмауэр Azure Premium добавляет возможности, такие как проверка других заголовков HTTP (например, агента пользователя) и включение проверки TLS для более глубокого анализа пакетов. Однако брандмауэр Azure не совпадает с брандмауэром веб-приложения. Если у вас есть веб-рабочие нагрузки в виртуальной сети, рекомендуется использовать брандмауэр веб-приложения.

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

• В этом примере брандмауэр Azure автоматически развертывает несколько экземпляров с внешним IP-адресом 192.168.100.4 и внутренними адресами в диапазоне 192.168.100.0/26. Как правило, эти экземпляры не отображаются администратору Azure. Тем не менее, учитывая их, может быть полезно для устранения проблем с сетью.

• Если трафик поступает из локальной виртуальной частной сети (VPN) или шлюза Azure ExpressRoute вместо Интернета, клиент запускает подключение к IP-адресу виртуальной машины. Он не запускает подключение к IP-адресу брандмауэра, и брандмауэр по умолчанию не выполняет исходный NAT.

Архитектура

На следующей схеме показан поток трафика и предполагается, что IP-адрес экземпляра является 192.168.100.7.

Рабочий процесс

1. Клиент запускает подключение к общедоступному IP-адресу брандмауэра Azure.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AzFwPIP

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

   • Исходный IP-адрес: 192.168.100.7
   • IP-адрес назначения: 192.168.1.4

3. Виртуальная машина отвечает на запрос приложения, который изменяет ip-адреса источника и назначения. Для входящего потока не требуется UDR, так как исходный IP-адрес является IP-адресом брандмауэра Azure. UDR на схеме 0.0.0.0/0 предназначен для исходящих подключений, чтобы гарантировать, что пакеты в общедоступный Интернет проходят через брандмауэр Azure.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.100.7

4. Брандмауэр Azure отменяет операции SNAT и DNAT и передает ответ клиенту.

   • Исходный IP-адрес: AzFwPIP
   • IP-адрес назначения: ClientPIP

Проектирование только шлюза приложений

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

Заметка

Мы не рекомендуем эту структуру, так как с помощью брандмауэра Azure для управления исходящими потоками вместо того, чтобы полагаться исключительно на группы безопасности сети, помогает предотвратить атаки, такие как утечка данных. С помощью брандмауэра Azure вы можете убедиться, что рабочие нагрузки отправляют данные только в утвержденный список URL-адресов. Кроме того, группы безопасности сети работают только на уровне 3 и уровне 4 и не поддерживают полные доменные имена.

Ключевое отличие от предыдущей структуры брандмауэра Azure заключается в том, что шлюз приложений не служит устройством маршрутизации с помощью NAT. Вместо этого он работает как полный обратный прокси приложения. Этот подход означает, что шлюз приложений останавливает веб-сеанс от клиента и устанавливает отдельный сеанс с одним из серверных серверов. Входящие ПОДКЛЮЧЕНИЯ HTTP(S) из Интернета отправляются на общедоступный IP-адрес шлюза приложений, а подключения из Azure или локальной среды используют частный IP-адрес шлюза. Возврат трафика с виртуальных машин Azure следует стандартной маршрутизации виртуальной сети обратно в Шлюз приложений. Дополнительные сведения см. далее в этой статье. Исходящие интернет-потоки из виртуальных машин Azure отправляются непосредственно в Интернет.

В следующей таблице перечислены потоки трафика.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Не применимо
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Не применимо
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Не применимо
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Не применимо

Архитектура

В следующем примере пошагового руководства по пакету показано, как клиент обращается к размещенной виртуальной машине приложению из общедоступного Интернета.

Рабочий процесс

1. Клиент запускает подключение к общедоступному IP-адресу шлюза приложений.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AppGwPIP

2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, который находится 192.168.200.7 в этом примере. Экземпляр шлюза приложений, который получает запрос, останавливает подключение от клиента и устанавливает новое соединение с одним из внутренних серверов. Серверная часть отображает экземпляр Шлюза приложений в качестве исходного IP-адреса. Шлюз приложений X-Forwarded-For вставляет заголовок HTTP с IP-адресом исходного клиента.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра шлюза приложений: 192.168.200.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: ClientPIP

3. Виртуальная машина отвечает на запрос приложения и изменяет исходные и конечные IP-адреса. Виртуальная машина может получить доступ к шлюзу приложений, поэтому для нее не требуется UDR.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

4. Экземпляр шлюза приложений отвечает клиенту.

   • Исходный IP-адрес: AppGwPIP
   • IP-адрес назначения: ClientPIP

Шлюз приложений добавляет метаданные в заголовки HTTP пакета, например X-Forwarded-For заголовок, содержащий IP-адрес исходного клиента. Некоторые серверы приложений нуждаются в IP-адресе исходного клиента для обслуживания содержимого, зависящее от географического расположения, или для ведения журнала. Дополнительные сведения см. в статье Принцип работы шлюза приложений.

• В этом примере IP-адрес 192.168.200.7 является одним из экземпляров, развернутых службой шлюза приложений автоматически. Он имеет внутренний, частный внешний IP-адрес 192.168.200.4. Эти отдельные экземпляры обычно невидимы для администратора Azure. Но выяснять разницу могут быть полезными, например при устранении неполадок в сети.

• Поток аналогичен, если клиент поступает из локальной сети через VPN или шлюз ExpressRoute. Разница заключается в том, что клиент обращается к частному IP-адресу шлюза приложений вместо общедоступного IP-адреса.

Заметка

Дополнительные сведения о X-Forwarded-For заголовке и сохранении имени узла в запросе см. в разделе "Сохранение исходного узла HTTP".

Брандмауэр Azure и шлюз приложений в параллельном проектировании

Благодаря простоте и гибкости часто рекомендуется параллельно запускать шлюз приложений и брандмауэр Azure.

Реализуйте эту структуру, если в виртуальной сети есть как веб-, так и не веб-рабочие нагрузки. Брандмауэр веб-приложения в Шлюзе приложений помогает защитить входящий трафик к веб-рабочим нагрузкам. Брандмауэр Azure проверяет входящий трафик для других приложений. Брандмауэр Azure охватывает исходящие потоки из обоих типов рабочих нагрузок.

Входящий HTTP(S) подключения из Интернета должны отправляться на общедоступный IP-адрес шлюза приложений. Подключения HTTP(S) из Azure или локальной среды должны отправляться в частный IP-адрес. Маршрутизация стандартной виртуальной сети отправляет пакеты из шлюза приложений на конечные виртуальные машины и из конечных виртуальных машин обратно в шлюз приложений. Дополнительные сведения см. далее в этой статье.

Для входящих подключений, отличных от HTTP(S), трафик должен быть направлен на общедоступный IP-адрес брандмауэра Azure, если он поступает из общедоступного Интернета. Трафик должен отправляться через брандмауэр Azure определяемыми пользователями, если он поступает из других виртуальных сетей Azure или локальных сетей. Все исходящие потоки из виртуальных машин Azure перенаправляются в брандмауэр Azure с помощью определяемых пользователем пользователей.

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Нет
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Да

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

Архитектуры

На следующей схеме показан поток трафика для входящих подключений HTTP(S) из внешнего клиента.

На следующей схеме показан поток трафика для исходящих подключений из сетевых виртуальных машин в Интернет. Одним из примеров является подключение к внутренним системам или получение обновлений операционной системы.

Шаги потока пакетов для каждой службы совпадают с предыдущими автономными параметрами проектирования.

Шлюз приложений перед проектированием брандмауэра Azure

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

С помощью брандмауэра Azure Premium эта конструкция может поддерживать комплексные сценарии, в которых брандмауэр Azure применяет проверку TLS для выполнения проверки IDPS на зашифрованном трафике между шлюзом приложений и веб-серверной частью.

Эта конструкция подходит для приложений, которые должны определять входящие IP-адреса источника клиента. Например, его можно использовать для обслуживания содержимого, зависяющего от географического расположения, или для ведения журнала. Шлюз приложений перед конструктором брандмауэра Azure записывает исходный IP-адрес входящего пакета в заголовке X-Forwarded-For , поэтому веб-сервер может видеть исходный IP-адрес в этом заголовке. Дополнительные сведения см. в статье Принцип работы шлюза приложений.

Для входящих ПОДКЛЮЧЕНИй HTTP(S) из Интернета необходимо отправить общедоступный IP-адрес шлюза приложений. Подключения HTTP(S) из Azure или локальной среды должны отправляться в частный IP-адрес. Из шлюза приложений определяемые пользователем UDR гарантируют, что пакеты направляются через брандмауэр Azure. Дополнительные сведения см. далее в этой статье.

Для входящих подключений, отличных от HTTP(S), трафик должен быть направлен на общедоступный IP-адрес брандмауэра Azure, если он поступает из общедоступного Интернета. Трафик должен отправляться через брандмауэр Azure определяемыми пользователями, если он поступает из других виртуальных сетей Azure или локальных сетей. Все исходящие потоки из виртуальных машин Azure перенаправляются в брандмауэр Azure с помощью определяемых пользователем пользователей.

Важным аспектом этой структуры является то, что брандмауэр Azure Premium видит трафик с исходным IP-адресом из подсети шлюза приложений. Если эта подсеть настроена с частным IP-адресом (в 10.0.0.0/8, 192.168.0.0/16172.16.0.0/12или100.64.0.0/10) Брандмауэр Azure Premium обрабатывает трафик из шлюза приложений как внутренний и не применяет правила IDPS для входящего трафика. В результате рекомендуется изменить частные префиксы IDPS в политике брандмауэра Azure. Это изменение гарантирует, что подсеть шлюза приложений не считается внутренним источником, что позволяет применять к трафику сигнатуры входящих и исходящих поставщиков удостоверений. Дополнительные сведения о направлениях правил поставщика удостоверений брандмауэра Azure и префиксах частных IP-адресов для поставщиков удостоверений брандмауэра Azure см. в правилах поставщиков удостоверений брандмауэра Azure.

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Да
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Да

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

• Шлюз приложений шифрует трафик, следуя принципам нулевого доверия, таким как сквозное шифрование TLS, и брандмауэр Azure получает зашифрованный трафик. Брандмауэр Azure "Стандартный" по-прежнему может применять правила проверки, такие как фильтрация уровня 3 и уровня 4 в правилах сети или полное доменное имя в правилах приложений с помощью заголовка "Указание имени сервера TLS" (SNI). Брандмауэр Azure Premium обеспечивает более глубокую видимость с проверкой TLS, например фильтрацией на основе URL-адресов.

• Если шлюз приложений отправляет незашифрованный трафик на серверы приложений, брандмауэр Azure видит входящий трафик в виде ясного текста. Проверка TLS не требуется в брандмауэре Azure.

• Если поставщик удостоверений включен в брандмауэре Azure, он проверяет, соответствует ли заголовок узла HTTP целевому IP-адресу. Для выполнения этой проверки требуется разрешение имен для полного доменного имени, указанного в заголовке узла. Это разрешение имен можно выполнить с помощью частных зон Azure DNS и параметров DNS брандмауэра Azure по умолчанию. Его также можно достичь с помощью пользовательских DNS-серверов, которые необходимо настроить в параметрах брандмауэра Azure. Если у вас нет административного доступа к виртуальной сети, в которой развернут брандмауэр Azure, последний метод является единственным вариантом. Одним из примеров является развертывание экземпляров брандмауэра Azure в центрах, защищенных виртуальной глобальной сетью Azure.

Архитектура

Для остальных потоков, которые включают входящий трафик, отличный от HTTP(S) и любой исходящий трафик, Брандмауэр Azure предоставляет проверку idPS и проверку TLS, где это подходит. Он также предоставляет фильтрацию на основе FQDN в правилах сети на основе DNS.

Рабочий процесс

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

1. Клиент запускает подключение к общедоступному IP-адресу шлюза приложений.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AppGwPIP

2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, который находится 192.168.200.7 в этом примере. Экземпляр шлюза приложений останавливает подключение от клиента и устанавливает новое подключение с одной из внутренних серверов. UDR 192.168.1.0/24 в подсети шлюза приложений перенаправит пакет в брандмауэр Azure и сохраняет целевой IP-адрес в веб-приложение.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра шлюза приложений: 192.168.200.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: ClientPIP

3. Брандмауэр Azure не применяет SNAT к трафику, так как трафик переходит к частному IP-адресу. Он перенаправит трафик на виртуальную машину приложения, если это разрешено правилами. Дополнительные сведения см. в статье об использовании SNAT для диапазонов частных IP-адресов в Брандмауэре Azure. Однако если трафик попадает в правило приложения в брандмауэре, рабочая нагрузка видит исходный IP-адрес конкретного экземпляра брандмауэра, который обработал пакет, так как брандмауэр Azure прокси-серверы подключения.

   • Исходный IP-адрес, если трафик разрешен правилом сети брандмауэра Azure и является частным IP-адресом одного из экземпляров шлюза приложений: 192.168.200.7
   • Исходный IP-адрес, если трафик разрешен правилом приложения брандмауэра Azure и является частным IP-адресом одного из экземпляров брандмауэра Azure: 192.168.100.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: ClientPIP

4. Виртуальная машина отвечает на запрос, который изменяет ip-адреса источника и назначения. UDR для 192.168.200.0/24 записи пакета, отправленного шлюзу приложений, перенаправляет его в брандмауэр Azure и сохраняет целевой IP-адрес к шлюзу приложений.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

5. Опять же, брандмауэр Azure не применяет SNAT к трафику, так как он переходит к частному IP-адресу и пересылает трафик в шлюз приложений.

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

6. Экземпляр шлюза приложений отвечает клиенту.

   • Исходный IP-адрес: AppGwPIP
   • IP-адрес назначения: ClientPIP

Исходящие потоки из виртуальных машин в общедоступный Интернет проходят через брандмауэр Azure, который определяет UDR 0.0.0.0/0 .

В качестве варианта этой структуры вы можете настроить частный DNAT в брандмауэре Azure, чтобы рабочая нагрузка приложения видела IP-адреса экземпляров брандмауэра Azure в качестве источника, и не требуются определяемые пользователем UDR. Исходный IP-адрес клиентов приложения уже сохраняется в заголовке X-Forwarded-For HTTP шлюзом приложений. Поэтому, если брандмауэр Azure применяет DNAT к трафику, информация не будет потеряна. Дополнительные сведения см. в статье "Фильтрация входящего трафика в Интернете или интрасети с помощью политики брандмауэра Azure DNAT" с помощью портала Azure.

Брандмауэр Azure перед проектированием шлюза приложений

Эта схема позволяет брандмауэру Azure фильтровать и удалять вредоносный трафик, прежде чем он достигнет шлюза приложений. Например, он может применять такие функции, как фильтрация на основе аналитики угроз. Еще одним преимуществом является то, что приложение получает один и тот же общедоступный IP-адрес для входящего и исходящего трафика независимо от протокола. Существует три режима, в которых можно теоретически настроить брандмауэр Azure:

• Брандмауэр Azure с правилами DNAT: Брандмауэр Azure переключает IP-адреса только на уровне IP-адресов, но не обрабатывает полезные данные. В результате он не изменяет ни один из заголовков HTTP.

• Брандмауэр Azure с правилами приложения и проверкой TLS отключен: Брандмауэр Azure может просмотреть заголовок SNI в TLS, но он не расшифровывает его. Новое TCP-подключение создается из брандмауэра к следующему прыжку. В этом примере это шлюз приложений.

• Брандмауэр Azure с включенными правилами приложений и проверкой TLS: Брандмауэр Azure просматривает содержимое пакета и расшифровывает их. Он служит прокси-сервером HTTP и может задать заголовки X-Forwarded-For HTTP для сохранения IP-адреса. Однако он представляет самогенерированный сертификат клиенту. Для интернет-приложений использование самогенерированного сертификата не является вариантом, так как предупреждение системы безопасности отправляется клиентам приложений из браузера.

В первых двух вариантах, которые являются единственными допустимыми параметрами для интернет-приложений, брандмауэр Azure применяет SNAT к входящего трафика без задания заголовка X-Forwarded-For . В результате приложение не может видеть исходный IP-адрес HTTP-запросов. Для административных задач, таких как устранение неполадок, можно получить фактический IP-адрес клиента для конкретного подключения, связав его с журналами SNAT брандмауэра Azure.

Преимущества этого сценария ограничены, так как если вы не используете проверку TLS и предоставляете самогенерированные сертификаты клиентам, брандмауэр Azure видит только зашифрованный трафик, который переходит в шлюз приложений. Этот сценарий обычно возможен только для внутренних приложений. Однако могут возникнуть сценарии, в которых эта конструкция предпочтительна. Один из сценариев заключается в том, что другой брандмауэр веб-приложения существует ранее в сети (например, с Azure Front Door), который может записать исходный IP-адрес в заголовке X-Forwarded-For HTTP. Вы также можете предпочесть эту структуру, если требуется много общедоступных IP-адресов, так как Шлюз приложений поддерживает один IP-адрес.

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

В следующей таблице перечислены потоки трафика для этого сценария.

Течь	Проходит через шлюз приложений или брандмауэр веб-приложения	Проходит через брандмауэр Azure
Трафик HTTP(S) из Интернета или локальной среды в Azure	Да	Да
Трафик HTTP(S) из Azure в Интернет или локальную среду	Нет	Да
Трафик, отличный от HTTP(S) из Интернета или локальной среды в Azure	Нет	Да
Трафик, отличный от HTTP(S) из Azure в Интернет или локальную среду	Нет	Да

Для входящего трафика HTTP(S) брандмауэр Azure обычно не расшифровывает трафик. Вместо этого применяются политики IDPS, для которых не требуется проверка TLS, например фильтрация IP-адресов или использование заголовков HTTP.

Архитектура

Приложение не может видеть исходный IP-адрес веб-трафика. Брандмауэр Azure применяет SNAT к пакетам по мере их входа в виртуальную сеть. Чтобы избежать этой проблемы, используйте Azure Front Door перед брандмауэром. Azure Front Door внедряет IP-адрес клиента в качестве заголовка HTTP перед вводом виртуальной сети Azure.

схема

Рабочий процесс

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

1. Клиент запускает подключение к общедоступному IP-адресу брандмауэра Azure.

   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AzFWPIP

2. Запрос к общедоступному IP-адресу брандмауэра Azure распространяется на внутренний экземпляр брандмауэра, который находится 192.168.100.7 в этом примере. Брандмауэр Azure применяет DNAT к веб-порту, обычно TCP 443, к частному IP-адресу экземпляра шлюза приложений. Брандмауэр Azure также применяет SNAT при выполнении DNAT. Дополнительные сведения см. в статье известных проблем брандмауэра Azure.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра брандмауэра Azure: 192.168.100.7
   • IP-адрес назначения: 192.168.200.4

3. Шлюз приложений устанавливает новый сеанс между экземпляром, обрабатывающим подключение и один из внутренних серверов. Исходный IP-адрес клиента не в пакете.

   • Исходный IP-адрес, который является частным IP-адресом экземпляра шлюза приложений: 192.168.200.7
   • IP-адрес назначения: 192.168.1.4
   • X-Forwarded-For заголовок: 192.168.100.7

4. Виртуальная машина отвечает на шлюз приложений, который изменяет ip-адреса источника и назначения:

   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.200.7

5. Шлюз приложений отвечает на IP-адрес источника SNAT экземпляра брандмауэра Azure. Брандмауэр Azure видит внутренний IP-адрес шлюза приложений, .4как исходный IP-адрес, даже если подключение поступает из определенного экземпляра шлюза приложений, например .7.

   • Исходный IP-адрес: 192.168.200.4
   • IP-адрес назначения: 192.168.100.7

6. Брандмауэр Azure отменяет SNAT и DNAT и отвечает клиенту.

   • Исходный IP-адрес: AzFwPIP
   • IP-адрес назначения: ClientPIP

Шлюз приложений должен иметь общедоступный IP-адрес, чтобы корпорация Майкрософт ей управляла, даже если у нее нет прослушивателей, настроенных для приложений.

Заметка

Маршрут 0.0.0.0/0 по умолчанию в подсети шлюза приложений, указывающей на брандмауэр Azure, не поддерживается, так как он нарушает трафик плоскости управления, необходимый шлюзу приложений для правильной работы.

Локальные клиенты

Предыдущие проекты отображают все входящие клиенты приложений из общедоступного Интернета. Локальные сети также обращаются к приложениям. Большинство предыдущих данных и потоков трафика совпадают с интернет-клиентами, но существуют некоторые заметные различия:

• VPN-шлюз или шлюз ExpressRoute находится перед брандмауэром Azure или шлюзом приложений.

• Брандмауэр веб-приложения использует частный IP-адрес шлюза приложений.

• Брандмауэр Azure не поддерживает DNAT для частных IP-адресов, поэтому необходимо использовать UDR для отправки входящего трафика в брандмауэр Azure из VPN или шлюзов ExpressRoute.

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

Архитектура

На следующей схеме показана параллельная конструкция шлюза приложений и брандмауэра Azure. Клиенты приложений приходят из локальной сети, подключенной к Azure через VPN или ExpressRoute:

Даже если все клиенты находятся в локальной среде или в Azure, шлюзе приложений и брандмауэре Azure должны иметь общедоступные IP-адреса. Эти общедоступные IP-адреса позволяют корпорации Майкрософт управлять службами.

Топология концентратора и периферийной топологии

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

Архитектура

• Брандмауэр Azure развертывается в центральной виртуальной сети концентратора. На предыдущей схеме показано, как развернуть шлюз приложений в концентраторе. Команды приложений часто управляют такими компонентами, как шлюзы приложений или шлюзы управления API. В этом сценарии эти компоненты развертываются в периферийных виртуальных сетях.

• Обратите особое внимание на определяемые пользователем пользовательский тип в периферийных сетях. Когда сервер приложений в периферии получает трафик от определенного экземпляра брандмауэра Azure, например 192.168.100.7 IP-адреса в предыдущих примерах, он должен отправлять трафик обратно в тот же экземпляр. Если UDR в периферийной части задает следующий прыжок трафика, адресованного концентратору, к IP-адресу брандмауэра Azure (192.168.100.4 на предыдущих схемах), возвращаемые пакеты могут оказаться в другом экземпляре брандмауэра Azure. Эта ситуация приводит к асимметричной маршрутизации. Если у вас есть UDR в периферийных виртуальных сетях, обязательно отправьте трафик в общие службы в концентраторе через брандмауэр Azure. Эти определяемые пользователем правила не включают префикс подсети брандмауэра Azure.

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

• Невозможно задать следующий прыжок для подсетей шлюза приложений или брандмауэра Azure через статические маршруты с типом следующего прыжка Virtual Network. Этот тип следующего прыжка действителен только в локальной виртуальной сети, а не в пирингах виртуальных сетей. Дополнительные сведения о типах определяемых пользователем пользователей и следующих прыжков см. в разделе "Маршрутизация трафика виртуальной сети".

Асимметричная маршрутизация

На следующей схеме показано, как периферийный сервер отправляет трафик SNAT обратно в подсистему балансировки нагрузки Azure брандмауэра Azure. Эта настройка приводит к асимметричной маршрутизации.

Чтобы решить эту проблему, определите UDR в периферийной сети без подсети брандмауэра Azure и только подсети, в которых находятся общие службы. На предыдущей схеме правильный UDR в периферии должен содержать 192.168.1.0/24только . Он не должен содержать весь диапазон 192.168.0.0/16, помеченный красным цветом.

Интеграция с другими продуктами Azure

Брандмауэр Azure и шлюз приложений можно интегрировать с другими продуктами и службами Azure.

Шлюз управления API

Интеграция обратных прокси-служб, таких как шлюз управления API в предыдущие проекты, чтобы обеспечить такие функции, как регулирование API или прокси-сервер проверки подлинности. Интеграция шлюза управления API значительно не влияет на проекты. Ключевое различие заключается в том, что вместо одного обратного прокси-сервера шлюза приложений есть два обратных прокси-сервера, цепочки друг за другом.

Дополнительные сведения см. в руководстве по проектированию для интеграции управления API и шлюза приложений в виртуальной сети ишлюзов API шаблонов приложений для микрослужб.

AKС

Для рабочих нагрузок, работающих в кластере AKS, можно развернуть шлюз приложений независимо от кластера. Кроме того, вы можете интегрировать его с кластером AKS с помощью контроллера входящего трафика шлюза приложений. При настройке определенных объектов на уровнях Kubernetes, таких как службы и входящий трафик, шлюз приложений автоматически адаптируется без дополнительных действий вручную.

Брандмауэр Azure играет важную роль в безопасности кластера AKS. Он предоставляет необходимые функции для фильтрации исходящего трафика из кластера AKS на основе полного доменного имени, а не только IP-адреса. Дополнительные сведения см. в разделе "Ограничение сетевого трафика с помощью брандмауэра Azure" в AKS.

При объединении шлюза приложений и брандмауэра Azure для защиты кластера AKS рекомендуется использовать вариант параллельного проектирования. Шлюз приложений с брандмауэром веб-приложения обрабатывает входящие запросы на подключение к веб-приложениям в кластере. Брандмауэр Azure разрешает только явно разрешенные исходящие подключения. Дополнительные сведения о параметре параллельного проектирования см. в разделе "Базовая архитектура" для кластера AKS.

Azure Front Door (облачное сетевое решение от Microsoft)

Azure Front Door имеет функциональные возможности, которые перекрываются с Шлюзом приложений в нескольких областях. Обе службы обеспечивают брандмауэр веб-приложения, разгрузку SSL и маршрутизацию на основе URL-адресов. Однако ключевым отличием является то, что в то время как шлюз приложений работает в виртуальной сети, Azure Front Door является глобальной, децентрализованной службой.

Иногда можно упростить проектирование виртуальной сети, заменив Шлюз приложений децентрализованной службой Azure Front Door. Большинство проектов, описанных в этой статье, по-прежнему применяются, за исключением возможности разместить брандмауэр Azure перед Azure Front Door.

Один из сценариев — использовать брандмауэр Azure перед шлюзом приложений в виртуальной сети. Шлюз приложений вводит X-Forwarded-For заголовок с IP-адресом экземпляра брандмауэра, а не IP-адресом клиента. Обходным решением является использование Azure Front Door перед брандмауэром X-Forwarded-For для внедрения IP-адреса клиента в качестве заголовка, прежде чем трафик входит в виртуальную сеть и достигает брандмауэра Azure. Вы также можете защитить источник с помощью Приватного канала Azure в Azure Front Door Premium.

Дополнительные сведения о различиях между двумя службами или о том, когда они используются, см. в разделе часто задаваемые вопросы о Azure Front Door.

Другие NVAs

Продукты Майкрософт не являются единственным выбором для реализации брандмауэра веб-приложения или функций брандмауэра следующего поколения в Azure. Широкий спектр партнеров Майкрософт предоставляет NVA. Основные понятия и конструкции, как и в этой статье, но существуют некоторые важные аспекты.

• Сетевые сети партнеров для брандмауэра следующего поколения могут обеспечить больший контроль и гибкость конфигураций NAT, которые не поддерживают брандмауэр Azure. Примеры включают DNAT из локальной среды или DNAT из Интернета без SNAT.

• Управляемые Azure NVAs, такие как Шлюз приложений и брандмауэр Azure, снижают сложность по сравнению с NVAs, где пользователям необходимо обрабатывать масштабируемость и устойчивость во многих устройствах.

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

Участников

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Автор субъекта:

• Хосе Морено | Главный инженер клиента

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

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

Дополнительные сведения о технологиях компонентов:

• Что такое Шлюз приложений?
• Что такое брандмауэр Azure?
• Что такое Azure Front Door?
• AKS
• Что такое виртуальная сеть?
• Что такое брандмауэр веб-приложения?
• Базовая архитектура кластера AKS

Связанные ресурсы

Изучите связанные архитектуры:

• Реализация безопасной гибридной сети
• безопасно управляемых веб-приложений
• Мультитенантное программное обеспечение как услуга в Azure
• Корпоративное развертывание с помощью среды службы приложений
• Высокодоступное корпоративное развертывание с помощью среды службы приложений