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

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

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

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

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

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

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

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

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

• Брандмауэр Azure Premium выполняет проверки безопасности:

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

• Если пакеты проходят тесты, брандмауэр Azure Premium выполняет следующие действия:

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

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

• Брандмауэр веб-приложения использует правила для предотвращения атак на веб-уровне. Примеры атак включают внедрение кода SQL и межсайтовые скрипты. Дополнительные сведения о правилах и наборе основных правил проекта безопасности веб-приложений (OWASP) см. в группах правил и правилах брандмауэра веб-приложений CRS.
• Брандмауэр Azure Premium использует универсальные правила обнаружения и предотвращения вторжений. Эти правила помогают выявлять вредоносные файлы и другие угрозы, предназначенные для веб-приложений.

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

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

Разрешение имен брандмауэра Azure уровня "Премиум" и "Имя"

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

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

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

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

ПОДКЛЮЧЕНИЯ TLS

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

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

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

Из шлюза приложений в брандмауэр Azure Premium

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

С брандмауэра Azure Premium на веб-сервер

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

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

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

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

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

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

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

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

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

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

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

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

• Настройка частной зоны DNS.
• Свяжите зону с виртуальной сетью, содержащей брандмауэр Azure Premium.
• Убедитесь, что запись A существует для значения, которое шлюз приложений использует для трафика и для проверок работоспособности.

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

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

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

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

Топология виртуальной глобальной сети

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

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

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

  • Настройте параметры 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 Premium.
4. Брандмауэр Azure Premium запрашивает разрешение DNS с DNS-сервера в виртуальной сети общих служб.
5. DNS-сервер отвечает на запрос разрешения.
6. Брандмауэр Azure Premium выполняет проверки безопасности пакетов. Если они передают тесты, брандмауэр Azure Premium перенаправит пакеты на виртуальную машину приложения.
7. Виртуальная машина отвечает и задает целевой IP-адрес шлюзу приложений. Подсеть приложения перенаправляет пакеты в брандмауэр Azure Premium.
8. Брандмауэр Azure Premium перенаправит пакеты в шлюз приложений.
9. Шлюз приложений отправляет пакеты в VPN.
10. VPN-подключение отвечает клиенту.

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

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

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

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

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

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

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

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

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

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

Как описано в правилах поставщиков удостоверений брандмауэра Azure, брандмауэр Azure Premium решит, какие правила idPS применяются в зависимости от исходных и целевых IP-адресов пакетов. Брандмауэр Azure будет обрабатывать частные IP-адреса по умолчанию в диапазонах RFC 1918 (10.0.0.0/8, 192.168.0.0/16 и 172.16.0.0/12) и RFC 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, этот диапазон можно исключить из списка внутренних префиксов для поставщиков удостоверений (см. диапазоны частных IPDS брандмауэра Azure premium дополнительные сведения о том, как это сделать) и развернуть шлюз приложений в подсети, настроенной с IP-адресом в 100.64.0.0/10.

Участников

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

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

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

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

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

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

• [Защита рабочих нагрузок и управление ими с помощью сегментации уровня сети][Защита рабочих нагрузок и управление ими с помощью сегментации уровня сети]
• Реализация безопасной гибридной сети
• топология сети концентратора в Azure
• топология сети концентратора с помощью виртуальной глобальной сети Azure