Брандмауэр веб-приложений для сетей Azure

Брандмауэр веб-приложений Azure (WAF) защищает ваши веб-приложения от распространенных атак на уровне HTTP, таких как SQL-инъекции, межсайтовый скриптинг (XSS) и обход путей. В отличие от Брандмауэр Azure, который проверяет трафик на уровнях 3–7 для угроз на уровне сети, WAF работает только на уровне 7 и понимает семантику HTTP, включая заголовки запросов, строки запроса, тела запросов и файлы cookie. Разверните WAF как политику, привязанную либо к Шлюз приложений Azure (региональный), либо к Azure Front Door (глобальная периферийная сеть), чтобы область защиты соответствовала архитектуре приложения. Брандмауэр веб-приложений — один из трёх основных сервисов сетевой безопасности Azure, наряду с Брандмауэр Azure и Azure DDoS Protection.

Описание этой статьи

В этой статье рассматривается защита уровня HTTP с помощью Брандмауэр веб-приложений Azure. Вы узнаете:

  • Сравнение платформ между WAF в Шлюзе приложений версии 2 и WAF на Azure Front Door.
  • Наборы правил на основе OWASP, включая набор правил по умолчанию (DRS) и набор основных правил (CRS).
  • Режим обнаружения и режим предотвращения и когда следует использовать каждый из них.
  • Варианты области действия политики WAF: глобальная, для каждого сайта и для каждого прослушивателя.
  • Пользовательские правила для ограничения скорости, геофильтрации и логики для конкретного приложения.
  • Различие между WAF (уровень 7 HTTP) и Брандмауэр Azure (сеть уровня 3–7).

Кто нуждается в этой статье

Разверните WAF, если рабочие нагрузки соответствуют одному или нескольким из следующих критериев:

  • Общедоступные веб-приложения: Ваши приложения принимают входящий трафик HTTP/HTTPS из Интернета, предоставляя им наиболее важные уязвимости OWASP, включая атаки на внедрение, нарушение проверки подлинности и попытки раскрытия конфиденциальных данных.
  • Требования к соответствию: Нормативные платформы, такие как PCI DSS (стандарт безопасности данных индустрии оплаты карточек) требует брандмауэра веб-приложения перед любым приложением, обрабатывающим данные карты оплаты.
  • Защита API: API являются общедоступными и требуют защиты от контрабанды запросов, избыточных полезных данных и атак на уровне протокола, которые брандмауэры сети не проверяют.
  • Защита от ботов: Необходимо классифицировать и контролировать автоматизированный трафик, блокируя вредоносных ботов и при этом разрешая доступ легитимным веб-краулерам и службам мониторинга.

Организации, которым требуется только фильтрация трафика на уровне сети (IP-адрес, порт и протокол) без проверки HTTP-запросов, должны использовать вместо этого Брандмауэр Azure или группы безопасности сети.

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

Акцент модернизации: Защитите клиентские веб-приложения с помощью WAF в Azure Front Door для глобальных приложений или в Application Gateway для приложений, развернутых в одном регионе, в соответствии с выбранным вариантом доставки — Front Door или Traffic Manager.

Кросс-облачный подход: Разверните WAF уровня 7 на шлюзе приложений Azure Application Gateway в сегменте spoke для перенесённых общедоступных веб-приложений и сопоставьте средства веб-защиты из других облаков (например, Google Cloud Armor) с Azure WAF.

Сравнение платформ Azure WAF

Azure WAF доступен на двух платформах. Каждая платформа интегрирует проверку WAF в другую точку в потоке трафика.

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

Capability WAF в шлюзе приложений версии 2 WAF на Azure Front Door
Область развертывания Региональный (один регион Azure) Глобальный (192+ пограничных точек присутствия по всему миру)
Точка проверки После того как трафик достигнет вашего региона На периферийном узле PoP, прежде чем трафик достигнет сервера-источника
Поддерживаемые наборы правил DRS 2.2, DRS 2.1, CRS 3.2 DRS 2.2, DRS 2.1, DRS 2.0
Настраиваемые правила ✔ ✔
Защита от ботов ✔ ✔ (Только уровень "Премиум")
Ограничение скорости ✔ ✔
Geo-filtering ✔ ✔
Политика на сайте ✔ (на прослушиватель, по пути) ✔ (для каждой конечной точки)
Управляемые наборы правил ✔ ✔ (Только уровень "Премиум"; Стандарт поддерживает только пользовательские правила)
Запросить осмотр кузова До 128 КБ (можно настроить) До 128 КБ (можно настроить)
Поддержка источника происхождения Приватный канал N/A (в связке с App Gateway) ✔ (подключение к частному источнику)
лучше всего подходит для Однорегионные приложения, балансировка нагрузки L7 + WAF Мультирегиональные приложения, глобальное ускорение + WAF

Note

Azure Front Door имеет два уровня: "Стандартный" и "Премиум". Управляемые наборы правил (включая drS и защиту ботов) доступны только в Front Door Premium. Front Door Standard поддерживает только пользовательские правила. Front Door (классическая версия) поддерживает только DRS 1.1 или более ранних версий.

Выбор платформы WAF

Используйте следующие критерии принятия решений:

  • Выберите WAF в Application Gateway, если приложение развертывается в одном регионе и вы уже используете Application Gateway для балансировки нагрузки уровня 7, завершения TLS или маршрутизации на основе путей. WAF добавляет встроенную инспекцию HTTP-трафика в потоке без дополнительного перехода через сервис.
  • Выберите WAF на Azure Front Door, если приложение охватывает несколько регионов, требует глобальной балансировки нагрузки или преимущества ускорения сети доставки содержимого (CDN). Front Door WAF анализирует трафик в ближайшей периферийной точке присутствия (PoP). Служба блокирует вредоносные запросы, прежде чем они пересекают магистраль Azure, чтобы получить доступ к источнику. Такой подход сокращает подверженность поверхности атаки и смягчает объёмные атаки уровня 7 на периферии сети.
  • Выберите вариант «Оба (многоуровневая)», если многорегиональное приложение, обслуживаемое Front Door, также требует региональных политик WAF, различающихся для каждого внутреннего сервера. Front Door обеспечивает первую линию глобальной защиты, а WAF шлюза приложений применяет пользовательские правила для конкретного региона ближе к рабочей нагрузке.

Рекомендации по проектированию

Фокус на дизайне WAF в режиме лифта и смены

  • Не используйте WAF для внутренних повторно размещённых рабочих нагрузок, не имеющих входящего доступа из Интернета; вернитесь к этому вопросу, когда будете публиковать приложение в Интернете.
  • Когда вы публикуете веб-приложение, сначала запустите WAF в режиме обнаружения, чтобы определить базовый профиль трафика, а затем, после корректировки правил для устранения ложных срабатываний, переключите его в режим предотвращения.
  • Используйте WAF Application Gateway для перенесённого без изменений веб-приложения, развёрнутого в одном регионе, для которого вы уже используете Application Gateway для маршрутизации на уровне 7.
  • Используйте логику правил веб-защиты в локальной инфраструктуре (например, правила OWASP) в качестве исходной политики.

Модернизация фокуса на дизайне WAF

  • Запустите WAF в режиме предотвращения с самого начала для клиентских приложений и установите последний управляемый набор правил, чтобы охват отслеживал новые угрозы OWASP автоматически.
  • Включите управление ботами, чтобы отделять легитимные краулеры от вредоносной автоматизации в ваших общедоступных приложениях.
  • Управляйте политикой WAF как кодом, чтобы региональные бэкенды в конфигурации active-active оставались синхронизированными через ваш конвейер развертывания.
  • Используйте периферийный WAF вместе с брандмауэром центрального узла для многоуровневой защиты и включите скидку на оплату WAF шлюза приложений, включив DDoS Network Protection в VNet.

Основные аспекты проектирования WAF для кросс-облачной среды

  • Размещение WAF уровня 7 в шлюзе приложений в периферийной виртуальной сети, поэтому общедоступный веб-трафик проверяется без подключения общедоступных IP-адресов непосредственно к виртуальным машинам.
  • Сопоставьте существующие средства веб-защиты из других облаков (например, AWS WAF или Google Cloud Armor) с наборами управляемых правил Azure WAF, чтобы сохранить охват защиты.
  • Проверьте общедоступный обмен данными через WAF и продолжайте проверку транзита между востоком и облаком на брандмауэре центра Виртуальная глобальная сеть.
  • Во время перехода сначала запустите WAF в режиме обнаружения (обучения), а затем выполните принудительное применение после подтверждения допустимых шаблонов трафика.

Prerequisites

Перед развертыванием Брандмауэр веб-приложений Azure убедитесь, что у вас есть:

  • Ресурс Application Gateway v2 или ресурс Azure Front Door: WAF развертывается как политика, связанная с одной из этих платформ. Перед созданием и привязкой политики WAF у вас уже должен быть подготовлен экземпляр Application Gateway v2 или профиль Azure Front Door.
  • Общедоступная рабочая нагрузка HTTP/HTTPS: Приложение должно получать входящий трафик HTTP/HTTPS. WAF проверяет семантику на уровне запроса и не обеспечивает преимущества для рабочих нагрузок, отличных от HTTP, или исключительно внутренних служб.
  • Общие сведения о шаблонах трафика HTTP: Знакомство с обычными шаблонами запросов приложения (заголовки, параметры запроса и содержимое текста) помогает настроить исключения и настроить правила для минимизации ложных срабатываний во время перехода режима обнаружения и предотвращения.

Наборы правил и обработка правил

WAF использует наборы правил для обнаружения вредоносных шаблонов в HTTP-запросах. Понимание иерархии правил и порядка обработки помогает настроить WAF для конкретных приложений.

Управляемые наборы правил

Microsoft поддерживает управляемые наборы правил на основе шаблонов основных наборов правил OWASP (CRS). Рекомендуемый набор правил для новых развертываний — DRS 2.2 (набор правил по умолчанию). DRS 2.2 основан на OWASP CRS 3.3.4 и включает сигнатуры Microsoft Threat Intelligence.

Набор правил На основе Поддержка платформы Recommendation
DRS 2.2 OWASP CRS 3.3.4 + Microsoft Threat Intel Шлюз приложений версии 2, Front Door Premium Рекомендуется для новых развертываний
DRS 2.1 OWASP CRS 3.3 Шлюз приложений версии 2, Front Door Premium Предыдущее поколение; поддерживается на обеих платформах
DRS 2.0 OWASP CRS 3.2 Только Front Door Premium Поддерживается; Версия Front Door N-2
CRS 3.2 OWASP CRS 3.2 Только шлюз приложений версии 2 Поддерживается; использование DRS 2.2 для новых развертываний

Наборы правил DRS и CRS используют оценку аномалий. Каждое правило сопоставления вносит оценку вместо немедленного блокирования запроса. Если совокупная оценка аномалий превышает настраиваемое пороговое значение, WAF принимает действие (блок или журнал). Этот подход уменьшает число ложноположительных срабатываний по сравнению с блокировкой по отдельным правилам, поскольку одно совпадение с низкой степенью уверенности не приводит к срабатыванию блокировки.

Настраиваемые правила

Пользовательские правила выполняются до управляемых правил и используют номера приоритетов для управления порядком оценки (более низкое число = более высокий приоритет). Используйте настраиваемые правила для:

  • Ограничение частоты запросов: Ограничьте количество запросов от каждого IP-адреса клиента в пределах заданного временного окна, чтобы предотвратить атаки с использованием скомпрометированных учетных данных и атаки перебором.
  • Геофильтрация: Разрешить или запретить трафик на основе страны или региона происхождения клиента.
  • Списки разрешённых и запрещённых IP-адресов: Разрешайте IP-адреса известных партнёров или блокируйте известных злоумышленников до применения управляемых правил.
  • Проверка заголовка запроса: Применяйте требования, относящиеся к приложению, такие как обязательные ключи API или ожидаемые типы контента.

Набор правил защиты от ботов

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

Режим обнаружения против режима предотвращения

Политики WAF работают в одном из двух режимов, определяющих, как система обрабатывает соответствующие запросы:

Режим Behavior Сценарий использования
Обнаружение Регистрирует совпавшие запросы, но не блокирует их. Запросы продолжают поступать на серверную часть. Первоначальное развертывание и настройка правил. Отслеживайте, какие правила активируются без влияния на рабочий трафик.
Предотвращение Блокирует соответствующие запросы и возвращает ответ 403. Регистрирует заблокированный запрос. Продуктивные рабочие нагрузки после завершения настройки правила. Активная защита от атак.
  1. Развертывание в режиме обнаружения: Включите WAF с выбранным набором правил в режиме обнаружения. Маршрутизация рабочего трафика через WAF.
  2. Проанализируйте журналы: Просмотрите журналы WAF, чтобы определить ложные срабатывания. Определите правила, которые срабатывают на легитимный трафик приложения.
  3. Создайте исключения: Для правил, которые приводят к ложным срабатываниям, настройте исключения, указывающие, какие поля запроса (заголовки, файлы cookie и параметры строки запроса) следует пропускать для определённых правил.
  4. Переключитесь в режим предотвращения: После 1–2 недель журналов обнаружения без нежелательных событий и при допустимом уровне ложных срабатываний переключитесь в режим предотвращения для активной блокировки.
  5. Текущий мониторинг: Продолжайте мониторинг журналов после переключения в режим предотвращения. Новые функции приложения или изменения API могут вводить новые шаблоны ложноположительных результатов.

Important

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

Область и связь политики WAF

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

Область политики WAF шлюза приложений

В Application Gateway свяжите политику WAF на трех уровнях детализации:

  • Глобально (для всего шлюза): Политика применяется ко всем прослушивателям и правилам путей в шлюзе приложений. Используйте глобальную область, когда все приложения за шлюзом используют одинаковые требования к защите.
  • Уровень прослушивателя: Другая политика WAF применяется к определенному прослушивателю (сочетание имени узла и порта). Используйте область уровня прослушивателя, если несколько приложений совместно используют шлюз, но требуют разных настроек правил или исключений.
  • Уровень правила пути URL: Политика WAF применяется к определенному правилу пути URL в прослушивателе. Используйте область действия правил пути для детального контроля над приложениями с серверными компонентами различной чувствительности.

Если к одному запросу применяются несколько областей действия, приоритет имеет наиболее конкретная политика: политика правила пути имеет приоритет над политикой уровня обработчика, а та — над глобальной политикой.

Область политики Front Door WAF

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

Совместное использование политик между ресурсами

Используйте одну политику WAF для нескольких экземпляров Application Gateway или конечных точек Front Door. Диспетчер брандмауэра Azure обеспечивает централизованную видимость и управление всеми политиками WAF независимо от платформы. Используйте общие политики, если нескольким ресурсам требуется одинаковая защита, чтобы упростить управление и обеспечить согласованность системы безопасности.

Различие от Брандмауэр Azure

WAF и Брандмауэр Azure защищают разные слои сетевого стека и выполняют взаимодополняющие функции. Разверните оба для эшелонированной защиты.

Атрибут Брандмауэр веб-приложений Брандмауэр Azure
Уровень OSI Уровень 7 (только HTTP/HTTPS) Уровни 3–7 (сеть и приложение)
Тип трафика Входящие HTTP/HTTPS запросы к веб-приложениям Все направления движения (северо-юг, восточная и западная часть)
Фокус проверки Семантика HTTP: заголовки, текст, файлы cookie, URI IP-адреса, порты, протоколы, полные доменные имена, URL-адреса
Обработчик правил Сопоставление шаблонов на основе OWASP + оценка аномалий Сетевые правила, правила приложения, правила NAT
Модель развертывания Интегрировано с шлюзом приложений или Front Door Автономная подсеть концентратора с маршрутизацией UDR
Типичные атаки заблокированы SQL-инъекция, XSS, CSRF, обход каталогов Сканирование портов, обратные вызовы C2, утечка DNS

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

Вопросы безопасности

Следующие методики безопасности помогут вам получить большую защиту от WAF:

  • Режим предотвращения для продуктивной среды: Никогда не оставляйте рабочие нагрузки в продуктивной среде в режиме обнаружения. Режим обнаружения обеспечивает видимость, но не обеспечивает принудительное применение, оставляя приложения подвержены атакам.
  • Настройка правил продолжается: Приложения развиваются. Новые эндпоинты API, параметры и типы контента могут вызывать ложные срабатывания в существующих наборах правил. Регулярно просматривайте журналы WAF после развертываний.
  • Интеграция с Log Analytics: Отправляйте журналы диагностики WAF в рабочую область Log Analytics. Используйте книгу WAF для визуализации заблокированных запросов, триггерных правил и распределения показателей аномалий.
  • DDoS и WAF вместе: WAF защищает от атак приложений уровня 7, но не устраняет атаки DDoS на уровне сети. Сочетайте WAF с Azure DDoS Protection для комплексной защиты на всех уровнях стека.
  • Блокировка источника: При использовании Front Door WAF настройте источник для приема трафика только из тега службы Front Door. Без блокировки источника злоумышленники могут обойти Front Door и отправлять запросы непосредственно в IP-адрес источника.
  • Защита конфиденциальных данных: Журналы WAF могут содержать данные запроса. Настройте правила очистки журналов для маскирования конфиденциальных полей (заголовки авторизации, файлы cookie или содержимое текста) в журналах диагностики WAF.

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

Узнать больше

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

Tip

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

Далее в пути лифта и смены:

Настройте мониторинг для перенесенной сети: проверьте подключение и производительность после настройки брандмауэра веб-приложения.

Далее в пути модернизации:

Включите защиту от атак DDoS для общедоступных конечных точек: защитите ресурсы общедоступных IP-адресов от распределенных атак типа "отказ в обслуживании".

Следующий этап вашего мультиоблачного пути:

Разверните перенесенные приложения: сопоставьте балансировщики нагрузки из AWS и Google Cloud с их эквивалентами в Azure для кросс-облачных рабочих нагрузок.

  • Last updated on