Бизнес-приложения доступны через веб и API, работают с внешними сервисами, обрабатывают критичные данные и постоянно меняются. Поэтому безопасность приложений нельзя свести ни к поиску уязвимостей в коде, ни к установке WAF перед приложением.
Тестирование до продакшена и защита трафика в продакшене решают разные задачи.
Блокировка включается после анализа реального трафика приложения.
Уязвимость должна попасть к нужной команде и быть перепроверена.
Hafaza Tech проектирует и внедряет Application Security на базе Fortinet FortiWeb, Imperva и OpenText Fortify — от WAF и защиты API до SAST/DAST и встраивания проверок в процессы разработки и центра мониторинга.
Уровень защиты трафика. FortiWeb — WAF для защиты веб-приложений и API. Используется в разных моделях развёртывания: анализ трафика приложения, защита от веб-атак, применение политик и виртуальный патчинг.
Особенно логичен там, где WAF должен работать вместе с существующей инфраструктурой Fortinet, но применяется и как самостоятельное средство защиты.
Конкретные возможности зависят от модели, версии и лицензирования.
Уровень защиты трафика. Специализированный вендор в области безопасности веб-приложений и API. Платформа закрывает сценарии WAF и WAAP: защита приложений и API, работа с ботами и другие риски уровня приложения.
Подходит там, где нужна централизованная защита приложений, доступных из интернета, в локальной, облачной или гибридной архитектуре.
Набор возможностей и модель развёртывания подбираются под требования проекта.
Уровень тестирования. OpenText Fortify работает на другом уровне архитектуры — это тестирование безопасности приложений и встраивание проверок в процесс разработки.
Используется для SAST и DAST, анализа уязвимостей приложений, интеграции с конвейерами сборки и организации работы с находками.
Fortify помогает найти уязвимость, а WAF — снизить риск её эксплуатации до исправления. В зрелой архитектуре эти средства используются вместе.
Три продукта не являются взаимозаменяемыми: FortiWeb и Imperva — средства защиты трафика в продакшене, Fortify — средство тестирования приложений до выпуска. Поэтому выбор делается не между ними, а по тому, какой уровень архитектуры закрывается в проекте.
Зачем нужен WAF
Web Application Firewall анализирует HTTP/S-трафик до того, как запрос попадёт в приложение, и применяет политики безопасности для выявления и блокирования вредоносной или нарушающей правила активности.
Защита от распространённых веб-атак
Проверка корректности протокола и запросов
Сигнатуры и репутационные механизмы
Поведенческие механизмы и выявление аномалий
Политики под конкретное приложение
Защита API
Противодействие ботам
Журналирование и телеметрия безопасности
Конкретный набор возможностей зависит от платформы, лицензии и архитектуры развёртывания — это проверяется на пилоте, а не предполагается по описанию.
Он снижает вероятность успешной эксплуатации уязвимости, но не исправляет саму уязвимость в приложении.
Поэтому правильная архитектура — не «WAF вместо исправления приложения», а безопасная разработка, тестирование и защита в продакшене вместе. Например, уязвимость найдена сканером или на тестировании, но изменение рабочего кода требует времени: на этот период WAF используется как компенсирующая мера.
Виртуальный патчинг сокращает окно риска между обнаружением уязвимости и реальным исправлением. Он особенно полезен, если приложение нельзя обновить немедленно, цикл выпуска длинный, уязвимость в унаследованной системе или нужно быстро снизить риск со стороны интернета.
Виртуальный патчинг — компенсирующая мера, а не постоянная замена исправлению. После исправления приложения защиту нужно перепроверить и при необходимости снять.
Классический WAF исторически занимался в основном трафиком веб-приложений. Сегодня приложения всё чаще строятся вокруг API, микросервисов и автоматических взаимодействий, поэтому защита расширяется в сторону Web Application and API Protection.
Трафик браузеров и клиентов к веб-интерфейсам: проверка запросов, защита от распространённых атак, политики под конкретное приложение.
Отдельный класс трафика со своей логикой: схемы, методы, токены, объектный доступ и допустимые действия.
Боты и автоматические взаимодействия — от безобидных до злоупотребляющих бизнес-логикой приложения.
Для заказчика важнее не термин WAAP сам по себе, а то, какую часть реальной поверхности атаки приложения способна контролировать выбранная платформа.
Безопасность API
У API собственные риски, связанные не только с вредоносным содержимым запроса, но и с тем, как API используется. Зрелая архитектура начинается с понимания: какие API существуют, кто ими пользуется, какие данные они обрабатывают, какие действия разрешены и что считается ненормальным поведением.
Неизвестные и забытые API
Аутентификация
Авторизация
Токены и учётные данные
Доступ на уровне объектов
Проверка схемы и протокола
Раскрытие чувствительных данных
Нетипичное использование API
Автоматизированные злоупотребления
Сценарии бизнес-логики
WAF может быть важным уровнем контроля, но аутентификация, авторизация и бизнес-логика всё равно должны быть правильно реализованы в самом приложении.
Защита в продакшене — только одна часть. До выпуска нужно уменьшить количество уязвимостей, которые вообще туда попадают. Для этого используются разные виды тестирования.
Анализирует код приложения или связанные артефакты — в зависимости от технологии и продукта. Помогает находить слабые места ближе к этапу разработки и даёт разработчику контекст для исправления.
Тестирует уже работающее приложение снаружи. Исходный код не анализирует: взаимодействует с приложением через доступные интерфейсы и находит уязвимости, которые проявляются во время выполнения.
Анализирует сторонние и открытые компоненты: зависимости, известные уязвимости, транзитивные зависимости, инвентаризацию компонентов и риски цепочки поставок.
Дополнительно программа безопасности приложений может включать поиск секретов в коде, интерактивное тестирование, проверку инфраструктуры как кода и другие средства — в зависимости от среды разработки.
Основная проблема начинается после того, как уязвимость обнаружена.
Если находки SAST, DAST, анализа компонентов и тестирования на проникновение живут отдельно, команда быстро получает десятки повторяющихся оповещений об одном и том же. Поэтому находки сводят в один процесс: объединение, устранение дублей, приоритизация, назначение владельца, исправление и проверка.
DevSecOps и контрольные точки
Проверки безопасности становятся частью обычного цикла разработки. При этом слишком жёсткие контрольные точки могут просто остановить разработку, поэтому политика должна учитывать риск и реальную способность команды исправлять находки.
Критичность находки
Возможность эксплуатации
Критичность приложения
Доступность из интернета
Наличие исправления
Бизнес-риск
Цель — не заблокировать максимальное количество сборок, а уменьшить количество значимых уязвимостей, которые доходят до продакшена.
WAF проектируется как часть рабочей архитектуры приложения. Конкретная модель зависит от инфраструктуры и требований заказчика, а ошибки в этой части влияют не только на безопасность, но и на доступность сервиса.
TLS и сертификаты
WAF должен иметь возможность анализировать трафик приложения после расшифровки — в той точке архитектуры, где это предусмотрено проектом. Поэтому заранее определяется, где выполняется терминация TLS, как управляются сертификаты, как трафик передаётся дальше, нужно ли повторное шифрование и какие требования предъявляются к протоколам и шифрам.
Отказоустойчивость и кластеризация
Проверки состояния и переключение
Поведение сессий при переключении
Синхронизация конфигурации
Процедуры восстановления
Решение: пропускать трафик или блокировать при отказе
Если включить жёсткую блокировку без анализа реального трафика, WAF начнёт блокировать нормальную работу приложения.
Трафик приложения может включать нестандартные запросы, загрузку файлов, API, веб-сокеты, процессы аутентификации, сторонние интеграции, мобильные приложения и автоматические сервисы. Поэтому мы используем последовательный подход.
Приложение постоянно меняется. Новый выпуск может добавить адреса, API, параметры, способ аутентификации, загрузку файлов или внешнюю интеграцию. Поэтому значимые релизы должны учитываться в жизненном цикле WAF: политика, корректная несколько месяцев назад, не обязательно соответствует текущей версии приложения.
WAF — важный источник телеметрии о том, что реально происходит с приложением в продакшене.
Особенно полезен контекст, когда событие в продакшене можно связать с уже известной уязвимостью: «известная уязвимость + попытка эксплуатации в реальном трафике» заметно меняет приоритет исправления.
Безопасность приложений становится заметно полезнее, когда разработка и продакшен не существуют отдельно. Телеметрия WAF показывает, какие части приложения реально атакуют, а результаты тестирования помогают центру мониторинга понимать, какие события опаснее. Так появляется цикл: проверить → защитить → наблюдать → улучшить.
Попытки эксплуатации
Нарушения политик
Атаки на критичные адреса и API
Автоматизированная и ботовая активность
Повторяющееся вредоносное поведение
Заблокированные запросы
Значимые аномалии
Не все приложения требуют одинаковой защиты. Приоритет обычно получают системы, доступные из интернета, платёжные приложения, клиентские порталы, мобильные бэкенды, критичные API и приложения с чувствительными данными.
01
Обследование
02
Охват приложений и API
03
Архитектура
04
Пилот
05
Настройка WAF
06
Тестирование приложений
07
Виртуальный патчинг
08
Интеграция с SOC
09
Регулярный пересмотр
Определяем приложения, доступные из интернета, состав API, архитектуру приложений, механизмы аутентификации, критичные данные, текущий WAF, используемые средства тестирования, конвейеры разработки, интеграцию с центром мониторинга и требования соответствия.
Для WAF проектируем поток трафика, модель развёртывания, терминацию TLS, пропускную способность, отказоустойчивость, архитектуру за WAF, зависимости приложения, журналирование и интеграции. Для тестирования — репозитории, языки и фреймворки, конвейеры сборки, тестовые среды, аутентификацию и процесс работы с находками.
Пилот WAF проверяет полный цикл: увидеть трафик → обнаружить атаку → безопасно заблокировать → сохранить работоспособность приложения → корректно отработать отказ. Проверяются легитимный трафик, характерные атаки, API, TLS, ложные срабатывания, задержка, совместимость, блокировка, переключение, журналирование и удобство управления.
Пилот тестирования проверяет цикл «найти → подтвердить → приоритизировать → исправить → перепроверить». Оценивается не количество найденных уязвимостей, а качество находок, доля ложных срабатываний, контекст для разработчика, покрытие аутентифицированных сценариев, встраивание в конвейер и работа с исправлениями.
Политики WAF выводятся в блокировку поэтапно, после анализа реального трафика. Параллельно настраивается виртуальный патчинг для уязвимостей, которые нельзя исправить немедленно.
После запуска значимые события передаются в центр мониторинга, а изменения приложений учитываются в жизненном цикле: новые API и релизы требуют повторной проверки политик. Безопасность приложений — непрерывный процесс, а не разовая настройка.
Выбор зависит от того, какой уровень архитектуры закрывается. Поэтому мы оцениваем решения на пилоте, а не по таблице функций.
Поддерживаемые приложения и API, модели развёртывания, архитектура TLS, защита от ботов.
Возможности виртуального патчинга, трудоёмкость донастройки, задержка, отказоустойчивость, журналирование.
Передача событий в SIEM, работа с существующей инфраструктурой, лицензирование и операционная сложность.
Поддерживаемые языки и фреймворки, качество результатов, доля ложных срабатываний.
Аутентифицированное тестирование, встраивание в конвейер, работа с находками, удобство для разработчика.
Лицензирование обоих уровней и совокупная стоимость владения на горизонте проекта.
Fortify помогает найти уязвимость. FortiWeb и Imperva снижают риск её эксплуатации в продакшене. В зрелой архитектуре эти средства дополняют друг друга, а не конкурируют.
Она не должна зависеть от одного средства контроля.
Уменьшать количество уязвимостей до продакшена → выявлять проблемы в работающем приложении → снижать риск эксплуатации → видеть реальные атаки → исправлять причины → перепроверять результат.
Не нашли ответа на свои вопросы? Отправьте свой вопрос ниже, и наша служба поддержки ответит на него в ближайшее время. Мы здесь, чтобы помочь вам с кибербезопасностью!
Задайте вопрос!
Если вы хотите узнать больше о наших услугах в области кибербезопасности или не уверены, какие решения подойдут именно вам, оставьте заявку — и наши специалисты свяжутся с вами для бесплатной консультации.
Дополняющие решения для комплексной защиты инфраструктуры и повышения общего уровня информационной безопасности.
Защита периметра и сегментов сети, в которых работают приложения.
Единый процесс мониторинга и расследования событий безопасности.
Устранение уязвимостей в инфраструктуре, на которой работают приложения.
