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

Многие наши клиенты используют для сетевой защиты популярные межсетевые экраны нового поколения (NGFW). С их помощью компании анализируют входящий и исходящий трафик, предотвращают вторжения, строят VPN-тоннели до конечных устройств и так далее. Кто-то приобретает аппаратные или виртуальные NGFW и администрирует их сам, кто-то арендует у нас ресурсы и получает NGFW как сервис. 

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

В статье на примере отечественного UTM UserGate покажу варианты страховки: от временного переключения на отечественный файрвол до полной замены NGFW. 

С чем столкнулись клиенты и чего боятся

Когда компания приобретает NGFW в собственность, она фактически платит по двум моделям: 

• Разовый платеж за программно-аппаратный комплекс или виртуальный аналог. Чаще всего в стоимость физического или виртуального аплайнса уже входит техподдержка.

• Ежемесячная подписка на модули защиты. IPS, IDS, контроль приложений, логирование и другие модули безопасности часто продаются отдельно. Клиент может выбрать только нужную ему функциональность или купить бандл со всеми модулями. Пока подписка активна, оборудование обновляет нужные базы сигнатур, обращаясь к облаку вендора.  

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

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

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

Что нужно уточнить перед внедрением

1. Приватный NGFW или публичный сервис по подписке. В обычной ситуации клиент выбирает приватное решение на своих ресурсах, если хочет сертифицироваться по требованиям ФСТЭК. 

   NGFW по сервисной модели (или MSS) чаще выбирают, если хотят передать администрирование квалифицированным специалистам, а своих в штате нет.

   Но в текущей ситуации появляется еще одно дополнительное преимущество NGFW по подписке в облаке: мы не знаем, сколько продлится ситуация, вернутся ли вендоры, возобновят ли поддержку. А значит, вкладываться в новое “железо” рискованно. Можно переплатить и потом долго ждать поставку на волне повышенного спроса. Любые виртуальные варианты будут дешевле и доступнее. А если прежний вендор вернется, NGFW в облаке можно будет просто потушить без лишних затрат.

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

3. Каковы требования к отказоустойчивости: нужен ли клиенту кластер и в каком режиме. 

4. Какие модули NGFW необходимы клиенту и для чего. Здесь специалисты определяют параметры подписки на дополнительные модули.

5. Это окончательный переезд или временное решение. От этого будет зависеть схема подключения решения в облаке.

6. Где находятся ресурсы клиента. Этот пункт тоже влияет на схему подключения. Например, если клиент уже размещается в наших ЦОД с MSS NGFW, мы можем организовать стыковую сеть между UserGate и клиентскими ресурсами. 

   Если клиент находится на своей площадке, то вместо стыка инженеры построят IPSec-туннель между облаком с NGFW и клиентской площадкой. Главный минус здесь – производительность. 

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

Если хочется сразу переехать

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

Тогда стандартная схема размещения ресурсов за MSS NGFW в нашем облаке будет такой:

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

• в отдельном сегменте DMZ размещены почтовые релеи, обменники;

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

Переезд на UserGate аналогичен процессу миграции на другие MSS NGFW, о чем мой коллега уже рассказывал. Напомню основные моменты:

1. Сначала все сетевые настройки и настройки безопасности переносятся “как есть”: старый конфиг переезжает на UserGate. Чтобы избежать простоя при миграции, инженеры заранее согласуют технологическое окно и детально документируют все параметры: 

   • как сегментирована сеть, 

   • какие VLAN’ы используются,

   • какие типы сетей: routed, isolated (если речь про виртуализацию),

   • как клиент выходит в интернет,

   • как все мониторится,

   • какие NAT-трансляции используются.

   Затем создается отдельная ВМ на UserGate, туда подаются VLAN’ы. Все правила доступа переносятся со старого оборудования, создаются NAT-трансляции с новыми адресами. Инженеры тушат интерфейс на старом NGFW и поднимают интерфейс с таким же адресом на UserGate. Параллельно клиент меняет DNS и последовательно переключает все VLAN’ы. 

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

3. После настраиваем необходимые модули NGFW: IPS, контроль приложений, антивирус. Сначала профили безопасности ставим в режим мониторинга и наблюдаем за срабатываниями, чтобы не заблокировать лишнее. И только потом совместно с клиентом договариваемся о правилах блокировки.

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

Если хочется сначала протестировать

Клиент облака может защитить ресурсы и заодно проверить “на вшивость” UserGate за счет одной из временных схем.

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

2. Поставить UserGate “в разрыв” между интернетом и клиентским файрволом. Это временный вариант, который требует совсем небольших изменений в сетевой инфраструктуре. Трафик будет фильтроваться на UserGate с актуальными сигнатурами, а настройки клиентского NGFW сохранятся на старом оборудовании и переносить их не придется.

   Выглядит схема так: 

   

   В этом случае на UserGate переносятся только правила межсетевого экранирования и настраиваются выбранные модули NGFW: сначала в режиме мониторинга, и только после согласования с клиентом – в режиме блокировки. По договоренности с клиентом также можно добавить на UserGate NAT-трансляции или публикацию ресурсов.

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

3. Завернуть трафик  “петлей” с клиентского NGFW на UserGate. Можно еще сильнее минимизировать вмешательство в существующую сетевую инфраструктуру. В этом случае мы настраиваем стык с пограничным сетевым оборудованием клиента и заворачиваем трафик “петлей” к UserGate, который выступает центром фильтрации. Выглядит так: 

   

   В этом случае на UserGate ничего не переносится со старых сетей клиента, только настраиваются правила межсетевого экранирования и профили защиты.  

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

Что и как можно защитить отечественным UserGate

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

Российская специфика. Здесь у импортозамещения есть формальная и практическая сторона. Начну с формальной – для тех, кому важна сертификация.  

UserGate сертифицирован ФСТЭК России: 

• по требованиям к межсетевым экранам (4-й класс, профили А и Б);

• по требованиям к системам обнаружения вторжений (4-й класс);

• по 4 уровню доверия. 

Большинству клиентов этой защиты достаточно, кроме тех, кто работает с гостайной. 

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

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

На UserGate есть модули, которые интересуют клиентов чаще всего: 

• IPS, 

• антивирус,

• контент-фильтрация,

• IRL-фильтрация

• IPSEC-VPN-тоннели,

• SSL-VPN,

• Mail security,

• контроль мобильных устройств.

Но помимо этого есть специфическая защита, например, поддержка АСУ ТП (Scada). Полный список модулей можно посмотреть здесь. 

Итак, даже в текущей нестабильной ситуации у нас есть выбор, как решить проблему ухода западных NGFW: 

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

• избежать лишних капитальных затрат благодаря помесячной аренде ресурсов по модели MSS NGFW;

• не обязательно сразу переезжать на отечественный NGFW: в облаке можно протестировать решение по гибридной схеме и принять решение.

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