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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Architecture

На следующей схеме показан поток трафика и предполагается, что 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-адрес является Брандмауэр Azure IP-адресом. 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 заключается в том, что Application Gateway не выполняет функции устройства маршрутизации с NAT. Вместо этого он работает как полный обратный прокси приложения. Такой подход означает, что шлюз приложений завершает веб-сеанс от клиента и устанавливает отдельный сеанс с одним из серверных серверов. Входящий ТРАФИК HTTP(S) из Интернета отправляется на общедоступный IP-адрес шлюза приложений, а подключения из Azure или локальной среды используют частный IP-адрес шлюза. Возврат трафика из виртуальных машин Azure следует стандартной маршрутизации виртуальной сети обратно к шлюзу приложений. Для получения дополнительной информации см. в этой статье раздел о последовательном прохождении пакетов. Исходящие интернет-потоки из виртуальных машин Azure отправляются непосредственно в интернет.

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

Architecture

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

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

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

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

2. Запрос к общедоступному IP-адресу шлюза приложений распространяется на внутренний экземпляр шлюза, который находится 192.168.200.7 в этом примере. Экземпляр шлюза приложений, который получает запрос, завершает подключение от клиента и устанавливает новое подключение с одним из серверов обработки. Бэкэнд воспринимает экземпляр шлюза приложения как исходный IP-адрес. Шлюз приложений вставляет в заголовок 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-адреса.

Брандмауэр Azure и Application Gateway в параллельной архитектуре

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

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

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

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

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

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

Архитектуры

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

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

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

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

Дополнительные сведения об этой структуре см. в статье "Реализация сети нулевого доверия для веб-приложений с помощью брандмауэра 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 пользовательскими маршрутами (UDR), если он поступает из других виртуальных сетей 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 Premium обрабатывает трафик из шлюза приложений как внутренний и не применяет правила IDPS для входящего трафика. В результате мы рекомендуем изменить частные префиксы IDPS в политике Брандмауэр Azure. Это изменение гарантирует, что подсеть шлюза приложений не считается внутренним источником, что позволяет применять сигнатуры IDPS (системы предотвращения вторжений и обнаружения вторжений) к входящему и исходящему трафику. Дополнительные сведения о направлениях правил и префиксах частных IP-адресов для системы обнаружения и предотвращения вторжений (IDPS) брандмауэра Azure см. в правилах IDPS брандмауэра Azure.

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

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

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

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

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

Architecture

Для остальных потоков, которые включают входящий трафик, отличный от 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-адресу. Он перенаправит трафик на виртуальную машину приложения, если это разрешено правилами. Дополнительные сведения см. в разделе диапазоны частных IP-адресов SNAT в Брандмауэр 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 к трафику, информация не будет потеряна. Дополнительные сведения см. в разделе Фильтрация входящего интернет-трафика или внутреннего трафика с помощью политики DNAT Брандмауэр Azure через портал 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 существует ранее в сети (например, с Azure Front Door), который может записать исходный IP-адрес в заголовке X-Forwarded-For HTTP. Вы также можете предпочесть эту структуру, если требуется много общедоступных IP-адресов, так как Шлюз приложений поддерживает один IP-адрес.

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

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

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

Architecture

Приложение не может видеть исходный 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. Шлюз приложений устанавливает новый сеанс между экземпляром, обрабатывающим подключение, и одним из серверов back-end. Исходный 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-адрес, чтобы корпорация Майкрософт ей управляла, даже если у нее нет прослушивателей, настроенных для приложений.

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

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

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

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

• Вы можете упростить структуру маршрутизации, настроив частный DNAT брандмауэра Azure , чтобы полное доменное имя приложения разрешалось в частный IP-адрес брандмауэра Azure. Если клиенты получают доступ к приложению по частному IP-адресу, используйте UDR в GatewaySubnet. Эти определяемые пользователем маршруты направляют трафик VPN или ExpressRoute в брандмауэр Azure.

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

Architecture

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

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

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

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

Architecture

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

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

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

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

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

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

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

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

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

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

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

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

AKS

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

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

При объединении шлюза приложений и Брандмауэр Azure для защиты кластера AKS рекомендуется использовать вариант параллельного проектирования. Шлюз приложений с брандмауэром веб-приложений Azure обрабатывает входящие запросы на подключение к веб-приложениям в кластере. Брандмауэр 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 перед брандмауэром для внедрения IP-адреса клиента в качестве заголовка X-Forwarded-For до того, как трафик входит в виртуальную сеть и достигает Брандмауэр Azure. Вы также можете защитить источник с помощью Приватного канала Azure в Azure Front Door Premium.

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

Другие NVAs

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

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

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

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

Соавторы

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

Основной автор:

• Хосе Морено | Инженер решений

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

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

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

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

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

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

• Реализация безопасной гибридной сети
• Безопасно управляемые веб-приложения
• Развертывание корпоративной инфраструктуры с высокой доступностью с помощью Среда службы приложений
• Развертывание корпоративного приложения с помощью Среда службы приложений