Миграция данных с 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.
• Файлы из карантина.