
Cтарший инженер по автоматизированным системам
управления производством в ICL Services
На российском рынке информационной безопасности растет число проектов с использованием межсетевых экранов нового поколения (NGFW) и криптошлюзов локальных производителей. По данным прошлого года, таких вендоров было более 40. Нередко эти проекты сопровождаются неожиданными подводными камнями, о которых мало кто слышал «на берегу». Они способны негативно повлиять на сроки внедрения и даже архитектуру конечного решения. Собрав опыт команды воедино, Булат Гатауллин, старший инженер по автоматизированным системам управления производством в ICL Services, приведет кейсы, с которыми компания столкнулась при внедрении отечественных решений в инфраструктуры крупных заказчиков.
При выборе NGFW или криптозащиты для построения шифрованных каналов связи, важно заранее ознакомиться с возможностями предложенного оборудования – ведь может получиться так, что устройство просто не поддерживает те технологии, которые ранее были использованы при помощи продукции зарубежных вендоров.
В ряде случаев устройство может не поддерживать:
Практическим путем мы выяснили, что при использовании отечественного NGFW в кластерной конфигурации могут возникать архитектурные ограничения.
Здесь весьма специфично реализован механизм кластеризации устройств – например, иногда после кластеризации отсутствует возможность добавления в кластер нового сетевого интерфейса, (например, VLAN). Если добавление все же необходимо, кластер придется разбирать целиком. Лучшим выходом будет продумать сетевую структуру заранее и заложить некоторое количество избыточных сетевых интерфейсов, которые всегда можно отключить и при необходимости снова включить.
В процессе внедрения отечественных 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-чатах или закрытых группах, что только затрудняет обмен опытом и повышение уровня компетенций.
Несмотря на отдельные технические ограничения, отмечу, что отечественные продукты активно развиваются, технологически догоняя мировых производителей с многолетним опытом. И не только – разработчики прислушиваются к пожеланиям клиентов. У отечественных вендоров неплохо налажена работа технической поддержки, а у избранных производителей файрволов поддержка и вовсе отвечает в течение нескольких минут, что является показателем высокой клиентоориентированности.
Резюмируя, могу сказать, что внедрять отечественные продукты информационной безопасности можно и нужно – нужно заранее закладывая небольшой запас времени на проект, чтобы изучить архитектурные ограничения используемого оборудования. Импортозамещение в ИБ сегодня – это уже не просто тренд, но реальность, которую можно реализовать при условии грамотного технического планирования и подготовки к возможным нестандартным ситуациям.
erid: 2SDnjcGdZch
* Реклама, РекламодательООО «ДжиДиСи Сервисез», ИНН 1660146230
Нажимая на кнопку, я даю Согласие на обработку персональных данных в соответствии с Политикой обработки.
Зарегистрироваться