Исторический фокус «Лаборатории Касперского» на потребительских антивирусных продуктах завершил трансформацию к 2026 году. Текущий портфель вендора представляет собой многоуровневый B2B/Enterprise стек (XDR, SIEM, SD-WAN, IoT-операционные системы), спроектированный с учетом жестких требований к локализации (Реестр отечественного ПО) и аппаратной совместимости в рамках географического контекста RU. Данный документ анализирует инфраструктурные требования, пропускную способность и архитектурные компромиссы актуальных корпоративных решений вендора.
Триангуляция: Экосистема Касперского в 2026
Что это: Переход от Endpoint к XDR и Unified Monitoring
Экосистема Касперского 2026 года базируется на концепции Extended Detection and Response (XDR), центральным узлом которой выступает SIEM-система KUMA. Модули KATA (Kaspersky Anti Targeted Attack) и KEDR (Endpoint Detection and Response) выступают сенсорами, передающими телеметрию в единое озеро данных. Подобная архитектура обеспечивает централизованный анализ логов, сетевого трафика (NDR) и событий на конечных точках.
Отличия: Микроядерная изоляция на базе KasperskyOS
Фундаментальным отличием инфраструктурного подхода является отказ от монолитных ядер в критических узлах. KasperskyOS использует микроядерную архитектуру (MILS - Multiple Independent Levels of Security). Объем доверенной кодовой базы ядра составляет порядка 100 КБ. Взаимодействие между изолированными доменами безопасности контролируется компонентом KSS (Kaspersky Security System) через строго типизированные IPC-вызовы (Inter-Process Communication).
Польза: Комплаенс КИИ и интеграция в Реестр Минцифры
Развертывание стека KUMA + KATA + KICS обеспечивает техническое закрытие требований приказов ФСТЭК России (№239, №235) для значимых объектов критической информационной инфраструктуры (КИИ) 1-й категории. Решения имеют сертификаты ФСТЭК, нативно интегрируются с сертифицированными отечественными дистрибутивами Linux (Astra Linux 1.8, РЕД ОС). Поддержка шифрования по ГОСТ 34.12-2015/34.13-2015 реализуется программно (что дает overhead на CPU до 15-20%) или аппаратно через интеграцию с внешними HSM-модулями (Hardware Security Module) для снижения нагрузки на высоконагруженных узлах.
Как работает Kaspersky Unified Monitoring and Analysis (KUMA)?
Топология сбора и корреляции: Collector, Correlator, Core
Архитектура KUMA разделена на три функциональных слоя: сбора, обработки и хранения. Коллекторы (Collectors) принимают raw-события по протоколам Syslog, WMI, REST API, парсят их и нормализуют в JSON. Корреляторы (Correlators) обрабатывают нормализованный поток, применяя правила выявления аномалий в оперативной памяти. Ядро (Core) обеспечивает оркестрацию и веб-интерфейс. Кластеризация компонентов по схеме Active-Active обеспечивает отказоустойчивость: при отказе одного коррелятора, трафик перебалансируется с использованием HAProxy без потери EPS (Events Per Second).
СУБД: Производительность ClickHouse и метрики DRP
Для хранения сырых событий и нормализованных логов KUMA использует колоночную СУБД ClickHouse. При нагрузке в 100 000 EPS система генерирует поток записи порядка 1.5–2 ГБ/мин. Для обеспечения latency чтения < 500 мс дисковая подсистема хранения горячих данных (Hot Tier) требует массивов с производительностью не менее 15 000 IOPS (рекомендуются NVMe SSD). Для обеспечения метрик Disaster Recovery Plan (DRP) кластер требует настройки потоковой репликации PostgreSQL (метаданные) и инкрементального резервного копирования партиций ClickHouse на S3-совместимое хранилище. Целевые аппаратные конфигурации позволяют достичь RPO (Recovery Point Objective) < 15 минут и RTO (Recovery Time Objective) < 4 часов при полном отказе узла хранилища.
Аппаратные спецификации (Hardware Specs) для высоконагруженных узлов
Вычислительные ресурсы: Core Count и частота (x86_64/ARM64)
Для обработки 50 000 EPS на одном узле Коррелятора KUMA требуется сервер с двумя процессорами архитектуры x86_64 (минимум 16 физических ядер на CPU с базовой частотой > 2.6 ГГц) и 128 ГБ RAM DDR5. KATA Central Node для обработки 2 Гбит/с сырого зеркалированного трафика требует 32-ядерных систем и 256 ГБ RAM. Заявлена совместимость с аппаратными платформами из реестра Минпромторга (YADRO, Aquarius, ICL), включая поддержку архитектуры ARM64 (для платформы Baikal-S), однако производительность на ARM-решениях в задачах глубокого инспектирования пакетов (DPI) ниже на 30-40% по сравнению с x86_64 аналогами с аналогичным TDP (Thermal Design Power).
Сетевой стек: Требования к интерфейсам (10/40 GbE) и PCIe 5.0
Сенсоры KATA и KICS for Networks требуют прямого захвата пакетов без потерь (zero packet loss). Для обеспечения wire-speed захвата на скорости 10+ Гбит/с используются сетевые адаптеры с поддержкой DPDK (Data Plane Development Kit) или PF_RING. Подключение адаптеров 40GbE/100GbE требует наличия слотов PCIe 5.0 x8/x16 для устранения узких мест на шине (bottlenecks).
Key Features Table: Аппаратные требования enterprise-компонентов (2026 baseline)
|
Компонент |
Роль в системе |
Мин. CPU (Ядра) |
Мин. RAM |
Дисковая подсистема |
Сеть |
|
KUMA Core |
Оркестратор / UI |
8 cores |
32 GB |
500 GB (SSD, >3000 IOPS) |
1 GbE |
|
KUMA Correlator |
Корреляция 20k EPS |
16 cores |
64 GB |
200 GB (SSD, >5000 IOPS) |
10 GbE |
|
KUMA Storage (CH) |
Хранилище (Hot) |
16 cores |
128 GB |
2 TB+ (NVMe, >15000 IOPS) |
10 GbE |
|
KATA Sensor |
Анализ SPAN 1 Gbps |
16 cores |
64 GB |
1 TB (SSD/HDD) |
2x 10 GbE (Capture) |
|
Kaspersky SD-WAN |
CPE Шлюз (Edge) |
4 cores |
8 GB |
64 GB (eMMC/SSD) |
4x 1 GbE |
Требования к сетевым фабрикам: Kaspersky SD-WAN
Пропускная способность и аппаратные Edge-платформы
Построение распределенной архитектуры требует применения Kaspersky SD-WAN. Аппаратные CPE-шлюзы (Customer Premises Equipment) обеспечивают шифрование каналов (IPSec) поверх Underlay-сетей с производительностью от 500 Мбит/с до 10 Гбит/с в зависимости от x86-платформы.
Отказоустойчивость Overlay-сетей
Маршрутизация трафика в Overlay-сети опирается на протокол BGP с применением политик Application-Aware Routing (AAR). При деградации основного канала (рост jitter > 30 мс или packet loss > 1%), оркестратор SD-WAN осуществляет бесшовное переключение сессий на резервный линк без разрыва TCP-соединений.
Как добиться максимального результата при развертывании KATA/KEDR?
Изоляция L2/L3 сегментов и настройка SPAN/Mirroring
Сенсоры KATA должны получать строго релевантный трафик. Настройка SPAN (Switched Port Analyzer) порта на ядре сети должна исключать дублирование пакетов и инкапсулированный (нетерминированный) IPsec/TLS-трафик. Эффективность выявления аномалий возрастает при подаче на сенсор расшифрованного трафика с SSL-инспекторов (через ICAP интеграцию с прокси-серверами).
Тюнинг PostgreSQL для Kaspersky Security Center (KSC)
При управлении инфраструктурой свыше 50 000 хостов через KSC на базе Linux, дефолтные настройки PostgreSQL приводят к деградации производительности. Необходимо корректировать параметры shared_buffers (выделять до 25% RAM сервера), work_mem (увеличивать для сортировки сложных выборок по событиям) и max_connections в postgresql.conf. Использование PgBouncer для пулинга соединений снижает overhead на CPU сервера БД на 15-20%.
В чем заключаются компромиссы (Alternative Perspective)?
TCO против Performance: Оценка стоимости хранения событий (Hot/Cold Storage)
Хранение 100% телеметрии в ClickHouse на NVMe-накопителях в течение 1 года (требование регуляторов) ведет к экспоненциальному росту TCO (Total Cost of Ownership). Компромисс заключается во внедрении Tiering-архитектуры: хранение данных за последние 30 дней на массивах с >15000 IOPS (Hot), и автоматический экспорт старых партиций на S3-совместимые объектные хранилища (Cold Storage на базе HDD 7200 RPM, <500 IOPS). Это увеличивает latency при ретроспективном поиске за прошлые месяцы до нескольких минут, но снижает стоимость хранения терабайта в 4-6 раз.
Аппаратная совместимость: Коммерческий SIEM против Open Source
Лицензирование KUMA строится по комбинированной модели: оплачивается базовое ядро, лимит EPS и количество защищаемых узлов. Переход на закрытую экосистему Касперского (KSC + KEDR + KUMA) обеспечивает нативную интеграцию API "из коробки" и наличие SLA от вендора. Альтернативное использование Open Source SIEM (например, ELK Stack или Wazuh) устраняет затраты на лицензии, но требует существенного фонда оплаты труда (ФОТ) на инхаус-разработку коннекторов и поддержку инфраструктуры. Для средних предприятий внедрение Open Source может быть оправдано, однако для сегмента Large Enterprise (от 10 000 узлов) совокупная стоимость ФОТ выделенной команды платформенных инженеров и риски отсутствия вендорской поддержки часто превышают стоимость коммерческих лицензий KUMA на горизонте трех лет.
Специфика промышленной безопасности: Развертывание KICS
KICS for Networks: Пассивный мониторинг без деградации сети
Для мониторинга сетей АСУ ТП недопустимо использование активного сканирования. KICS for Networks работает в строго пассивном режиме (Promiscuous mode), анализируя зеркалированный трафик индустриальных протоколов (Modbus TCP, IEC 60870-5-104, DNP3). Система не инжектирует пакеты в сеть, гарантируя нулевое влияние на ПЛК (Программируемые логические контроллеры), где задержка более 10 мс может привести к остановке технологического процесса.
KICS for Nodes: Совместимость с SCADA и RTOS
Агент KICS for Nodes спроектирован с учетом жестких ограничений промышленных узлов. Он потребляет не более 100 МБ RAM в фоновом режиме и способен работать на устаревших ОС (вплоть до Windows XP/7) без необходимости перезагрузки хоста при обновлении баз, что критично для систем с требованием непрерывного аптайма.
Советы эксперта (System Integrator Perspective):
"При сайзинге инфраструктуры под KUMA всегда закладывайте 30% запас по IOPS для ClickHouse на случай шторма событий (Event Storm). Использование программных RAID5/6 недопустимо — только аппаратный RAID10 для баз данных. На этапе внедрения KATA в сегментах КИИ, предварительно согласуйте с сетевым отделом схему маршрутизации ERSPAN-трафика, чтобы не перегрузить линки агрегации. Также для SD-WAN всегда планируйте выделенные out-of-band интерфейсы управления."
FAQ
Какой объем RAM и IOPS нужен для базы ClickHouse в KUMA?
Для хранения горячих данных при нагрузке от 20 000 EPS требуется массив из NVMe SSD с производительностью не менее 15 000 IOPS и сервер с объемом оперативной памяти от 128 ГБ. Использование программных RAID-массивов для СУБД не допускается.
Как лицензируется SIEM-система KUMA?
Модель лицензирования комбинированная: приобретается базовая лицензия на ядро системы, к которой добавляются пакеты (бандлы) на лимит событий в секунду (EPS) и лицензии на количество защищаемых активов (узлов) в инфраструктуре.
Поддерживает ли Kaspersky Security Center работу на отечественных ОС?
Да, KSC разворачивается на сертифицированных дистрибутивах Linux (Astra Linux 1.8, РЕД ОС 8.0, ALT Linux 10). Для работы базы данных используется PostgreSQL или Postgres Pro вместо MS SQL, применявшегося в Windows-версиях.
Сайт производителя