Что учесть при переходе на отечественные NGFW

Что учесть при переходе на отечественные NGFW

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

Основные сложности

В 90% проектов «Инфосистемы Джет», связанных с переходом на отечественные NGFW, использовались решения следующих вендоров:

1. UserGate;
2. «Код Безопасности»;
3. ИнфоТеКС;
4. Ideco.

С середины 2022 года мы выполнили более 250 пресейлов по миграции и успешно завершили более 50 проектов. Благодаря полученному опыту получилось выделить четыре кластера основных сложностей:

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

Проиллюстрируем их конкретными примерами.

Принципиально разная архитектура у разных вендоров

Задача. Заменить текущий заграничный NGFW на отечественный, учитывая, что в конфигурации зарубежного использовался необычный способ трансляции адресов: транслировались адреса всех устройств, а хосты, которым NAT (Network Address Translation) не требовался, исключались с помощью гибкого и удобного механизма — правил no-nat.

Сложность. В отечественном NGFW возможность использовать правила no-nat штатными средствами не заложена.

Решение. Проблема может быть решена путём создания правил с инвертированием адресов источника и назначения, а подчас и инвертированием зон. Главная идея состоит в том, чтобы заданные инвертированные критерии в правиле совпали, а само правило не отработало и трансляция адресов не произошла. Дойдя до конца списка NAT-правил, отечественный NGFW перейдёт к обработке трафика следующим модулем и трансляция адресов выполнена не будет. Такой способ можно использовать для реализации переноса конфигурации 1 в 1 при достаточном количестве условий для правила NAT.

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

Неоптимальная архитектура сети до миграции

Задача. Мигрировать WAN-модуль и перенести несколько DMZ-подсетей (/29) с публичными адресами и публичными сервисами за кластер NGFW. При этом любой трафик, покидающий DMZ-подсеть, должен проходить через межсетевой экран.

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

Решение. При проведении работ по миграции на L3-коммутаторе между WAN-блоком и сегментом DMZ был включён функционал VRF-Lite. С помощью данного функционала таблицы маршрутизации изолировались друг от друга. В каждом экземпляре VRF создан виртуальный интерфейс в соответствующей DMZ-подсети и виртуальный интерфейс в стыковочной подсети между коммутатором и NGFW. Для стыковочной подсети использованы приватные IP-адреса. С помощью маршрутизации настроена связность между NGFW и сегментом DMZ. Схема позволила обойти ограничения описания выше и разместить сегмент DMZ за NGFW.

Более низкая производительность по сравнению с западными решениями с тем же набором функционала

Задача. Заменить зарубежное решение на отечественное при миграции ядрового NGFW.

Сложность. Задачу невозможно решить линейной миграцией с одного устройства на другое, поскольку производительность отечественного аналога меньше, чем у зарубежного.

Решение. Использовать совместно с NGFW пакетные брокеры. Архитектура при замене подразумевает использование нескольких независимых единиц межсетевых экранов по схеме N+1. С помощью такой архитектуры удаётся добиться необходимой производительности, сопоставимой с производительностью текущего NGFW или превышающей её. Брокеры сетевых пакетов в этой архитектуре выполняют функции балансировки трафика между узлами by session. Также при такой схеме решается вопрос масштабируемости: при использовании пакетных брокеров всегда можно добавить дополнительные независимые NGFW. 

Невозможность автоматического переноса настроек

Задача. Заменить NGFW с богатой историей эксплуатации.

Сложность. При миграции организация столкнулась с проблемой, что на Cisco ASA много контекстов и тысячи правил. Предлагаемые вендором скрипты для переноса правил работают некорректно.

Решение. Разработан скрипт, обеспечивающий формирование списков объектов и правил из произвольного числа контекстов. Скрипт проверит наличие задублированных объектов и правил в конфигурациях, обеспечивает их переименование, если совпадение частичное: например, одинаковое название группы, но разный состав и игнорирование дубликатов при полном совпадении. Также скрипт умеет оптимизировать правила — формировать одно правиловместо нескольких с одинаковыми адресами назначения и портами, но разными адресами источника. Этот скрипт увеличивает скорость работы команды внедрения и экономит множество сил и времени на внедрение нового NGFW.

Чему стоит уделить внимание на проекте по импортозамещению на рынке сетевой безопасности

Рассмотрим пример типового проекта по миграции на отечественные NGFW. Средняя длительность проекта по нашему опыту составляет от 6 до 12 месяцев, основные этапы выглядят так:

• обследование;
• разработка архитектуры и концепции сегментации с учётом актуальных угроз;
• проектирование и внедрение;
• переключение трафика;
• передача на сервис.

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

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

Если осознанно подойти к процессу, то от перехода на отечественные NGFW можно выиграть:

• улучшить архитектуру и осознанный подход к построению сети;
• актуализировать проектную и рабочую документацию;
• оптимизировать политики NGFW;
• интегрироваться с российской экосистемой ИБ и ИТ;
• создать зоны безопасности NGFW, актуальные угрозам.

Реклама. АО «ИНФОСИСТЕМЫ ДЖЕТ», ИНН: 7729058675, Erid: 2VfnxxcKcBr