Никто не хочет покупать кота в мешке, особенно когда речь идет о дорогостоящих ИБ-решениях. Поэтому сделке и интеграции часто предшествует пилотный проект. Казалось бы, что может быть проще: поставил СЗИ, посмотрел пару недель, как оно работает и принял решение о покупке (или не принял). На практике же после пилота иногда повисает «неловкая пауза»: заказчик не понимает, как ему оценить результаты теста, а вендор – как дальше защищать свой продукт, потому что вводных от заказчика было ничтожно мало. Итог может быть печальным для всех. Вендор уйдет без клиента, а потенциальный заказчик – без киберзащиты. Поэтому, чтобы недели (а иногда и месяцы) не прошли даром, к пилоту надо хорошо подготовиться. Особенно если речь идет о сложных системах, таких как межсетевой экран веб-приложений (WAF). Поскольку WAF – это полноценный участник архитектуры, он требует правильной интеграции с защищаемыми приложениями, балансировщиками нагрузки и другими системами в инфраструктуре заказчика. Давайте посмотрим на каждый этап пилота отдельно.
Что именно «пилотим»?
Для начала надо определиться со списком приложений, которые будут заведены за WAF в рамках пилотного тестирования. Не пытайтесь защитить всё и сразу: для пилота лучше ограничиться двумя критичными приложениями. Это должны быть реальные приложения с реальными пользователями, ведь без этого невозможно определить, как WAF держит нагрузку, какую задержку трафика вносит и, главное, не блокирует ли легитимных пользователей из-за ложных срабатываний (и насколько просто создавать исключения для фолзов).
Каждое веб-приложение при этом стоит подробно описать:
доменное имя (FQDN);
IP-адрес(а) backend-серверов;
используемые порты;
протоколы (HTTP / HTTPS);
необходимость TLS / mTLS;
тип приложения (web, API, mobile backend и т.д.).
WAF – это не чёрный ящик, а «прозрачный посредник», которому нужно точно знать маршрут. Большинство задержек и сбоев на пилоте происходят именно на этапе «а куда вообще слать трафик?». Поэтому заранее собранные параметры экономят часы и даже дни.
Современные приложения используют разные протоколы (а не только HTTP) и надо понять, умеет ли WAF в принципе работать с этим разнообразием. Поэтому для защищаемых ресурсов надо прописать:
использование дополнительных протоколов, например, WebSocket / HTTP2 / gRPC;
наличие REST / SOAP / GraphQL API;
особенности аутентификации (JWT, OAuth, cookies, custom headers);
загрузка файлов (multipart/form-data);
нестандартные HTTP-методы;
чувствительность к изменению заголовков, задержкам, блокировке отдельных запросов;
наличие собственных механизмов rate limiting или защиты.
Определившись с основными характеристиками приложений, надо понять какой объем трафика придётся фильтровать WAF. Исходя из этого можно понять, объем железа, необходимого для развертывания и работы решения на стороне заказчика. Если ресурсов недостаточно, то WAF не будет успевать обрабатывать запросы, что увеличит задержки и скорость ответа пользователям веб-приложения. Для сайзинга большинства WAF достаточно следующих параметров:
средний и пиковый RPS;
объем трафика (Mbps / Gbps);
Архитектура и схема включения WAF
Итак, с приложениями и трафиком – понятно. Самое время определить архитектуру и место, куда будет интегрирован WAF. Современные веб-приложения имеют многоуровневую и распределённую архитектуру: балансировщики нагрузки, reverse proxy, web-серверы и backend-сервисы. На каждом из этих уровней могут применяться решения, влияющие на обработку трафика, терминацию TLS, маршрутизацию запросов и передачу клиентских данных.
И WAF должен вписаться в эту цепочку органично. Поэтому важно понимать фактическую архитектуру приложения, его сетевую топологию и особенности взаимодействия компонентов. Это помогает:
выбрать оптимальное место установки WAF;
корректно определить точку терминации TLS;
обеспечить прозрачную интеграцию без влияния на работу приложения;
избежать дополнительных доработок и изменений в ходе пилота.
Типовая архитектура веб-приложения выглядит так:
Куда в таком случае можно установить WAF:
WAF перед LB (User → WAF → LB → App)
WAF за LB (User → LB → WAF → App)
WAF в качестве LB (User → WAF → App)
WAF интегрируется в LB / Web Servers (модуль для nginx/angie)
Какой вариант интеграции WAF выбрать, зависит как от текущей архитектуры заказчика, так и от характеристик решения выбранного вендора. Поэтому идеальной будет та схема, которая учитывает все эти особенности.
Важные детали
№1. Точка терминации TLS
Почти весь современный веб-трафик зашифрован (HTTPS/TLS). Если WAF его не расшифрует, то будет видеть только IP-адреса и заголовки без содержания запросов. Чтобы трафик не превратился в черный ящик, на этапе подготовки пилота необходимо выбрать точку разрыва соединения (терминации).
Вариант А: TLS терминируется на WAF. Тогда потребуется загрузка серверных сертификатов и закрытых ключей в WAF.
Вариант Б: TLS терминируется до WAF (на существующем LB/proxy-сервере). WAF получает уже расшифрованный трафик.
В зависимости от выбранной схемы придется менять конфигурацию балансировщиков, backend-приложений или DNS-записей.
Кроме того, надо учитывать, что может потребоваться и повторное шифрование трафика от WAF к защищаемым приложениям, в том числе, и mTLS. В таком случае потребуется выпуск новых сертификатов и/или добавление корпоративного УЦ в список доверенных на узлах WAF.
№2 Проблема клиентского IP
Если WAF стоит за балансировщиком, критически важно обеспечить передачу реального IP-адреса клиента. Иначе:
Снижается эффективность защитных механизмов.
Не работает rate limiting (все запросы будут с IP балансировщика).
Логи становятся бесполезными для расследования инцидентов.
Что нужно согласовать:
Механизм передачи от LB к WAF: HTTP-заголовки (X-Forwarded-For, X-Real-IP, Forwarded) или прокси-протокол.
Доверенные подсети: WAF должен знать, от каких IP принимать эти заголовки.
Передача от WAF к Backend: backend тоже должен видеть реальный IP. Возможно, потребуется добавить IP-адреса нод WAF в список доверенных на стороне backend.
Обеспечение сетевой связности и доступов
Скорее всего, в сети заказчика есть сегментация и межсетевое экранирование. С развёртыванием WAF в инфраструктуре появляется новый хост, а значит, надо обеспечить его связанность с другими компонентами приложения, добавив правила в файрволлы и согласовав необходимые сетевые доступы.
Таблица доступов может выглядеть следующим образом:
Источник | Получатель | Порт | Протокол | Комментарий |
АРМ администратора | Веб-консоль управления WAF | 443 | TCP | Доступ администратора к веб-консоли |
АРМ администратора | Хост, на котором установлены компоненты WAF | 22 | TCP | Доступ администратора по SSH |
АРМ пользователей системы | Веб-консоль управления WAF | 443 | TCP | Доступ пользователей |
Компонент WAF №1 | Компонент WAF №2 | XXX | TCP | Современные WAF имеют микросервисную архитектуру, поэтому разные компоненты системы (узлы обработки трафика, управляющие узлы, базы данных и т.п.) могут быть развернуты на разных серверах. |
Также уточните требования к прокси, если в вашей инфраструктуре ограничен прямой выход в интернет. Это нужно, чтобы WAF смог обновлять свои компоненты и базы знаний.
Организационные вопросы и роли
Техника – это половина дела. Вторая половина – это люди и процессы. Обычно пилотом занимается команда ИБ, но на деле оказывается, что к этому процессу привлекают специалистов из других отделов.
Роли со стороны заказчика:
Владелец приложения или сервиса (который разрешает пилот, согласует downtime, оценивает влияние на бизнес).
Специалисты ИТ-инфраструктуры и сетевые инженеры (чтобы предоставили вычислительные ресурсы и организовали сетевую связанность).
Команда разработки (чтобы проверить, что WAF ничего не сломал или для настройки backend, если нужно).
Специалисты по ИБ (тут и так понятно).
Что согласовать до старта:
Cроки и план проведения пилота.
Необходимость подписания NDA.
Предоставление удаленного доступа инженерам вендора и/или интегратора (если требуется).
Процесс внесения изменений в инфраструктуру (Change Management).
Контактных лиц для оперативного взаимодействия и порядок эскалации инцидентов.
Критерии успешности пилота
Представьте: вы 2 месяца пилотировали WAF, привлекли коллег из смежных отделов помимо ИБ, потратили время и силы своих сотрудников. А в итоге не понимаете, как оценить результат. Вроде, все работает, деградации приложений нет, какие-то атаки за время пилота даже удалось отразить – успешен ли этот пилот и достаточно ли аргументов, чтобы закупить решение?
Чтобы деньги и силы не были потрачены впустую, мы советуем заранее определить критерии, по которым пилот будет считаться успешным. Например:
отсутствие негативного влияния на доступность приложений;
корректная обработка легитимного трафика;
обнаружение и/или блокировка тестовых атак;
удобство эксплуатации и администрирования;
качество отчетности и логирования.
Оценка эффективности пилота заслуживает отдельной статьи, так как уместить все детали в одну небольшую главу текста невозможно. Подробно о критериях успеха пилота мы расскажем в следующем посте, который выйдет совсем скоро.
Автор: Владимир Гриднев, заместитель генерального директора по развитию бизнеса WMX
