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

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

• защиты от атак DDoS Azure, в сочетании с рекомендациями по проектированию приложений, предоставляет расширенные функции защиты от атак DDoS. Вы должны включить защиту от атак DDOS Azure в любой виртуальной сети периметра.
• Брандмауэр Azure — это управляемый брандмауэр следующего поколения, который предлагает преобразование сетевых адресов (NAT). Брандмауэр Azure использует фильтрацию пакетов по IP-адресам и протоколам управления передачей и портам протокола TCP/UDP или на основе атрибутов HTTP(S) на основе приложений или SQL. Брандмауэр Azure также применяет аналитику угроз Майкрософт для идентификации вредоносных IP-адресов. Дополнительные сведения см. в документации по брандмауэру Azure.
• брандмауэра Azure уровня "Премиум" включает все функции брандмауэра Azure уровня "Стандартный" и другие функции, такие как проверка TLS и система обнаружения вторжений и защиты (IDPS).
• шлюз приложений Azure — это подсистема балансировки нагрузки управляемого веб-трафика и полный обратный прокси-сервер HTTP(S), который может выполнять шифрование и расшифровку SSL. Шлюз приложений сохраняет исходный IP-адрес клиента в заголовке X-Forwarded-For HTTP. Шлюз приложений также использует брандмауэр веб-приложения для проверки веб-трафика и обнаружения атак на уровне HTTP. Дополнительные сведения см. в документации по шлюзу приложений .
• брандмауэр веб-приложений Azure (WAF) является необязательным дополнением к шлюзу приложений Azure. Он обеспечивает проверку HTTP-запросов и предотвращает вредоносные атаки на веб-уровне, такие как внедрение SQL или межсайтовый скрипт. Дополнительные сведения см. в документациипо брандмауэру веб-приложений .

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

Брандмауэр Azure и Шлюз приложений Azure используют различные технологии, и они поддерживают обеспечение ценных бумаг различных потоков:

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

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

• брандмауэра Azure только, если в виртуальной сети нет веб-приложений. Он будет контролировать как входящий трафик в приложения, так и исходящий трафик.
• шлюз приложений только, если только веб-приложения находятся в виртуальной сети, а группы безопасности сети (NSG) обеспечить достаточную фильтрацию выходных данных. Функциональные возможности, предоставляемые брандмауэром Azure, могут предотвратить множество сценариев атаки (например, кражу данных, поставщики удостоверений и т. д.). По этой причине только сценарий шлюза приложений не рекомендуется и поэтому не документируется и не находится в приведенной выше блок-диаграмме.
• Брандмауэр Azure и шлюз приложений параллельно, который является одним из наиболее распространенных проектов. Используйте это сочетание, если требуется, чтобы шлюз приложений Azure защищал приложения HTTP(S) от веб-атак и Брандмауэр Azure для защиты всех других рабочих нагрузок и фильтрации исходящего трафика.
• Шлюз приложений передбрандмауэра Azure, если требуется, чтобы брандмауэр Azure проверял весь трафик, WAF для защиты веб-трафика и приложения, чтобы узнать исходный IP-адрес клиента. При проверке брандмауэра Azure Premium и TLS эта конструкция также поддерживает комплексный сценарий SSL.
• Брандмауэр Azure передшлюза приложений, если требуется, чтобы брандмауэр Azure проверял и фильтрировал трафик, прежде чем он достигнет шлюза приложений. Так как брандмауэр Azure не собирается расшифровывать трафик HTTPS, функциональные возможности, добавляемые в шлюз приложений, ограничены. Этот сценарий не описан в приведенной выше блок-диаграмме.

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

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

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

Только брандмауэр Azure

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

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

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

• Служба "Стандартный" брандмауэра Azure проверяет только атрибуты уровня 3 & уровня 4 пакетов в правилах сети и заголовок HTTP узла в правилах приложения.
• Брандмауэр Azure Premium добавляет такие возможности, как проверка других заголовков HTTP (например, User-Agent) и включение проверки TLS для более глубокого анализа пакетов. Брандмауэр Azure не эквивалентен брандмауэру веб-приложения. Если у вас есть веб-рабочие нагрузки в виртуальной сети, настоятельно рекомендуется использовать WAF.

В следующем примере пошагового руководства по пакету показано, как клиент обращается к размещенной виртуальной машине приложению из общедоступного Интернета. Схема включает только одну виртуальную машину для простоты. Для повышения доступности и масштабируемости у вас будет несколько экземпляров приложений за подсистемой балансировки нагрузки. В этой структуре брандмауэр 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. Правило NAT назначения (DNAT) брандмауэра Azure преобразует IP-адрес назначения в IP-адрес приложения в виртуальной сети. Брандмауэр Azure также исходные nats (SNATs) пакет, если он выполняет 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/0 предназначен для исходящих подключений, чтобы убедиться, что пакеты в общедоступный Интернет проходят через брандмауэр Azure.
   • Исходный IP-адрес: 192.168.1.4
   • IP-адрес назначения: 192.168.100.7
4. Наконец, брандмауэр Azure отменяет операции SNAT и DNAT и передает ответ клиенту:
   • Исходный IP-адрес: AzFwPIP
   • IP-адрес назначения: ClientPIP

Только шлюз приложений

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

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

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

Архитектура

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

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

1. Клиент запускает подключение к общедоступному IP-адресу шлюза приложений Azure:
   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AppGwPIP
2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, в этом случае 192.168.200.7. Экземпляр шлюза приложений, который получает запрос, останавливает подключение от клиента и устанавливает новое подключение с одной из внутренних серверов. Серверная часть отображает экземпляр Шлюза приложений в качестве исходного IP-адреса. Шлюз приложений вставляет заголовок HTTP X-Forwarded-For с исходным IP-адресом клиента.
   • Исходный IP-адрес: 192.168.200.7 (частный IP-адрес экземпляра шлюза приложений)
   • 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

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

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

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

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

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

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

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

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

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

Архитектуры

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

схема

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

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

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

Эта схема более подробно описана в сети нулевого доверия для веб-приложений с помощью брандмауэра Azure и шлюза приложений, в этом документе будет сосредоточено внимание на сравнении с другими вариантами проектирования. В этой топологии входящий веб-трафик проходит через брандмауэр Azure и WAF. WAF обеспечивает защиту на уровне веб-приложения. Брандмауэр 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/16, 172.16.0.0/12 или 100.64.0.0/10), брандмауэр Azure Firewall Premium будет обрабатывать трафик из шлюза приложений как внутренний и не будет применять правила IDPS для входящего трафика. Дополнительные сведения о направлениях правил поставщика удостоверений брандмауэра Azure и префиксах частных IP-адресов для поставщиков удостоверений можно найти в правилах поставщиков удостоверений брандмауэра Azure. Следовательно, рекомендуется изменить частные префиксы IDPS в политике брандмауэра Azure, чтобы подсеть шлюза приложений не считалась внутренним источником, чтобы применить к трафику входящий и исходящий сигнатуры IDPS.

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

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

1. Шлюз приложений шифрует трафик после принципов нулевого доверия (сквозного шифрования TLS), а брандмауэр Azure получит зашифрованный трафик. Тем не менее, Брандмауэр Azure Standard сможет применять правила проверки, такие как фильтрация уровня 3 & уровня 4 в правилах сети или полное доменное имя в правилах приложений с помощью заголовка "Указание имени сервера TLS" (SNI). Брандмауэр Azure Premium обеспечивает более глубокую видимость с проверкой TLS, например фильтрацией на основе URL-адресов.
2. Если шлюз приложений отправляет незашифрованный трафик на серверы приложений, брандмауэр Azure увидит входящий трафик в виде ясного текста. Проверка TLS не требуется в брандмауэре Azure.
3. Если поставщик удостоверений включен в брандмауэре Azure, убедитесь, что заголовок узла HTTP соответствует целевому IP-адресу. Для этого потребуется разрешение имен для полного доменного имени, указанного в заголовке узла. Это разрешение имен можно достичь с помощью частных зон Azure DNS и параметров DNS брандмауэра Azure по умолчанию с помощью Azure DNS. Его также можно достичь с помощью пользовательских DNS-серверов, которые необходимо настроить в параметрах брандмауэра Azure. (Дополнительные сведения см. в разделе Параметры DNS брандмауэра Azure.) Если нет административного доступа к виртуальной сети, в которой развернут брандмауэр Azure, последний метод является единственным вариантом. Одним из примеров является развертывание брандмауэров Azure в защищенных центрах виртуальной глобальной сети.

Архитектура

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

схема

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

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

1. Клиент запускает подключение к общедоступному IP-адресу шлюза приложений Azure:
   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AppGwPIP
2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, в этом случае 192.168.200.7. Экземпляр шлюза приложений останавливает подключение от клиента и устанавливает новое соединение с одним из внутренних серверов. UDR для 192.168.1.0/24 в подсети шлюза приложений перенаправит пакет в брандмауэр Azure, сохраняя конечный IP-адрес в веб-приложение:
   • Исходный IP-адрес: 192.168.200.7 (частный IP-адрес экземпляра шлюза приложений)
   • IP-адрес назначения: 192.168.1.4
   • Заголовок X-Forwarded-For: ClientPIP
3. Брандмауэр Azure не SNAT трафик, так как трафик собирается на частный IP-адрес. Он перенаправит трафик на виртуальную машину приложения, если это разрешено правилами. Дополнительные сведения см. в брандмауэра Azure. Однако если трафик попадает в правило приложения в брандмауэре, рабочая нагрузка увидит исходный IP-адрес конкретного экземпляра брандмауэра, обрабатывающего пакет, так как брандмауэр Azure будет прокси-подключение:
   • Исходный IP-адрес, если трафик разрешен правилом сети брандмауэра Azure: 192.168.200.7 (частный IP-адрес одного из экземпляров шлюза приложений).
   • Исходный IP-адрес, если трафик разрешен правилом приложения брандмауэра Azure: 192.168.100.7 (частный IP-адрес одного из экземпляров брандмауэра Azure).
   • 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.

Шлюз приложений после брандмауэра

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

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

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

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

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

Архитектура

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

схема

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

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

1. Клиент запускает подключение к общедоступному IP-адресу брандмауэра Azure:
   • Исходный IP-адрес: ClientPIP
   • IP-адрес назначения: AzFWPIP
2. Запрос к общедоступному IP-адресу брандмауэра Azure распространяется на внутренний экземпляр брандмауэра, в этом случае 192.168.100.7. Брандмауэр Azure ДНКТ веб-порта, как правило, TCP 443, к частному IP-адресу экземпляра шлюза приложений. Брандмауэр Azure также SNATs при выполнении DNAT. Дополнительные сведения см. в статье известных проблем брандмауэра Azure:
   • Исходный IP-адрес: 192.168.100.7 (частный IP-адрес экземпляра брандмауэра Azure)
   • IP-адрес назначения: 192.168.200.4
3. Шлюз приложений устанавливает новый сеанс между экземпляром, обрабатывающий подключение и один из внутренних серверов. Исходный IP-адрес клиента не в пакете:
   • Исходный IP-адрес: 192.168.200.7 (частный IP-адрес экземпляра шлюза приложений)
   • 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. Даже если подключение поступает из определенного экземпляра шлюза приложений, например .7, брандмауэр Azure видит внутренний IP-адрес шлюза приложений .4 в качестве исходного IP-адреса:
   • Исходный IP-адрес: 192.168.200.4
   • IP-адрес назначения: 192.168.100.7
6. Наконец, брандмауэр Azure отменяет SNAT и DNAT и отвечает клиенту:
   • Исходный IP-адрес: AzFwPIP
   • IP-адрес назначения: ClientPIP

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

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

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

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

Архитектура

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

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

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

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

Архитектура

Соображения

Ниже приведены некоторые рекомендации по этой топологии.

• Брандмауэр Azure развертывается в центральной виртуальной сети концентратора. На приведенной выше схеме показано, как развернуть шлюз приложений в концентраторе. Группы приложений часто управляют такими компонентами, как шлюзы приложений Azure или шлюзы управления API Azure, хотя. В этом случае эти компоненты развертываются в периферийных виртуальных сетях.
• Обратите особое внимание на определяемые пользователем сети в периферийных сетях: когда сервер приложений в периферии получает трафик от определенного экземпляра брандмауэра Azure, например адрес 192.168.100.7 в предыдущих примерах, он должен отправлять трафик обратно в тот же экземпляр. Если UDR в периферии задает следующий прыжок трафика, адресованного концентратору, к IP-адресу брандмауэра Azure (192.168.100.4 на приведенных выше схемах), возвращаемые пакеты могут в конечном итоге оказаться в другом экземпляре брандмауэра Azure, что приводит к асимметричной маршрутизации. Убедитесь, что если у вас есть UDR в периферийных виртуальных сетями для отправки трафика в общие службы в концентраторе через брандмауэр Azure, эти определяемые пользователем элементы не включают префикс подсети брандмауэра Azure.
• Предыдущая рекомендация применяется одинаково к подсети шлюза приложений и любым другим сетевым виртуальным устройствам или обратным прокси-серверам, которые могут быть развернуты в центральной виртуальной сети.
• Невозможно задать следующий прыжок для подсетей шлюза приложений или брандмауэра Azure через статические маршруты с типом следующего прыжка Virtual Network. Этот тип следующего прыжка действителен только в локальной виртуальной сети, а не между пирингами виртуальной сети. Дополнительные сведения о определяемых пользователем маршрутах и типах следующего прыжка см. в маршрутизации трафика виртуальной сети.

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

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

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

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

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

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

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

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

Служба Azure Kubernetes

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

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

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

Azure Front Door

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

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

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

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

Другие сетевые виртуальные устройства

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

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

Участников

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

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

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

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

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

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

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

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

• Реализация безопасной гибридной сети
• безопасно управляемых веб-приложений
• Защита бота канала Microsoft Teams и веб-приложения за брандмауэра
• вопросы безопасности для приложений IaaS с высокой степенью конфиденциальности в Azure
• Multitenant SaaS в Azure
• развертывание Enterprise с помощью среды служб приложений
• корпоративное развертывание с высоким уровнем доступности с помощью среды служб приложений
• базовая архитектура для кластера Службы Azure Kubernetes (AKS)