Kaspersky Unified Monitoring and Analysis Platform

О программе Kaspersky Unified Monitoring and Analysis Platform

Kaspersky Unified Monitoring and Analysis Platform (далее KUMA или "программа") – это комплексное программное решение, сочетающее в себе следующие функциональные возможности:

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

Программа построена на микросервисной архитектуре. Это означает, что вы можете создавать и настраивать только необходимые микросервисы (далее также "сервисы"), что позволяет использовать KUMA и как систему управления журналами, и как полноценную SIEM-систему. Кроме того, благодаря гибкой маршрутизации потоков данных вы можете использовать сторонние сервисы для дополнительной обработки событий.

Функциональность обновлений (включая обновления антивирусных сигнатур и обновления кодовой базы) может быть недоступна в программе на территории США.

В этом разделе справки

Что нового

Комплект поставки

Аппаратные и программные требования

Интерфейс KUMA

Совместимость с другими программами

В начало
[Topic 217694]

Что нового

Kaspersky Unified Monitoring and Analysis Platform появились следующие возможности и доработки:

  • Исправления и доработки в KUMA 3.4.2:
    • Решена проблема слишком долгой процедуры обслуживания базы данных SQLite.
    • Оптимизировано хранение истории версий ресурсов, что позволяет избежать увеличения размера базы данных.
  • Новые возможности в KUMA 3.4.2:
  • Добавлена поддержка работы KUMA на следующих операционных системах:
    • Astra Linux 1.7.6.
  • В KUMA 3.4.1 в правилах обогащения событий типа DNS доступен параметр Требуется рекурсия. С помощью переключателя Требуется рекурсия можно включить отправку коллектором KUMA рекурсивных запросов к авторитативным DNS-серверам для выполнения обогащения. Значение по умолчанию: Выключено.
  • В KUMA 3.4.1 доступно получение и обработка инцидентов от НКЦКИ. После обновления до версии 3.4.1 Ядро KUMA при каждом запуске отправляет запрос о наличии новых карточек инцидентов по адресу, указанному в поле URL в настройках интеграции KUMA с НКЦКИ, и затем продолжает отправлять запросы каждые 10 минут. Если в личном кабинете пользователя НКЦКИ появился новый инцидент, KUMA регистрирует инцидент с префиксом ALRT* и дальнейшее взаимодействие с НКЦКИ ведется уже в рамках созданного инцидента.

    Взаимодействие с НКЦКИ доступно, даже если в KUMA инцидент переведен в статус Закрыт: вы можете менять значения в поле Статус НКЦКИ и вести чат с НКЦКИ.

  • В KUMA 3.4.1 расширен список доступных предустановленных панелей мониторинга.
  • Начиная с версии KUMA 3.4.1 и Kaspersky Endpoint Security 12.9 добавлена поддержка EDR-действий при реагировании на угрозы.
  • Добавлена возможность визуализировать на интерактивном графе зависимости ресурсов между собой и другими объектами. Теперь при редактировании ресурсов вы можете выяснить, к каким связанным ресурсам применится изменение. Вы можете отображать на графе те или иные типы ресурсов и сохранять построенный граф в формате SVG.
  • Появилась возможность добавлять теги для ресурсов, что позволяет осуществлять удобный поиск ресурсов, объединенных одним тегом.
  • Роль Доступ к общим ресурсам упразднена, и вместо нее добавлены следующие роли пользователей:
    • Чтение общих ресурсов.
    • Редактирование общих ресурсов. Редактировать ресурсы в Общем тенанте теперь может Главный администратор и пользователь с ролью Редактирование общих ресурсов.
  • Добавлено версионирование ресурсов (за исключением словарей и таблиц), обеспечивающее хранение истории их изменений.

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

    После обновления KUMA до версии 3.4 для существующих ресурсов версии появятся только после сохранения изменений.

  • Добавлена возможность искать ресурсы по их содержимому с помощью полнотекстового поиска. Вы можете найти ресурсы, хотя бы в одном поле которого встречается конкретное слово, например, если вам нужно найти правила, в которых есть условие с определенным словом.
  • Доступен новый тип ресурсов KUMA – Правила сбора и анализа данных, который позволяет планировать выполнение SQL-запросов в хранилище по заданному расписанию и осуществлять корреляцию по полученным данным.
  • Появилась возможность передавать значения уникальных полей в поля корреляционных событий при создании правил корреляции с типом standard.
  • Добавлены новые наборы SQL-функций enrich и lookup, которые позволяют использовать атрибуты активов и учетных записей, данные из словарей и таблиц, в поисковых запросах для фильтрации событий, формирования отчетов и виджетов (тип графика: таблица). Вы можете использовать наборы функций enrich и lookup в SQL-запросе в правилах сбора и анализа данных.
  • Реализовано сохранение истории поисковых запросов. Теперь вы можете обращаться к истории запросов и быстро находить нужный выполненный вами запрос.
  • Добавлена возможность организовать сохраненные запросов в дереве папок для структурированного хранения и быстрого поиска запросов. Теперь вы можете редактировать ранее сохраненные запросы, переименовывать их, иерархически размещать запросы в группах (папках) и осуществлять поиск по ранее сохраненным запросам в поисковой строке. Также вы можете редактировать запросы и создавать ссылки на часто используемые запросы, добавляя их в «Избранное».
  • Добавлена возможность создавать временный список исключений (например, создавать исключения для ложноположительных срабатываний при работе с алертами или инцидентами). Вы можете сформировать список исключений по каждому корреляционному правилу.
  • При создании коллектора на шаге Парсинг событий добавлена возможность передавать в поле события KUMA название обрабатываемого коллектором файла или пути к файлу.
  • В коннектор с типом file добавлены следующие параметры:
    • Поле Время ожидания изменений, сек. Это поле позволяет указать время в секундах, в течение которого файл не должен обновляться, чтобы KUMA выполнила с ним действие, указанное в раскрывающемся списке Действие после таймаута: удалить, добавить суффикс, оставить без изменений.
    • Раскрывающийся список Действие после таймаута. Этот раскрывающийся список позволяет указать действие, которое KUMA выполняет с файлом по прошествии времени, указанного в поле Время ожидания изменений, сек.
  • В коннекторы с типом file, 1с-xml и 1c-log добавлены следующие параметры:
    • Раскрывающийся список Режим опроса файл/папки. Этот раскрывающийся список позволяет указать режим, в котором коннектор перечитывает файлы в директории.
    • Поле Интервал запросов, мс. Это поле позволяет указать интервал в миллисекундах, с которым коннектор перечитывает файлы в директории.
  • Изменен подход к определению срока хранения событий при использовании холодного хранения в связи с добавлением возможности задать условия хранения событий в кластере ClickHouse в размере дискового пространства (точного в ГБ и в процентах) при создании хранилища или пространства. Добавлен параметр Время хранения событий, в котором теперь определяется общая длительность хранения событий в KUMA с момента поступления. Этот параметр заменил параметр Срок холодного хранения событий.

    При обновлении KUMA до версии 3.4, если ранее у вас были настроены диски холодного хранения, значение параметра Время хранения событий будет рассчитано как сумма ранее указанных значений в параметрах Срок хранения событий и Срок холодного хранения событий.

  • Добавлена возможность гибкой настройки условий хранения событий в кластере ClickHouse с помощью параметра Варианты хранения событий для более устойчивой работы хранилища: по сроку хранения, размеру хранилища в ГБ или доли размера хранилища от общего доступного ему объема диска. При срабатывании заданного условия события перемещаются на диск холодного хранения или удаляются.

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

  • Появилась возможность обеспечить гранулярный доступ к событиям для пользователей с разными правами. Доступ к событиям регулируется на уровне пространства хранилища. После обновления KUMA до версии 3.4 всем существующим пользователям будет назначен набор пространств All spaces, то есть будут доступны все пространства без ограничений. Вы можете разграничить доступ: необходимо настроить наборы пространств и отрегулировать права доступа. Также после обновления во всех виджетах, где были выбраны хранилища, будут выбраны все доступные пространства хранилища. Если создано новое пространство, пространство не будет выбрано автоматически в параметрах настройки виджета. Новое пространство следует выбрать в параметрах настройки виджете вручную.
  • Добавлена возможность управлять полями расширенной схемы событий в разделе ПараметрыПоля расширенной схемы событий. Вы можете просматривать существующие поля расширенной схемы событий и ресурсы, в которых они используются, изменять поля, создавать новые поля вручную и импортировать из файла, а также экспортировать поля и информацию о них.

    При обновлении KUMA до версии 3.4 ранее созданные поля расширенной схемы событий будут автоматически перенесены и отобразятся в разделе ПараметрыПоля расширенной схемы событий со следующими особенностями:

    • Если у вас было несколько полей одного типа с одинаковым именем, в KUMA 3.4 будет перенесено только одно поле.
    • Все поля с префиксом KL в названии будут перенесены в KUMA 3.4 со статусом Включено. Если какие-либо из этих полей станут служебными, вы не сможете их удалить, изменить, отключить или экспортировать.
    • Поля расширенной схемы событий, которые не соответствуют требованиям к полям в версии 3.4, будут перенесены в KUMA 3.4 со статусом Выключено.

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

  • Добавлена возможность фильтровать и отображать данные за относительный временной диапазон.

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

    Для фильтрации данных время приводится в UTC, и затем в интерфейсе KUMA конвертируется в соответствии с локальным часовым поясом, установленным в браузере.

  • Добавлена поддержка автодополнения при наборе функций переменных в корреляторах и правилах корреляции.

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

  • Добавлена возможность применить несколько политик мониторинга к нескольким источникам событий или отключить политики мониторинга от нескольких источников сразу.
  • Для политик мониторинга добавлен параметр Расписание, который позволяет настроить регулярность применения политик мониторинга к источникам событий.
  • Добавлена возможность управлять создаваемыми для агента подключениями для более удобной работы с ними. Вы можете переименовывать подключения, чтобы в дальнейшем определить, от какого подключения и с какого агента пришло событие, дублировать подключения, чтобы создавать новые подключения на основе существующих, и удалять подключения. Также восстановлен функционал, позволяющий использовать один агент для чтения нескольких файлов.
  • В агентах KUMA появилась возможность отслеживать маршрут события, если в подключении агента указана хотя бы одна точка назначения типа internal и если в коллекторе, принимающем события от агента, настроен коннектор типа internal. После настройки агента информация о маршруте события появится в карточке события, в карточке алерта и карточке корреляционного события в разделе Журнал отслеживания событий. Для событий с отслеживанием маршрута в разделе Журнал отслеживания событий информация о сервисах, через которые проходит событие, отображается в преобразованном виде. Имена сервисов представлены в виде ссылки. Вы можете нажать на ссылку с именем сервиса, чтобы открыть новую вкладку браузера с карточкой сервиса. Если вы измените название сервиса, новое название сервиса отобразится в карточках новых событий и в карточках уже обработанных событий. Если вы удалите сервис в разделе Активные сервисы, в карточках событий в разделе Журнал отслеживания событий вместо ссылки будет отображаться Удален. Остальные данные о маршруте события не будут удалены и по-прежнему будут отображаться.
  • Конвертор правил Sigma выполняет преобразование правил в селектор фильтра, SQL-запрос для поиска событий или в корреляционное правило KUMA типа simple. Доступен с лицензией LGPL 2.1.
  • Появилась возможность установить сервис AI рейтинг и статус активов при условии, что лицензия содержит модуль AI.

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

  • В регионе RU при условии наличия лицензионного модуля AI доступна возможность проанализировать с помощью Kaspersky Investigation & Response Assistant (далее - KIRA) команду, на которую сработало корреляционное правило. Такой анализ помогает расследовать алерты и инциденты, предлагая понятное описание параметров команды.

    Вы можете отправить запрос в KIRA из карточки события или карточки корреляционного события. KIRA выполнит деобфускацию, если команда обфусцирована, и покажет результат: вывод, краткое содержание и развернутый анализ. Результаты запроса хранятся в кэше в течение 14 дней и доступны для повторного просмотра в карточке события на вкладке Анализ KIRA всем пользователям с правами доступа. Также есть возможность просмотреть результат в свойствах задачи Запрос в KIRA или перезапустить задачу и выполнить анализ с нуля.

  • Добавлена возможность категоризации активов по относительному временному диапазону.

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

    Для категоризации время приводится в UTC, и затем в интерфейсе KUMA конвертируется в соответствии с локальным часовым поясом, установленным в браузере.

  • Добавлены новые типы настраиваемых шаблонов уведомлений.

    В предыдущих версиях шаблоны уведомлений были доступны только для уведомления о создании алертов. Теперь вы также можете создавать шаблоны уведомлений следующих типов:

    • Завершение генерации отчета.
    • Завершение асинхронной задачи (шаблон с таким типом может быть только один).
    • Нарушение политики мониторинга.
    • Перемещение пользователя в другую группу KASAP.

    Все типы шаблонов доступны при создании шаблона для Общего тенанта. Для всех остальных тенантов доступны типы шаблонов уведомлений Созданный алерт и Нарушение политики мониторинга.

  • Добавлен новый тип графиков – Сложенная столбчатая диаграмма.

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

  • Добавлена возможность множественного выбора активов с помощью фильтра и удаления всех выбранных активов. Теперь вы также можете выделить все активы в категории, привязать их к категории или отвязать активы от категории.
  • Добавлена возможность множественного выбора ресурсов и их удаления. Вы можете удалять все ресурсы или отдельные типы ресурсов.
  • В группе виджетов Активы добавлены предустановленные виджеты, а также новый тип Пользовательский виджет, позволяющий производить пользовательскую аналитику по активам.
  • Улучшен экспорт виджетов в PDF: теперь, если отображаемые данные в виджете выходят за пределы видимой области, такой виджет при эскпорте в PDF разбивается на несколько виджетов, а вертикальные столбчатые диаграммы преобразуются в горизонтальные.
  • Добавлен унифицированный нормализатор для различных версий NetFlow (NetFlow v5, NetFlow v9, IPFIX/NetFlow v10): вместо трех отдельных нормализаторов вы можете использовать один. Нормализаторы NetFlow v5, NetFlow v9 и IPFIX (NetFlow v10) при этом по-прежнему доступны.

    Помимо этого, теперь последний шаблон NetFlow сохраняется на диске для каждого источника событий, что позволяет при перезапуске коллектора сразу парсить поток netflow от уже известного источника событий.

  • Добавлена возможность автоматически принимать Лицензионное соглашение во время установки агента KUMA на устройствах Linux и устройствах Windows с использованием параметра --accept-eula. Также у агента Windows появилась возможность задать пароль к учетной записи, под которой будет работать агент, как параметр командной строки.
  • В разделе РесурсыАктивные сервисы в таблице сервисов добавлен новый столбец параметра UUID, в котором отображается уникальный идентификатор сервиса.

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

  • KUMA поддерживает оператор UNION для подключений к СУБД Oracle в качестве источника событий.
  • Для оптимизации управления активами процесс импорта информации об активах из Kaspersky Security Center был разделен на две задачи:
    • Импорт информации об основных параметрах активов (состоянии защиты, версии антивирусных баз, оборудовании), который занимает меньше времени и предполагает более частый запуск.
    • Импорт информации об остальных параметрах активов (уязвимостях, программном обеспечении, владельцах), во время которого может загружаться большое количество информации и на выполнение которого требуется более длительное время.

    Каждая из задач импорта может запускаться независимо от другой и для каждой доступна отдельная настройка расписания автоматического запуска при настройке параметров интеграции с Kaspersky Security Center.

  • Добавлена возможность отобразить отдельные графики поступления событий для нескольких источников событий одновременно, а также построить диаграмму поступления событий на основе графиков для нескольких источников событий, чтобы сравнить поток и динамику поступления событий для нескольких источников событий.
  • В условия активной категоризации и поиска активов добавлены новые параметры фильтрации: Версия ПО, Группа KSC, CVSS (уровень критичности уязвимости CVE на активе), Количество CVE (количество уникальных уязвимостей с признаком CVE на активе), а также фильтрация по настраиваемым полям активов.
  • Появилась возможность получать обновления ресурсов через прокси-сервер.
  • Добавлена возможность включить генерацию отчетов по потреблению ресурсов (CPU, RAM и т.д.) в виде дампов по запросу техподдержки.
  • Для ресурсов в таблице отображается количество ресурсов из доступных вам тенантов в таблице: общее или с учетом примененного фильтра или поиска, а также количество выбранных ресурсов.
  • Новый коннектор office365 позволяет настроить получение событий из облачного решения Microsoft 365 (Office 365) по API.
  • Прекращена поддержка и поставка устаревших ресурсов:
    • [OOTB] Linux audit and iptables syslog
    • [OOTB] Linux audit.log file
    • [OOTB] Checkpoint Syslog CEF by CheckPoint
    • [OOTB] Eltex MES Switches
    • [OOTB] PTsecurity NAD
    • [OOTB][AD] Granted TGS without TGT (Golden Ticket)
    • [OOTB][AD] Possible Kerberoasting attack
    • [OOTB][AD][Technical] 4768. TGT Requested
    • [OOTB][AD] List of requested TGT. EventID 4768
В начало
[Topic 220925]

Комплект поставки

В комплект поставки входят следующие файлы:

  • kuma-ansible-installer-<номер сборки>.tar.gz – используется для установки компонентов KUMA без возможности развертывания в отказоустойчивой конфигурации;
  • kuma-ansible-installer-ha-<номер сборки>.tar.gz – используется для установки компонентов KUMA с возможностью развертывания в отказоустойчивой конфигурации;
  • файлы с информацией о версии (примечания к выпуску) на русском и английском языках.
В начало
[Topic 217846]

Аппаратные и программные требования

Рекомендуемые требования к оборудованию

В этом разделе приведены требования к оборудованию для обработки различных вариантов потока событий в секунду (Events per Second, далее EPS), поступающих в KUMA.

В таблице ниже приведены аппаратные и программные требования к оборудованию для установки компонентов KUMA, исходя из представления, что кластер ClickHouse принимает только запросы INSERT. Требования к оборудованию для удовлетворения потребностей по запросам SELECT рассчитывается отдельно под конкретный профиль использования СУБД заказчика.

Рекомендуемые требования к оборудованию для хранилищ кластера ClickHouse

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

  • Дисковая подсистема
  • Сетевой интерфейс
  • Оперативная память
  • Профиль использования

Дисковая подсистема

Основная нагрузка на ClickHouse в KUMA - это вставки (запись):

  • События поступают в СУБД практически постоянным потоком.
  • Вставки, по меркам ClickHouse, частые и мелкие.
  • ClickHouse отличается высоким показателем write amplification за счет постоянных фоновых слияних кусков партиций (parts).
  • Часть партиции размером до 1 ГБ хранится в виде единственного файла. При превышении размера в 1 ГБ для части применяется wide column format, где каждая колонка таблицы представлена в виде двух файлов .dat и .mrk. В этом случае, для перезаписи части в результате ее слияния с другой частью, требуется запись в 384 файла + fsync на каждый - это большое количество IOPS.

Разумеется, ClickHouse одновременно выполняет и поисковые запросы, но их значительно меньше, чем операций записи. С учетом характера нагрузки, мы рекомендуем следующий подход к организации дисковой подсистемы:

  1. Использовать DAS (Direct Attached Storage) c NVME или SAS/SATA-интерфейсами, избегая решений класса SAN/NAS.
  2. Если узлы кластера ClickHouse развернуты в виртуальной среде, директория /opt/kaspersky/kuma должна быть напрямую смонтирована на дисковый массив. Не следует использовать виртуальные диски.
  3. Если есть возможность использовать SSD (SATA/NVME) - это предпочтительный вариант. Любые SSD серверного класса обеспечат большую производительность, чем HDD (даже 15к RPM). Для SSD следует использовать RAID-10 или RAID-0, RAID-0 - при условии использования репликации в ClickHouse.
  4. Если использование SSD невозможно, следует применять HDD 15к RPM, SAS, объединенные в RAID-10.
  5. Допускается гибридный вариант - горячие данные (например, за последний месяц) хранятся на SSD, а холодные данные - на HDD. Таким образом операции записи всегда будут адресованы SSD-массивам.
  6. Программный RAID массив (madm) всегда будет демонстрировать более высокую производительность и гибкость, чем аппаратный RAID-контроллер. При использовании RAID-0 или RAID-10 важно, чтобы stripe size был равен 1 МБ. Часто в аппаратных RAID-контроллерах stripe size по умолчанию выставлен в 64 КБ, а максимально доступное значение - 256-512 КБ. Для RAID-10 near-layout более оптимален для записи, а far-layout - для чтения. Это следует учитывать в случае использования гибридного варианта SSD + HDD.
  7. Рекомендуемые файловые системы - EXT4 или XFS, желательно с опцией монтирования noatime.

Сетевой интерфейс

  1. На каждом узле кластера должен быть установлен и соответствующим образом скоммутирован сетевой интерфейс с пропускной способностью не менее 10 Гбит/с. С учетом write amplification и репликации идеальным решением будет 25 Гбит/с.
  2. При необходимости процессы репликации могут использовать обособленный сетевой интерфейс, который не обрабатывает трафик, связанный со вставками и поисковыми запросами.

Оперативная память

ClickHouse рекомендует придерживаться отношения RAM к объему хранимых данных равному 1:100.
Но сколько оперативной памяти потребуется, если на каждом узле предполагается хранить 50 ТБ, ведь зачастую глубина хранения событий определяется требованиями регулятора, и поисковые запросы не выполняются на всю глубину хранения? Поэтому рекомендацию можно трактовать следующим образом: если средняя глубина запроса предполагает сканирование партиций суммарным объемом в 10 ТБ, то потребуется 100 ГБ RAM. Это общая рекомендация, рассчитанная на широкие аналитические запросы.
В общем случае, наличие свободной памяти на сервере положительно влияет на производительность поисковых запросов по наиболее свежим событиям, так как содержимое файлов партиций будет продублировано в Page Cache OS, соответственно, считываться содержимое файлов будет из RAM, а не с диска.

Профиль использования

Требования к оборудованию рассчитаны на поглощение СУБД потока в N EPS при нахождении СУБД в покое (поисковые запросы не выполняются, только вставки). На этапе внедрения KUMA не всегда представляется возможность точно ответить на следующие вопросы:

  1. Какие поисковые и аналитические запросы будут выполняться в системе?
  2. Какова интенсивность, конкурентность и глубина поисковых запросов?
  3. Какова фактическая производительность узлов кластера?

Таким образом эволюция кластера ClickHouse в процессе эксплуатации KUMA является вполне нормальной практикой. Если в результате увеличения потока EPS или увеличения интенсивности/ресурсоемкости поисковых запросов кластер перестает справляться с нагрузкой, следует либо добавить больше шардов (горизонтальное масштабирование), либо усовершенствовать дисковые подсистемы / СPU / RAM на узлах кластера.

Конфигурацию оборудования необходимо подбирать исходя из профиля нагрузки системы. Допустимо использовать конфигурацию типа «All-in-one» при обрабатываемом потоке событий до 10 000 EPS и при использовании графических панелей, поставляемых с системой.

KUMA поддерживает работу с процессорами Intel или AMD с поддержкой набора инструкций SSE 4.2 и набора инструкций AVX.

 

До 3000 EPS

До 10 000 EPS

До 20 000 EPS

До 50 000 EPS

Конфигурация

Установка на одном сервере

 

Одно устройство. Характеристики устройства:

От 16 потоков или vCPU.

От 32 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – SSD*.

Скорость передачи данных – от 100 Мбит/с.

 

Установка на одном сервере

 

Одно устройство. Характеристики устройства:

От 24 потоков или vCPU.

От 64 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – SSD*.

Скорость передачи данных - от 100 Мбит/с.

 

1 сервер для Ядра +

1 сервер для Коллектора +

1 сервер для Коррелятора +

3 выделенных сервера с ролью Кипера +

2 сервера для Хранилища*

*Рекомендуемая конфигурация. 2 сервера для Хранилища используются при конфигурации ClickHouse с 2 репликами в каждом шарде для обеспечения отказоустойчивости и доступности собранных в хранилище событий. Если требования отказоустойчивости к хранилищу не применяются, допустимо использовать конфигурацию ClickHouse с 1 репликой в каждом шарде и использовать, соответственно, 1 сервер для Хранилища.

1 сервер для Ядра +

2 сервера для Коллектора +

1 сервер для Коррелятора +

3 выделенных сервера с ролью Кипера +

4 сервера для Хранилища*

*Рекомендуемая конфигурация. 4 сервера для Хранилища используются при конфигурации ClickHouse с 2 репликами в каждом шарде для обеспечения отказоустойчивости и доступности собранных в хранилище событий. Если требования отказоустойчивости к хранилищу не применяются, допустимо использовать конфигурацию ClickHouse с 1 репликой в каждом шарде и использовать, соответственно, 2 сервера для Хранилища.

Требования для компонента Ядро

-

-

Одно устройство.

Характеристики устройства:

От 10 потоков или vCPU.

От 24 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – SSD.

Скорость передачи данных - от 100 Мбит/с.

 

Одно устройство.

Характеристики устройства:

От 10 потоков или vCPU.

От 24 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – SSD.

Скорость передачи данных - от 100 Мбит/с.

 

Требования для компонента Коллектор

-

-

Одно устройство.

Характеристики устройства:

От 8 потоков или vCPU.

От 16 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – допустим HDD.

Скорость передачи данных - от 100 Мбит/с.

 

Два устройства.

Характеристики каждого устройства:

От 8 потоков или vCPU.

От 16 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – допустим HDD.

Скорость передачи данных - от 100 Мбит/с.

 

Требования для компонента Коррелятор

-

-

Одно устройство.

Характеристики устройства:

От 8 потоков или vCPU.

От 32 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – допустим HDD.

Скорость передачи данных - от 100 Мбит/с.

 

Одно устройство.

Характеристики устройства:

От 8 потоков или vCPU.

От 32 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – допустим HDD.

Скорость передачи данных - от 100 Мбит/с.

 

Требования для компонента Кипер

-

-

Три устройства.

Характеристики каждого устройства:

От 6 потоков или vCPU.

От 12 ГБ оперативной памяти.

От 50 ГБ в каталоге /opt.

Тип хранилища данных – SSD.

Скорость передачи данных - от 100 Мбит/с.

 

Три устройства.

Характеристики каждого устройства:

От 6 потоков или vCPU.

От 12 ГБ оперативной памяти.

От 50 ГБ в каталоге /opt.

Тип хранилища данных – SSD.

Скорость передачи данных - от 100 Мбит/с.

 

Требования к компоненту Хранилище

-

-

Два устройства.

Характеристики каждого устройства:

От 24 потоков или vCPU.

От 64 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – SSD*.

Рекомендуемая скорость передачи данных между узлами ClickHouse должна быть не менее 10 Гбит/с, если поток событий равен или превышает 20 000 EPS.

 

Четыре устройства.

Характеристики каждого устройства:

От 24 потоков или vCPU.

От 64 ГБ оперативной памяти.

От 500 ГБ в каталоге /opt.

Тип хранилища данных – SSD*.

Рекомендуемая скорость передачи данных между узлами ClickHouse должна быть не менее 10 Гбит/с, если поток событий равен или превышает 20 000 EPS.

 

Операционные системы

  • Ubuntu 22.04 LTS.
  • Oracle Linux 8.6, 8.7, 8.10, 9.2, 9.3, 9.4.
  • Astra Linux Special Edition РУСБ.10015-01 (2021-1126SE17 оперативное обновление 1.7.1).
  • Astra Linux Special Edition РУСБ. 10015-01 (2022-1011SE17MD оперативное обновление 1.7.2.UU.1).
  • Astra Linux Special Edition РУСБ.10015-01 (2022-1110SE17 оперативное обновление 1.7.3). Требуется версия ядра 5.15.0.33 или выше.
  • Astra Linux Special Edition РУСБ.10015-01 (2023-0630SE17MD срочное оперативное обновление 1.7.4.UU.1).
  • Astra Linux Special Edition РУСБ.10015-01 (2024-0212SE17MD срочное оперативное обновление 1.7.5.UU.1).
  • Astra Linux Special Edition РУСБ.10015-01 (2024-0830SE17 срочное оперативное обновление 1.7.6).
  • РЕД ОС 7.3.4, 8.

Криптонаборы TLS

Поддерживается протокол TLS версии 1.2 и 1.3. Интеграция с сервером, не поддерживающим версии и криптонаборы TLS, которые требует KUMA, невозможна.

Поддерживаемые криптонаборы TLS 1.2:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.

Поддерживаемые криптонаборы TLS 1.3:

  • TLS_AES_128_GCM_SHA256.
  • TLS_AES_256_GCM_SHA384.
  • TLS_CHACHA20_POLY1305_SHA256.

В зависимости от количества и сложности запросов к БД, выполняемых пользователями, отчетами, панелями мониторинга объем необходимых ресурсов может быть увеличен.

На каждые 50 000 (сверх 50 000) активов необходимо добавить к ресурсам компонента Ядро 2 дополнительных потока или vCPU и 4 ГБ оперативной памяти.

На каждые 100 (сверх 100) сервисов, которыми управляет компонент Ядро необходимо добавить к ресурсам компонента Ядро 2 дополнительных потока или vCPU.

Необходимо размещать ClickHouse на твердотельных накопителях (англ. solid state drive, далее - SSD). Использование SSD позволяет повысить скорость доступа к данным.

* - если профиль использования системы не предполагает выполнения агрегационных SQL-запросов к Хранилищу с глубиной более 24 часов, допускается использовать дисковые массивы на базе HDD (HDD 15 000 RPM, интерфейс SAS, объединенные в RAID-10).

Для размещения данных с использованием технологии HDFS могут быть использованы жесткие диски.

Экспорт событий записывается на диск компонента Ядро во временную папку /opt/kaspersky/kuma/core/tmp/. Экспортированные данные хранятся в течение 10 суток, затем автоматически удаляются. Если вы планируете экспортировать большой объем событий, необходимо выделить дополнительное место.

Работа в виртуальных средах

Поддерживается установка KUMA в следующих виртуальных средах:

  • VMware 6.5 и выше.
  • Hyper-V для Windows Server 2012 R2 и выше.
  • QEMU-KVM 4.2 и выше.
  • ПК СВ "Брест" РДЦП.10001-02.

Работа в облачных средах

Поддерживается работа в облачной инфраструктуре. Система может быть установлена на виртуальные машины по модели IaaS (инфраструктура как сервис).

Для работы в облачной инфраструктуре мы рекомендуем использовать конфигурации "Установка на одном сервере" для 3 000 EPS и 10 000 EPS. Виртуальные машины должны удовлетворять аппаратным и программным требованиям, предъявляемым к обычной установке.

При выборе дисковой подсистемы сервера, следует ориентироваться на параметр "количество операций ввода/вывода (IOPS)". Рекомендуемое минимальное значение 1000 IOPS.

Рекомендации касательно ресурсов для компонента Коллектор

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

Также необходимо иметь в виду, что количество потребляемой коллектором оперативной памяти зависит от настроенных методов обогащения (DNS, учетные записи, активы, обогащение данными из Kaspersky CyberTrace) и использования агрегации (на потребление оперативной памяти влияет параметр окна агрегации данных, количество полей, по которым выполняется агрегация данных, объем данных в агрегируемых полях). Показатели использования KUMA вычислительных ресурсов зависят от типа анализируемых событий и от эффективности нормализатора.

Например, при потоке событий 1000 EPS и выключенном обогащении событий (обогащение событий выключено, агрегация событий выключена, 5000 учетных записей, 5000 активов в тенанте) одному коллектору требуются следующие ресурсы:

• 1 процессорное ядро или 1 виртуальный процессор;

• 512 МБ оперативной памяти;

• 1 ГБ дискового пространства (без учета кэша событий).

Например, для 5 коллекторов, которые не выполняют обогащение событий потребуется выделить следующие ресурсы: 5 процессорных ядер, 2,5 ГБ оперативной памяти и 5 ГБ свободного дискового пространства.

Рекомендации экспертов "Лаборатории Касперского" для серверов хранилищ

Для подключения системы хранения данных (далее СХД) к серверам хранилища следует использовать высокоскоростные протоколы, например Fibre Channel или iSCSI 10G. Для подключения СХД не рекомендуется использовать протоколы прикладного уровня, такие как NFS и SMB.

На серверах кластера ClickHouse рекомендуется использовать файловую систему ext4.

При использовании RAID-массивов рекомендуется использовать RAID 0 для достижения высокой производительности, а RAID 10 для обеспечения высокой производительности и отказоустойчивости.

Для обеспечения отказоустойчивости и быстродействия подсистемы хранения данных мы рекомендуем разворачивать все узлы ClickHouse исключительно на разных дисковых массивах.

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

Для высоконагруженных инсталляций KUMA рекомендуется устанавливать ClickHouse на аппаратных серверах.

Требования к устройствам для установки агентов

Для передачи данных в коллектор KUMA на устройствах сетевой инфраструктуры требуется установить агенты. Требования к устройствам приведены в таблице ниже.

 

Устройства с ОС Windows

Устройства с ОС Linux

Процессор

Одноядерный, 1.4 ГГц или выше.

Одноядерный, 1.4 ГГц или выше.

ОЗУ

512 МБ

512 МБ

Свободное дисковое пространство

1 ГБ

1 ГБ

Операционные системы

  • Microsoft Windows 2012.

    Поскольку для Microsoft Windows 2012 наступил конец жизненного цикла, эта OC поддерживается ограниченно.

  • Microsoft Windows Server 2012 R2.
  • Microsoft Windows Server 2016.
  • Microsoft Windows Server 2019.
  • Microsoft Windows 10 20H2, 21H1.
  • Oracle Linux версии 8.6, 8.7, 9.2.
  • Astra Linux Special Edition РУСБ.10015-01 (2021-1126SE17 оперативное обновление 1.7.1).
  • Astra Linux Special Edition РУСБ. 10015-01 (2022-1011SE17MD оперативное обновление 1.7.2.UU.1).
  • Astra Linux Special Edition РУСБ.10015-01 (2022-1110SE17 оперативное обновление 1.7.3).
  • Astra Linux Special Edition РУСБ.10015-01 (2023-0630SE17MD срочное оперативное обновление 1.7.4.UU.1).

Требования к клиентским устройствам для работы с веб-интерфейсом KUMA

Процессор: Intel Core i3 8-го поколения.

ОЗУ: 8 ГБ.

Поддерживаемые браузеры:

  • Google Chrome 110 и выше.
  • Mozilla Firefox 115 и выше.

Требования к устройствам для установки KUMA в Kubernetes

Кластер Kubernetes для развертывания KUMA в отказоустойчивом варианте включает в минимальной конфигурации:

  • 1 узел балансировщика – не входит в кластер;
  • 3 узла-контроллера;
  • 2 рабочих узла.

Минимальные аппаратные требования к устройствам для установки KUMA в Kubernetes представлены в таблице ниже.

 

Балансировщик

Контроллер

Рабочий узел

Процессор

1 ядро с 2 потоками или 2 vCPU.

1 ядро с 2 потоками или 2 vCPU.

12 потоков или 12 vCPU.

ОЗУ

От 2 ГБ

От 2 ГБ

От 24 ГБ

Свободное дисковое пространство

От 30 ГБ

От 30 ГБ

От 1 ТБ в каталоге /opt/

 

От 32 ГБ в каталоге /var/lib/

 

Пропускная способность сети

10 Гбит/с

10 Гбит/с

10 Гбит/с

В начало
[Topic 217889]

Интерфейс KUMA

Работа с программой осуществляется через веб-интерфейс.

Окно веб-интерфейса программы содержит следующие элементы:

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

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

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

  • во всех разделах: закрывать окно, открывающееся в правой боковой панели – Esc;
  • в разделе События:
    • переключаться между событиями в правой боковой панели – и ;
    • запускать поиск (при фокусе на поле запроса) – Ctrl/Command + Enter;
    • сохранять поисковый запрос – Ctrl/Command + S.
В начало
[Topic 230383]

Совместимость с другими программами

Kaspersky Endpoint Security для Linux

При установке на одном сервере компонентов KUMA и программы Kaspersky Endpoint Security для Linux каталог report.db может достигать больших размеров и занимать все дисковое пространство. Кроме того, Kaspersky Endpoint Security для Linux по умолчанию сканирует все файлы KUMA, включая служебные, что может влиять на производительность. Чтобы избежать этих проблем, выполните следующие действия:

  • Обновите программу Kaspersky Endpoint Security для Linux до версии 12.0 или выше.
  • Мы не рекомендуем включать сетевые компоненты Kaspersky Endpoint Security для Linux.
  • Добавьте в общие исключения и в исключения для проверки по требованию следующие директории:
    1. На сервере Ядра KUMA:
      • /opt/kaspersky/kuma/victoria-metrics/ - папка с данными Victoria Metrics.
      • /opt/kaspersky/kuma/mongodb - папка с данными MongoDB.
    2. На сервере хранилища:
      • /opt/kaspersky/kuma/clickhouse/ - папка ClickHouse.
      • /opt/kaspersky/kuma/storage/<идентификатор хранилища>/buffers/ - папка с буферами хранилища.
    3. На сервере коррелятора:
      • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/data/ - папки со словарями.
      • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/lists - папки с активными листами.
      • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/ctxtables - папки с контекстными таблицами.
      • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/buffers - папка с буферами.
    4. На сервере коллекторов:
      • /opt/kaspersky/kuma/collector/<идентификатор коллектора>/buffets - папка с буферами.
      • /opt/kaspersky/kuma/collector/<идентификатор коллектора>/data/ - папка со словарями.
    5. Папки с журналами для каждого сервиса.

Подробнее об исключениях из проверки см. онлайн-справку Kaspersky Endpoint Security для Linux.

В начало
[Topic 230384]