50 оттенков NGFW: когда требований больше, чем здравого смысла
Выбор NGFW редко сводится к простому сравнению характеристик. На практике заказчику приходится сопоставлять не только производительность и список функций, но и архитектуру сети, требования регуляторов, компетенции команды, бюджет, особенности лицензирования и планы развития инфраструктуры.
Поэтому универсального ответа на вопрос "какой NGFW лучший?" не существует. Корректнее спрашивать: какой продукт наиболее точно соответствует конкретным задачам, ограничениям и уровню зрелости организации.
Выбор без выбора
Нередко проект начинается не с анализа угроз и бизнес-процессов, а с длинного перечня пожеланий. В техническое задание попадают:
- межсетевой экран и NAT;
- IPS;
- контроль приложений;
- фильтрация URL;
- антивирусная проверка;
- Anti-Bot;
- песочница;
- анализ зашифрованного трафика;
- VPN;
- SD-WAN;
- многофакторная аутентификация;
- BGP, OSPF и другие протоколы маршрутизации;
- PBR, VRF, ECMP, DHCP, VLAN, VXLAN;
- интеграция с AD и SIEM;
- централизованное управление;
- кластеризация Active-Active;
- геораспределённая отказоустойчивость.
При этом система должна обрабатывать десятки гигабит в секунду, работать с минимальной задержкой, соответствовать требованиям импортозамещения, иметь необходимые сертификаты и укладываться в ограниченный бюджет.
В результате от одного решения ожидают свойств сразу нескольких классов оборудования: производительности маршрутизатора, функций шлюза безопасности, возможностей прокси, SD-WAN-платформы и системы управления доступом. Теоретически это возможно, но на практике почти всегда приводит к компромиссам.
Первый вопрос при таком подходе должен звучать не "поддерживает ли продукт эту функцию?", а "какую проблему она должна решить и будет ли она реально использоваться?".
Три уровня требований
Удобно разделить требования на три группы.
1. Критически необходимые
Это функции, без которых запуск системы невозможен либо она не выполнит основную задачу. Например:
- маршрутизация между сегментами;
- фильтрация трафика;
- IPS для определённых зон;
- организация VPN;
- интеграция с каталогом пользователей;
- журналирование событий.
Такие возможности должны быть подтверждены не только в документации, но и на тестовом стенде.
2. Нужные в ближайшей перспективе
Сюда относятся функции, которые организация планирует внедрить в течение ближайших шести-двенадцати месяцев. Например, централизованное управление, интеграция с SIEM, автоматизация политик или переход к сегментации доступа.
По этим пунктам важно оценивать не только текущую реализацию, но и зрелость продукта: насколько стабильно работает функция, как она настраивается, кто отвечает за её поддержку и как часто выходят обновления.
3. Потенциально полезные
Это категория "пусть будет на всякий случай". В неё попадают возможности, которые когда-нибудь могут пригодиться, уже были в старом решении или упоминались в презентации другого производителя.
Именно такие пункты чаще всего раздувают техническое задание. При этом каждая дополнительная функция увеличивает сложность эксплуатации, требования к обучению персонала и стоимость лицензий.
Один NGFW на всю инфраструктуру
Идея заменить несколько специализированных решений одним универсальным NGFW выглядит привлекательной. Меньше производителей, единая консоль, один договор поддержки, упрощённая схема управления.
Однако объединение функций не всегда означает упрощение. На одном устройстве могут одновременно выполняться маршрутизация, глубокий анализ трафика, SSL-инспекция, VPN, антивирусная проверка и передача больших объёмов данных. При росте нагрузки отдельная функция способна повлиять на работу всей платформы.
Кроме того, разные сегменты сети предъявляют разные требования. Интернет-шлюзу важны производительность и защита внешнего периметра, внутреннему шлюзу - сегментация и контроль доступа, филиалам - отказоустойчивость и удобство централизованного управления.
Поэтому перед выбором единой платформы следует определить, действительно ли консолидация снижает сложность или просто переносит её в один критически важный узел.
Производительность: цифры не всегда отражают реальность
Показатели пропускной способности в рекламных материалах нельзя сравнивать напрямую. В одном случае речь идёт о чистой маршрутизации, в другом - о трафике с включёнными IPS, контролем приложений, фильтрацией URL и расшифровкой TLS.
На итоговую скорость влияют:
- размер пакетов;
- количество одновременных сессий;
- доля коротких соединений;
- используемые протоколы;
- включённые профили безопасности;
- объём журналирования;
- работа в кластерном режиме;
- типы сетевых интерфейсов;
- версия программного обеспечения.
Особенно осторожно нужно относиться к тестам, где измеряется только один сценарий. Реальная инфраструктура почти никогда не состоит из идеально однородного трафика.
Корректный подход - сформировать несколько собственных сценариев и проверить их на стенде: обычный транзит, межсегментный обмен, VPN, веб-трафик, зашифрованные соединения, нагрузка с включёнными средствами предотвращения атак.
Что не видно в техническом описании
Документация редко показывает повседневную сторону эксплуатации. Между заявленной функцией и удобным рабочим процессом может быть большая разница.
На тестировании стоит проверить:
- насколько быстро создаются и изменяются политики;
- можно ли понять причину срабатывания правила;
- насколько удобен поиск по журналам;
- как система обрабатывает ошибки конфигурации;
- есть ли безопасный откат изменений;
- насколько информативны отчёты;
- как выполняется обновление сигнатур и программного обеспечения;
- можно ли автоматизировать типовые операции;
- как устроено разграничение полномочий администраторов.
Не менее важен процесс восстановления после сбоя. Следует заранее выяснить, сколько времени занимает замена устройства, можно ли быстро развернуть резервную конфигурацию и как ведёт себя кластер при отказе одного из узлов.
Крупные и менее известные вендоры
Большой производитель обычно предлагает развитую экосистему, обширную документацию, обучающие программы и большое количество специалистов на рынке. Но это не гарантирует идеального соответствия конкретной инфраструктуре.
У менее крупных разработчиков могут быть сильные стороны: гибкая адаптация, более быстрая коммуникация, удобные условия внедрения, возможность доработок. Одновременно выше риск зависимости от небольшой команды, ограниченной базы интеграторов и менее предсказуемого развития продукта.
Оценивать нужно не размер бренда, а устойчивость решения: частоту обновлений, качество поддержки, прозрачность дорожной карты, совместимость с используемыми системами и наличие специалистов, способных сопровождать платформу после завершения проекта.
Цена покупки - не вся стоимость
Лицензирование NGFW часто оказывается сложнее самой закупки оборудования. Отдельно могут оплачиваться IPS, антивирус, фильтрация URL, песочница, VPN, облачное управление, техническая поддержка и обновление баз.
Поэтому сравнивать нужно не цену устройства, а совокупную стоимость владения на несколько лет. В расчёт следует включить:
- аппаратную платформу;
- программные лицензии;
- поддержку;
- продление подписок;
- резервные узлы;
- обучение сотрудников;
- услуги внедрения;
- миграцию политик;
- возможные интеграции;
- трудозатраты администраторов.
Дешёвое решение с неудобным управлением может оказаться дороже более дорогой альтернативы уже на этапе эксплуатации.
Как выстроить правильный выбор
Рациональная процедура может выглядеть так:
1. Описать защищаемые сегменты и потоки данных.
2. Зафиксировать актуальные угрозы и требования регуляторов.
3. Разделить функции на обязательные, планируемые и второстепенные.
4. Определить реальную нагрузку с запасом на рост.
5. Сформировать несколько рабочих сценариев.
6. Проверить кандидатов на стенде или в пилотной зоне.
7. Оценить удобство эксплуатации и качество журналирования.
8. Рассчитать совокупную стоимость владения.
9. Проверить доступность компетенций и поддержки.
10. Подготовить план миграции и возврата к прежней конфигурации.
Отдельно стоит определить критерии провала пилота. Например, критичным может считаться отсутствие нужной интеграции, недостаточная производительность при включённом IPS или невозможность обеспечить требуемую отказоустойчивость.
Итог
Хороший NGFW - не тот, у которого длиннее список функций и выше цифра в рекламном буклете. Это решение, которое закрывает реальные риски, вписывается в архитектуру сети, понятно администраторам и остаётся управляемым после завершения проекта.
Чем точнее сформулированы задачи, тем меньше вероятность переплатить за невостребованные возможности. В большинстве случаев разумнее выбрать платформу с достаточным, а не максимальным набором функций, заранее проверить её на собственных сценариях и оценить не только запуск, но и многолетнюю эксплуатацию.
Главный критерий выбора - не количество поддерживаемых технологий, а способность системы предсказуемо защищать инфраструктуру при приемлемой цене, сложности и уровне нагрузки на команду.