Enterprise-защита задешево: что облако сделало с WAF

Привет, Хабр! На связи Егор Сапун, руководитель направления сертификации инфраструктуры Рег.облака.

Кибератаки касаются не только крупного бизнеса. За последний год с киберинцидентами столкнулись 82% российских компаний малого и среднего бизнеса. По данным Positive Technologies, в 2025 году 75% успешных атак на веб-приложения российских организаций приводили к нарушению их деятельности.

От части атак на сайты, веб-приложения и API защищает WAF. Но для многих компаний это все еще enterprise-решение: классический WAF необходимо развернуть в своей или арендованной инфраструктуре, встроить в путь трафика. Для этого нужны вычислительные ресурсы а также компетенции по настройке и сопровождению. У небольших компаний таких ресурсов может и не быть.

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

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

Навигация по тексту:

• Как облачный WAF снижает порог входа для бизнеса

• Можно ли обойтись без человека, который отвечает за WAF

• Как мы сделали WAF доступнее для небольших команд

• WAF — не панацея

Как облачный WAF снижает порог входа для бизнеса

С классическим WAF мало заплатить за саму защиту. Для аппаратного решения нужны платформа и лицензия, а при росте нагрузки может потребоваться масштабирование по производительности или установка дополнительных узлов. При этом вендор может прекратить поддержку платформы, даже если само оборудование еще работает. Например, новые версии ПО перестанут на ней работать. Тогда платформу придется модернизировать или менять, чтобы и дальше получать обновления.

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

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

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

За счет этого облачный WAF становится доступнее компаниям без собственной ИБ-инфраструктуры и отдельной команды. Например:

• интернет-магазинам и маркетплейсам — профиль может учитывать работу каталога, поиска, корзины, авторизации и оформления заказа;

• SaaS-сервисам и другим проектам с API — методы, параметры, форматы запросов и ограничения на их частоту;

• веб-студиям и digital-агентствам — защиту нескольких клиентских проектов с разными профилями трафика и политиками;

• медиа и другим публичным веб-проектам — автоматизированный трафик, например частые обращения к поиску, авторизации или другим ресурсоемким функциям.

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

Можно ли обойтись без человека, который отвечает за WAF

Отдельный ИБ-специалист для работы с облачным WAF нужен не всегда. Но кто-то все равно должен его подключить, проверять актуальность политик, разбирать срабатывания и принимать решения по исключениям. Эти задачи можно распределить между DevOps-инженером или системным администратором и разработчиком.

Саму работу специалиста с WAF можно разделить на три этапа:

1. Подготовка. Понадобятся доступ к DNS, список доменов и поддоменов, которые нужно защитить, адреса серверов или балансировщиков, на которые приходит трафик, и список внешних сервисов, которым нужен доступ к ресурсу. Еще лучше заранее подготовить план отката DNS и проверить TTL, чтобы при необходимости быстро вернуть прежнюю схему маршрутизации.

Здесь пригодится и помощь разработчика: он знает, какие URL и методы API использует ресурс, какие параметры принимает, откуда приходят вебхуки и какие пользовательские сценарии должны работать без блокировок.

2. Подключение. Эту часть может взять на себя DevOps или системный администратор: настроить DNS и направить трафик через WAF и убедиться, что origin-сервер принимает только очищенный трафик. После переключения стоит проверить основные сценарии — например, авторизацию, формы, методы API и внешние интеграции.

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

3. Сопровождение. После подключения могут появиться ложные срабатывания. Например, WAF может заблокировать допустимое значение параметра формы, нестандартный JSON-пейлоад, вебхук или запрос от внешней интеграции. Разработчик определяет, относится ли запрос к нормальной работе ресурса, а DevOps или инженер по эксплуатации находит сработавшее правило в журнале и корректирует политику.

Обычно безопаснее добавить исключение для конкретного rule-path-parameter сочетания или режима работы правила, чем отключать правило целиком.

Возвращаться к настройкам нужно и после изменений в проекте. Если появилась новая форма, метод API, способ авторизации, загрузка файлов или интеграция, стоит проверить новый сценарий и посмотреть, не появились ли связанные с ним срабатывания и блокировки.

Как мы сделали WAF доступнее для небольших команд

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

Вот как это устроено:

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

• Два режима работы правил — аудит и блокировка. Часть правил можно сразу перевести в режим блокировки, а часть сначала оставить в режиме аудита. В этом режиме можно посмотреть, на какие реальные запросы реагирует система, и только после этого включить блокировку. Такой подход помогает минимизировать ложные срабатывания.

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

WAF анализирует HTTP/HTTPS-трафик, блокирует распространенные веб-атаки, включая SQL-инъекции и XSS, фильтрует вредоносные запросы к API, помогает отсекать ботов и автоматизированный трафик и контролировать аномальную нагрузку на уровне L7. Можно ограничивать частоту запросов и управлять доступом.

Сейчас сервис уже можно протестировать бесплатно: защитить до трех приложений с нагрузкой до 50 запросов в секунду.

Подключение состоит из пяти шагов:

1. Подключите WAF-защиту. Укажите название услуги, выберите тариф и нажмите «Подключить».

После активации услуга появится в разделе WAF-защиты. Через меню услуги можно перейти к настройкам — для этого выберите «Управлять защитой».

2. Добавьте ресурс. В панели управления WAF откройте раздел «Приложения» и нажмите «Добавить приложение». Можно добавить сайт или веб-сервис.

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

4. Настройте защиту. Выберите профиль безопасности и при необходимости добавьте IP-адреса или сети в белый список. После этого создайте приложение.

5. Измените A-запись DNS на IP-адрес центра очистки, чтобы направить через него трафик.

После переключения стоит проверить основные сценарии приложения: авторизацию, формы, методы API и внешние интеграции. Если WAF реагирует на легитимный запрос, срабатывание можно найти в журнале и при необходимости добавить в исключение.

WAF — не панацея

WAF не решает все проблемы безопасности веб-ресурса. Если в коде или используемых компонентах есть уязвимость, ее все равно нужно исправлять. До установки патча WAF может выступать компенсирующей мерой и снижать риск эксплуатации уязвимости, блокируя часть потенциально опасных запросов, но не заменяет само исправление.

Не от всех атак WAF защищает в принципе. Например, против объемных DDoS-атак нужна отдельная DDoS-защита. Сложные боты тоже могут потребовать Anti-Bot: они меняют IP-адреса, выполняют JavaScript и имитируют действия обычных пользователей.

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

Если у вас уже есть WAF, расскажите в комментариях, сколько на самом деле ресурсов он требует: кто его настраивает, сколько времени уходит на сопровождение и удалось ли обойтись без отдельной ИБ-функции. Особенно интересно, как это устроено в небольших командах.