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

Чтобы защитить рабочие нагрузки приложений 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, если в виртуальной сети нет веб-приложений. Брандмауэр будет управлять входящим трафиком к приложениям и исходящим трафиком.
• Только Шлюз приложений, если в виртуальной сети размещены только веб-приложения, и группы безопасности сети обеспечивают достаточную фильтрацию выходных данных. Функциональные возможности, предоставляемые Брандмауэр Azure, могут предотвратить множество сценариев атаки (например, кражу данных, поставщики удостоверений и т. д.). По этой причине Шлюз приложений один сценарий обычно не рекомендуется и поэтому не документируется и не находится в приведенной выше блок-диаграмме.
• Брандмауэр Azure и Шлюз приложений параллельно — один из наиболее распространенных вариантов проектирования. Используйте эту комбинацию, если вам нужно, чтобы Шлюз приложений Azure защищал от атак веб-приложения HTTP(S), а Брандмауэр Azure — все остальные рабочие нагрузки и фильтровал исходящий трафик.
• Шлюз приложений перед Брандмауэром Azure. Еще одна популярная схема — это когда необходимо, чтобы Брандмауэр Azure проверял весь трафик и WAF обеспечивал защиту веб-трафика, а приложению необходимо знать исходный IP-адрес клиента. При использовании Брандмауэра Azure категории "Премиум" и проверки TLS такое проектирование также поддерживает сценарий комплексного шифрования SSL.
• Брандмауэр Azure перед Шлюзом приложений. Если требуется, чтобы Брандмауэр Azure проверял и фильтровал трафик до того, как он достигнет Шлюза приложений. Поскольку Брандмауэр Azure не предполагает расшифровку трафика HTTPS, его функциональные возможности, которыми он дополняет Шлюз приложений, ограничены. Этот сценарий не описан в приведенной выше блок-схеме.

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

• Клиенты локальных приложений.
• Звездообразные сети.
• Реализации Службы Azure Kubernetes.

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

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

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

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

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

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

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

Важно отметить, что Брандмауэр Azure Premium увидит трафик с исходным IP-адресом из подсети Шлюз приложений. Если эта подсеть настроена с частным IP-адресом (в 10.0.0.0/8192.168.0.0/16, 172.16.0.0/12 или100.64.0.0/10), Брандмауэр Azure Premium будет обрабатывать трафик из Шлюз приложений как внутренний и не будет применять правила IDPS для входящего трафика. Дополнительные сведения о направлениях правил 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-адресу. Для этого ей потребуется разрешение имен для FQDN, указанного в заголовке Host. Это разрешение имен можно получить с помощью Частных зон Azure DNS и стандартных параметров DNS Брандмауэра Azure, используя Azure DNS. Или с помощью пользовательских DNS-серверов, которые необходимо настроить в параметрах Брандмауэра Azure. (Дополнительные сведения см. в разделе Брандмауэр Azure DNS Параметры.) Если нет административного доступа к виртуальная сеть, где развертывается Брандмауэр Azure, последний метод является единственной возможностью. Один из примеров — Брандмауэры Azure, развернутые в защищенных концентраторах Виртуальной глобальной сети.

Архитектура

Для остальных потоков (входящий трафик, не относящийся к HTTP(S), и любой исходящий трафик) в Брандмауэре Azure будет обеспечена проверка на основе системы обнаружения вторжений и защиты от них и TLS, где это необходимо. Она также обеспечивает фильтрацию на основе полного доменного имени в сетевых правилах на основе 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-адрес экземпляра Шлюза приложений Azure)
   • Целевой IP-адрес: 192.168.1.4
   • Заголовок X-Forwarded-For: ClientPIP
3. Служба "Брандмауэр Azure" не может преобразовывать сетевые адреса источника для трафика, поскольку трафик направляется на частный IP-адрес. Поэтому она переадресовывает трафик на виртуальную машину приложения, если это разрешено правилами. Дополнительные сведения см. в статье со сравнением SNAT Брандмауэра 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" не может преобразовывать сетевые адреса источника для трафика, поскольку трафик направляется на частный 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 преобразовывает сетевые адреса источника для входящего трафика, поэтому приложение не будет видеть исходный IP-адрес HTTP-запросов. С точки зрения администрирования, например для устранения неполадок, можно получить фактический IP-адрес клиента для определенного подключения, соотнося его с журналами SNAT Брандмауэр Azure.

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

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

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

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

Архитектура

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

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

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

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

Архитектура

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

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

Звездообразная топология

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

Архитектура

Рекомендации

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

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

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

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

Чтобы устранить эту проблему, определите определяемые пользователем маршруты в периферийной сети без подсети Брандмауэра Azure, но с подсетями, в которых размещены общие службы. Для этого примера правильный определяемый пользователем маршрут в периферийной сети должен содержать только адрес 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.

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

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

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

Соавторы

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

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

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

Следующие шаги

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

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

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

Сведения о связанных архитектурах:

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