Как выбрать WAF: критерии выбора межсетевого экрана уровня приложений

Короткий ответ: сначала определите регуляторный статус — субъект КИИ, оператор ГИС или организация, обязанная применять сертифицированные средства защиты, требует продукт с действующим сертификатом ФСТЭК на профиль МЭ типа «Г». Дальше проверьте, как устроена защита именно вашего трафика: если приложение отдаёт JSON-API, покрытие общего OWASP Top-10 не гарантирует защиту от специфичных API-атак — это отдельная строка в сравнении.

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

WAF (Web Application Firewall, в терминологии ФСТЭК — межсетевой экран уровня веб-приложений) разбирает HTTP/HTTPS-запросы к конкретному веб-приложению — параметры форм, сессионные токены, структуру URL — и блокирует атаки по классификации OWASP Top-10: SQL-инъекции, межсайтовый скриптинг, обход авторизации, включение файлов, удалённое выполнение кода. Зрелый WAF также закрывает уязвимость приложения виртуальным патчем ещё до выхода официального обновления от разработчика, отражает автоматизированные сканеры и ботов и смягчает DDoS-атаки уровня приложения (L7) — то есть работает там, где сетевой периметр уже пропустил трафик как легитимный по портам и протоколам.

NGFW фильтрует более широкий сетевой трафик по IP-адресам, портам, протоколам и сигнатурам приложений на уровнях L3–L7, но не разбирает логику конкретного веб-приложения так глубоко: видит, что пакет идёт к веб-серверу по HTTPS, но не то, что значение параметра в форме содержит SQL-инъекцию. Грань между классами на практике размыта — многие российские вендоры NGFW продают WAF-модуль в той же линейке, сертифицированный по общему профилю защиты МЭ, поэтому функциональность WAF стоит проверять по факту прохождения тестов на конкретных типах атак, а не по названию продукта.

Разбор класса NGFW — на странице «NGFW: что это и как выбрать».

Ниже — критерии, которые стоит проверять у любого кандидата независимо от вендора. Вес каждого меняется в зависимости от того, что вы защищаете — публичный сайт, сервис с активным API или объект с регуляторными требованиями; сценарии разобраны в следующем разделе.

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

1. Определите, обязателен ли для вас сертификат ФСТЭК на профиль МЭ Г (субъект КИИ, оператор ГИС, компания с госучастием).
2. Уточните у кандидатов модель детекта — только сигнатуры или сигнатуры вместе с поведенческим анализом/ML.
3. Проверьте покрытие OWASP Top-10 и частоту обновления базы правил.
4. Если приложение отдаёт JSON/REST/GraphQL API — уточните наличие отдельного модуля защиты API и покрытие OWASP API Security Top-10.
5. Определите режим развёртывания (inline, reverse-proxy, облачный) исходя из топологии сети и требований к размещению данных.
6. Запросите тест латентности и throughput на реальном профиле своего трафика, а не на синтетическом стенде вендора.
7. Пройдите пилот в режиме обучения/мониторинга перед переключением в блокирующий режим и оцените долю ложных срабатываний.
8. Уточните SLA вендора на выпуск виртуальных патчей под свежие уязвимости (CVE).
9. Проверьте наличие и качество антибот-модуля — как он отличает легитимных ботов от вредоносных.
10. Проверьте готовые интеграции с используемой SIEM/SOAR и формат передачи событий.
11. Сравните модели лицензирования (по throughput, числу доменов, трафику) и посчитайте TCO на 3 года с учётом тюнинга правил и продления сертификата.
12. Сверьте срок действия сертификата ФСТЭК выбранного продукта в госреестре СЗИ ФСТЭК перед подписанием договора.

• Включать блокирующий режим сразу после установки без периода обучения. Легитимные пользователи получают ложные блокировки, команда в панике откатывает WAF в режим наблюдения — и защита на время пропадает как раз тогда, когда её только начали внедрять.
• Считать, что общий OWASP Top-10 закрывает и защиту API. Без отдельного тестирования API-эндпоинтов часть атак — нарушение авторизации на уровне объекта, чрезмерное раскрытие данных — проходит мимо сигнатур, рассчитанных на HTML-формы.
• Тестировать производительность по паспортным цифрам вендора. Реальная латентность при глубокой инспекции содержимого и расшифровке TLS почти всегда выше заявленной — разница проявляется именно под пиковой нагрузкой собственного приложения.
• Не закладывать в бюджет тюнинг правил после запуска. Доля ложных срабатываний снижается постепенно и силами аналитика, а не автоматически сразу после включения продукта — это отдельная статья затрат, которую часто забывают при расчёте TCO.
• Выбирать облачный WAF для КИИ и ГИС без проверки требований к размещению трафика. Сертификат ФСТЭК на сам продукт не снимает вопрос, где физически проходит и обрабатывается трафик — это нужно проверять до подписания договора, а не после аудита регулятора.

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

Смежные классы: NGFW — сетевой периметр, в который часто встроен WAF-модуль, API Security — специализированная защита программных интерфейсов за пределами общего WAF-модуля. Для проверки, как формально подтверждается соответствие СЗИ требованиям регулятора, — раздел «Оценка соответствия» на SecRadar.