[Topic 251751]

Справка Kaspersky Unified Monitoring and Analysis Platform

Новые функции

• Что нового в KUMA
  
  

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

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

Начало работы

• Архитектура программы
• Установка и удаление
• Работа с тенантами
• Мониторинг источников событий
  
  

Работа в веб-интерфейсе KUMA

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

Дополнительные возможности

• Взаимодействие с внешними системами по API
  
  

Лицензирование

• Лицензирование KUMA
  
  

Обращение в Службу технической поддержки

• Способы получения технической поддержки
  
  

[Topic 217694]

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

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

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

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

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

[Topic 220925]

Что нового

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

• Добавлена поддержка работы 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 расширен список доступных предустановленных панелей мониторинга.
• Добавлена возможность визуализировать на интерактивном графе зависимости ресурсов между собой и другими объектами. Теперь при редактировании ресурсов вы можете выяснить, к каким связанным ресурсам применится изменение. Вы можете отображать на графе те или иные типы ресурсов и сохранять построенный граф в формате 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.

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

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

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

• Добавлена возможность множественного выбора активов с помощью фильтра и удаления всех выбранных активов. Теперь вы также можете выделить все активы в категории, привязать их к категории или отвязать активы от категории.
• Добавлена возможность множественного выбора ресурсов и их удаления. Вы можете удалять все ресурсы или отдельные типы ресурсов.
• В группе виджетов Активы добавлены предустановленные виджеты, а также новый тип Пользовательский виджет, позволяющий производить пользовательскую аналитику по активам.
• Улучшен экспорт виджетов в 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 217846]

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

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

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

[Topic 217889]

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

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

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

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

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

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

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

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

На каждые 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 на устройствах сетевой инфраструктуры требуется установить агенты. Требования к устройствам приведены в таблице ниже.

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

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

ОЗУ: 8 ГБ.

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

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

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

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

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

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

[Topic 230383]

Интерфейс KUMA

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

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

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

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

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

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

[Topic 230384]

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

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 217958]

Архитектура программы

Стандартная установка программы включает следующие компоненты:

• Ядро, включающее графический интерфейс для мониторинга и управления настройками компонентов системы.
• Агенты, которые используются для пересылки сырых событий с серверов и рабочих станций в точки назначения KUMA.
• Один или несколько коллекторов, которые получают сообщения из источников событий и осуществляют их парсинг, нормализацию и, если требуется, фильтрацию и/или агрегацию.
• Маршрутизаторы событий, которые принимают события от коллекторов и с учетом настроенных фильтров направляют события в заданных точки назначения. Таким образом, эти сервисы используются для распределения нагрузки на каналы связи.
• Коррелятор, который анализирует полученные из коллекторов нормализованные события, выполняет необходимые действия с активными листами и создает алерты в соответствии с правилами корреляции.
• Хранилище, в котором содержатся нормализованные события и зарегистрированные алерты.

События передаются между компонентами по надежным транспортным протоколам (при желании с шифрованием). Вы можете настроить балансировку нагрузки для ее распределения между экземплярами сервисов, а также включить автоматическое переключение на резервный компонент в случае недоступности основного. Если недоступны все компоненты, события сохраняются в буфере жесткого диска и передаются позже. Размер буфера в файловой системе для временного хранения событий можно менять.

Архитектура KUMA

[Topic 217779]

Ядро

Ядро – это центральный компонент KUMA, на основе которого строятся все прочие сервисы и компоненты. Предоставляемый Ядром графический пользовательский интерфейс веб-интерфейса предназначен как для повседневного использования, так и для настройки системы в целом.

Ядро позволяет выполнять следующие задачи:

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

[Topic 217762]

Коллектор

Коллектор – это компонент программы, который получает сообщения из источников событий, обрабатывает их и передает в хранилище, коррелятор и/или сторонние сервисы для выявления алертов.

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

Алгоритм работы коллектора состоит из следующих этапов:

1. Получение сообщений из источников событий

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

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

   В программе доступны следующие типы коннекторов:

   • tcp;
   • udp;
   • netflow;
   • sflow;
   • nats-jetstream;
   • kafka;
   • kata/edr;
   • http;
   • sql;
   • file;
   • 1c-xml;
   • 1c-log;
   • diode;
   • ftp;
   • nfs;
   • vmware;
   • wmi;
   • wec;
   • snmp-trap;
   • elastic;
   • etw.
2. Парсинг и нормализация событий

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

   В программе доступны следующие нормализаторы:

   • JSON;
   • CEF;
   • Regexp;
   • Syslog (как для RFC3164 и RFC5424);
   • CSV;
   • Ключ-значение;
   • XML;
   • NetFlow (единый нормализатор для NetFlow v5, NetFlow v9 и IPFIX);
   • NetFlow v5;
   • NetFlow v9;
   • SQL;
   • IPFIX (v10).
3. Фильтрация нормализованных событий

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

4. Обогащение и преобразование нормализованных событий

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

   • константы;
   • cybertrace;
   • словари;
   • dns;
   • события;
   • ldap;
   • шаблоны;
   • данные о часовых поясах;
   • геоданные.

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

   • lower – перевод всех символов в нижний регистр;
   • upper – перевод всех символов в верхний регистр;
   • regexp – извлечение подстроки с использованием регулярных выражений RE2;
   • substring – получение подстроки по заданным номерам начальной и конечной позиции;
   • replace – замена текста введенной строкой;
   • trim – удаление заданных символов;
   • append – добавление символов в конец значения поля;
   • prepend – добавление символов в начало значения поля.
5. Агрегация нормализованных событий

   Вы можете настроить правила агрегации, чтобы уменьшить количество схожих событий, передаваемых в хранилище и/или коррелятор. Настройка правил агрегации позволит объединить несколько событий в одно событие. Это помогает снизить нагрузку на сервисы, которые отвечают за дальнейшую обработку событий, сэкономить место для хранения данных и сэкономить лицензионную квоту (EPS). Например, можно агрегировать в одно событие все события сетевых подключений, выполненных по одному и тому же протоколу транспортного и прикладного уровней между двумя IP-адресами и полученных в течение заданного интервала.

6. Передача нормализованных событий

   По завершении всех этапов обработки событие отправляется в настроенные точки назначения.

[Topic 217784]

Коррелятор

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

Полученные в ходе анализа данные применяются для выполнения следующих задач:

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

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

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

Алгоритм работы коррелятора состоит из следующих этапов:

1. Получение события

   Коррелятор получает нормализованное событие из коллектора или другого сервиса.

2. Применение правил корреляции

   Правила корреляции можно настроить на срабатывание на основе одного события или последовательности событий. Если по правилам корреляции не был выявлен алерт, обработка события завершается.

3. Реагирование на алерт

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

   • обогащение события;
   • операции с активными листами;
   • отправка уведомлений;
   • сохранение корреляционного события.
4. Отправка корреляционного события

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

[Topic 218010]

Хранилище

Хранилище KUMA используется для хранения нормализованных событий таким образом, чтобы к ним обеспечивался быстрый и бесперебойный доступ из KUMA с целью извлечения аналитических данных. Скорость и бесперебойность доступа обеспечивается за счет использования технологии ClickHouse. Таким образом хранилище – это кластер ClickHouse, связанный с сервисом хранилища KUMA. Кластеры ClickHouse можно дополнять дисками холодного хранения данных.

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

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

[Topic 220211]

Основные сущности

В этом разделе описаны основные сущности, с которыми работает KUMA.

[Topic 221264]

О тенантах

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

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

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

По умолчанию в KUMA созданы два тенанта:

• Главный (или Main) – в нем содержатся ресурсы и сервисы, относящиеся к главному тенанту. Эти ресурсы доступны только главному администратору.
• Общий – в этот тенант главный администратор может поместить ресурсы, категории активов и политики мониторинга, которые смогут задействовать пользователи всех тенантов. Доступ к общему тенанту можно ограничить для отдельных пользователей.

  Если в параметрах пользователя установлен флажок Скрывать ресурсы из общего тенанта, этому пользователю становится недоступна принадлежащая общему тенанту папка Shared в веб-интерфейсе KUMA в разделе Ресурсы → <Тип ресурсов>. Это означает, что пользователь не сможет просмотреть, отредактировать или еще как-то использовать общие ресурсы. Пользователь также не сможет экспортировать общие ресурсы и наборы ресурсов, в состав которых входят ресурсы из общего тенанта: ни через веб-интерфейс, ни через REST API.

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

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

[Topic 217693]

О событиях

События – это события информационной безопасности, зарегистрированные на контролируемых элементах IT-инфраструктуры организации. Например, события включают попытки входа в систему, взаимодействия с базой данных и рассылку информации с датчиков. Каждое отдельное событие может показаться бессмысленным, но если рассматривать их вместе, они формируют более широкую картину сетевой активности, помогающую идентифицировать угрозы безопасности. Это основная функциональность KUMA.

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

Для обеспечения удобства расследования алертов и обработки инцидентов убедитесь, что на всех устройствах, связанных с жизненным циклом обработки событий (источники событий, серверы KUMA, клиентские хосты) время синхронизируется при помощи серверов Network Time Protocol (NTP).

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

Первые шаги выполняются в коллекторе.

1. Сырое событие. Исходное сообщение, полученное KUMA от источника событий с помощью коннектора, называется сырым событием. Это необработанное сообщение, и KUMA пока не может использовать его. Чтобы с таким событием можно было работать, его требуется нормализовать, то есть привести к модели данных KUMA. Это происходит на следующем этапе.
2. Нормализованное событие. Нормализатор преобразует данные сырого события так, чтобы они соответствовали модели данных KUMA. После этой трансформации исходное сообщение становится нормализованным событием и может быть проанализировано в KUMA. С этого момента KUMA работает только с нормализованными событиями. Необработанные, сырые события больше не используются, но их можно сохранить как часть нормализованных событий внутри поля Raw.

   В программе представлены следующие нормализаторы:

   • JSON
   • CEF
   • Regexp
   • Syslog (как для RFC3164 и RFC5424)
   • CSV/TSV
   • Ключ-значение
   • XML
   • Netflow v5, v9, IPFIX (v10), sFlow v5
   • SQL

   По завершении этого этапа нормализованные события можно использовать для анализа.

3. Точка назначения. После обработки события коллектором оно готово к пересылке в другие сервисы KUMA: в коррелятор и/или хранилище KUMA.

Следующие этапы жизненного цикла события проходят в корреляторе.

Типы событий:

1. Базовое событие. Событие, которое было нормализовано.
2. Агрегированное событие. Чтобы не тратить время и ресурсы на обработку большого количества однотипных сообщений, похожие события можно объединять в одно событие. Такие события ведут себя и обрабатываются так же, как и базовые события, но в дополнение ко всем параметрам родительских событий (событий, которые были объединены) агрегированные события имеют счетчик, показывающий количество родительских событий, которые они представляют. Агрегированные события также хранят время, когда были получены первое и последнее родительские события.
3. Корреляционное событие. При обнаружении последовательности событий, удовлетворяющих условиям правила корреляции, программа создает корреляционное событие. Эти события можно фильтровать, обогащать и агрегировать. Их также можно отправить на хранение или в коррелятор на анализ.
4. Событие аудита. События аудита создаются при выполнении в KUMA определенных действий, связанных с безопасностью, и используются для обеспечения целостности системы. Они автоматически размещаются в отдельном пространстве хранилища и хранятся не менее 365 дней.
5. Событие мониторинга. Такие события используются для отслеживания изменений в количестве данных, поступающих в KUMA.

[Topic 217691]

Об алертах

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

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

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

На основании обнаружений можно создать инциденты.

Работа с алертами в KUMA описана в этом разделе.

[Topic 220212]

Об инцидентах

Если характер поступающих в KUMA данных, создаваемых корреляционных событий и алертов указывает на возможную атаку или уязвимость, признаки такого происшествия можно объединить в инцидент. Это позволяет специалистам службы безопасности анализировать проявления угрозы комплексно и облегчает реагирование.

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

Инциденты можно экспортировать в НКЦКИ.

[Topic 217692]

Об активах

Активы – это сетевые устройства, зарегистрированные в KUMA. Активы генерируют сетевой трафик при отправке и получении данных. Программа KUMA может быть настроена для отслеживания этой активности и создания базовых событий с четким указанием того, откуда исходит трафик и куда он направляется. В событии могут быть записаны исходные и целевые IP-адреса, а также DNS-имена. Если вы регистрируете актив с определенными параметрами (например, конкретным IP-адресом), формируется связь между этим активом и всеми событиями, в которых указаны эти параметры (в нашем случае IP-адрес).

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

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

Работа с активами в KUMA описана в этом разделе.

[Topic 221640]

О ресурсах

Ресурсы – это компоненты KUMA, которые содержат параметры для реализации различных функций: например, установления связи с заданным веб-адресом или преобразования данных по определенным правилам. Из этих компонентов, как из частей конструктора, собираются наборы ресурсов для сервисов, на основе которых в свою очередь создаются сервисы KUMA.

[Topic 221642]

О сервисах

Сервисы – это основные компоненты KUMA, с помощью которых осуществляется работа с событиями: получение, обработка, анализ и хранение. Каждый сервис состоит из двух частей, работающих вместе:

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

Между собой части сервисов соединены с помощью идентификатора сервисов.

[Topic 217690]

Об агентах

Агенты KUMA – это сервисы, которые используются для пересылки необработанных событий с серверов и рабочих станций в точки назначения KUMA.

Типы агентов:

• wmi – используются для получения данных с удаленных устройств Windows с помощью Windows Management Instrumentation. Устанавливается на устройства Windows.
• wec – используются для получения журналов Windows с локального устройства с помощью Windows Event Collector. Устанавливается на устройства Windows.
• tcp – используются для получения данных по протоколу TCP. Устанавливается на устройства Linux и Windows.
• udp – используются для получения данных по протоколу UDP. Устанавливается на устройства Linux и Windows.
• nats-jetstream – используются для коммуникации через NATS. Устанавливается на устройства Linux и Windows.
• kafka – используются для коммуникации с помощью kafka. Устанавливается на устройства Linux и Windows.
• http – используются для связи по протоколу HTTP. Устанавливается на устройства Linux и Windows.
• file – используются для получения данных из файла. Устанавливается на устройства Linux и Windows.
• ftp – используются для получения данных по протоколу File Transfer Protocol. Устанавливается на устройства Linux и Windows.
• nfs – используются для получения данных по протоколу Network File System. Устанавливается на устройства Linux и Windows.
• snmp – используются для получения данных с помощью Simple Network Management Protocol. Устанавливается на устройства Linux и Windows.
• diode – используются вместе с диодами данных для получения событий из изолированных сегментов сети. Устанавливается на устройства Linux и Windows.
• etw – используются для получения данных Event Tracing for Windows. Устанавливается на устройства Windows.

[Topic 217695]

Об уровне важности

Параметр Уровень важности отражает, насколько чувствительны для безопасности происшествия, обнаруженные коррелятором KUMA. Он показывает порядок, в котором следует обрабатывать алерты, а также указывает, требуется ли участие старших специалистов по безопасности.

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

Уровень важности алерта можно изменить вручную. Измененный вручную уровень важности перестает автоматически обновляться правилами корреляции.

Возможные значения уровня важности:

• Низкий
• Средний
• Высокий
• Критический

[Topic 217959]

Лицензирование программы

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

[Topic 222243]

О Лицензионном соглашении

Лицензионное соглашение – это юридическое соглашение между вами и АО "Лаборатория Касперского", в котором указано, на каких условиях вы можете использовать программу.

Внимательно ознакомьтесь с условиями Лицензионного соглашения перед началом работы с программой.

Вы можете ознакомиться с условиями Лицензионного соглашения следующими способами:

• Перейти в папку с распакованным установщиком и прочитать текстовый файл ./roles/kuma/files/LICENSE
• Перейти в папку с распакованным установщиком и выполнить следующую команду, чтобы вывести на экран текст лицензионного соглашения:

  ./roles/kuma/files/kuma license --show

• На хосте с любым установленным компонентом KUMA - таким как Ядро, коллектор, коррелятор, хранилище - выполнить следующую команду, чтобы вывести на экран текст лицензионного соглашения:

  /opt/kaspersky/kuma/kuma license --show

• На устройствах, входящих в группы kuma_storage, kuma_collector, kuma_correlator или kuma_core в файле инвентаря, открыть файл LICENSE, расположенный в папке /opt/kaspersky/kuma.

  На хосте из группы kuma_core можно увидеть лицензионное соглашение только если выбрана не кластерная установка.

• На Windows-агенте выполнить следующую команду, чтобы вывести на экран текст лицензионного соглашения:

  .\kuma.exe license --show

• На Linux-агенте перейти в директорию с исполняемым файлом kuma и выполнить следующую команду, чтобы вывести на экран текст лицензионного соглашения:

  ./kuma license --show

Вы принимаете условия Лицензионного соглашения, подтверждая свое согласие с текстом Лицензионного соглашения во время установки программы. Если вы не согласны с условиями Лицензионного соглашения, вы должны прервать установку программы и не должны использовать программу.

[Topic 233460]

О лицензии

Лицензия – это ограниченное по времени право на использование программы, предоставляемое вам на основании Лицензионного соглашения.

Лицензия включает в себя право на получение следующих видов услуг:

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

Объем предоставляемых услуг и срок использования программы зависят от типа лицензии, по которой была активирована программа.

Лицензия предоставляется при приобретении программы. Поведение KUMA в случае отсутствия лицензии:

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

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

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

[Topic 233471]

О Лицензионном сертификате

Лицензионный сертификат – это документ, который передается вам вместе с файлом ключа или кодом активации.

В Лицензионном сертификате содержится следующая информация о предоставляемой лицензии:

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

[Topic 233462]

О лицензионном ключе

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

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

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

Лицензионный ключ может быть активным и резервным.

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

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

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

[Topic 233467]

О файле ключа

Файл ключа – это файл с названием license.key, который вам предоставляет "Лаборатория Касперского". Файл ключа предназначен для добавления лицензионного ключа, активирующего программу.

Вы получаете файл ключа по указанному вами адресу электронной почты после приобретения KUMA.

Чтобы активировать программу с помощью файла ключа, не требуется подключение к серверам активации "Лаборатории Касперского".

Если файл ключа был случайно удален, вы можете его восстановить. Файл ключа может потребоваться вам, например, для регистрации в Kaspersky CompanyAccount.

Для восстановления файла ключа вам нужно выполнить одно из следующих действий:

• Обратиться к продавцу лицензии.
• Получить файл ключа на веб-сайте "Лаборатории Касперского" на основе имеющегося кода активации.

[Topic 276582]

О лицензионном коде

Лицензионный код – это уникальная последовательность из двадцати латинских букв и цифр, которая позволяет активировать программу. Вы получаете лицензионный код от "Лаборатория Касперского" по указанному вами адресу электронной почты после приобретения KUMA.

При активации лицензионным кодом с сервера Ядра требуется постоянный доступ в интернет. Чтобы активировать программу с помощью лицензионного кода требуется подключение к серверу активации "Лаборатории Касперского":

https://activation-v2.kaspersky.com:443

В случае закрытой инфраструктуры вы можете указать прокси-сервер.

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

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

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

Если вы хотите использовать лицензионный код для активации KUMA, в разделе Параметры → Лицензия в раскрывающемся списке Тип активации выберите Активация ключом.

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

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

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

[Topic 261327]

Предоставление данных в Kaspersky Unified Monitoring and Analysis Platform

Данные, передаваемые третьим сторонам

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

Данные, обрабатываемые локально

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

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

Для выполнения своих основных функций KUMA может принимать, хранить и обрабатывать следующую информацию:

• Данные об устройствах в сети организации.

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

  • Импортировать активы:
    • По запросу из MaxPatrol.
    • По расписанию: из Kaspersky Security Center и KICS/KATA.
  • Создать активы вручную через веб-интерфейс или с помощью API.

  KUMA хранит следующие данные об устройствах:

  • Технические характеристики устройства.
  • Уязвимости, зафиксированные на активе.
  • Данные, специфичные для источника получения актива.
• Дополнительные технические характеристики устройств в сети организации, указываемые пользователем для отправки инцидента в НКЦКИ: IP адреса, доменные имена, URI-адреса, Email-адрес атакованного объекта, атакованная сетевая служба и порт/протокол.
• Данные организации: наименование, ИНН, адрес, адрес электронной почты для отправки информации об уведомлении.
• Данные Active Directory об организационных единицах, доменах, пользователях, группах, полученные в результате опроса сети Active Directory.

  Сервер Ядра KUMA получает эти данные, если настроена соответствующая интеграция. Для обеспечения безопасного подключения к серверу LDAP пользователь вводит URL сервера, базу поиска (Base DN), учетные данные для подключения и сертификат в консоли KUMA.

• Данные для доменной аутентификации пользователей в KUMA: корневой DN для поиска групп доступа в службе каталогов Active Directory, URL-адрес контроллера домена, сертификат (публичный ключ root, которым подписан сертификат AD), полный путь к группе доступа пользователей в AD (distinguished name).
• Данные, содержащиеся в событиях от настроенных источников.

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

• Данные, необходимые для интеграции KUMA с другими приложениями (Kaspersky Threat Lookup, Kaspersky CyberTrace, Kaspersky Security Center, Kaspersky Industrial CyberSecurity for Networks, Kaspersky Automated Security Awareness Platform, Kaspersky Endpoint Detection and Response, Security Orchestration, Automation and Response SOAR, AI-сервисы: AI рейтинг и статус активов, Kaspersky Investigation & Response Assistant).

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

• Данные об источниках, с которых настроено получение событий.

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

• Учетные записи пользователей: имя, логин, адрес электронной почты. Пользователь может просмотреть свои данные в профиле в консоли KUMA.
• Параметры профиля пользователя:
  • Роль пользователя в KUMA. Пользователь может видеть назначенную ему роль(-и).
  • Язык локализации, параметры уведомлений, отображение непечатаемых символов.

    Пользователь вводит эти данные в интерфейсе KUMA.

  • Список категорий активов в разделе Активы, панель мониторинга по умолчанию, признак режима ТВ для панели мониторинга, SQL-запрос по событиям по умолчанию, пресет по умолчанию.

    Пользователь указывает эти параметры в соответствующих разделах консоли KUMA.

• Данные для доменной аутентификации пользователей в KUMA:
  • Active Directory: корневой DN для поиска групп доступа в службе каталогов Active Directory, URL-адрес контроллера домена, сертификат (публичный ключ root, которым подписан сертификат AD), полный путь к группе доступа пользователей в AD (distinguished name).
  • Active Directory Federation Services: идентификатор доверенной стороны (идентификатор KUMA в ADFS), URI для получения метаданных Connect, URL для перенаправления из ADFS и сертификат сервера ADFS.
  • FreeIPA: база поиска (Base DN), URL, сертификат (публичный ключ root, которым подписан сертификат FreeIPA), учетные данные пользовательской интеграции, учетные данные для подключения.
• События аудита.

  KUMA автоматически фиксирует события аудита.

• Журнал KUMA.

  Пользователь может включить ведение расширенных записей журналов в консоли KUMA. Записи журнала хранятся на устройстве пользователя, автоматическая передача данных отсутствует.

• Информация о принятии пользователем условий юридических соглашений с "Лабораторией Касперского".
• Любые данные, которые пользователь вводит в интерфейсе KUMA.

Перечисленные выше данные могут попасть в KUMA следующими способами:

• Пользователь вводит данные в консоли KUMA.
• Сервисы KUMA (агент или коллектор) получают данные при настроенном пользователем подключении к источникам событий.
• Через REST API KUMA.
• Данные об устройствах могут быть получены с помощью утилиты из MaxPatrol.

Перечисленные данные хранятся в базе данных KUMA (Mongo DB, Click House, SQLite). Пароли хранятся в зашифрованном виде (хранится хеш паролей).

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

Файлы дампа, файлы трассировки и файлы журналов компонентов KUMA могут содержать персональные и конфиденциальные данные. Файлы дампа, файлы трассировки и файлы журналов хранятся в открытом виде на устройстве. Файлы дампа, файлы трассировки и файлы журналов не передаются в "Лабораторию Касперского" автоматически, но администратор может передать эти данные в "Лабораторию Касперского" вручную по запросу Службы технической поддержки для решения проблем в работе KUMA.

"Лаборатория Касперского" использует полученные данные в анонимной форме и только для целей общей статистики. Сводная статистика автоматически формируется из полученной исходной информации и не содержит каких-либо персональных или прочих конфиденциальных данных. При накоплении новых данных предыдущие данные уничтожаются (один раз в год). Сводная статистика хранится неограниченное время.

"Лаборатория Касперского" обеспечивает защиту всех полученных данных в соответствии с законодательством и применимыми правилами "Лаборатории Касперского". Данные передаются по безопасным каналам связи.

[Topic 217709]

Добавление лицензионного ключа в веб-интерфейс программы

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

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

Чтобы добавить лицензионный ключ в веб-интерфейс KUMA:

1. Откройте веб-интерфейс KUMA и выберите раздел Параметры → Лицензия.

   Откроется окно с условиями лицензии KUMA.

2. Выберите ключ, который хотите добавить:
   • Если необходимо добавить активный ключ, нажмите на кнопку Добавить активный лицензионный ключ.

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

   • Если вы хотите добавить резервный ключ, нажмите на кнопку Добавить резервный лицензионный ключ.

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

   Откроется окно выбора файла лицензионного ключа.

3. Выберите файл лицензии, указав путь к папке и имя лицензионного ключа (файла с расширением KEY).

Лицензионный ключ из выбранного файла загружен в программу. Информация о лицензионном ключе отображается в разделе Параметры → Лицензия.

[Topic 218040]

Просмотр информации о добавленном лицензионном ключе в веб-интерфейсе программы

В веб-интерфейсе KUMA можно просмотреть информацию о добавленном лицензионном ключе. Информация о лицензионном ключе отображается в разделе Параметры → Лицензия.

Только пользователи с ролью администратора могут просматривать информацию о лицензии.

В окне вкладки Лицензия отображается следующая информация о добавленных лицензионных ключах:

• Истекает – дата истечения срока действия лицензионного ключа.
• Осталось дней – количество дней до истечения срока действия лицензии.
• Доступное EPS – количество обрабатываемых в секунду событий, которое поддерживается лицензией.
• Текущее EPS за сутки – текущее среднее количество событий за сутки, которое обрабатывает KUMA.
• Лицензионный ключ – уникальная буквенно-цифровая последовательность.
• Компания – название компании, купившей лицензию.
• Имя клиента – имя клиента, купившего лицензию.
• Модули – модули, доступные для лицензии.

Для лицензии SMB доступны следующие параметры в дополнение в указанным выше:

• Текущее EPS за сутки – текущее среднее количество событий за сутки, которое обрабатывает KUMA.
• Текущее EPS за час – текущее среднее количество событий за час, которое обрабатывает KUMA.

Если значения двух параметров превышены, коллектор с максимальным количеством EPS останавливает прием новых событий на 1 час. По прошествии 1 часа работа коллектора будет восстановлена. Может быть приостановлена работа нескольких коллекторов. Пользователю с ролью Главный администратор будет отправлено уведомление о превышении допустимого лицензией количества EPS.

[Topic 217963]

Удаление лицензионного ключа в веб-интерфейсе программы

Вы можете удалить добавленный лицензионный ключ из KUMA (например, если вам нужно заменить текущий лицензионный ключ другим). После удаления лицензионного ключа коллекторы сразу прекращают принимать и обрабатывать события. Старые события остаются доступны. Также невозможно создавать и редактировать ресурсы, создавать и запускать сервисы. Эта работа возобновится при добавлении лицензионного ключа.

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

Чтобы удалить лицензионный ключ:

1. Откройте веб-интерфейс KUMA и выберите раздел Параметры → Лицензия.

   Откроется окно с условиями лицензии KUMA.

2. Нажмите на значок на лицензии, которую требуется удалить.

   Откроется окно подтверждения.

3. Подтвердите удаление лицензионного ключа.

Лицензионный ключ удален из программы.

[Topic 249526]

Руководство администратора

В этой главе представлена информация об установке и настройке SIEM-системы KUMA.

[Topic 217904]

Установка и удаление KUMA

Развернуть всё | Свернуть всё

Для выполнения установки вам понадобится дистрибутив:

• kuma-ansible-installer-<номер сборки>.tar.gz содержит все необходимые файлы для установки KUMA без поддержки отказоустойчивых конфигураций.
• kuma-ansible-installer-ha-<номер сборки>.tar.gz содержит все необходимые файлы для установки KUMA в отказоустойчивой конфигурации.

Для установки вам понадобится файл установщика install.sh и файл инвентаря с описанием инфраструктуры. Файл инвентаря вы сможете создать на основе шаблона. Каждый дистрибутив содержит файл установщика install.sh и следующие шаблоны файла инвентаря:

• single.inventory.yml.template
• distributed.inventory.yml.template
• expand.inventory.yml.template
• k0s.inventory.yml.template

KUMA размещает свои файлы в папке /opt, поэтому мы рекомендуем сделать /opt отдельным разделом и выделить под него все дисковое пространство, за исключением 16 ГБ для операционной системы.

Установка KUMA выполняется одинаково на всех хостах при помощи установщика и подготовленного вами файла инвентаря, в котором описана конфигурация. Мы рекомендуем заранее продумать схему установки.

Доступны следующие варианты установки:

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

  Схема установки на одном сервере

  

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

  Пример файла инвентаря для схемы установки на одном сервере

  all:

  vars:

  deploy_to_k8s: false

  need_transfer: false

  generate_etc_hosts: false

  deploy_example_services: true

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma1.example.com:

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma1.example.com

  kuma_correlator:

  hosts:

  kuma1.example.com

  kuma_storage:

  hosts:

  kuma1.example.com:

  shard: 1

  replica: 1

  keeper: 1

  Вы можете установить все компоненты KUMA на одном сервере: в файле инвентаря single.inventory.yml для всех компонентов следует указывать один сервер. Установка "все в одном" может обеспечить обработку небольшого потока событий - до 10000 EPS. Если вы планируете использовать много макетов панели мониторинга и обрабатывать большой объем поисковых запросов, одного сервера может не хватить. Мы рекомендуем выбрать распределенную установку.

• Распределенная установка

  Схема распределенной установки

  

  Схема распределенной установки

  Пример файла инвентаря для схемы распределенной установки

  all:

  vars:

  deploy_to_k8s: false

  need_transfer: false

  generate_etc_hosts: false

  deploy_example_services: false

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma-core-1.example.com:

  ip: 0.0.0.0

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma-collector-1.example.com:

  ip: 0.0.0.0

  kuma_correlator:

  hosts:

  kuma-correlator-1.example.com:

  ip: 0.0.0.0

  kuma_storage:

  hosts:

  kuma-storage-cluster1-server1.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server2.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server3.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server4.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server5.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 1

  kuma-storage-cluster1-server6.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 2

  kuma-storage-cluster1-server7.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 3

  Вы можете установить сервисы KUMA на разных серверах: конфигурацию для распределенной установки вы можете описать в файле инвентаря distributed.inventory.yml.

• Распределенная установка в отказоустойчивой конфигурации

  Схема распределенной установки в отказоустойчивой конфигурации

  

  Распределенная установка в отказоустойчивой конфигурации

  Пример файла инвентаря для схемы распределенной установки в отказоустойчивой конфигурации

  all:

  vars:

  deploy_to_k8s: true

  need_transfer: true

  generate_etc_hosts: false

  airgap: true

  deploy_example_services: false

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma-core-1.example.com:

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma-collector-1.example.com:

  ip: 0.0.0.0

  kuma-collector-2.example.com:

  ip: 0.0.0.0

  kuma_correlator:

  hosts:

  kuma-correlator-1.example.com:

  ip: 0.0.0.0

  kuma-correlator-2.example.com:

  ip: 0.0.0.0

  kuma_storage:

  hosts:

  kuma-storage-cluster1-server1.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server2.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server3.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server4.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server5.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 1

  kuma-storage-cluster1-server6.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 2

  kuma-storage-cluster1-server7.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 3

  kuma_k0s:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_lb:

  hosts:

  kuma_lb.example.com:

  kuma_managed_lb: true

  kuma_control_plane_master:

  hosts:

  kuma_cpm.example.com:

  ansible_host: 10.0.1.10

  kuma_control_plane_master_worker:

  kuma_control_plane:

  hosts:

  kuma_cp1.example.com:

  ansible_host: 10.0.1.11

  kuma_cp2.example.com:

  ansible_host: 10.0.1.12

  kuma_control_plane_worker:

  kuma_worker:

  hosts:

  kuma-core-1.example.com:

  ansible_host: 10.0.1.13

  extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

  kuma_worker2.example.com:

  ansible_host: 10.0.1.14

  extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

  Вы можете установить Ядро KUMA в кластере Kubernetes для обеспечения отказоустойчивости. Используйте файл инвентаря k0s.inventory.yml для описания конфигурации.

[Topic 231034]

Требования к установке программы

Общие требования к установке программы

Вы можете установить программу на следующих операционных системах:

• Oracle Linux.
• Astra Linux.
• Ubuntu.
• РЕД ОС.

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

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

  Операционная система РЕД ОС 8 поддерживается без высокой доступности (англ. High Availability, HA). При использовании операционной системы РЕД ОС 8 в конфигурации Сервер с поддержкой графического интерфейса вам нужно установить пакет iscsi-initiator-utils, после чего выполнить следующие команды:

  systemctl enable iscsid

  systemctl start iscsid

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

• Серверы, предназначенные для установки компонентов, соответствуют аппаратным и программным требованиям.
• Порты, которые KUMA займет при установке, доступны.
• Адресация компонентов KUMA осуществляется по полному доменному имени FQDN хоста в формате hostname.example.com. Перед установкой программы убедитесь, что в поле Static hostname возвращается правильное имя FQDN хоста. Для этого выполните команду:

  hostnamectl status

• Имя сервера, на котором запускается установщик, отличается от localhost или localhost.<домен>.
• Имя сервера, котором будет установлено Ядро KUMA, не начинается с цифры.
• Настроена синхронизация времени на всех серверах с сервисами KUMA по протоколу Network Time Protocol (NTP).

Требования к установке на операционных системах Oracle Linux, Astra Linux, Ubuntu 22.04 LTS и РЕД ОС 7.3.4 и 8

[Topic 267523]

Обновление с операционной системы Oracle Linux 8.x до Oracle Linux 9.x

Чтобы выполнить обновление с Oracle Linux 8.x до Oracle Linux 9.x:

1. Отключите сервисы KUMA на хостах, где сервисы установлены, с помощью следующих команд:
   • sudo systemctl disable kuma-collector-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-correlator-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-storage-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-grafana.service
   • sudo systemctl disable kuma-mongodb.service
   • sudo systemctl disable kuma-victoria-metrics.service
   • sudo systemctl disable kuma-vmalert.service
   • sudo systemctl disable kuma-core.service
2. Выполните обновление ОС на каждом хосте.
3. После обновления установите пакет compat-openssl11 на хосте, где будет разворачиваться Ядро KUMA вне кластера, с помощью следующей команды:

   yum install compat-openssl11

4. Включите сервисы на хостах, где сервисы установлены, с помощью следующих команд:
   • sudo systemctl enable kuma-core.service
   • sudo systemctl enable kuma-storage-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-collector-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-correlator-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-grafana.service
   • sudo systemctl enable kuma-mongodb.service
   • sudo systemctl enable kuma-victoria-metrics.service
   • sudo systemctl enable kuma-vmalert.service
5. Перезагрузите хосты.

В результате обновление выполнено.

[Topic 217770]

Порты, используемые KUMA при установке

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

Перед установкой Ядра на устройстве убедитесь, что следующие порты свободны:

• 9090: используется Victoria Metrics.
• 8880: используется VMalert.
• 27017: используется MongoDB.

В таблице ниже показаны значения сетевых портов по умолчанию. Порты открываются установщиком автоматически при установке KUMA

Сетевые порты, используемые для взаимодействия компонентов KUMA

Порты, используемые предустановленными ресурсами из состава OOTB

Порты открываются установщиком автоматически при установке KUMA.

Порты, используемые предустановленными ресурсами из состава OOTB:

• 7230/tcp
• 7231/tcp
• 7232/tcp
• 7233/tcp
• 7234/tcp
• 7235/tcp
• 5140/tcp
• 5140/udp
• 5141/tcp
• 5144/udp

Трафик Ядра KUMA в отказоустойчивой конфигурации

В таблице "Трафик Ядра KUMA в отказоустойчивой конфигурации" указаны инициатор соединения (источник) и назначение. Номер порта на инициаторе может быть динамическим. Обратный трафик в рамках установленного соединения не должен блокироваться.

Трафик Ядра KUMA в отказоустойчивой конфигурации

[Topic 294030]

Скачивание CA-сертификатов

В веб-интерфейсе KUMA вы можете скачать следующие CA-сертификаты:

• CA-сертификат REST API

  Сертификат требуется для проверки подлинности API-сервера, обслуживающего публичное API KUMA. Также вы можете использовать этот сертификат при импорте данных из отчетов MaxPatrol.

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

• CA-сертификат Microservice

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

Чтобы скачать CA-сертификат:

1. Откройте веб-интерфейс KUMA.
2. В левом нижнем углу окна нажмите на имя учетной записи пользователя и в открывшемся меню нажмите на кнопку CA-сертификат REST API или CA-сертификат Microservice, в зависимости от сертификата, который вы хотите скачать.

Сертификат сохраняется в папку загрузки, настроенную в вашем браузере.

[Topic 275543]

Перевыпуск внутренних CA-сертификатов

Изменено место хранения самоподписанного CA-сертификата и механизм перевыпуска сертификата.
Сертификат хранится в СУБД. Недопустимо применять прежний метод перевыпуска внутренних сертификатов через удаление сертификатов из файловой системы Ядра и перезапуск Ядра. Такой способ приведет к невозможности запустить Ядро. До завершения процесса перевыпуска сертификатов не следует подключать к Ядру новые сервисы.
После того как вы перевыпустите внутренние CA-сертификаты в разделе веб-интерфейса KUMA Параметры → Общие → Перевыпустить внутренние CA-сертификаты, необходимо остановить сервисы, удалить прежние сертификаты из директорий сервисов и вручную перезапустить все сервисы. Перевыпускать внутренние CA-сертификаты могут только пользователи с ролью Главный администратор.

Опция Перевыпустить внутренние CA-сертификаты доступна только пользователю с ролью Главный администратор.

Перевыпуск сертификатов для отдельного сервиса остается прежним: в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы необходимо выбрать сервис, выбрать в контекстном меню Сбросить сертификат и удалить прежний сертификат в директории установки сервиса. KUMA автоматически сгенерирует новый сертификат. Для работающих сервисов перезапуск не требуется, новый сертификат будет применен автоматически. Если сервис был остановлен, необходимо перезапустить сервис, чтобы применить новый сертификат.

Чтобы перевыпустить внутренние CA-сертификаты:

1. В веб-интерфейсе KUMA перейдите в раздел Параметры → Общие, нажмите кнопку Перевыпустить внутренние CA-сертификаты и ознакомьтесь с отобразившимся предупреждением. Если вы принимаете решение продолжить перевыпуск сертификатов, нажмите Да.

   В результате будут перевыпущены CA-сертификаты для сервисов KUMA и CA-сертификат для ClickHouse. Далее вам нужно будет остановить сервисы, удалить прежние сертификаты из директорий установки сервисов, перезапустить Ядро и перезапустить остановленные сервисы, чтобы применить перевыпущенные сертификаты.

2. Подключитесь к хостам, где развернуты сервисы коллектора, коррелятора и маршрутизатора событий.
   1. Остановите все сервисы с помощью следующей команды:

      sudo systemctl stop kuma-<collector/correlator/eventRouter>-<ID сервиса>.service

   2. Удалите файлы сертификатов internal.cert и internal.key из директорий /opt/kaspersky/kuma/<тип сервиса>/<ID сервиса>/certificates с помощью следующей команды:

      sudo rm -f /opt/kaspersky/kuma/<тип сервиса>/<ID сервиса>/certificates/internal.cert

      sudo rm -f /opt/kaspersky/kuma/<тип сервиса>/<ID сервиса>/certificates/internal.key

3. Подключитесь к хостам, где развернуты сервисы хранилища.
   1. Остановите все сервисы хранилища.

      sudo systemctl stop kuma-<storage>-<ID сервиса>.service

   2. Удалите файлы сертификатов internal.cert и internal.key из директорий /opt/kaspersky/kuma/storage/<ID сервиса>/certificates.

      sudo rm -f /opt/kaspersky/kuma/storage/<ID сервиса>/certificates/internal.cert

      sudo rm -f /opt/kaspersky/kuma/storage/<ID сервиса>/certificates/internal.key

4. Удалите все сертификаты ClickHouse из директории /opt/kaspersky/kuma/clickhouse/certificates.

   sudo rm -f /opt/kaspersky/kuma/clickhouse/certificates/internal.cert

   sudo rm -f /opt/kaspersky/kuma/clickhouse/certificates/internal.key

5. Подключитесь к хостам, где развернуты сервисы агентов.
   1. Остановите сервисы агентов Windows и агентов Linux.
   2. Удалите файлы сертификатов internal.cert и internal.key из рабочих директорий агентов.
6. Запустите Ядро, чтобы применить новые CA-сертификаты.
   • Для установки "all-in-one" и распределенной установки KUMA выполните команду:

     sudo systemctl restart kuma-core-00000000-0000-0000-0000-000000000000.service

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

     sudo k0s kubectl rollout restart deployment/core-deployment -n kuma

     Перезапуск victoria-metrics при этом не потребуется.

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

7. Перезапустите все сервисы, остановленные в ходе выполнения инструкции.

   sudo systemctl start kuma-<collector/correlator/eventRouter/storage>-<ID сервиса>.service

8. Перезапустите victoria-metrics.

   sudo systemctl start kuma-victoria-metrics.service

Внутренние CA-сертификаты перевыпущены и применены.

[Topic 217747]

Изменение самоподписанного сертификата веб-консоли

Вы можете использовать сертификат и ключ своей компании вместо самоподписанного сертификата веб-консоли. Например, если вы хотите заменить сертификат веб-консоли с самоподписанного CA Core на сертификат, выпущенный корпоративным CA, необходимо предоставить external.cert и незашифрованный external.key в формате PEM.

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

Чтобы заменить сертификат веб-консоли KUMA на сертификат external:

1. Если вы используете сертификат и ключ в PFX контейнере, в OpenSSL конвертируйте файл PFX в сертификат и зашифрованный ключ в формате PEM:

   openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nokeys -out external.cert

   openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nocerts -nodes -out external.key

   При выполнении команды потребуется указать пароль от ключа PFX (Enter Import Password).

   В результате получен сертификат external.cert и ключ external.key в формате PEM.

2. В веб-интерфейсе KUMA перейдите в раздел Параметры → Общие → Параметры Ядра. В блоке параметров Внешняя TLS-пара нажмите Загрузить сертификат и Загрузить ключ и загрузите external.cert и незашифрованный external.key в формате PEM.
3. Перезапустите KUMA:

   systemctl restart kuma-core

4. Обновите страницу или перезапустите браузер, с помощью которого вы работаете в веб-интерфейсе KUMA.

Сертификат и ключ вашей компании заменены.

[Topic 255123]

Синхронизация времени на серверах

Чтобы настроить синхронизацию времени на серверах:

1. Установите chrony с помощью следующей команды:

   sudo apt install chrony

2. Настройте синхронизацию системного времени с NTP-сервером:
   1. Убедитесь, что виртуальная машина имеет доступ в интернет.

      Если доступ есть, вы можете перейти к шагу b.

      Если доступ отсутствует, отредактируйте файл /etc/chrony.conf, заменив значение 2.pool.ntp.org на имя или IP-адрес внутреннего NTP-сервера вашей организации.

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

      sudo systemctl enable --now chronyd

   3. Через несколько секунд выполните следующую команду:

      sudo timedatectl | grep 'System clock synchronized'

      Если системное время синхронизировано верно, вывод будет содержать строку System clock synchronized: yes.

Синхронизация настроена.

[Topic 255188]

О файле инвентаря

Установка, обновление и удаление компонентов KUMA производится из папки с распакованным установщиком kuma-ansible-installer с помощью инструмента Ansible и созданного вами файла инвентаря. Вы можете указать значения параметров конфигурации KUMA в файле инвентаря, а установщик использует эти значения при развертывании, обновлении и удалении программы. Файл инвентаря имеет формат YAML.

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

• single.inventory.yml.template – используется для установки KUMA на одном сервере. Содержит минимальный набор параметров, оптимизированный для установки на одном устройстве, без использования кластера Kubernetes.
• distributed.inventory.yml.template – используется для первоначальной распределенной установки KUMA без использования кластера Kubernetes, расширения установки "все в одном" до распределенной и для обновления KUMA.
• expand.inventory.yml.template – используется в ряде сценариев изменения конфигурации: для добавления серверов коллекторов и серверов корреляторов, для расширения существующего кластера хранения и добавления нового кластера хранения. Если вы используете этот файл инвентаря для изменения конфигурации, установщик не останавливает сервисы во всей инфраструктуре. Установщик может останавливать только те сервисы, которые размещены на хостах, перечисленных в файле инвентаря expand.inventory.yml, если вы повторно используете файл инвентаря.
• k0s.inventory.yml.template – используется для установки или переноса KUMA в кластер Kubernetes.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

[Topic 244406]

Параметры конфигурации KUMA в файле инвентаря

Файл инвентаря может содержать следующие блоки:

• all
• kuma
• kuma_k0s

Для каждого хоста вам нужно указать FQDN в формате <имя хоста>.<домен> и при необходимости IPv4-адрес или IPv6-адрес. Имя домена Ядра KUMA и его поддомены не должны начинаться с цифры.

Блок all

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

Пример переопределения переменных в файле инвентаря

В таблице ниже приведен список возможных переменных в разделе vars и их описание.

Список возможных переменных в разделе vars

Блок kuma

В этом блоке вы можете указать параметры компонентов KUMA, развернутых вне кластера Kubernetes. Блок kuma может содержать следующие разделы:

• vars – переменные, которые распространяются на все хосты, указанные в блоке kuma.
• children – группы параметров компонентов:
  • kuma_core – параметры Ядра KUMA. Вы можете указать только один хост и следующие параметры ротации журнала базы данных MongoDB для хоста:
    • mongo_log_archives_number – количество предыдущих журналов, которые сохраняются при ротации журнала базы данных MongoDB.
    • mongo_log_file_size – размер журнала базы данных MongoDB в гигабайтах, при котором начинается ротация. Если журнал базы данных MongoDB не превышает указанный размер, ротации не происходит.
    • mongo_log_frequency_rotation – интервал проверки размера журнала базы данных MongoDB для ротации. Возможные значения:
      • hourly – размер журнала базы данных MongoDB проверяется каждый час.
      • daily – размер журнала базы данных MongoDB проверяется каждый день.
      • weekly – размер журнала базы данных MongoDB проверяется каждую неделю.

    Журнал базы данных MongoDB содержится в директории /opt/kaspersky/kuma/mongodb/log.

    • raft_node_addr – FQDN, на котором raft будет слушать сигналы от других узлов. Значение параметра следует указывать в следующем формате: <FQDN хоста>:<порт>. Если значение параметра не указано явно, то в качестве <FQDN хоста> по умолчанию принимается FQDN, где разворачивается Ядро KUMA, а <порт> - 7209. Вы можете указать произвольный адрес, чтобы адаптировать Ядро KUMA под специфику своей инфраструктуры.
  • kuma_collector – параметры коллекторов KUMA. Вы можете указать несколько хостов.
  • kuma_correlator – параметры корреляторов KUMA. Вы можете указать несколько хостов.
  • kuma_storage – параметры узлов хранилища KUMA. Вы можете указать несколько хостов, а также идентификаторы шарда, реплики и кипера для хостов с помощью следующих параметров:
    • shard – идентификатор шарда.
    • replica – идентификатор реплики.
    • keeper – идентификатор кипера.

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

Блок kuma_k0s

В этом блоке вы можете указать параметры кластера Kubernetes, использование которого обеспечивает отказоустойчивость KUMA. Этот блок указан только в файле инвентаря, основанном на шаблоне файла инвентаря k0s.inventory.yml.template.

Для тестовой и демонстрационной установки в окружениях с ограниченными вычислительными ресурсами вам нужно указать переменную low_resources: true в блоке all. В этом случае минимальный объем директории для установки ядра KUMA будет снижен до 4 ГБ и ограничения для других вычислительных ресурсов не будут указаны.

Для каждого хоста в блоке kuma_k0s должен быть указан уникальный FQDN и IP-адрес с помощью переменной ansible_host, кроме хоста в разделе kuma_lb. Для хоста в разделе kuma_lb должен быть указан только FQDN. Хосты в группах не должны повторяться.

Для демонстрационной установки допустимо совместить контроллер с рабочим узлом. Такая конфигурация не обеспечивает отказоустойчивости Ядра KUMA и служит для демонстрации возможностей или проверки программной среды.
Минимальная конфигурация для обеспечения отказоустойчивости составляет 3 контроллера, 2 рабочих узла и 1 балансировщик нагрузки nginx. Для промышленной эксплуатации рекомендуется использовать отдельные рабочие узлы и контроллеры. Если контроллер кластера находится под рабочей нагрузкой и под (англ. pod) с Ядром KUMA размещается на контроллере, выключение контроллера приведет к полной потере доступа к Ядру KUMA.

Блок kuma_k0s может содержать следующие разделы:

• vars – переменные, которые распространяются на все хосты, указанные в блоке kuma.
• сhildren – параметры кластера Kubernetes, использование которого обеспечивает отказоустойчивость KUMA.

В таблице ниже приведен список возможных переменных в разделе vars и их описание.

Список возможных переменных в разделе vars

[Topic 217908]

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

Чтобы установить компоненты KUMA на одном сервере, выполните следующие шаги:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке KUMA.
2. Подготовьте файл инвентаря single.inventory.yml.

   Используйте шаблон файла инвентаря single.yml.template, который входит в поставку, чтобы создать файл инвентаря single.inventory.yml и описать в нем сетевую структуру компонентов программы. С помощью single.inventory.yml установщик развернет KUMA.

3. Установите программу.

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

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

[Topic 222158]

Подготовка файла инвентаря single.inventory.yml

Установка, обновление и удаление компонентов KUMA производится из папки с распакованным установщиком с помощью инструмента Ansible и созданного пользователем файла инвентаря в формате YML с перечнем хостов компонентов KUMA и других параметров. Если вы хотите установить все компоненты KUMA на одном сервере, следует указать в файле инвентаря один и тот же хост для всех компонентов.

Чтобы создать файл инвентаря для установки на одном сервере:

1. Скопируйте архив с установщиком kuma-ansible-installer-<номер версии>.tar.gz на сервер и распакуйте его с помощью следующей команды (потребуется около 2 ГБ дискового пространства):

   sudo tar -xpf kuma-ansible-installer-<номер версии>.tar.gz

2. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer

3. Скопируйте шаблон single.inventory.yml.template и создайте файл инвентаря с именем single.inventory.yml:

   cp single.inventory.yml.template single.inventory.yml

4. Отредактируйте параметры файла инвентаря single.inventory.yml.

   Если вы хотите, чтобы при установке были созданы предустановленные сервисы, присвойте параметру deploy_example_services значение true.

   deploy_example_services: true

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

5. Замените в файле инвентаря все строки kuma.example.com на имя хоста, на который следует установить компоненты KUMA.

Файл инвентаря создан. С его помощью можно установить KUMA на одном сервере.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Пример файла инвентаря для установки на одном сервере

[Topic 222159]

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

Вы можете установить все компоненты KUMA на одном сервере с помощью инструмента Ansible и файла инвентаря single.inventory.yml.

Чтобы установить KUMA на одном сервере:

1. Скачайте на сервер дистрибутив KUMA kuma-ansible-installer-<номер сборки>.tar.gz и распакуйте его. Архив распаковывается в папку kuma-ansibleinstaller.
2. Войдите в папку с распакованным установщиком.
3. В зависимости от типа активации лицензии, который вы планируете использовать, выберите один из вариантов:
   • Если вы планируете использовать активацию лицензии файлом, поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

     Файл ключа должен иметь название license.key.

     sudo cp <файл ключа>.key <папка установщика>/roles/kuma/files/license.key

   • Если вы планируете использовать активацию с помощью лицензионного кода, переходите к следующему пункту инструкции.

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

4. Запустите установку компонентов с использованием подготовленного файла инвентаря single.inventory.yml с помощью следующей команды:

   sudo ./install.sh single.inventory.yml

5. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

   В зависимости от типа активации лицензии результатом запуска установщика будет один из следующих вариантов:

   • Если вы планируете использовать активацию лицензии файлом и поместили файл с лицензионным ключом в папку <папка установщика>/roles/kuma/files/, в результате запуска установщика с инвентарем single.inventory.yml будет установлено Ядро KUMA, все заданные в файле инвентаря сервисы и OOTB-ресурсы. Если в инвентаре был задан параметр example_services=true, демонстрационные сервисы будут установлены.
   • Если вы планируете использовать активацию с помощью лицензионного кода, или планируете предоставить лицензионный файл позднее, в результате запуска установщика с инвентарем single.inventory.yml будет установлено только Ядро KUMA.

     Чтобы установить сервисы, в консоли командной строки укажите лицензионный код. Затем запустите установщик postinstall.sh с файлом инвентаря single.inventory.yml.

     sudo ./postinstall.sh single.inventory.yml

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

6. По окончании установки войдите в веб-интерфейс KUMA и в строке браузера введите адрес веб-интерфейса KUMA, а затем на странице входа введите учетные данные.

   Адрес веб-интерфейса KUMA – https://<FQDN хоста, на котором установлена KUMA>:7220.

   Учетные данные для входа по умолчанию:
   - логин – admin
   - пароль – mustB3Ch@ng3d!

   После первого входа измените пароль учетной записи admin

Все компоненты KUMA установлены и выполнен вход в веб-интерфейс.

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

Установку можно расширить до распределенной.

[Topic 217917]

Распределенная установка

Распределенная установка KUMA происходит в несколько этапов:

1. Проверка соблюдения аппаратных и программных требований, а также требований к установке KUMA.
2. Подготовка контрольной машины.

   Контрольная машина используется в процессе установки программы: на ней распаковывается и запускаются файлы установщика.

3. Подготовка целевых машин.

   На целевые машины устанавливаются компоненты программы.

4. Подготовка файла инвентаря distributed.inventory.yml.

   Создайте файл инвентаря с описанием сетевой структуры компонентов программы. С помощью этого файла инвентаря установщик развернет KUMA.

5. Установка программы.

   Установите программу и выполните вход в веб-интерфейс.

6. Создание сервисов.

   Создайте клиентскую часть сервисов в веб-интерфейсе KUMA и установите серверную часть сервисов на целевых машинах.

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

   При развертывании нескольких сервисов KUMA на одном хосте в процессе установки требуется указать уникальные порты для каждого сервиса с помощью параметров --api.port <порт>.

При необходимости вы можете изменить сертификат веб-консоли KUMA на сертификат своей компании.

[Topic 222083]

Подготовка контрольной машины

Чтобы подготовить контрольную машину для установки KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке программы.
2. Сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин, выполнив следующую команду:

   sudo ssh-keygen -f /root/.ssh/id_rsa -N "" -C kuma-ansible-installer

   Если на контрольной машине заблокирован доступ root по SSH, сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин с помощью пользователя из группы sudo:

   Если у пользователя нет прав sudo, добавьте пользователя в группу sudo:

   usermod -aG sudo user

   ssh-keygen -f /home/<имя пользователя из группы sudo>/.ssh/id_rsa -N "" -C kuma-ansible-installer

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

3. Убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   sudo ssh-copy-id -i /root/.ssh/id_rsa root@<имя хоста контрольной машины>

   Если на контрольной машине заблокирован доступ root по SSH и вы хотите использовать ключ SSH из домашней директории пользователя из группы sudo, убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   ssh-copy-id -i /home/<имя пользователя из группы sudo>/.ssh/id_rsa <имя пользователя из группы sudo>@<имя хоста контрольной машины>

4. Скопируйте архив с установщиком kuma-ansible-installer-<version>.tar.gz на контрольную машину и распакуйте его с помощью следующей команды (потребуется около 2 ГБ дискового пространства):

   sudo tar -xpf kuma-ansible-installer-<номер версии>.tar.gz

Контрольная машина готова для установки KUMA.

[Topic 217955]

Подготовка целевой машины

Чтобы подготовить целевую машину для установки компонентов KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке.
2. Установите имя хоста. Мы рекомендуем указывать FQDN. Например: kuma1.example.com.

   Не следует изменять имя хоста KUMA после установки: это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами программы.

3. Зарегистрируйте целевую машину в DNS-зоне вашей организации для преобразования имен хостов в IP-адреса.

   Если в вашей организации не используется DNS-сервер, вы можете использовать для преобразования имен файл /etc/hosts. Содержимое файлов можно автоматически создать для каждой целевой машины при установке KUMA.

4. Чтобы получить имя хоста, которое потребуется указать при установке KUMA, выполните следующую команду и запишите результат:

   hostname -f

   Целевая машина должна быть доступна по этому имени для контрольной машины.

Целевая машина готова для установки компонентов KUMA.

[Topic 222085]

Подготовка файла инвентаря distributed.inventory.yml

Чтобы создать файл инвентаря distributed.inventory.yml:

1. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer

2. Скопируйте шаблон distributed.inventory.yml.template и создайте файл инвентаря с именем distributed.inventory.yml:

   cp distributed.inventory.yml.template distributed.inventory.yml

3. Отредактируйте параметры файла инвентаря distributed.inventory.yml.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Пример файла инвентаря для Распределенной схемы установки

[Topic 217914]

Установка программы в распределенной конфигурации

Установка KUMA производится помощью инструмента Ansible и YML-файла инвентаря. Установка производится с контрольной машины, при этом все компоненты KUMA устанавливаются на целевых машинах.

Чтобы установить KUMA:

1. На контрольной машине войдите в папку с распакованным установщиком.

   cd kuma-ansible-installer

2. В зависимости от типа активации лицензии, который вы планируете использовать, выберите один из вариантов:
   • Если вы планируете использовать активацию лицензии файлом, поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

     Файл ключа должен иметь название license.key.

     sudo cp <файл ключа>.key <папка установщика>/roles/kuma/files/license.key

   • Если вы планируете использовать активацию с помощью лицензионного кода, переходите к следующему пункту инструкции.
3. Запустите установку компонентов с использованием подготовленного файла инвентаря distributed.inventory.yml, находясь в папке с распакованным установщиком:

   sudo ./install.sh distributed.inventory.yml

4. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

   В зависимости от типа активации лицензии результатом запуска установщика будет один из следующих вариантов:

   • Если вы планируете использовать активацию лицензии файлом и поместили файл с лицензионным ключом в папку <папка установщика>/roles/kuma/files/, в результате запуска установщика с файлом инвентаря distributed.inventory.yml будет установлено Ядро KUMA, все заданные в файле инвентаря сервисы и OOTB-ресурсы.
   • Если вы планируете использовать активацию с помощью лицензионного кода, или планируете предоставить лицензионный файл позднее, в результате запуска установщика с файлом инвентаря distributed.inventory.yml будет установлено только Ядро KUMA.

     Чтобы установить сервисы, в консоли командной строки укажите лицензионный код. Затем запустите установщик postinstall.sh с файлом инвентаря distributed.inventory.yml.

     sudo ./postinstall.sh distributed.inventory.yml

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

5. По окончании установки войдите в веб-интерфейс KUMA и в строке браузера введите адрес веб-интерфейса KUMA, а затем на странице входа введите учетные данные.

   Адрес веб-интерфейса KUMA – https://<FQDN хоста, на котором установлена KUMA>:7220.

   Учетные данные для входа по умолчанию:
   - логин – admin
   - пароль – mustB3Ch@ng3d!

   После первого входа измените пароль учетной записи admin

Все компоненты KUMA установлены и выполнен вход в веб-интерфейс.

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

[Topic 244396]

Распределенная установка в отказоустойчивой конфигурации

Вы можете обеспечить отказоустойчивость KUMA путем развертывания Ядра KUMA в кластере Kubernetes, а также использования внешнего балансировщика TCP-трафика.

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-<номер сборки>.tar.gz и подготовленный вами файл инвентаря k0s.inventory.yml, в котором вы определите конфигурацию кластера. При новой установке в отказоустойчивой конфигурации всегда импортируются ресурсы OOTB. Вы можете выполнить установку с развертыванием демонстрационных сервисов. Для этого нужно в файле инвентаря указать параметр deploy_example_services: true.

Поместить Ядро KUMA в кластер Kubernetes можно следующими способами:

• Установить KUMA в кластере Kubernetes с нуля.
• Перенести Ядро существующей установки KUMA в кластер Kubernetes.

Минимальная конфигурация

В Kubernetes существует 2 роли узлов:

• контроллеры (control-plane) – узлы с этой ролью управляют кластером, хранят метаданные и распределяют рабочую нагрузку.
• рабочие (worker) – узлы с этой ролью несут полезную рабочую нагрузку, то есть размещают процессы KUMA.

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

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

Не следует использовать балансировщик в качестве контрольной машины для запуска установщика KUMA.

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

В случае демонстрационной установки KUMA допустимо совмещать роли контроллера и рабочего узла. Однако при расширении установки до распределенной необходимо переустановить кластер Kubernetes целиком, выделив 3 отдельных узла с ролью контроллера и как минимум 2 узла с ролью рабочего узла. Обновление KUMA до следующих версий недоступно при наличии узлов, совмещающих роли контроллера и рабочего узла.

[Topic 244399]

Дополнительные требования при развертывании Ядра в Kubernetes

Если вы планируете защитить сетевую инфраструктуру KUMA с помощью программы Kaspersky Endpoint Security for Linux, вам нужно сначала установить KUMA в кластере Kubernetes и только потом разворачивать Kaspersky Endpoint Security for Linux. При обновлении или удалении KUMA вам нужно предварительно остановить Kaspersky Endpoint Security for Linux с помощью команды:

systemctl stop kesl

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

• Общие требования к установке программы.
• На хостах, которые планируются под узлы кластера Kubernetes, не используются IP-адреса из следующих блоков Kubernetes:
  • serviceCIDR: 10.96.0.0/12;
  • podCIDR: 10.244.0.0/16.

  Для IP-адресов из блоков исключен трафик на прокси-серверы.

• Каждый хост имеет уникальный идентификатор (/etc/machine-id).
• На хостах установлен и включен инструмент для управления межсетевым экраном firewalld или uwf для внесения правил в iptables.
• Установлен и настроен балансировщик нагрузки nginx (дополнительные сведения см. в документации балансировщика нагрузки nginx). Вы можете установить балансировщик нагрузки nginx с помощью одной из следующих команд:
  • sudo yum install nginx – для операционной системы Oracle Linux.
  • sudo apt install nginx-full – для операционной системы Astra Linux.
  • sudo apt install nginx libnginx-mod-stream – для операционной системы Ubuntu.
  • sudo yum install nginx nginx-all-modules – для операционной системы РЕД ОС.

  Если вы хотите, чтобы балансировщик нагрузки nginx был настроен автоматически в процессе установки KUMA, установите балансировщик нагрузки nginx и откройте к нему доступ по SSH так же, как для хостов кластера Kubernetes.

  Пример автоматически созданной конфигурации nginx

  Установщик создает файл конфигурации /etc/nginx/kuma_nginx_lb.conf, пример содержимого которого приведен ниже. Разделы upstream формируются динамически и содержат IP-адреса контроллеров кластера Kubernetes (в примере – 10.0.0.2-4 в разделах upstream kubeAPI_backend, upstream konnectivity_backend, controllerJoinAPI_backend) и IP-адреса рабочих узлов (в примере 10.0.1.2-3), для которых в файле инвентаря в переменной extra_args содержится значение "kaspersky.com/kuma-ingress=true".

  В конец файла /etc/nginx/nginx.conf дописывается строка "include /etc/nginx/kuma_nginx_lb.conf;", позволяющая применить сформированный файл конфигурации. При большом количестве активных сервисов и пользователей может понадобиться увеличить лимит открытых файлов в параметрах nginx.conf.

  Пример файла конфигурации:

  # Ansible managed

  #

  # LB KUMA cluster

  #

  stream {

      server {

          listen          6443;

          proxy_pass      kubeAPI_backend;

      }

      server {

          listen          8132;

          proxy_pass      konnectivity_backend;

      }

      server {

          listen          9443;

          proxy_pass      controllerJoinAPI_backend;

      }

      server {

          listen          7209;

          proxy_pass      kuma-core-hierarchy_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7210;

          proxy_pass      kuma-core-services_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7220;

          proxy_pass      kuma-core-ui_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7222;

          proxy_pass      kuma-core-cybertrace_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7223;

          proxy_pass      kuma-core-rest_backend;

          proxy_timeout   86400s;

      }

      upstream kubeAPI_backend {

          server 10.0.0.2:6443;

          server 10.0.0.3:6443;

          server 10.0.0.4:6443;

      }

      upstream konnectivity_backend {

          server 10.0.0.2:8132;

          server 10.0.0.3:8132;

          server 10.0.0.4:8132;

      }

      upstream controllerJoinAPI_backend {

          server 10.0.0.2:9443;

          server 10.0.0.3:9443;

          server 10.0.0.4:9443;

      }

      upstream kuma-core-hierarchy_backend {

          server 10.0.1.2:7209;

          server 10.0.1.3:7209;

      }

      upstream kuma-core-services_backend {

          server 10.0.1.2:7210;

          server 10.0.1.3:7210;

      }

      upstream kuma-core-ui_backend {

          server 10.0.1.2:7220;

          server 10.0.1.3:7220;

      }

      upstream kuma-core-cybertrace_backend {

          server 10.0.1.2:7222;

          server 10.0.1.3:7222;

      }

      upstream kuma-core-rest_backend {

          server 10.0.1.2:7223;

          server 10.0.1.3:7223;

  }

   worker_rlimit_nofile 1000000;

  events {

  worker_connections 20000;

  }

  # worker_rlimit_nofile – ограничение на максимальное число открытых файлов (RLIMIT_NOFILE) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

  # worker_connections – максимальное число соединений, которые одновременно может открыть рабочий процесс.

• На сервере балансировщика нагрузки nginx добавлен ключ доступа с устройства, с которого осуществляется установка KUMA.
• На сервере балансировщика нагрузки nginx в операционной системе не включен модуль SELinux.
• На хостах установлены пакеты tar, systemctl.