[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 появились следующие возможности и доработки:

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

• Добавлена поддержка работы KUMA на следующих операционных системах:
  • Ubuntu 22.04 LTS.
  • Oracle Linux 9.4.
  • Astra Linux 1.7.5.
  • РЕД ОС 7, 8.
• Начиная с версии 3.2.x, обновлены требования к сложности пароля. Пароль должен быть длиной не менее 16 символов, содержать не менее одной буквы и цифры, и должен содержать не более двух одинаковых символов подряд. Новые требования применяются только к новым установкам. В существующих установках KUMA требования применяются только к новым пользователям. Для существующих пользователей требования будут применены только при смене пароля.
• В веб-консоли KUMA в разделе Активные сервисы сервис Ядра отображается как core-1. В операционной системе сервера Ядра сервис kuma-core.service теперь называется kuma-core 00000000-0000-0000-0000-000000000000.service.
• Добавлен сервис Маршрутизатор событий. Этот сервис позволяет принимать события от коллекторов и направлять события в заданные точки назначения в соответствии с настроенными на сервисе фильтрами. Использование такого промежуточного сервиса позволяет эффективно распределять нагрузку на каналы связи и использовать каналы связи с невысокой пропускной способностью. Например, как показано на схеме в раскрывающемся блоке, вместо нескольких потоков событий от коллектора 5 до точек назначения, вы можете отправлять события одним потоком: на схеме коллектор 1 + коллектор 2 + коллектор 3 отправляют события в маршрутизатор локального офиса, затем в маршрутизатор дата-центра, и в нем уже происходит передача событий в заданные точки назначения.

  Схема отправки событий с использованием маршрутизатора событий и без использования маршрутизатора

  

• Интеграция с НКЦКИ: обновлен список полей и типы инцидентов, добавлена возможность предоставления информации об утечке персональных данных. Экспортированые инциденты со старым типом, который больше не поддерживается, будут отображаться корректно.
• Выполнение группировки по произвольным полям, использование функций округления времени из интерфейса работы с событиями.

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

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

• Добавлена возможность преобразования исходного поля с использованием функции вычисления информационной энтропии. В коллекторе можно настроить правило обогащения для исходного поля типа event, выбрать тип преобразования entropy и указать целевое поле типа float, куда KUMA поместит результат преобразования. Результатом преобразования будет число. Показатель вычисления информационной энтропии позволяет выявлять DNS-туннели, компрометацию паролей, например, когда пользователь ввел пароль вместо логина и этот пароль записывается в журнал в открытом виде. Обычно логин содержит буквы, и функция преобразования вычислит информационную энтропию и запишет результат, например, 2,5416789. Если пользователь по ошибке ввел пароль в поле для логина и таким образом пароль оказался в журнале в открытом виде, KUMA вычислит информационную энтропию и запишет результат 4 - показатель энтропии будет выше, поскольку пароль содержит буквы, цифры и символы. Таким образом, можно искать события, где у имени пользователя показатель энтропии больше 3 и можно настроить правило реагирования "Требуется смена пароля". После настройки в коллекторе обогащения следует обновить параметры, чтобы применить изменения.
• Доступен поиск событий одновременно по нескольким выбранным хранилищам с помощью простого запроса. Например, таким образом вы можете выполнять поиск событий, чтобы определить, где учетная запись блокируется или на какой URL с каких IP-адресов был выполнен вход.

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

• Покрытие матрицы правил на MITRE ATT&CK.

  Разрабатывая детектирующую логику, аналитик может ориентироваться на соответствие контента реальным угрозам. С помощью матриц MITRE ATT&CK можно определить, к каким техникам уязвимы ресурсы организации. В помощь аналитикам создан механизм, который позволяет визуализировать покрытие матрицы MITRE ATT&CK разработанными правилами и таким образом оценить уровень защищенности.

  Функционал позволяет:

  • Импортировать в KUMA актуальный файл с перечнем техник и тактик.
  • Перечислить в свойствах правил техники и тактики, выявляемые этим правилом.
  • Экспортировать из KUMA список правил, размеченных по матрице в MITRE ATT&CK Navigator (можно указать отдельные папки с правилами).

  Файл со списком размеченных правил визуализируется в MITRE ATT&CK Navigator.

• Чтение файлов агентом Windows.

  Агент KUMA, устанавливаемый на системах c ОС Windows, теперь может читать текстовые файлы и передавать данные в коллектор KUMA. Один агент, установленный на сервере с ОС Windows, может передавать данные как из журналов Windows, так и из текстовых файлов с журналами. Например, больше не потребуется использовать сетевые папки для получения журналов транспорта Exchange Server, или журналов IIS.

• Получение журналов DNS Analytics с использованием коннектора etw.

  Использование Windows агентом нового транспорта ETW (сервис Event Tracing for Windows) для чтения подписки DNS Analytics обеспечивает получение расширенного журнала DNS, событий диагностики, аналитических данных о работе DNS-сервера – больше информации, чем в журнале отладки DNS, и с меньшим влиянием на производительность DNS-сервера.

  Рекомендуемая конфигурация для чтения журналов ETW:

  • Если на сервере, который является источником журналов DNS Analytics, не установлен никакой агент, создать новый коллектор и новый агент:
    1. Создать коннектор etw. Агент будет создан автоматически.
    2. Создать отдельный коллектор для журналов ETW. В мастере установки коллектора указать коннектор etw, указать нормализатор [OOTB] Microsoft DNS ETW logs json.
    3. Установить коллектор и агент.
  • Если на сервере, который является источником журналов DNS Analytics, уже установлен агент WEC, создать коллектор и отредактировать параметры созданного вручную агента:
    1. Создать коллектор с транспортом http и разделителем \0, и указать нормализатор [OOTB] Microsoft DNS ETW logs json.
    2. Сохранить параметры коллектора.
    3. Установить коллектор.
    4. В существующем агенте WEC добавить дополнительную конфигурацию ETW и в ней указать:
       • коннектор etw
       • в качестве точки назначения указать созданный в пункте a. коллектор
       • выбрать тип точки назначения http и разделитель \0.
    5. Сохранить параметры агента и запустить агент.
• Обогащение CyberTrace по API.

  Cybertrace-http — новый тип потокового обогащения событий в CyberTrace, который позволяет отправлять большое количество событий одним запросом на API-интерфейс CyberTrace. Мы рекомендуем применять этот тип обогащения в системах с большим потоком событий. Производительность cybertrace-http значительно превосходит показатели прежнего типа cybertrace, который по-прежнему доступен в KUMA для обеспечения обратной совместимости.

• Активация с помощью кода.

  Реализована возможность активировать KUMA при помощи кода активации. Такой метод позволяет не беспокоиться об импорте в KUMA новых ключей при продлении или при изменении состава лицензии. Для активации с помощью кода требуется доступ сервера Ядра к нескольким серверам в интернете. При этом вы можете использовать прежний метод активации - с использованием файла лицензии.

• Оптимизирована передача событий в формате CEF. Отправляемые события содержат заголовок CEF и только непустые поля. При передаче событий в сторонние системы в формате CEF поля, не содержащие данных, не передаются.
• Добавлена возможность получения событий из ClickHouse с помощью коннектора SQL. В параметрах коннектора SQL вы можете выбрать Тип базы данных для соединения. При этом в поле URL будет автоматически указан префикс, соответствующий протоколу взаимодействия.
• В коннекторы file, 1c-log и 1c-xml добавлен параметр Интервал запросов, мс, отвечающий за интервал чтения файлов из директории. Настройка этого параметра позволяет снизить потребление CPU и RAM.
• Параметр airgap исключен из файла инвентаря. Если в вашем файле инвентаря остался параметр airgap, установщик его проигнорирует при выполнении установки или обновления.
• Логин и пароль вынесены из секрета типа URL и Proxy. Добавлена возможность преобразования пароля.
• В служебные события о выпадении записи из активного листа и контекстной таблицы добавлены поля, которые содержат не только ключ, но и значение. Поля со значениями дают больше гибкости в написании правил корреляции для обработки таких служебных событий.

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

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

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

• Добавлена возможность мониторинга сервисов.

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

• Обновлен перечень статусов для сервисов: добавлен фиолетовый статус, расширено пременение желтого статуса.
• Теперь вы можете перейти из раздела Состояние источников к событиям выбранного источника событий. Уточняющие условия в строке поискового запроса формируются автоматически после перехода по ссылке. По умолчанию отображаются события за последние 5 минут. При необходимости вы можете изменить интервал и снова выполнить запрос.
• Сбор метрик с агента.

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

• Добавлена поддержка компактной встраиваемой СУБД SQLite версии 3.37.2.
• Добавлен коннектор elastic для получения событий из Elasticsearch версии 7 и 8. Для коннектора добавлен секрет fingerprint.
• Для коннекторов с типами tcp, udp и file добавлены следующие параметры обработки событий auditd:
  • Переключатель Auditd позволяет группировать полученные от коннектора строки событий auditd в одно событие auditd.
  • Поле TTL буфера событий позволяет указать время жизни буфера для строк событий auditd в миллисекундах.
• Добавлена возможность настраивать список полей для определения источников событий. DeviceProduct, DeviceHostName, DeviceAddress, DeviceProcessName – используемый по умолчанию набор полей для определения источников событий. Теперь перечень полей и их последовательность можно переопределить. Допускается указать максимум 9 полей в значимой для пользователей последовательности. После сохранения изменений в наборе полей ранее определенные источники событий будут удалены из веб-интерфейса KUMA и из базы данных. Сохраняется возможность использовать набор полей для определения источников событий по умолчанию.
• В графический конструктор поисковых запросов для событий добавлен оператор iLike.
• Обновлен перечень методов REST API. Описание методов v2.1 доступно в формате OpenAPI.
• В параметрах коннектора snmp-trap появился дополнительный параметр, позволяющий обозначить OID, являющийся MAC-адресом.
• Установщик KUMA проверяет состояние SELinux.
• Прекращена поддержка создания резервной копии Ядра при помощи утилиты командной строки /opt/kaspersky/kuma/kuma tools backup.
• Прекращена поддержка и поставка устаревших нормализаторов:
  • [Deprecated][OOTB] Microsoft SQL Server xml.
  • [Deprecated][OOTB] Windows Basic.
  • [Deprecated][OOTB] Windows Extended v.0.3.
  • [Deprecated][OOTB] Cisco ASA Extended v 0.1.
  • [Deprecated][OOTB] Cisco Basic.

[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.

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

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

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

Требования к устройствам для установки 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.

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

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

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 for Networks.
  • Создать активы вручную через веб-интерфейс или с помощью 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).

  Это могут быть сертификаты, токены, 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 22.04 LTS.
• РЕД ОС 7.3.4 или 8.

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

  Операционная система РЕД ОС 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 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 – для операционной системы Orcale 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.

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

• Количество ядер CPU (потоков) – 12 или больше.
• ОЗУ – 22528 МБ или больше.
• Объем свободного пространства на диске в разделе /opt/ – 1000 ГБ или больше.
• Если производится первичная установка, в /var/lib/ должно быть не менее 32GB свободного места. Если установка кластера на этот узел ранее уже проводилась, размер требуемого свободного пространства уменьшается на размер директории /var/lib/k0s.

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

Дополнительные требования при установке на операционной системе Astra Linux или Ubuntu

• Установка KUMA в отказоустойчивом варианте поддерживается на операционной системе Astra Linux Special Edition РУСБ.10015-01 (2022-1011SE17MD, оперативное обновление 1.7.2.UU.1). Требуется версия ядра 5.15.0.33 или выше.
• На машинах, предназначенных для развертывания кластера Kubernetes, установлены следующие пакеты:
  • open-iscsi;
  • wireguard;
  • wireguard-tools.

  Вы можете установить пакеты с помощью команды:

  sudo apt install open-iscsi wireguard wireguard-tools

Дополнительные требования при установке на операционной системе Oracle Linux, РЕД ОС и на операционных системах Red Hat Enterprise Linux

На машинах, предназначенных для развертывания кластера Kubernetes, установлены следующие пакеты:

• iscsi-initiator-utils;
• wireguard-tools.

Перед установкой пакетов на операционной системе Oracle Linux вам нужно добавить репозиторий EPEL в качестве источника с помощью одной из следующих команд:

• sudo yum install oracle-epel-release-el8 - для операционной системы Oracle Linux 8.
• sudo yum install oracle-epel-release-el9 - для операционной системы Oracle Linux 9.

Вы можете установить пакеты с помощью команды:

sudo yum install iscsi-initiator-utils wireguard-tools

[Topic 269330]

Установка KUMA в кластере Kubernetes с нуля

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Topic 269332]

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

Чтобы подготовить контрольную машину для установки 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-ha-<номер версии>.tar.gz на контрольную машину и распакуйте его с помощью следующей команды:

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

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

[Topic 269334]

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

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

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

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

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

   Вариант с использованием файла /etc/hosts не применим для развертывания Ядра в Kubernetes.

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

   hostname -f

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

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

[Topic 269310]

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

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

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

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

   cd kuma-ansible-installer-ha

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

   cp k0s.inventory.yml.template k0s.inventory.yml

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

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

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: false

   generate_etc_hosts: false

   deploy_example_services: true

   kuma:

   children:

   kuma_core:

   hosts:

   kuma.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma.example.com:

   kuma_correlator:

   hosts:

   kuma.example.com:

   kuma_storage:

   hosts:

   kuma.example.com:

   shard: 1

   replica: 1

   keeper: 1

   kuma_k0s:

   children:

   kuma_control_plane_master_worker:

   hosts:

   kuma-cpw.example.com:

   ansible_host: 10.0.2.11

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

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

   Пример файла инвентаря для распределенной установки в отказоустойчивой конфигурации с 3 контроллерами, 2 рабочими узлами и 1 балансировщиком

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: false

   generate_etc_hosts: false

   deploy_example_services: false

   kuma:

   children:

   kuma_core:

   hosts:

   kuma-core.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma-collector.example.com:

   kuma_correlator:

   hosts:

   kuma-correlator.example.com:

   kuma_storage:

   hosts:

   kuma-storage-cluster1.server1.example.com

   kuma-storage-cluster1.server2.example.com

   kuma-storage-cluster1.server3.example.com

   kuma-storage-cluster1.server4.example.com

   kuma-storage-cluster1.server5.example.com

   kuma-storage-cluster1.server6.example.com

   kuma-storage-cluster1.server7.example.com

   kuma_k0s:

   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_cp2.example.com:

   ansible_host: 10.0.1.11

   kuma_cp3.example.com:

   ansible_host: 10.0.1.12

   kuma_control_plane_worker:

   kuma_worker:

   hosts:

   kuma-w1.example.com:

   ansible_host: 10.0.2.11

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

   kuma-w2.example.com:

   ansible_host: 10.0.2.12

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

   Для такой конфигурации следует указать параметры need_transfer: false, deploy_example_services: false, в разделе kuma_storage перечислить серверы для кластера хранения. Роли шарда, реплики и кипера вы сможете назначить указанным в инвентаре серверам в веб-интерфейсе KUMA после завершения установки.

   Пример файла инвентаря для переноса Ядра в кластер Kubernetes из распределенной установки для обеспечения отказоустойчивости

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: true

   generate_etc_hosts: false

   deploy_example_services: false

   kuma:

   children:

   kuma_core:

   hosts:

   kuma-core.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma-collector.example.com:

   kuma_correlator:

   hosts:

   kuma-correlator.example.com:

   kuma_storage:

   hosts:

   kuma-storage-cluster1.server1.example.com

   kuma-storage-cluster1.server2.example.com

   kuma-storage-cluster1.server3.example.com

   kuma-storage-cluster1.server4.example.com

   kuma-storage-cluster1.server5.example.com

   kuma-storage-cluster1.server6.example.com

   kuma-storage-cluster1.server7.example.com

   kuma_k0s:

   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_cp2.example.com:

   ansible_host: 10.0.1.11

   kuma_cp3.example.com:

   ansible_host: 10.0.1.12

   kuma_control_plane_worker:

   kuma_worker:

   hosts:

   kuma-w1.example.com:

   ansible_host: 10.0.2.11

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

   kuma-w2.example.com:

   ansible_host: 10.0.2.12

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

   В файле инвентаря k0s.inventory.yml в разделах kuma_core, kuma_ collector, kuma_correlator, kuma_storage укажите те же хосты, которые использовались в файле distributed.inventory.yml при обновлении KUMA с версии 2.1.3 до версии 3.0.3, и затем до версии 3.2, или при новой установке программы. В файле инвентаря k0s.inventory.yml необходимо указать параметры deploy_to_k8s: true, need_transfer:true, deploy_example_services: false.