В первой части статьи про KNGFW мы разобрали, как собрать контур управления, связать компоненты и получить рабочую основу. Но на этом этапе NGFW всё ещё остаётся «правильно собранным железом». Оно готово к работе, но само по себе ещё ничего не защищает.
В это статье начинается самое интересное: момент, когда устройство начинает «оживать». Появляются реальные правила, через него идёт трафик уже не в тестовом, а в рабочем режиме, а сама система из набора компонентов превращается в полноценный элемент инфраструктуры.
Дальше материал будет максимально прикладным. Сначала собирём базовую конфигурацию: сеть, доступы, NAT, логирование, интеграции. Всё, на чём держится повседневная работа. А затем переходим к модулям безопасности и той задаче, ради которой NGFW в принципе и внедряется.
Настройка KNGFW: базовая конфигурация, интеграции и ключевые модули безопасности
После того как контур управления развёрнут, устройства добавлены в систему, шаблоны подготовлены, а кластерная логика приведена в рабочее состояние, можно переходить к следующему большому этапу — непосредственной настройке KNGFW. Именно здесь решение начинает восприниматься не просто как аппаратный узел, а как полноценный рабочий межсетевой экран, встроенный в инфраструктуру и готовый к повседневной эксплуатации.
Этот раздел логично разделить на две части. Сначала имеет смысл пройтись по базовой конфигурации, без которой дальнейшая работа с устройством будет неполной: сетевые параметры, политики фильтрации, NAT, интеграция с внешней SIEM, логирование и наблюдаемость. Это тот фундамент, на котором потом уже будет строиться вся защитная логика решения.
Следующий шаг — основные модули безопасности, которые доступны в KNGFW на текущем этапе развития продукта. Здесь важно отдельно подчеркнуть, что KNGFW во многом воспринимается как profile-based решение, то есть защитная логика строится не только на самих правилах доступа, но и на наборах профилей безопасности, которые затем привязываются к сетевым политикам. Такой подход хорошо знаком тем, кто уже работал с современными NGFW: сначала создаются и настраиваются сами профили, затем они комбинируются с правилами фильтрации и применяются к нужным сценариям трафика.
Базовая конфигурация KNGFW
Прежде чем переходить к защитным механизмам, важно довести до рабочего состояния базовую эксплуатационную конфигурацию устройства. На практике именно этот этап определяет, насколько удобно KNGFW будет жить в инфраструктуре дальше, а именно:
-
насколько предсказуемо будут применяться правила;
-
как будет выглядеть публикация сервисов;
-
куда уйдут события безопасности;
-
как в целом будет организовано сопровождение решения.
Проще говоря, здесь мы настраиваем не «киберзащиту в чистом виде», а тот слой, без которого сама защита не сможет полноценно работать в боевом окружении. Поэтому в первую очередь стоит последовательно пройтись по сетевой части, правилам межсетевого экрана, NAT, журналированию и интеграции с системами мониторинга и анализа событий.
После завершения развёртывания основная работа переносится в централизованный интерфейс управления.
Именно здесь будут создаваться объекты, зоны, правила фильтрации, NAT-политики, профили безопасности и параметры взаимодействия с внешними системами.
Настройка маршрутизации и NTP
С маршрутизацией здесь всё достаточно понятно: на этом этапе в шаблонах задаются маршруты, через которые KNGFW будет достигать как внешние сети, так и внутренние служебные сегменты, в том числе контур управления, backend-слой и системы наблюдаемости.
С практической точки зрения это важный момент по двум причинам:
-
Во-первых, именно от корректной маршрутизации зависит доступность KSC, KNBE и всех внешних систем, с которыми KNGFW должен взаимодействовать.
-
Во-вторых, проблемы на этом уровне впоследствии часто выглядят как «не работает шаблон», «не приходят события» или «не подключается backend», хотя реальная причина лежит именно в связности и таблице маршрутов.
Рядом с маршрутизацией логично сразу настроить и NTP. На первый взгляд это выглядит как второстепенная системная деталь, но в эксплуатации время на сетевом устройстве — это база для корректных журналов, сопоставления событий, работы SIEM, анализа инцидентов и нормальной технической поддержки. Если время на NGFW расходится с остальной инфраструктурой, расследование даже простых инцидентов быстро приводит к лишней ручной работе.
Поэтому здесь лучше не откладывать NTP «на потом», а сразу включить его в состав базовой конфигурации. На практике это означает, что ещё до перехода к правилам безопасности устройство уже должно иметь:
-
корректную сетевую связность до NTP-источников;
-
понятную схему маршрутизации для management и служебного трафика;
-
синхронизированное время, которое будет использоваться в системных и security-журналах.
Сетевая конфигурация и объекты
Следующий шаг — это подготовка сетевых сущностей, которые затем будут использоваться в правилах и профилях. Сюда относятся адресные объекты, группы объектов, сервисы, зоны безопасности, интерфейсы.
Смысл этого этапа простой: чем аккуратнее здесь собрана база сущностей, тем проще дальше сопровождать политику межсетевого экрана. Если с самого начала договориться о внятной структуре объектов, именовании зон и логике сервисов, то последующая конфигурация читается заметно легче, а сами изменения вносятся более предсказуемо.
Именно на этом уровне закладывается удобство эксплуатации. То есть дальше инженер работает уже не с «сырыми IP-адресами и портами», а с понятными объектами и логическими группами, из которых затем собираются правила доступа и политики безопасности.
Настройка зон
После того как базовые интерфейсы и сетевые объекты подготовлены, необходимо настроить зоны. В практической эксплуатации это один из ключевых элементов конфигурации, потому что именно зоны дальше становятся основой для правил межсетевого экрана, NAT-политик и части защитной логики.
Если говорить проще, зона — это логическое объединение интерфейсов с одинаковой ролью в политике безопасности. Такой подход удобен тем, что позволяет строить правила не от конкретного физического порта, а от понятной сетевой роли: например, внешняя зона, внутренняя зона, DMZ, management-сегмент или отдельные технологические подсети. В результате политика становится более читаемой, масштабируется проще и не требует постоянной пересборки при изменении отдельных интерфейсов.
На практике этот этап лучше не воспринимать как формальность. Если зоны изначально собраны неаккуратно, дальше это почти всегда отражается на всей конфигурации: правила становятся менее прозрачными, NAT начинает хуже читаться, а логика доступа между сегментами быстро теряет наглядность. Поэтому лучше сразу придерживаться простой и воспроизводимой схемы: один смысловой сегмент — одна зона с понятным названием и предсказуемой ролью в политике.
На следующем этапе именно зоны становятся одной из главных опорных сущностей для настройки FW-правил. Поэтому их удобно рассматривать как промежуточный, но очень важный слой между базовой сетевой конфигурацией и самой политикой безопасности.
Политики межсетевого экрана (FW)
После подготовки объектов можно переходить к классической сетевой политике — правилам межсетевого экрана. Здесь всё устроено достаточно привычно: определяются источник и назначение, зоны, сервисы, действие правила, а также параметры журналирования и привязки дополнительных защитных механизмов.
С точки зрения логики KNGFW — это важный слой, потому что именно через него потом «подцепляются» профили безопасности. То есть правило межсетевого экрана здесь выполняет не только роль классического allow/deny, но и становится точкой применения защитной логики. Например, SSL-инспекции, IDPS, антивирусной проверки и других модулей.
С точки зрения человека, который все настраивает — это удобно. Базовая политика доступа и безопасность не живут в отрыве друг от друга, а собираются в единую эксплуатационную схему. При этом сами правила остаются понятными и читаемыми, особенно если заранее аккуратно подготовлены объекты, зоны и сервисы.
NAT и публикация сервисов
Следующий обязательный блок — NAT. В повседневной эксплуатации он обычно отвечает либо за публикацию внутренних сервисов во внешние сети, либо за исходящую трансляцию трафика при доступе пользователей и систем в интернет.
В KNGFW NAT настройки практические такие же, как и на других сетевых устройствах. Для публикации внутренних сервисов используется DNAT: задаются внешний адрес или интерфейс, нужный сервис и внутренний узел, на который должен быть передан трафик.
Для исходящего доступа используется стандартный SNAT или маскарадинг в зависимости от схемы адресации и логики выхода в сеть.
Важно, что NAT здесь не стоит рассматривать в отрыве от остальной политики. На практике публикация или исходящая трансляция почти всегда проверяются в связке с firewall-правилами, зонами и сервисами. Поэтому при диагностике нужно смотреть не только на то, разрешён ли трафик самим правилом FW, но и на то, какое правило NAT в итоге к нему применилось.
Интеграция с SIEM и наблюдаемость
Отдельный важный блок в базовой конфигурации — интеграция KNGFW с SIEM. В реальном мире это не дополнительная опция, а обязательная часть ввода решения в нормальную эксплуатацию. Без неё межсетевой экран может и будет корректно обрабатывать трафик, но останется «слепым» с точки зрения сопровождения, расследования и контроля происходящего.
Поэтому я хочу показать, как организуется отправка журналов и событий безопасности из KNGFW во внешнюю SIEM. Обычно на старте наибольший интерес представляют системные события, журналирование правил межсетевого экрана, срабатывания защитных модулей и события, связанные с критичными изменениями состояния устройства.
Здесь важно разделять системные события и события безопасности.
-
Системные события описывают состояние самого KNGFW: работу сервисов, изменения конфигурации, состояние интерфейсов, кластера и других служебных компонентов.
-
События безопасности относятся уже к обработке трафика: срабатывания правил FW, IDPS, SSL/TLS-инспекции, антивируса, DNS Security и других защитных механизмов.
Проще говоря, системные события отвечают на вопрос «что происходит с устройством?», а события безопасности — на вопрос «что происходит с трафиком и как на него реагирует KNGFW?»
Мониторинг состояния устройства
Помимо отправки security-событий во внешнюю SIEM, полезно сразу закрыть и вторую эксплуатационную задачу — мониторинг технического состояния самого устройства. Эту часть мы реализовали с помощью Zabbix. Если SIEM в большей степени отвечает за анализ журналов и событий безопасности, то Zabbix в такой схеме удобен именно как слой повседневной наблюдаемости. Он позволяет отслеживать здоровье узла, состояние интерфейсов, нагрузку и общую эксплуатационную картину.
Удобно, что шаблон мониторинга для Zabbix входит в поставку решения, поэтому здесь не требуется собирать всю логику наблюдаемости с нуля. Это заметно упрощает старт. Базовый набор метрик и сущностей для мониторинга уже подготовлен вендором, и его остаётся только корректно применить в своей системе. Благодаря этому подключение KNGFW к Zabbix выглядит понятно и не требует какой-то нетиповой интеграции.
С технической точки зрения сама настройка тоже не вызывает сложностей, поскольку строится на вполне привычной схеме через SNMP. То есть на стороне KNGFW подготавливаются параметры SNMP-доступа, после чего устройство добавляется в Zabbix с использованием штатного шаблона мониторинга.
За счёт этого решение быстро встраивается в уже существующий контур наблюдаемости и начинает отдавать необходимые эксплуатационные метрики.
Практическая ценность здесь в том, что мониторинг позволяет заметить проблему ещё до того, как она перерастёт в полноценный инцидент безопасности или отказ сервиса. Например, деградация линка, нестабильное состояние интерфейса, рост нагрузки, проблемы со служебной связностью или отклонения в работе кластера. Всё это удобнее видеть именно в системе мониторинга, а не пытаться потом собирать постфактум по разным журналам.
Поэтому Zabbix здесь рекомендую воспринимать не как «ещё один дополнительный инструмент», а как обязательную часть эксплуатационной обвязки KNGFW. В результате картина получается полной:
-
SIEM отвечает за события безопасности и журналирование;
-
Zabbix за здоровье устройства, интерфейсов и базовую эксплуатационную телеметрию.
На этом этапе можно считать, что базовая подготовка KNGFW завершена. Мы уже собрали сетевую часть, настроили зоны, маршрутизацию, синхронизацию времени, подготовили правила доступа, NAT, логирование и контур наблюдаемости. То есть устройство к этому моменту уже выглядит не как тестовый стенд, а как вполне нормальный элемент инфраструктуры, который можно дальше осмысленно вводить в эксплуатацию.
Модули безопасности KNGFW
Этот блок уже не про базовую сетевую связность и эксплуатационную обвязку, а про те механизмы, за счёт которых KNGFW начинает выполнять именно защитную функцию. В текущей логике решения они организованы по profile-based модели: сначала создаются и настраиваются профили безопасности, а затем эти профили привязываются к нужным правилам доступа и применяются к соответствующему трафику.
Такой подход делает конфигурацию более структурированной. Сетевая политика и защитная логика не смешиваются в одном перегруженном правиле, а разделяются на два понятных уровня: отдельно описываются условия прохождения трафика, отдельно механизмы его проверки и контроля. За счёт этого конфигурация легче читается, проще переиспользуется и удобнее сопровождается в дальнейшем.
Перед тем как переходить к отдельным модулям, коротко покажу, где именно в интерфейсе находятся профили безопасности и как в целом выглядит этот раздел настройки.
После этого уже можно последовательно пройтись по тем модулям, которые доступны в KNGFW на текущем этапе и представляют наибольший практический интерес.
2SSL/TLS Inspection
Логично начинать именно с SSL/TLS-инспекции, потому что для многих других модулей — это базовый элемент видимости. Без расшифровки существенная часть современного трафика для межсетевого экрана остаётся «непрозрачной», а значит, контроль приложений, часть сигнатурной логики и более глубокая инспекция будут ограничены.
В KNGFW SSL/TLS-инспекция выстраивается через отдельные настройки в разделе политик. На практике здесь задаются параметры расшифровки, сертификаты, правила применения, а также исключения. Например, по категориям сайтов или отдельным доменам.
Это важный момент, потому что внедрение SSL-инспекции почти всегда требует аккуратного баланса между глубиной контроля и эксплуатационной устойчивостью: без исключений легко получить конфликты с банковскими, государственными или иными чувствительными ресурсами.
Ниже показал, как в интерфейсе KNGFW выглядят правила SSL/TLS-инспекции, где настраивается само правило расшифровки. Стоит подчеркнуть, что в составе такого правила необходимо явно указать сервис HTTPS (443/tcp). Это принципиальный момент, потому что именно благодарю этому, правило начинает применяться к нужному трафику. Если этот шаг пропустить, логика расшифровки в ожидаемом виде работать не будет.
После того как само правило инспекции создано, остаётся встроить его в реальную политику доступа, то есть включить расшифровку в тех правилах, через которые пользователи или хосты выходят в интернет. Это важный шаг. Пока профиль не привязан к рабочему правилу доступа, инспекция фактически не будет задействована на реальном трафике.
Дальше можно переходить к самой простой и наглядной проверке работоспособности. Для этого достаточно открыть любой сайт и посмотреть, какой сертификат видит браузер. Если SSL/TLS, инспекция применена корректно. Будет видно, что сертификат подменён и межсетевой экран выступает в роли MITM-прокси.
Отдельно мы проверили исключения для банковских ресурсов. Как видно на примере, после добавления такой категории в список исключений, сертификат уже не подменяется, то есть трафик корректно обрабатывается без SSL/TLS-инспекции.
Все проделанное выше — это фундамент для дальнейшей работы с «богатыми» сценариями безопасности. Именно он дает возможность видеть прикладной трафик глубже и применять к нему остальные механизмы контроля уже не вслепую, а с полноценной инспекцией содержимого.
IDPS
Перед тем как перейти к самому модулю, стоит коротко обозначить общую механику. В KNGFW основные защитные функции настраиваются через профили безопасности. Именно здесь будет собираться вся прикладная логика.
Чтобы не перегружать разбор, для ознакомления мы покажем эту схему на одном общем профиле. На его примере будет проще последовательно пройтись по каждому модулю. И начнем мы с IDPS.
IDPS настраивается отдельным профилем и затем привязывается к соответствующим правилам фильтрации. В нашем сценарии мы смотрели не только на факт срабатывания, но и на то, насколько логично события потом выглядят в журнале и SIEM.
Самое основное — тесты. Мы старались не «ломать стенд», а проверять сценариями, похожими на реальные:
-
DNS‑туннелирование (на базе инструмента DNSlivery);
-
несколько CVE‑сценариев на уровне HTTP веб‑слоя, чтобы проверить сигнатурную часть и реакцию на попытки эксплуатации.
В нашей SIEM, взаимодействие с которой мы разбирали немного выше, это выглядело таким образом:
Впечатление от модуля в целом осталось положительным. Он быстро вводится в работу, даёт понятный результат и уже на старте закрывает базовую потребность в сигнатурной защите трафика. При этом в практической эксплуатации нам не хватило гибкости. Прежде всего в части настройки сигнатур, выбора их набора под конкретные сценарии и возможности добавлять собственные.
При этом сам вектор развития здесь выглядит перспективно. Насколько мы понимаем, работа над этой частью уже идёт, и в обозримом будущем у продукта должна появиться более гибкая сигнатурная настройка. Это сделает модуль заметно сильнее для более зрелых и масштабных сценариев эксплуатации.
Antivirus
Антивирусный модуль KNGFW логично рассматривать как следующий защитный слой. Уже не только на уровне сетевых взаимодействий, но и на уровне самих передаваемых объектов. В реальной эксплуатации это важно прежде всего для сценариев загрузки файлов, веб-доступа и базовой проверки вредоносного содержимого, проходящего через межсетевой экран.
Антивирусный блок в KNGFW мы проверяли как в потоковом, так и в объектном режиме. Сигнатуры подтягиваются через KSN, и в типовом сценарии это именно тот уровень «базовой гигиены», который ожидаешь от NGFW. Вредоносные файлы и подозрительные ресурсы должны отрезаться до попадания на хосты.
Вся настройка также происходит через профиль данного модуля.
Для проверки мы использовали классический EICAR‑файл. В первом заходе NGFW блокирует скачивание, а при повторной попытке выдает страницу блокировки (если включено отображение страницы).
Видно, что модуль работает стабильно и предсказуемо. Дополнительно проверяли URL‑категории «malware» и «phishing» на тестовых страницах и тоже получили ожидаемый результат.
Также не стоит забывать об исключениях. Профиль антивируса позволяет исключать проверку для конкретных URL/IP (в разумных пределах). Это полезно, когда есть доверенные внутренние репозитории, специфичные интеграции или сервисы, которые страдают от ложных срабатываний. Такие исключения помогают снижать нагрузку и избегать сюрпризов для критичных бизнес‑процессов.
На следующий шаг в виде интеграции антивирусной части с KATA Sandbox тоже стоит обратить внимание. В нашей конфигурации мы до этого не дошли, но в облачном контуре такой сценарий выглядит многообещающе. Подозрительные объекты можно отдавать в песочницу за поведенческим вердиктом и уже по нему блокировать или разрешать.
DNS Security
Ещё один важный модуль — DNS Security. На первый взгляд он может показаться более «точечным», чем SSL-инспекция или IDPS, но на практике он закрывает очень понятный и применимый на практике сценарий — контроль DNS-трафика и ограничение доступа к вредоносным или нежелательным ресурсам уже на этапе DNS-резолвинга.
В KNGFW этот модуль также органично вписывается в общую модель профилей безопасности. Он позволяет инспектировать DNS-запросы и ответы, а в зависимости от политики либо блокировать обращение к проблемным ресурсам, либо перенаправлять его в сторону sinkhole-сценариев.
Настройка заняла буквально несколько минут: включить DNS Security, определить политику реакции и указать адрес sinkhole (если используется перенаправление).
В эксплуатации модуль работает довольно прозрачно. Основные вопросы обычно сводятся к тому, какой DNS‑трафик мы пропускаем через NGFW (все ли резолверы/клиенты попадают под инспекцию), и как мы хотим обрабатывать исключения для внутренних доменов.
WEB Control
Ещё один важный этап — это веб-контроль. По сути, речь идёт о механизме URL-фильтрации, который позволяет управлять доступом к нежелательным, нерелевантным или потенциально рискованным веб-ресурсам. С практической точки зрения это удобный инструмент не только для базового ограничения доступа к определённым категориям сайтов, но и для более аккуратного сценария, когда пользователю сначала показывается предупреждение, а уже затем принимается решение о предоставлении доступа.
На практике настройка начинается с создания нового профиля веб-контроля в уже знакомом разделе. Здесь задаётся его имя, и при необходимости включается использование KSN для более точной категоризации объектов. После этого уже можно переходить к основному содержанию профиля — действиям для URL-категорий.
В качестве примера можно использовать два довольно показательных сценария. Для категории социальных сетей удобно задать действие предупреждения. В этом случае пользователь при открытии ресурса не блокируется сразу, а попадает на страницу-предупреждение, где может осознанно принять решение о продолжении. Это мягкий и довольно практичный сценарий, когда доступ не запрещается жёстко, но сам факт обращения к такой категории всё равно фиксируется и становится видимым в логах.
Для второй категории, например, поиска работы, уже можно задать более строгую реакцию и показывать страницу блокировки. Такой вариант подходит для тех случаев, когда доступ к определённому классу ресурсов должен быть ограничен полностью, без возможности обхода через предупреждающую страницу. Отдельно полезно включить логирование, чтобы обращения к этим категориям попадали в журнал и могли дальше анализироваться уже в общем контуре наблюдаемости.
После подготовки самого профиля его нужно не забыть включить в группу профилей безопасности, а также добавить проверку трафика для правила выхода в интернет.
Проверка работы модуля выглядит достаточно просто. Например, при открытии vk.com, если сайт попадает под категорию социальных сетей, пользователь перенаправляется на страницу предупреждения. На этой странице обычно отображается полезная диагностическая информация: сам URL, категория сайта, имя профиля Web Control и адрес клиента. Если в профиле настроен мягкий режим предупреждения, пользователь может проигнорировать предупреждение и продолжить работу.
В более жёстком сценарии, например, для категории поиска работы, будет уже отображаться страница блокировки и доступ к ресурсу окажется запрещён полностью.
В результате веб-контроль в KNGFW воспринимается как довольно практичный модуль: он легко встраивается в общую profile-based логику, быстро настраивается на базовом уровне и даёт понятный прикладной результат уже на первом тестировании. Особенно полезно, что здесь можно не ограничиваться жёсткой блокировкой, а выбирать более гибкие сценарии: от предупреждения пользователя до полного запрета доступа с обязательным журналированием событий.
Таким образом, на этом этапе мы последовательно прошлись по основным модулям безопасности, которые на текущий момент доступны в KNGFW, и показали, как они собираются в рамках единого профиля безопасности. По сути, именно здесь видно, как работает profile-based логика решения: отдельные механизмы не настраиваются изолированно, а объединяются в общую защитную схему, которая затем применяется к нужным правилам доступа и начинает работать уже на реальном трафике.
На практическом уровне мы посмотрели, как выглядит сама настройка профилей, как отдельные модули включаются в общую группу безопасности, как задаются их параметры и как проверяется их работа в реальных сценариях: от SSL/TLS-инспекции и IDPS до антивирусной проверки, DNS Security и веб-контроля. За счёт этого KNGFW начинает восприниматься уже не просто как межсетевой экран с набором отдельных функций, а как достаточно цельная платформа сетевой защиты, где базовая сетевая политика и прикладные механизмы безопасности связаны между собой в единую эксплуатационную модель.
KNGFW: сильные стороны, ограничения и сравнение с другими NGFW
Что понравилось в эксплуатации
Первое и, пожалуй, главное — единый контур управления. Если в инфраструктуре уже есть KSC и KES, добавление KNGFW в ту же солянку будет очень органичным. И это не только вопрос удобства, но и вопрос зрелости процессов: роли, шаблоны, изменения и инвентаризация начинают жить в более цельной системе.
Второй сильный момент — шаблоны. После первичной настройки становится понятно, что именно шаблонный подход делает систему по‑настоящему пригодной для масштабирования и повторяемой эксплуатации. В этом смысле KNGFW выглядит современно и вполне уверенно.
Третье — понятный старт с базовыми защитными модулями. Если вы уже работали с мировыми лидерами рынка или российскими NGFW-решениями, серьёзного «культурного шока» здесь не будет. Базовые принципы те же: правила, объекты, профили, инспекция, исключения, события.
К чему нужно было привыкать и где заметна «молодость» продукта
Чтобы картина была честной, добавлю несколько пунктов, которые мы отметили как зону роста продукта. Особенно если сравнивать его с более зрелыми NGFW, где часть этих сценариев уже давно воспринимается как базовая норма.
-
Больше управляемости IDPS‑сигнатур: видимость и тюнинг отдельных детектов, возможность добавлять свои сигнатуры и управлять пулом включённых правил. Для крупных контуров это часто не «хочу», а «надо».
-
Готовые пресеты сервисов для FW‑правил (SSH, SMTP, RDP и т.п.). Один раз собрать несложно, но на старте пилота это лишняя рутина, которую удобно закрывать «из коробки».
-
VPN‑сценарии (Remote Access/Site‑to‑Site). В нашей версии отсутствуют полноценные VPN‑сценарии, а для NGFW такого класса это обычно ожидаемая функция. Будет здорово увидеть это в продукте в ближайшее время.
-
Кластерные сценарии. Мы очень ждём эволюции в сторону более привычной модели с VIP NGFW на data-plane и более «самодостаточной» работой.
При этом важно отметить, что все эти моменты мы воспринимаем не как тупиковые ограничения, а скорее, как понятные зоны развития продукта. Мы держим связь с коллегами со стороны вендора, обсуждаем практические сценарии эксплуатации и видим, что работа по этим направлениям уже идёт. Поэтому здесь скорее не ощущение «чего-то критично не хватает», а ожидание ближайших доработок, которые должны сделать решение заметно более зрелым в повседневной эксплуатации.
В заключение поделюсь одним кейсом, а точнее, заметкой, которая может быть уже не актуальной на момент прочтения статьи.
На одном из этапов мы столкнулись со сбоем синхронизации кластера, и единственным верным способом восстановления оказался сброс устройств до заводского состояния с последующей повторной регистрацией этих устройств в среде KSC. Неприятно, но не фатально. Мы убедились в одной особенности, которую описывали в первой части статьи: основные объекты (FW, NAT, объекты, профили) жили в KSC, поэтому восстановление свелось к пересборке кластера и повторному применению шаблонов, что не заняло много времени и не вызвало серьезного простоя. По информации от коллег, в самом ближайшем обновлении логика кластеризации полностью перерабатывается и такие ситуации больше не будут повторяться.
В итоге KNGFW оставил у нас впечатление решения с уже сформированной базой и понятной архитектурной логикой, которое при этом всё ещё активно развивается. Для нас в этом проекте определяющим оказался не набор отдельных функций сам по себе, а общая эксплуатационная картина: централизованное управление, работа через шаблоны, связка с KSC и KES, понятная модель дальнейшего сопровождения и ощущение, что продукт движется в предсказуемом направлении.
Выбор в пользу KNGFW не был спонтанным, мы остановились на решении, которое показалось нам наиболее подходящим именно для нашей инфраструктуры и управленческой модели. При этом мы не идеализируем продукт и не пытаемся представить его, как «финально завершённый». Скорее наоборот: нам было важно увидеть, что у решения уже есть крепкая основа, а его развитие выглядит последовательным и понятным с инженерной точки зрения.
Именно поэтому текущее внедрение мы воспринимаем не как эксперимент ради эксперимента, а как осознанную ставку на перспективный продукт, который уже сейчас можно использовать в реальных инфраструктурных задачах и который, как нам кажется, будет заметно усиливаться по мере выхода новых релизов.
Если какие-то аспекты этой темы вам интересны глубже, задавайте вопросы в комментариях. А то, что останется за рамками этой статьи, мы постараемся разобрать в следующих публикациях.
ссылка на оригинал статьи https://habr.com/ru/articles/1024128/