schemaType: ParameterSet
schemaVersion: 1.0.1
namespace: ""
name: bootstrap
project: xdr
nodes:
  - desc: cdt-primary1
    type: primary
    host: "<IPv4_первичного_узла>"
    access:
      ssh:
        user: "<имя_пользователя>" # По умолчанию root
        key: "<путь_к_закрытому_ключу>" # По умолчанию /root/.ssh/id_rsa
  - desc: cdt-w1
    type: worker
    host: "<IPv4_рабочего_узла_1>"
    access:
      ssh:
        user: "<имя_пользователя>"
        key: "<путь_к_закрытому_ключу>"
    kind: admsrv  # Сервер администрирования будет установлен на этом узле
  - desc: cdt-w2
    type: worker
    host: "<IPv4_рабочего_узла_2>"
    access:
      ssh:
        user: "<имя_пользователя>"
        key: "<путь_к_закрытому_ключу>"
    kuma_roles: ["storage"]  # Хранилище закреплено за этим узлом
  - desc: cdt-w3
    type: worker
    host: "<IPv4_рабочего_узла_3>"
    access:
      ssh:
        user: "<имя_пользователя>"
        key: "<путь_к_закрытому_ключу>"
parameters:
  - name: psql_dsn
    source:
      value: "postgres://<dbms_username>:<password>@<fqdn_СУБД>:<порт_СУБД>" # Если пароль содержит спецсимволы, их необходимо привести к URI кодировке
  - name: ingress_ip
    source:
      value: "<IPv4_шлюза_кластера_Kubernetes>" # Ранее зарезервированный ingress_ip
  - name: ssh_pk
    source:
      path: "<путь_к_закрытому_ключу_на_устройстве_администратора>"
  - name: admin_password
    source:
      value: "<пароль_учётной_записи_admin>"
  - name: core_disk_request
    source:
      value: 100Gi
  - name: metrics_disk_request
    source:
        value: 80Gi
  - name: inventory
    source:
      value: "/dev/null"  # Все сервисы KUMA будут внутри кластера Kubernetes
  - name: license
    source:
      value: "<путь_к_лицензионному_ключу>" # Рекомендуется файл переименовать в license.key
  - name: smp_domain
    source:
      value: "<доменное_имя>"
  - name: pki_host_list
    source:
      value: "admsrv api console kuma monitoring agentserver updater"
  - name: low_resources
    source:
      value: "false"
  - name: nwc-language
    source:
      value: "ruRu"  # Или "enUS"
  - name: skip_preflight_checks
    source:
      value: "false"
  - name: openbao_ha_mode
    source:
      value: "true"
  - name: grafana_admin_user
    source:
      value: <имя_пользователя>
  - name: grafana_admin_password
    source: 
      value: "ваш_пароль"
  - name: route_permissions_dryrun
    source:
      value: "true"

schemaType: ParameterSet
schemaVersion: 1.0.1
namespace: ""
name: bootstrap
project: xdr
nodes:
  - desc: cdt-1
    type: primary-worker
    host: "<IPv4_единственного_узла>"
    access:
      ssh:
        user: "<имя_пользователя>" # По умолчанию root
        key: "<путь_к_закрытому_ключу>" # По умолчанию /root/.ssh/id_rsa
parameters:
  - name: psql_dsn
    source:
      value: "postgres://<dbms_username>:<password>@<fqdn_СУБД_в_кластере>:<порт>"  # Если пароль содержит спецсимволы, их необходимо привести к URI кодировке
  - name: ingress_ip
    source:
      value: "<IPv4_шлюза_кластера_Kubernetes>" # Ранее зарезервированный ingress_ip
  - name: ssh_pk
    source:
      path: "<путь_к_закрытому_ключу>"
  - name: admin_password
    source:
      value: "<пароль_учётной_записи_admin>"
  - name: inventory
    source:
      value: "/dev/null" # Все сервисы KUMA будут внутри кластера Kubernetes
  - name: license
    source:
      value: "<путь_к_лицензионному_ключу>" # Рекомендуется файл переименовать в license.key
  - name: smp_domain
    source:
      value: "<доменное_имя>"
  - name: pki_host_list
    source:
      value: "admsrv api console kuma monitoring agentserver updater"
  - name: low_resources
    source:
      value: "true"
  - name: openbao_ha_mode
    source:
      value: "false"
  - name: default_class_replica_count
    source:
      value: 1
  - name: grafana_admin_user
    source:
      value: "<имя_пользователя>"
  - name: grafana_admin_password
    source:
      value: "<пароль_пользователя>"

1.1. Поддерживаемые версии

1.2. Аппаратные требования (на клиенте)

• RAM: ≥2 ГБ (x64)
• HDD: ≥2 ГБ свободного места
• CPU: ≥1 ГГц, поддержка SSE2

1.3. Необходимые лицензии

• Лицензия KES
• Для работы KATA Sandbox должно быть развернуто решение Kaspersky Anti Targeted Attack Platform версии 7.0 или выше, либо XDR 2.0 + и Sandbox 8.0+.

2.1. Настройка инсталляционного пакета

1. Откройте OSMP Web Console → Операции → Хранилища → Инсталляционные пакеты

2. Найдите пакет KES 12.7+

3. Перейдите в Параметры → Detection and Response

4. Включите: Sandbox

📸 Скриншот 1: Выбор компонента Sandbox c KES 12.7

5. (Рекомендуется) Включите: Настройки установки → Добавить путь к приложению в переменную окружения %PATH%

📸 Скриншот 2: Добавить путь к приложению в переменную окружения %PATH%

6. Нажмите «Обновить базы» → «Сохранить»

📸 Скриншот 3: Обновить базы

2.2. Создание задачи удалённой установки

1. Перейдите: Устройства → Задачи → Добавить

2. Выберите:

1. Приложение: Kaspersky Security Center
2. Тип задачи: Удалённая установка программы

3. Укажите устройства (вручную или из списка)

📸 Скриншот 4: Удаленная установка программы

4. Выберите:

1. Инсталляционный пакет: KES 12.7+
2. Агент администрирования: KSC Agent

5. Если агент уже установлен — выберите: «Учётная запись не требуется»

📸 Скриншот 5: Учетная запись не требуется (Агент администрирования уже установлен)

6. Нажмите «Готово» → «Запустить»

📸 Скриншот 6: После создания она автоматически переходит в состояние ожидания, поэтому её необходимо запустить вручную.

2.3. Добавление лицензии

Для активации KATA Sandbox вам потребуется лицензионный ключ, который включает в себе функциональность KATA или KEDR. Подробнее о доступных функциональностях см. в справке Kaspersky Anti Targeted Attack Platform.

1. Устройства → Задачи → Добавить → Добавление ключа

2. Выберите KES 12.7+, укажите устройства

📸 Скриншот 7: Добавление ключа KES

3. Выберите файл ключа → снимите галочку «Использовать как резервный»

📸 Скриншот 8: Использовать ключ в качестве резервного

3.1. Создание задачи

1. Устройства → Задачи → Добавить → Изменение состава компонентов

2. Выберите KES 12.7+ → укажите устройства

📸 Скриншот 9: выбор на «Изменение состава компонентов приложения».

3. В параметрах задачи включите: Detection and Response → Sandbox

📸 Скриншот 10: «Параметры приложения» и выберите компоненты «Detection and Response». Активируйте компонент «Sandbox»

4. Внесите изменения в задачу «Изменение состава компонентов приложения». Добавьте данные «Имя пользователя» и «Пароль» для её выполнения, чтобы избежать проблем в процессе.

📸 Скриншот 11: выбор на «Изменение состава компонентов приложения».

5. Запустите задачу

📸 Скриншот 12: Запустите созданную задачу.

4.1. Скачивание TLS-сертификата из OSMP

1. Войдите в OSMP Web Console (администратор)

2. Параметры → Тенанты, нажмите на название тенанта и выберите вкладку Параметры → Сертификаты.

3. В разделе Сертификат Сервера нажмите Экспорт.

4. В этом же разделе экспортируйте Сертификат Endpoint Agent, выберите сертификат либо сгенерируйте новый и нажмите Экспортировать. (При создании нового сертификата старый будет удален. Поэтому его нужно будет обновить во всех политиках, где он использовался.)

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

6. По итогу будут экспортированы два файла certificate.pem и certificate.pfx

4.2. Настройка политики

1. Устройства → Политики → Добавить → KES 12.7+

2. В мастере выберите стандартный режим

3. Перейдите: Параметры приложения → Встроенные агенты → Sandbox

4. Включите компонент

5. Выбираем Режим интеграции: KATA Sandbox

6. Выберите Тип отправки файлов на проверку.

Для работы KATA Sandbox в ручном режиме должно быть развернуто решение Kaspersky Anti Targeted Attack Platform версии 7.0 или выше. Для работы KATA Sandbox в автоматическом режим должно быть развернуто решение Kaspersky Anti Targeted Attack Platform версии 8.0 или выше, либо KEDR 8.0+.

7. Нажмите «Подключение к серверам Sandbox» → Настройки подключения

- Загрузите в раздел TLS-сертификат сервера ранее выгруженный сертификат certificate.pem

- Дополнительная защита подключения загрузите ранее выгруженный сертификат certificate.pfx и введите заданный пароль.

8. Укажите адрес agentserver. Его можно найти в том же разделе, где и Сертификат сервера.

📸 Скриншот 13: копируем адрес сервера

- Укажите адрес и порт 443

📸 Скриншот 14: указываем адрес сервера KEDR и порт

6. Нажмите «Сохранить»

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

📸 Скриншот 15: указываем адрес сервера KATA и порт

8. Детально описание доступно в онлайн-документации

5.1. Со стороны клиента (Агента)

1. Откройте клиент KES

2. Перейдите в раздел «Безопасность». Убедиться, что должен быть добавлен компонент Network Detection and Response (KATA). Он должен быть подсвечен зеленым цветом, что подтверждает его активацию и наличие лицензии.

📸 Скриншот 16: разделе «Безопасность» присутствует установленный компонент «Sandbox».

3. Перейти в раздел Мониторинг → Отчеты→ Network Detection and Response (KATA), либо в том же разделе Безопасность кликнуть по значку троеточия и выпадающем меню выбрать Открыть отчет.

5.2. Со стороны консоли OSMP

1. В свойствах устройства в Web Console (Активы (Устройства) → Управляемые устройства → ссылка <имя устройства> → Приложения → ссылка <название приложения Kaspersky Endpoint Security> → Общие → Компоненты).

📸 Скриншот 17: разделе «Безопасность» присутствует установленный компонент «Sandbox».

1.1. Поддерживаемые версии

1.2. Аппаратные требования (на клиенте)

• RAM: ≥2 ГБ (x64)
• HDD: ≥2 ГБ свободного места
• CPU: ≥1 ГГц, поддержка SSE2

1.3. Необходимые лицензии

• Лицензия KES
• Лицензия KEDR

📌 Обе лицензии нужно добавить отдельно, они не взаимозаменяемы. Либо можно использовать одну лицензию, которая включает функционал EDR и расширенную версию KES.

2.1. Настройка инсталляционного пакета

1. Откройте OSMP Web Console → Операции → Хранилища → Инсталляционные пакеты

2. Найдите пакет KES 12.1+

3. Выберите режим работы Kaspersky Endpoint Security для Windows:

- Стандартный - Это базовый режим, который используется по умолчанию. Он входит в состав EPP-решений от "Лаборатории Касперского", например, в Kaspersky Endpoint Security для бизнеса. Этот режим обеспечивает комплексную защиту рабочих станций и серверов от угроз, сетевых атак и мошенничества.

- EDR-агент - EDR-агент предназначен для интеграции с решениями Detection and Response от "Лаборатории Касперского" и EPP-решениями сторонних поставщиков. Например, он работает с Kaspersky Managed Detection and Response (MDR) и Kaspersky Anti Targeted Attack Platform (KATA). Также поддерживается интеграция с SIEM-решением Kaspersky Unified Monitoring and Analysis Platform (KUMA). В этом режиме отключены стандартные компоненты защиты, такие как защита от файловых и веб-угроз. Основную защиту компьютера обеспечивает стороннее EPP-решение. EDR-агент непрерывно следит за процессами, сетевыми соединениями и изменениями файлов, взаимодействуя с решениями Detection and Response.

- Легкий агент - Этот режим предназначен для защиты виртуальных сред. Легкий агент входит в состав Kaspersky Security для виртуальных и облачных сред. Он защищает виртуальные машины с гостевыми операционными системами, обеспечивая те же компоненты защиты, что и в стандартном режиме. Однако проверку на вирусы и вредоносные программы выполняет специальный компонент на отдельной виртуальной машине – SVM (Secure Virtual Machine). Таким образом, ресурсы виртуальной машины не расходуются на обеспечение безопасности.

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

4. Перейдите в Параметры → Detection and Response

5. Включите: Endpoint Detection and Response (KATA)

📸 Скриншот 1: Выбор компонента EDR до KES 12.8

📸 Скриншот 2: Выбор компонента EDR для KES 12.8+

6. (Рекомендуется) Включите: Настройки установки → Добавить путь к приложению в переменную окружения %PATH%

📸 Скриншот 3: Добавить путь к приложению в переменную окружения %PATH%

7. (Опционально) Нажмите «Обновить базы» → «Сохранить»

📸 Скриншот 4: Обновить базы

2.2. Создание задачи удалённой установки

1. Перейдите: Устройства → Задачи → Добавить

2. Выберите:

1. Приложение: Kaspersky Security Center
2. Тип задачи: Удалённая установка программы

3. Укажите устройства (вручную или из списка)

📸 Скриншот 5: Удаленная установка программы

4. Выберите:

1. Инсталляционный пакет: KES 12.1+
2. Агент администрирования: KSC Agent

5. Если агент уже установлен — выберите: «Учётная запись не требуется»

📸 Скриншот 6: Учетная запись не требуется (Агент администрирования уже установлен)

6. Нажмите «Готово» → «Запустить»

📸 Скриншот 7: После создания она автоматически переходит в состояние ожидания, поэтому её необходимо запустить вручную.

2.3. Добавление лицензий

⚠️ Важно: Добавьте обе лицензии отдельно!

Лицензия KES + EDR:

1. Устройства → Задачи → Добавить → Добавление ключа

2. Выберите KES 12.1+, укажите устройства

📸 Скриншот 8: Добавление ключа KES

3. Выберите файл ключа → снимите галочку «Использовать как резервный»

📸 Скриншот 9: Использовать ключ в качестве резервного

Лицензия KEDR:

1. Повторите шаги выше, но выберите ключ KEDR

📸 Скриншот 10: Добавление ключа EDR

3.1. Создание задачи

1. Устройства → Задачи → Добавить → Изменение состава компонентов

2. Выберите KES 12.1+ → укажите устройства

📸 Скриншот 11: выбор на «Изменение состава компонентов приложения».

3. В параметрах задачи включите: Detection and Response → Endpoint Detection and Response (KATA)

📸 Скриншот 12: «Параметры приложения» и выберите компоненты «Detection and Response». Активируйте компонент «Endpoint Detection and Response (KATA)» (Выбор компонента EDR до KES 12.8)

📸 Скриншот 13: Выбор компонента EDR для KES 12.8+

4. Внесите изменения в задачу «Изменение состава компонентов приложения». Добавьте данные «Имя пользователя» и «Пароль» для её выполнения, чтобы избежать проблем в процессе.

📸 Скриншот 14: выбор на «Изменение состава компонентов приложения».

5. Запустите задачу

📸 Скриншот 15: Запустите созданную задачу.

3.3. Добавление лицензии KEDR

1. Создайте задачу «Добавление ключа»

2. Выберите ключ KEDR → примените к тем же устройствам

📸 Скриншот 16: выбираем «Добавление ключа».

4.1. Настройка политики

1. Войдите в OSMP Web Console (администратор)

2. Перейдите в раздел Управление активами → Политики → KES 12.1+

3. Добавьте политику KES 12.1+

3. Непосредственно внутри самой политики перейти в Параметры приложения → Встроенные агенты → Endpoint Detection and Response Expert (on-premise).

4. Включите компонент

5. Выберите Endpoint Detection and Response Expert (версия 8.0 и выше)

6. В разделе Подключение к серверам сбора телеметрии жмем +Добавить → Выбрать сервер выбираем нужный нам сервер сбора телеметрии (коллектор).

📸 Скриншот 17: в политике настраиваем Подключение к серверам сбора телеметрии

Важно: Если клиенты подключаются и управляются напрямую сервером KEDR 8+ (OSMP/XDR), выбор серверов будет доступен, и все данные подставятся автоматически, включая адрес сервера сбора телеметрии и сертификаты. Если же агенты подключаются к отдельному серверу KSC и данные платформы не объединяются, адрес коллектора и сертификат необходимо будет загрузить из другого раздела. Этот процесс описан ниже.

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

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

9. Далее в разделе Подключение к серверам реагирования жмем +Добавить → Выбрать сервер выбираем сервер реагирования.

Важно: Если клиенты подключаются и управляются напрямую сервером KEDR 8+ (OSMP/XDR), выбор серверов будет доступен, и все данные подставятся автоматически, включая адрес сервера реагирования и сертификаты. Если же агенты подключаются к отдельному серверу KSC и данные платформы не объединяются, адрес сервера реагирования и сертификат необходимо будет загрузить из другого раздела. Этот процесс описан ниже.

📸 Скриншот 18: в политике настраиваем Подключение к серверам реагирования

10. Жмем Сохранить и закрыть

4.2. Если используется внешний сервер KSC

4.2.1. Подготовка к настройке политики

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

1. Перейдите в раздел Мониторинг → Ресурсы и сервисы → Работа с сервисами → Активные сервисы

2. Выберите тот коллектор, что отвечает за сбор телеметрии, на примере это встроенный коллектор [OOTB] Kaspersky EDR. После того как выбрали нужный коллектор нажмите правой кнопкой мыши и выберите Скачать сертификат, либо выполните как на картинке.

📸 Скриншот 19: разделе «Сертификат сервера» нажимаем «Экспортировать».

3. Необходимо скопировать адрес сервера сбора телеметрии, данный адрес необходимо будет указать при настройке политики как описано в предыдущем разделе 4.1. Настройка политики. Для этого жмем на коллектор встроенный коллектор [OOTB] Kaspersky EDR правой кнопкой мыши и выбираем Развернуть. В открывшемся окне необходимо скопировать скопировать адрес Connection gateway URL: ********, как на примере ниже.

📸 Скриншот 20: разделе «Сертификат сервера» нажимаем «Развернуть» и копируем адрес «Connection gateway».

4. На данном этапе был скопирован адрес Сервера сбора телеметрии (connection gateway) и выгружен сертификат [OOTB] Kaspersky EDR эти данные необходимо будет указать при настройке политики на KSC не объединённом с KEDR 8+ (OMSP/XDR).

5. Далее для настройки политики также понадобиться адрес Сервера реагирования и Сертификат Endpoint Agent.

6. Для этого перейдите Параметры → Тенанты, нажмите на название тенанта и выберите вкладку Параметры → Сертификаты.

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

8. Здесь в разделе Сертификат сервера экспортировать сам сертификат сервера нажав Экспортировать

9. По итогу будет экспортирован файл certificate.pem

10. Ниже экспортируйте Сертификат Endpoint Agent, выберите сертификат либо сгенерируйте новый и нажмите Экспортировать. (При создании нового сертификата старый будет удален. Поэтому его нужно будет обновить во всех политиках, где он использовался.) При экспорте потребуется указать пароль, так как сертификат будет Сертификат будет экспортирован в PFX-архив, защищенный паролем.

11. По итогу будет экспортирован файл certificate.pfx

📸 Скриншот 21: разделе «Параметры → Тенанты → Параметры → Сертификаты» где показано что от куда копировать и экспортировать.

4.2.2. Настройка политики на внешнем KSC

1. Перейдите в политику, в политике в разделе Подключение к серверам сбора телеметрии указывается полученный адрес connection gateway нажав на +Добавить → Новый сервер и порт 443

2. Нажав на Настройки подключения → Сертификат сервера загружается ранее выгруженный сертификат [OOTB] Kaspersky EDR . Также рекомендуем в разделе Дополнительная защита подключения указать ранее выгруженный сертификат для защиты подключения certificate.pfx.

3. Далее в политике необходимо настроить Подключение к серверам реагирования. Для этого необходимо будет добавить адрес сервера FQDN сервера агента и в разделе Настройки подключения добавить Сертификат сервера certificate.pem и загрузить в раздел Дополнительная защита выгруженный ранее сертификат certificate.pfx.

4. Нажимаем Сохранить и закрыть для завершения настройки политики.

5.1. Непосредственно на OSMP

1. Войдите в OSMP Web Console (администратор)

2. Перейдите: Активы (Устройства) → Анализ и реагирование в данном разделе так же, как и в разделе Администрирование и защита будут появляться все подключенные устройства. В данном разделе можно добавить колонки по которым можно отфильтровать агенты по следующему статусу:

- Телеметрия получена

- Статус телеметрии

- Статус EDR

- Последнее подключение к EDR

- Лицензия EDR

- Версия агента EDR

📸 Скриншот 22: разделе «Анализ и реагирование» начнут появляться «Агенты» со статусом «Нормальная активность».

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

📸 Скриншот 23: разделе «Поиск угроз» вывод собранной телеметрии с EDR агентов.

4. В свойствах устройства в Web Console (Активы (Устройства) → Управляемые устройства → ссылка <имя устройства> → Приложения → ссылка <название приложения Kaspersky Endpoint Security> → Общие → Компоненты).

📸 Скриншот 24: разделе «Безопасность» присутствует установленный компонент «Sandbox».

5.2. Со стороны клиента (Агента)

1. Откройте клиент KES

2. Перейдите в раздел «Безопасность». Убедиться, что должен быть добавлен компонент Endpoint Detection and Response Expert (on-premise). Он должен быть подсвечен зеленым цветом, что подтверждает его активацию и наличие лицензии.

📸 Скриншот 25: разделе «Безопасность» присутствует установленный компонент «Endpoint Detection and Response Expert (on-premise)».

3. Перейти в раздел Мониторинг → Отчеты→ Endpoint Detection and Response Expert (on-premise), либо в том же разделе Безопасность кликнуть по значку троеточия и выпадающем меню выбрать Открыть отчет.

📸 Скриншот 26: Варианты проверки статуса подключения компонента «Endpoint Detection and Response Expert (on-premise) к «Central Node».

1.1. Поддерживаемые версии

1.2. Аппаратные требования (на клиенте)

• CPU: ≥1 ГГц, поддержка SSE2
• RAM: ≥2 ГБ (x64)
• HDD: ≥2 ГБ свободного места

1.3. Необходимые лицензии

• Лицензия KESL+EDR

2.1. Настройка инсталляционного пакета

1. Откройте OSMP Web Console → Операции → Хранилища → Инсталляционные пакеты

2. Найдите пакет KESL 11.4+

3.Перейдите в Параметры и выберите режим использования приложения:

• Стандартном режим - Kaspersky Endpoint Security используется как автономное приложение для защиты рабочих станций и серверов под управлением операционных систем Linux.
• Легкий агент - Kaspersky Security для виртуальных в составе решения. Kaspersky Endpoint Security используется как компонент решения Kaspersky Security для виртуальных сред Легкий агент для защиты виртуальных машин с гостевыми операционными системами Linux.
• EDR-агент - Endpoint Detection and Response для совместной работы на защищаемых устройствах решений Detection and Response от "Лаборатории Касперского" и антивирусных приложений от сторонних поставщиков (далее также "режим Агента Endpoint Detection and Response").

📸 Скриншот 1: Выбор компонента Режима работы KESL 12.4+

4. Выполните дополнительные настройки в Консоли администрирования с детальным описанием можно ознакомиться в онлайн-документации

2.2. Создание задачи удалённой установки

1. Перейдите: Устройства → Задачи → Добавить

2. Выберите:

1. Приложение: Kaspersky Security Center
2. Тип задачи: Удалённая установка программы

3. Укажите устройства (вручную или из списка)

📸 Скриншот 2: Удаленная установка программы

4. Выберите:

1. Инсталляционный пакет: KESL 11.4+
2. Агент администрирования: KSC Agent

5. Если агент уже установлен — выберите: «Учётная запись не требуется»

📸 Скриншот 3: Учетная запись не требуется (Агент администрирования уже установлен)

6. Нажмите «Готово» → «Запустить»

📸 Скриншот 4: После создания она автоматически переходит в состояние ожидания, поэтому её необходимо запустить вручную.

2.3. Добавление лицензий

Лицензия KES + EDR:

1. Устройства → Задачи → Добавить → Добавление ключа

Для интеграции с компонентами Kaspersky Anti Targeted Attack Platform вам нужно активировать решение Kaspersky Anti Targeted Attack Platform (см. подробнее в справке решения). Активировать компоненты приложения Kaspersky Endpoint Security, обеспечивающие интеграцию, не требуется, основные лицензии Kaspersky Endpoint Security включают в себя эту функциональность.

2. Выберите KESL 11.4+, укажите устройства

📸 Скриншот 5: Добавление ключа KESL

3. Выберите файл ключа → снимите галочку «Использовать как резервный»

📸 Скриншот 6: Использовать ключ в качестве резервного

4.1. Настройка политики

1. Войдите в OSMP Web Console (администратор)

2. Перейдите в раздел Управление активами → Политики → KES 12.1+

3. Добавьте политику KES 12.1+

3. Непосредственно внутри самой политики перейти в Параметры приложения → Встроенные агенты → Endpoint Detection and Response Expert (on-premise).

4. Включите компонент

5. Выберите Endpoint Detection and Response Expert (версия 8.0 и выше)

6. В разделе Подключение к серверам сбора телеметрии жмем +Добавить → Выбрать сервер выбираем нужный нам сервер сбора телеметрии (коллектор).

📸 Скриншот 7: в политике настраиваем Подключение к серверам сбора телеметрии

Важно: Если клиенты подключаются и управляются напрямую сервером KEDR 8+ (OSMP/XDR), выбор серверов будет доступен, и все данные подставятся автоматически, включая адрес сервера сбора телеметрии и сертификаты. Если же агенты подключаются к отдельному серверу KSC и данные платформы не объединяются, адрес коллектора и сертификат необходимо будет загрузить из другого раздела. Этот процесс описан ниже.

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

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

9. Далее в разделе Подключение к серверам реагирования жмем +Добавить → Выбрать сервер выбираем сервер реагирования.

Важно: Если клиенты подключаются и управляются напрямую сервером KEDR 8+ (OSMP/XDR), выбор серверов будет доступен, и все данные подставятся автоматически, включая адрес сервера реагирования и сертификаты. Если же агенты подключаются к отдельному серверу KSC и данные платформы не объединяются, адрес сервера реагирования и сертификат необходимо будет загрузить из другого раздела. Этот процесс описан ниже.

📸 Скриншот 8: в политике настраиваем Подключение к серверам реагирования

10. Жмем Сохранить и закрыть

4.2. Если используется внешний сервер KSC

4.2.1. Подготовка к настройке политики

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

1. Перейдите в раздел Мониторинг → Ресурсы и сервисы → Работа с сервисами → Активные сервисы

2. Выберите тот коллектор, что отвечает за сбор телеметрии, на примере это встроенный коллектор [OOTB] Kaspersky EDR. После того как выбрали нужный коллектор нажмите правой кнопкой мыши и выберите Скачать сертификат, либо выполните как на картинке.

📸 Скриншот 9: разделе «Сертификат сервера» нажимаем «Экспортировать».

3. Необходимо скопировать адрес сервера сбора телеметрии, данный адрес необходимо будет указать при настройке политики как описано в предыдущем разделе 4.1. Настройка политики. Для этого жмем на коллектор встроенный коллектор [OOTB] Kaspersky EDR правой кнопкой мыши и выбираем Развернуть. В открывшемся окне необходимо скопировать скопировать адрес Connection gateway URL: ********, как на примере ниже.

📸 Скриншот 10: разделе «Сертификат сервера» нажимаем «Развернуть» и копируем адрес «Connection gateway».

4. На данном этапе был скопирован адрес Сервера сбора телеметрии (connection gateway) и выгружен сертификат [OOTB] Kaspersky EDR эти данные необходимо будет указать при настройке политики на KSC не объединённом с KEDR 8+ (OMSP/XDR).

5. Далее для настройки политики также понадобиться адрес Сервера реагирования и Сертификат Endpoint Agent.

6. Для этого перейдите Параметры → Тенанты, нажмите на название тенанта и выберите вкладку Параметры → Сертификаты.

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

8. Здесь в разделе Сертификат сервера экспортировать сам сертификат сервера нажав Экспортировать

9. По итогу будет экспортирован файл certificate.pem

10. Ниже экспортируйте Сертификат Endpoint Agent, выберите сертификат либо сгенерируйте новый и нажмите Экспортировать. (При создании нового сертификата старый будет удален. Поэтому его нужно будет обновить во всех политиках, где он использовался.) При экспорте потребуется указать пароль, так как сертификат будет Сертификат будет экспортирован в PFX-архив, защищенный паролем.

11. По итогу будет экспортирован файл certificate.pfx

📸 Скриншот 11: разделе «Параметры → Тенанты → Параметры → Сертификаты» где показано что от куда копировать и экспортировать.

4.2.2. Настройка политики на внешнем KSC

1. Перейдите в политику, в политике в разделе Подключение к серверам сбора телеметрии указывается полученный адрес connection gateway нажав на +Добавить → Новый сервер и порт 443

2. Нажав на Настройки подключения → Сертификат сервера загружается ранее выгруженный сертификат [OOTB] Kaspersky EDR . Также рекомендуем в разделе Дополнительная защита подключения указать ранее выгруженный сертификат для защиты подключения certificate.pfx.

3. Далее в политике необходимо настроить Подключение к серверам реагирования. Для этого необходимо будет добавить адрес сервера FQDN сервера агента и в разделе Настройки подключения добавить Сертификат сервера certificate.pem и загрузить в раздел Дополнительная защита выгруженный ранее сертификат certificate.pfx.

4. Нажимаем Сохранить и закрыть для завершения настройки политики.

5.1. Непосредственно на OSMP

1. Войдите в OSMP Web Console (администратор)

2. Перейдите: Активы (Устройства) → Анализ и реагирование в данном разделе так же, как и в разделе Администрирование и защита будут появляться все подключенные устройства. В данном разделе можно добавить колонки по которым можно отфильтровать агенты по следующему статусу:

- Телеметрия получена

- Статус телеметрии

- Статус EDR

- Последнее подключение к EDR

- Лицензия EDR

- Версия агента EDR

📸 Скриншот 22: разделе «Анализ и реагирование» начнут появляться «Агенты» со статусом «Нормальная активность».

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

📸 Скриншот 23: разделе «Поиск угроз» вывод собранной телеметрии с EDR агентов.

4. В свойствах устройства в Web Console (Активы (Устройства) → Управляемые устройства → ссылка <имя устройства> → Приложения → ссылка <название приложения Kaspersky Endpoint Security> → Общие → Компоненты).

📸 Скриншот 24: разделе «Безопасность» присутствует установленный компонент «Sandbox».

5.2. Со стороны клиента (Агента)

Откройте клиент и используйте команду kesl-control --app-info

📸 Скриншот 12: результаты вывода команды «kesl-control» со статусом подключения EDR агента.

1.1. Поддерживаемые версии

1.2. Аппаратные требования (на клиенте)

• CPU: ≥1 ГГц, поддержка SSE2
• RAM: ≥2 ГБ (x64)
• HDD: ≥2 ГБ свободного места

1.3. Необходимые лицензии

• Лицензия KESL
• Для работы KATA Sandbox должно быть развернуто решение Kaspersky Anti Targeted Attack Platform версии 7.0 или выше, либо OSMP/XDR 2.0 + и Sandbox 8.0+.

2.1. Настройка инсталляционного пакета

1. Откройте OSMP Console → Операции → Хранилища → Инсталляционные пакеты

2. Найдите пакет KESL 12.2+

3.Перейдите в Параметры

4. Выполните дополнительные настройки в Консоли администрирования с детальным описанием можно ознакомиться в онлайн-документации

2.2. Создание задачи удалённой установки

1. Перейдите: Устройства → Задачи → Добавить

2. Выберите:

1. Приложение: Kaspersky Security Center
2. Тип задачи: Удалённая установка программы

3. Укажите устройства (вручную или из списка)

📸 Скриншот 1: Удаленная установка программы

4. Выберите:

1. Инсталляционный пакет: KESL 12.2+
2. Агент администрирования: KSC Agent

5. Если агент уже установлен — выберите: «Учётная запись не требуется»

📸 Скриншот 2: Учетная запись не требуется (Агент администрирования уже установлен)

6. Нажмите «Готово» → «Запустить»

📸 Скриншот 3: После создания она автоматически переходит в состояние ожидания, поэтому её необходимо запустить вручную.

2.3. Добавление лицензий

Лицензия KESL:

1. Устройства → Задачи → Добавить → Добавление ключа

Для интеграции с компонентами Kaspersky Anti Targeted Attack Platform вам нужно активировать решение Kaspersky Anti Targeted Attack Platform (см. подробнее в справке решения). Активировать компоненты приложения Kaspersky Endpoint Security, обеспечивающие интеграцию, не требуется, основные лицензии Kaspersky Endpoint Security включают в себя эту функциональность.

2. Выберите KESL 12.2+, укажите устройства

📸 Скриншот 4: Добавление ключа KESL

3. Выберите файл ключа → снимите галочку «Использовать как резервный»

📸 Скриншот 5: Использовать ключ в качестве резервного

4.1. Скачивание TLS-сертификата из OSMP

1. Войдите в OSMP Web Console (администратор)

2. Параметры → Тенанты, нажмите на название тенанта и выберите вкладку Параметры → Сертификаты.

3. В разделе Сертификат Сервера нажмите Экспорт.

4. В этом же разделе экспортируйте Сертификат Endpoint Agent, выберите сертификат либо сгенерируйте новый и нажмите Экспортировать. (При создании нового сертификата старый будет удален. Поэтому его нужно будет обновить во всех политиках, где он использовался.)

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

6. По итогу будут экспортированы два файла certificate.pem и certificate.pfx

4.2. Настройка политики

1. Устройства → Политики → Добавить → KES 12.7+

2. В мастере выберите стандартный режим

3. Перейдите: Параметры приложения → Встроенные агенты → Sandbox

4. Включите компонент

5. Выбираем Режим интеграции: KATA Sandbox

6. Выберите Тип отправки файлов на проверку.

Для работы KATA Sandbox в ручном режиме должно быть развернуто решение Kaspersky Anti Targeted Attack Platform версии 7.0 или выше. Для работы KATA Sandbox в автоматическом режим должно быть развернуто решение Kaspersky Anti Targeted Attack Platform версии 8.0 или выше, либо KEDR 8.0+.

7. Нажмите «Подключение к серверам Sandbox» → Настройки подключения

- Загрузите в раздел TLS-сертификат сервера ранее выгруженный сертификат certificate.pem

- Дополнительная защита подключения загрузите ранее выгруженный сертификат certificate.pfx и введите заданный пароль.

8. Укажите адрес agentserver. Его можно найти в том же разделе, где и Сертификат сервера.

📸 Скриншот 6: копируем адрес сервера

- Укажите адрес и порт 443

📸 Скриншот 7: указываем адрес сервера KEDR и порт

6. Нажмите «Сохранить»

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

📸 Скриншот 8: указываем адрес сервера KATA и порт

8. Детально описание доступно в онлайн-документации

5.1. Со стороны клиента (Агента)

1. Откройте клиент и используйте команду kesl-control --app-info

📸 Скриншот 9: результаты вывода команды «kesl-control» со статусом подключения EDR агента.

2. В свойствах устройства в Web Console (Активы (Устройства) → Управляемые устройства → ссылка <имя устройства> → Приложения → ссылка <название приложения Kaspersky Endpoint Security> → Общие → Компоненты).

📸 Скриншот 10: результаты вывода команды «kesl-control» со статусом подключения EDR агента.

1.1. Что такое плейбук

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

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

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

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

Например, если в системе появился критический алерт, плейбук может:

1. определить устройство, на котором произошло событие;
2. получить сведения о пользователе;
3. изолировать устройство от сети;
4. запустить дополнительную проверку;
5. отправить уведомление ответственному специалисту.

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

1.2. Чем плейбук отличается от обычного действия

Отдельное действие выполняет только одну операцию:

• изолировать устройство;
• получить информацию о процессе;
• отправить уведомление.

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

Именно поэтому плейбуки являются одним из основных инструментов автоматизации реагирования в Kaspersky EDR Expert и OSMP.

Зачем нужны плейбуки

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

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

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

Например, при обнаружении вредоносного процесса плейбук может автоматически:

• определить устройство, на котором произошло событие;
• получить информацию о пользователе;
• изолировать устройство от сети;
• запустить IOC Scan;
• отправить уведомление ответственному сотруднику.

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

Какие задачи решают плейбуки

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

Автоматическое реагирование

Выполнение заранее определенных действий сразу после появления алерта или инцидента.

Например:

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

Обогащение информации

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

• получить информацию об устройстве;
• определить пользователя;
• найти связанные алерты;
• извлечь хэш, IP-адрес или имя процесса.

Проверка условий

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

Например:

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

Оркестрация действий

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

Получен алерт        │        ▼Получить HostID        │        ▼Получить информацию о пользователе        │        ▼Изолировать устройство        │        ▼Запустить IOC Scan        │        ▼Отправить уведомление

Когда стоит использовать плейбуки

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

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

Перед запуском скриптов экспорта и импорта необходимо рассчитать требуемые ресурсы и дисковое пространство. Ошибка на этом этапе приведет к прерыванию процесса миграции из-за нехватки места или перегрузки процессора.

Состав переносимых данных

Данные в KATA/KEDR 7.1 разделены на три логических слоя. Базовая миграция (Этапы 1 и 2) переносит только алерты, инциденты и объекты из S3. Сырая телеметрия переносится только при явном запуске Этапа 3.

1. Расчет места на внешнем диске (Базовая миграция)

Внешний диск (Transport Storage) используется для временного хранения данных при переносе между серверами.

Формула расчета:

Disk_size_GB = 2 * ( (N_ioa_alerts + N_ioc_alerts) * 0.00005 + N_ext_alerts * 0.2 + 0.8 * Storage_GB + 1 )

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

Альтернатива: Если вы выбираете сценарий переноса телеметрии без внешнего хранилища (напрямую через сеть), требования к внешнему SSD-массиву не применяются. Вместо этого потребуются дополнительные ресурсы CPU/RAM на целевом сервере OSMP (см. раздел 4 ниже).

Где взять переменные:

Пример расчета:
Вводные: Storage_GB = 200, N_ioa_alerts = 40 000, N_ioc_alerts = 10 000, N_ext_alerts = 0.
Расчет: 2 * ( (50000 * 0.00005) + 0 + (0.8 * 200) + 1 ) = 2 * ( 2.5 + 160 + 1 ) = 327 ГБ.
Результат: Требуется внешний диск объемом не менее 330 ГБ.

2. Требования к целевому серверу (OSMP)

На время выполнения скрипта импорта целевой сервер Kaspersky EDR Expert 8.1 должен иметь свободные ресурсы для распаковки архивов и записи в БД.

Необходимо временно зарезервировать:

⚠️ Правило масштабирования: При планировании постоянного дискового пространства на новом сервере выделите вдвое больше места, чем рассчитано по «Руководству по масштабированию». Это необходимо для стабильной работы баз данных и сервисов KUMA после завершения импорта.

Важно: Указанные 4 ядра CPU и 4 ГБ RAM — это базовые требования для импорта конфигурации и истории. Если вы планируете перенос телеметрии, необходимо дополнительно зарезервировать ресурсы согласно разделу 4 (от +6 до +18 ядер CPU и от +4 до +12 ГБ RAM в зависимости от выбранного сценария).

3. Требования для переноса телеметрии

Если требуется перенести сырую телеметрию (Этап 3), необходимо рассчитать эффективное количество хостов и подготовить высокоскоростное хранилище.

Шаг 1. Расчет эффективного количества хостов (K)

Разные ОС генерируют разный объем телеметрии. Для расчета используется формула приведения к единому знаменателю:

K = A + 3*B + 3*C + 20*D

• A — рабочие станции и терминальные серверы Windows.
• B — рабочие станции и терминальные серверы Linux.
• C — рабочие станции и терминальные серверы macOS.
• D — серверы (физические или виртуальные, любая ОС).

Шаг 2. Расчет объема данных и места на диске

Объем данных, выгружаемых из Elasticsearch, рассчитывается по формуле:

ES_Data_Volume = (K / 15000) * (460GB * <период хранения в днях>) / 0.65

Параметр <период хранения в днях> соответствует значению telemetry-keep-days при запуске скрипта экспорта.

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

Disk_size_Telemetry = ES_Data_Volume * 2.6

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

• Тип: SSD.
• Конфигурация: RAID 0.
• Производительность: 200 ROPS (чтение), 200 WOPS (запись), пропускная способность ~1 ГБ/сек.

Пример расчета:
Вводные: Парк: 2000 Win (A), 100 Lin (B), 0 Mac (C), 50 Серверов (D). Период хранения: 14 дней.

1. Считаем K: 2000 + (3*100) + (3*0) + (20*50) = 3300.
2. Считаем ES_Data: (3300 / 15000) * (460 * 14) / 0.65 ≈ 2180 ГБ.
3. Считаем Диск: 2180 * 2.6 ≈ 5668 ГБ.
   Результат: Требуется внешний SSD-массив объемом не менее 5,7 ТБ.

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

Если вы планируете переносить сырую телеметрию (Этап 3), необходимо заранее выбрать один из двух архитектурных сценариев. От этого выбора зависят требования к оборудованию, время миграции и даже выбор основного сценария перехода.

Сравнительная таблица сценариев переноса телеметрии

Дополнительные ресурсы для Сценария Б (Без внешнего хранилища)

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

Критическое ограничение: Если выбран сценарий переноса телеметрии без внешнего хранилища, развертывание Kaspersky EDR Expert 8.1 на том же сервере, где ранее был развернут KEDR 7.1 (Сценарий 1), невозможно. Старый сервер KATA должен оставаться в сети на протяжении всего процесса импорта телеметрии, а в Сценарии 1 сервер KEDR 7.1 удаляется до начала импорта.

Решение: Если вы хотите использовать Сценарий 1 (экономия железа) — выбирайте перенос телеметрии с внешним хранилищем.

5. Ограничения и запреты

Что НЕ переносится автоматически:

• Файлы из карантина.
• Завершенные задачи (если результат не сохранен в хранилище).
• Неактивные пользователи Active Directory.
• Исключения IOA (требуют ручного импорта из файла excludes.json после миграции).

Запрещенные действия во время экспорта и импорта:
До завершения процесса импорта категорически запрещено:

1. Выполнять действия с образами ОС в Sandbox или менять правила Sandbox.
2. Добавлять, изменять или удалять правила запрета, IOC, IOA, YARA и исключения IOA.
3. Добавлять или удалять Endpoint Agent, менять их группы и теги.
4. Изменять список паролей архивов.

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

Официальная документация Kaspersky EDR Expert 8.1 выделяет четыре сценария перехода с KATA/KEDR 7.1. Выбор сценария зависит от доступных аппаратных ресурсов, текущей архитектуры и допустимого времени простоя (Downtime).

Сводная таблица сценариев

Детальный разбор сценариев

Сценарий 1: Использование того же сервера (Экономия ресурсов, максимальный простой)

Этот сценарий допускает повторное использование оборудования, но требует существенного простоя сервера. OSMP развертывается непосредственно на существующем сервере KATA/KEDR 7.1 после этапа экспорта данных.

Критическая особенность:

⚠️ Важно: Даже если вы используете тот же сервер для развертывания OSMP, для запуска скрипта импорта (kata-osmp-import.sh) все равно потребуется дополнительное устройство Linux. Скрипт импорта не может выполняться на том же узле, где работает OSMP.

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

Альтернативы:
• Использовать Сценарий 2 (Отдельный сервер) + телеметрия без внешнего хранилища.
• Использовать Сценарий 1 + телеметрия с внешним хранилищем (предварительно выгрузив .dump файлы до удаления KEDR 7.1).

Оценка времени простоя:

• Без телеметрии: до 6 часов.
• С телеметрией: зависит от объема данных. Около 24 часов для конфигурации с 5000 агентов Endpoint Agent и глубиной хранения 30 дней.

Высокоуровневый алгоритм (Фазы):

1. Фаза Экспорта (на старом KEDR 7.1): Подключение внешнего диска ➔ Запуск kata-osmp-export.sh --step first ➔ Отключение интеграций и агентов ➔ Запуск --step second ➔ (Опционально) --step third для телеметрии ➔ Отключение диска.
2. Фаза Разрушения и Создания: Удаление KEDR 7.1 с диска ➔ Развертывание OSMP на этом же "железе".
3. Фаза Импорта (на временном Linux-сервере): Подключение диска к временному Linux-серверу с Docker ➔ Запуск kata-osmp-import.sh --step first ➔ Ручной импорт исключений IOA и переключение агентов через KSC ➔ Запуск --step second.
4. Финал: Перенос телеметрии (отдельным сценарием).

Сценарий 2: Использование отдельного сервера (Минимизация простоя)

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

Логика минимизации простоя:
Процесс разделен на этапы, чтобы старый KEDR 7.1 продолжал защищать периметр как можно дольше:

1. Сохранение данных Этапа 1 (конфигурации, правила) и их импорт в новый OSMP.
2. Переключение агентов Endpoint Agent на новый сервер через политики Kaspersky Security Center. Именно этот период считается временем простоя.
3. Перенос исторических данных (Этап 2) и телеметрии (Этап 3). На этом этапе OSMP уже полноценно работает, а старый сервер можно выводить из эксплуатации.

Сценарий 3: Миграция распределенного решения (Кластер KATA)

Применяется, если текущая инфраструктура развернута в виде кластера (Primary Central Node, Secondary Central Node, Embedded SCN). Главная цель — перенести данные так, чтобы сохранить изоляцию и иерархию тенантов в новой OSMP.

Специфика и жесткие ограничения:

1. Один диск на всех. Для переноса данных должен использоваться строго один внешний диск. Скрипт экспорта последовательно запускается на каждом узле кластера, диск физически перемещается между ними.
2. Маппинг тенантов. Перед импортом необходимо вручную создать тенанты в OSMP и составить JSON-файл конфигурации (tenant_config.json), сопоставляя узлы SCN с тенантами OSMP (строго 1-к-1).
3. Импорт через корень. Импорт всегда начинается через узел OSMP, содержащий корневой тенант. Данные со SCN распределяются по иерархии автоматически.
4. Нюанс с глобальными правилами. Глобальные YARA-правила или пароли для архивов, созданные на SCN, при миграции всегда переносятся в корневой тенант сервера OSMP.

Пример файла tenant_config.json:

{
  "globalTenantName": "Root tenant",
  "tenants": [
    { "scnName": "embedded_scn", "xdrTenantName": "embedded_scn" },
    { "scnName": "scn", "xdrTenantName": "scn" },
    { "scnName": "scn_2", "xdrTenantName": "scn_2" }
  ]
}

Важно: Тенант с именем embedded_scn в этом файле всегда указывает на главный сервер управления — Primary Central Node (PCN).

Сценарий 4: Разделение на KATA 8.0 и Kaspersky EDR Expert 8.1

Начиная с версии 8.1, функциональность KEDR становится частью Kaspersky EDR Expert, а KATA остается отдельным решением. Этот сценарий описывает переход с единого решения на два независимых продукта.

Порядок действий:

1. Развертывание нового сервера Kaspersky EDR Expert 8.1.
2. Перенос данных EDR из KATA 7.1 в новый Kaspersky EDR Expert 8.1.
3. Обновление старой KATA 7.1 до версии 8.0.

   Критически важно: После обновления KATA до 8.0 функциональность и данные KEDR на этом сервере станут недоступны.

4. Переключение серверов Sandbox. В связи с переносом функционала EDR, общее потребное количество серверов Sandbox должно перераспределиться между двумя системами.

Ограничения для кластера в этом сценарии:

• Обновите KATA до версии 8.0 только ПОСЛЕ развертывания всех узлов Kaspersky EDR Expert и переноса всех данных KEDR.
• Поэтапный перенос данных (от узла к узлу) не поддерживается. Скрипт переноса должен сначала экспортировать данные со всех серверов и только после этого импортировать их.

Итоговый алгоритм принятия решения

Используйте эту инструкцию для выбора целевого сценария:

Шаг 1. Оценка текущей архитектуры

• Если у вас развернут кластер (PCN + SCN) ➔ Выбирайте Сценарий 3.
• Если у вас один узел (Central Node) ➔ Переходите к Шагу 2.

Шаг 2.1. Если планируется перенос телеметрии — выберите способ передачи:

• Если есть быстрый SSD-массив (RAID 0, ~1 ГБ/сек) или сеть медленная ➔ Телеметрия с внешним хранилищем (доступны все 4 сценария миграции).
• Если нет SSD, но есть быстрая сеть (10 Гбит/с+) и готовы выделить CPU/RAM ➔ Телеметрия без внешнего хранилища (Сценарий 1 недоступен, выбирайте Сценарий 2, 3 или 4).

Шаг 2. Оценка аппаратных ресурсов и требований бизнеса

• Если нужно минимизировать простой и есть ресурсы ➔ Выбирайте Сценарий 2 (Отдельный сервер).
• Если нет ресурсов на новый сервер ➔ Выбирайте Сценарий 1 (Тот же сервер). Закладывайте окно простоя на выходные.
• Если бизнес требует архитектурно разделить SIEM (KATA) и EDR ➔ Выбирайте Сценарий 4 (Разделение на два решения).

Универсальные ограничения (Запрет на изменения)

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

1. Добавлять, изменять или удалять пользователей.
2. Выполнять действия с образами ОС в Sandbox или менять правила Sandbox.
3. Добавлять, изменять или удалять правила запрета.
4. Добавлять, изменять или удалять IOC, IOA-правила, YARA-правила, исключения IOA и расписание проверки IOC.
5. Добавлять или удалять Endpoint Agent, менять их группы и теги.
6. Изменять список паролей архивов.

Что НЕ переносится автоматически:

• История алертов (переносятся только специфические метаданные).
• Завершенные задачи (если результат не сохранен в хранилище).
• Неактивные пользователи и учетные записи, связанные с Active Directory.
• Файлы из карантина.

Все действия по монтированию внешних дисков и запуску скриптов миграции должны выполняться строго в режиме Technical Support Mode. Этот режим останавливает основные службы записи KATA и делает снятие слепков данных безопасным.

Критическое правило: Все действия по монтированию/размонтированию внешних дисков, а также запуск скриптов миграции (kata-osmp-export.sh и kata-osmp-import.sh) должны выполняться строго в режиме Technical Support Mode. Как войти в этот режим — используйте штатные средства обслуживания KATA (см. документацию по эксплуатации вашей версии).

Вариант А: Физический диск (USB / SATA)

Подходит, если у вас физический сервер (Bare Metal) или к виртуальной машине проброшен RAW-диск.

Инструкции по монтированию и размонтированию физического диска

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

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

   lsblk
   sudo fdisk -l

   Пример найденного устройства: /dev/sdb1
3. Смените формат устройства на файловую систему Ext4, чтобы подготовить диск к записе данных:

   sudo mkfs.ext4 /dev/<disk>

   ВНИМАНИЕ: Эта команда полностью удалит все данные с диска!

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

   sudo mkdir -p /mnt/external_disk

5. Выполните следующую команду (зависит от файловой системы диска):

   sudo mount /dev/<диск> /mnt/external_disk

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

sudo umount /mnt/external_disk

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

Вариант Б: Сетевая папка (Samba / Windows Share)

Самый популярный сценарий для виртуальных сред (VMware, Hyper-V, KVM), где нет возможности подключить USB-накопитель.

Инструкции по созданию общего ресурса

Чтобы создать общий ресурс Samba (на отдельном Linux-сервере):

1. Установите Samba:

   sudo apt update
   sudo apt install samba samba-common-bin

2. Добавьте пользователя Samba с созданием домашней папки для этого пользователя. Эта папка будет служить общей папкой.

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

   sudo useradd -m -d /home/<SHARE_FOLDER> -s /bin/bash <USER_NAME>

3. Задайте пароль и активируйте пользователя:

   sudo smbpasswd -a <USER_NAME>
   sudo smbpasswd -e <USER_NAME>

4. Добавьте следующий блок в файл конфигурации /etc/samba/smb.conf:

   [<SHARE_FOLDER>]
   comment = Сетевой ресурс
   path = /home/<SHARE_FOLDER>
   read only = no
   browseable = yes
   guest ok = no

   где SHARE_FOLDER – имя общей директории.
5. Перезапустите сервис:

   sudo systemctl restart smbd nmbd

Чтобы создать общий ресурс Windows (cmd / PowerShell):

1. Убедитесь, что консоль запущена от имени администратора.
2. Создайте пользователя и задайте пароль:

   net user <USER_NAME> <PASSWORD> /add /expires:never

3. Создайте папку и установите общий доступ к ней:

   mkdir <SHARE_FOLDER>
   icacls <SHARE_FOLDER> /inheritance:r
   icacls <SHARE_FOLDER> /grant "Everyone:(OI)(CI)F"

4. Создайте общий ресурс для пользователя:

   net share <SHARE_NAME>=<SHARE_FOLDER> /grant:<USER_NAME>,full

Инструкции по монтированию и размонтированию сетевого ресурса

Этот метод предназначен для SMB/CIFS (Windows Share / Samba). Он подходит для разового подключения. После перезагрузки системы соединение будет потеряно.

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

1. Скачайте и установите следующие три пакета:
   • libtalloc2_2.4.2-1~bpo12+1_amd64.deb
   • libwbclient0_4.9.5+dfsg-5+deb10u3astra.ce4_amd64.deb
   • cifs-utils_6.8-2+deb10u1+ci202212062128+astra2_amd64.deb

   ℹ️ Примечание для закрытых контуров (Astra Linux): Не изменяйте файл source.list. Чтобы установить программное обеспечение, скачайте необходимые пакеты .deb из общедоступных репозиториев или из частных репозиториев, поддерживаемых вашей организацией.

2. Создайте точку монтирования:

   sudo mkdir -p <PATH_FOLDER>

3. Монтируйте сетевой ресурс:

   sudo mount -t cifs //<SERVER>/<SHARE_FOLDER> /<PATH_FOLDER> -o username=<NAME>,password=<PASSWORD>,vers=2.1

   
   Где:
   • SERVER – IP-адрес сервера или его сетевое имя.
   • SHARE_FOLDER – имя общей директории.
   • PATH_FOLDER – локальный путь к точке монтирования.
   • NAME – имя пользователя в Windows/Samba.
   • PASSWORD – пароль пользователя.
   • 2.1 – рекомендуемая версия протокола.
   Пример команды:
   

   sudo mount -t cifs //<IP-адрес>/Share /mnt/share -o username=<имя пользователя>,password=<пароль>,vers=2.1

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

sudo umount <PATH_FOLDER>

После завершения переноса данных рекомендуется удалить пакет cifs-utils и его зависимости.

Чтобы удалить пакет cifs-utils и его зависимости, выполните следующую команду:

sudo apt remove --purge cifs-utils && sudo apt autoremove -y

Если вы планируете переносить сырую телеметрию (Этап 3) и выбрали Сценарий Б: Перенос телеметрии без внешнего хранилища (напрямую через сеть), необходимо заранее учесть дополнительные требования. Этот сценарий предполагает прямое чтение телеметрии из старого Elasticsearch сервера KATA/KEDR 7.1 через сеть с использованием коллектора KUMA.

Критическое ограничение: Если выбран сценарий переноса телеметрии без внешнего хранилища, развертывание Kaspersky EDR Expert 8.1 на том же сервере, где был развернут KEDR 7.1 (Сценарий 1 миграции), невозможно. Старый сервер KATA должен оставаться в сети на протяжении всего процесса импорта телеметрии.

7.1. Предварительные условия

Для успешного выполнения этого сценария убедитесь, что выполнены следующие условия:

• У вас есть два отдельных сервера: KEDR 7.1 на платформе KATA и Kaspersky EDR Expert 8.1 на OSMP.
• Между серверами обеспечена высокая пропускная способность сети (рекомендуется 10 Гбит/с и выше).
• У вас есть временная лицензия на XDR, дающая право на настройку коннекторов импорта (запрашивается через Службу технической поддержки).
• Вы понимаете, что коллектор KUMA нельзя разворачивать в кластере Kubernetes OSMP.
• У вас есть отдельный Linux-сервер для установки коллектора KUMA (рекомендуется) или достаточно ресурсов на узле OSMP.
• DNS-сервер настроен корректно: запись *.kuma_host.smp_domain существует и правильно настроена.
• На сервере KATA установлено и работает решение KATA/KEDR 7.1 с накопленной телеметрией.

7.2. Понимание индексов Elasticsearch

Прежде чем планировать ресурсы, необходимо понять, что такое индексы Elasticsearch в контексте KATA/KEDR и как определить их количество в вашей системе.

7.2.1. Что такое индексы Elasticsearch?

В KATA/KEDR 7.1 телеметрия хранится в базе данных Elasticsearch. Индекс — это логическая единица хранения данных, аналогичная таблице в реляционной базе данных. Каждый индекс содержит телеметрию за определенный период времени или определенного типа.

Типичная структура индексов в KATA/KEDR 7.1:

• Индексы создаются автоматически по мере накопления телеметрии
• Обычно каждый индекс соответствует определенному периоду (например, день или неделя)
• Имена индексов имеют формат: kaspersky_edr_events_YYYY.MM.DD или подобный
• Количество индексов зависит от:
  • Глубины хранения телеметрии (параметр telemetry-keep-days)
  • Периода ротации индексов (настройки Elasticsearch)
  • Объема накопленной телеметрии

7.2.2. Как определить количество индексов в вашей системе

Чтобы узнать точное количество индексов в вашем KATA/KEDR 7.1, выполните следующие действия:

Шаг 1. Подключитесь к серверу KATA по SSH.

Шаг 2. Выполните команду для получения списка индексов:

docker exec -t $(docker ps -q -f name=elasticsearch.1) curl localhost:9200/_cat/indices?h=index,store.size

Шаг 3. Проанализируйте вывод команды. Пример вывода:

12345

Шаг 4. Подсчитайте количество строк (индексов) в выводе. Это и есть количество индексов, которые нужно будет импортировать.

7.2.3. Типичные сценарии

Сценарий 1: Небольшая инфраструктура (1-5 индексов)

• Глубина хранения: 7-14 дней
• Количество конечных точек: до 1000
• Ресурсы: Отдельный сервер с 5-10 ядер CPU, 1 ГБ RAM
• Время импорта: Несколько часов

Сценарий 2: Средняя инфраструктура (5-20 индексов)

• Глубина хранения: 14-30 дней
• Количество конечных точек: 1000-5000
• Ресурсы: Отдельный сервер с 10-20 ядер CPU, 2-4 ГБ RAM
• Время импорта: 1-3 дня (импорт партиями по 5 индексов)

Сценарий 3: Крупная инфраструктура (20+ индексов)

• Глубина хранения: 30+ дней
• Количество конечных точек: 5000+
• Ресурсы: Отдельный сервер с 20+ ядер CPU, 4+ ГБ RAM
• Время импорта: Несколько дней (импорт партиями по 5 индексов)

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

7.3. Требования к ресурсам

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

Требования к ресурсам отдельного Linux-сервера для коллектора:

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

💡 Совет: Если вы не хотите выделять отдельный сервер, можно установить коллектор прямо на узел OSMP. Но тогда требования к ресурсам OSMP возрастают: +6 ядер CPU / +4 ГБ RAM для 1 индекса или +12 ядер CPU / +8 ГБ RAM для 5 индексов.

7.4. Ограничения и рекомендации

• Рекомендуется использовать не более пяти коннекторов одновременно. Если требуется импортировать более пяти индексов, дождитесь завершения текущего импорта в коллектор, замените индексы следующим набором (до пяти), обновите конфигурацию коннектора и запустите его снова.
• Импорт телеметрии занимает много времени (может длиться несколько часов или дней в зависимости от объема данных), но не влияет на работу Kaspersky EDR Expert — система уже полноценно функционирует и обрабатывает новые события.
• После завершения импорта коннектор можно удалить, а отдельный сервер (если он использовался) можно убрать из кластера KUMA.

7.5. Пошаговая инструкция

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

• Этап 1. Подготовка архива к экспорту из KEDR 7.1 — подраздел «Подготовка сервера KATA для переноса телеметрии без внешнего хранилища» (открытие порта Elasticsearch, получение учетных данных).
• Этап 2. Импорт данных в Kaspersky EDR Expert 8.1 — подраздел «Импорт телеметрии без внешнего хранилища» (настройка коллектора KUMA, мониторинг, завершение миграции).

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

• Завершен раздел «Предварительная подготовка» (обновлены Endpoint Agent, получены пакеты, рассчитаны ресурсы, выбран сценарий миграции).
• Внешнее хранилище подготовлено и смонтировано (см. раздел 6 «Подготовка внешнего хранилища»).
• Сервер KATA/KEDR 7.1 переведен в режим Technical Support Mode.
• У вас есть необходимые файлы из набора пакетов для миграции:
  • kata-osmp-export.sh
  • img_kata_osmp_migrate.tar
  • gateway-migration_v2.0.+.tar (для сценария с внешним хранилищем)

Важно: Во время процесса экспорта категорически запрещено вносить изменения в KATA/KEDR 7.1:

• Добавлять, изменять или удалять пользователей
• Выполнять действия с образами ОС в Sandbox или менять правила Sandbox
• Добавлять, изменять или удалять правила запрета, IOC, IOA, YARA
• Добавлять или удалять Endpoint Agent, менять их группы и теги
• Изменять список паролей архивов

Находясь в режиме Technical Support Mode, поместите в рабочую директорию на сервере KATA следующие файлы из набора пакетов для миграции:

• kata-osmp-export.sh — скрипт экспорта
• img_kata_osmp_migrate.tar — архив TAR, содержащий Docker-образ для экспорта

Убедитесь, что скрипт имеет права на выполнение. Если нет, назначьте их командой:

chmod +x kata-osmp-export.sh

На этом шаге экспортируются данные, необходимые для запуска OSMP и репликации рабочего состояния KEDR 7.1 (конфигурация, правила, списки агентов).

Что экспортируется на этом шаге:

• Список активных (включенных) пользователей
• Список имен образов, включенных в набор данных Sandbox, и пользовательские правила Sandbox
• Правила запрета, IOC-правила, пользовательские IOA-правила, пользовательские YARA-правила
• Пароли к архивам, используемые при проверке антивирусом и Sandbox
• Расписание IOC-проверок
• Список Endpoint Agent, их группы и теги

Команда для запуска:

./kata-osmp-export.sh --step first --migration-dir /mnt/external_disk

Где /mnt/external_disk — путь к точке монтирования вашего внешнего хранилища.

💡 Важное замечание про IOA: Скрипт автоматически экспортирует исключения IOA в отдельный файл excludes.json в формате, совместимом с политиками Endpoint Agent. Этот файл будет находиться среди экспортированных данных в директории ioa. Его нужно будет вручную импортировать в политики KES после миграции (см. Этап 2).

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

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

Выполните следующие действия:

1. Отключите KEDR 7.1 от всех внешних интеграций (SIEM, TI, сторонние API).
2. Отключите Endpoint Agent в параметрах политики:
   • Удалите сертификаты Endpoint Agent
   • Включите проверку подлинности сертификатов
   После этого Endpoint Agent на конечных точках не сможет подключиться к старому серверу KEDR 7.1.

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

На этом шаге экспортируются исторические данные и дополнительные параметры.

Что экспортируется на этом шаге:

• База данных алертов
• Дополнительные данные, связанные с алертами
• Хранилище (данные для расследования, загруженные вручную файлы и файлы, полученные с помощью задачи get)
• Шаблоны уведомлений по электронной почте

Команда для запуска:

./kata-osmp-export.sh --step first --migration-dir /mnt/external_disk

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

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

Для кого этот шаг:

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

Что экспортируется на этом шаге:

• Сырая телеметрия из Elasticsearch за указанный период

Команда для запуска:

./kata-osmp-export.sh --step third --migration-dir /mnt/external_disk

Дополнительно можно указать параметры:

• --telemetry-max-processes <количество> — ограничение количества процессов
• --telemetry-keep-days <количество дней> — глубина выгрузки телеметрии

Данные телеметрии будут размещены по пути migration-dir/nodes/[GUID узла]/archive_source/elasticsearch/ в файлах .dump.

💡 Совет: Для определения оптимального значения --telemetry-keep-days используйте формулу расчета из раздела «Требования для переноса телеметрии».

После успешного завершения всех необходимых этапов экспорта, в режиме Technical Support Mode безопасно отключите (размонтируйте) внешний диск или сетевой ресурс от сервера KEDR 7.1.

Для физического диска:

sudo umount /mnt/external_disk

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

Для сетевого ресурса (Samba/Windows Share):

sudo umount /mnt/external_disk

После завершения миграции рекомендуется удалить пакет cifs-utils в целях безопасности:

sudo apt remove --purge cifs-utils && sudo apt autoremove -y

Если вы выбрали Сценарий Б: Перенос телеметрии без внешнего хранилища (напрямую через сеть), необходимо подготовить старый сервер KATA/KEDR 7.1 для прямого чтения телеметрии через сеть.

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

1.8.1. Проверка необходимых файлов

Убедитесь, что на сервере KATA существуют следующие файлы:

ls -l /etc/kaspersky/node.json
ls -l /home/swarm_user/.ssh/id_rsa

Если файлы отсутствуют, обратитесь в Службу технической поддержки.

1.8.2. Создание директории для скрипта

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

mkdir /home/admin/elastic_script_dir

1.8.3. Загрузка Docker-образа

Скопируйте на сервер архив TAR, содержащий образ Docker kata_osmp_migrate, и выполните следующую команду:

docker load -i ./img_kata_osmp_migrate.tar

Скопируйте значение Loaded image в выводе команды (например, registry.kata.zvx.com:5000/kaspersky/kata/management/kata_osmp_migrate:d0a217b), которое затем будет необходимо использовать на следующем шаге вместо migrate_image:tag.

1.8.4. Генерация скрипта и получение учетных данных

Запустите образ в режиме генерации скрипта:

sudo docker run --rm \
 -v /home/admin/elastic_script_dir:/elastic_script_dir \
 -v /etc/kaspersky:/etc/kaspersky \
 -v /home/swarm_user/.ssh:/home/swarm_user/.ssh \
 --network kata_prod_network \
 migrate_image:tag \
 generate-elastic-script \
 --elastic-script-dir /elastic_script_dir

Важно: Замените migrate_image:tag на значение, полученное на предыдущем шаге (например, registry.kata.zvx.com:5000/kaspersky/kata/management/kata_osmp_migrate:d0a217b).

После генерации скрипта в консоль выводятся данные, необходимые для коллектора KUMA:

• Конечная точка Elasticsearch (endpoint)
• Пользователь Elasticsearch
• Пароль Elasticsearch
• SSL-сертификат Elasticsearch

SSL-сертификат будет расположен по адресу:

/home/admin/elastic_script_dir/conf.d/elastic.crt

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

1.8.5. Открытие внешнего доступа

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

cd /home/admin/elastic_script_dir

Запустите скрипт в режиме open:

sudo ./kata-elastic-access.sh open

В результате выполнения этой команды открывается внешний порт Elasticsearch. Сервер KATA готов к переносу телеметрии.

Elasticsearch будет доступен по адресу:

https://<host>:8888/kata/elastic/

Индексы Elasticsearch будут доступны по адресу:

https://<host>:8888/kata/elastic/_cat/indices?v&s=index:desc

1.8.6. Получение списка индексов

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

docker exec -t $(docker ps -q -f name=elasticsearch.1) curl localhost:9200/_cat/indices?h=index,store.size

После выполнения этих действий сервер KATA готов к приему запросов от коллектора KUMA. Переходите к Этапу 2 для настройки импорта.

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

• Завершен Этап 1 (экспорт данных из KATA/KEDR 7.1)
• Развернут новый сервер Kaspersky EDR Expert 8.1 на OSMP (для Сценария 2) ИЛИ удален старый KEDR 7.1 и установлена OSMP на том же сервере (для Сценария 1)
• Подготовлен отдельный Linux-сервер для импорта (или используется старый KEDR 7.1, если он еще не удален)
• На сервере импорта установлен Docker
• Внешнее хранилище с архивом миграции доступно для сервера импорта
• Получена временная лицензия на XDR (если планируется перенос телеметрии)

Важно: Если вы используете Сценарий 1 (Тот же сервер), последовательность действий следующая:

1. Выполнить экспорт (Этап 1)
2. Удалить KEDR 7.1 с диска
3. Развернуть OSMP на этом же сервере
4. Подготовить отдельный временный Linux-сервер для импорта
5. Выполнить импорт (Этап 2)

Вам потребуется отдельный Linux-сервер для выполнения скрипта импорта. Это может быть:

• Вариант А: Отдельная виртуальная или физическая машина
• Вариант Б: Старый сервер KEDR 7.1 (если он еще не удален и на нем установлен Docker)

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

💡 Совет: Если вы используете старый сервер KEDR 7.1 в качестве сервера импорта, Docker на нем уже установлен. Это самый быстрый вариант — не нужно разворачивать новую машину.

Проверка установки Docker:

docker --version

Если Docker не установлен, обратитесь к документации вашей ОС для установки.

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

• kata-osmp-import.sh — скрипт импорта
• img_kata_osmp_migration_importer.tar — архив TAR, содержащий Docker-образ для импорта

Убедитесь, что скрипт имеет права на выполнение:

chmod +x kata-osmp-import.sh

Подключите внешнее хранилище с архивом миграции к серверу импорта. Используйте те же команды монтирования, что и на Этапе 1 (раздел 6 «Подготовка внешнего хранилища»).

Для физического диска:

sudo mkdir -p /mnt/external_disk
sudo mount /dev/sdX /mnt/external_disk

Для сетевого ресурса (Samba/Windows Share):

sudo mkdir -p /mnt/external_disk
sudo mount -t cifs //<SERVER>/<SHARE_FOLDER> /mnt/external_disk -o username=<USER>,password=<PASS>,vers=2.1

Убедитесь, что архив миграции доступен:

ls -la /mnt/external_disk

Вы должны увидеть директорию migration-dir с экспортированными данными.

2.4.1. Подготовка к запуску импорта

Перед запуском скрипта импорта необходимо выполнить ряд критически важных действий на сервере Kaspersky EDR Expert 8.1. Без этих шагов импорт не запустится.

2.4.1.1. Установка cnab gateway-migration

Gateway-migration — это шлюз импорта данных, который создает необходимые сертификаты для безопасного взаимодействия между сервером импорта и OSMP.

Шаг 1. Подключитесь к серверу Kaspersky EDR Expert 8.1 по SSH.

Шаг 2. Проверьте, установлен ли gateway-migration:

./bin/kdt state -l gateway-migration

Шаг 3. Если gateway-migration не установлен, выполните установку из архива TAR:

./bin/kdt apply -k gateway-migration_<версия>.tar
./bin/kdt invoke gateway-migration -a start

💡 Пример: Если у вас файл gateway-migration_v2.0.123.tar, команда будет:

./bin/kdt apply -k gateway-migration_v2.0.123.tar
./bin/kdt invoke gateway-migration -a start

Шаг 4. После запуска шлюза будут созданы три сертификата, которые необходимо сохранить на отдельном сервере Linux (сервере импорта):

• YYYY-MM-DDThh_mm_ss-ca.crt — CA-сертификат
• tls.crt — TLS-сертификат
• tls.key — TLS-ключ

Важно: Сертификаты создаются в директории, где запущен gateway-migration. Найдите их и скопируйте на сервер импорта в отдельную директорию, например /home/admin/certs/.

# На сервере OSMP - найдите сертификаты
find / -name "*.crt" -path "*/gateway-migration/*" 2>/dev/null
find / -name "*.key" -path "*/gateway-migration/*" 2>/dev/null

# Скопируйте на сервер импорта
scp /path/to/certs/*.crt user@import-server:/home/admin/certs/
scp /path/to/certs/*.key user@import-server:/home/admin/certs/

2.4.1.2. Получение API-токена Kaspersky EDR Expert

API-токен требуется для импорта определенных объектов (например, пользователей, шаблонов уведомлений).

Шаг 1. Откройте веб-интерфейс Kaspersky EDR Expert 8.1.

Шаг 2. Перейдите в раздел Настройки → API-токены.

Шаг 3. Нажмите на кнопку Добавить токен и укажите имя токена (например, migration-token).

Шаг 4. В поле Срок действия укажите минимально достаточный срок (например, 7 дней).

Шаг 5. В разделе Методы API установите флажки для следующих методов:

• GET:/api/v1/tenants
• GET:/api/v1/notifications/incident/template/default
• POST:/api/v1/notifications/incident/template
• POST:/api/v3/kuma/resources/*/create
• POST:KEDR Migration

Шаг 6. Нажмите Создать, затем Копировать и закрыть.

Критически важно: Токен будет показан только один раз и скопирован в буфер обмена. Сохраните его в надежном месте на сервере импорта, например в файле /home/admin/api-token.txt. В дальнейшем скопировать его будет невозможно!

2.4.1.3. Создание migration-url

Migration-url — это специальный URL для доменного имени (FQDN) хоста Kaspersky EDR Expert. Он используется скриптом импорта для подключения к OSMP.

Шаг 1. Определите FQDN вашего сервера Kaspersky EDR Expert 8.1:

hostname -f

Пример вывода: xdr.company.local

Шаг 2. Сформируйте migration-url. Он должен начинаться с https://migrate.:

https://migrate.<FQDN>

Пример: для fqdn=xdr.company.local → --migration-url https://migrate.xdr.company.local

Шаг 3. Добавьте соответствующую DNS-запись на вашем DNS-сервере:

• Тип записи: A или CNAME
• Имя: migrate (или migrate.xdr.company.local)
• Значение: IP-адрес сервера Kaspersky EDR Expert 8.1

Шаг 4. Проверьте доступность migration-url с сервера импорта:

curl -k https://migrate.xdr.company.local

💡 Совет: Если у вас нет возможности настроить DNS, можно временно добавить запись в файл /etc/hosts на сервере импорта:

echo "<IP-адрес-OSMP> migrate.xdr.company.local" >> /etc/hosts

2.4.1.4. Добавление тенантов

Перед импортом необходимо создать тенанты в Kaspersky EDR Expert 8.1, в которые будут импортированы данные.

Для режима одного узла (Single Node):

Шаг 1. Откройте веб-интерфейс Kaspersky EDR Expert 8.1.

Шаг 2. Перейдите в раздел Настройки → Тенанты.

Шаг 3. Выберите Корневой тенант, нажмите на кнопку Добавить.

Шаг 4. Укажите имя тенанта (например, Root tenant) и нажмите Добавить.

При запуске скрипта импорта используйте параметр --tenant-name:

--tenant-name "Root tenant"

💡 Совет: Если имя тенанта содержит пробел, его необходимо заключить в кавычки.

Для режима мультитенантности (кластер KATA):

Используйте файл конфигурации tenant_config.json, который должен быть создан заранее (см. раздел «Выбор сценария миграции» → «Сценарий 3»).

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

{
  "globalTenantName": "Root tenant",
  "tenants": [
    {
      "scnName": "embedded_scn",
      "xdrTenantName": "embedded_scn"
    },
    {
      "scnName": "scn",
      "xdrTenantName": "scn"
    },
    {
      "scnName": "scn_2",
      "xdrTenantName": "scn_2"
    }
  ]
}

Важно: Требуется тенант с именем embedded_scn, который указывает на главный сервер управления — Primary Central Node (PCN).

При запуске скрипта импорта используйте параметр --tenant-config-path:

--tenant-config-path /path/to/tenant_config.json

2.4.1.5. Подготовка сервера импорта

На сервере импорта создайте директорию для сертификатов и API-токена:

mkdir -p /home/admin/certs

Скопируйте в эту директорию:

• Три сертификата из шага 2.4.1.1 (ca.crt, tls.crt, tls.key)
• Файл с API-токеном (api-token.txt)

Убедитесь, что права доступа корректны:

chmod 600 /home/admin/certs/*
chmod 600 /home/admin/api-token.txt

На этом шаге импортируются данные конфигурации, правила и списки агентов. После этого шага новый Kaspersky EDR Expert 8.1 будет готов к приему агентов.

Команда для запуска (одиночный узел):

./kata-osmp-import.sh \
  --step first \
  --migration-dir /mnt/external_disk \
  --migration-url https://migrate.xdr.company.local \
  --api-token $(cat /home/admin/api-token.txt) \
  --ca-cert /home/admin/certs/ca.crt \
  --tls-cert /home/admin/certs/tls.crt \
  --tls-key /home/admin/certs/tls.key \
  --tenant-name "Root tenant"

Где:

• /mnt/external_disk — путь к точке монтирования внешнего хранилища
• https://migrate.xdr.company.local — migration-url из шага 2.4.1.3
• /home/admin/api-token.txt — файл с API-токеном из шага 2.4.1.2
• /home/admin/certs/ — директория с сертификатами из шага 2.4.1.1

Для кластера KATA (распределенное решение):

Если вы мигрируете кластер KATA (PCN + SCN), используйте параметр --tenant-config-path вместо --tenant-name:

./kata-osmp-import.sh \
  --step first \
  --migration-dir /mnt/external_disk \
  --migration-url https://migrate.xdr.company.local \
  --api-token $(cat /home/admin/api-token.txt) \
  --ca-cert /home/admin/certs/ca.crt \
  --tls-cert /home/admin/certs/tls.crt \
  --tls-key /home/admin/certs/tls.key \
  --tenant-config-path /path/to/tenant_config.json

💡 Напоминание: Файл tenant_config.json должен быть создан заранее (см. раздел «Выбор сценария миграции» → «Сценарий 3»).

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

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

2.6.1. Обновление агентов Endpoint Agent (если необходимо)

Если версии агентов Endpoint Agent слишком ранние и не обеспечивают совместимость с Kaspersky EDR Expert 8.1, их необходимо обновить.

Важно: Поддержка передачи телеметрии реализована только в актуальных версиях Endpoint Agent (начиная с KES 12.12 и KESL 12.4).

2.6.2. Ручной импорт исключений IOA

Скрипт экспорта автоматически выгрузил исключения IOA в файл excludes.json, но они не импортируются автоматически. Необходимо выполнить ручной импорт.

Шаг 1. Найдите файл excludes.json в архиве миграции:

find /mnt/external_disk -name "excludes.json"

Обычно он расположен по пути: /mnt/external_disk/migration-dir/ioa/excludes.json

Шаг 2. Откройте веб-интерфейс Kaspersky EDR Expert 8.1.

Шаг 3. Перейдите в раздел Политики → выберите политику Endpoint Agent.

Шаг 4. В разделе Исключения IOA нажмите Импорт и загрузите файл excludes.json.

💡 Совет: Исключения можно импортировать как в общие исключения, так и в исключения для конкретных типов событий. Если импортированное исключение отсутствует в одном разделе, проверьте другой раздел политики Endpoint Agent.

2.6.3. Переключение агентов Endpoint Agent

Это критический момент — именно сейчас происходит переключение агентов со старого сервера на новый. Это и есть время простоя.

Шаг 1. Откройте консоль Kaspersky Security Center (KSC).

Шаг 2. Перейдите в раздел Управляемые устройства → выберите группу с агентами Endpoint Agent.

Шаг 3. Откройте свойства группы и перейдите на вкладку Политики.

Шаг 4. В политике Endpoint Agent измените адрес сервера управления:

• Укажите адрес нового сервера Kaspersky EDR Expert 8.1
• Сохраните изменения

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

Важно: После переключения агенты начнут отправлять данные на новый сервер Kaspersky EDR Expert 8.1. Старый сервер KEDR 7.1 больше не будет получать данные от агентов.

2.6.4. Проверка подключения агентов

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

1. Откройте веб-интерфейс Kaspersky EDR Expert 8.1
2. Перейдите в раздел Устройства → Endpoint Agent
3. Проверьте, что агенты отображаются в списке и имеют статус Онлайн

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

Команда для запуска:

./kata-osmp-import.sh \
  --step second \
  --migration-dir /mnt/external_disk \
  --migration-url https://migrate.xdr.company.local \
  --api-token $(cat /home/admin/api-token.txt) \
  --ca-cert /home/admin/certs/ca.crt \
  --tls-cert /home/admin/certs/tls.crt \
  --tls-key /home/admin/certs/tls.key \
  --tenant-name "Root tenant"

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

💡 Совет: Импорт исторических данных может занять продолжительное время (от нескольких минут до нескольких часов в зависимости от объема данных). Однако на этом этапе Kaspersky EDR Expert 8.1 уже полноценно работает и обрабатывает новые события от агентов.

Если вы выбрали Сценарий А: Перенос телеметрии с внешним хранилищем и выполнили экспорт третьего этапа (Step Third) на Этапе 1, необходимо выполнить импорт телеметрии.

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

2.8.1. Подготовка дампов телеметрии

Убедитесь, что на внешнем хранилище присутствуют файлы дампов телеметрии:

ls -la /mnt/external_disk/migration-dir/nodes/*/archive_source/elasticsearch/

Вы должны увидеть файлы с расширением .dump.

2.8.2. Настройка коллектора KUMA

Для импорта телеметрии необходимо настроить коллектор KUMA типа file на сервере OSMP.

Шаг 1. Откройте веб-интерфейс Kaspersky EDR Expert 8.1.

Шаг 2. Перейдите в раздел Мониторинг → Ресурсы и сервисы → Конфигурация сервисов → Коллекторы.

Шаг 3. Найдите коллектор [OOTB] Kaspersky EDR events migration file и нажмите на него.

Шаг 4. На вкладке Транспорт укажите путь к дампу телеметрии:

/mnt/external_disk/migration-dir/nodes/<GUID узла>/archive_source/elasticsearch/

Шаг 5. На вкладке Парсинг событий выберите нормализатор:

[OOTB] Normalizer for KEDR events migration

Шаг 6. На вкладке Маршрутизация убедитесь, что в качестве точки назначения указано [OOTB] OSMP Storage.

Шаг 7. Сохраните конфигурацию и запустите коллектор.

💡 Рекомендация: Настоятельно рекомендуется установить коллектор KUMA на отдельный сервер и включить этот сервер в кластер KUMA. Это снижает требования к ресурсам на основном узле OSMP.

2.8.3. Мониторинг импорта телеметрии

Отслеживайте прогресс импорта через веб-интерфейс KUMA:

1. Перейдите в раздел Мониторинг → Ресурсы и сервисы → Активные сервисы
2. Найдите коллектор в списке
3. Проверьте статус (должен быть 🟢 зелёный)
4. Отслеживайте использование CPU и памяти

💡 Совет: Импорт телеметрии может занять много времени (от нескольких часов до нескольких дней в зависимости от объема данных). Однако Kaspersky EDR Expert 8.1 уже полноценно работает и обрабатывает новые события.

2.8.4. Завершение импорта телеметрии

После завершения импорта телеметрии:

1. Остановите коллектор KUMA
2. Удалите коллектор из конфигурации KUMA
3. Отключите внешнее хранилище от сервера импорта

Если вы выбрали Сценарий Б: Перенос телеметрии без внешнего хранилища и выполнили подготовку сервера KATA (подраздел 1.8), необходимо настроить коллектор KUMA для импорта телеметрии напрямую из старого Elasticsearch.

Важно: Этот подраздел выполняется только если вы выбрали сценарий без внешнего хранилища и выполнили все шаги из подраздела 1.8.

2.9.1. Добавление отдельного сервера в кластер KUMA (рекомендуется)

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

На сервере управления KUMA выполните следующие действия:

Шаг 1. Создайте файл expand.inventory.yml со следующим содержимым:

kuma_collector:
  hosts:
    - <IP-адрес или FQDN нового сервера>
kuma_correlator:
  hosts: []
kuma_storage:
  hosts: []

Шаг 2. Выполните команду подготовки инфраструктуры:

./kdt invoke kuma --action addHosts --param host_inventory='<путь к файлу expand.inventory.yml>'

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

2.9.2. Создание коннекторов elastic в KUMA

Вы можете создать собственный коллектор или воспользоваться встроенным коллектором [OOTB] Kaspersky EDR events migration Elasticsearch. Рекомендуется использовать встроенный коллектор.

Шаг 1. Открытие мастера настройки коллектора

1. В главном меню перейдите в раздел Мониторинг → Ресурсы и сервисы → Конфигурация сервисов и нажмите Коллекторы.
2. В списке коллекторов найдите коллектор с именем [OOTB] Kaspersky EDR events migration Elasticsearch и нажмите на него.
3. Откроется мастер Изменение коллектора.

Шаг 2. Настройка вкладки "Транспорт"

На вкладке Транспорт в разделе Подключение укажите следующие параметры:

Важно: Чтобы избежать проблем с производительностью KUMA и Elasticsearch, рекомендуется указывать значение size не более 10 000.

💡 Совет: Для импорта данных можно создавать и использовать несколько подключений. Каждое соединение соответствует одному индексу в Elasticsearch. Рекомендуется использовать не более пяти коннекторов одновременно. Если у вас более 5 индексов, импортируйте партиями.

Шаг 3. Настройка вкладки "Парсинг событий"

На вкладке Парсинг событий выберите нормализатор:

[OOTB] Normalizer for KEDR events migration

Шаг 4. Настройка вкладки "Маршрутизация"

1. На вкладке Маршрутизация удалите встроенное хранилище [OOTB] OSMP Storage.
2. Нажмите на кнопку Добавить и выберите Создать в поле Назначение.
3. Выберите вариант хранилище в поле Тип.
4. Выберите [OOTB] OSMP Storage (Kubernetes gateway) в поле URL.
5. Введите URL в следующем формате:

https://api.<id>.kuma_host.smp_domain:443

Важно: Убедитесь, что запись *.kuma_host.smp_domain существует и правильно настроена на вашем DNS-сервере.

Шаг 5. Сохранение конфигурации

1. Нажмите на кнопку Сохранить.
2. На шаге проверки параметров нажмите Создать и сохранить сервис.
3. Будет отображена рекомендуемая команда для установки коллектора.
4. Скопируйте рекомендуемую команду и нажмите Сохранить.

2.9.3. Установка коллектора на отдельном сервере

Выполните скопированную команду через sudo на сервере, на котором установлены сервисы KUMA:

sudo /opt/kaspersky/kuma/kuma collector \
  --core https://<FQDN сервера Ядра KUMA>:7210 \
  --id <идентификатор сервиса коллектора> \
  --api.port <порт для связи с устанавливаемым компонентом> \
  --install

Где:

• FQDN сервера Ядра KUMA: <kuma_host>.<smp_domain>
• Порт по умолчанию: 7210 (неизменяемый)
• Идентификатор сервиса: скопирован из веб-интерфейса KUMA
• Порт API: указывается при установке нескольких сервисов на одном устройстве (должен быть уникальным)

💡 Пример команды:

sudo /opt/kaspersky/kuma/kuma collector \
  --core https://kuma-core.company.local:7210 \
  --id collector-abc123def456 \
  --api.port 7221 \
  --install

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

2.9.4. Мониторинг и проверка импорта

Проверка статуса коллектора через веб-интерфейс

1. В главном меню перейдите в раздел Мониторинг → Ресурсы и сервисы → Активные сервисы.
2. Найдите ваш коллектор в таблице.
3. Проверьте колонку Статус:
   • 🟢 Зелёный — сервис работает корректно
   • 🟡 Жёлтый — сервис работает с предупреждениями
   • 🔴 Красный — сервис не работает
4. Отслеживайте использование CPU и Памяти в реальном времени.

Проверка через поиск событий

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

1. Перейдите в раздел Мониторинг → События.
2. Выберите ваш коллектор в фильтре.
3. Убедитесь, что события начинают поступать.

Команды диагностики

На сервере KUMA выполните команды для проверки состояния:

# Список всех компонентов и их статусов
./kdt state

# Полный журнал событий для конкретного компонента
./kdt state -l <название_компонента>

Как понять, что импорт завершен

Импорт телеметрии считается завершенным, когда:

• Все индексы из старого Elasticsearch обработаны
• В новом Kaspersky EDR Expert 8.1 появились исторические события за указанный период
• Статус коллектора в веб-интерфейсе KUMA — зелёный
• Использование CPU и памяти коллектора стабилизировалось на низком уровне

💡 Совет: Импорт телеметрии занимает много времени (может длиться несколько часов или даже дней в зависимости от объема данных), но не влияет на работу Kaspersky EDR Expert — система уже полноценно функционирует и обрабатывает новые события.

2.9.5. Закрытие доступа к Elasticsearch

После завершения импорта телеметрии необходимо закрыть доступ к Elasticsearch на сервере KATA.

Важно: Описываемые ниже действия необходимо выполнить на сервере KATA в режиме Technical Support Mode.

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

cd /home/admin/elastic_script_dir

Запустите скрипт в режиме close:

sudo ./kata-elastic-access.sh close

В результате выполнения этой команды внешний порт Elasticsearch будет закрыт, и сервер KATA вернется в безопасное состояние.

2.9.6. Завершение миграции телеметрии

Удаление коннекторов

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

1. В главном меню перейдите в раздел Мониторинг → Ресурсы и сервисы → Активные сервисы.
2. Найдите коллекторы, созданные для импорта телеметрии.
3. Щелкните правой кнопкой мыши на коллекторе и выберите Удалить.
4. Подтвердите удаление.

Удаление сервера из кластера KUMA (если использовался отдельный сервер)

Если вы использовали отдельный Linux-сервер для коллектора, его можно убрать из кластера KUMA:

1. В главном меню перейдите в раздел Мониторинг → Ресурсы и сервисы → Устройства.
2. Найдите сервер, который использовался для коллектора.
3. Щелкните правой кнопкой мыши и выберите Удалить из кластера.
4. Подтвердите удаление.

Очистка временных файлов

На сервере KATA выполните очистку временных файлов:

# Удаление директории со скриптами
sudo rm -rf /home/admin/elastic_script_dir

# Удаление Docker-образа (опционально)
docker rmi <имя_образа>

После завершения всех этапов импорта (включая телеметрию, если она переносилась) безопасно отключите внешнее хранилище от сервера импорта.

Для физического диска:

sudo umount /mnt/external_disk

Для сетевого ресурса:

sudo umount /mnt/external_disk

После завершения миграции рекомендуется удалить пакет cifs-utils в целях безопасности:

sudo apt remove --purge cifs-utils && sudo apt autoremove -y