Развертывание Open Single Management Platform

Следуя этому сценарию, вы можете подготовить инфраструктуру к развертыванию Open Single Management Platform и всех необходимых компонентов, подготовить конфигурационный файл, содержащий параметры установки, и развернуть решение с помощью утилиты Kaspersky Deployment Toolkit (далее также KDT).

Прежде чем приступить к развертыванию Open Single Management Platform и компонентов Open Single Management Platform, рекомендуется прочитать Руководство по усилению защиты.

Сценарий развертывания состоит из следующих этапов:

1. Выбор варианта развертывания Open Single Management Platform

   Выберите конфигурацию Open Single Management Platform, наиболее подходящую для вашей организации. Доступно развертывание на нескольких узлах и на одном узле:

2. Загрузка дистрибутива с компонентами Open Single Management Platform

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

   • Транспортный архив, который содержит компоненты Open Single Management Platform и Лицензионные соглашения Open Single Management Platform и KDT.
   • Архив с утилитой KDT, а также шаблоны конфигурационного файла и файл инвентаря KUMA.
3. Установка системы управления базами данных (СУБД)

   Для развертывания на нескольких узлах вручную установите СУБД на отдельном сервере за пределами кластера Kubernetes.

   Для развертывания на одном узле вручную установите СУБД на целевом устройстве перед развертыванием Open Single Management Platform. В этом случае компоненты СУБД и Open Single Management Platform устанавливаются на одном и том же целевом устройстве, но СУБД не будет включена в кластер Kubernetes.

   Если вы выполняете демонстрационное развертывание и хотите установить СУБД внутри кластера, пропустите этот шаг. KDT установит СУБД во время развертывания Open Single Management Platform.

4. Подготовка устройства администратора и целевых устройств

   С учетом выбранной схемы развертывания определите количество целевых устройств, на которых вы будете разворачивать кластер Kubernetes и компоненты Open Single Management Platform, входящие в этот кластер. Подготовьте выбранные устройства администратора и целевые машины к развертыванию Open Single Management Platform.

   Инструкции:

   • Развертывание на нескольких узлах: подготовка устройства администратора и целевых устройств.
   • Развертывание на одном узле: подготовка устройства администратора и целевых устройств.
5. Подготовка устройств KUMA

   Подготовьте целевые устройства KUMA для установки сервисов KUMA (коллекторы, корреляторы и хранилища).

   Инструкции: Подготовка устройств к установке сервисов KUMA.

6. Подготовка файла инвентаря KUMA для установки сервисов KUMA

   Подготовьте файл инвентаря KUMA в формате YAML. Файл инвентаря KUMA содержит параметры для установки сервисов KUMA

   Инструкции: Подготовка файла инвентаря KUMA.

7. Подготовка конфигурационного файла

   Подготовьте конфигурационный файл в формате YAML. Конфигурационный файл содержит список целевых устройств для развертывания и набор параметров для установки компонентов Open Single Management Platform.

   Если вы разворачиваете Open Single Management Platform на отдельном узле, используйте конфигурационный файл, содержащий параметры установки, предназначенные для развертывания на одном узле.

   Инструкции:

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

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

   Инструкции: Указание параметров установки с помощью мастера настройки.

8. Развертывание Open Single Management Platform

   Разверните Open Single Management Platform с помощью KDT. KDT автоматически разворачивает кластер Kubernetes, в котором установлены компоненты Open Single Management Platform и другие компоненты инфраструктуры.

   Инструкции: Установка Open Single Management Platform.

9. Установка сервисов KUMA

   Установите сервисы KUMA (коллекторы, корреляторы и хранилища) на подготовленные целевые устройства KUMA, расположенные вне кластера Kubernetes.

   Инструкции: Установка сервисов KUMA.

10. Настройка интеграции с Kaspersky Anti Targeted Attack Platform

    Установите Central Node, чтобы получать телеметрию от Kaspersky Anti Targeted Attack Platform, а затем настройте интеграцию Open Single Management Platform и KATA/KEDR для управления действиями по реагированию на угрозы на активах, подключенных к серверам Kaspersky Endpoint Detection and Response.

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

    Двухуровневая иерархия серверов с установленными компонентами Central Node. Эта иерархия выделяет первичный управляющий сервер (Primary Central Node (PCN)) и вторичные серверы (Secondary Central Nodes (SCN)).

    При настройке серверов Central Node вам нужно указать минимально возможное значение в поле Хранилище, чтобы избежать дублирования данных между базами Open Single Management Platform и KEDR.

Руководство по усилению защиты

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

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

В Руководстве по усилению защиты описаны рекомендации и особенности настройки Open Single Management Platform и его компонентов для снижения рисков его компрометации.

Руководство по усилению защиты содержит следующую информацию:

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

Управление инфраструктурой Open Single Management Platform

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

Управление учетными записями операционной системы

Для работы с кластером Kubernetes с помощью KDT рекомендуется создать отдельного пользователя с минимальными правами. Оптимальным способом является реализация управления учетными записями пользователей операционной системы с помощью LDAP с возможностью отзыва прав пользователей через LDAP. Информацию о конкретной реализации отзыва прав и блокировки пользователей см. в руководстве пользователя/администратора в вашем решении LDAP. Рекомендуется использовать пароль длиной не менее 18 символов или парольную фразу, содержащую не менее 4 слов с любыми разделителями, для аутентификации пользователя. Также можно использовать физические средства аутентификации (например, токен).

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

Рекомендуется не предоставлять права на запуск для директорий .ssh, .kube, .config и .kdt, а также для всех файлов, содержащихся в этих директориях в корневой директории документов пользователя.

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

Рекомендуется использовать минимальный набор приложений, необходимый для работы KDT и Open Single Management Platform. Например, вам не нужно использовать графический пользовательский интерфейс для работы в кластере Kubernetes, поэтому не рекомендуется устанавливать графические пакеты. Если пакеты установлены, рекомендуется удалить эти пакеты, включая графические серверы, такие как Xorg или Wayland.

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

• Для операционных систем с диспетчером пакетов atp:

  /etc/apt/apt.conf.d/50unattended-upgrades

  Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; "${distro_id}ESMApps:${distro_codename}-apps-security"; "${distro_id}ESM:${distro_codename}-infra-security"; };
• Для операционных систем с диспетчером пакетов rp, dnf и yum:

  /etc/dnf/automatic.conf

  [commands] # Какое обновление выполнить: # default = все доступные обновления # security = только обновления безопасности upgrade_type = default # Следует ли скачивать обновления, когда они будут доступны, # dnf-automatic.timer. notifyonly.timer, download.timer и # install.timer отменяют этот параметр. download_updates = yes # Следует ли применять обновления, когда они будут доступны, # dnf-automatic.timer. notifyonly.timer, download.timer и # install.timer отменяют этот параметр. apply_updates = no

Параметры безопасности операционной системы

Параметры безопасности ядра Linux можно включить в файле /etc/sysctl.conf или с помощью команды sysctl. Рекомендуемые параметры безопасности ядра Linux перечислены во фрагменте файла /etc/sysctl.conf:

/etc/sysctl.conf

Рекомендуется ограничить доступ к PID. Это уменьшит вероятность того, что один пользователь будет отслеживать процессы другого пользователя. Вы можете ограничить доступ к PID при монтировании файловой системы /proc, например, добавив следующую строку в файл /etc/fstab:

Если процессы операционной системы управляются с помощью системы systemd, служба systemd-logind по-прежнему может контролировать процессы других пользователей. Для корректной работы пользовательских сессий в системе systemd необходимо создать файл /etc/systemd/system/systemd-logind.service.d/hidepid.conf и добавить в него следующие строки:

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

С помощью команды systemctl mask ctrl-alt-del.target рекомендуется выключить комбинацию клавиш Ctrl+Alt+Del, чтобы предотвратить неожиданную перезагрузку операционной системы.

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

Рекомендуется использовать сетевой экран для ограничения сетевой активности. Об используемых портах и протоколах см. в разделе Порты, используемые Open Single Management Platform.

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

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

• Устройство администратора: ~/kdt
• Целевое устройство: /etc/k0s/, /var/lib/k0s

Также рекомендуется зашифровать эти резервные копии.

Руководства по усилению защиты для различных операционных систем и СУБД

Если вам нужно настроить параметры безопасности вашей операционной системы и программного обеспечения, вы можете использовать рекомендации, предоставленные Center for Internet Security (CIS).

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

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

Безопасность соединения

Строгие параметры TLS

Рекомендуется использовать протокол TLS версии 1.2 или выше и ограничить или запретить использование небезопасных алгоритмов шифрования.

Вы можете настроить протоколы шифрования (TLS), используемые Сервером администрирования. При этом учитывайте, что на момент выпуска определенной версии Open Single Management Platform параметры протокола шифрования по умолчанию настроены так, чтобы обеспечить безопасную передачу данных.

Ограничение доступа к базе данных Open Single Management Platform

Рекомендуется ограничить доступ к базе данных Open Single Management Platform. Например, разрешить доступ только с устройств, на которых установлен Open Single Management Platform. Это позволит снизить вероятность взлома базы данных Open Single Management Platform через известные уязвимости.

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

Учетные записи и авторизация

Использование двухэтапной проверки Open Single Management Platform

Open Single Management Platform обеспечивает двухэтапную проверку для пользователей на основе стандарта RFC 6238 (TOTP: Time-Based One-Time Password Algorithm).

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

Существуют как программные, так и аппаратные аутентификаторы (токены), поддерживающие стандарт RFC 6238. Например, к программным аутентификаторам относятся Google Authenticator, Microsoft Authenticator, FreeOTP.

Категорически не рекомендуется устанавливать приложение для аутентификации на том же устройстве, с которого выполняется подключение к Open Single Management Platform. Например, вы можете установить приложение для аутентификации на мобильном устройстве.

Использование двухфакторной аутентификации операционной системы

Рекомендуется использовать многофакторную аутентификацию (MFA) на устройствах с развернутым Open Single Management Platform с помощью токена, смарт-карты или другим способом (если это возможно).

Запрет на сохранение пароля администратора

При работе с Open Single Management Platform через браузер не рекомендуется сохранять пароль администратора в браузере на устройстве пользователя.

Авторизация внутреннего пользователя

По умолчанию пароль внутренней учетной записи пользователя Open Single Management Platform должен соответствовать следующим требованиям:

• Длина пароля должна быть от 8 до 16 символов.

• Пароль должен содержать символы как минимум трех групп из списка ниже:

  • верхний регистр (A–Z);

  • нижний регистр (a–z);

  • числа (0–9);

  • специальные символы (@ # $ % ^ & * - _ ! + = [ ] { } | : ' , . ? / \ ` ~ " ( ) ;).

• Пароль не должен содержать пробелов, символов Юникода или комбинации "." и "@", когда "." расположена перед "@".

По умолчанию максимальное количество попыток ввода пароля равно 10. Вы можете изменить количество попыток ввода пароля.

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

Ограничение назначения роли Главного администратора

Пользователю назначается роль Главного администратора в списке контроля доступа (ACL) Open Single Management Platform. Не рекомендуется назначать роль Главного администратора большому количеству пользователей.

Настройка прав доступа к функциям приложения

Рекомендуется использовать возможности гибкой настройки прав доступа пользователей и групп пользователей к разным функциям Open Single Management Platform.

Управление доступом на основе ролей позволяет создавать типовые роли пользователей с заранее настроенным набором прав и присваивать эти роли пользователям в зависимости от их служебных обязанностей.

Основные преимущества ролевой модели управления доступом:

• простота администрирования;
• иерархия ролей;
• принцип наименьшей привилегии;
• разделение обязанностей.

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

При настройке ролей требуется уделить особое внимание привилегиям, связанным с изменением состояния защиты устройства с Open Single Management Platform и удаленной установкой стороннего программного обеспечения:

• Управление группами администрирования.
• Операции с Сервером администрирования.
• Удаленная установка.
• Изменение параметров хранения событий и отправки уведомлений.

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

Отдельная учетная запись для удаленной установки приложений

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

Рекомендуется использовать отдельную учетную запись для удаленной установки приложений. Вы можете назначить роль или разрешения отдельной учетной записи.

Регулярный аудит всех пользователей

Рекомендуется проводить регулярный аудит всех пользователей на устройстве, где развернуто приложение Open Single Management Platform. Это позволит реагировать на некоторые типы угроз безопасности, связанные с возможной компрометацией устройства.

Управление защитой Open Single Management Platform

Выбор программного обеспечения защиты Open Single Management Platform

В зависимости от типа развертывания Open Single Management Platform и общей стратегии защиты выберите приложение для защиты устройств с развернутым Open Single Management Platform и устройства администратора.

Если вы разворачиваете Open Single Management Platform на выделенных устройствах, рекомендуется выбрать приложение Kaspersky Endpoint Security для защиты устройств с развернутым Open Single Management Platform и устройства администратора. Это позволит применить все имеющиеся технологии для защиты этих устройств, в том числе модули поведенческого анализа.

Если Open Single Management Platform разворачивается на устройствах, которые уже существуют в инфраструктуре и ранее использовались для выполнения других задач, рекомендуются следующие приложения защиты:

• Kaspersky Industrial CyberSecurity for Nodes. Это приложение рекомендуется устанавливать на устройства, входящие в промышленную сеть. Kaspersky Industrial CyberSecurity for Nodes – это приложение, имеющее сертификаты совместимости с различными производителями промышленного программного обеспечения.
• Рекомендованные приложения безопасности. Если Open Single Management Platform развернут на устройствах с другим программным обеспечением, нужно ознакомиться с рекомендациями производителя программного обеспечения по использованию антивирусных приложений (возможно, уже существуют рекомендации по выбору приложения защиты, и, вероятно, вам потребуется выполнить настройку доверенной зоны).

Модули защиты

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

Настройка сетевого экрана устройств с Open Single Management Platform

На устройствах с развернутым Open Single Management Platform рекомендуется настроить сетевой экран, чтобы ограничить количество устройств, с которых администраторы могут подключаться к Open Single Management Platform через браузер.

По умолчанию

Open Single Management Platform использует порт 443 для входа в систему через браузер. Рекомендуется ограничить число устройств, с которых Open Single Management Platform может управляться по этим портам.

Управление защитой клиентских устройств

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

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

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

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

Правила автоматического перемещения устройств между группами администрирования

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

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

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

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

Требования к безопасности к устройствам с точками распространения и шлюзам соединений

Устройства с установленным Агентом администрирования могут использоваться в качестве точки распространения и выполнять следующие функции:

• Распространять обновления и инсталляционные пакеты, полученные от Open Single Management Platform, на клиентские устройства в группе.
• Выполнять удаленную установку приложений сторонних производителей и приложений "Лаборатории Касперского" на клиентские устройства.
• Опрашивать сеть с целью обнаружения новых устройств и обновления информации об уже известных устройствах. Точка распространения может использовать те же методы обнаружения устройств, что и Open Single Management Platform.

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

• снижение нагрузки на Open Single Management Platform;
• оптимизация трафика;
• предоставление Open Single Management Platform доступа к устройствам в труднодоступных частях сети.

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

Ограничение автоматического назначения точек распространения

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

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

При необходимости вы также можете просмотреть Отчет о работе точек распространения.

Настройка защиты управляемых приложений

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

Рекомендуется создать политику для каждого вида используемого приложения и всех компонентов Open Single Management Platform (Агент администрирования, Kaspersky Endpoint Security для Windows, Kaspersky Endpoint Agent и другие). Эта групповая политика должна применяться ко всем управляемым устройствам (корневой группе администрирования) или к отдельной группе, в которую автоматически попадают новые управляемые устройства в соответствии с настроенными правилами перемещения.

Установка пароля на выключение защиты и удаление приложения

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

Использование Kaspersky Security Network

Во всех политиках управляемых приложений и в свойствах Open Single Management Platform рекомендуется использовать Kaspersky Security Network (KSN) и принять актуальное Положение о KSN. При обновлении Open Single Management Platform вы также можете принять обновленное Положение о KSN. Если использование облачных служб запрещено законодательством или иными нормативными актами, вы можете не включать KSN.

Регулярная проверка управляемых устройств

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

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

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

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

Передача событий в сторонние системы

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

Мониторинг и отчеты

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

Экспорт событий в SIEM-системы

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

Уведомление по электронной почте о событиях аудита

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

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

Схемы развертывания

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

Существует два варианта развертывания Open Single Management Platform: на нескольких узлах или на одном узле кластера Kubernetes. Прежде чем начать, рекомендуется ознакомиться с доступными схемами развертывания и выбрать ту, которая лучше всего соответствует требованиям вашей организации. Вы можете использовать руководство по масштабированию, в котором описаны требования к оборудованию и рекомендуемый вариант развертывания в зависимости от количества устройств в организации.

В зависимости от выбранного варианта развертывания вам могут потребоваться следующие устройства для работы Open Single Management Platform:

• Устройство администратора

  Устройство администратора – это физическая или виртуальная машина, которая используется для развертывания и управления кластером Kubernetes и Open Single Management Platform. Поскольку KDT работает на устройстве администратора, это устройство должно соответствовать требованиям KDT.

• Целевые устройства

  Целевые устройства – это физические или виртуальные машины, на которые устанавливается Open Single Management Platform. Используются следующие целевые устройства:

  • Целевые устройства для установки компонентов Open Single Management Platform.

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

    Целевые устройства должны соответствовать требованиям для выбранного варианта развертывания (развертывание на нескольких узлах или развертывание на одном узле).

  • Целевые устройства KUMA для установки сервисов KUMA.

    Целевые устройства, не входящие в кластер Kubernetes и используемые для установки сервисов KUMA (корреляторы, коллекторы и хранилища). Количество целевых устройств KUMA зависит от количества событий которые Open Single Management Platform должен обработать.

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

• Устройство СУБД (только для развертывания на нескольких узлах)

  Устройством для установки СУБД является отдельный сервер, расположенный вне кластера Kubernetes. Это устройство должно соответствовать требованиям для узла базы данных.

• Устройство KATA/KEDR (необязательно)

  Если вы хотите получать телеметрию от Kaspersky Anti Targeted Attack Platform и управлять действиями по реагированию на угрозы на активах, подключенных к серверам Kaspersky Endpoint Detection and Response, вы можете установить и настроить Kaspersky Anti Targeted Attack Platform с функциональным блоком Kaspersky Endpoint Detection and Response. Kaspersky Anti Targeted Attack Platform – это автономное решение, которое необходимо установить на отдельный сервер, не входящий в кластер Kubernetes. Подробную информацию о сценариях развертывания KATA см. в документации KATA.

Развертывание на нескольких узлах.

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

В этой конфигурации вам понадобится минимум семь устройств:

• 1 устройство администратора;
• 4 целевых устройства для установки кластера Kubernetes и компонентов Open Single Management Platform;
• 1 устройство для установки СУБД;
• 1 целевое устройство KUMA для установки сервисов KUMA.

Развертывание на одном узле

При развертывании на одном узле все компоненты Open Single Management Platform устанавливаются на одном узле кластера Kubernetes. Вы можете выполнить развертывание Open Single Management Platform на одном узле, чтобы решение требовало меньше вычислительных ресурсов.

В этой конфигурации вам понадобится минимум три устройства:

• 1 устройство администратора;
• 1 целевое устройство для установки кластера Kubernetes, компонентов Open Single Management Platform и СУБД;
• 1 целевое устройство KUMA для установки сервисов KUMA.

В этой конфигурации СУБД не требует отдельного узла, но она должна быть установлена вручную на целевом устройстве перед развертыванием Open Single Management Platform.

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

На рисунке ниже приведена схема развертывания приложения Open Single Management Platform на нескольких узлах.

Схема развертывания Open Single Management Platform на нескольких узлах

Схема развертывания Open Single Management Platform на нескольких узлах включает следующие основные компоненты:

• Устройство администратора. На этом устройстве администратор использует Kaspersky Deployment Toolkit для развертывания и управления кластером Kubernetes и Open Single Management Platform. Устройство администратора не входит в кластер Kubernetes.
• Кластер Kubernetes. Кластер Kubernetes включает узел контроллера (также называемый первичным узлом во время процедуры развертывания) и как минимум три рабочих узла. Количество рабочих узлов может быть разным. На схеме распределение компонентов Open Single Management Platform по рабочим узлам показано в качестве примера. Фактическое распределение компонентов может отличаться.
• Сервер СУБД. Для корректной работы компонентов Open Single Management Platform необходим сервер с установленной системой управления базами данных. Администратор устанавливает СУБД вручную на отдельные серверы вне кластера Kubernetes.
• Устройства с сервисами KUMA. Сервисы KUMA (коллекторы, корреляторы и хранилища) устанавливаются на устройства, расположенные вне кластера Kubernetes. Количество целевых устройств для сервисов KUMA может отличаться.
• KATA с KEDR. Kaspersky Anti Targeted Attack Platform с функциональным блоком Kaspersky Endpoint Detection and Response. Подробную информацию о сценариях развертывания KATA см. в документации KATA.
• Устройство пользователя с Open Single Management Platform. Пользовательское устройство, которое используется для входа в Консоль OSMP или Консоль KUMA.
• Подчиненные Серверы администрирования (необязательно). Подчиненные Серверы администрирования используются для создания иерархии Серверов.
• Управляемые устройства. Клиентские устройства защищены Open Single Management Platform. На каждом управляемом устройстве установлен Агент администрирования.

Порты

На схеме не отображены все порты, необходимые для успешного развертывания. Полный список портов приведен в разделе Порты, используемые Open Single Management Platform.

Условные обозначения схемы:

На схеме не показано взаимодействие внутри кластера Kubernetes между узлами и между компонентами Open Single Management Platform. Подробнее см. в разделе Порты, используемые Open Single Management Platform.

Список портов, которые необходимо открыть на управляемых устройствах, приведен в разделе Порты, используемые Open Single Management Platform.

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

На схеме сервисы KUMA развернуты по схеме развертывания на нескольких узлах. Количество целевых устройств для сервисов KUMA может отличаться. Список открываемых портов зависит от выбранной схемы развертывания. Полный список портов приведен в разделе Порты, используемые Open Single Management Platform.

TCP-порт 7221 и другие порты для установки служб. Вы указываете эти порты как значение для --api.point <port>.

Схема развертывания на одном узле

На рисунке ниже приведена схема развертывания приложения Open Single Management Platform на одном узле.

Схема развертывания Open Single Management Platform на одном узле

Схема развертывания Open Single Management Platform на одном узле включает следующие основные компоненты:

• Устройство администратора. На этом устройстве администратор использует Kaspersky Deployment Toolkit для развертывания и управления кластером Kubernetes и Open Single Management Platform. Устройство администратора не входит в кластер Kubernetes.
• Кластер Kubernetes. Кластер Kubernetes включает в себя устройство, которое действует как узел контроллера (далее также первичный узел во время процедуры развертывания) и как рабочий узел.
• Сервер СУБД. Для корректной работы компонентов Open Single Management Platform необходим сервер с установленной системой управления базами данных. Сервер СУБД не входит в кластер Kubernetes. Администратор устанавливает СУБД вручную на целевом устройстве, которое будет действовать как первичный рабочий узел перед развертыванием Open Single Management Platform.
• Устройства с сервисами KUMA. Сервисы KUMA (коллекторы, корреляторы и хранилища) устанавливаются на устройства, расположенные вне кластера Kubernetes. Количество целевых устройств для сервисов KUMA может отличаться.
• KATA с KEDR. Kaspersky Anti Targeted Attack Platform с функциональным блоком Kaspersky Endpoint Detection and Response. Подробную информацию о сценариях развертывания KATA см. в документации KATA.
• Устройство пользователя с Open Single Management Platform. Пользовательское устройство, которое используется для входа в Консоль OSMP или Консоль KUMA.
• Подчиненные Серверы администрирования (необязательно). Подчиненные Серверы администрирования используются для создания иерархии Серверов.
• Управляемые устройства. Клиентские устройства защищены Open Single Management Platform. На каждом управляемом устройстве установлен Агент администрирования.

Порты

На схеме не отображены все порты, необходимые для успешного развертывания. Полный список портов приведен в разделе Порты, используемые Open Single Management Platform.

Условные обозначения схемы:

Список портов, которые необходимо открыть на управляемых устройствах, приведен в разделе Порты, используемые Open Single Management Platform.

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

На схеме сервисы KUMA развернуты по схеме развертывания на нескольких узлах. Количество целевых устройств для сервисов KUMA может отличаться. Список открываемых портов зависит от выбранной схемы развертывания. Полный список портов приведен в разделе Порты, используемые Open Single Management Platform.

TCP-порт 7221 и другие порты для установки служб. Вы указываете эти порты как значение для --api.point <port>.

Порты, используемые Open Single Management Platform

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

Для взаимодействия между устройством администратора и устройствами, которые используются для установки сервисов KUMA и находятся вне кластера Kubernetes, доступ предоставляется только по TCP-порту 22.

Порты, используемые для взаимодействия между устройством администратора и целевыми устройствами

Для корректной работы компонентов Open Single Management Platform целевые устройства должны находиться в одном широковещательном домене.

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

Если вы используете сетевой экран firewalld или UFW на целевых устройствах, KDT автоматически откроет требуемые порты на сетевых экранах. Или вы можете вручную открыть перечисленные порты перед развертыванием Open Single Management Platform.

Обязательные порты, используемые компонентами Open Single Management Platform

В таблице ниже указаны порты, которые по умолчанию не открываются на сетевых экранах при развертывании Open Single Management Platform. Эти порты невозможно изменить.

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

Необязательные порты на сетевом экране, используемые компонентами Open Single Management Platform

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

Если вы используете сетевой экран firewalld или UFW на целевых устройствах, KDT автоматически откроет требуемые порты на сетевых экранах. Или вы можете вручную открыть перечисленные порты перед развертыванием Open Single Management Platform.

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

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

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

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

Если используются стандартные примеры служб, при развертывании Open Single Management Platform автоматически открываются следующие порты:

• 7230 TCP
• 7231 TCP
• 7232 TCP
• 7233 TCP
• 7234 TCP
• 7235 TCP
• 5140 TCP
• 5140 UDP
• 5141 TCP
• 5144 UDP

Подготовительные работы и развертывание

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

Вы узнаете, как установить Open Single Management Platform по схеме развертывания на нескольких узлах и развертывания на одном узле. Также в этом разделе содержится информация о том, как развернуть несколько кластеров Kubernetes с экземплярами Open Single Management Platform и переключаться между ними с помощью KDT.

Развертывание на нескольких узлах: подготовка устройства администратора и целевых устройств

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

Подготовка устройства администратора

Предварительно вам нужно подготовить устройство, которое будет выполнять роль устройства администратора, с которого будет запускаться KDT. Это устройство может быть включено или не включено в кластер Kubernetes, созданный с помощью KDT во время развертывания. Если устройство администратора не включено в кластер, оно будет использоваться только для развертывания и управления кластером Kubernetes и Open Single Management Platform. Если устройство администратора включено в кластер, оно также будет действовать как целевое устройство, которое используется для работы компонентов Open Single Management Platform.

Чтобы подготовить устройство администратора:

1. Убедитесь, что оборудование и программное обеспечение на устройстве администратора соответствуют требованиям для KDT.
2. Выделите не менее 10 ГБ свободного места в директории временных файлов (/tmp) для KDT. Если у вас недостаточно свободного места в этой директории, выполните следующую команду, чтобы указать путь к другой директории:

   export TMPDIR=<new_directory>/tmp

3. Установите пакет для Docker версии 23 или выше, а затем выполните действия после установки, чтобы настроить устройство администрирования для правильной работы с Docker.

   Не устанавливайте неофициальные версии пакета Docker из хранилищ операционных систем.

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

   Просмотреть информацию

   1. Поскольку устройство будет действовать как устройство администратора и целевое устройство, убедитесь, что оно соответствует требованиям для развертывания на одном узле (так как демонстрационное развертывание и развертывание на одном узле имеют схожую схему развертывания).
   2. Убедитесь, что на устройстве администратора поддерживается технология cgroup v2.

      Технология cgroup v2 поддерживается для версии ядра Linux 2.6.24 и выше.

   3. Установите пакет uidmap на устройстве администратора.

      Убедитесь, что файлы /etc/subgid и /etc/subuid содержат учетную запись пользователя, под которой будет запущен KDT. Для этого вы можете выполнить следующую команду:

      getsubids USER

      Если эта команда не возвращает результат, вам нужно вручную добавить учетную запись пользователя в файлы /etc/subgid и /etc/subuid в следующем формате:

      <username>:<min_subid>:<range_length>

      где

      • <username> – имя пользователя учетной записи, под которым будет запущен KDT.
      • <min_subid> – минимальное значение subuid.
      • <range_length> – количество subuid, выделенных для пользователя <username>.

Подготовка целевых устройств

Целевые устройства – это физические или виртуальные машины, которые используются для развертывания Open Single Management Platform и которые включены в кластер Kubernetes. Компоненты Open Single Management Platform работают на этих устройствах.

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

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

• Один первичный узел.

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

• Три рабочих узла.

  Рабочие узлы предназначены для выполнения рабочей нагрузки компонентов Open Single Management Platform.

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

  Вы можете установить СУБД внутри кластера Kubernetes при выполнении демонстрационного развертывания Open Single Management Platform. В этом случае выделите дополнительный рабочий узел для установки СУБД. KDT установит СУБД во время развертывания Open Single Management Platform.

  Для развертывания на нескольких узлах, рекомендуется установить СУБД на отдельный сервер вне кластера. После развертывания Open Single Management Platform замена СУБД, которая установлена внутри кластера, на СУБД, установленную на отдельном сервере, недоступна. Вам необходимо удалить все компоненты Open Single Management Platform и снова установить Open Single Management Platform. В этом случае данные будут потеряны.

Чтобы подготовить целевые устройства:

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

   Для правильной работы Open Single Management Platform версия ядра Linux должна быть 5.15.0.107 или выше на целевых устройствах с операционной системой семейства Ubuntu.

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

2. На каждом целевом устройстве установите пакет sudo, если этот пакет еще не установлен. Для операционных систем семейства Debian установите пакет UFW на целевые устройства.
3. На каждом целевом устройстве настройте файл /etc/environment. Если инфраструктура вашей организации использует прокси-сервер для доступа в интернет, подключите целевые устройства к интернету.
4. На первичном узле с конфигурацией UFW разрешите IP-переадресацию. В файле /etc/default/ufw установите для параметра DEFAULT_FORWARD_POLICY значение ACCEPT.
5. Предоставьте доступ к хранилищу пакетов. Это хранилище содержит следующие пакеты, необходимые для работы Open Single Management Platform:
   • nfs-common
   • tar
   • iscsi-package
   • wireguard
   • wireguard-tools

   KDT попытается установить эти пакеты во время развертывания из хранилища пакетов. Также эти пакеты можно установить вручную.

6. Для первичного узла убедитесь, что установлен пакет curl.
7. Для рабочих узлов убедитесь, что установлен пакет libnfs версии 12 и выше.

   Пакеты curl и libnfs не устанавливаются во время развертывания из хранилища пакетов с помощью KDT. Вам нужно установить эти пакеты вручную, если они еще не установлены.

8. Зарезервируйте статические IP-адреса для целевых устройств для шлюза кластера Kubernetes и для устройства с СУБД (если СУБД установлена внутри кластера).

   Шлюз Kubernetes предназначен для подключения компонентов Open Single Management Platform, установленных внутри кластера Kubernetes. IP-адрес шлюза соединения указан в конфигурационном файле.

   Для стандартного использования решения, когда вы устанавливаете СУБД на отдельный сервер, IP-адрес шлюза соединения – это IP-адрес в нотации CIDR, которая содержит маску подсети /32 (например, 192.168.0.0/32).

   Для демонстрационных целей, когда вы устанавливаете СУБД внутри кластера Kubernetes, IP-адрес шлюза является IP-диапазоном (например, 192.168.0.1–192.168.0.2).

   Убедитесь, что целевые устройства, шлюз соединения кластера Kubernetes и устройство с СУБД находятся в одном широковещательном домене.

9. На своем DNS-сервере зарегистрируйте FQDN служб для подключения к службам Open Single Management Platform.

   По умолчанию службы Open Single Management Platform доступны по следующим адресам:

   • <console_host>.<smp_domain> – доступ к интерфейсу Консоли OSMP.
   • <admsrv_host>.<smp_domain> – взаимодействие с Сервером администрирования.
   • <kuma_host>.<smp_domain> – доступ к интерфейсу Консоли KUMA.
   • <api_host>.<smp_domain> – доступ к API Open Single Management Platform.
   • <psql_host>.<smp_domain> – взаимодействие с СУБД (PostgreSQL).

     Где <console_host>, <admsrv_host>, <kuma_host>, <api_host> и <psql_host> являются именами устройств сервисов, <smp_domain> является доменным именем сервиса. Эти параметры являются частями сервисов FQDN, которые вы можете указать в конфигурационном файле. Если вы не указываете пользовательские значения имен служб устройств, используются значения по умолчанию: console_host – "console", admsrv_host – "admsrv", kuma_host – "kuma", api_host – "api", psql_host – "psql".

     Зарегистрируйте FQDN службы <psql_host>.<smp_domain>, если вы установили СУБД внутри кластера Kubernetes на узле СУБД и вам нужно подключиться к СУБД.

   В зависимости от того, где вы хотите установить СУБД, перечисленные FQDN служб должны быть преобразованы в IP-адрес кластера Kubernetes следующим образом:

   • СУБД на отдельном сервере (стандартное использование).

     В этом случае IP-адрес шлюза соединения – это адрес служб Open Single Management Platform (без учета IP-адреса СУБД). Например, если указан IP-адрес шлюза соединения 192.168.0.0/32, FQDN службы должны быть разрешаться следующим образом:

     • <console_host>.<smp_domain> – 192.168.0.0/32
     • <admsrv_host>.<smp_domain> – 192.168.0.0/32
     • <kuma_host>.<smp_domain> – 192.168.0.0/32
     • <api_host>.<smp_domain> – 192.168.0.0/32
   • СУБД внутри кластера Kubernetes (демонстрационное развертывание).

     В этом случае IP-адрес шлюза соединения представляет собой IP-диапазон. Первый IP-адрес диапазона – это адрес служб Open Single Management Platform (без учета IP-адреса СУБД). Второй IP-адрес диапазона – IP-адрес СУБД. Например, если указан IP-диапазон шлюза соединения 192.168.0.1–192.168.0.2, FQDN служб должны быть разрешены следующим образом:

     • <console_host>.<smp_domain> – 192.168.0.1
     • <admsrv_host>.<smp_domain> – 192.168.0.1
     • <kuma_host>.<smp_domain> – 192.168.0.1
     • <api_host>.<smp_domain> – 192.168.0.1
     • <psql_host>.<smp_domain> – 192.168.0.2
10. На целевых устройствах создайте учетные записи, которые будут использоваться для развертывания Open Single Management Platform.

    Эти учетные записи используются для SSH-соединения и должны иметь возможность повышать привилегии (sudo) без ввода пароля. Для этого добавьте созданные учетные записи пользователей в файл /etc/sudoers.

11. Настройте SSH-соединение между устройством администратора и целевыми устройствами:
    1. На устройстве администратора сгенерируйте SSH-ключи с помощью утилиты ssh-keygen без парольной фразы.
    2. Скопируйте открытый ключ на каждое целевое устройство (например, в директории /home/<имя_пользователя>/.ssh) с помощью утилиты ssh-copy-id.

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

12. Для корректной работы компонентов Open Single Management Platform обеспечьте сетевой доступ между целевыми устройствами и при необходимости откройте требуемые порты на сетевом экране устройства администратора и целевых устройств.
13. Настройте синхронизацию времени по протоколу Network Time Protocol (NTP) на устройстве администратора и целевых устройствах.
14. При необходимости подготовьте пользовательские сертификаты для работы с публичными службами Open Single Management Platform.

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

Развертывание на одном узле: подготовка устройства администратора и целевых устройств

Подготовка к развертыванию на одном узле включает настройку устройства администратора и целевых устройств. В конфигурации с одним узлом кластер Kubernetes и компоненты Open Single Management Platform устанавливаются на одном целевом устройстве. После подготовки целевого устройства и указания конфигурационного файла, вы сможете развернуть Open Single Management Platform на целевом устройстве с использованием KDT.

Подготовка устройства администратора

Предварительно вам нужно подготовить устройство, которое будет выполнять роль устройства администратора, с которого будет запускаться KDT. Это устройство может быть включено или не включено в кластер Kubernetes, созданный с помощью KDT во время развертывания. Если устройство администратора не включено в кластер, оно будет использоваться только для развертывания и управления кластером Kubernetes и Open Single Management Platform. Если устройство администратора включено в кластер, оно также будет действовать как целевое устройство, которое используется для работы компонентов Open Single Management Platform. В этом случае будет использовано только одно устройство для развертывания и работы решения.

Чтобы подготовить устройство администратора:

1. Убедитесь, что оборудование и программное обеспечение на устройстве администратора соответствуют требованиям для KDT.
2. Выделите не менее 10 ГБ свободного места в директории временных файлов (/tmp) для KDT. Если у вас недостаточно свободного места в этой директории, выполните следующую команду, чтобы указать путь к другой директории:

   export TMPDIR=<new_directory>/tmp

3. Установите пакет для Docker версии 23 или выше, а затем выполните действия после установки, чтобы настроить устройство администрирования для правильной работы с Docker.

   Не устанавливайте неофициальные версии пакета Docker из хранилищ операционных систем.

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

   Просмотреть информацию

   1. Поскольку устройство будет действовать как устройство администратора и целевое устройство, убедитесь, что оно соответствует требованиям для развертывания на одном узле (так как демонстрационное развертывание и развертывание на одном узле имеют схожую схему развертывания).
   2. Убедитесь, что на устройстве администратора поддерживается технология cgroup v2.

      Технология cgroup v2 поддерживается для версии ядра Linux 2.6.24 и выше.

   3. Установите пакет uidmap на устройстве администратора.

      Убедитесь, что файлы /etc/subgid и /etc/subuid содержат учетную запись пользователя, под которой будет запущен KDT. Для этого вы можете выполнить следующую команду:

      getsubids USER

      Если эта команда не возвращает результат, вам нужно вручную добавить учетную запись пользователя в файлы /etc/subgid и /etc/subuid в следующем формате:

      <username>:<min_subid>:<range_length>

      где

      • <username> – имя пользователя учетной записи, под которым будет запущен KDT.
      • <min_subid> – минимальное значение subuid.
      • <range_length> – количество subuid, выделенных для пользователя <username>.

Подготовка целевого устройства

Целевое устройство – это физическая или виртуальная машина, которая используются для развертывания Open Single Management Platform и которая включена в кластер Kubernetes. Целевое устройство управляет кластером Kubernetes, хранит метаданные, а также на этом устройстве работают компоненты Open Single Management Platform. Минимальная конфигурация кластера для развертывания с одним узлом включает одно целевое устройство, которое действует как первичный и рабочий узлы. На этом первичном рабочем узле установлен кластер Kubernetes и компоненты Open Single Management Platform.

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

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

Чтобы подготовить целевое устройство:

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

   Для правильной работы Open Single Management Platform версия ядра Linux должна быть 5.15.0.107 или выше на целевом устройстве с операционной системой семейства Ubuntu.

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

2. Установите пакет sudo, если этот пакет еще не установлен. Для операционных систем семейства Debian установите пакет UFW.
3. Настройте файл /etc/environment. Если инфраструктура вашей организации использует прокси-сервер для доступа в интернет, подключите целевое устройство к интернету.
4. На первичном рабочем узле с конфигурацией UFW разрешите IP-переадресацию. В файле /etc/default/ufw установите для параметра DEFAULT_FORWARD_POLICY значение ACCEPT.
5. Предоставьте доступ к хранилищу пакетов. Это хранилище содержит следующие пакеты, необходимые для работы Open Single Management Platform:
   • nfs-common
   • tar
   • iscsi-package
   • wireguard
   • wireguard-tools

   KDT попытается установить эти пакеты во время развертывания из хранилища пакетов. Также эти пакеты можно установить вручную.

6. Убедитесь, что пакеты curl и libnfs установлены на первичном рабочем узле.

   Пакеты curl и libnfs не устанавливаются во время развертывания из хранилища пакетов с помощью KDT. Вам нужно установить эти пакеты вручную, если они еще не установлены. Используется пакет libnfs версии 12 и выше.

7. Зарезервируйте статические IP-адреса для целевого устройства и шлюза кластера Kubernetes.

   Шлюз Kubernetes предназначен для подключения компонентов Open Single Management Platform, установленных внутри кластера Kubernetes.

   Для стандартного использования решения, когда вы устанавливаете СУБД на целевое устройство вне кластера, IP-адрес шлюза соединения – это IP-адрес в нотации CIDR, которая содержит маску подсети /32 (например, 192.168.0.0/32).

   Для демонстрационных целей, когда вы устанавливаете СУБД внутри кластера Kubernetes, IP-адрес шлюза является IP-диапазоном (например, 192.168.0.1–192.168.0.2).

   Убедитесь, что целевое устройство и шлюз соединения кластера Kubernetes находятся в одном широковещательном домене.

8. На своем DNS-сервере зарегистрируйте FQDN служб для подключения к службам Open Single Management Platform.

   По умолчанию службы Open Single Management Platform доступны по следующим адресам:

   • <console_host>.<smp_domain> – доступ к интерфейсу Консоли OSMP.
   • <admsrv_host>.<smp_domain> – взаимодействие с Сервером администрирования.
   • <kuma_host>.<smp_domain> – доступ к интерфейсу Консоли KUMA.
   • <api_host>.<smp_domain> – доступ к API Open Single Management Platform.
   • <psql_host>.<smp_domain> – взаимодействие с СУБД (PostgreSQL).

     Где <console_host>, <admsrv_host>, <kuma_host>, <api_host> и <psql_host> являются именами устройств сервисов, <smp_domain> является доменным именем сервиса. Эти параметры являются частями сервисов FQDN, которые вы можете указать в конфигурационном файле. Если вы не указываете пользовательские значения имен служб устройств, используются значения по умолчанию: console_host – "console", admsrv_host – "admsrv", kuma_host – "kuma", api_host – "api", psql_host – "psql".

     Зарегистрируйте FQDN службы <psql_host>.<smp_domain>, если вы установили СУБД внутри кластера Kubernetes на узле СУБД и вам нужно подключиться к СУБД.

   В зависимости от того, где вы хотите установить СУБД, перечисленные FQDN служб должны быть преобразованы в IP-адрес кластера Kubernetes следующим образом:

   • СУБД на целевом устройстве вне кластера Kubernetes (стандартное использование)

     В этом случае IP-адрес шлюза соединения – это адрес служб Open Single Management Platform (без учета IP-адреса СУБД). Например, если указан IP-адрес шлюза соединения 192.168.0.0/32, FQDN службы должны быть разрешаться следующим образом:

     • <console_host>.<smp_domain> – 192.168.0.0/32
     • <admsrv_host>.<smp_domain> – 192.168.0.0/32
     • <kuma_host>.<smp_domain> – 192.168.0.0/32
     • <api_host>.<smp_domain> – 192.168.0.0/32
   • СУБД внутри кластера Kubernetes (демонстрационное развертывание).

     В этом случае IP-адрес шлюза соединения представляет собой IP-диапазон. Первый IP-адрес диапазона – это адрес служб Open Single Management Platform (без учета IP-адреса СУБД). Второй IP-адрес диапазона – IP-адрес СУБД. Например, если указан IP-диапазон шлюза соединения 192.168.0.1–192.168.0.2, FQDN служб должны быть разрешены следующим образом:

     • <console_host>.<smp_domain> – 192.168.0.1
     • <admsrv_host>.<smp_domain> – 192.168.0.1
     • <kuma_host>.<smp_domain> – 192.168.0.1
     • <api_host>.<smp_domain> – 192.168.0.1
     • <psql_host>.<smp_domain> – 192.168.0.2
9. Создайте учетные записи, которые будут использоваться для развертывания Open Single Management Platform.

   Эти учетные записи используются для SSH-соединения и должны иметь возможность повышать привилегии (sudo) без ввода пароля. Для этого добавьте созданные учетные записи пользователей в файл /etc/sudoers.

10. Настройте SSH-соединение между устройством администратора и целевыми устройствами:
    1. На устройстве администратора сгенерируйте SSH-ключи с помощью утилиты ssh-keygen без парольной фразы.
    2. Скопируйте открытый ключ на целевое устройство (например, в директорию /home/<имя_пользователя>/.ssh) с помощью утилиты ssh-copy-id.

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

11. Для корректной работы компонентов Open Single Management Platform откройте требуемые порты на сетевом экране устройства администратора и целевых устройств.
12. Настройте синхронизацию времени по протоколу Network Time Protocol (NTP) на устройстве администратора и целевых устройствах.
13. При необходимости подготовьте пользовательские сертификаты для работы с публичными службами Open Single Management Platform.

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

Подготовка устройств к установке сервисов KUMA

Сервисы KUMA (коллекторы, корреляторы и хранилища) устанавливаются на целевые устройства KUMA, расположенные вне кластера Kubernetes.

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

Чтобы подготовить целевые устройства KUMA к установке сервисов KUMA:

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

   Вам нужно указать FQDN, например: kuma1.example.com.

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

3. Выполните следующие команды:

   hostname -f

   hostnamectl status

   Сравните результат команды hostname -f и значение поля Static hostname в выводе команды hostnamectl status. Эти значения должны совпадать с FQDN устройства.

4. Настройте SSH-соединение между устройством администратора и целевыми устройствами KUMA:

   Используйте SSH-ключи, созданные для целевых устройств. Скопируйте открытый ключ на целевые устройства KUMA с помощью утилиты ssh-copy-id.

5. Зарегистрируйте целевые устройства KUMA в зоне DNS вашей организации, чтобы разрешить преобразование имен устройств в IP-адреса.
6. Убедитесь, что на всех целевых устройствах KUMA настроена синхронизация времени по протоколу Network Time Protocol (NTP).

Устройство готово к установке сервисов KUMA.

Установка системы управления базами данных

Open Single Management Platform поддерживает системы управления базами данных (СУБД) PostgreSQL или Postgres Pro. Полный список поддерживаемых СУБД см. в разделе Аппаратные и программные требования.

Для каждого из следующих компонентов Open Single Management Platform требуется база данных:

• Сервер администрирования
• Платформа автоматизации
• Incident Response Platform (IRP)
• Identity and Access Manager (IAM)

Каждый компонент должен использовать отдельную базу данных в одном экземпляре СУБД. Рекомендуется устанавливать экземпляр СУБД вне кластера Kubernetes.

Для установки СУБД KDT требует наличия привилегированной учетной записи СУБД с правами на создание баз данных и других учетных записей СУБД. KDT использует эту привилегированную учетную запись СУБД для создания баз данных и других учетных записей СУБД, необходимых для работы компонентов Open Single Management Platform.

Сведения о том, как установить выбранную СУБД, см. в документации к этой СУБД.

После установки СУБД необходимо настроить параметры сервера СУБД для оптимизации работы СУБД с Open Single Management Platform.

Настройка сервера PostgreSQL или Postgres Pro для работы с Open Single Management Platform

Open Single Management Platform поддерживает системы управления базами данных (СУБД) PostgreSQL или Postgres Pro. Полный список поддерживаемых СУБД см. в разделе Аппаратные и программные требования. Вы можете настроить параметры сервера СУБД для оптимизации работы СУБД с Сервером администрирования.

Путь по умолчанию к конфигурационному файлу: /etc/postgresql/<ВЕРСИЯ>/main/postgresql.conf

Рекомендуемые параметры для работы СУБД PostgreSQL и Postgres Pro с Сервером администрирования:

• shared_buffers = 25% от объема оперативной памяти устройства, на котором установлена СУБД.

  Если оперативной памяти меньше 1 ГБ, то оставьте значение по умолчанию.

• max_stack_depth = если СУБД установлена на устройстве Linux, то параметр рассчитывается по формуле: максимальный размер стека (выполните команду ulimit -s, чтобы получить это значение в КБ) минус 1 МБ.

  Если СУБД установлена на устройстве Windows, оставьте значение по умолчанию 2 МБ.

• temp_buffers = 24MB
• work_mem = 16MB
• max_connections = 220

  Это минимально рекомендованное значение, вы можете указать большее.

• max_parallel_workers_per_gather = 0
• maintenance_work_mem = 128MB

После обновления файла postgresql.conf примените конфигурацию или перезапустите службу. Дополнительную информацию см. в документации PostgreSQL.

Если вы используете кластерную СУБД Postgres, укажите параметр max_connections для всех серверов СУБД и в конфигурации кластера.

Если вы используете Postgres Pro 15.7 или Postgres Pro 15.7.1, выключите параметр enable_compound_index_stats:

enable_compound_index_stats = off

Подробную информацию о параметрах сервера PostgreSQL и Postgres Pro, а также о том, как указать эти параметры, см. в документации соответствующей СУБД.

Подготовка файла инвентаря KUMA

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

Файл инвентаря KUMA – это файл в формате YAML, который содержит параметры установки для развертывания сервисов KUMA, не включенных в кластер Kubernetes. Путь к файлу инвентаря KUMA включен в конфигурационный файл, который используется Kaspersky Deployment Toolkit для развертывания Open Single Management Platform.

Шаблоны файла инвентаря KUMA находятся в дистрибутиве. Если вы хотите установить сервисы KUMA (хранилище, коллектор и коррелятор) на одном устройстве, используйте файл single.inventory.yaml. Чтобы установить сервисы на нескольких устройствах в сетевой инфраструктуре, используйте файл distributed.inventory.yaml.

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

Чтобы подготовить файл инвентаря KUMA,

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

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

• all block

  Блок all содержит переменные, которые применяются ко всем устройствам, указанным в файле инвентаря. Переменные находятся в разделе vars.

• kuma block

  Блок kuma содержит переменные, которые применяются к устройствам, на которых будут установлены сервисы KUMA. Эти устройства перечислены в блоке kuma в разделе children. Переменные находятся в разделе vars.

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

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

Пример шаблона файла инвентаря KUMA для установки сервисов KUMA на отдельном устройстве (файл single.inventory.yaml)

Пример шаблона файла инвентаря KUMA для установки сервисов KUMA на нескольких устройствах (файл distributed.inventory.yaml)

Развертывание на нескольких узлах: параметры установки

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

Конфигурационный файл – это файл в формате YAML, содержащий набор параметров установки компонентов Open Single Management Platform.

Параметры установки, указанные в таблицах ниже, необходимы для развертывания на нескольких узлах Open Single Management Platform. Чтобы развернуть Open Single Management Platform на отдельном узле, используйте конфигурационный файл, содержащий параметры установки, характерные для развертывания на одном узле.

Шаблон конфигурационного файла (multinode.smp_param.yaml.template) находится в дистрибутиве в архиве с утилитой KDT. Вы можете заполнить шаблон конфигурационного файла вручную либо вы можете использовать мастер настройки, чтобы указать параметры установки, необходимые для развертывания Open Single Management Platform, и сгенерировать конфигурационный файл.

Не все перечисленные ниже параметры включены в шаблон конфигурационного файла. Этот шаблон содержит только те параметры, которые должны быть указаны перед развертыванием Open Single Management Platform. Остальные параметры имеют значения по умолчанию и не включены в шаблон. Вы можете вручную добавить эти параметры в конфигурационный файл, чтобы перезаписать их значения.

Для корректной работы KDT с конфигурационным файлом добавьте пустую строку в конце файла.

Раздел nodes конфигурационного файла содержит параметры установки для каждого целевого устройства кластера Kubernetes. Эти параметры перечислены в таблице ниже.

Раздел nodes

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

Раздел параметров

Пример конфигурационного файла развертывания Open Single Management Platform на нескольких узлах

Развертывание на одном узле: параметры установки

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

Конфигурационный файл, используемый для развертывания Open Single Management Platform на одном узле, содержит параметры установки, необходимые как для развертывания на нескольких узлах, так и для развертывания на одном узле. Также этот конфигурационный файл содержит параметры, специфичные только для развертывания на одном узле (vault_replicas, vault_ha_mode, vault_standalone и default_сlass_replica_count).

Шаблон конфигурационного файла (singlenode.smp_param.yaml.template) находится в дистрибутиве в архиве с утилитой KDT. Вы можете заполнить шаблон конфигурационного файла вручную либо вы можете использовать мастер настройки, чтобы указать параметры установки, необходимые для развертывания Open Single Management Platform, и сгенерировать конфигурационный файл.

Не все перечисленные ниже параметры включены в шаблон конфигурационного файла. Этот шаблон содержит только те параметры, которые должны быть указаны перед развертыванием Open Single Management Platform. Остальные параметры имеют значения по умолчанию и не включены в шаблон. Вы можете вручную добавить эти параметры в конфигурационный файл, чтобы перезаписать их значения.

Для корректной работы KDT с конфигурационным файлом добавьте пустую строку в конце файла.

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

Раздел nodes

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

Раздел параметров

Пример конфигурационного файла для развертывания Open Single Management Platform на одном узле

Указание параметров установки с помощью мастера настройки

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

Предварительные требования

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

Процесс

Чтобы указать параметры установки с помощью мастера настройки:

1. На устройстве администратора, на котором расположена утилита KDT, запустите мастер настройки с помощью следующей команды:

   ./kdt wizard -k <путь_к_транспортному_архиву> -o <путь_к_конфигурационному_файлу>

   где:

   • <path_to_transport_archive> – путь к транспортному архиву.
   • <path_to_configuration_file> – путь, по которому вы хотите сохранить конфигурационный файл и имя конфигурационного файла.

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

   Если у вас нет прав на запись в указанной директории или в этой директории находится файл с таким же именем, возникает ошибка и мастер завершает работу.

2. Введите IPv4-адрес первичного узла (или первичного рабочего узла, если вы будете выполнять развертывание на одном узле). Это значение соответствует параметру host конфигурационного файла.
3. Введите имя пользователя учетной записи, используемой для подключения к первичному узлу с помощью KDT (параметр user конфигурационного файла).
4. Введите путь к закрытой части SSH-ключа, который находится на устройстве администратора и используется для подключения к первичному узлу KDT (параметр key конфигурационного файла).
5. Введите количество рабочих узлов.

   Возможные значения:

   • 0 – развертывание на одном узле.
   • 3 или более – развертывание на нескольких узлах.

   Этот шаг определяет вариант развертывания Open Single Management Platform. Если вы хотите выполнить развертывание на одном узле, следующие параметры, характерные для этого варианта развертывания, примут значения по умолчанию:

   • type—primary-worker
   • low_resources – true
   • vault_replicas—1
   • vault_ha_mode—false
   • vault_standalone—true
   • default_class_replica_count – 1
6. Для каждого рабочего узла введите IPv4-адрес (параметр host конфигурационного файла).

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

   Для развертывания на нескольких узлах для параметра kind первого рабочего узла по умолчанию установлено значение admsrv. Это означает, что Сервер администрирования будет установлен на первом рабочем узле. Для развертывания на одном узле параметр kind не указывается для первичного рабочего узла.

7. Для каждого рабочего узла введите имя пользователя, используемое для подключения к рабочему узлу с помощью KDT (параметр user конфигурационного файла).
8. Для каждого рабочего узла введите путь к закрытой части SSH-ключа, который используется для подключения к рабочему узлу с помощью KDT (параметр key конфигурационного файла).
9. Введите строку подключения для доступа к СУБД, которая установлена и настроена на отдельном сервере (параметр psql_dsn конфигурационного файла).

   Укажите этот параметр следующим образом: postgres://<dbms_username>:<password>@<fqdn>:<port>.

   Мастер задает параметры установки только для варианта развертывания с установленной СУБД на отдельном сервере, расположенном вне кластера Kubernetes.

10. Введите IP-адрес шлюза кластера Kubernetes (параметр ip_address конфигурационного файла).

    Шлюз кластера должен быть включен в ту же подсеть, что и все узлы кластера. IP-адрес шлюза кластера должен содержать маску подсети /32.

11. Введите пароль учетной записи Open Single Management Platform, которая будет создана KDT при установке (параметр admin_password конфигурационного файла).

    Имя пользователя по умолчанию для этой учетной записи – "admin". Этой учетной записи пользователя назначена роль Главного администратора.

12. Введите путь к файлу инвентаря KUMA, расположенному на устройстве администратора (параметр inventory конфигурационного файла).

    Файл инвентаря KUMA содержит параметры установки для развертывания сервисов KUMA, не входящих в кластер Kubernetes.

13. Введите путь к файлу с Лицензионным соглашением Ядра KUMA (параметр license конфигурационного файла).
14. Введите имя домена, которое используется в FQDN публичных служб Open Single Management Platform (параметр smp_domain конфигурационного файла).
15. Укажите путь к пользовательским сертификатам, которые используются для работы с публичными службами Open Single Management Platform (параметр intermediate_bundle конфигурационного файла).

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

16. Введите t, чтобы использовать рабочий процесс для управления инцидентами, разработанный на основании ГОСТ Р 59712-2022 (параметр feature_gost_status в конфигурационном файле).
17. Проверьте указанные параметры, которые отображаются в нумерованном списке.

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

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

Конфигурационный файл с указанными параметрами сохраняется в формате YAML.

Остальные параметры установки включены в конфигурационный файл со значениями по умолчанию. Вы можете изменить конфигурационный файл вручную перед развертыванием Open Single Management Platform.

Установка Open Single Management Platform

Open Single Management Platform разворачивается с помощью KDT. KDT автоматически разворачивает кластер Kubernetes, в котором установлены компоненты Open Single Management Platform и другие компоненты инфраструктуры. Шаги установки Open Single Management Platform не зависят от выбранного варианта развертывания.

Если вам нужно установить несколько кластеров Kubernetes с экземплярами Open Single Management Platform, вы можете использовать необходимое количество контекстов.

Чтобы установить Open Single Management Platform:

1. Распакуйте загруженный дистрибутив с KDT на устройство администратора.
2. Ознакомьтесь с Лицензионным соглашением KDT, находящимся в дистрибутиве с компонентами Open Single Management Platform.

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

   Вы можете ознакомиться с Лицензионным соглашением KDT после установки Open Single Management Platform. Файл находятся в директории /home/kdt/ пользователя, который запускает установку Open Single Management Platform.

3. Во время установки KDT загружает недостающие пакеты из хранилищ операционной системы. Перед установкой Open Single Management Platform, выполните следующую команду на целевых устройствах, чтобы убедиться, что кеш apt/yum актуален.

   apt update

4. На устройстве администратора выполните следующие команды, чтобы начать развертывание Open Single Management Platform с помощью KDT. Укажите путь к транспортному архиву с компонентами Open Single Management Platform и путь к конфигурационному файлу, который вы заполнили ранее (наборы параметров установки для развертывания на нескольких узлах и развертывания на одном узле различаются).

   chmod +x kdt

   ./kdt apply -k <полный_путь_к_архиву_транспорта> -i <полный_путь_к_конфигурационному_файлу>

   Вы можете установить Open Single Management Platform без запроса на ознакомление с условиями Лицензионного соглашения и Политикой конфиденциальности OSMP, если вы используете флаг --accept-eula. В этом случае вам нужно ознакомиться с Лицензионным соглашением и Политикой конфиденциальности OSMP перед установкой приложения. Файлы находятся в дистрибутиве с компонентами Open Single Management Platform.

   Если вы хотите прочитать и принять условия Лицензионного соглашения и Политики конфиденциальности во время развертывания, не используйте флаг --accept-eula.

5. Если вы не использовали флаг --accept-eula на предыдущем шаге, прочтите Лицензионное соглашение и Политику конфиденциальности OSMP. Текст отображается в окне командной строки. Нажмите пробел, чтобы просмотреть следующий фрагмент текста. При отображении запроса введите следующие значения:
   1. Введите y, если вы понимаете и принимаете условия Лицензионного соглашения.

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

   2. Введите y, если вы понимаете и принимаете условия Политики конфиденциальности и соглашаетесь, что ваши данные будут обрабатываться и пересылаться (в том числе в третьи страны) в соответствии с Политикой конфиденциальности.

      Введите n, если вы не принимаете условия Политики конфиденциальности.

      Чтобы использовать Open Single Management Platform, вам нужно принять условия Лицензионного соглашения и Политики конфиденциальности.

   После того как вы начнете развертывание, KDT проверяет, соответствуют ли аппаратное и программное обеспечение, а также сетевая конфигурация узлов кластера Kubernetes необходимым условиям для установки решения. Если все строгие предварительные проверки успешно пройдены, KDT разворачивает компоненты Open Single Management Platform в кластере Kubernetes на целевых устройствах. В ином случае развертывание будет прервано. Вы можете пропустить предварительные проверки перед развертыванием, если это необходимо (укажите для параметра установки ignore_precheck значение true).

   При развертывании Open Single Management Platform на главном Сервере администрирования создается пользователь. Чтобы начать настройку Консоли OSMP, этому пользователю назначаются следующие роли: XDR-роль Главного администратора в корневом тенанте и роль Главного администратора в Kaspersky Security Center.

6. Просмотрите журналы событий установки компонента Bootstrap в директории с утилитой KDT и при необходимости получите диагностическую информацию о компонентах Open Single Management Platform.
7. Войдите в Консоль OSMP и в Консоль KUMA.

   Адрес Консоли OSMP по умолчанию – https://<console_host>.<smp_domain>:443.

   Адрес Консоли KUMA по умолчанию – https://<kuma_host>.<smp_domain>:443.

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

Open Single Management Platform развернут на целевых устройствах. Установите сервисы KUMA, чтобы начать работу с решением.

Настройка доступа в интернет целевых устройств

Если инфраструктура вашей организации использует прокси-сервер для доступа в интернет, а также нужно подключить целевые устройства к интернету, вам необходимо добавить IP-адрес каждого целевого устройства в переменную no_proxy в файле /etc/environment перед развертыванием Open Single Management Platform. Это позволяет установить прямое подключение целевых устройств к интернету и правильно развернуть Open Single Management Platform.

Чтобы настроить доступ целевых устройств в интернет:

1. На целевом устройстве откройте файл /etc/environment с помощью текстового редактора. Например, следующая команда открывает файл с помощью текстового редактора GNU nano:

   sudo nano /etc/environment

2. В файл /etc/environment добавьте IP-адрес целевого устройства в переменную no_proxy через запятую без пробела.

   Например, переменную no_proxy можно изначально указать следующим образом:

   no_proxy=localhost,127.0.0.1

   Вы можете добавить IP-адрес целевого устройства (192.168.0.1) в переменную no_proxy:

   no_proxy=localhost,127.0.0.1,192.168.0.1

   Также вы можете указать подсеть, в которую входят целевые устройства (в нотации CIDR):

   no_proxy=localhost,127.0.0.1,192.168.0.0/24

3. Сохраните файл /etc/environment.

После добавления IP-адресов в файл /etc/environment к каждому целевому устройству вы можете продолжить подготовку целевых устройств и дальнейшее развертывание Open Single Management Platform.

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

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

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.

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

Установка сервисов KUMA

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

Типы сервисов:

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

Устанавливать сервисы KUMA можно только после развертывания Open Single Management Platform. При развертывании Open Single Management Platform подготавливается необходимая инфраструктура: на подготовленных устройствах создаются служебные директории, в которые добавляются файлы, необходимые для установки сервиса. Рекомендуется устанавливать сервисы в следующем порядке: хранилище, коллекторы, корреляторы и агенты.

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

1. Войдите в Консоль KUMA.

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

   • В главном меню Консоли OSMP перейдите в Параметры → KUMA.
   • В браузере перейдите по адресу https://<kuma_host>.<smp_domain>:443.

     Адрес Консоли KUMA состоит из значений параметров kuma_host и smp_domain, указанных в конфигурационном файле.

2. В Консоли KUMA создайте набор ресурсов для каждого сервиса KUMA (хранилищ, коллекторов и корреляторов), который вы хотите установить на подготовленных устройствах в сетевой инфраструктуре.
3. Создайте сервисы для хранилищ, коллекторов и корреляторов в Консоли KUMA.
4. Получите идентификаторы сервисов для привязки созданных наборов ресурсов и сервисов KUMA:
   1. В главном меню Консоли KUMA перейдите в раздел Ресурсы → Активные сервисы.
   2. Выберите требуемый сервис KUMA и нажмите на кнопку Копировать идентификатор.
5. На подготовленных устройствах в сетевой инфраструктуре выполните соответствующие команды для установки сервисов KUMA. Используйте идентификаторы сервисов, которые были получены ранее:
   • Команда установки хранилища:

     sudo /opt/kaspersky/kuma/kuma storage --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --install

   • Команда установки коллектора:

     sudo /opt/kaspersky/kuma/kuma collector --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the collector>

   • Команда установки коррелятора:

     sudo /opt/kaspersky/kuma/kuma correlator --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the correlator> --install

   По умолчанию полное доменное имя Ядра KUMA – <kuma_console>.<smp_domain>.

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

   Откройте порты, соответствующие установленному коллектору и коррелятору на сервере (TCP 7221 и другие порты, используемые для установки сервисов в качестве значения параметра --api.port <порт>).

6. Во время установки сервисов KUMA прочтите Лицензионное соглашение KUMA. Текст отображается в окне командной строки. Нажмите пробел, чтобы просмотреть следующий фрагмент текста. При отображении запроса введите следующие значения:
   • Введите y, если вы понимаете и принимаете условия Лицензионного соглашения.
   • Введите n, если вы не принимаете условия Лицензионного соглашения. Чтобы использовать сервисы KUMA, вам нужно принять условия Лицензионного соглашения.

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

   • На устройствах, входящих в группу kuma_utils в файле инвентаря KUMA, откройте файл LICENSE, расположенный в директории /opt/kaspersky/kuma/utils.
   • На устройствах, входящих в другие группы (kuma_storage, kuma_collector или kuma_correlator) в файле инвентаря KUMA, откройте файл LICENSE, расположенный в директории /opt/kaspersky/kuma.
   • Выполните команду:

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

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

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

   Файлы, необходимые для установки агента, находятся в директории /opt/kaspersky/kuma/utils.

Необходимые для работы Open Single Management Platform сервисы KUMA установлены.

Развертывание нескольких кластеров Kubernetes и экземпляров Open Single Management Platform

KDT позволяет развернуть несколько кластеров Kubernetes с экземплярами Open Single Management Platform и переключаться между ними с помощью контекстов. Контекст – это набор параметров доступа, определяющих кластер Kubernetes, с которым пользователь может выбрать взаимодействие. Контекст также включает данные для подключения к кластеру с помощью KDT.

Предварительные требования

Перед созданием контекстов и установкой кластеров Kubernetes с экземплярами Open Single Management Platform необходимо выполнить следующие действия:

1. Подготовить устройство администратора и целевые устройства.

   Для установки нескольких кластеров и экземпляров Open Single Management Platform вам нужно подготовить одно устройство администрирования для всех кластеров и отдельные наборы целевых устройств для каждого кластера. Компоненты Kubernetes не следует устанавливать на целевые устройства.

2. Подготовить устройства к установке сервисов KUMA.

   Для установки сервисов KUMA вам нужно подготовить отдельные наборы устройств для каждого экземпляра Open Single Management Platform.

3. Подготовить файл инвентаря KUMA.

   Для установки сервисов KUMA вам нужно подготовить отдельные файлы инвентаря для каждого экземпляра Open Single Management Platform.

4. Подготовить конфигурационный файл.

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

Процесс

Чтобы создать контекст с кластером Kubernetes и экземпляром Open Single Management Platform:

1. На устройстве администратора, на котором расположена утилита KDT, выполните команду и укажите имя контекста:

   ./kdt ctx --create <имя_контекста>

   Контекст с указанным именем создан.

2. Установите кластер Kubernetes и Open Single Management Platform.

Кластер с экземпляром Open Single Management Platform развернут в контексте. Создание контекста завершено. Когда вы получаете файлы журналов событий компонентов Open Single Management Platform, файлы журналов событий содержат имя вашего текущего контекста.

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

Вам нужно развернуть кластер Kubernetes и экземпляр Open Single Management Platform после создания контекста, чтобы завершить создание контекста. Если вы не выполните развертывание в контексте, а затем создадите другой контекст, первый контекст будет удален.

Чтобы просмотреть список созданных контекстов и имя активного контекста,

на устройстве администратора, на котором расположена утилита KDT, выполните команду:

./kdt ctx

Чтобы переключиться на нужный контекст,

На устройстве администратора, на котором расположена утилита KDT, выполните команду и укажите имя контекста:

./kdt ctx <имя_контекста>

После выбора контекста KDT подключается к соответствующему кластеру Kubernetes. Теперь вы можете работать с этим кластером и экземпляром Open Single Management Platform. К выбранному кластеру применяются команды KDT.

При удалении компонентов Open Single Management Platform, установленных в кластере Kubernetes, и самого кластера с помощью KDT соответствующие контексты также удаляются. Другие контексты и их кластеры с экземплярами Open Single Management Platform не удаляются.

Предварительная проверка готовности инфраструктуры для развертывания

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

Все проверки разделены на две группы:

• Строгие проверки.

  Проверка параметров, которые критически важны для работы Open Single Management Platform. Если эта проверка не пройдет, развертывание прерывается.

• Нестрогие проверки.

  Проверка параметров, которые не являются критически важными для работы Open Single Management Platform. Если эта проверка не пройдена, развертывание продолжается.

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

• Оборудование:
  • На дисках достаточно свободного места для развертывания.
  • Конфигурация процессора соответствует требованиям.
  • Свободного пространства оперативной памяти достаточно для развертывания.
  • Процессор поддерживает инструкции AVX, SSE2 и BMI.
• Программное обеспечение:
  • Операционная система и ее версия соответствуют требованиям.
  • Версия ядра соответствует требованиям.
  • Systemctl установлен и доступен (строгая проверка).
  • Доступно обновление кеша диспетчера пакетов (строгая проверка).
  • На узле установлены необходимые пакеты правильной версии (строгая проверка).
  • На узле не установлены запрещенные пакеты (docker и podman) (строгая проверка).
  • Отсутствуют устаревшие бинарные файлы k0s (строгая проверка).
  • Отсутствуют устаревшие конфигурационные файлы k0s (строгая проверка).
• Сеть:
  • Все узлы кластера расположены в одном широковещательном домене.
  • На узле доступно разрешение DNS-имен (строгая проверка).
  • На узлах кластера настроена синхронизация времени (строгая проверка).
  • Доступны необходимые порты.

Если все строгие предварительные проверки успешно пройдены, KDT разворачивает компоненты Open Single Management Platform в кластере Kubernetes на целевых устройствах. Результаты всех пройденных и не пройденных проверок сохраняются на каждом узле в файле /tmp/k0s_report.txt. Вы можете пропустить предварительные проверки перед развертыванием, если это необходимо (укажите для параметра установки ignore_precheck значение true).

Вход в Open Single Management Platform

Чтобы войти в Open Single Management Platform, вам нужно знать веб-адрес Консоли Open Single Management Platform. В вашем браузере должен быть включен JavaScript.

Чтобы войти в Консоль Open Single Management Platform:

1. В браузере перейдите по адресу https://<console_host>.<smp_domain>:443.

   Адрес Консоли Open Single Management Platform состоит из значений параметров console_host и smp_domain, указанных в конфигурационном файле.

   Отобразится страница входа в приложение.

2. Выполните одно из следующих действий:
   • Чтобы войти в Консоль Open Single Management Platform Console с использованием доменной учетной записи пользователя, введите имя пользователя и пароль доменного пользователя.

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

     • Username@dns.domain.
     • NTDOMAIN\Username.

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

   • Введите имя пользователя и пароль внутреннего пользователя.
   • Если на Сервере создан один или несколько виртуальных Серверов администрирования и вы хотите войти на виртуальный Сервер:
     1. Нажмите на кнопку Показать параметры виртуального Сервера.
     2. Введите имя виртуального Сервера администрирования, которое вы указали при его создании.
     3. Введите имя пользователя и пароль внутреннего или доменного пользователя, имеющего права на виртуальном Сервере администрирования.
3. Нажмите на кнопку Войти.

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

Open Single Management Platform позволяет работать с интерфейсами Консоли Open Single Management Platform и Консоли KUMA.

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

Если вы используете разные окна браузера или разные устройства для входа в Консоль Open Single Management Platform Console и Консоль KUMA, вам необходимо повторно ввести учетные данные. В этом случае, когда вы выходите из одной Консоли в окне браузера или устройства, на котором она открыта, сеанс продолжается в окне или устройстве, на котором открыта другая Консоль.

Чтобы выйти из Open Single Management Platform Console:

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

Приложение Open Single Management Platform Console закрыто и отображается страница входа в приложение.

Обслуживание Open Single Management Platform

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

Обновление Open Single Management Platform с версии 1.1 до версии 1.2

Вы можете обновить Open Single Management Platform с версии 1.1 до 1.2 с помощью KDT. KDT обновляет кластер Kubernetes, компоненты Open Single Management Platform и сервисы KUMA, установленные на целевых устройствах KUMA за пределами кластера. При обновлении вам не нужно заполнять конфигурационный файл, так как используются параметры установки, указанные во время развертывания. Шаги обновления Open Single Management Platform с предыдущей версии не зависят от выбранного варианта развертывания.

Чтобы обновить Open Single Management Platform с предыдущей версии:

1. Скачайте и распакуйте дистрибутив Open Single Management Platform версии 1.2.
2. На устройстве администратора выполните экспорт текущей версии конфигурационного файла.
3. В экспортированном конфигурационном файле обновите параметры установки, перечисленные в раскрывающемся блоке ниже.

   Измененные параметры установки

   Старые параметры установки (версия 1.1)	Новые параметры установки (версия 1.2)	Действие
   sshKey		Удалить устаревшие параметры
   pki_domain
   coreIngressHost
   KUMAUIURL
   webConsoleURL
   kdtStateSize
   adminLogin
   psql_ns
   psql_instance
   kumaUrl
   kumaLogin
   kscpassword	admin_password	Переименовать
   adminPassword
   iam-nwc_host ("console.smp.local")	iam-nwc_host ("console")	Изменить значение (исключить значение smp_domain из значения параметра)
   flow_host ("console.smp.local")	flow_host ("console")
   hydra_host ("console.smp.local")	hydra_host ("console")
   login_host ("console.smp.local")	login_host ("console")
   gateway_host ("console.smp.local")	gateway_host ("console")
   admsrv_fqdn ("admsrv.smp.local")	admsrv_host ("admsrv")	Переименовать и изменить значение (исключить значение smp_domain из значения параметра)
   console_fqdn ("console.smp.local")	console_host ("console")
   api_fqdn ("api.smp.local")	api_host ("api")
   kuma_fqdn ("kuma.smp.local")	kuma_host ("kuma")
   psql_fqdn ("psql.smp.local")	psql_host ("psql")
   monitoring_fqdn ("monitoring.smp.local")	monitoring_host ("monitoring")
   pki_fqdn_list ("admsrv.smp.local api.smp.local console.smp.local kuma.smp.local psql.smp.local monitoring.smp.local")	pki_host_list ("admsrv api console kuma psql monitoring")
   ipaddress	ip_address	Переименовать
   lowResources	low_resources
   coreDiskRequest	core_disk_request
   hostInventory	host_inventory

4. Ознакомьтесь с Лицензионным соглашением KDT, находящимся в дистрибутиве с компонентами Open Single Management Platform.

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

   Вы можете ознакомиться с Лицензионным соглашением KDT после обновления Open Single Management Platform. Файл находятся в директории /home/kdt/ пользователя, который запускает обновление Open Single Management Platform.

5. На устройстве администратора выполните команду для обновления компонента Bootstrap. В команде укажите полный путь к транспортному архиву с компонентами Open Single Management Platform и полный путь к конфигурационному файлу:

   ./kdt apply -k <полный_путь_к_архиву_обновлений_XDR> -i <полный_путь_к_конфигурационному_файлу> --force-bootstrap

6. Выполните следующую команду для обновления Open Single Management Platform:

   ./kdt apply -k <полный_путь_к_архиву_обновлений_XDR> --force

   Чтобы начать обновление Open Single Management Platform, примите условия Лицензионного соглашения и Политики конфиденциальности.

   Вы можете установить Open Single Management Platform без запроса на ознакомление с условиями Лицензионного соглашения и Политикой конфиденциальности OSMP, если вы используете флаг --accept-eula. В этом случае вам нужно ознакомиться с Лицензионным соглашением и Политикой конфиденциальности OSMP перед обновлением Open Single Management Platform. Файлы находятся в дистрибутиве с компонентами Open Single Management Platform. Используя флаг --accept-eula, вы подтверждаете, что полностью прочитали, поняли и принимаете условия Лицензионного соглашения и Политики конфиденциальности.

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

7. Если вы не использовали флаг --accept-eula на предыдущем шаге, прочтите Лицензионное соглашение и Политику конфиденциальности OSMP. Текст отображается в окне командной строки. Нажмите пробел, чтобы просмотреть следующий фрагмент текста. При отображении запроса введите следующие значения:
   1. Введите y, если вы понимаете и принимаете условия Лицензионного соглашения.

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

   2. Введите y, если вы понимаете и принимаете условия Политики конфиденциальности и соглашаетесь, что ваши данные будут обрабатываться и пересылаться (в том числе в третьи страны) в соответствии с Политикой конфиденциальности.

      Введите n, если вы не принимаете условия Политики конфиденциальности.

   Если вы не принимаете условия Лицензионного соглашения и Политики конфиденциальности, приложение Open Single Management Platform не будет обновлено.

Приложение Open Single Management Platform обновлено с версии 1.1 до версии 1.2.

Обновление компонентов Open Single Management Platform

KDT позволяет обновлять компоненты Open Single Management Platform (включая веб-плагины управления). В дистрибутив включены новые версии компонентов Open Single Management Platform.

Установка компонентов более ранней версии не поддерживается.

Чтобы обновить компоненты Open Single Management Platform:

1. Загрузите дистрибутив с новыми версиями компонентов Open Single Management Platform.
2. При необходимости экспортируйте текущую версию конфигурационного файла на устройстве администратора.

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

3. Обновите компоненты Open Single Management Platform:
   • Выполните команду для стандартного обновления компонентов Open Single Management Platform:

     ./kdt apply -k <полный_путь_к_архиву_обновлений_XDR> -i <полный_путь_к_конфигурационному_файлу>

   • Если версия установленного компонента Open Single Management Platform совпадает с версией компонента в дистрибутиве, обновление этого компонента пропускается. Выполните команду, чтобы принудительно обновить этот компонент с помощью флага force:

     ./kdt apply --force -k <полный_путь_к_архиву_обновлений_XDR> -i <полный_путь_к_конфигурационному_файлу>

4. Если дистрибутив содержит новую версию компонента Bootstrap, выполните команду, чтобы обновить кластер Kubernetes:

   ./kdt apply -k <полный_путь_к_архиву_обновлений_XDR> -i <полный_путь_к_конфигурационному_файлу> --force-bootstrap

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

5. Если появится новая версия Лицензионного соглашения и Политики конфиденциальности, прочтите Лицензионное соглашение и Политику конфиденциальности компонента Open Single Management Platform. Текст отображается в окне командной строки. Нажмите пробел, чтобы просмотреть следующий фрагмент текста. При отображении запроса введите следующие значения:
   1. Введите y, если вы понимаете и принимаете условия Лицензионного соглашения.

      Введите n, если вы не принимаете условия Лицензионного соглашения. Чтобы использовать компонент Open Single Management Platform, вам нужно принять условия Лицензионного соглашения.

   2. Введите y, если вы понимаете и принимаете условия Политики конфиденциальности и соглашаетесь, что ваши данные будут обрабатываться и пересылаться (в том числе в третьи страны) в соответствии с Политикой конфиденциальности.

      Введите n, если вы не принимаете условия Политики конфиденциальности.

   Чтобы обновить компонент Open Single Management Platform, вам нужно принять условия Лицензионного соглашения и Политики конфиденциальности.

После того как вы примете Лицензионное соглашение и Политику конфиденциальности, KDT обновит компоненты Open Single Management Platform.

Вы можете ознакомиться с Лицензионным соглашением и Политикой конфиденциальности компонента Open Single Management Platform после обновления. Файлы находятся в директории /home/kdt/ пользователя, который запускает установку Open Single Management Platform.

Добавление и удаление узлов кластера Kubernetes

Если нагрузка на компоненты Open Single Management Platform изменится, вы можете добавить или удалить целевые устройства, включенные в кластер Kubernetes (узлы кластера). KDT позволяет вам изменить количество узлов в существующем кластере Kubernetes.

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

Чтобы добавить узлы в кластер Kubernetes:

1. Экспортируйте текущий конфигурационный файл.

   Текущая версия конфигурационного файла сохраняется в указанной директории с указанным именем.

2. В разделе nodes экспортированного конфигурационного файла добавьте параметры одного или нескольких новых узлов (desc, type, host, kind, user и key) и сохраните конфигурационный файл.
3. Скопируйте открытый ключ на каждый новый узел (например, в директорию /home/<имя_пользователя>/.ssh) с помощью утилиты ssh-copy-id.
4. На устройстве администратора выполните следующую команду, чтобы применить измененный конфигурационный файл к кластеру Kubernetes. В команде укажите полный путь к этому конфигурационному файлу:

   ./kdt apply -i <полный_путь_к_конфигурационному_файлу>

5. Выполните следующую команду, чтобы обновить компонент Bootstrap с добавленными узлами. В команде укажите полный путь к транспортному архиву с компонентами Open Single Management Platform:

   ./kdt apply -k <полный_путь_к_транспортному_архиву> --force-bootstrap

Новые узлы добавлены в кластер Kubernetes.

Чтобы удалить узел из кластера Kubernetes:

1. Убедитесь, что на устройстве администратора установлена утилита kubectl.
2. Переместите конфигурационный файл, который используется для развертывания, в директорию /root/.kube.
3. Переименуйте конфигурационный файл в config.yaml.
4. Выполните следующую команду для отображения списка всех узлов кластера:

   kubectl get nodes

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

   kubectl drain <имя_узла> --delete-emptydir-data --ignore-daemonsets

6. Выполните следующую команду для удаления узла из кластера:

   kubectl delete node <имя_узла>

Указанный узел удален.

Контроль версий конфигурационного файла

При работе с Open Single Management Platform вам может потребоваться изменить параметры, которые были указаны в конфигурационном файле перед развертыванием Open Single Management Platform. Например, чтобы изменить объем дискового пространства, используемого для хранения данных Сервера администрирования, нужно изменить параметр ksc_state_size. Текущая версия конфигурационного файла с измененным параметром ksc_state_size обновляется в кластере Kubernetes.

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

Чтобы экспортировать текущую версию конфигурационного файла,

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

./kdt ec -e <имя_конфигурационного_файла_и_путь>

Текущая версия конфигурационного файла сохраняется в указанной директории с указанным именем.

Вы можете использовать экспортированный конфигурационный файл, например, при обновлении компонентов Open Single Management Platform или добавлении плагинов управления для приложениями "Лаборатории Касперского".

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

Удаление Open Single Management Platform

KDT позволяет вам удалить все компоненты Open Single Management Platform установленные в кластере Kubernetes, сам кластер, сервисы KUMA, установленные вне кластера, и другие артефакты, созданные во время развертывания или работы решения.

Чтобы удалить компоненты Open Single Management Platform и связанные с ними данные:

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

   ./kdt remove --all

   Эта команда удаляет следующие объекты и артефакты:

   • Все компоненты Open Single Management Platform, установленные в кластере Kubernetes, и сам кластер.

   • Учетную запись пользователя Open Single Management Platform, которая была создана с помощью KDT во время развертывания.

   • Базу данных, расположенную на отдельном сервере или внутри кластера, схемы СУБД и учетные записи СУБД, созданные с помощью KDT во время развертывания.

   • Сервисы KUMA, установленные вне кластера на устройствах, которые указаны в файле инвентаря.

   • Содержимое следующих директорий на целевых устройствах:
     • /var/spool/ksc/logs
     • /var/spool/ksc/backup
     • /var/spool/ksc/
     • /var/lib/k0s
     • /run/k0s
     • /etc/k0s/
     • /etc/containerd/
     • /var/lib/containerd/
     • /run/containerd/

   • Журналы событий, полученные во время установки и работы компонентов Open Single Management Platform.

   • Данные, относящиеся к компонентам Open Single Management Platform на устройстве администратора.

   Если устройство администратора не имеет сетевого доступа к целевому устройству, удаление компонентов прерывается. Вы можете восстановить доступ к сети и перезапустить удаление Open Single Management Platform. Также вы можете удалить компоненты Open Single Management Platform с целевых устройств вручную.

   Если вы используете несколько кластеров Kubernetes, управляемых контекстами, эта команда удаляет только текущий контекст Kubernetes, соответствующий кластер и компоненты Open Single Management Platform, установленные в кластере. Другие контексты и их кластеры с экземплярами Open Single Management Platform не удаляются.

2. Закройте порты, используемые Open Single Management Platform, которые были открыты при развертывании, если это необходимо. Эти порты не закрываются автоматически.

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

4. Удалите KDT и содержимое директорий /home/<user>/kdt и /home/<user>/.kdt.

Компоненты Open Single Management Platform, база данных и связанные с ними данные будут удалены, а порты, используемые Open Single Management Platform, закрыты.

Установленные на управляемых устройствах приложения "Лаборатории Касперского" невозможно удалить с помощью команды ./kdt remove. Подробнее об удалении приложений "Лаборатории Касперского" см. в документации к ним.

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

Удаление компонентов Open Single Management Platform вручную

Если устройство администратора не имеет сетевого доступа к целевому устройству, удаление компонентов Open Single Management Platform с помощью KDT прерывается. Вы можете восстановить доступ к сети и перезапустить удаление решения. Также вы можете удалить компоненты Open Single Management Platform с целевых устройств вручную.

Чтобы удалить компоненты Open Single Management Platform с целевых устройств вручную:

1. На целевом устройстве остановите службу k0s с помощью команды:

   /usr/local/bin/k0s stop

2. Сбросьте узлы кластера в исходное состояние с помощью команды:

   /usr/local/bin/k0s reset

3. Удалите содержимое следующих директорий:

   • Обязательные директории:

     • /etc/k0s/
     • /var/lib/k0s/
     • /usr/libexec/k0s/
     • /usr/local/bin/ (удалите только файл k0s)

   • Необязательные директории:

     • /var/lib/containerd/
     • /var/cache/k0s/
     • /var/cache/kubelet/
     • /var/cache/containerd/

     Вы можете удалить директории /var/lib/containerd/ и /var/cache/containerd/, если служба containerd используется только для работы Open Single Management Platform. Иначе ваши данные, содержащиеся в директориях /var/lib/containerd/ и /var/cache/containerd/, могут быть потеряны.

     Содержимое директорий /var/cache/k0s/, /var/cache/kubelet/ и /var/cache/containerd/ автоматически удаляется после перезапуска целевого устройства. Вам не нужно удалять содержимое этих директорий вручную.

4. Перезагрузите все целевые устройства.

Компоненты Open Single Management Platform удалены с целевых устройств.

Переустановка компонентов Open Single Management Platform

Во время установки Open Single Management Platform на устройстве администратора KDT отображает журнал событий установки, в котором видно, правильно ли установлены компоненты Open Single Management Platform.

После установки Open Single Management Platform вы можете запустить следующую команду, чтобы просмотреть список всех установленных компонентов:

./kdt status

Отображается список установленных компонентов. Правильно установленные компоненты имеют статус Успешно. Если не удалось установить компонент, этот компонент будет иметь статус Сбой.

Чтобы просмотреть полный журнал событий установки неправильно установленного компонента Open Single Management Platform, выполните команду:

./kdt status -l <название_компонента>

Также можно вывести всю диагностическую информацию о компонентах Open Single Management Platform с помощью следующей команды:

./kdt logs get --to-archive

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

Чтобы переустановить неправильно установленные компоненты Open Single Management Platform:

• Если вы не изменяли конфигурационный файл, выполните следующую команду и укажите тот же транспортный архив, который использовался при установке Open Single Management Platform:

  ./kdt apply -k <полный_путь_к_транспортному_архиву>

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

  ./kdt apply -k <полный_путь_к_архиву_транспорта> -i <полный_путь_к_конфигурационному_файлу>

KDT переустанавливает только неправильно установленные компоненты Open Single Management Platform.

Остановка узлов кластера Kubernetes

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

В виртуальной среде не выключайте виртуальные машины, на которых размещены активные узлы кластера Kubernetes.

Чтобы остановить многоузловой кластер Kubernetes (схема развертывания на нескольких узлах):

1. Войдите на рабочий узел и инициируйте плавное завершение работы. Повторите этот процесс для всех рабочих узлов.
2. Войдите на первичный узел и инициируйте плавное завершение работы.

Чтобы остановить кластер Kubernetes с одним узлом (схема развертывания на одном узле),

войдите на первичный узел и инициируйте плавное завершение работы.

Использование сертификатов для публичных служб Open Single Management Platform

Для работы с публичными службами Open Single Management Platform вы можете использовать самоподписанные или пользовательские сертификаты. По умолчанию Open Single Management Platform использует самоподписанные сертификаты.

Сертификаты необходимы для следующих публичных служб Open Single Management Platform:

• <console_host>.<smp_domain> – доступ к интерфейсу Консоли OSMP.
• <admsrv_host>.<smp_domain> – взаимодействие с Сервером администрирования.
• <api_host>.<smp_domain> – доступ к API Open Single Management Platform.

FQDN публичных служб Open Single Management Platform состоят из имен устройств и доменного имени, указанных в конфигурационном файле. Список адресов публичных служб Open Single Management Platform, для которых при развертывании определяются самоподписанные или пользовательские сертификаты, указывается в параметре установки pki_fqdn_list.

Пользовательский сертификат должен быть указан как файл в формате PEM, содержащий полную цепочку сертификатов (или только один сертификат) и незашифрованный закрытый ключ.

Вы можете указать промежуточный сертификат из инфраструктуры закрытых ключей (PKI) вашей организации. Пользовательские сертификаты для публичных служб Open Single Management Platform выдаются из этого пользовательского промежуточного сертификата. Также вы можете указать конечные сертификаты для каждой публичной службы. Если конечные сертификаты указаны только для части публичных служб, то для остальных публичных служб выдаются самоподписанные сертификаты.

Для публичных служб <console_host>.<smp_domain> и api.<smp_domain> пользовательские сертификаты можно указать только перед развертыванием в конфигурационном файле. Чтобы использовать пользовательский промежуточный сертификат, укажите параметры установки intermediate_bundle и intermediate_enabled.

Если вы хотите использовать конечные пользовательские сертификаты для работы с публичными службами Open Single Management Platform, укажите соответствующие параметры установки console_bundle, admsrv_bundle и api_bundle. Установите для параметра intermediate_enabled значение false и не указывайте параметр intermediate_bundle.

Для службы <admsrv_host>.<smp_domain> вы можете заменить выданный самоподписанный сертификат Сервера администрирования пользовательским сертификатом с помощью утилиты klsetsrvcert.

Автоматический перевыпуск сертификатов не поддерживается. Примите во внимание срок действия сертификата и обновите сертификат, когда срок его действия истечет.

Чтобы обновить пользовательские сертификаты:

1. На устройстве администратора выполните экспорт текущей версии конфигурационного файла.
2. В экспортированном конфигурационном файле укажите путь к новому пользовательскому промежуточному сертификату в параметре установки intermediate_bundle. Если вы используете конечные пользовательские сертификаты для каждой публичной службы, укажите параметры установки console_bundle, admsrv_bundle и api_bundle.
3. Выполните следующую команду и укажите полный путь к измененному конфигурационному файлу:

   ./kdt apply -i <полный_путь_к_конфигурационному_файлу>

Пользовательские сертификаты обновлены.

Расчет и изменение дискового пространства для хранения данных Сервера администрирования

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

• Информация об активах (устройствах).
• Информация о событиях, зарегистрированных на Сервере администрирования для выбранного клиентского устройства.
• Информация о домене, в котором находятся активы.
• Данные компонента Контроль приложений.
• Обновления. В папке общего доступа требуется дополнительно не менее 4 ГБ для хранения обновлений.
• Инсталляционные пакеты. При наличии на Сервере администрирования инсталляционных пакетов в папке общего доступа дополнительно потребуется количество места, равное суммарному размеру доступных для установки инсталляционных пакетов.
• Задачи удаленной установки. При наличии на Сервере администрирования задач удаленной установки на диске дополнительно потребуется количество места на диске, равное суммарному размеру устанавливаемых инсталляционных пакетов.

Расчет минимального дискового пространства для хранения данных Сервера администрирования

Минимальный объем дискового пространства, необходимый для хранения данных Сервера администрирования, можно приблизительно оценить по формуле:

(724 * C + 0.15 * E + 0.17 * A + U), КБ

где:

• C – количество активов (устройств).
• E – количество сохраняемых событий.
• A – суммарное количество объектов домена:
  • учетных записей устройств;
  • учетных записей пользователей;
  • учетных записей групп безопасности;
  • организационных подразделений.
• U – размер обновлений (не менее 4 ГБ).

Если опрос домена выключен, то "A" следует считать равным нулю.

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

Изменение дискового пространства для хранения данных Сервера администрирования

Объем свободного дискового пространства, выделяемого для хранения данных Сервера администрирования, указывается в конфигурационном файле перед развертыванием Open Single Management Platform (параметр ksc_state_size). Примите во внимание минимальное дисковое пространство, рассчитанное по формуле.

Чтобы проверить объем дискового пространства, используемого для хранения данных Сервера администрирования после установки Open Single Management Platform:

на устройстве администратора, на котором расположена утилита KDT, выполните команду:

./kdt invoke ksc --action getPvSize

Отображается объем необходимого свободного места на диске в гигабайтах.

Чтобы изменить объем дискового пространства для хранения данных Сервера администрирования после установки Open Single Management Platform:

на устройстве администратора, на котором расположена утилита KDT, выполните команду, указав необходимое свободное место на диске в гигабайтах (например, "50Gi"):

./kdt invoke ksc --action setPvSize --param ksc_state_size="<новый_объем_дискового_пространства>Gi"

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

Ротация секретов

KDT позволяет выполнять ротацию секретов, которые используются для подключения к кластеру Kubernetes, компонентам инфраструктуры Open Single Management Platform и СУБД. Период ротации этих секретов можно указать в соответствии с требованиями информационной безопасности вашей организации. Секреты находятся на устройстве администратора.

Секреты, которые используются для подключения к кластеру Kubernetes, включают клиентский сертификат и закрытый ключ. Секреты доступа к Реестру и СУБД включают соответствующие DSN.

Чтобы выполнить ротацию секретов для подключения к кластеру Kubernetes вручную,

на устройстве администратора, на котором расположена утилита KDT, выполните команду:

./kdt invoke bootstrap --action RotateK0sConfig

Новые секреты подключения к кластеру Kubernetes сгенерированы.

При обновлении Bootstrap секреты подключения к кластеру Kubernetes обновляются автоматически.

Чтобы выполнить ротацию секретов для подключения к Реестру вручную,

на устройстве администратора, на котором расположена утилита KDT, выполните команду:

./kdt invoke bootstrap --action RotateRegistryCreds

Новые секреты для подключения к Реестру сгенерированы.

Добавление устройств для установки дополнительных сервисов KUMA

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

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

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

./kdt invoke kuma --action addHosts --param hostInventory=<путь_к_файлу_инвентаря>

На устройствах, указанных в файле expand.inventory.yml, служебные каталоги, в которые добавляются файлы, необходимые для установки службы.

Пример дополнительного файла инвентаря KUMA для установки сервисов KUMA (файл expand.inventory.yml)

Добавление дополнительного хранилища, коллектора или коррелятора

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

Чтобы добавить дополнительное хранилище кластера, коллектор или коррелятор:

1. Войдите в Консоль KUMA.

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

   • В главном меню Консоли OSMP перейдите в Параметры → KUMA.
   • В браузере перейдите по адресу https://<kuma_host>.<smp_domain>:443.

     Адрес Консоли KUMA состоит из значений параметров kuma_host и smp_domain, указанных в конфигурационном файле.

2. В Консоли KUMA создайте набор ресурсов для каждого сервиса KUMA (хранилищ, коллекторов и корреляторов), который вы хотите установить на подготовленных устройствах.
3. Создайте сервисы для хранилищ, коллекторов и корреляторов в Консоли KUMA.
4. Получите идентификаторы сервисов для привязки созданных наборов ресурсов и сервисов KUMA:
   1. В главном меню Консоли KUMA перейдите в раздел Ресурсы → Активные сервисы.
   2. Выберите требуемый сервис KUMA и нажмите на кнопку Копировать идентификатор.
5. Установите сервисы KUMA на каждое подготовленное устройство, указанное в разделах kuma_storage, kuma_collector и kuma_correlator файла инвентаря expand.inventory.yml. На каждом устройстве в команде установки укажите идентификатор сервиса, соответствующий устройству. Выполните соответствующие команды, чтобы установить сервисы KUMA:
   • Команда установки хранилища:

     sudo /opt/kaspersky/kuma/kuma storage --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --install

   • Команда установки коллектора:

     sudo /opt/kaspersky/kuma/kuma collector --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the installed component>

   • Команда установки коррелятора:

     sudo /opt/kaspersky/kuma/kuma correlator --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the installed component> --install

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

   FQDN Ядра KUMA – это <kuma_host>.<smp_domain>.

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

Дополнительные сервисы KUMA установлены.

Добавление устройств в существующее хранилище

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

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

1. Войдите в Консоль KUMA.

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

   • В главном меню Консоли OSMP перейдите в Параметры → KUMA.
   • В браузере перейдите по адресу https://<kuma_host>.<smp_domain>:443.

     Адрес Консоли KUMA состоит из значений параметров kuma_host и smp_domain, указанных в конфигурационном файле.

2. Добавьте узлы в хранилище кластера. Для этого измените параметры существующего хранилища кластера:
   1. В разделе Ресурсы → Хранилища выберите существующее хранилище и его для изменения.
   2. В разделе Узлы кластера ClickHouse нажмите на Добавить узлы и в полях для нового узла укажите роли. Укажите соответствующие доменные имена устройств из раздела kuma_storage файла expand.inventory.yml, а затем укажите роли для новых узлов.
   3. Сохраните изменения.

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

3. Создайте сервисы хранилища для каждого добавленного узла хранилища кластера в Консоли KUMA и привяжите сервисы к хранилищу кластера.
4. Получите идентификаторы сервиса хранилища для каждого подготовленного устройства для установки сервисов KUMA:
   1. В главном меню Консоли KUMA перейдите в раздел Ресурсы → Активные сервисы.
   2. Выберите требуемый сервис KUMA и нажмите на кнопку Копировать идентификатор.
5. Установите сервис хранилища на каждое подготовленное устройство, указанное в разделе kuma_storage файла инвентаря expand.inventory.yml. На каждом устройстве в команде установки укажите идентификатор сервиса, соответствующий устройству. Выполните следующую команду, чтобы установить сервис хранилища:

   sudo /opt/kaspersky/kuma/kuma storage --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --install

   FQDN Ядра KUMA – это <kuma_host>.<smp_domain>.

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

Дополнительные устройства добавлены в хранилище кластера.

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

Замена устройства, использующего хранилище KUMA

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

1. Заполните файл expand.inventory.yml, указав параметры устройства, которое вы хотите заменить.
2. Выполните следующую команду, указав файл expand.inventory.yml для удаления устройства:

   ./kdt invoke kuma --action removeHosts --param hostInventory=<путь_к_файлу_инвентаря>

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

   ./kdt invoke kuma --action addHosts --param hostInventory=<путь_к_файлу_инвентаря>

4. Выполните шаги 2–6 инструкции по добавлению устройств для сервисов KUMA, чтобы добавить устройство с хранилищем KUMA.

Устройство с хранилищем KUMA заменено на другое.

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

Чтобы исправить ошибку при добавлении реплики шарда:

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

   /opt/kaspersky/kuma/clickhouse/bin/client.sh

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

2. Запустите команду, чтобы удалить данные об устройстве, которое вы хотите заменить:
   • Если доступно устройство с репликой того же шарда, которому принадлежит неправильно добавленная реплика, выполните команду:

     SYSTEM DROP REPLICA '<replica number of read-only node>' FROM TABLE kuma.events_local_v2

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

     SYSTEM DROP REPLICA '<replica number of read-only node>' FROM ZKPATH '/clickhouse/tables/kuma/<shard number of read-only node>/kuma/events_local_v2

3. Восстановите работу добавленного устройства с репликой с выполнив команду:

   SYSTEM RESTORE REPLICA kuma.events_local_v2

Работоспособность добавленного устройства с репликой восстановлена.

Настройка модели статусов инцидентов

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

Поддерживаются две модели статусов инцидентов:

1. Стандартная:
   • Новый

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

   • В обработке

     Этот статус означает, что аналитик начал работу над инцидентом или возобновил работу, изменив статус Отложен. Когда вы устанавливаете статус В обработке, инцидент назначается вам автоматически. Изменить статус В обработке можно на любой другой.

   • Отложен

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

   • Закрыт

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

     • Верное срабатывание.
     • Ложное срабатывание.
     • Низкий приоритет.

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

     Статус Закрыт можно изменить только на статус Новый. Если вы хотите вернуть закрытый инцидент в работу, измените его статус следующим образом: Закрыт → Новый → В обработке.

2. Совместимая с ГОСТ:
   • Новый

     Когда вы создаете инцидент или он создается автоматически, инцидент имеет статус Новый. Вы можете изменить статус инцидента на Анализ. Когда вы меняете статус Новый на Анализ, инцидент назначается вам автоматически.

   • Анализ

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

     Вы можете изменить статус инцидента на Локализация или Выполнен.

   • Локализация

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

     Вы можете изменить статус инцидента на Последствия или Выполнен.

   • Последствия

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

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

   • Ликвидация

     Этот статус означает, что выполняется устранение последствий инцидента.

     Вы можете изменить статус инцидента на Выполнен.

   • Выполнен

     Этот статус означает, что проводится оценка полноты выполненных действий на этапах Анализ, Локализация, Последствия и Ликвидация.

     Вы можете изменить статус инцидента на Закрыт, Анализ, Локализация, Последствия, Ликвидация.

   • Закрыт

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

     • Верное срабатывание.
     • Ложное срабатывание.
     • Низкий приоритет.

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

Чтобы сменить модель статусов на совместимую с ГОСТ:

1. В файле docker/compose/osmp.yaml укажите значение переменной окружения OSMP_WORKFLOW_ID.

   OSMP_WORKFLOW_ID: "gost"

2. В файле /plugins/irp/.env укажите значение переменной FEATURE_GOST_STATUS.

   FEATURE_GOST_STATUS=true

Статусы инцидентов не конвертируются при смене модели статуса. Не рекомендуется менять модель статусов, если у вас есть активные инциденты.