Миграция данных с 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

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

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

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

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

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

Шаг 7.1. Подготовка сервера KATA (открытие порта Elasticsearch)

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

ℹ️ Примечание: Конкретные шаги по открытию порта зависят от вашей конфигурации KATA и правил межсетевого экрана. Обратитесь к документации по эксплуатации вашей версии KATA.

Шаг 7.2. Подготовка отдельного Linux-сервера для коллектора KUMA

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

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

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

Шаг 7.3. Краткий обзор процесса импорта (для понимания объема работ)

На этапе импорта телеметрии (Этап 3) вам потребуется выполнить следующие действия в консоли OSMP:

1. Создать коннектор типа elastic для каждого индекса Elasticsearch на старом сервере KATA. Поскольку индексов может быть много (до 5 и более), рекомендуется использовать скрипт для автоматизации этого процесса.
2. Настроить нормализатор: на вкладке «Парсинг событий» выбрать [OOTB] Normalizer for KEDR events migration.
3. Настроить маршрутизацию: на вкладке «Маршрутизация» удалить встроенное хранилище [OOTB] OSMP Storage и создать новую точку назначения типа storage с URL [OOTB] OSMP Storage (Kubernetes gateway).
4. Запустить коллектор и дождаться завершения импорта исторических данных.

⚠️ Важно: По завершении переноса данных коннектор можно удалить, а отдельный сервер (если он использовался) можно убрать из кластера KUMA. Импорт телеметрии занимает много времени, но не влияет на работу Kaspersky EDR Expert — система уже полноценно функционирует.

Подробная пошаговая инструкция по переносу телеметрии будет приведена в разделе «Этап 3. Перенос данных телеметрии».