50 оттенков NGFW: когда требований больше, чем здравого смысла

Эта статья родилась из профессионального опыта и многочисленных обсуждений вокруг проектов по NGFW: из технических заданий, вопросов и ситуаций, которые хорошо знакомы тем, кто хоть раз участвовал в выборе и внедрении подобных решений. Здесь не будет рейтинга вендоров или ответа на вопрос, какой NGFW «самый лучший». Это не столько про технологии, сколько про наш повседневный опыт, архитектурные компромиссы и попытки вместе с заказчиком ответить на главный вопрос: «а что действительно нужно?» Рекомендуем читать с чувством юмора. Все совпадения с реальными проектами случайны.

Какой NGFW лучше?

«Какой NGFW лучший?» Это, пожалуй, один из самых популярных вопросов, который мы слышим от заказчиков. И каждый раз хочется дать красивый, короткий и уверенный ответ: «Берите вот этот. Он лучший».

Но есть одна небольшая проблема — такого NGFW не существует. Поэтому, если вы открыли эту статью в надежде увидеть таблицу с рейтингом «1 место — X, 2 место — Y, 3 место — Z», можете сразу закрывать вкладку. Здесь такого не будет. Потому что правильный вопрос при выборе NGFW звучит совсем иначе: «Какой NGFW лучше всего подходит именно под наши задачи?»

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

Иногда эти представления прекрасно совпадают с реальностью. А иногда получается классическая история:

— Мы хотим всё, что умел наш старый импортный NGFW. И даже то, что умел другой иностранный вендор, мы не знаем, но мы слышали.

— А что именно из этого вы используете?

— Ну... всё.

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

— А конкретно?

— Ну, много всего. Нельзя потерять функциональность.

После этого начинается самое интересное.

Выбор без выбора

На практике выбор NGFW редко начинается с анализа задач. Чаще он начинается с набора хотелок.

Список выглядит примерно так, и это лишь малая часть:

• Firewall;

• NAT;

• IPS;

• Application Control;

• URL Filtering;

• Anti-Bot;

• Antivirus;

• Sandbox;

• SSL Inspection;

• VPN;

• SD-WAN;

• MFA;

• IP SLA;

• динамическая маршрутизация — BGP, OSPF и всё, что ещё может понадобиться;

• PBR, VRF, ECMP, DHCP, VLAN, VXLAN;

• централизованное управление;

• интеграция с SIEM;

• интеграция с AD;

• интеграция ещё с чем-нибудь, что было в презентации прошлого вендора.

И всё это желательно:

• на 100 Гбит/с;

• с минимальной задержкой;

• в Active-Active;

• с геораспределённым кластером;

• без потери производительности;

• на отечественном оборудовании;

• с необходимыми сертификатами;

• и, конечно, в пределах бюджета.

При этом российского производства, состоящий во всех возможных реестрах и имеющий все необходимые сертификаты. И главное — недорого, а желательно ещё и по трейд-ин взамен старого. То есть нужен одновременно и суперкар, и грузовик, и ледокол.

А зачем вам это всё?

На этом этапе появляется самый неприятный вопрос для проекта: «А что из этого вам действительно нужно?» И тут полезно разделить требования хотя бы на три категории.

1. Нужно сейчас

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

Например:

• Firewall;

• NAT;

• VPN;

• базовая маршрутизация;

• IPS для определённых защищаемых сегментов и типов трафика;

• интеграция с каталогом пользователей.

Это обязательный минимум.

2. Нужно в обозримом будущем

Функции, которые реально планируется использовать в ближайшие полгода-год.

Например:

• SSL Inspection;

• Application Control;

• URL Filtering;

• Централизованное управление.

Здесь уже можно смотреть на план развития продукта.

3. Когда-нибудь

Это самая интересная категория.

Сюда обычно попадает всё остальное:

• «вдруг понадобится»;

• «хорошо бы иметь»;

• «у прошлого вендора было»;

• «а если через пять лет появится такая задача?»;

• «ну и вообще пусть поддерживает».

Особенность этой категории в том, что она может расти бесконечно. Именно здесь рождается большинство технических заданий на 150 страниц.

А сколько денег?

Есть вопросы, на которые заказчик иногда отвечает удивительно уверенно.

— Какой бюджет?

— Мы не ограничены в бюджете.

Отлично. Это один из самых недолговечных ответов в проекте. Обычно он живёт до первого коммерческого предложения.

После появления спецификации начинается:

«А почему так дорого?»

«А эту лицензию точно нельзя убрать?»

«А давайте вот эту функцию пока не будем брать».

«А мы готовы отказаться от этого».

«А можно как-нибудь дешевле?»

И внезапно выясняется, что бюджет всё-таки был ограничен.

Просто об этом забыли сообщить на первом этапе.

Поэтому бюджет тоже нужно раскладывать на составляющие:

• стоимость оборудования;

• лицензии;

• техническая поддержка;

• обновления;

• централизованное управление;

• резервирование;

• дополнительные модули;

• масштабирование;

• обучение;

• эксплуатация.

Потому что цена NGFW и стоимость владения NGFW — это не одно и то же.

50 оттенков несоответствия

Особенно хорошо это видно, если взять условного заказчика и пройтись по его требованиям.

— Вам нужен IPS?

— Да, обязательно.

— Какой трафик сейчас анализируется?

— Пока никакой.

— Какие сигнатуры критичны?

— Все.

— Вы его будете настраивать?

— А вы нам поможете?

Следующий пункт:

— Нужен Application Control?

— Обязательно.

— Какие приложения необходимо контролировать?

— Все.

— А сейчас что блокируется?

— YouTube.

И так далее…

В итоге получается парадоксальная конструкция: функциональность критически необходима, но сценария её использования нет. Это и есть одно из самых дорогих слов в проектировании информационной безопасности: «Возможно, понадобится когда-нибудь потом».

Сначала определяем задачу, потом коробку

Вместо вопроса: «Какой NGFW выбрать?» гораздо полезнее начать с другого: «Что именно мы защищаем?» И здесь уже появляется архитектура.

Пользовательский периметр

Что нужно защищать?

• офисы;

• филиалы;

• удалённые сотрудники;

• подрядчики.

Интернет-периметр

• исходящий трафик;

• публикация сервисов;

• DMZ.

Периметр ЦОД

• north-south;

• east-west.

Удалённый доступ

• VPN;

• удалённые рабочие места;

• администрирование.

Специальные сегменты

• КИИ;

• технологические сети;

• критичные сервисы.

И вот здесь внезапно выясняется, что «один NGFW для всего» — уже не такая очевидная идея. Один и тот же продукт может прекрасно подходить для интернет-периметра и совершенно иначе показывать себя при защите большого объёма east-west трафика в ЦОД.

Один NGFW на всё?

Иногда да. Иногда нет.

Если у компании:

• один интернет-периметр;

• небольшой ЦОД;

• несколько офисов;

• ограниченное количество пользователей;

• понятный VPN;

то вполне возможно, что универсальный NGFW — лучшее решение.

Но если перед нами:

• несколько ЦОД;

• геораспределённая инфраструктура;

• разные классы пользователей;

• отдельные нормативные контуры;

• высокий east-west трафик;

• большие объёмы VPN;

то попытка заставить одну пару NGFW делать вообще всё может превратить архитектуру в очередной аттракцион.

Особенно когда вместе с функциями безопасности на него пытаются повесить:

• ядро маршрутизации;

• концентрацию BGP;

• роль VPN-концентратора;

• SD-WAN;

В какой-то момент NGFW перестаёт быть средством сетевой безопасности и начинает выполнять функции, для которых изначально предназначались другие компоненты инфраструктуры. И здесь снова появляется простой инженерный принцип: «если у вас есть молоток, это ещё не значит, что любой объект вокруг — гвоздь»

NGFW не обязательно должен становиться маршрутизатором, а маршрутизатор — межсетевым экраном. Да, оба умеют работать с пакетами. Но дальше начинаются нюансы, за которые в будущем приходится расплачиваться.

Особенно когда вместе с функциями безопасности на него пытаются повесить:

• ядро маршрутизации;

• концентрацию BGP;

• роль VPN-концентратора;

• SD-WAN;

В какой-то момент NGFW перестаёт быть средством сетевой безопасности и начинает выполнять функции, для которых изначально предназначались другие компоненты инфраструктуры. И здесь снова появляется простой инженерный принцип: «если у вас есть молоток, это ещё не значит, что любой объект вокруг — гвоздь»

NGFW не обязательно должен становиться маршрутизатором, а маршрутизатор — межсетевым экраном. Да, оба умеют работать с пакетами. Но дальше начинаются нюансы, за которые в будущем приходится расплачиваться.

А теперь про производительность

Здесь начинается второй классический вопрос: «А сколько гигабит он держит?»

И дальше появляется любимая таблица:

Всё прекрасно. Пока не возникает вопрос: «А в вашем трафике эти цифры относятся к какому профилю трафика?»

Потому что заявленные 100 Гбит/с производительности вовсе не означают, что через него можно пропустить 100 Гбит/с реального трафика с включёнными IPS, инспекцией TLS и расширенным логированием. Это две совершенно разные истории. А если добавить маленький размер пакета, большое количество новых соединений, большое количество одновременных сессий, VPN и сложные правила, то паспортная цифра может начать выглядеть совсем иначе. И поэтому сравнивать NGFW только по одной цифре производительности — примерно, как выбирать автомобиль по максимальной скорости, не спрашивая, где на нём собираются ездить.

В хорошем проекте смотрят не на красивую цифру на первой странице технической документации, а на то, что NGFW действительно способен пропустить в условиях реальной нагрузки.

Что нельзя узнать из технической документации

Техническая документация прекрасно отвечает на вопрос:

«Что умеет продукт?»

Но никогда не отвечает на вопросы:

«Насколько удобно с этим жить?»

«Что произойдёт при аварии?»

«Как быстро инженер найдёт проблему в три часа ночи?»

«Что будет с производительностью после включения пяти дополнительных функций?»

«Насколько болезненным окажется обновление?»

И вот это уже невозможно проверить галочкой в таблице.

Поэтому перед покупкой имеет смысл проверять не только функциональность, но и реальные сценарии:

• запуск и изменение правил;

• диагностику;

• отказ одного узла;

• восстановление;

• обновление;

• работу кластера;

• производительность;

• резервирование;

• журналирование;

• интеграцию с существующей инфраструктурой.

Именно здесь очень полезно пилотное тестирование. Потому что иногда две недели тестирования экономят несколько лет эксплуатации неудачного решения.

Поговорим о вендорах

И вот здесь обычно возникает главный вопрос: «А что всё-таки брать?» Пора его снова разворачивать.

У разных вендоров разные архитектурные подходы, наборы функций, модели лицензирования и особенности эксплуатации. Поэтому попытка составить простой рейтинг «кто лучше» довольно быстро превращается в спор о вкусах.

Условно можно представить рынок так.

Вендор А делает акцент на производительности и масштабировании. Для него важны большие объёмы трафика, большое количество сессий и возможность построения крупных кластеров.

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

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

Вендор D может делать акцент на сетевых функциях, VPN, маршрутизации или отдельных сценариях защищённого доступа.

Поэтому условное сравнение лучше строить не по принципу «кто первый», а по тому, для каких сценариев продукт подходит лучше всего.

А что с менее крупными решениями?

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

Если задача заключается в том, чтобы:

• фильтровать трафик;

• организовать NAT;

• обеспечить VPN;

• реализовать базовые функции IPS;

• контролировать доступ пользователей;

• обеспечить необходимую маршрутизацию;

то далеко не всегда требуется максимально функциональный NGFW.

В некоторых проектах более компактное решение может оказаться вполне достаточным.

И здесь появляется довольно простая зависимость: «зачем покупать комбайн на 150 функций, из которых будут использоваться пять?»

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

Она требует:

• обучения;

• сопровождения;

• обновлений;

• тестирования;

• мониторинга;

• документации;

• иногда отдельной лицензии.

В результате получается довольно простой принцип: «Не обязательно покупать самый функциональный NGFW. Нужно купить тот, чью функциональность вы действительно собираетесь использовать». А если завтра выяснится, что вам действительно нужны ещё 145 функций, будет хороший повод написать еще одну статью. 😊

Дорого и плохо

Это, пожалуй, самая неприятная комбинация. Потратить много денег можно практически на любой NGFW. Сделать при этом архитектуру неудобной — тоже. Например: купить мощный NGFW, а затем использовать его как VPN-концентратор с четырьмя правилами Firewall/NAT. Получается весьма дорогой маршрутизатор с чувством собственного достоинства.

Но существует и обратная крайность: купить дешёвое решение, а потом обнаружить, что критичная функция не работает так, как вам надо. И вот тут появляется дилемма: дёшево сейчас или дорого потом?

На практике вариантов даже больше:

дёшево и хорошо — идеально, но практически не встречается;

дорого и хорошо — неприятно, но понятно;

дёшево и плохо — тоже понятно;

дорого и плохо — вот это уже ошибка.

Что действительно надо сравнивать

Я бы сравнивал NGFW не по количеству галочек в функциональном листе, а по нескольким вопросам:

Что нужно бизнесу?

• поддерживает ли DLP;

• есть ли у нас реальный сценарий DLP.

Что нужно ИБ?

• есть ли 50 тысяч IPS-сигнатур;

• какие угрозы мы реально собираемся обнаруживать.

Что нужно сети?

Здесь уже появляются вполне конкретные вещи:

• производительность;

• BGP;

• OSPF;

• VRF;

• ECMP;

• PBR;

• количество маршрутов;

• количество peer'ов.

И очень важно заранее определить, где заканчивается зона ответственности NGFW и начинается зона ответственности сетевой инфраструктуры.

Что нужно эксплуатации?

• насколько просто управлять;

• насколько понятно диагностировать;

• как обновлять;

• как строить кластер;

• как организовать мониторинг.

Что будет через три года?

Потому что NGFW редко покупают на год.

Именно здесь нужно смотреть:

• дорожную карту развития продукта;

• масштабируемость;

• лицензирование;

• производительность на реальном профиле;

• отказоустойчивость;

• надежность вендора.

Болезненный вопрос — лицензирование

Можно долго обсуждать функции. А потом открыть коммерческое предложение и обнаружить:

Firewall входит, VPN — отдельно, IPS — отдельно, SSL Inspection входит, Application Control входит, централизованное управление — отдельно, поддержка — отдельно, обновления входят.

И здесь появляется новая инженерная дисциплина — арифметика.

Причём считать желательно на несколько лет вперёд.

Потому что иногда продукт, который выглядит дешевле на этапе закупки, оказывается дороже после добавления:

• необходимых лицензий;

• поддержки;

• обновлений;

• централизованного управления;

• дополнительных модулей.

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

Как я бы строил выбор

Если совсем упростить, то процесс можно свести к пяти этапам.

Шаг 1. Определить периметры

Что именно защищаем? Пользователей? Интернет? ЦОД? Удалённый доступ? Специальные контуры?

Шаг 2. Определить критичные функции

Что обязательно должно работать в день запуска? Не «хорошо бы иметь», а без чего проект действительно не состоится.

Шаг 3. Разделить требования по горизонту

Сейчас / скоро / когда-нибудь.

Шаг 4. Определить реальную нагрузку

Не паспортную, а ту, с которой NGFW действительно будет работать в инфраструктуре:

• объём и профиль трафика;

• количество одновременных соединений;

• количество новых соединений в секунду;

• доля зашифрованного трафика;

• использование функций безопасности.

Шаг 5. И только теперь смотрим на продукты

В таком случае выбор становится гораздо проще. Потому что из двадцати потенциальных решений останется, например, четыре. А дальше уже начинается нормальная инженерная работа —сравнение. И здесь уже имеет смысл смотреть техническую документацию, проводить пилоты, проверять производительность и задавать неудобные вопросы вендору.

А если хочется совсем просто?

Есть ещё один способ проверить требования.

Перед закупкой задать три вопроса по каждой функции:

1. Что она решает?

Если ответа нет, то, возможно, она не нужна.

2. Когда мы её будем использовать?

Если ответ: «Когда-нибудь», переносим её в третью категорию.

3. Что произойдёт, если её не будет?

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

Итог

Вернёмся к вопросу, с которого начали. Какой NGFW лучший?

Ответ всё ещё: НИКАКОЙ!

Не существует универсально лучшего NGFW. Существует решение, которое в рамках конкретной архитектуры обеспечивает требуемый уровень защиты, производительности, отказоустойчивости и управляемости при приемлемой стоимости владения. Потому что в реальном мире выбор NGFW — это не конкурс презентаций. Это выбор компромисса.

И иногда лучший NGFW — тот, в котором нет двадцати функций, которые вам никогда не понадобятся. А иногда — наоборот. А бывает так, что одна отсутствующая функция способна перечеркнуть все преимущества любого решения.

Именно поэтому ответ на вопрос «Какой NGFW лучше?» должен начинаться не с названия вендора, а с вопроса «какую задачу мы решаем и каким способом хотим её решить?» Всё остальное — уже следующий этап.

Потому что лучший NGFW — это не тот, у которого больше всего функций. А тот, у которого хватает именно тех функций, за которые вы готовы платить.