Миграция данных с KATA/KEDR 7.1 на KEDR Expert 8+

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

• Данные алертов
• Дополнительные данные алертов
  • Хранилище Sandbox.
  • Обнаруженное файловое хранилище.
• IOC-правила
• Пользовательские IOA-правила
• Исключения IOA
• Пользовательские YARA-правила
• Пользовательские правила отправки объектов в Kaspersky Sandbox
  • Правила проверки файлов.
  • Правила проверки ссылок.
  • Список пользовательских образов.
  • Список образов, входящих в набор Sandbox по умолчанию.
• Хранилище артефактов расследования
  • Загруженные вручную файлы.
  • Файлы, полученные с помощью задачи get.
  • Результаты проверки Anti-Malware Engine.
  • Результаты проверки YARA.
  • Результаты проверки Sandbox.
• Правила запрета
• Пароли архивов, используемые при проверке Anti-Malware и Kaspersky Sandbox.
• Активные пользователи системы
• Шаблоны уведомлений по электронной почте
• Информация об Endpoint Agent
• База данных телеметрии поиска угроз
  • Переносится только при явном запуске Этапа 3 (перенос телеметрии). В базовую миграцию (Этапы 1 и 2) не входит.

ℹ️ Примечание:
Полный перечень переносимых атрибутов для каждого объекта приведен в официальной документации Kaspersky EDR Expert 8.1.

Переносится с особенностями

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

• Endpoint Agent
  • Перед началом миграции необходимо обновить Endpoint Agent до версии, поддерживаемой Kaspersky EDR Expert 8.1.
• Историческая телеметрия
  • Переносится отдельным этапом и не входит в основной процесс миграции.
• Исключения IOA
  • Экспортируются в отдельный файл excludes.json и импортируются после завершения миграции. Исключения можно импортировать как в общие исключения, так и в исключения для конкретных типов событий. Если импортированное исключение отсутствует в одном разделе, проверьте другой раздел политики Endpoint Agent.
• Алерты
  • Рекомендуется переносить только алерты со статусом «Закрыто».
• Активные пользователи системы
  • Пользователи Active Directory не переносятся.
• Шаблоны уведомлений по электронной почте
  • Не экспортируются шаблоны, использующие критерии, не поддерживаемые OSMP (например, IDS).
• IOC-алерты
  • Переносятся только правила, полностью соответствующие стандартам OpenIOC 1.0 и OpenIOC 1.1.
  IOC-алерты, связанные с правилами, не соответствующими этим стандартам, не переносятся. Информация о таких алертах отображается в журнале ошибок миграции.

Не переносится

На момент подготовки статьи документация указывает, что автоматически не переносятся:

• Данные раздела «Карантин».

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

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

Данные в 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