Привет, Хабр!

Поскольку я тут впервые, для начала представлюсь. Меня зовут Мария, и я — системный инженер. Работаю в ИТ-департаменте «Лаборатории Касперского», в отделе телекоммуникационной инфраструктуры. Работу люблю и советую, но не всем. Самой интересно:)

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

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

C чего все начиналось

А начиналась история для меня с того, что внутри компании состоялся анонс разработки собственного NGFW. Мы в ИТ-департаменте читали статьи по теме на внутреннем портале, слушали новости на AMA-сессиях. И все ждали, когда же нам дадут посмотреть на новый продукт. Наконец, первая внутренняя демоверсия была готова и к нам постучались.

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

Синтетическим тестам было решено сказать «нет» — они и так в достаточном количестве проводятся разработчиками продукта. Нужна была показательная проверка под реальной нагрузкой, поэтому пилотировать NGFW мы планировали сразу на прод-трафике.
Дело было за малым — найти мотивированных добровольцев, готовых отдать свои сети под защиту нашего продукта. Самой мотивированной оказалась… сама команда разработки NGFW. Ребята были уверены в своем продукте, потому готовы были пилотировать его на себе.

You are (not) prepared

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

Вернее, думала, что была готова. Потому что заранее предусмотреть все было невозможно — я бралась за развертывание бета-версии, в которой еще не все было реализовано, до релиза оставалось еще 4 месяца, и документация была неполная. Поэтому непонятки и приколы, естественно, встретились, но вот только совсем не там, где предполагалось. Оглядываясь сейчас назад, осознаю: вначале я понятия не имела, каким именно вызовом для меня станет этот пилот, где он поставит мне подножки и какой бесценный опыт я добавлю себе в копилку, когда все-таки его закончу.

Задача, первые впечатления и двойственные ощущения

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

Спойлер: по результатам пилота мы составили поэтапный план расширения инсталляционной базы Kaspersky NGFW — уже сейчас мы используем его в нескольких сегментах, а в 2026 году после релиза 1.2, который запланирован на Q1, начнем более масштабный переход.

Пара слов о самом главном нюансе этого пилота. Так как пилотировать фаерволы мне не впервой, я еще перед началом работ в уме расставила майлстоуны. Продумала, куда смотреть и что щупать, чтобы правильно понять, где все работает хорошо, а где надо допилить или переделать. Но самым большим сюрпризом для меня стало то, что для работы с продуктом мне пришлось развернуть Open Single Management Platform (OSMP) — это масштабная и на первый взгляд довольно сложная платформа, которая является также ключевым компонентом Kaspersky Symphony XDR, и подробнее об этом опыте я расскажу чуть ниже.

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

О железния: получилось с третьего раза

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

И все же ребята из команды разработки Kaspersky NGFW были уверены в надежности своего продукта даже без кластера.

Резюмируя, первая аппаратная платформа beta-2 в наших тестах — по одному устройству для каждой команды.

Подписали релиз beta-2, и RnD передали железку. Когда мы ее получили, даже коллеги из соседних отделов сбежались посмотреть.

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

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

Был и плюс — дисков там два. Переустановили все на рабочий и снова запустили. Минус — пришлось настраивать систему с нуля во второй раз.

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

Система централизованного управления фаерволами OSMP: главный вызов, превратившийся в ценнейший опыт

Вместе с настройкой оборудования передо мной стояла еще одна важная задача — развертывание системы централизованного управления. Как я уже упоминала, внедрение OSMP в рамках тестирования NGFW стало одним из неожиданных, но в то же время интересных и познавательных этапов всего проекта. За плечами у меня уже был опыт работы с разными фаерволами, и каждый из них имел свои особенности развертывания и управления. OSMP удивила: процесс был в своем роде уникальным и не совсем похожим на то, с чем я сталкивалась ранее.

Поначалу все выглядело довольно масштабно, опыта работы с такого рода решениями у меня еще не было. Документация впечатляла объемом, а системные требования поражали воображение. В большинстве случаев для работы с NGFW достаточно развернуть виртуальную машину, активировать лицензии, задать IP — и на этом все.

Но OSMP — это не просто система управления NGFW, а целая платформа со множеством компонентов и ролей, которая интегрирует различные решения в единую продуктовую экосистему. Установка включает развертывание кластера Kubernetes, СУБД и множества других элементов.

К счастью, при тестировании beta-версии у меня была возможность обратиться за поддержкой к коллегам из разработки, и это стало поворотным моментом. После консультаций выяснилось, что все не так страшно, как казалось на первый взгляд. Многие моменты процесса автоматизированы, главное — грамотно заполнить конфигурационный файл.

Когда развертывание завершилось, передо мной открылся долгожданный веб-интерфейс OSMP. Он насыщен — много незнакомых сетевому инженеру элементов и настроек, а управление NGFW не сразу бросается в глаза. Например, поиск событий в логах реализован через SQL-запросы — необычно, но в теории дает мощные возможности для анализа. И это лишь часть того, что открывает перед пользователем OSMP.

Главное, что помогает быстро освоиться, это понимание концепции: OSMP — это не просто инструмент для работы с NGFW, а мощная платформа для управления безопасностью всей ИТ-инфраструктуры. Да, она требует немного иного подхода, особенно от специалистов, привыкших к классическим решениям. Но именно такие вызовы развивают и расширяют профессиональный кругозор.

Сценарии тестирования: как и что проверяли

Помимо подготовки инфраструктуры, необходимо было разработать ПМИ. Версия продукта beta-2 обладала минимально необходимым и достаточным функционалом, который позволял, хоть и с некоторыми оговорками, встроить Kaspersky NGFW в инфраструктуру на место фаервола другого производителя, защищавшего сети команды NGFW на тот момент.

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

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

Немного про ПМИ

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

Сценарии выполнялись в режиме сравнения — есть ли функция в нашем NGFW, можно ли ее воспроизвести в том или ином виде. Если функции не было, оценивали, насколько тяжело будет обходиться без нее. По выявленным доработкам функциональности расставляли приоритеты. Плюс я, с учетом своего практического опыта работы с фаерволами, выявляла необходимость UX-улучшений. Например, непонятную логику создания правил или переизбыток кликов для какого-то действия. Такие моменты и предложения по доработкам тоже добавлялись в столбец для моих комментов.

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

Вот как это выглядело:

Немного о некоторых сценариях

Одним из самых важных моментов не только для фаерволов, но и для любого сетевого оборудования, является наличие выделенного менеджмент-интерфейса. Он должен иметь собственное пространство маршрутизации, также должна быть возможность ограничения доступа к нему (ACL или local-in policy). Если с первым у Kaspersky NGFW все отлично, менеджмент-интерфейс находится в собственном VRF, то второе следует отметить звездочкой. Ограничивать доступ к менеджмент-интерфейсу пока что можно только через system shell, используя старый добрый iptables. Тем не менее функционал есть, а допилить его обещают совсем скоро — в релизе 1.1 в конце сентября 2025 г.

Также одним из самых первых тест-кейсов была проверка работы port-channel. Нам важно, чтобы фаервол умел работать с агрегацией физических интерфейсов по протоколу LACP. Собрали агрегированный интерфейс на фаерволе (там он называется bond), port-channel на нашем коммутаторе Cisco и… ничего. Интерфейс перешел в состояние lacp-suspended, LACPDU не ходят. Проблема решилась, когда я заменила в фаерволе трансиверы производства FS на Finisar. При этом в документации к beta-2 не было информации о списке поддерживаемых трансиверов — пришлось действовать интуитивно. Подсветили этот момент разработчикам, обещали организовать поставку поддерживаемых трансиверов с релиза 1.0.

Также проверяла возможность экспорта/импорта конфигурационного файла. С этим у Kaspersky NGFW все супер. Файл экспортируется в человекочитаемом формате JSON или XML на выбор.

Перейдем к функционалу фаервола. Сначала рассмотрю объекты, которые доступны для создания. Тут почти все стандартно: хост, сеть, диапазон, сервис. FQDN-объекты обещают завести к релизу v1.0 (конец июля 2025 г.). Небольшим неудобством стало отсутствие групп в beta-2, которое разработчики обещают реализовать в Q1 2026.

О правилах сетевого доступа. Было приятно узнать, что уже на этапе беты поддерживается до 20 000 правил на одном устройстве без потерь в производительности, а то некоторые вендоры в этом плане действительно могут неприятно удивлять. Процесс создания правил не вызвал у меня каких-либо сложностей.

Также проверила и работу модуля IDPS. Попросила коллег сымитировать пару атак в своих сетях — отловил все без исключений. А вот при создании IDPS-профиля столкнулась с некоторой непрозрачностью. Я привыкла видеть список всех имеющихся сигнатур, с базовой информацией по каждой, с возможностью выбирать, какие именно я хочу добавить в свой профиль (поштучно или с помощью фильтра по тому или иному полю). В Kaspersky NGFW это пока не реализовано, но уже внесено разработчиками в роадмап.

Протестировала и работу App-фильтрации. Радует наличие Unknown Application как отдельной категории. Определение имеющихся приложений работает хорошо, не было ни одной проблемы за время пилота.

Ну и напоследок, пожалуй, расскажу о просмотре событий, реализованном в ОSMP. Окно просмотра событий выглядит вот так:

Как я уже упоминала, поиск событий осуществляется с помощью SQL-запросов. Для меня это было что-то новое и поначалу вызвало неоднозначную реакцию, но потом я обнаружила удобную возможность — добавлять условия в запрос прямо из контекстного меню в событиях. Более того, готовые запросы можно сохранять в память и выбирать те, которые будут запускаться автоматически при переходе в данный раздел OSMP. Со временем я поняла, что интерфейс достаточно гибкий и удобный.

Примерно так и происходила проверка сценариев. Я описала далеко не все, а только те, которые показались мне наиболее интересными и показательными.

Что особенно порадовало: интерфейс, производительность, компактность, эффективность

Среди всех сильных сторон, выявленных в ходе тестирования, отдельно хочется выделить графический интерфейс. Уже на текущем этапе он выглядит очень достойно и современно. Конечно, развитие всегда возможно — особенно в таких масштабных продуктах — но уже сейчас GUI продукта может уверенно конкурировать с лучшими зарубежными аналогами.

Также радует, что при отличной производительности устройство получилось весьма компактным и занимает один юнит в стойке.

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

Выводы и роадмап

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

Да, это пилотирование оказалось куда более насыщенным и непростым, чем я изначально предполагала, пришлось быстро осваивать новые для себя инструменты и подходы. В процессе тестирования бета-версии NGFW заметным стало направление, которое стоит улучшать: упростить развертывание OSMP и управление NGFW через консоль. Несмотря на то что пришло понимание, что Kubernetes — новый стандарт для развертывания крупных Enterprise-систем, требующих отказоустойчивости и гибкого масштабирования, хочется сделать решение более доступным для сетевых инженеров и сократить время на настройку. Также было бы здорово, если бы интерфейс стал еще более интуитивным, особенно в случаях, когда требуется быстрое и гибкое управление фаерволами в рамках конкретных задач. 

По словам команды разработки, эти улучшения станут (а некоторые уже стали) частью ближайших релизов, так что с нетерпением ждем реализации новых требований, которые мы подсветили коллегам! 

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

Ну и самое главное — пилот постепенно переходит в этап внедрения. Мы составили поэтапный план расширения инсталляционной базы Kaspersky NGFW — релиз 1.0 (август 2025 г.) будет использоваться в нескольких сегментах корпоративной сети, а начиная с 1.2 (Q1 2026), мы стартуем более масштабный постепенный переход с текущих NGFW на наш собственный.