На что обращать внимание при внедрении российских NGFW

Ограниченный функционал

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

Кластеризация и архитектура интерфейсов

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

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

Поддержка со стороны вендора: 3 примера из жизни

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

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

1. Ошибка авторизации в Active Directory

На одном из проектов при внедрении отечественного NGFW в качестве прокси-сервера мы столкнулись с тем, что некоторые пользователи, интегрированные из Active Directory, не могли авторизоваться для выхода в сеть. При авторизации у пользователей выходила ошибка:

Дальнейший траблшутинг показал, что вся эта выборка пользователей является членами большого количества групп безопасности AD – а это приводило к превышению лимита на объем заголовка запроса, который обрабатывался в nginx и использовался на NGFW. Благодаря технической поддержке вендора удалось достаточно быстро решить эту проблему путем добавления параметра

()

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

Тем не менее в процессе выполнения запроса выяснились и другие особенности работы NGFW:

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

Отдел разработки вендора пообещал внести эти исправления в новом релизе.

2. Блокировка пользователей после смены пароля в Active Directory

Мы наблюдали случай, связанный блокировкой пользователей, интегрированных из Active Directory: инженеры ИТ-отдела обратили внимание, что довольно часто пользователи теряют доступ в интернет.

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

История стара как мир: после смены пароля пользователь забывает новый пароль или допускает ошибки при вводе, а после нескольких неудачных попыток – блокируется на час. Здесь же происходило иначе: при синхронизации NGFW с Active Directory, заблокированный пользователь оказывался таковым и на межсетевом экране.

При этом после разблокировки пользователя в AD силами ИТ-отдела либо по истечении 60 минут пользователь оставался заблокированным в NGFW, и разблокировать его можно было лишь вручную. Позднее вендор реализовал исправление, и теперь разблокировка происходит автоматически.

3. Проблема доступа к криптошлюзу через агрегированный канал

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

Заключение

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

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

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