Внедрение своего NGFW на собственной инфраструктуре: как мы ели кактус и что из этого получилось

Если бы всего пару лет назад мы задали вопрос IT- или ИБ-специалисту, какой NGFW лучше выбрать, то все в один голос рекомендовали бы продукты иностранных вендоров. Эти решения созревали десятилетиями, были вне конкуренции по своим характеристикам и, как следствие, доминировали на российском рынке. Сейчас, когда переход на отечественные NGFW должен произойти уже вот-вот, компаниям предстоит не только выбрать оптимальное решение под свои задачи, но и внедрить его на своей инфраструктуре, причем так, чтобы не положить весь корпоративный трафик. На основе опыта внедрения собственного продукта InfoWatch ARMA Стена (NGFW) на своей инфраструктуре рассказываем, как развиваются события, когда компания уже выбрала межсетевой экран и приступает к его пилотированию. В статье – рекомендации для заказчиков NGFW: какие важные моменты нужно учесть на старте, как сформировать список требований и какие шаги нужно предпринять для доработки, чтобы на выходе получить рабочий продукт.

Созданием NGFW мы, как и большинство компаний на российском рынке, вплотную занимаемся последние несколько лет, при этом еще в 2019 году мы разработали и выпустили коммерческий релиз МСЭ для защиты промышленных сетей InfoWatch Industrial ARMA Firewall. То есть в разработке межсетевых экранов мы далеко не новички. На базе этого промышленного экрана была построена первая версия NGFW, а летом 2024 года мы представили новую версию – InfoWatch ARMA Стена (NGFW), с новой архитектурой и аппаратной платформой.

В этой статье Владимир Садовников, СТО InfoWatch ARMA, и Стас Румянцев, продакт-менеджер InfoWatch ARMA, рассказывают о том, как мы решили протестировать на себе все этапы внедрение межсетевого экрана и раскатили наш NGFW на собственной инфраструктуре. Благодаря этому пилоту мы прочувствовали все этапы внедрения МСЭ в двойном объеме – одновременно и как заказчик, и как разработчик.

Как мы решили есть кактус

Владимир Садовников, СТО InfoWatch ARMA: «В 2022 году после ухода зарубежных производителей многие российские компании остались без защиты от кибератак, количество которых резко выросло, поэтому нам было важно предложить рынку рабочий вариант защиты сетевого периметра. Однако по мере разработки функциональности мы пришли к необходимости создания новой платформы для корпоративного NGFW – с новым уровнем производительности и широким набором опций, а значит и другой архитектурой».

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

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

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

Очевидно, что обновленную версию нужно было собирать с учетом запросов и требований этих целевых аудиторий, ставить на пилоты и полученную экспертизу использовать для доработки продукта. Еще до начала внедрения внутри мы начали общаться с клиентами и партнерами на предмет того, какие функции межсетевых экранов им необходимы в первую очередь – здесь и сейчас. Мы проводили опросы чтобы сформировать критически важный набор фичей, опрашивали специалистов, которые эксплуатируют решение и со стороны ИТ, и со стороны ИБ, и постепенно верифицировали список требований. При этом мы помнили про ограничения по сертификации – ведь решение должно заменить критически важные задачи существующих инфраструктур и для этого пройти сертификацию ФСТЭК.

В какой-то момент мы решили съесть кактус целиком и внедрить наш NGFW на инфраструктуру InfoWatch в качестве основного решения. Этот переход позволял нам отладить процесс технической поддержки продукта, провести эксплуатацию последней версии в рабочих условиях и предоставить в команду разработки максимально развернутый отчет о выявленных дефектах. Сейчас это звучит сильно упрощенно, но на практике все происходило гораздо сложнее. В результате внутреннее пилотирование сильно повлияло на весь процесс разработки. Разработчики следовали старому принципу «eat your own dog food», потому что сами первыми сталкивались с результатами своего труда.

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

• составление ТЗ и требований

• доработка

• внедрение

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

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

Составление ТЗ: торг, компромисс и урезание требований

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

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

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

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

Владимир Садовников: «Некоторые заказчики говорят нам – сделайте как у Check Point. А там еще более навороченный комбайн, еще более сложный маршрутизатор, еще больше протоколов, но не все это действительно необходимо. Давайте исходить из своих реальных потребностей, не нужно во всем ориентироваться на западные решения с их спецификой и более чем 50-летним опытом разработки. Не нужно искать цифры и показатели Cisco в отечественных продуктах, лучше оценить то, что реально нужно вашему бизнесу прямо сейчас».

Доработка: производительность и функциональность, которых достаточно

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

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

Важный момент – в контексте доработок продукта стоит упомянуть о скорости и производительности решения и о том, как мы двигались в этом направлении, к каким результатам и выводам пришли. Сегодня «Стена» представлена в трех аппаратных конфигурациях: К10000, К1000 и К100. Все они сертифицированы Минпромторгом и закрывают потребности большинства российских компаний – как правило, в их распределенной инфраструктуре распространены именно сетевые интерфейсы 1 Гбит/сек и 10 Гбит/сек. К слову, в наших собственных сетях только в отдельных точках было 10 Гбит/сек, остальное все было гигабитное. Что касается интерфейсов 25 Гбит/сек или 40 Гбит/сек – это уже уровень дата-центров.

Внедрение: ожидания и реальность

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

Проблема, с которой мы столкнулись, – наша большая сеть, в которой все крутилось на разном оборудовании, оказалась не готова к NGFW. Реальность и наши ожидания сильно разошлись. Тогда мы сделали первый тестовый контур ARMA, который на данный момент работает как полноценная тестовая альфа-лаборатория, куда выгружаются самые свежие версии, а во внешний контур уходят протестированные стабильные релизы. Сначала решение запустили на гостевой сети Wi-Fi, получили мощную обратную связь от коллег (в разных форматах:), и когда добились качественной работы NGFW на этом участке, то перенесли его на более крупный сегмент сети.

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

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

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

Техподдержка, протестированная на себе

Отсутствие качественной техподдержки может остановить любое пилотирование. Мы смогли выстроить процесс так, чтобы он занимал несколько часов, в том числе благодаря тому, что работали в буквальном смысле за одной «стеной»: ИТ и ИБ-служба выступали в роли заказчика, а отдел разработки отвечал за устранение неполадок, поставку фичей и поиск оптимальных конфигураций большого количества взаимосвязанных функций и сервисов.

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

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

Что дальше?

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

До конца 2024 года планируем расширить интеграционные возможности в части взаимодействия с внешними SIEM-системами, консолью управления InfoWatch ARMA Management Console и линейкой DLP-продуктов InfoWatch. Интеграция крайне важна, поскольку внедрение NGFW происходит на сформированной инфраструктуре и МСЭ должен качественно дополнять все ее элементы – например, обогащать SIEM-систему данными, управляться централизованно через привычный интерфейс, давать возможность реализации новых сценариев DLP. И еще мы продолжаем процесс сертификации программной части продукта.

Выводы по результатам внутреннего пилота

Компании, которая решила поставить у себя NGFW, нужно обязательно готовить к этому свою ИБ-службу: пересматривать правила, которыми они закрывали безопасность сети, адаптировать их под новое решение. ИБ-специалистам должно быть удобно работать с новым инструментом.

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

Даже при наличии типовых сценариев универсального NGFW нет и не может быть. Сегменты сети в каждой организации разные, и нагрузка в разных сегментах распределяется по-разному. В одном из наших пилотных проектов у заказчика из промышленного сектора не оказалось единой точки входа трафика, и мы после долгих совместных поисков нашли наиболее критичные места: две точки с кластерами, где реально проходил трафик 10 Гбит/с, и две без кластеров – чуть менее важный сегмент с трафиком до 100 Мбит/с. Это хороший пример того, как у одного клиента для закрытия его потребностей были применены сразу несколько продуктов.

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