Сеть для веб-приложений с Брандмауэром Azure и Шлюзом приложений, действующая по принципу “Никому не доверяй”

Шлюз приложений Azure
Брандмауэр Azure
Виртуальная сеть Azure
Виртуальная глобальная сеть Azure (WAN)
Брандмауэр веб-приложения Azure

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

Как правило, различные типы сетевых устройств проверяют разные аспекты сетевых пакетов.

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

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

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

Скачайте файл Visio для этой архитектуры.

Эта архитектура использует протокол TLS для шифрования трафика на каждом этапе.

  • Клиент отправляет пакеты в Шлюз приложений — подсистему балансировки нагрузки. Эта подсистема действует в сочетании с дополнительной службой Брандмауэр веб-приложений Azure.

  • Шлюз приложений расшифровывает пакеты и ищет угрозы для веб-приложений. Если найти угрозы не удается, пакеты шифруются в соответствии с принципом “Никому не доверяй”. Затем служба разблокирует пакеты.

  • Брандмауэр Azure ценовой категории “Премиум” проводит следующие проверки безопасности:

  • Если пакеты проходят тесты, Брандмауэр Azure ценовой категории “Премиум” выполняет следующие действия.

    • Шифрует пакеты
    • Определяет виртуальную машину приложения (VM) с помощью службы доменных имен (DNS)
    • Пересылает пакеты на виртуальную машину приложения

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

  • Брандмауэр веб-приложений использует правила для предотвращения атак на веб-уровне. Примеры атак: внедрение кода SQL и межсайтовые сценарии. Подробнее о правилах, а также о наборе основных правил Open Web Application Security Project (OWASP) см. в разделе Правила и группы правил CRS Брандмауэра веб-приложений.
  • Брандмауэр Azure ценовой категории “Премиум” использует правила обнаружения и предотвращения типовых вторжений. Эти правила помогают определить вредоносные файлы и другие угрозы, нацеленные на веб-приложения.

Эта архитектура поддерживает различные типы проектирования сети, которые обсуждаются в этой статье:

  • сети с традиционной звездообразной топологией;
  • сети, использующие Виртуальную глобальную сеть Azure в качестве платформы;
  • сети, использующие Azure Route Server для упрощения динамической маршрутизации.

Брандмауэр Azure ценовой категории “Премиум” и разрешение имен

При проверке на наличие вредоносного трафика Брандмауэр Azure ценовой категории “Премиум” смотрит, совпадает ли заголовок узла HTTP с IP-адресом пакета и портом TCP. Например, предположим, что Шлюз приложений отправляет веб-пакеты на IP-адрес 172.16.1.4 и в порт TCP 443. Значение заголовка узла HTTP должно разрешаться в этот IP-адрес.

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

Примечание.

Шлюз приложений не поддерживает номера портов в заголовках узла HTTP. В результате:

  • Брандмауэр Azure ценовой категории “Премиум” предполагает, что по умолчанию используется TCP-порт HTTPS 443.
  • Подключение между Шлюзом приложений и веб-сервером поддерживается только для TCP-порта 443, а не для нестандартных портов.

Цифровые сертификаты

На следующей схеме показаны общие имена (CN) и центры сертификации (ЦС), используемые в сеансах и сертификатах TLS архитектуры.

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

Подключения TLS

Эта архитектура содержит три отдельных подключения TLS. Цифровые сертификаты проверяют каждое из них.

От клиентов к Шлюзу приложений

В Шлюзе приложений развертывается цифровой сертификат, который видят клиенты. Хорошо известный ЦС, например DigiCert или Let's Encrypt, как правило, выдает такой сертификат.

От Шлюза приложений к Брандмауэру Azure ценовой категории “Премиум”

Чтобы расшифровать и проверить трафик TLS, Брандмауэр Azure ценовой категории “Премиум” динамически создает сертификаты. Он также предоставляет себя Шлюзу приложений в качестве веб-сервера. Частный ЦС подписывает сертификаты, создаваемые Брандмауэром Azure ценовой категории “Премиум”. Подробнее см. на странице Сертификаты Брандмауэра Azure ценовой категории "Премиум". Шлюзу приложений необходимо проверить эти сертификаты. В параметрах HTTP приложения настраивается корневой ЦС, используемый Брандмауэром Azure ценовой категории "Премиум".

От Брандмауэра Azure ценовой категории "Премиум" к веб-серверу

Брандмауэр Azure Premium устанавливает сеанс TLS с целевым веб-сервером. и проверяет, подписаны ли пакеты TLS веб-сервера известным ЦС.

Роли компонентов

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

  • Шлюз приложений является обратным веб-прокси. Он защищает веб-серверы от вредоносных клиентов, перехватывая запросы HTTP и HTTPS. Вы объявляете каждый защищенный сервер во внутреннем пуле Шлюза приложений, указывая его IP-адрес или полное доменное имя. Легальные клиенты должны иметь возможность доступа к каждому приложению. Поэтому Шлюз приложений настраивается с помощью цифрового сертификата, подписанного общедоступным ЦС. Используйте ЦС, который будет принимать любой клиент TLS.
  • Брандмауэр Azure ценовой категории "Премиум" — это веб-прокси переадресации, или просто веб-прокси. Он защищает клиенты от вредоносных веб-серверов, перехватывая вызовы TLS от защищенных клиентов. Когда защищенный клиент выполняет HTTP-запрос, прокси-сервер переадресации олицетворяет целевой веб-сервер, создавая цифровые сертификаты и представляя их клиенту. Брандмауэр Azure ценовой категории "Премиум" использует частный ЦС, который подписывает динамически создаваемые сертификаты. Защищенные клиенты настраиваются таким образом, чтобы они доверяли этому частному ЦС. В этой архитектуре Брандмауэр Azure ценовой категории "Премиум" защищает запросы от Шлюза приложений к веб-серверу. Шлюз приложений доверяет частному ЦС, используемому Брандмауэром Azure ценовой категории "Премиум".

Маршрутизация и пересылка трафика

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

  • Шлюз приложений Azure всегда ведет себя как прокси-сервер, а Брандмауэр Azure Premium также выполняется при настройке проверки TLS: сеансы TLS от клиентов будут прерваны Шлюз приложений, а новые сеансы TLS будут созданы для Брандмауэр Azure. Брандмауэр Azure будут получать и завершать сеансы TLS, полученные из Шлюз приложений, и создавать новые сеансы TLS для рабочих нагрузок. Этот факт имеет последствия для конфигурации поставщиков удостоверений Брандмауэр Azure Premium, в разделах ниже содержатся дополнительные сведения об этом.
  • Рабочая нагрузка увидит подключения, поступающие из IP-адреса подсети Брандмауэр Azure. Исходный IP-адрес клиента сохраняется в заголовке X-Forwarded-For HTTP, вставленном Шлюз приложений.
  • Трафик из Шлюз приложений в рабочую нагрузку обычно отправляется в Брандмауэр Azure с помощью механизмов маршрутизации Azure либо с определяемыми пользователем маршрутами, настроенными в подсети Шлюз приложений, либо с маршрутами, введенными azure Виртуальная глобальная сеть или сервером маршрутов Azure. Хотя явное определение частного IP-адреса Брандмауэр Azure в серверном пуле Шлюз приложений возможно, это технически не рекомендуется, так как он отнимает некоторые из функций Брандмауэр Azure, таких как балансировка нагрузки и прилипание.

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

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

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

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

Благодаря традиционным звездообразным архитектурам частные зоны DNS обеспечивают простой способ использования DNS:

  • Настройте частную зону DNS.
  • Свяжите ее с виртуальной сетью, содержащей Брандмауэр Azure ценовой категории "Премиум".
  • Убедитесь, что для значения, которое Шлюз приложений использует для трафика и проверок работоспособности, существует запись A.

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

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

  1. Клиент отправляет запрос на веб-сервер.
  2. Шлюз приложений перехватывает пакеты клиента и проверяет их. Если пакеты проходят проверку, Шлюз приложений отправляет пакет виртуальной машине сервера. Когда пакет достигает Azure, пакеты в подсети Шлюза приложений по определяемому пользователем маршруту (UDR) перенаправляются в Брандмауэр Azure ценовой категории "Премиум".
  3. Брандмауэр Azure ценовой категории “Премиум” проверяет безопасность пакетов. Если тесты пройдены успешно, Брандмауэр Azure ценовой категории “Премиум” перенаправляет пакеты на виртуальную машину приложения.
  4. Виртуальная машина отвечает и задает IP-адрес назначения Шлюзу приложений. UDR в подсети виртуальной машины перенаправляет пакеты в Брандмауэр Azure ценовой категории “Премиум”.
  5. Брандмауэр Azure ценовой категории “Премиум” перенаправляет пакеты в Шлюз приложений.
  6. Шлюз приложений отвечает клиенту.

Трафик также может поступать из локальной сети, а не из общедоступного Интернета. Трафик проходит через виртуальную частную сеть (VPN) типа "сеть — сеть" или через ExpressRoute. В этом сценарии трафик сначала достигает шлюза виртуальной сети в сети концентратора. Остальная часть сетевого потока движется так же, как в предыдущем случае.

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

  1. Локальный клиент подключается к шлюзу виртуальной сети.
  2. Шлюз перенаправляет пакеты клиента в Шлюз приложений.
  3. Шлюз приложений проверяет пакеты. Если они прошли проверку, UDR в подсети Шлюза приложений пересылает пакеты в Брандмауэр Azure ценовой категории “Премиум”.
  4. Брандмауэр Azure ценовой категории “Премиум” проверяет безопасность пакетов. Если тесты пройдены успешно, Брандмауэр Azure ценовой категории “Премиум” перенаправляет пакеты на виртуальную машину приложения.
  5. Виртуальная машина отвечает и задает IP-адрес назначения Шлюзу приложений. UDR в подсети виртуальной машины перенаправляет пакеты в Брандмауэр Azure ценовой категории “Премиум”.
  6. Брандмауэр Azure ценовой категории “Премиум” перенаправляет пакеты в Шлюз приложений.
  7. Шлюз приложений отправляет пакеты шлюзу виртуальной сети.
  8. Шлюз отвечает клиенту.

топология Виртуальная глобальная сеть

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

При использовании Виртуальной глобальной сети в качестве сетевой платформы наблюдаются два основных отличия:

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

    • Настройте Параметры DNS Брандмауэра Azure для использования пользовательских DNS-серверов.
    • Разверните серверы в виртуальной сети общих служб, которую вы подключаете к виртуальной глобальной сети.
    • Свяжите частную зону DNS с виртуальной сетью общих служб. DNS-серверы могут затем разрешить имена, которые Шлюз приложений использует в заголовках узла HTTP. Подробнее см. на странице Параметры DNS Брандмауэра Azure.
  • Виртуальную глобальную сеть можно использовать для программирования маршрутов на периферии, только если префикс короче (более общий), чем префикс виртуальной сети. Например, на схемах над периферийной виртуальной сетью имеется префикс 172.16.0.0/16: в этом случае Виртуальная глобальная сеть не сможет внедрить маршрут, соответствующий префиксу виртуальной сети (172.16.0.0/16) или любой из подсетей (172.16.0.0/24, 172.16.1.0/24). Другими словами, Виртуальная глобальная сеть не может привлечь трафик между двумя подсетями, которые находятся в одной виртуальной сети. Это ограничение становится очевидным, если Шлюз приложений и целевой веб-сервер находятся в одной виртуальной сети: Виртуальная глобальная сеть не может принудительно заставить трафик между Шлюз приложений и веб-сервером проходить через Брандмауэр Azure Premium (обходное решение будет вручную настраивать определяемые пользователем маршруты в подсетях Шлюз приложений и веб-сервера).

На следующей схеме показан поток пакетов, когда используется Виртуальная глобальная сеть. В этом случае доступ к Шлюзу приложений осуществляется из локальной сети. VPN типа "сеть — сеть" или ExpressRoute связывает эту сеть с виртуальной глобальной сетью. Доступ из Интернета осуществляется аналогично.

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

  1. Локальный клиент подключается к VPN.
  2. VPN перенаправляет пакеты клиентов в Шлюз приложений.
  3. Шлюз приложений проверяет пакеты. Если они прошли проверку, подсеть Шлюза приложений пересылает пакеты Брандмауэру Azure ценовой категории “Премиум”.
  4. Брандмауэр Azure ценовой категории “Премиум запрашивает разрешение DNS у DNS-сервера в виртуальной сети общих служб.
  5. DNS-сервер отвечает на запрос разрешения.
  6. Брандмауэр Azure ценовой категории “Премиум” проверяет безопасность пакетов. Если тесты пройдены успешно, Брандмауэр Azure ценовой категории “Премиум” перенаправляет пакеты на виртуальную машину приложения.
  7. Виртуальная машина отвечает и задает IP-адрес назначения Шлюзу приложений. Подсеть приложения перенаправляет пакеты в Брандмауэр Azure Premium.
  8. Брандмауэр Azure ценовой категории “Премиум” перенаправляет пакеты в Шлюз приложений.
  9. Шлюз приложений отправляет пакеты в VPN.
  10. VPN отвечает клиенту.

При использовании такой схемы, возможно, придется изменить маршрутизацию, которую концентратор объявляет в периферийных виртуальных сетях. В частности, Шлюз приложений версии 2 поддерживает маршрут 0.0.0.0/0, только если он указывает на Интернет. Маршруты с таким адресом, не указывающие на Интернет, блокируют возможность подключения, которая требуется корпорации Майкрософт для управления Шлюзом приложений. Если виртуальный концентратор объявляет маршрут 0.0.0.0/0, предотвратите его распространение в подсеть Шлюза приложений, выполнив одно из следующих действий.

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

Топология сервера маршрутизации

Route Server обеспечивает другой способ автоматического внедрения маршрутов в периферийные сети. Эта функция позволяет избежать административных издержек при обслуживании таблиц маршрутизации. Route Server объединяет Виртуальную глобальную сеть и различные сети со звездообразной топологией.

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

На следующей схеме показан поток пакетов, когда Route Server упрощает динамическую маршрутизацию. Обратите внимание на следующие моменты.

  • Для Route Server в настоящее время требуется устройство, которое внедряет маршруты для их отправки по протоколу BGP. Так как Брандмауэр Azure ценовой категории “Премиум” не поддерживает BGP, используйте вместо него сетевой виртуальный модуль (NVA) стороннего производителя.
  • Функции NVA в концентраторе определяют, требуется ли DNS для вашей реализации.

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

  1. Локальный клиент подключается к шлюзу виртуальной сети.
  2. Шлюз перенаправляет пакеты клиента в Шлюз приложений.
  3. Шлюз приложений проверяет пакеты. Если они прошли проверку, подсеть Шлюза приложений пересылает пакеты серверу. Маршрут в подсети Шлюза приложений, добавленный Route Server, перенаправлял бы трафик в NVA.
  4. NVA проверяет пакеты на безопасность. Если тесты пройдены успешно, NVA перенаправляет пакеты на виртуальную машину приложения.
  5. Виртуальная машина отвечает и задает IP-адрес назначения Шлюзу приложений. Маршрут, который Route Server добавил в подсеть виртуальной машины, перенаправляет пакеты в NVA.
  6. NVA пересылает пакеты Шлюзу приложений.
  7. Шлюз приложений отправляет пакеты шлюзу виртуальной сети.
  8. Шлюз отвечает клиенту.

Как и в случае с Виртуальной глобальной сетью, при использовании Route Server может потребоваться изменить маршрутизацию. Если вы объявите маршрут 0.0.0.0/0, он может распространиться в подсеть Шлюза приложений. Но Шлюз приложений не поддерживает этот маршрут. В этом случае настройте таблицу маршрутизации для подсети Шлюза приложений. Включите в нее маршрут для 0.0.0.0/0 и тип Internet следующего прыжка.

Поставщики удостоверений и частные IP-адреса

Как описано в правилах Брандмауэр Azure IDPS, Брандмауэр Azure Premium решит, какие правила поставщиков удостоверений следует применять в зависимости от исходных и целевых IP-адресов пакетов. Брандмауэр Azure будет обрабатывать частные IP-адреса по умолчанию в диапазонах RFC 1918 (10.0.0.0/8192.168.0.0/16и) и 172.16.0.0/12RFC 6598 (100.64.0.0/10) как внутренние. Следовательно, если как в схемах в этой статье Шлюз приложений развертывается в подсети в одной из этих диапазонов (172.16.0.0/24в примерах выше), Брандмауэр Azure Premium рассмотрит трафик между Шлюз приложений и рабочая нагрузка, которая должна быть внутренней, и будут использоваться только подписи IDPS, которые будут применяться к внутреннему трафику или любому трафику. Подписи IDPS, помеченные для входящего или исходящего трафика, не будут применяться к трафику между Шлюз приложений и рабочей нагрузкой.

Самый простой способ принудительного применения правил входящего подписи IDPS к трафику между Шлюз приложений и рабочей нагрузкой заключается в размещении Шлюз приложений в подсети с префиксом вне частных диапазонов. Вам не обязательно нужно использовать общедоступные IP-адреса для этой подсети, но вместо этого можно настроить IP-адреса, которые Брандмауэр Azure Premium рассматриваются как внутренние для поставщиков удостоверений. Например, если ваша организация не использует 100.64.0.0/10 диапазон, этот диапазон можно исключить из списка внутренних префиксов для поставщиков удостоверений (Брандмауэр Azure дополнительные сведения о том, как это сделать) и развернуть Шлюз приложений в подсети, настроенной с IP-адресом.100.64.0.0/10

Соавторы

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

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

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