Привет! Меня зовут Кирилл, я инженер команды киберзащиты облачного провайдера Nubes. В зоне моей ответственности решения сетевой защиты. В рамках запуска облака КИИ «ТУЧА» мне досталась задача развернуть и настроить NGFW для защищённого контура. В этой статье хочу поделиться практическим опытом первого внедрения Kaspersky NGFW без лишнего маркетинга, а с акцентом на те моменты, которые действительно важны при первом знакомстве с продуктом.
Сразу обозначу рамки материала. Мы сознательно не выносили в эту статью нагрузочные испытания, подробные сравнительные тесты и формальный обзор рынка. Здесь акцент на другом: показать практический путь первого развёртывания Kaspersky NGFW, логику шагов, архитектурные особенности и те моменты, на которые стоит обратить внимание инженеру при первом знакомстве с решением.
В этой части я расскажу именно про архитектуру, развёртывание и подключение компонентов Kaspersky NGFW. А вот вторую часть полностью посвящу базовой конфигурации системы: от настройки объектов, зон и сетевых правил до журналирования, интеграции с SIEM и включения основных функций безопасности, таких как SSL/TLS-инспекция, IDPS, антивирус, DNS Security и веб-контроль.
Ну и чтобы не перегружать текст длинными названиями и не отвлекаться на отдельный блок с терминами, основные пояснения я буду давать по ходу статьи, в тех местах, где они действительно нужны. Сразу зафиксируем следующее сокращение: далее по тексту KNGFW – это Kaspersky NGFW, и именно так будет обозначаться решение в целом.
Почему Kaspersky?
Выбор NGFW под инфраструктурный проект сейчас сама по себе нетривиальная задача: рынок уже сформировался, решений стало больше, но у каждого свой подход к архитектуре, управлению и зрелости отдельных функций. В нашем случае принципиальным условием был сертифицированный многофункциональный межсетевой экран, пригодный для использования в защищённом контуре. Мы посмотрели на доступные варианты, проговорили эксплуатационные сценарии, сделали базовые сравнительные проверки и в итоге остановились на KNGFW.
Причина такого выбора достаточно простая: кредит доверия к вендору, понятная траектория развития продукта и желание одними из первых получить собственную практическую экспертизу по этому решению.
Архитектура решения и место KNGFW среди других NGFW
Прежде чем переходить к пошаговому развёртыванию, имеет смысл зафиксировать общую архитектурную схему. На ней хорошо видно, как между собой взаимодействуют централизованная консоль управления Kaspersky Security Center (далее KSC), backend‑слой оркестрации и шаблонного управления Kaspersky NGFW Backend Environment (далее KNBE), кластер KNGFW и контур мониторинга. Также на схеме видно по каким плоскостям идёт управление, синхронизация и передача журналов.
Как устроен контур управления
В нашем стенде, а затем и в продуктивной архитектуре, получилось три логических слоя.
Первый слой – управление: KSC, а при необходимости и OSMP.
Второй – KNBE, который отвечает за backend‑функции, оркестрацию и шаблонную логику.
Третий – сами аппаратные узлы KNGFW, на которые в итоге попадают политики, сетевые параметры и профили безопасности.
Отдельным слоем в практической эксплуатации идёт мониторинг. В нашем случае значимая часть событий уезжает во внешнюю SIEM, поэтому встроенную визуализацию мы не делали центральным элементом архитектуры.
Единая платформа управления: почему для нас это скорее плюс
Вокруг единой платформы управления для NGFW обычно бывают две крайние позиции.
Первая: чем меньше компонентов, тем лучше.
Вторая: чем богаче экосистема и глубже централизация, тем удобнее эксплуатация.
На практике истина, как обычно, посередине.
Нам в подходе Kaspersky понравилось то, что здесь есть выбор: можно не строить с первого дня максимально тяжёлый управленческий контур, а начать с KSC, если он уже существует в инфраструктуре, и постепенно наращивать функциональность там, где это действительно нужно.
Да, такой путь даёт ограничения. Прежде всего в части встроенной аналитики и дашбордов, если не разворачивать OSMP в полном объёме. Но для нас это не стало проблемой, соответствующие задачи уже закрывались собственной SIEM. Поэтому наличие нескольких режимов зрелости мы восприняли не как недостаток, а как нормальную инженерную гибкость.
Как это выглядит на фоне других NGFW
Если не первый день работаешь с разными NGFW, довольно быстро начинаешь замечать общую логику: почти у всех зрелых решений есть свой централизованный контур управления, а сам по себе такой подход давно стал стандартом. В этом смысле KNGFW не изобретает принципиально новую парадигму, а встраивается в уже понятную модель.
Для нас важнее было другое: KNGFW хорошо ложится в знакомую экосистему. Если в инфраструктуре уже используются другие СЗИ семейства Kaspersky, то появление NGFW в этом же контуре управления выглядит логично и удобно. На практике это означает меньше отдельных консолей, меньше разрозненных точек администрирования и более понятный жизненный цикл изменений.
Если хочется глубже погрузиться в технические детали, отдельно рекомендую сразу посмотреть официальные материалы вендора: документацию по развёртыванию KNGFW, комплект поставки и руководство по CLI.
Развёртывание: путь от контура управления до готового устройства
Если говорить коротко, чтобы полноценно пользоваться KNGFW, нужно последовательно подготовить контур управления, backend-слой и сами аппаратные узлы. Именно это и делаем.
Что подготовить до начала работ:
Сервер под KSC или OSMP (OSMP – Open Single Management Platform, единая платформа управления и аналитики, обеспечивающая дополнительную интеграцию компонентов) с доступом к будущей management-сети.
Хост или кластер под KNBE. Если планируется HA, сразу определите схему размещения узлов, адресацию и VIP KNBE.
Актуальные инсталляционные материалы: дистрибутивы компонентов управления, плагин KNGFW для KSC, сертификаты и сопутствующие файлы для первичного развёртывания.
Подготовленная management-сеть и адресный план для аппаратных узлов KNGFW.
Понимание того, какой VRF будет использоваться для управления и как будет отделена плоскость управления от плоскости пользовательского трафика.
Решение по внешнему журналированию: будете ли вы использовать встроенную аналитику, OSMP или сразу отправите события во внешнюю SIEM.
Шаг 1. Поднимаем KSC / OSMP и ставим плагин KNGFW
Начальный этап – установка KSC либо OSMP на отдельном сервере. Подробно пересказывать установочные инструкции здесь не буду, они уже достаточно хорошо описаны в официальной документации здесь и здесь.
В нашем случае в качестве управляющего компонента мы выбрали KSC. Такой вариант оказался для наиболее практичным с точки зрения развёртывания, дальнейшей эксплуатации и встраивания в уже существующий контур администрирования.
На этом шаге для нас было важно зафиксировать роль управляющего компонента и ту точку, с которой дальше будет строиться весь контур управления KNGFW.
Положительно на старте сказалось и то, что вместе с поставкой были доступны основные материалы для первичного развёртывания: плагин KNGFW, сопутствующие файлы c образами контейнеров KNBE, дистрибутив KUMA, готовый template для интеграции с Zabbix. При этом сертифицированный дистрибутив KSC, который мы использовали для управления всей средой, был оперативно предоставлен через техническую поддержку.
Важно проговорить про плагин KNGFW. Устанавливается он через интерфейс KSC из меню управления параметрами сервера с последующей загрузкой плагина из файла. После его добавления в консоли становятся доступны сущности и элементы управления, связанные с межсетевыми экранами.
Шаг 2. Разворачиваем KNBE
Следующий слой – KNBE. Если говорить максимально простым языком, на момент релиза 1.1 KNBE обеспечивает возможность централизовано управлять сетевой конфигурацией устройств, что заметно облегчает работу с шаблонами.
В тестовом сценарии всё можно собрать на одной машине. Мы же сразу шли в HA‑вариант на Astra Linux. В контейнерном исполнении это оказалось достаточно прямолинейно: контейнеры поднимаются докером, а отказоустойчивость организуется через Corosync/Pacemaker (кластерный менеджмент + плавающий VIP KNBE адрес для точки подключения).
HA – high availability, отказоустойчивое исполнение сервисов или кластера.
VIP KNBE – виртуальный IP‑адрес backend‑кластера KNBE, через который к нему подключаются внешние компоненты управления.
Подробнее изучить этот этап можно в официальном руководстве, там он очень хорошо раскрыт. В нём последовательно описаны все шаги, начиная с подготовки сертификатов и необходимых параметров окружения и заканчивая полным развёртыванием контейнеров и проверкой готовности компонентов.
На выходе этого этапа мы должны получить рабочее контейнерное окружение KNBE и корректно собранный HA-кластер. Иными словами, backend-слой должен быть не просто установлен, а приведён в состояние, при котором все контейнеры подняты, сервисы работают согласованно, а кластер удерживает свои ресурсы и виртуальный адрес.
С точки зрения официальной логики KNBE контейнеры обеспечивают работу backend-компонентов, оркестрацию, внутренние сервисы взаимодействия и хранение необходимых служебных данных. Поэтому итоговая проверка здесь сводится к двум вещам: убедиться, что контейнеры находятся в рабочем состоянии, и проверить, что сам кластер узлов собран корректно.
Что даёт KNBE дальше: профили безопасности как единый «пакет»
На текущем этапе роль KNBE в первую очередь связана с централизованным управлением сетевой конфигурацией устройств и общей backend-логикой решения. При этом важно отдельно уточнить, что в версии 1.1 политики и профили безопасности опираются на механизмы KSC.
По факту это означает, что в текущей конфигурации KSC остаётся основным контуром, через который настраиваются и применяются политики доступа и профили безопасности (этот момент мы еще подсветим в конце статьи), тогда как KNBE обеспечивает централизованную работу с сетевой частью и упрощает управление конфигурацией устройств в целом.
Отдельно стоит отметить, что такая логика не является финальной. В релизе 1.2 планируется перенос механики работы с политиками и профилями безопасности на плоскость KNBE. Поэтому архитектуру решения уже сейчас можно воспринимать как задел на дальнейшее развитие, где backend-слой будет играть более заметную роль и в сетевой оркестрации, и в управлении защитной логикой.
Чтобы KSC начал работать с KNBE, ему нужно указать точку подключения. В HA-варианте это обычно VIP KNBE-кластера.
Шаг 3. Первичная подготовка аппаратного узла KNGFW
Дальше переходим к самим устройствам. Первичное подключение классическое: консольный кабель, скорость 115200 бит/с, базовая настройка интерфейса управления. На моделях KX‑400, KX‑1000 и KX‑3500 для этого используется выделенный интерфейс mgmt, а на KX‑100 эту роль выполняет port1.
По умолчанию на соответствующем интерфейсе уже есть адрес и активирован SSH, поэтому задача обычно сводится к тому, чтобы привести адресацию к своей схеме.
Отдельно подчеркну плоскость управления: KNGFW поддерживает работу с VRF, поэтому мы сознательно использовали этот механизм и разделяли плоскость управления и плоскость основного трафика. Это удобно не только с точки зрения маршрутизации, но и с точки зрения дальнейшей эксплуатации, сопровождения и снижения риска пересечения служебных и пользовательских потоков.
Фактически на этом этапе речь идёт о первичной подготовке устройства к подключению в контур управления, то есть к дальнейшему взаимодействию с KSC и KNBE. Базовая настройка сетевых интерфейсов, адресации и управляющих параметров выполняется через CLI, а сами команды подробно описаны в официальном руководстве по работе с KNGFW из командной строки.
На этом шаге важно зафиксировать два результата:
Мы можем уверено зайти на устройство по SSH через management‑VRF.
Устройство имеет сетевую связность до серверов KSC и KNBE.
Шаг 4. Подключаем KNGFW к KSC
Когда management‑сеть готова, подключаем устройство к KSC. В CLI это выглядит достаточно понятно, если вы уже работали с NGFW:
Указываем адрес сервера KSC
ksc-server address console.<домен> либо IP
Выбираем VRF, через который пойдёт управление
ksc-server vrf Main
Проверяем статус
show ksc-server status
После этого важно принять одно правило: источником истины для конфигурации становится не ручной CLI, а KSC и связанные с ним шаблоны. Локальные изменения через командную строку без фиксации в управленческом контуре долго не живут.
Шаг 5. Подключаем KNGFW к KNBE
Следом подключаем устройство к backend‑оркестратору. На практике мы делали так:
Загружаем сгенерированный на этапе разворачивания кластера KNBE CA‑сертификат на NGFW (scp/WinSCP).
При необходимости кладём его в файл через
viв system shell.Настраиваем knbe-agent.
Настраиваем агента
knbe-agent address ххх.ххх.ххх.ххх protocol https port 8080 interval 5 vrf Management ca-cert /root/ca.pemexit
Применяем и сохраняем конфигурацию
commit
config save
Проверяем
show knbe-agent
После этого устройство начинает получать сетевые шаблоны и политики, которые мы подготовим в контуре управления.
Шаг 6. Настраиваем шаблоны и заводим устройства
Когда базовые связи уже настроены, начинается, пожалуй, самая важная с эксплуатационной точки зрения часть – работа с шаблонами. Выполняется она через плагин управления KNGFW в интерфейсе KSC, и в целом логика здесь достаточно быстро становится понятной: после установки плагина в консоли появляются объекты, политики, шаблоны, профили безопасности и остальные сущности, с которыми дальше и строится работа.
Здесь возможны разные подходы: один шаблон на группу однотипных устройств, базовый шаблон с локальными изменениями или отдельный шаблон на каждое устройство. Мы выбрали третий вариант. Да, он увеличивает число шаблонов, зато даёт больше свободы в работе с адресацией, исключениями, интерфейсами и дальнейшими изменениями.
В целом интерфейс воспринимается достаточно дружелюбно: навигация читается быстро, основные сущности разведены логично, поэтому даже при первом знакомстве с решением не возникает ощущения, что нужно долго разбираться, где именно находится та или иная настройка.
Ниже показан уже подготовленный сетевой шаблон KNGFW.
На практике работа с ним начинается не с «одной галочки», а с последовательного заполнения базовых параметров устройства через плагин управления KNGFW в KSC: сначала задаются интерфейсы и их роли, затем маршрутизация, при необходимости DHCP, NTP и остальные системные параметры, которые должны быть одинаково и предсказуемо применены к конкретному узлу или группе узлов. Такой подход удобен тем, что ещё до постановки устройства на учёт можно собрать для него понятную и воспроизводимую заготовку, от которой потом уже строится вся дальнейшая конфигурация.
Отдельное внимание на этом этапе стоит уделить интерфейсам. Именно здесь определяется, какие порты будут участвовать в передаче пользовательского трафика, какие останутся в management-плоскости, а какие будут использоваться в кластерной логике. Если планируется работа в HA-сценарии, то ещё на уровне шаблона важно корректно выделить и настроить интерфейс синхронизации. Через него узлы будут обмениваться служебным трафиком, keep-alive-пакетами и данными, необходимыми для поддержания active/passive-пары.
Как видно на скриншоте, эта роль задаётся отдельно, и пропускать этот шаг не стоит. Именно он обеспечивает корректное взаимодействие устройств внутри кластера.
Сама логика шаблонов в KNGFW достаточно удобная: сначала собирается базовая сетевая и системная конфигурация, затем она привязывается к конкретному устройству, а уже после этого становится основой для дальнейшей настройки правил, NAT, профилей безопасности и остальных модулей.
После того как базовые шаблоны подготовлены, остаётся связать их с конкретными аппаратными узлами в разделе «устройства».
На пример таким образом выглядит уже зарегистрированное устройство. Внутри можно будет увидеть все тоже самое что и в шаблоне. Но важно учитывать следующий момент: изменения, внесённые на уровне конфигурации «устройства» в UI KSC (не шаблона), имеют более высокий приоритет, но и более высокий риск при восстановлении, если устройство придётся возвращать в заводское состояние.
Для этого устройство нужно добавить в контур управления и однозначно идентифицировать, чтобы система понимала, к какому именно KNGFW применять подготовленную конфигурацию.
В Kaspersky NGFW эта привязка выполняется с помощью уникального идентификатора устройства DPID. Именно по нему платформа «узнаёт» нужный узел и позволяет корректно поставить его на учёт.
Его можно посмотреть через CLI на управленческом интерфейсе, после чего устройство связывается с нужным шаблоном.
show interfaces name port1
либо
show interfaces name mgmt..
Меню добавления устройства не сильно отличается от добавления шаблона:
Шаг 7. Собираем кластер KNGFW
Последний значимый шаг на этапе развёртывания – сборка кластера KNGFW. На практике это довольно простая и логичная процедура: выбираем узлы, задаём параметры keep‑alive, определяем интерфейсы для синхронизации и получаем active/passive‑пару.
Дополнительно стоит включить мониторинг интерфейсов, задействованных в кластерном взаимодействии. Поскольку через них проходит служебный обмен между узлами, их состояние критично для работы HA-механизма. Наблюдение за такими интерфейсами позволяет быстрее выявлять проблемы со связностью и заранее понимать, не влияет ли состояние канала на синхронизацию и устойчивость кластера.
Таким образом будет выглядеть успешно собранный кластер.
Здесь сразу отметим одну деталь: в той версии решения, с которой работали мы, «классического» VIP NGFW для пользовательского трафика в кластере не хватало.
VIP NGFW – виртуальный IP‑адрес или кластерный адрес, относящийся уже к самим межсетевым экранам и их data‑plane/сервисной логике.
Модель оказалась ближе к active/passive без отдельного виртуального адреса на data‑plane, и это требует чуть другого подхода на аплинках (например, решать отказоустойчивость на уровне upstream).
Непривычно? Да! Фатально? Нет! Просто важно учитывать это на этапе дизайна. По информации от коллег, развитие кластерных сценариев – один из ожидаемых пунктов ближайших обновлений, и мы сами этот момент очень ждём.
В active/passive‑режиме пассивная нода действительно живёт «в тени»: часть операций недоступна, потому что она не обслуживает трафик. Это важно помнить при изменениях:
основные изменения вносятся на активной ноде;
при правке интерфейсов активной ноды UI предлагает сразу указать параметры для пассивной.
Если же нужно сделать что‑то, что упирается в ограничения пассивного режима, иногда проще кратковременно «разобрать» кластер через CLI, выполнить операцию и собрать обратно. Это не то, что хочется делать регулярно, но как аварийный инструмент полезно.
Итоги развертывания: что оказалось очевидным, а что нет
Предлагаю завершить первую часть статьи на этом. В ней мы прошли путь от подготовки стенда до развёртывания и подключения основных компонентов Kaspersky NGFW.
Из очевидного: первичная сетевая настройка, регистрация в KSC и базовая логика шаблонов. Любому инженеру, который уже работал с другими NGFW, этот этап будет понятен. Менее очевидной частью оказался именно KNBE: пока не разворачиваешь его руками, не до конца понимаешь, насколько он важен для нормальной жизни с системой. Это, пожалуй, главное отличие от более монолитных подходов, где backend‑логика сильнее скрыта от администратора.
Во второй же части мы перейдём к базовой конфигурации решения: разберём настройку объектов и зон, правила Firewall и NAT, журналирование, интеграцию с SIEM, а также последовательно посмотрим на ключевые механизмы защиты — SSL/TLS-инспекцию, IDPS, антивирус, DNS Security и веб-контроль.
Продолжение выйдет уже в ближайшее время.
