KEDR (OSMP)

Установка и обновление

Гайд по установке Kaspersky EDR Expert (on-premise)

Инструкции по настройке

Оптимизация дисковой подсистемы
Настройка доменной аутентификации Kerberos
Процесс установки и настройки компонента Sandbox (OSMP) на базе KES Windows
Процесс установки и настройки компонента EDR (OSMP) на базе KES Windows
Процесс установки и настройки компонента EDR (OSMP) на базе KES Linux
Процесс установки и настройки компонента Sandbox (OSMP) на базе KES Linux
Настройка подключения агентов через промежуточный прокси-сервер
Руководство по утилите KDT

Диагностика и решение проблем

KEDR Expert on-premise: общие рекомендации по диагностике и устранению неполадок
Очистка событий в хранилище (освобождение места)

Плейбуки

Плейбуки в Kaspersky EDR Expert 8.1: Полное руководство

Миграция

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

Установка и обновление

Гайд по установке Kaspersky EDR Expert (on-premise)

Инструкция составлена на основе официальной документации и опыта эксплуатации.
Дата исправления: 29.06.2026

Часть 1. Типы установки

Параметр	Стандартная конфигурация (несколько узлов)	Демонстрационная конфигурация (один узел)
СУБД PostgreSQL	Устанавливается вне кластера Kubernetes на отдельном сервере	Устанавливается на одном хосте с кластером Kubernetes
Минимальное количество узлов	1 первичный + 3 рабочих узла + сервер СУБД + 1 узел администратора (опционально)	1 узел (все компоненты на одном устройстве) + 1 узел администратора (опционально)
Назначение	Промышленная эксплуатация	Тестирование, демонстрация, обучение

Роли узлов:

Узел администратора - устройство с утилитой KDT (Kaspersky Deployment Toolkit) для развертывания и управления компонентами OSMP.
Primary/master/controller/первичный рабочий узел - узел контроллера, осуществляющий управление кластером k0s.
Worker/рабочий узел - узел кластера k0s с полезной нагрузкой.
DB/СУБД - сервер с СУБД для кластера OSMP.
KUMA services/устройство с сервисами KUMA - устройства с установленными сервисами KUMA: коллектор, коррелятор, хранилище (в случае KEDR входят в состав Kubernetes кластера).
Целевые устройства - устройства, на которых устанавливается OSMP (все вышеперечисленные узлы)

Часть 2. Критические требования инфраструктуры

2.1. СУБД PostgreSQL

Параметр	Требование
Версия	15.7 или выше
Расположение	Вне кластера Kubernetes (стандартная конфигурация)
Привилегированная учётная запись	Требуется учётная запись с правами суперпользователя для создания баз данных во время развертывания
Поддержка кластеров	Поддерживается синхронная репликация (минимум 3 узла, максимум 15).
Дисковая подсистема	SSD/NVMe рекомендуется

2.2. Сетевые требования

Требование	Описание
Широковещательный домен	Все целевые устройства кластера Kubernetes должны находиться в одном широковещательном домене (одна L2-сеть)
Статические IPv4-адреса	Все узлы кластера и шлюз Kubernetes должны иметь статические IPv4-адреса в одной подсети
Синхронизация времени	Разница во времени между узлами не должна превышать 5 секунд (рекомендуется использовать NTP)
DNS	Должна быть настроена зона для домена smp_domain (например, smp.local) с записями для всех сервисов

2.3. Аппаратные требования (минимальные)

Компонент	Процессор	ОЗУ	Дисковая подсистема
Все компоненты на одном узле (демонстрационная конфигурация)	12 ядер	56 Гб	1300 Гб

Для корректного развертывания решения убедитесь, что процессор целевого устройства (компонентов KEDR) поддерживает набор инструкций BMI, AVX и SSE 4.2.

2.4. Программные требования

Требования к программному обеспечению и поддерживаемым системам и платформам

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

OSMP с компонентами KUMA

Поддерживаются следующие 64-разрядные версии операционных систем:

Ubuntu Server 22.04 LTS.
Ubuntu Server 24.04 LTS.
Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.8.1).
Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.8.2).

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

Платформы виртуализации

Название платформы виртуализации	OSMP	Sandbox (опционально)
VMware ESXi 7.0;
Hyper-V для Windows Server 2022;
ПК СВ "Брест" 3.3;
"РЕД Виртуализация" 7.3;
zVirt Node 4.2 или выше
Nutanix 7.3

Система управления базами данных (СУБД)

PostgreSQL 15.х 64-разрядная

PostgreSQL 16.x 64-разрядная
PostgreSQL 17.х 64-разрядная
PostgreSQL 18.x 64-разрядная
Postgres Pro 15.х (все редакции) 64-разрядная
Postgres Pro 16.х (все редакции) 64-разрядная
Postgres Pro 17.х (все редакции) 64-разрядная
Postgres Pro 16.х Enterprise 64-разрядная (кластер Built-in High Availability).
Postgres Pro 17 Enterprise 64-разрядная (кластер Built-in High Availability).

Часть 3. Подготовка устройств

Отключайте файл подкачки (swap) в продуктовых средах

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

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

sudo apt update
sudo apt install -y python3

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

Пример:

Для Ubuntu:
# Удалите старые версии 
sudo apt remove docker docker-engine docker.io containerd runc

# Установите зависимости 
sudo apt update 
sudo apt install ca-certificates curl gnupg lsb-release  

# Добавьте официальный GPG ключ Docker 
sudo mkdir -p /etc/apt/keyrings 
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg  

# Добавьте репозиторий 
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null  

# Установите Docker
sudo apt update 
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Добавьте пользователя в группу docker
sudo usermod -aG docker $USER  

# Настройте автозапуск 
sudo systemctl enable docker.service 
sudo systemctl enable containerd.service  

# Перезагрузитесь или выполните
newgrp docker

Ещё вариант:

apt install docker.io

Генерация SSH-ключа (без парольной фразы):

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""

Скопируйте ключ на все целевые устройства:

ssh-copy-id username@<IP_целевого_устройства>

# Проверка подключения без пароля
ssh username@<IP_целевого_устройства> "sudo whoami"

При установке от учётной записи root убедитесь, что ключ на целевых устройствах располагается по пути /root/.ssh/authorized_keys

Целевые устройства (OSMP):

Проверка cgroup v2:

mount | grep cgroup 
# Должно быть: cgroup2 on /sys/fs/cgroup type cgroup2

Отключите SELinux (если установлен)

# Проверка статуса 
getenforce  

# Отключение (требуется перезагрузка) 
sudo setenforce 0 sudo sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

Настройте proxy (если требуется)

# Отредактируйте /etc/environment 
sudo nano /etc/environment  

# Добавьте: 
HTTP_PROXY="http://proxy.example.com:8080" 
HTTPS_PROXY="http://proxy.example.com:8080" 
NO_PROXY="localhost,127.0.0.1,<IP_адреса_узлов_кластера>"

Настройте firewall (если используется)

# Разрешите SSH
sudo ufw allow 22/tcp

# Разрешите Kubernetes порты
sudo ufw allow 6443/tcp
sudo ufw allow 2379:2380/tcp
sudo ufw allow 10250/tcp

# Разрешите PostgreSQL порты
sudo ufw allow 5432/tcp

# Включите IP forwarding для primary/worker node
sudo sed -i 's/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/' /etc/sysctl.conf
sudo sysctl -p

Для отключения firewall'а выполните:

systemctl stop ufw
systemctl disable ufw

Установка обязательных пакетов:

# Общие пакеты для всех узлов:
sudo apt update
sudo apt install -y sudo nfs-common tar wireguard wireguard-tools python3-apt

# Для первичного узла дополнительно:
sudo apt install -y curl

# Для рабочих узлов дополнительно (наименования могут отличаться в зависимости от выбранного дистрибутива Linux):
sudo apt install -y libnfs12 iscsi-package

Настройка беспарольного sudo:

# Для пользователя, который будет использоваться KDT:
echo "username ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers

Это позволит учетной записи иметь возможность повышать привилегии (sudo) без ввода пароля

Настройка синхронизации времени:

sudo timedatectl set-ntp true

Настройка IP-переадресации (только для первичного узла с UFW):

# В файле /etc/default/ufw установите:
DEFAULT_FORWARD_POLICY="ACCEPT"

# Примените изменения:
sudo ufw reload

СУБД PostgreSQL:

Установка обязательных пакетов:

sudo apt update
sudo apt install -y postgresql

Настройка параметров в postgresql.conf:

nano /etc/postgresql/<ВЕРСИЯ>/main/postgresql.conf

# Переопределите следующие параметры:
listen_addresses = '*'
port = 5432
max_connections = 512
shared_buffers = 8GB                  # 25% от ОЗУ, минимум 3 ГБ
effective_cache_size = 24GB           # 75% от ОЗУ
temp_buffers = 24MB
work_mem = 64MB
maintenance_work_mem = 1GB
max_stack_depth = 7MB                 # Для Linux: ulimit -s минус 1 МБ
effective_io_concurrency = 200        # 200 для SSD или 2 для HDD
max_parallel_workers_per_gather = 0
wal_buffers = 64MB
max_wal_size = 4GB
min_wal_size = 1GB
random_page_cost = 1.1                # 1.1 для SSD или 4.0 для HDD
log_hostname = 1
standard_conforming_strings = on      # Обязательно должно быть 'on'

Разрешение удаленного подключения к СУБД:

nano /etc/postgresql/<ВЕРСИЯ>/main/pg_hba.conf

# В секции 'IPv4 local connections' переопределите значение:
host   all   all   0.0.0.0/0    scram-sha-256

Перезапуск службы:

systemctl restart postgresql

Создание привилегированной учётной записи:

# Подключитесь к PostgreSQL:
sudo -u postgres psql

# Создайте учётную запись с правами суперпользователя и базу, например:
CREATE USER <kaspersky_admin> WITH PASSWORD '<StrongPassword123!>' SUPERUSER;
CREATE DATABASE <kaspersky_admin> OWNER <kaspersky_admin>;

Подготовка инфраструктуры:

1. Зарезервируйте IP-адрес из той же подсети, что и у серверов Primary/Worker. Адрес должен быть свободен и будет назначен в процессе установки (указывается в файле param.yaml в поле ingress_ip).

2. Добавьте в DNS-зону вашей организации (предпочтительно создать поддомен) следующие записи:

console.<smp_domain> <ingress_ip>
admsrv.<smp_domain> <ingress_ip>
api.<smp_domain> <ingress_ip>
monitoring.<smp_domain> <ingress_ip>
updater.<smp_domain> <ingress_ip>
agentserver.<smp_domain> <ingress_ip>
kuma.<smp_domain> <ingress_ip>
*.kuma.<smp_domain> <ingress_ip>

где, <smp_domain> - домен или поддомен вашей организации (данный домен должен быть указан в файле параметров (param.yaml) в одноименном поле smp_domain), а <ingress_ip> - зарезервированный IP из предыдущего пункта.

Обратите внимание, что для имени kuma необходимо создать wildcard (*) на DNS-сервере

Часть 4. Этапы установки

Подготовка файла param.yaml:

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

Формат файла для стандартной конфигурации с сервисами KUMA внутри кластера

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

Формат файла для демонстрационной конфигурации с сервисами KUMA внутри кластера

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

Установка

1. Загрузите на устройство администратора следующие файлы:

bin.tar.gz - архив с утилитой KDT, используется для развертывания и изменения параметров инсталляции
xdr-<version>.tar.gz - транспортный архив с компонентами SMP
license.key - ключ лицензии

2. Распакуйте архив bin.tar.gz

tar -xzf bin.tar.gz

3. Дайте файлу kdt права на выполнение:

chmod +x ./kdt

4. Запустите установку командой:

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

Часть 5. Базовые действия после установки

Первый вход в веб-интерфейс:

Откройте в браузере https://console.<smp_domain>
Войдите под учётной записью admin с паролем из параметра admin_password и завершите настройку 2FA.

Активация лицензии:

В главном окне приложения нажмите на имя Сервера администрирования. Откроется окно свойств Сервера администрирования
На вкладке Общие выберите раздел Лицензионные ключи
В разделе Действующая лицензия нажмите на кнопку Выбрать
В открывшемся окне выберите лицензионный ключ, который вы хотите использовать для активации Kaspersky EDR Expert (on-premise) 8.0. Если лицензионного ключа нет в списке, нажмите на кнопку Добавить лицензионный ключ и укажите новый лицензионный ключ
Нажмите на кнопку Сохранить

Предоставление доступа к функционалу Kaspersky EDR:

В главном окне приложения перейдите в Параметры, выберите раздел Тенанты и нажмите на Root tenant
На вкладке Права доступа нажмите на кнопку Добавить пользователя
Выберите пользователя admin и предоставьте ему роль Главный администратор
Нажмите кнопку Сохранить и далее Сохранить и закрыть

Установка плагинов управления:

Загрузите плагин управления конечным устройством для OSMP с расширением .tar на узел администратора
Выполните установку командой:

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

Обновление баз Kaspersky EDR:

В главном окне приложения перейдите в Параметры, выберите раздел Тенанты и нажмите на Root tenant
На вкладке Параметры перейдите к Параметры сканирования и на вкладку Обновить базы
Запустите обновление и дождитесь успешного статуса

Подключение Sandbox:

В главном окне приложения перейдите в Параметры, выберите раздел Тенанты и нажмите на Root tenant
На вкладке Параметры перейдите к Серверы Sandbox и нажмите кнопку Добавить
Укажите IP-адрес Sandbox 8 версии, получите отпечаток, задайте произвольное имя, нажмите кнопку Добавить
В браузере перейдите и авторизуйтесь в веб-консоли Sandbox и примите запрос на подключение в разделе Авторизация
В консоли OSMP дождитесь, что статус авторизации изменился на Одобрено и отобразились наборы виртуальных машин

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

В главном окне приложения перейдите в Управление активами - Политики
Создайте политику или откройте её свойства и перейдите в Параметры приложения
Раскройте ветку Встроенные агенты и перейдите в параметры для Endpoint Detection and Response Expert (on-premise)
Установите переключатель в статус ВКЛЮЧЕН. Установите переключатель замка, чтобы изменение применялось на конечном узле
Выберите Endpoint Detection and Response Expert (версия 8.0 и выше)
Для раздела Подключение к серверам сбора телеметрии нажмите кнопку Добавить и нажмите Выбрать сервер
В открывшемся окне отметьте единственный сервер коллектора и нажмите кнопку Добавить
Ниже повторите действия для указания сервера реагирования
При необходимости настройте другие пункты политики и сохраните изменения

Настройка политик для подключения Sandbox к конечным устройствам:

В главном окне приложения перейдите в Параметры, выберите раздел Тенанты и нажмите на Root tenant
На вкладке Параметры перейдите к Сертификаты и нажмите кнопку Экспортировать сертификат сервера и ниже сертификат Endpoint Agent, указав пароль
В главном окне приложения перейдите в Управление активами - Политики
Создайте политику или откройте её свойства и перейдите в Параметры приложения
Раскройте ветку Встроенные агенты и перейдите в параметры для Sandbox
Установите переключатель в статус ВКЛЮЧЕН. Установите переключатель замка, чтобы изменение применялось на конечном узле
Выберите режим интеграции KATA Sandbox
Для раздела Подключение к серверам Sandbox нажмите кнопку Добавить и укажите адрес сервера agentserver.<smp_domain>
Нажмите Настройки подключения и загрузите экспортированный сертификат сервера. В этом же поле обязательно включите использование двусторонней аутентификации и подставьте сертификат Endpoint Agent с паролем, указанным при его экспорте
При необходимости настройте другие пункты политики и сохраните изменения

Базовая настройка завершена. Подключите совместимые приложения KES для Windows 12.11 и выше, KES для Linux 12.4, KES для Mac 12.2.1 и приступайте к работе с Kaspersky EDR Expert (on-premise).

Инструкции по настройке

Оптимизация дисковой подсистемы

Дата обновления: 23.04.2026

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

Перед дальнейшими изменениями можете выполнить команду на сервере СУБД и записать результаты:

fio --name=test --directory=/var/lib/postgresql/<ваша_версия>/main --rw=randrw --bs=8k --size=1G --iodepth=16 --ioengine=libaio --direct=1 --fsync=1 --runtime=60

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

lsblk -d -o name,rota,TYPE,MODEL,SIZE

Ожидаемые выводы и их интерпритация:

#Пример 1: SSD
NAME    ROTA    TYPE    MODEL              SIZE
sda        0    disk    Samsung_SSD_860    500G   # ROTA=0 (SSD)

#Пример 2: HDD
NAME    ROTA    TYPE    MODEL              SIZE
sda        1    disk    WDC_WD10EZEX       1T     # ROTA=1 (HDD)

#Пример 3: Виртуальный диск (VMware)
NAME    ROTA    TYPE    MODEL              SIZE
sda        0    disk    Virtual_disk       100G   # ROTA=0 (считаем как SSD)

#Пример 4: NVMe
NAME    ROTA    TYPE    MODEL              SIZE
nvme0n1    0    disk    INTEL_SSD          500G   # NVMe (всегда SSD)

Далее настроим планировщие I/O:

Создадим udev правило и отредактируем его:

nano /etc/udev/rules.d/60-scheduler.rules

Для SSD (ROTA=0) вставим следующие значения:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/nr_requests}="1024"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/max_sectors_kb}="2048"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/read_ahead_kb}="128"

Для HDD (ROTA=1):

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/nr_requests}="256"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/max_sectors_kb}="512"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/read_ahead_kb}="256"

Для NVMe (ROTA=0):

ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/nr_requests}="1024"

И применим правила:

udevadm control --reload-rules
udevadm trigger --name-match=sda #изменить имя диска, если отличается

Далее настроим параметры ядра (sysctl):

Создадим файл настроек и отредактируем его:

nano /etc/sysctl.d/99-database-tuning.conf

Для SSD / NVMe / Виртуальных дисков (ROTA=0):

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500

fs.aio-max-nr = 2097152

vm.swappiness = 1
vm.vfs_cache_pressure = 50

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Для HDD (ROTA=1):

vm.dirty_ratio = 30
vm.dirty_background_ratio = 10
vm.dirty_expire_centisecs = 6000
vm.dirty_writeback_centisecs = 3000

fs.aio-max-nr = 2097152

vm.swappiness = 1
vm.vfs_cache_pressure = 50

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

И применем настройки:

sysctl -p /etc/sysctl.d/99-database-tuning.conf

Далее настроим опции файловой системы:

Отредактируем fstab (предварительно сделайте резервную копию):

nano /etc/fstab

Найдём строку, как пример для ext4:

UUID=3fe51788-bb69-467d-89a9-a146c1df7fdd /                       ext4    defaults        1 1

Заменим на:

UUID=3fe51788-bb69-467d-89a9-a146c1df7fdd /                       ext4    rw,noatime,nodiratime,data=ordered,errors=remount-ro        1 1

Для xfs заменим на: noatime,nodiratime,logbufs=8,logbsize=256k

Далее перемонтируем корневую систему:

mount -o remount /

или перезагрузим систему.

Также рекомендую обновить systemd после изменения /etc/fstab:

systemctl daemon-reload

Далее настроим TRIM (только для SSD):

# Включить fstrim.timer:
systemctl enable --now fstrim.timer

# Проверить статус:
systemctl status fstrim.timer

Далее перепроверим конфигуарцию postgresql.conf:

nano /etc/postgresql/<ВЕРСИЯ>/main/postgresql.conf

# Переопределите следующие параметры:
listen_addresses = '*'
port = 5432
max_connections = 512
shared_buffers = 8GB                  # 25% от ОЗУ, минимум 3 ГБ
effective_cache_size = 24GB           # 75% от ОЗУ
temp_buffers = 24MB
work_mem = 64MB
maintenance_work_mem = 1GB
max_stack_depth = 7MB                 # Для Linux: ulimit -s минус 1 МБ
effective_io_concurrency = 200        # 200 для SSD или 2 для HDD
max_parallel_workers_per_gather = 0
wal_buffers = 64MB
max_wal_size = 4GB
min_wal_size = 1GB
random_page_cost = 1.1                # 1.1 для SSD или 4.0 для HDD
log_hostname = 1
standard_conforming_strings = on      # Обязательно должно быть 'on'

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

Инструкции по настройке

Настройка доменной аутентификации Kerberos

Дата обновления: 28.04.2026

Процесс настройки доменной аутентификации описан в официальной справке. Обратите внимание, что keytab выписывается на console.<smp.domain>.

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

1) Проверка keytab файла

Установите MIT Kerberos for Windows: https://web.mit.edu/kerberos/dist/kfw/

И выполните:

"C:\Program Files (x86)\MIT\Kerberos\bin\klist.exe" -k -t -e C:\<путь>\<имя>.keytab

Правильный вывод:

KVNO	Timestamp	Principal
3	01/01/70 03:00:00	HTTP/console.xdr.sales.lab@SALES.LAB (AES-256 CTS...)

Частые ошибки это двойные бэкслеши HTTP\\console..., либо неправильное шифрование etype: arcfour-hmac, либо kvno указан иной. В этом случае, то пересоздайте keytab, указав верные данные, включая учетную запись, к который прикреплен SPN.

2) Настройка браузера для SSO

Быстрая локальная проверка - это запуск браузера с параметрами:

chrome.exe --auth-server-allowlist="*.<smp.domain>"
msedge.exe --auth-server-allowlist="*.<smp.domain>"

Закрепить результат можно через Group Policy Management Editor (gpme.msc) перейдите в Computer Configuration → Preferences → Windows Settings → Registry и добавьте элемент со следующими значениями:

Параметр	Значение для Chrome	Значение для Edge
Action	Update	Update
Hive	HKEY_LOCAL_MACHINE	HKEY_LOCAL_MACHINE
Key Path	SOFTWARE\Policies\Google\Chrome	SOFTWARE\Policies\Microsoft\Edge
Value name	AuthServerAllowlist	AuthServerAllowlist
Value type	REG_SZ	REG_SZ
Value data	*.<smp.domain>	*.<smp.domain>

Также можно добавить изменение в локальный реестр:

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v AuthServerAllowlist /t REG_SZ /d "*.<smp.domain>" /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v AuthServerAllowlist /t REG_SZ /d "*.<smp.domain>" /f

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

При изменении политики на клиентском ПК необходимо выполнить:

gpupdate /force

3) Legacy способ с настройкой системной зоны

В локальной политике или групповой политике перейти в Computer Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page и для Site to Zone Assignment List добавить содержание *.<smp.domain> со значением 1.

При изменении политики на клиентском ПК необходимо выполнить:

gpupdate /force

Способ устаревший и уже не применяется для браузера Mozilla Firefox!

Инструкции по настройке

Процесс установки и настройки компонента Sandbox (OSMP) на базе KES Windows

📦 Варианты подключения

Версия решения: KES 12.7+; KEDR 8.0+ (OSMP);
Тип развёртывания:

Чистая установка с компонентом Sandbox
Активация компонента Sandbox на уже установленном KES

💡 Рекомендация:
Используйте чистую установку, если вы разворачиваете решение впервые.
Используйте активацию через задачу, если KES уже развёрнут и обновлён до 12.7+.

ВАЖНО:
В этой инструкции рассмотрим только настройку через KSC Web Console. MMC консоль больше не поддерживается, поэтому рекомендуется использовать веб-консоль.

1. Подготовка

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

Компонент	Минимальная версия
KEDR (OSMP)	8.0+
KSC	13.2+
KES для Windows	12.7+

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

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

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

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

2. Чистая установка KES 12.7+ с Sandbox через OSMP Web Console

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

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

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

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

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

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

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

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

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

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

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

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

2. Выберите:

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

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

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

4. Выберите:

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

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

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

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

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

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

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

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

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

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

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

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

3. Активация Sandbox на уже установленном KES

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

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

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

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

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

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

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

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

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

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

4. Интеграция с KEDR 8+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Проверка интеграции

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

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

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

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

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

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

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

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

📌 Полезные ссылки

✅ Развёртывание KES 12.7+ с Sandbox завершено!

Инструкции по настройке

Процесс установки и настройки компонента EDR (OSMP) на базе KES Windows

📦 Варианты подключения

Версия решения: KES 12.1+; KEDR 8+ (OSMP/XDR);
Тип развёртывания:

Чистая установка с компонентом EDR
Активация компонента EDR на уже установленном KES

💡 Рекомендация:
Используйте чистую установку, если вы разворачиваете решение впервые.
Используйте активацию через задачу, если KES уже развёрнут и обновлён до 12.1+.

ВАЖНО:
В этой инструкции мы рассмотрим только настройку через KSC Web Console. MMC консоль больше не поддерживается, поэтому рекомендуется использовать веб-консоль.

Начиная с версии Kaspersky Endpoint Security для Windows 12.11 компонент EDR (KATA) переименован в Endpoint Detection and Response Expert (версия 8.0 и выше). В этой версии приложения компонент совместим с Kaspersky Anti Targeted Attack Platform версии 7.1 и ниже и Kaspersky Endpoint Detection and Response Expert (on-premise).

Компоненты EDR Optimum, EDR Expert и EDR (KATA) несовместимы между собой.

1. Подготовка

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

Компонент	Минимальная версия
KEDR (OSMP/XDR)	8+
KSC	13.2+
KES для Windows	12.1+

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

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

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

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

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

2. Чистая установка KES 12.1+ с EDR через OSMP Web Console

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Выберите:

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

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

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

4. Выберите:

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензия KEDR:

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

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

3. Активация EDR на уже установленном KES

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Интеграция с KEDR 8+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Проверка интеграции

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

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

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

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

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

- Статус EDR

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

- Лицензия EDR

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

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

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

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

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

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

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

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

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

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

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

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

📌 Полезные ссылки

✅ Развёртывание KES 12.1+ с EDR завершено!
Теперь ваши конечные точки:

Передают телеметрию в KATA
Участвуют в расследовании инцидентов
Поддерживают автоматическую корреляцию с сетевыми событиями

Инструкции по настройке

Процесс установки и настройки компонента EDR (OSMP) на базе KES Linux

📦 Варианты подключения

Версия решения: KESL 11.4+; KEDR 8+ (OSMP/XDR);

Примечание:
В отличие от версии KES Windows, KES Linux не требует установки и включения компонента EDR, так как он уже входит в состав установленного решения и для его активации необходимо включить использование его в политике и настроить интеграцию.

Начиная с версии Kaspersky Endpoint Security 12.4 для Linux компонент Endpoint Detection and Response (KATA) переименован в Endpoint Detection and Response Expert (on-premise). Теперь этот компонент обеспечивает интеграцию не только с Kaspersky Endpoint Detection and Response (KATA), компонентом Kaspersky Anti Targeted Attack Platform, но и с решением Kaspersky Endpoint Detection and Response Expert (on-premise).

Если приложение Kaspersky Endpoint Security используется в режиме Легкого агента для защиты виртуальных сред (О режимах использования приложения Kaspersky Endpoint Security, Просмотр в командной строке информации об использовании приложения в режиме Легкого агента), активация выполняется на стороне Сервера защиты (компонента решения Kaspersky Security для виртуальных сред Легкий агент) путем добавления лицензионных ключей на SVM.

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

1. Подготовка

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

Компонент	Минимальная версия
KEDR (OSMP/XDR)	8+
KSC	13.2+
KES для Linux	11.4+

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

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

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

Лицензия KESL+EDR

2. Чистая установка KESL 11.4+ с EDR через OSMP Web Console

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

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

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

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

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

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

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

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

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

2. Выберите:

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

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

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

4. Выберите:

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Интеграция с KEDR 8+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Проверка интеграции

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

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

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

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

- Статус EDR

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

- Лицензия EDR

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

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

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

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

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

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

📌 Полезные ссылки

✅ Развёртывание KESL 11.4+ с EDR завершено!
Теперь ваши конечные точки:

Передают телеметрию в KATA
Участвуют в расследовании инцидентов
Поддерживают автоматическую корреляцию с сетевыми событиями

Инструкции по настройке

Процесс установки и настройки компонента Sandbox (OSMP) на базе KES Linux

📦 Варианты подключения

Версия решения: KESL 12.2+; KEDR 8+ (OSMP/XDR);

Примечание:
В отличие от версии KES Windows, KES Linux не требует установки и включения компонента Sandbox, так как он уже входит в состав установленного решения и для его активации необходимо включить использование его в политике и настроить интеграцию.

1. Подготовка

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

Компонент	Минимальная версия
KEDR (OSMP/XDR)	8+
KSC	13.2+
KES для Linux	12.2+

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

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

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

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

2. Чистая установка KESL 12.2+ с EDR через OSMP Web Console

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

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

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

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

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

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

2. Выберите:

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

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

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

4. Выберите:

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

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

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

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

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

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

Лицензия KESL:

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

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

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

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

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

3. Интеграция с KEDR 8+ (OSMP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Проверка интеграции

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

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

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

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

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

📌 Полезные ссылки

✅ Развёртывание KESL 11.4+ с Sandbox завершено!

Инструкции по настройке

Настройка подключения агентов через промежуточный прокси-сервер

Дата обновления: 08.07.2026

За основу написания статьи послужила страница в справке: https://support.kaspersky.ru/kedr-expert-on-premise/8.1/322641

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

Запись, которую мы будем указывать в качестве сервера сбора телеметрии, например, telemetry.<example.com>
Запись, которую мы будем указывать в качестве сервера реагирования, например, response.<example.com>

Далее подготовим рабочий каталог для сертификатов:

sudo mkdir -p /etc/nginx/mtls && cd /etc/nginx/mtls

Создадим самоподписанный корневой сертификат (Root CA):

openssl genrsa -out ca.key 4096

openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
   -subj "/C=US/O=ExampleCorp/OU=IT/CN=Example Root CA" -out ca.crt
# Укажите свои параметры владельца

Создадим сертификат для сервера реагирования:

openssl genrsa -out response.key 2048

openssl req -new -key response.key \
   -subj "/C=US/O=ExampleCorp/OU=IT/CN=response.<example.com>" -out response.csr
# Укажите свои параметры владельца

openssl x509 -req -in response.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
   -out response.crt -days 825 -sha256 \
   -extfile <(printf "subjectAltName=DNS:response.<example.com>\nkeyUsage=digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth")
# Укажите свой SAN

По аналогии создадим сертификат для сервера телеметрии:

openssl genrsa -out telemetry.key 2048

openssl req -new -key telemetry.key \
   -subj "/C=US/O=ExampleCorp/OU=IT/CN=telemetry.<example.com>" -out telemetry.csr
# Укажите свои параметры владельца

openssl x509 -req -in telemetry.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
   -out telemetry.crt -days 825 -sha256 \
   -extfile <(printf "subjectAltName=DNS:telemetry.<example.com>\nkeyUsage=digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth")
# Укажите свой SAN

Далее в OSMP экспортируем сертификат для Endpoint Agent: Параметры --> Тенанты --> Root tenant --> Параметры --> Сертификаты и экспортируем сертификат Endpoint Agent, который размещаем в ранее созданной директории /etc/nginx/mtls

Из экспортируемого pfx сертификата Endpoint Agent извлекаем данные:

openssl pkcs12 -in certificate.pfx -cacerts -nokeys -out ca-xdr.crt
openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out client.crt
openssl pkcs12 -in certificate.pfx -nocerts -nodes -out client.key

Далее установим права доступа:

chmod 600 *.key
chown root:root *.crt *.key *.csr

Далее установим Nginx:

sudo apt update
sudo apt install nginx

nginx -V
# Проверьте наличие модуля http_ssl_module (по умолчанию включен в Nginx)

Создайте файл конфигурации nginx по пути /etc/nginx/conf.d/asproxy.conf и отредактируйте его:

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

# Использование map для поддержки WebSocket
map $http_upgrade $connection_upgrade {
   default upgrade;
   ''      close;
}

server {
   listen 443 ssl http2;
   listen 9443 ssl;
   server_name response.<example.com>; # Укажите свой сервер

   ssl_certificate         /etc/nginx/mtls/resposne.crt;
   ssl_certificate_key     /etc/nginx/mtls/resposne.key;
   ssl_trusted_certificate /etc/nginx/mtls/ca.crt;
   ssl_client_certificate  /etc/nginx/mtls/ca-xdr.crt;
   ssl_verify_client       on;
   ssl_verify_depth        2;
   ssl_protocols           TLSv1.2 TLSv1.3;
   ssl_session_cache       shared:SSL:10m;

   proxy_set_header X-Client-Verify $ssl_client_verify;
   proxy_set_header X-Client-DN     $ssl_client_s_dn;
   proxy_set_header X-Client-Cert   $ssl_client_escaped_cert;

   proxy_http_version                 1.1;
   proxy_set_header Host              agentserver.<smp_domain>; # Укажите адрес agentserver
   proxy_set_header X-Real-IP         $remote_addr;
   proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;

   proxy_connect_timeout 5s;
   proxy_send_timeout    60s;
   proxy_read_timeout    60s;
   send_timeout          60s;

   proxy_ssl_server_name on;
   proxy_ssl_name        agentserver.<smp_domain>; # Укажите адрес agentserver
   proxy_ssl_verify      off;
   proxy_ssl_protocols   TLSv1.2 TLSv1.3;

   proxy_ssl_certificate     /etc/nginx/mtls/client.crt;
   proxy_ssl_certificate_key /etc/nginx/mtls/client.key;

    location / {
     proxy_pass https://agentserver.<smp_domain>; # Укажите адрес agentserver
 }

     location ^~ /vthost/sessions {
     proxy_pass https://agentserver.<smp_domain>:9443; # Укажите адрес agentserver

     proxy_set_header Upgrade    $http_upgrade;
     proxy_set_header Connection $connection_upgrade;

     proxy_read_timeout  3600s;
     proxy_send_timeout  3600s;

     proxy_request_buffering off;
     proxy_buffering         off;
 }

   access_log /var/log/nginx/response.access.log;
   error_log  /var/log/nginx/response.error.log warn;

   error_page 495 496 497 = /__mtls_error;
   location = /__mtls_error { return 403; }
}
server {
   listen 443 ssl http2;
   server_name telemetry.<example.com>; # Укажите свой сервер

   ssl_certificate         /etc/nginx/mtls/telemetry.crt;
   ssl_certificate_key     /etc/nginx/mtls/telemetry.key;
   ssl_trusted_certificate /etc/nginx/mtls/ca.crt;
   ssl_client_certificate  /etc/nginx/mtls/ca-xdr.crt;
   ssl_verify_client       on;
   ssl_verify_depth        2;
   ssl_protocols           TLSv1.2 TLSv1.3;
   ssl_session_cache       shared:SSL:10m;

   proxy_set_header X-Client-Verify $ssl_client_verify;
   proxy_set_header X-Client-DN     $ssl_client_s_dn;
   proxy_set_header X-Client-Cert   $ssl_client_escaped_cert;

   proxy_http_version                 1.1;
   proxy_set_header Host              in.ehoqhrjot93jdnmw23jqkxyfq.kuma.<smp_domain>; # Укажите свой адрес коллектора EDR
   proxy_set_header X-Real-IP         $remote_addr;
   proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;

   proxy_connect_timeout 10s;
   proxy_send_timeout    300s;
   proxy_read_timeout    300s;
   send_timeout          300s;

   proxy_ssl_server_name on;
   proxy_ssl_name        in.ehoqhrjot93jdnmw23jqkxyfq.kuma.<smp_domain>; # Укажите свой адрес коллектора EDR
   proxy_ssl_verify      off;
   proxy_ssl_protocols   TLSv1.2 TLSv1.3;


   proxy_ssl_certificate     /etc/nginx/mtls/client.crt;
   proxy_ssl_certificate_key /etc/nginx/mtls/client.key;

   proxy_request_buffering off;
   proxy_buffering         off;

   location / {
     proxy_pass https://in.ehoqhrjot93jdnmw23jqkxyfq.kuma.<smp_domain>:443; # Укажите свой адрес коллектора EDR
   }

   access_log /var/log/nginx/telemetry.access.log;
   error_log  /var/log/nginx/telemetry.error.log warn;

   error_page 495 496 497 = /__mtls_error;
   location = /__mtls_error { return 403; }
}

Далее в политике для KES'ов в настройках Endpoint Detection and Response Expert (on-premise) указываем в качестве сервера сбора телеметрии - https://telemetry.<example.com> на 443 порту, а в настройках подключения указываем созданный сертификат telemetry.crt, и для дополнительной защиты подставляем ранее экспортируемый с OSMP pfx сертификат для Endpoint Agent. Для сервера реагирования указываем - response.<example.com> на 443 порту, а в настройках подключения - созданный сертификат response.crt, и для дополнительной защиты всё тот же pfx сертификат для Endpoint Agent.

Инструкции по настройке

Руководство по утилите KDT

Дата обновления: 14.07.2026

KDT (Kaspersky Deployment Tool) - это основной инструмент командной строки для установки, обновления, настройки и обслуживания компонентов Kaspersky XDR Expert в кластере Kubernetes.

1. Основы и глобальное поведение

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

./kdt [ГЛОБАЛЬНЫЕ_ФЛАГИ] <команда> [ФЛАГИ_КОМАНДЫ]

Полезные глобальные флаги:

-v (--version): Показать версию и завершить работу.
-p (--keep-log): Сохранить временные файлы логов (полезно для отладки).
--no-progress: Скрыть индикатор прогресса (удобно для CI/CD пайплайнов).

Важные особенности:

Предварительные проверки: Перед выполнением большинства команд KDT проверяет аппаратное обеспечение, ОС, сеть и наличие установленного Bootstrap.
Коды возврата:
- 0 — успех.
- 1 — общая ошибка или провал валидации.
- 2 — прерывание по сигналу SIGINT (Ctrl+C). Обратите внимание: в KDT используется код 2, а не стандартный 130.
- 12 — ошибка драйвера выполнения контейнеров.

2. Сценарий первоначального развертывания

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

Шаг 1: Интерактивный мастер (`wizard`)

Вместо ручного написания YAML-файла используйте встроенный мастер. Он задаст все необходимые вопросы: от топологии узлов (primary/worker) и SSH-ключей до строки подключения к PostgreSQL и требований к паролю администратора.

./kdt wizard -k xdr-2.1.tar -o deployment.yaml

Требования к паролю администратора XDR: 10–256 символов, минимум 3 категории (верхний/нижний регистр, цифры, спецсимволы), без пробелов и комбинации .@.

Шаг 2: Применение конфигурации (`apply`)

После генерации файла запустите развертывание. Флаг --accept-eula позволяет выполнить установку в полностью автоматическом (неинтерактивном) режиме.

./kdt apply -k xdr-2.1.tar -i deployment.yaml --accept-eula

3. Повседневное администрирование

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

Проверка состояния и логи

Список компонентов: ./kdt state --list (или короткий алиас ./kdt s --list). Добавьте --with-deps, чтобы увидеть зависимости.
Детальный лог компонента: ./kdt state --log backup-operator

Получение логов контейнеров:

./kdt logs get --app kuma --last 24h --destination ./kuma_logs.txt
# или короткий алиас: ./kdt l --app kuma --last 24h

Выполнение действий над компонентами (`invoke`)

Команда invoke позволяет вызывать специфичные для компонентов действия (например, изменение размера дисков, настройка бэкапов, смена IP).

Примеры:

# Настроить NFS-хранилище для бэкапов
./kdt invoke backup-operator -a setBackupStore --param backup_target_url="nfs://storage.local:/backups"

# Создать ручной бэкап с хранением 5 копий
./kdt invoke backup-operator -a createBackup --param backup_retain=5

# Изменить ingress-IP шлюза
./kdt invoke gateway -a changeIngressIP --param ingress_ip="192.168.1.100"

# Увеличить диск KUMA Core
./kdt invoke kuma -a setCorePvcSize --param core_disk_request="500Gi"

Чтобы узнать, какие действия доступны для компонента, используйте: ./kdt describe <имя_компонента> (алиас ./kdt d).

Резервное копирование и восстановление состояния (`state`)

KDT позволяет делать снапшоты внутренней базы данных состояний:

# Создание бэкапа состояния
./kdt state --backup state_backup.tar

# Восстановление состояния (с опциональной очисткой старых данных)
./kdt state --restore --from-backup state_backup.tar --wipe

# Ротация ключа шифрования statedb
./kdt state --rotate-secret

4. Работа в изолированных контурах (Air-Gap)

Для сред без доступа к интернету используется отдельная утилита kdt-airgap-preparation. Процесс состоит из трех четких этапов:

Сканирование (scan): Выполняется на целевом изолированном узле. Создает файл инвентаризации с перечнем недостающих пакетов.
```
kdt-airgap-preparation scan -k ~/.ssh/id_rsa -c config.yaml --airgap -i nodes-airgap.yaml
```
Загрузка (pull): Файл nodes-airgap.yaml переносится на машину с интернетом. Утилита скачивает все зависимости и упаковывает их в TAR-архив.
```
kdt-airgap-preparation pull -n nodes-airgap.yaml -a airgap-packages.tar
```
Установка (install): Архив переносится обратно в изолированный контур и развертывается на целевых узлах через SSH.
```
kdt-airgap-preparation install -a airgap-packages.tar -k ~/.ssh/id_rsa
```

После этого можно запускать стандартный ./kdt apply.

5. Продвинутые возможности и отладка

Управление контекстами (`ctx`)

Если вы обслуживаете несколько кластеров XDR, KDT позволяет переключаться между ними, подобно kubectl config use-context:

./kdt ctx                  # Показать список и активный контекст
./kdt ctx prod-cluster     # Переключиться на prod
./kdt ctx new-cluster --create # Создать новый (завершится после apply)

Распределенная трассировка (`traces`)

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

./kdt traces find --output traces.json --service-name kuma --min-duration 100ms --num-traces 10

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

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

./kdt export-config --filename current_config.yaml
# или короткий алиас:
./kdt ec -e current_config.yaml

6. Полезные переменные окружения

Поведение KDT можно гибко настраивать без изменения командной строки:

Переменная	Значение по умолчанию	Описание
KDT_YES	(не задана)	Установите `1` для автоматического подтверждения всех запросов (идеально для Ansible/CI/CD).
KDT_HOME	~/.kdt	Позволяет изменить домашнюю директорию утилиты.
KDT_PARALLELS_LIMIT	`-1` (авто)	Ограничение на количество параллельных операций.

Рекомендация: Всегда используйте команду ./kdt describe перед вызовом новых действий через invoke, чтобы убедиться в правильности передаваемых параметров, и регулярно экспортируйте конфигурацию (export-config) после внесения значимых изменений в кластер.

Диагностика и решение проблем

KEDR Expert on-premise: общие рекомендации по диагностике и устранению неполадок

Версия продукта: KEDR Expert on-premise 8.0
Актуальный список ограничений: support.kaspersky.ru/kedr-expert-on-premise/8.0/303912

1. Проверка основных компонентов KUMA (вне Kubernetes кластере):

systemctl status kuma-collector-<id>.service
systemctl status kuma-correlator-<id>.service
systemctl status kuma-storage-<id>.service

ID компонента можно скопировать из консоли OSMP (Ресурсы и сервисы - Активные сервисы)

Работа с логами через системное журналирование:

journalctl -xe
journalctl -xe | grep "<component-name-with-id>"
journalctl -u "<component-name-with-id>" -e

Работа с логами коллекторов, корреляторов и хранилищ:

less /opt/kaspersky/kuma/collector/<collector_id>/log/collector
less /opt/kaspersky/kuma/correlator/<correlator_id>/log/correlator
less /opt/kaspersky/kuma/storage/<storage_id>/log/storage
tail -n 100 /opt/Kaspersky/kuma/storage/<storage_id>/log/storage 
systemctl list-units | grep kuma-<name service>

Проверить открыт ли удаленный порт:

telnet <host-ip> <port>
nc -uzv <host-ip> <port>
nmap <host-ip> -p <port>

Проверить открытые порты:

firewall-cmd --list-ports

Открыть порт на firewall:

firewall-cmd --add-port=7210/tcp --permanent
firewall-cmd --reload

Проверка входящих подключений через tcpdump:

tcpdump -i any port 5144 -A

2. Полезные команды для работы с Kubernetes

Для Kubernetes k0s Cluster

Task	Command
View cluster info	k0s kubectl cluster-info
View nodes	k0s kubectl get nodes
View node details	k0s kubectl describe node <node-name>
Check k0s status	k0s status

Для Kubernetes k0s Pods

Task	Command
List all pods	k0s kubectl get pods -A
List all pods changes in real-time	k0s kubectl get pods -A --watch
List pods in a namespace	k0s kubectl get pods -n <namespace>
Pod details	k0s kubectl describe pod <pod-name> -n <namespace>
Delete pod	k0s kubectl delete pod <pod-name> -n <namespace>
Exec into a pod	k0s kubectl exec -it <pod-name> -n <namespace> -- /bin/sh

Для Kubernetes k0s Namespace

Task	Command
List namespaces	k0s kubectl get namespaces -A
Get all resources in namespace	k0s kubectl get all -n <namespace>
Delete namespace	k0s kubectl delete namespace <name>

Для Kubernetes k0s Secrets & ConfigMaps

Task	Command
List all secrets	k0s kubectl get secrets -A
List secrets in a namespace	k0s kubectl get secret -n <namespace>
View secret (base64 encoded)	k0s kubectl get secret <name> -n <namespace> -o yaml
Decode secret	k0s kubectl get secret -o jsonpath=”{.data.}” -n <namespace>
List configmaps	k0s kubectl get configmap
View configmap	k0s kubectl describe configmap <name>

Для Kubernetes k0s Logs

Task	Command
View logs of a pod	k0s kubectl logs <pod-name> -n <namespace>
Get logs of a pod in a real time	k0s kubectl logs -f <pod-name> -n <namespace>
Save a specific log to the file	k0s kubectl logs -f <pod-name> -n <namespace> > log.txt
Stream logs	k0s kubectl logs -f <pod-name> -n <namespace>
View logs of previous run	k0s kubectl logs --previous <pod-name> -n <namespace>

Для Kubernetes k0s Deployments & Services

Task	Command
List all deployments	k0s kubectl get deployments -A
List deployments in a namespace	k0s kubectl get deployments -n <namespace>
List services	k0s kubectl get svc
View deployment status	k0s kubectl rollout status deployment/<name>
Restart deployment	k0s kubectl rollout restart deployment <name>

Для Kubernetes k0s PVC

Task	Command
List all PV	K0s kubectl get pvc -A
List PVCs in a namespace	k0s kubectl get pvc -n <namespace>
PVC details	k0s kubectl describe pvc <pvc-name> -n <namespace>
Edit a PVC in a namespace	k0s kubectl edit pvc -n <namespace>
List all PV	K0s kubectl get pv -A
List PVCs in a namespace	k0s kubectl get pv -n <namespace>
PVC details	k0s kubectl describe pv <pvc-name> -n <namespace>

3. Получение диагностической информации о KEDR (XDR) компонентах

Утилита KDT позволяет получать диагностическую информацию о компонентах KEDR (XDR), устранять неполадки самостоятельно или с помощью службы технической поддержки Kaspersky.
1) После установки вы можете выполнить следующую команду, чтобы просмотреть список всех установленных компонентов:

./kdt state

2) Отобразится список установленных компонентов. Правильно установленные компоненты имеют статус "Succeeded". Если установка компонента завершилась неудачно, этот компонент имеет статус "Failed".
3) Чтобы просмотреть полный журнал установки некорректно установленного компонента, выполните следующую команду:

./kdt state -l <имя_компонента>

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

./kdt logs get <флаг>

a. Где <флаги> - это параметры команды, которая позволяет настроить результат ведения журнала.
b. Вы можете указать следующие параметры ведения журнала:

Период регистрации, например, все журналы за последние 12 часов:

./kdt logs get --to-archive --last=12h

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

./kdt logs get -D ./path_to_folder/ --last=12h

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

./kdt logs get -h
./kdt logs get --help

6) Логи также можно загрузить непосредственно из pod'ов. Для этого выполните команды (не забудьте изменить namespace):

k0s kubectl get pods -A
k0s kubectl get pods -n irp 
k0s kubectl logs interpreter-58c5856f7c-hfd87 -n irp

Где имя interpreter-58c5856f7c-hfd87 должно быть изменено на уникальное имя вашего pod'а

Диагностика и решение проблем

Очистка событий в хранилище (освобождение места)

Вариант 1: Автоматическая ротация через политику хранения

Перейдите в Ресурсы и сервисы - Активные сервисы
Нажмите на имя нужного сервиса хранилища
Измените условие хранения:

Примечание: Изменения применяются в течение ~1 часа. Устаревшие разделы будут удалены автоматически.

Вариант 2: Ручная очистка разделов

Перейдите в Ресурсы и сервисы - Активные сервисы
Нажмите правой кнопкой на имя нужного сервиса хранилища
Перейдите в просмотр разделов и вручную удалите выбранные разделы (место на диске будет увеличено сразу)

Плейбуки

Плейбуки в Kaspersky EDR Expert 8.1: Полное руководство

ℹ️ Важно: Информация, приведённая в данной статье, является разработкой команды pre-sales и/или AntiAPT Community и НЕ является официальной рекомендацией вендора.
Официальная документация по разделу «Плейбуки».

Источники информации

Статья основана на следующих материалах:

Источник	Описание
Официальная справка Kaspersky EDR Expert 8.1	Разделы «Плейбуки», «Модель данных алерта», «Модель данных инцидента», «Действия по реагированию»
KUMA Community	Статьи «Триггеры в плейбуках» и «Действия в плейбуках» (https://kb.kuma-community.ru)
Предустановленные плейбуки [KL]	Реальные примеры алгоритмов от Лаборатории Касперского (P001–P005 и др.)
Практический опыт	Настройка плейбуков в реальных инфраструктурах и разбор типовых ошибок

Для кого эта статья

Статья предназначена для:

Аналитиков SOC, которые хотят научиться создавать и читать плейбуки
Инженеров внедрения, настраивающих Kaspersky EDR Expert у заказчиков
Руководителей SOC, планирующих автоматизацию реагирования

Что вы получите после прочтения

После изучения материала вы сможете:

Читать любой плейбук и понимать, что он делает (разбирать JSON и jq-выражения)
Писать свои плейбуки с нуля — от простого условия до сложного алгоритма
Отлаживать плейбуки, которые не работают
Избегать типичных ошибок, на которых теряют часы новички
Настраивать автоматическое реагирование на критические угрозы

Ограничения

Синтаксис jq-выражений, модель данных и имена полей могут меняться между версиями Kaspersky EDR Expert. Всегда проверяйте актуальную документацию для вашей версии.
Перед применением в продуктивной среде обязательно тестируйте плейбуки в режиме «Обучение».

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

1.1. Определение

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

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

1.2. Режимы работы плейбука

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

Режим	Как работает	Участие аналитика
Автоматический	Плейбук автоматически запускается при обнаружении соответствующих алертов или инцидентов	Не требуется
Обучение	Плейбук запрашивает разрешение пользователя на запуск при обнаружении соответствующих алертов или инцидентов	Требуется подтверждение
Ручной	Плейбук можно запустить только вручную	Полный контроль

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

Плейбуки решают три ключевые задачи SOC:

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

1.4. Область применения

Плейбуки используются в следующих сценариях:

Автоматическое реагирование на критические угрозы — ransomware, sandbox-детекты, компрометация учётных записей
Автоматическое обогащение данных — отправка наблюдаемых объектов (IP, хеши, домены, URL) в Kaspersky Threat Intelligence Portal через действие iocsEnrichment для получения дополнительной информации об угрозах
Ручное реагирование — аналитик выбирает инцидент и запускает плейбук
Расследование — сбор дампов памяти, образов дисков, ключей реестра

1.5. Перечень возможностей плейбуков

Плейбуки в Kaspersky EDR Expert 8.1 предоставляют следующие возможности:

Возможность	Описание
Автоматический запуск	Плейбук срабатывает по триггеру при обнаружении соответствующих алертов/инцидентов
Ручной запуск	Аналитик сам выбирает объекты и запускает плейбук
Триггеры на jq	Гибкая фильтрация по свойствам, активам, наблюдаемым объектам, событиям
19 действий по реагированию	От сбора форензики до изоляции хостов и блокировки учётных записей
Визуальный редактор	Создание алгоритмов без написания JSON вручную
Тестовый режим	Эмуляция запуска без выполнения реальных действий
Ручное подтверждение	Требование одобрения перед опасными действиями
Версионирование	Автоматическое сохранение истории изменений с возможностью отката
Наследование тенантов	Плейбуки автоматически доступны дочерним тенантам

2. Типы плейбуков и область действия

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

2.1. Два типа плейбуков

В Kaspersky EDR Expert 8.1 существует два типа плейбуков: предустановленные (от Лаборатории Касперского) и пользовательские (созданные администраторами SOC).

2.1.1. Предустановленные плейбуки [KL]

Предустановленные плейбуки созданы специалистами «Лаборатории Касперского» и отмечены префиксом [KL] в названии. Они основаны на правилах корреляции KUMA и закрывают типовые сценарии реагирования на угрозы.

Список предустановленных плейбуков:

Название	Область действия	Назначение
`[KL] P001` "Creation of executable files by office applications"	Алерт	Реагирование на фишинг через офисные приложения
`[KL] P002` "Windows Event Log was cleared"	Инцидент	Блокировка учётной записи при очистке журналов Windows
`[KL] P003` "Suspicious child process from wmiprvse.exe"	Алерт	Завершение подозрительных процессов и AV-проверка
`[KL] P004` "Sandbox Medium Detect"	Алерт	Блокировка файлов с уровнем важности «Средний» из Sandbox
`[KL] P005` "Sandbox High Detect"	Алерт	Блокировка файлов с уровнем важности «Высокий» из Sandbox
`[KL] "Playbook for checking external IP addresses"`	Инцидент	Обогащение внешних IP через Kaspersky TIP и изоляция хостов
`[KL] "Playbook for isolating a device where an infected file is detected"`	Инцидент	Изоляция устройства с заражённым файлом

Особенности предустановленных плейбуков:

Операция	Доступна	Комментарий
Просмотр	✅	Полная информация о триггере и алгоритме
Изменение режима работы	✅	Можно переключить между Автоматическим / Обучение / Ручной
Изменение триггера	✅	Можно адаптировать условие срабатывания
Изменение алгоритма	❌	JSON-код алгоритма заблокирован для редактирования
Удаление	❌	Предустановленные плейбуки нельзя удалить
Дублирование	✅	Можно создать копию и модифицировать её

Как модифицировать предустановленный плейбук:

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

Открыть плейбук [KL] в Консоли OSMP (Мониторинг → Плейбуки).
Нажать кнопку «Дублировать и изменить».
Система создаст копию плейбука с новым именем (например, My P003 Custom).
В копии можно изменять алгоритм, триггер и все параметры.
Оригинальный плейбук [KL] остаётся неизменным.

💡 Рекомендация: Перед дублированием убедитесь, что настроены интеграции, необходимые для работы плейбука (Active Directory для blockLDAPAccount, Kaspersky TIP для iocsEnrichment, KASAP для assignKasapGroup).

2.1.2. Пользовательские плейбуки

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

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

Параметр	Назначение
Область действия	Алерт или Инцидент (определяет синтаксис jq-выражений)
Триггер	jq-выражение, определяющее условия автоматического запуска
Алгоритм	JSON-код, описывающий последовательность действий

Дополнительные возможности:

Импорт/экспорт через XDR REST API для переноса плейбуков между тенантами
Полное управление версиями (сравнение, восстановление)
Настройка ручного подтверждения для опасных действий
Использование любых из 19 действий по реагированию

2.2. Область действия (критическое ограничение)

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

2.2.1. Как это влияет на синтаксис

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

Элемент	Для области «Алерт»	Для области «Инцидент»
Ключевое слово	`alert`	`incident`
Доступ к активам	`alert.Assets[]`	`incident.Alerts[].Assets[]`
Доступ к наблюдаемым объектам	`alert.Observables[]`	`incident.Alerts[].Observables[]`
Доступ к событиям	`alert.BaseEvents[]`	`incident.Alerts[].BaseEvents[]`
Доступ к исходным событиям	`alert.OriginalEvents[]`	`incident.Alerts[].OriginalEvents[]`
Доступ к просканированным файлам	`alert.ScannedFiles[]`	`incident.Alerts[].ScannedFiles[]`

2.2.2. Почему структура различается

Различие в синтаксисе связано с моделью данных:

Алерт — самостоятельный объект. Его активы, наблюдаемые объекты и события лежат непосредственно в корне: alert.Assets[].
Инцидент — агрегатор нескольких алертов. У инцидента нет собственных активов — все данные находятся внутри вложенных алертов: incident.Alerts[].Assets[].

2.2.3. Примеры для разных областей действия

Пример 1: Извлечение ID хостов

Для плейбука с областью «Алерт»:

[alert.Assets[] | select(.Type == "host") | .ID]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Assets[] | select(.Type == "host") | .ID]

Пример 2: Извлечение хешей SHA256

Для плейбука с областью «Алерт»:

[alert.Observables[] | select(.Type == "sha256") | .Value]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Observables[] | select(.Type == "sha256") | .Value]

2.2.4. Ошибка при несоответствии области действия

Если в плейбуке с областью «Алерт» использовать ключевое слово incident (или наоборот), система выдаст ошибку:

Expression does not match the selected scope

Типичные ошибки:

Область плейбука	Неправильное выражение	Правильное выражение
Алерт	`incident.Alerts[].Assets[]`	`alert.Assets[]`
Алерт	`incident.Severity`	`alert.Severity`
Инцидент	`alert.Assets[]`	`incident.Alerts[].Assets[]`
Инцидент	`alert.Severity`	`incident.Severity`

2.2.5. Как выбрать область действия

Критерий	Выбирайте «Алерт»	Выбирайте «Инцидент»
Сценарий	Реагирование на одиночное событие	Реагирование на расследование из нескольких связанных алертов
Пример	Sandbox-детект одного файла	Компрометация учётной записи с несколькими алертами
Данные	Все данные в одном объекте	Нужно агрегировать данные из нескольких алертов
Предустановленные плейбуки	P001, P003, P004, P005	P002, External IP, Infected file

💡 Рекомендация: Если сценарий реагирования требует анализа нескольких связанных событий (например, фишинг + запуск вредоноса + очистка журналов), выбирайте область «Инцидент». Для точечных детектов (один файл, один процесс) достаточно области «Алерт».

2.3. Дочерние инциденты (ограничение автозапуска)

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

2.3.1. Что такое дочерние инциденты

В Kaspersky EDR Expert поддерживается сегментация — разделение инфраструктуры на логические сегменты (тенанты). При срабатывании правила корреляции может создаваться:

Родительский инцидент — в корневом тенанте
Дочерние инциденты — в дочерних тенантах (копии родительского для каждого сегмента)

2.3.2. Почему автоматический запуск не работает

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

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

2.3.3. Как работать с дочерними инцидентами

Способ 1: Ручной запуск

Открыть дочерний инцидент в Консоли OSMP (Мониторинг → Инциденты → XDR-инциденты).
Нажать «Выбрать плейбук».
Выбрать нужный плейбук из списка.
При необходимости выбрать целевые активы и наблюдаемые объекты.
Нажать «Запустить».

Способ 2: Настройка сегментации

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

Способ 3: Реагирование через родительский инцидент

Если плейбук работает с родительским инцидентом, его действия (например, addFilePreventionRules с selector: execution-tenant) применяются ко всем хостам в тенанте, включая дочерние. Это позволяет централизованно реагировать на угрозу.

2.4. Наследование тенантов

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

2.4.1. Как работает наследование

Событие	Результат
Создан плейбук в корневом тенанте	Автоматически доступен во всех существующих дочерних тенантах
Добавлен новый дочерний тенант	Плейбук автоматически наследуется новым тенантом
Изменён плейбук в корневом тенанте	Изменения применяются во всех дочерних тенантах
Дочерний тенант дублировал плейбук	Копия становится локальной и не зависит от родительской версии

2.4.2. Как отключить наследование

Если плейбук специфичен для конкретного тенанта (например, использует уникальные интеграции, локальные скрипты или специфичные пути к файлам), наследование можно отключить:

Открыть плейбук для создания или изменения.
В настройках плейбука снять флажок «Наследовать дочерними тенантами».
Сохранить изменения.

После этого плейбук будет доступен только в том тенанте, где был создан.

2.4.3. Практические рекомендации

Сценарий	Рекомендация
Плейбук использует стандартные действия (`deleteFile`, `isolateHost`, `addFilePreventionRules`)	✅ Оставить наследование включённым
Плейбук использует интеграцию с локальным скриптом	❌ Отключить наследование
Плейбук обращается к специфичному пути в файловой системе	❌ Отключить наследование
Плейбук использует интеграцию с Active Directory, доступной во всех тенантах	✅ Оставить наследование включённым
Плейбук использует Kaspersky TIP (лицензия только в корневом тенанте)	❌ Отключить наследование

💡 Рекомендация: При создании нового плейбука всегда оценивайте, нужен ли он во всех тенантах. Если есть сомнения — отключите наследование. Включить его позже можно в любой момент.

3. Архитектура плейбука

В этом разделе разберём структуру плейбука: из каких компонентов он состоит, какие параметры обязательны, как устроен алгоритм и как система выполняет шаги.

3.1. Три компонента плейбука

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

Компонент	Назначение	Где настраивается
Параметры плейбука	Определение свойств плейбука (имя, область действия, режим работы)	В интерфейсе Консоли OSMP
Триггер плейбука	Определение условий автоматического запуска	В интерфейсе Консоли OSMP (jq-выражение)
Алгоритм плейбука	Определение последовательности действий	В интерфейсе Консоли OSMP (JSON-код или визуальный редактор)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249249 «Плейбуки».

3.2. Параметры плейбука

При создании плейбука в Консоли OSMP настраиваются следующие параметры:

3.2.1. Обязательные параметры

Параметр	Описание	Требования
Имя	Название плейбука	Уникально в рамках тенанта
Область действия	Тип объекта, с которым работает плейбук	`Алерт` или `Инцидент` (выбирается один)
Версия	Версия плейбука	Минимальная длина — 1 символ
dslSpecVersion	Версия схемы DSL	Минимальная длина — 1 символ
actionsSpecVersion	Версия спецификации действий	Минимальная длина — 1 символ
executionFlow	Массив шагов выполнения	Минимум один шаг

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

3.2.2. Дополнительные параметры

Параметр	Описание	Значение по умолчанию
Описание	Текстовое описание плейбука	Пусто
Режим работы	Автоматический / Обучение / Ручной	Обучение (для предустановленных)
Теги	Метки для фильтрации (до 30 тегов)	Пусто
playbookRunTimeout	Максимальное время выполнения плейбука	`24h`
timeouts	Политики тайм-аута для шагов	Пусто
input	jq-выражение для преобразования входящих данных	Пусто
output	jq-выражение для изменения вывода плейбука	Пусто

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 249267 «Создание плейбуков» и 267548 «Алгоритм плейбука».

3.3. Режимы работы плейбука

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

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

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249249 «Плейбуки».

3.3.1. Поведение при одновременном запуске (для автоматического режима)

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

Поведение	Описание
Добавить в очередь (по умолчанию)	Новый запуск добавляется в очередь и выполняется после завершения текущего
Завершить текущий и запустить новый	Текущий запуск прерывается, начинается новый
Не запускать новые	Новый запуск не выполняется, продолжается текущий

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков».

3.4. Алгоритм плейбука (executionFlow)

Алгоритм плейбука описывается в формате JSON и определяет последовательность шагов выполнения.

3.4.1. Структура JSON алгоритма

{
  "version": "1",
  "dslSpecVersion": "1.1.0",
  "actionsSpecVersion": "1",
  "playbookRunTimeout": "24h",
  "executionFlow": [
    /* шаги выполнения */
  ]
}

Обязательные поля:

version — версия плейбука
dslSpecVersion — версия схемы DSL
actionsSpecVersion — версия спецификации действий
executionFlow — массив шагов выполнения

Опциональные поля:

playbookRunTimeout — максимальное время выполнения (по умолчанию 24h, максимум 48h)
input — jq-выражение для преобразования входящих данных
output — jq-выражение для изменения вывода плейбука
timeouts — политики тайм-аута для шагов

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

3.4.2. Типы шагов выполнения

Массив executionFlow содержит шаги, которые выполняются в порядке, указанном в массиве. Существует пять типов шагов:

Тип шага	Назначение	Обязательные параметры
Действие (ResponseFunction)	Выполнение действия по реагированию	`type`, `assets`
Цикл (Loop)	Повторение набора шагов для каждого элемента массива	`input`, `steps`
Параллель (Parallel)	Параллельное выполнение нескольких веток шагов	`branches`, `aggregate`
Ветвление (Decision)	Условное выполнение шагов	`conditions`
Обновление данных (UpdateData)	Сохранение промежуточных данных в операционные данные	`filter` или `output`

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 270357, 270351, 270352, 270354, 270355.

3.4.3. Пример: шаг типа «Действие»

Из предустановленного плейбука [KL] P003 "Suspicious child process from wmiprvse.exe" (область действия — Алерт):

{
  "action": {
    "function": {
      "type": "blockLDAPAccount",
      "assets": "${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"
    }
  },
  "onError": "stop"
}

Разбор:

type: "blockLDAPAccount" — действие блокировки учётной записи в Active Directory
assets — jq-выражение, извлекающее ID пользователей-атакующих из алерта
onError: "stop" — при ошибке прервать выполнение плейбука

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

3.4.4. Пример: шаг типа «Цикл»

Из того же плейбука [KL] P003:

{
  "loop": {
    "batchSize": 1,
    "input": "${ [alert.OriginalEvents[] | [select(.DestinationProcessName != null and .DestinationProcessName != \"\")][] | .DestinationProcessName] }",
    "mode": "parallel",
    "onError": "stop",
    "steps": [
      {
        "action": {
          "function": {
            "type": "killProcess",
            "assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}",
            "params": {
              "path": "${ .[0] }"
            }
          }
        }
      }
    ]
  }
}

Разбор:

input — jq-выражение, извлекающее имена процессов из исходных событий алерта
batchSize: 1 — обрабатывать по одному элементу за итерацию
mode: "parallel" — выполнять итерации параллельно
.[0] — внутри шагов цикла текущий элемент доступен через .[0]

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

3.4.5. Пример: шаг типа «Ветвление»

Из предустановленного плейбука [KL] "Playbook for checking external IP addresses" (область действия — Инцидент):

{
  "decision": {
    "conditions": [
      {
        "condition": "${[.details.observableData[] | select(.status == \"ok\" and .ipObservableData.ipGeneralInfo.threatScore > 80)] | length > 0}",
        "name": "Condition 1",
        "steps": [
          /* шаги, выполняемые при истинности условия */
        ]
      }
    ]
  }
}

Разбор:

condition — jq-выражение, возвращающее true или false
name — название условия (для удобства чтения)
steps — шаги, выполняемые, если условие истинно

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] Playbook for checking external IP addresses».

3.4.6. Обработка ошибок

Каждый шаг может содержать параметр onError, определяющий поведение при ошибке:

Значение	Поведение
`stop`	Прервать выполнение плейбука
`continue`	Пропустить шаг и продолжить выполнение

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

3.5. Визуальный редактор vs JSON

Алгоритм плейбука можно создавать двумя способами:

3.5.1. Визуальный редактор

Преимущества:

Не требует знания синтаксиса JSON
Автоматическая проверка синтаксиса
Подсказки по полям при вводе jq-выражений
Наглядное отображение потока выполнения

Недостатки:

Ограниченная гибкость по сравнению с ручным написанием JSON
Сложность при отладке больших алгоритмов

3.5.2. Ручное написание JSON

Преимущества:

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

Недостатки:

Требует знания синтаксиса JSON и jq
Риск синтаксических ошибок

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 303486 «Настройка шагов выполнения плейбука в визуальном редакторе».

3.6. Статусы плейбуков

Плейбук может находиться в одном из следующих статусов:

Статус	Описание
Активный	Плейбук готов к использованию
Черновик	Плейбук создан, но не активирован. Нельзя запустить, но можно изменить
Удалено	Плейбук удалён. Доступен только для просмотра и копирования
Недоступно	Плейбук использует недоступный веб-плагин или действия не по лицензии

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264606 «Таблица плейбуков».

4. Модель данных: Алерт vs Инцидент

В этом разделе разберём, как Kaspersky EDR Expert хранит информацию об угрозах, какие данные доступны в плейбуках и как правильно к ним обращаться в зависимости от контекста выполнения.

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 269125 «Модель данных алерта»
Официальная справка Kaspersky EDR Expert 8.1, раздел 269168 «Модель данных инцидента»
Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука»
Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука»
Примеры из предустановленных плейбуков [KL]

4.1. Модель данных алерта

Алерт — это объект, создаваемый правилом корреляции KUMA при обнаружении события, соответствующего условиям правила. Алерт содержит информацию об обнаруженной угрозе, включая связанные активы, наблюдаемые объекты и события.

4.1.1. Ключевые поля алерта

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

Поле	Тип	Описание
`Name`	Строка	Название алерта
`Severity`	Строка	Важность алерта (`critical`, `high`, `medium`, `low`)
`Status`	Строка	Статус алерта (`new`, `inProgress`, `inIncident`, `closed`)
`DetectSource`	Строка	Источник обнаружения (`KES`, `KATA`, `KUMA`)
`CreatedAt`	Строка	Дата и время создания алерта
`Assets`	Массив	Активы, связанные с алертом (хосты, пользователи)
`Observables`	Массив	Наблюдаемые объекты (хеши, IP, URL, пути к файлам)
`BaseEvents`	Массив	Нормализованные события
`OriginalEvents`	Массив	Исходные события
`ScannedFiles`	Массив	Просканированные файлы
`DetectionTechnologies`	Массив	Технологии обнаружения (`SB`, `IOC`, `ML`, `AV`)
`MITRETactics`	Массив	Тактики MITRE ATT&CK
`MITRETechniques`	Массив	Техники MITRE ATT&CK

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 269125 «Модель данных алерта».

4.1.2. Структура элементов массива Assets

Каждый элемент массива Assets содержит информацию об активе:

Поле	Тип	Описание
`ID`	Строка	Уникальный идентификатор актива (UUID)
`Name`	Строка	Имя актива (имя хоста или учётной записи)
`Type`	Строка	Тип актива (`host`, `user`)
`IsAttacker`	Булево	Является ли актив атакующим
`IsVictim`	Булево	Является ли актив жертвой

Пример из документации ([KL] P003):

[ alert.Assets[] | select(.Type == "user" and .IsAttacker) | .ID]

Это jq-выражение извлекает ID всех пользователей-атакующих из алерта.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

4.1.3. Структура элементов массива Observables

Каждый элемент массива Observables содержит информацию о наблюдаемом объекте:

Поле	Тип	Описание
`Type`	Строка	Тип наблюдаемого объекта (`sha256`, `md5`, `ip`, `fileFullName`, `fileName`, `url`, `domain`)
`Value`	Строка	Значение наблюдаемого объекта
`Details`	Строка	Дополнительные сведения (например, путь к файлу для хеша)

Пример из документации ([KL] P004):

[alert.ScannedFiles[] | select(any(.DetectionTechnologies[] == "SB"; .)) | .Hashes | map(.Value)] | flatten

Это jq-выражение извлекает хеши файлов, обнаруженных через Sandbox.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

4.2. Модель данных инцидента

Инцидент — это объект, объединяющий несколько связанных алертов в одно расследование. Инцидент создаётся либо автоматически (по правилам сегментации или корреляции), либо вручную аналитиком.

4.2.1. Ключевые поля инцидента

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

Поле	Тип	Описание
`Name`	Строка	Название инцидента
`Severity`	Строка	Важность инцидента (`critical`, `high`, `medium`, `low`)
`Priority`	Строка	Приоритет инцидента
`Status`	Строка	Статус инцидента
`CreatedAt`	Строка	Дата и время создания инцидента
`Alerts`	Массив	Алерты, входящие в инцидент

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 269168 «Модель данных инцидента».

4.2.2. Вложенная структура инцидента

Критически важно: У инцидента нет собственных активов, наблюдаемых объектов и событий. Все эти данные находятся внутри вложенных алертов в массиве Alerts.

incident
├── Name, Severity, Priority, Status, CreatedAt
└── Alerts[]                  ← массив алертов
    ├── Name, Severity, Status, DetectSource
    ├── Assets[]              ← активы каждого алерта
    ├── Observables[]         ← наблюдаемые объекты каждого алерта
    ├── BaseEvents[]          ← нормализованные события каждого алерта
    ├── OriginalEvents[]      ← исходные события каждого алерта
    └── ScannedFiles[]        ← просканированные файлы каждого алерта

4.2.3. Как обращаться к данным инцидента

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

Данные	Правильное обращение	Неправильное обращение
Активы инцидента	`incident.Alerts[].Assets[]`	`incident.Assets[]`
Наблюдаемые объекты инцидента	`incident.Alerts[].Observables[]`	`incident.Observables[]`
Базовые события инцидента	`incident.Alerts[].BaseEvents[]`	`incident.BaseEvents[]`
Исходные события инцидента	`incident.Alerts[].OriginalEvents[]`	`incident.OriginalEvents[]`
Просканированные файлы инцидента	`incident.Alerts[].ScannedFiles[]`	`incident.ScannedFiles[]`

Пример из документации ([KL] P002):

[ incident.Alerts[] | select(.OriginalEvents[] | .ExternalID == "R050") | .Assets[] | select(.Type == "user" and .IsAttacker) | .ID]

Это jq-выражение извлекает ID пользователей-атакующих из алертов инцидента, у которых исходные события содержат ExternalID == "R050".

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P002».

4.3. Три типа данных в плейбуке

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

Тип данных	Обращение	Доступ	Назначение
Глобальные	`alert.` или `incident.`	Только чтение	Содержат информацию об алерте или инциденте
Операционные	`.input.*`	Чтение и запись	Передаются между шагами алгоритма
Локальные	В рамках шага	Чтение и запись	Ограничены одним шагом

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

4.3.1. Глобальные данные

Определение из документации:

«Глобальные данные содержат информацию об алерте или инциденте. Доступны только для чтения на любом шаге.»

Как обращаться:

Для плейбука с областью действия «Алерт»: alert.Assets[], alert.Observables[], alert.Severity
Для плейбука с областью действия «Инцидент»: incident.Alerts[], incident.Severity, incident.Priority

Особенности:

Доступны на любом шаге алгоритма
Нельзя изменить через плейбук
Ключевые слова alert и incident используются без точки в начале

Пример из документации ([KL] P003):

[ alert.Assets[] | select(.Type == "user" and .IsAttacker) | .ID]

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука» и 271611 «[KL] P003».

4.3.2. Операционные данные

Определение из документации:

«Операционные данные передаются между шагами алгоритма. Обращение через контекст .input.»

Как обращаться:

Через префикс .input: .input.hashes, .input.hostIds, .input.assets

Особенности:

Создаются и изменяются шагами updateData
Доступны на любом шаге после сохранения
В операционных данных имена полей задаются разработчиком плейбука

Пример из документации ([KL] "Playbook for isolating a device where an infected file is detected"):

{
  "decision": {
    "conditions": [
      {
        "condition": "${((.input.assets // []) | length) > 0 and ([.input.observables[] | select(.type == \"md5\" or .type == \"sha256\" and .value != null and .value != \"\")] | length) > 0}",
        "name": "has input data"
      }
    ]
  }
}

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

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 324933 «[KL] Playbook for isolating a device where an infected file is detected».

4.3.3. Локальные данные

Локальные данные ограничены одним шагом выполнения. Они создаются через параметр input шага и преобразуются в операционные данные через параметр output.

Пример из документации ([KL] P003) — шаг Loop:

{
  "loop": {
    "input": "${ [alert.OriginalEvents[] | [select(.DestinationProcessName != null and .DestinationProcessName != \"\")][] | .DestinationProcessName] }",
    "steps": [
      {
        "action": {
          "function": {
            "type": "killProcess",
            "params": {
              "path": "${ .[0] }"
            }
          }
        }
      }
    ]
  }
}

В этом примере:

input шага loop — jq-выражение, возвращающее массив имён процессов
Внутри шагов цикла текущий элемент доступен через .[0] (локальные данные)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

4.4. Контекст выполнения: триггер vs алгоритм

Согласно официальной документации (раздел 273327), синтаксис обращения к данным зависит от того, где пишется jq-выражение — в триггере или в алгоритме.

4.4.1. В триггере плейбука

Определение из документации:

«Триггер плейбука — это фильтр, позволяющий выбрать алерты или инциденты, для которых необходимо запустить плейбук. Фильтр применяется к каждому объекту (алерту или инциденту) индивидуально.»

Контекст триггера — это сам алерт или инцидент, поэтому обращение идёт без префикса:

Примеры из документации:

Триггер плейбука [KL] P001 (область «Алерт»):

[.OriginalEvents[] | .ExternalID == "R350"] | any

Триггер плейбука [KL] P002 (область «Инцидент»):

[.Alerts[] | .OriginalEvents[] | .ExternalID == "R050"] | any

Триггер плейбука [KL] P004 (область «Алерт»):

event.new and .Severity == "medium" and any(.DetectionTechnologies[] == "SB"; .)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 271609–271772 (предустановленные плейбуки [KL]).

4.4.2. В алгоритме плейбука (executionFlow)

Определение из документации:

«Алгоритм плейбука описывается в формате JSON и состоит из шагов выполнения.»

В алгоритме используются полные пути с ключевыми словами alert или incident:

Пример из документации ([KL] P002):

[ incident.Alerts[] | select(.OriginalEvents[] | .ExternalID == "R050") | .Assets[] | select(.Type == "user" and .IsAttacker) | .ID]

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P002».

4.4.3. Сравнительная таблица

Контекст	Обращение к важности	Обращение к активам	Обращение к наблюдаемым объектам
Триггер (алерт)	`.Severity`	`.Assets[]`	`.Observables[]`
Триггер (инцидент)	`.Severity`	`.Alerts[].Assets[]`	`.Alerts[].Observables[]`
Алгоритм (алерт)	`alert.Severity`	`alert.Assets[]`	`alert.Observables[]`
Алгоритм (инцидент)	`incident.Severity`	`incident.Alerts[].Assets[]`	`incident.Alerts[].Observables[]`

4.5. Визуальная шпаргалка

┌─────────────────────────────────────────────────────────────┐
│                     ПЛЕЙБУК (Playbook)                      │
├─────────────────────────────────────────────────────────────┤
│  ТРИГГЕР                                                    │
│  Контекст: сам алерт/инцидент                               │
│  Обращение: .Severity, .Name, .Alerts[], .Assets[]          │
│  (без префикса alert. или incident.)                        │
├─────────────────────────────────────────────────────────────┤
│  АЛГОРИТМ (executionFlow)                                   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ ГЛОБАЛЬНЫЕ ДАННЫЕ (read-only)                       │   │
│  │ Для алерта:  alert.Assets[]                         │   │
│  │              alert.Observables[]                    │   │
│  │              alert.Severity                         │   │
│  │ Для инцидента: incident.Alerts[].Assets[]           │   │
│  │                incident.Alerts[].Observables[]      │   │
│  │                incident.Severity                    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ ОПЕРАЦИОННЫЕ ДАННЫЕ (read/write)                    │   │
│  │ .input.hashes                                       │   │
│  │ .input.hostIds                                      │   │
│  │ .input.assets                                       │   │
│  │ (обновляются через updateData)                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ ЛОКАЛЬНЫЕ ДАННЫЕ (в рамках шага)                    │   │
│  │ .[0] — текущий элемент в цикле                      │   │
│  │ . — текущий контекст                                │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Шаги: action → decision → loop → parallel → updateData     │
└─────────────────────────────────────────────────────────────┘

5. Чувствительность к регистру (КРИТИЧНО)

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

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука»
Примеры из предустановленных плейбуков [KL] (разделы 271609–324934)
Практический опыт команды pre-sales и AntiAPT Community

5.1. Почему регистр имеет значение

Согласно официальной документации (раздел 267548), jq-выражения в плейбуках чувствительны к регистру символов. Это означает, что Assets и assets — это два разных поля, и система обрабатывает их по-разному.

Причина: Модель данных Kaspersky EDR Expert использует строгую типизацию с фиксированными именами полей. Имена полей в модели данных алерта и инцидента зафиксированы в документации и не могут быть изменены.

Критически важно: Даже одна буква в неправильном регистре приведёт к ошибке выполнения плейбука или к тому, что jq-выражение вернёт пустой результат.

5.2. Примеры ошибок из-за регистра

5.2.1. Ошибка 1: Неправильный регистр ключевого слова

Неправильно:

Alert.Assets[]

Правильно:

alert.Assets[]

Объяснение: Ключевое слово alert всегда пишется строчными буквами. Alert с заглавной буквы система не распознает.

ℹ️ Источник: Примеры из официальной документации ([KL] P001–P005).

5.2.2. Ошибка 2: Неправильный регистр имени поля

Неправильно:

alert.assets[]

Правильно:

alert.Assets[]

Объяснение: Имя поля Assets в модели данных алерта пишется с заглавной буквы A. Строчное assets не существует в модели данных.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 269125 «Модель данных алерта».

5.2.3. Ошибка 3: Неправильный регистр значения поля Type

Неправильно:

alert.Assets[] | select(.type == "host")

Правильно:

alert.Assets[] | select(.Type == "host")

Объяснение: Поле Type в элементе массива Assets пишется с заглавной буквы T. Строчное type не существует.

ℹ️ Источник: Пример из официальной документации ([KL] P003):

[ alert.Assets[] | select(.Type == "host") | .ID]

5.2.4. Ошибка 4: Неправильный регистр значения поля Value

Неправильно:

alert.Observables[] | select(.Type == "sha256") | .value

Правильно:

alert.Observables[] | select(.Type == "sha256") | .Value

Объяснение: Поле Value в элементе массива Observables пишется с заглавной буквы V.

ℹ️ Источник: Пример из официальной документации ([KL] P004):

[alert.ScannedFiles[] | select(any(.DetectionTechnologies[] == "SB"; .)) | .Hashes | map(.Value)] | flatten

5.2.5. Ошибка 5: Неправильный регистр в операционных данных

Неправильно:

.input.Assets[]

Правильно:

.input.assets[]

Объяснение: В операционных данных (.input) имена полей задаются разработчиком плейбука. В примере из документации ([KL] "Playbook for isolating a device where an infected file is detected") используется строчное .input.assets:

((.input.assets // []) | length) > 0

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 324933.

5.3. Таблица правильных написаний полей

5.3.1. Для алертов (alert)

Поле	Правильное написание	Неправильные варианты
Активы	`alert.Assets[]`	alert.assets[], alert.ASSETS[]
Наблюдаемые объекты	`alert.Observables[]`	alert.observables[]
Базовые события	`alert.BaseEvents[]`	alert.baseEvents[]
Исходные события	`alert.OriginalEvents[]`	alert.originalEvents[]
Просканированные файлы	`alert.ScannedFiles[]`	alert.scannedFiles[]
Технологии обнаружения	`alert.DetectionTechnologies[]`	alert.detectionTechnologies[]
Тактики MITRE	`alert.MITRETactics[]`	alert.mitretactics[]
Техники MITRE	`alert.MITRETechniques[]`	alert.mitretechniques[]
Важность	`alert.Severity`	alert.severity
Имя	`alert.Name`	alert.name
Статус	`alert.Status`	alert.status
Источник обнаружения	`alert.DetectSource`	alert.detectSource

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 269125 «Модель данных алерта».

5.3.2. Для инцидентов (incident)

Поле	Правильное написание	Неправильные варианты
Алерты инцидента	`incident.Alerts[]`	incident.alerts[], Incident.Alerts[]
Активы через алерты	`incident.Alerts[].Assets[]`	incident.Alerts[].assets[]
Наблюдаемые через алерты	`incident.Alerts[].Observables[]`	incident.Alerts[].observables[]
Важность инцидента	`incident.Severity`	incident.severity
Приоритет инцидента	`incident.Priority`	incident.priority
Имя инцидента	`incident.Name`	incident.name
Статус инцидента	`incident.Status`	incident.status

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 269168 «Модель данных инцидента».

5.3.3. Для элементов массивов

Поле	Правильное написание	Неправильные варианты
Тип актива	`.Type`	.type, .TYPE
Значение наблюдаемого	`.Value`	.value, .VALUE
ID актива	`.ID`	.id, .Id
Имя актива	`.Name`	.name
Является ли атакующим	`.IsAttacker`	.isAttacker, .isattacker
Является ли жертвой	`.IsVictim`	.isVictim
Дополнительные сведения	`.Details`	.details

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 269125 и 269168.

5.4. Разный регистр в глобальных и операционных данных

5.4.1. Глобальные данные (alert/incident)

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

alert.Assets[]
alert.Observables[]
select(.Type == "host")
.Value

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

5.4.2. Операционные данные (.input)

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

.input.assets[]
.input.observables[]
select(.type == "host")
.value

Пример из документации ([KL] "Playbook for isolating a device where an infected file is detected"):

((.input.assets // []) | length) > 0 and ([.input.observables[] | select(.type == "md5" or .type == "sha256")] | length) > 0

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 324933.

5.4.3. Почему разный регистр?

Глобальные данные — это часть модели данных KUMA, где имена полей стандартизированы и пишутся с заглавных букв (CamelCase).

Операционные данные — это "переменные", которые создаёт разработчик плейбука. В примерах от Лаборатории Касперского используется соглашение: когда в .input сохраняются те же данные, что были в alert.Assets[], разработчики используют строчные буквы для визуального различия.

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

5.5. Практические рекомендации

5.5.1. Используйте подсказки интерфейса

При вводе jq-выражений в Консоли OSMP система автоматически показывает подсказки с правильными именами полей:

Начните вводить alert. → появится список полей с правильным регистром
Начните вводить incident. → появится список полей с правильным регистром
Начните вводить " (кавычку) → появится список допустимых значений для полей

5.5.2. Копируйте примеры из документации

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

Официальной документации (разделы 269125, 269168)
Предустановленных плейбуков [KL] (разделы 271609–324934)
Этой статьи (таблицы 5.3.1–5.3.3)

5.5.3. Проверяйте регистр при возникновении ошибок

Если плейбук не работает или возвращает пустой результат:

Проверьте, что все имена полей написаны с правильным регистром
Сравните с таблицами 5.3.1–5.3.3
Убедитесь, что в глобальных данных используется заглавный регистр, а в операционных — строчный (если следуете соглашению)

5.5.4. Создайте шпаргалку для команды

Распечатайте или сохраните таблицы 5.3.1–5.3.3 как шпаргалку для аналитиков SOC. Это сократит количество ошибок при создании плейбуков.

6. Создание плейбука в интерфейсе

В этом разделе разберём, как создать плейбук в Консоли OSMP: какие роли необходимы, какие шаги нужно выполнить, какие параметры настроить и как сохранить результат.

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков»
Официальная справка Kaspersky EDR Expert 8.1, раздел 264606 «Таблица плейбуков»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков»

6.1. Необходимые роли

Для создания плейбука пользователь должен обладать одной из следующих ролей в Kaspersky EDR Expert:

Роль	Возможность создания
Главный администратор	✅ Да
Администратор тенанта	✅ Да
Администратор SOC	✅ Да
Аналитик SOC	✅ Да
Аналитик 1-го уровня	✅ Да
Аналитик 2-го уровня	✅ Да
Менеджер SOC	❌ Нет
Подтверждающий	❌ Нет
Аудитор	❌ Нет

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков».

💡 Рекомендация: Если в вашей организации действует принцип минимальных привилегий, назначайте роль «Аналитик 1-го уровня» или «Аналитик 2-го уровня» только тем сотрудникам, которые действительно создают плейбуки. Остальным аналитикам достаточно роли «Аудитор» для просмотра.

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

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

Шаг 1. Открытие мастера создания

Войдите в Консоль OSMP под учётной записью с необходимой ролью.
Перейдите в раздел Мониторинг → Плейбуки.
Нажмите кнопку «Создать».

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

┌─────────────────────────────────────────────────────────────┐
│                    МАСТЕР СОЗДАНИЯ ПЛЕЙБУКА                 │
├────────────────────┬────────────────────────────────────────┤
│                    │                                        │
│   НАВИГАЦИЯ        │         РАБОЧАЯ ОБЛАСТЬ                │
│                    │                                        │
│   • Параметры      │   (зависит от выбранного пункта)       │
│   • Триггер        │                                        │
│   • Алгоритм       │                                        │
│                    │                                        │
│                    │                                        │
├────────────────────┴────────────────────────────────────────┤
│          [ Сохранить как черновик ]  [ Опубликовать ]       │
└─────────────────────────────────────────────────────────────┘

Шаг 2. Настройка параметров плейбука

В разделе «Параметры» заполните обязательные поля:

Поле	Описание	Требования
Имя	Название плейбука	Уникально в рамках тенанта
Область действия	Тип объекта	🔘 Алерт / 🔘 Инцидент
Режим работы	Способ запуска	🔘 Автоматический / 🔘 Обучение / 🔘 Ручной
Версия	Версия плейбука	Минимум 1 символ
dslSpecVersion	Версия схемы DSL	Минимум 1 символ
actionsSpecVersion	Версия спецификации действий	Минимум 1 символ

Дополнительные поля:

Описание — текстовое описание плейбука (опционально)
Теги — до 30 тегов для фильтрации (опционально)
playbookRunTimeout — максимальное время выполнения (по умолчанию 24h, максимум 48h)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков».

Шаг 3. Настройка триггера

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

Пример простого триггера для алерта:

.Severity == "critical" and event.new

Пример триггера для инцидента:

[.Alerts[] | .Severity == "critical"] | any and event.new

💡 Подробнее про синтаксис jq — в Разделе 7. Сейчас достаточно понимать, что триггер — это условие, которое возвращает true или false для каждого алерта/инцидента.

Шаг 4. Построение алгоритма

Перейдите в раздел «Алгоритм» и создайте последовательность шагов выполнения. Это можно сделать двумя способами:

Способ 1: Визуальный редактор

Используйте интерфейс drag-and-drop
Добавляйте шаги через кнопку «+»
Настраивайте каждый шаг в правой панели

Способ 2: Ручное написание JSON

Переключитесь в режим редактирования JSON
Введите код алгоритма вручную

Пример простейшего алгоритма:

{
  "version": "1",
  "dslSpecVersion": "1.1.0",
  "actionsSpecVersion": "1",
  "executionFlow": [
    {
      "action": {
        "function": {
          "type": "isolateHost",
          "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}"
        }
      },
      "onError": "stop"
    }
  ]
}

💡 Подробнее про построение алгоритма — в Разделе 8.

Шаг 5. Сохранение

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

Вариант	Описание	Когда использовать
Сохранить как черновик	Плейбук сохраняется, но не активируется	Для продолжения работы позже
Опубликовать	Плейбук активируется и готов к запуску	Когда все настройки завершены

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков».

6.3. Настройка одновременного запуска

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

Когда это актуально

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

Варианты поведения

Поведение	Описание	Когда использовать
Добавить в очередь (по умолчанию)	Новый запуск добавляется в очередь и выполняется после завершения текущего	Для большинства сценариев
Завершить текущий и запустить новый	Текущий запуск прерывается, начинается новый	Когда актуальна только последняя информация
Не запускать новые	Новый запуск не выполняется, продолжается текущий	Когда важно не прерывать текущую работу

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков».

💡 Рекомендация: Для сценариев реагирования на критические угрозы (ransomware, компрометация учётных записей) используйте вариант «Завершить текущий и запустить новый», чтобы обеспечить реакцию на самую актуальную информацию. Для сценариев сбора форензики используйте «Добавить в очередь», чтобы не прерывать уже начатый сбор данных.

6.4. Наследование тенантов

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

Как работает наследование

Настройка	Результат
Наследование включено (по умолчанию)	Плейбук автоматически доступен во всех существующих и будущих дочерних тенантах
Наследование отключено	Плейбук доступен только в том тенанте, где был создан

Когда отключать наследование

Сценарий	Рекомендация
Плейбук использует стандартные действия (`deleteFile`, `isolateHost`)	Оставить наследование
Плейбук использует интеграцию с локальным скриптом	Отключить наследование
Плейбук обращается к специфичному пути в файловой системе	Отключить наследование
Плейбук использует Kaspersky TIP (лицензия только в корневом тенанте)	Отключить наследование

💡 Подробнее про наследование — в Разделе 2.4.

6.5. Статусы плейбуков

После создания плейбук получает один из статусов:

Статус	Описание	Доступные действия
Активный	Плейбук готов к использованию	Запуск, изменение, удаление
Черновик	Плейбук создан, но не активирован	Изменение, публикация, удаление. Запуск невозможен
Удалено	Плейбук удалён	Просмотр, копирование. Изменение и запуск невозможны
Недоступно	Плейбук использует недоступный веб-плагин или действия не по лицензии	Просмотр. Запуск и изменение невозможны

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264606 «Таблица плейбуков».

Переходы между статусами

[Создание] → Черновик → [Публикация] → Активный
                             ↓
                        [Удаление] → Удалено

[Создание] → Черновик → [Удаление] → Удалено

Любой статус → [Потеря лицензии/веб-плагина] → Недоступно

6.6. Таблица плейбуков

После создания плейбук появляется в общей таблице плейбуков (Мониторинг → Плейбуки). Таблица содержит следующие столбцы:

Столбец	Описание
Имя	Название плейбука (кликабельно — открывает детали)
Область действия	Алерт или Инцидент
Режим работы	Автоматический / Обучение / Ручной
Статус	Активный / Черновик / Удалено / Недоступно
Версия	Текущая версия плейбука
Тенант	Тенант, которому принадлежит плейбук
Теги	Теги, назначенные плейбуку
Действия	Кнопки: Изменить, Дублировать, Удалить, Просмотреть историю

Фильтрация и поиск

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

По имени (текстовый поиск)
По области действия (Алерт / Инцидент)
По режиму работы (Автоматический / Обучение / Ручной)
По статусу (Активный / Черновик / Удалено / Недоступно)
По тегам (до 30 тегов)
По тенанту

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264606 «Таблица плейбуков».

7. Настройка триггера

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

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков»
Примеры из предустановленных плейбуков [KL] (разделы 271609–324934)

7.1. Что такое триггер

Согласно официальной документации (раздел 273327):

Ключевые характеристики триггера:

Использует выражения языка jq (реализация gojq на языке Go)
Применяется к каждому алерту или инциденту индивидуально
Возвращает true (запустить плейбук) или false (не запускать)
Настраивается только для плейбуков в режимах «Автоматический» и «Обучение»
Для плейбуков в режиме «Ручной» триггер не настраивается

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.2. Когда срабатывает триггер

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

7.2.1. Создание нового алерта или инцидента

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

7.2.2. Изменение существующего алерта

Триггер проверяется при следующих изменениях алерта:

Событие	Описание
Назначение или удаление аналитика	Изменение ответственного за алерт
Изменение статуса алерта	Переход между статусами (`new`, `inProgress`, `inIncident`, `closed`)
Изменение базовых событий	Добавление или удаление связанных событий
Связывание или удаление связи алерта с инцидентом	Присоединение алерта к инциденту или отвязка
Изменение значения в поле `ExternalReference`	Обновление внешней ссылки

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.2.3. Изменение существующего инцидента

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

Событие	Описание
Назначение или удаление аналитика	Изменение ответственного за инцидент
Изменение статуса инцидента	Переход между статусами
Изменение приоритета инцидента	Обновление приоритета
Объединение инцидентов	Слияние нескольких инцидентов в один
Изменение базовых событий	Добавление или удаление связанных событий

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.2.4. Ручной запуск с опцией «Запустить для всех соответствующих»

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

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.3. Синтаксис jq (gojq)

Триггеры плейбуков используют язык jq в реализации gojq (на языке Go). Реализация gojq совместима со стандартным jq, но имеет некоторые улучшения:

Более точные математические функции
Улучшенная работа с целыми числами

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука». Ссылка на документацию gojq: https://github.com/itchyny/gojq

7.3.1. Базовые конструкции jq

Точка (.) — текущий объект (алерт или инцидент):

Обращение к полю:

.Severity
.Name
.Status

Сравнение значений:

.Severity == "critical"
.Severity != "low"

Логические операторы:

(.Severity == "critical") and (.DetectSource == "KES")
(.Severity == "high") or (.Severity == "critical")
not (.Status == "closed")

Итерация по массиву:

.Assets[]
.Observables[]
.MITRETactics[]

Фильтрация через select:

.Assets[] | select(.Type == "host")
.Observables[] | select(.Type == "sha256")

Обёртка в массив:

[.Assets[] | select(.Type == "host") | .ID]

Проверка наличия подстроки:

jq1.Name | contains("Ransomware")

Проверка соответствия регулярному выражению:

.Name | test("Ransomware.*")

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука». Полное руководство по jq: https://jqlang.org/manual/

7.3.2. Работа с массивами — критически важно

Это самая частая причина ошибок в триггерах. Рассмотрим пример:

Неправильно:

.DetectionTechnologies[] == "SB"

Это выражение вернёт несколько значений true или false (по одному для каждого элемента массива). jq не сможет интерпретировать результат как единое условие.

Правильно (вариант 1):

[.DetectionTechnologies[] | . == "SB"] | any

Разбор:

.DetectionTechnologies[] — взять каждую технологию обнаружения
| . == "SB" — проверить, равна ли она "SB"
[...] — собрать результаты в массив (например, [false, false, true])
| any — вернуть true, если хотя бы один элемент массива true

Правильно (вариант 2, более короткий):

any(.DetectionTechnologies[]; . == "SB")

ℹ️ Источник: Примеры из официальной документации ([KL] P004, P005)

event.new and .Severity == "medium" and any(.DetectionTechnologies[] == "SB"; .)

7.3.3. Проверка наличия элементов в массиве

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

[.Assets[] | select(.Type == "host")] | length > 0

Это выражение возвращает true, если в алерте есть хотя бы один хост.

ℹ️ Источник: Пример из официальной документации ([KL] P001):

[.OriginalEvents[] | .ExternalID == "R350"] | any

7.3.4. Использование переменных

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

.Severity == "critical" as $is_critical |
$is_critical and ([.Assets[] | select(.Type == "host")] | length > 0)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.3.5. Работа с датами

Для работы с датами в jq доступны функции now, todate, fromdate:

now
now | todate
.CreatedAt | split(".")[0] + "Z" | fromdate

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.4. Функция event для отслеживания изменений

Согласно официальной документации (раздел 273327), в триггере доступен специальный объект event, который содержит информацию о том, что именно произошло с алертом или инцидентом.

7.4.1. Структура объекта event

{
  "new": true,
  "manual": true,
  "updateOperations": [
    "alertChangedToNew",
    "alertLinkedWithIncidentBySystem"
  ]
}

Поле	Тип	Описание
`new`	Булево	`true`, если алерт/инцидент только что создан
`manual`	Булево	`true`, если изменение сделано вручную (не системой)
`updateOperations`	Массив строк	Список операций, которые были выполнены

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.4.2. Примеры использования функции event

Пример 1: Срабатывать только для новых алертов

event.new

Это выражение возвращает true только при создании нового алерта/инцидента.

ℹ️ Источник: Пример из официальной документации ([KL] P004):

event.new and .Severity == "medium" and any(.DetectionTechnologies[] == "SB"; .)

Пример 2: Срабатывать только при ручном переоткрытии алерта

event.manual and ([event.updateOperations[] | . == "alertReopened"] | any)

Пример 3: Срабатывать только при автоматическом связывании с инцидентом

[event.updateOperations[] | . == "alertLinkedWithIncidentBySystem"] | any

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.4.3. Список операций updateOperations

Согласно официальной документации, объект event.updateOperations может содержать следующие значения:

Для алертов:

Операция	Описание
`alertChangedToNew`	Изменение статуса на «New»
`alertReopened`	Повторное открытие алерта
`alertLinkedWithIncidentBySystem`	Автоматическое связывание с инцидентом
`alertUnlinkedFromIncident`	Отвязка от инцидента
`alertAssignedToAnalyst`	Назначение аналитика
`alertUnassignedFromAnalyst`	Удаление аналитика

Для инцидентов:

Операция	Описание
`incidentChangedToNew`	Изменение статуса на «New»
`incidentPriorityChanged`	Изменение приоритета
`incidentMerged`	Объединение инцидентов
`incidentAssignedToAnalyst`	Назначение аналитика
`incidentUnassignedFromAnalyst`	Удаление аналитика

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.5. Ограничения: что НЕЛЬЗЯ использовать в триггерах

Согласно официальной документации (раздел 273327), не рекомендуется использовать в триггерах следующие поля из-за их большого объёма, что может привести к деградации производительности:

Поле	Причина ограничения
`OriginalEvents`	Очень большой объём данных (исходные события)
`Observables`	Может содержать тысячи элементов
`Extra`	Дополнительная информация, может быть огромной
`Alerts` (для инцидентов)	Массив алертов может быть очень большим

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

7.5.1. Почему это важно

Триггер проверяется для каждого алерта или инцидента в системе. Если в триггере используются «тяжёлые» поля, система вынуждена загружать и обрабатывать большие объёмы данных для каждого объекта. Это приводит к:

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

7.5.2. Альтернативы

Вместо этого	Используйте
`OriginalEvents`	`BaseEvents` или обогащённые поля
`Observables`	`ScannedFiles` или `DetectionTechnologies`
`Extra`	Основные поля алерта/инцидента
`Alerts` (для инцидентов)	Агрегированные поля инцидента

💡 Рекомендация: Если необходимо использовать «тяжёлое» поле в триггере, тщательно протестируйте производительность на реальных данных перед внедрением в продуктивную среду.

7.6. Примеры триггеров из официальной документации

Разберём реальные триггеры из предустановленных плейбуков [KL].

7.6.1. Триггер плейбука [KL] P001

Область действия: Алерт

Триггер:

[.OriginalEvents[] | .ExternalID == "R350"] | any

Разбор:

.OriginalEvents[] — пройтись по всем исходным событиям алерта
| .ExternalID == "R350" — проверить, соответствует ли событие правилу корреляции R350
[...] | any — вернуть true, если хотя бы одно событие соответствует

Назначение: Срабатывает для алертов, созданных правилом корреляции R350 «Creation of executable files by office applications».

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P001».

7.6.2. Триггер плейбука [KL] P002

Область действия: Инцидент

Триггер:

[.Alerts[] | .OriginalEvents[] | .ExternalID == "R050"] | any

Разбор:

.Alerts[] — пройтись по всем алертам инцидента
| .OriginalEvents[] — пройтись по всем исходным событиям каждого алерта
| .ExternalID == "R050" — проверить, соответствует ли событие правилу корреляции R050
[...] | any — вернуть true, если хотя бы одно событие в любом алерте соответствует

Назначение: Срабатывает для инцидентов, содержащих алерты от правила корреляции R050 «Windows Event Log was cleared».

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P002».

7.6.3. Триггер плейбука [KL] P003

Область действия: Алерт

Триггер:

[.OriginalEvents[] | .ExternalID == "R297"] | any

Разбор: Аналогично P001, но для правила корреляции R297 «Suspicious child process from wmiprvse.exe».

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

7.6.4. Триггер плейбука [KL] P004

Область действия: Алерт

Триггер:

event.new and .Severity == "medium" and any(.DetectionTechnologies[] == "SB"; .)

Разбор:

event.new — только для новых алертов
.Severity == "medium" — важность «medium»
any(.DetectionTechnologies[] == "SB"; .) — хотя бы одна технология обнаружения — Sandbox

Назначение: Срабатывает для новых алертов с важностью «medium», обнаруженных через Sandbox.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

7.6.5. Триггер плейбука [KL] P005

Область действия: Алерт

Триггер:

event.new and .Severity == "high" and any(.DetectionTechnologies[] == "SB"; .)

Разбор: Аналогично P004, но для важности «high».

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] P005».

7.6.6. Триггер плейбука [KL] "Playbook for checking external IP addresses"

Область действия: Инцидент

Триггер:

event.new and ([ .Alerts[] | .Observables[] | select(.Value | test("^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)") | not) | .Value ] | length > 0)

Разбор:

event.new — только для новых инцидентов
.Alerts[] — пройтись по всем алертам инцидента
.Observables[] — пройтись по всем наблюдаемым объектам
select(.Value | test("^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)") | not) — оставить только те, значение которых НЕ соответствует приватным IP-диапазонам
[...] | length > 0 — вернуть true, если есть хотя бы один внешний IP

Назначение: Срабатывает для новых инцидентов, содержащих хотя бы один внешний IP-адрес.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318590 «[KL] Playbook for checking external IP addresses».

7.7. Проверка триггера через кнопку «Найти»

Согласно официальной документации (раздел 249267), в интерфейсе создания плейбука доступна кнопка «Найти», которая позволяет проверить корректность триггера.

Как работает кнопка «Найти»

Введите jq-выражение в поле триггера.
Нажмите кнопку «Найти».
Система применит выражение ко всем существующим алертам/инцидентам (в зависимости от выбранной области действия).
Отобразится список алертов/инцидентов, для которых триггер возвращает true.

Что это даёт

Проверка синтаксиса jq-выражения
Проверка логики триггера (возвращает ли он ожидаемые объекты)
Оценка объёма объектов, на которые сработает триггер
Выявление ошибок до публикации плейбука

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков».

💡 Рекомендация: Всегда используйте кнопку «Найти» перед публикацией плейбука. Это позволяет убедиться, что триггер срабатывает на ожидаемые объекты и не захватывает лишние.

7.8. Практические рекомендации

7.8.1. Начинайте с простых триггеров

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

Шаг 1: Простая проверка важности

.Severity == "critical"

Шаг 2: Добавление проверки источника

.Severity == "critical" and .DetectSource == "KES"

Шаг 3: Добавление проверки технологий обнаружения

.Severity == "critical" and .DetectSource == "KES" and any(.DetectionTechnologies[] == "SB"; .)

Шаг 4: Добавление проверки через event

event.new and .Severity == "critical" and .DetectSource == "KES" and any(.DetectionTechnologies[] == "SB"; .)

7.8.2. Всегда используйте `event.new` для автоматических плейбуков

Если плейбук должен срабатывать только при создании нового алерта/инцидента, добавьте event.new в триггер. Это предотвратит повторные срабатывания при изменении алерта/инцидента.

7.8.3. Оборачивайте итераторы в `[...] | any`

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

7.8.4. Избегайте «тяжёлых» полей

Не используйте OriginalEvents, Observables, Extra, Alerts в триггерах без крайней необходимости. Если они необходимы, тщательно тестируйте производительность.

7.8.5. Проверяйте синтаксис через кнопку «Найти»

Перед публикацией плейбука всегда проверяйте триггер через кнопку «Найти». Это позволяет выявить ошибки синтаксиса и логики до запуска в продуктивной среде.

7.8.6. Используйте подсказки интерфейса

При вводе jq-выражений в Консоли OSMP система автоматически показывает подсказки:

Начните вводить . → появится список доступных полей
Начните вводить " (кавычку) → появится список допустимых значений

8. Построение алгоритма (executionFlow)

В этом разделе разберём, как построить алгоритм плейбука: из чего состоит JSON-документ, какие типы шагов выполнения существуют, как извлекать данные, обрабатывать ошибки и настраивать таймауты.

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука»
Официальная справка Kaspersky EDR Expert 8.1, разделы 270351–270357 (описания типов шагов)
Примеры из предустановленных плейбуков [KL] (разделы 271609–324934)

8.1. Структура JSON алгоритма

Согласно официальной документации (раздел 267548), алгоритм плейбука описывается в формате JSON и состоит из двух основных частей:

8.1.1. Общая информация о плейбуке

{
  "version": "1",
  "dslSpecVersion": "1.1.0",
  "actionsSpecVersion": "1",
  "playbookRunTimeout": "24h",
  "executionFlow": [
    /* шаги выполнения */
  ]
}

Обязательные поля:

Поле	Тип	Описание	Требования
`version`	Строка	Версия плейбука	Минимальная длина — 1 символ
`dslSpecVersion`	Строка	Версия схемы DSL	Минимальная длина — 1 символ
`actionsSpecVersion`	Строка	Версия спецификации действий	Минимальная длина — 1 символ
`executionFlow`	Массив	Шаги выполнения	Минимум один шаг

Опциональные поля:

Поле	Тип	Описание	Значение по умолчанию
`playbookRunTimeout`	Строка	Максимальное время выполнения плейбука	`24h`
`input`	Строка	jq-выражение для преобразования входящих данных	Пусто
`output`	Строка	jq-выражение для изменения вывода плейбука	Пусто
`timeouts`	Объект	Политики тайм-аута для шагов	Пусто

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

8.1.2. Массив executionFlow

Массив executionFlow содержит шаги, которые выполняются в порядке, указанном в массиве. Каждый шаг — это объект с определённой структурой в зависимости от типа шага.

Типы шагов выполнения:

Тип шага	Ключевое поле	Назначение
Действие (ResponseFunction)	`action`	Выполнение действия по реагированию
Цикл (Loop)	`loop`	Повторение набора шагов для каждого элемента массива
Параллель (Parallel)	`parallel`	Параллельное выполнение нескольких веток шагов
Ветвление (Decision)	`decision`	Условное выполнение шагов
Обновление данных (UpdateData)	`updateData`	Сохранение промежуточных данных

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 270351–270357.

8.2. Шаг 1: Action (Действие)

Согласно официальной документации (раздел 270357), шаг типа «Действие» выполняет конкретное действие по реагированию.

8.2.1. Структура шага Action

{
  "action": {
    "function": {
      "type": "deleteFile",
      "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}",
      "params": {
        "path": "${alert.Observables[] | select(.Type == \"filepath\") | .Value}"
      }
    }
  },
  "onError": "stop",
  "timeout": {
    "scheduleToCloseTimeout": "24h"
  },
  "output": {
    "action": "merge",
    "filter": "${.}"
  },
  "manualApprove": {
    "timeout": "60m",
    "emailNotifications": {
      "enabled": true,
      "delay": "10m"
    }
  }
}

8.2.2. Обязательные параметры

Параметр	Тип	Описание
`type`	Строка	Тип действия (например, `deleteFile`, `isolateHost`, `blockLDAPAccount`)
`assets`	Строка (jq-выражение)	jq-выражение, возвращающее массив ID активов

8.2.3. Опциональные параметры

Параметр	Тип	Описание
`params`	Объект	Дополнительные параметры действия (зависят от типа действия)
`onError`	Строка	Обработка ошибок: `stop` (прервать) или `continue` (пропустить)
`timeout`	Объект	Таймаут выполнения действия
`output`	Объект	Изменение выходных данных через jq-выражение
`manualApprove`	Объект/Булево	Настройка ручного подтверждения

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 270357 «Действие».

8.2.4. Пример из документации: [KL] P003

Из предустановленного плейбука [KL] P003 "Suspicious child process from wmiprvse.exe":

{
  "action": {
    "function": {
      "type": "blockLDAPAccount",
      "assets": "${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"
    }
  },
  "onError": "stop"
}

Разбор:

type: "blockLDAPAccount" — действие блокировки учётной записи в Active Directory
assets — jq-выражение извлекает ID пользователей-атакующих из алерта:
- alert.Assets[] — пройтись по всем активам алерта
- select(.Type == "user" and .IsAttacker) — оставить только пользователей-атакующих
- .ID — извлечь ID каждого пользователя
onError: "stop" — при ошибке прервать выполнение плейбука

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

8.2.5. Пример из документации: [KL] P004

Из предустановленного плейбука [KL] P004 "Sandbox Medium Detect":

{
  "loop": {
    "input": "${[alert.OriginalEvents[] | .DestinationProcessName]}",
    "batchSize": 1,
    "mode": "parallel",
    "onError": "stop",
    "aggregate": "${.}",
    "output": {
      "action": "merge",
      "filter": "${.}"
    },
    "steps": [
      {
        "action": {
          "function": {
            "type": "killProcess",
            "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}",
            "params": {
              "path": "${.[0]}"
            }
          }
        }
      }
    ]
  }
}

Разбор:

type: "addFilePreventionRules" — создание правила запрета на запуск файла
assets: ["selector": "execution-tenant"] — специальный селектор, применяющий правило ко всему тенанту (не jq-выражение!)
params.files — jq-выражение извлекает хеши файлов, обнаруженных через Sandbox:
- alert.ScannedFiles[] — пройтись по всем просканированным файлам
- select(any(.DetectionTechnologies[] == "SB"; .)) — оставить только файлы, обнаруженные через Sandbox
- .Hashes | map(.Value) — извлечь значения хешей
- | flatten — преобразовать в плоский массив
params.notify: true — отправить уведомление о создании правила

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

8.3. Шаг 2: Loop (Цикл)

Согласно официальной документации (раздел 270351), шаг типа «Цикл» повторяет набор шагов для каждого элемента массива.

8.3.1. Структура шага Loop

{
  "loop": {
    "input": "${[alert.OriginalEvents[] | .DestinationProcessName]}",
    "batchSize": 1,
    "mode": "parallel",
    "onError": "stop",
    "aggregate": "${.}",
    "output": {
      "action": "merge",
      "filter": "${.}"
    },
    "steps": [
      {
        "action": {
          "function": {
            "type": "killProcess",
            "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}",
            "params": {
              "path": "${.[0]}"
            }
          }
        }
      }
    ]
  }
}

8.3.2. Обязательные параметры

Параметр	Тип	Описание
`input`	Строка (jq-выражение)	jq-выражение, возвращающее массив для итерации
`steps`	Массив	Шаги, выполняемые для каждого элемента

8.3.3. Опциональные параметры

Параметр	Тип	Описание	Значение по умолчанию
`batchSize`	Число	Количество элементов за одну итерацию	`1`
`mode`	Строка	Режим выполнения: `sequential` или `parallel`	`sequential`
`onError`	Строка	Обработка ошибок: `stop` или `continue`	`stop`
`aggregate`	Строка (jq-выражение)	jq-выражение для агрегирования результатов	`${.}`
`output`	Объект	Изменение выходных данных	Пусто

8.3.4. Доступ к текущему элементу

Внутри шагов цикла текущий элемент (или группа элементов, если batchSize > 1) доступен через:

.[0] — первый элемент
.[1] — второй элемент
и т.д.

8.3.5. Пример из документации: [KL] P003

Из предустановленного плейбука [KL] P003:

{
  "loop": {
    "batchSize": 1,
    "input": "${ [alert.OriginalEvents[] | [select(.DestinationProcessName != null and .DestinationProcessName != \"\")][] | .DestinationProcessName] }",
    "mode": "parallel",
    "onError": "stop",
    "steps": [
      {
        "action": {
          "function": {
            "type": "killProcess",
            "assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}",
            "params": {
              "path": "${ .[0] }"
            }
          }
        }
      }
    ]
  }
}

Разбор:

input — jq-выражение извлекает имена процессов из исходных событий:
- alert.OriginalEvents[] — пройтись по всем исходным событиям
- select(.DestinationProcessName != null and .DestinationProcessName != "") — оставить только события с непустым именем процесса
- .DestinationProcessName — извлечь имя процесса
batchSize: 1 — обрабатывать по одному процессу за итерацию
mode: "parallel" — выполнять итерации параллельно
.[0] — внутри шага текущий элемент (имя процесса) доступен через .[0]
assets — применить действие ко всем хостам из алерта

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

8.4. Шаг 3: Parallel (Параллель)

Согласно официальной документации (раздел 270352), шаг типа «Параллель» выполняет несколько веток шагов одновременно с одними и теми же входными данными.

8.4.1. Структура шага Parallel

{
  "parallel": {
    "input": "${[incident.Alerts[].Assets[] | select(.Type == \"host\") | .ID]}",
    "aggregate": "${.}",
    "output": {
      "action": "merge",
      "filter": "${.}"
    },
    "onError": "continue",
    "branches": [
      {
        "name": "isolate_hosts",
        "steps": [
          {
            "action": {
              "function": {
                "type": "isolateHost",
                "assets": "${.}"
              }
            }
          }
        ]
      },
      {
        "name": "collect_forensics",
        "steps": [
          {
            "action": {
              "function": {
                "type": "getForensics",
                "assets": "${.}"
              }
            }
          }
        ]
      }
    ]
  }
}

8.4.2. Обязательные параметры

Параметр	Тип	Описание
`branches`	Массив	Ветки выполнения (каждая ветка — объект с `name` и `steps`)
`aggregate`	Строка (jq-выражение)	jq-выражение для агрегирования результатов

8.4.3. Опциональные параметры

Параметр	Тип	Описание
`input`	Строка (jq-выражение)	jq-выражение для входных данных
`output`	Объект	Как применить выходные данные: `merge` или `overwrite`
`onError`	Строка	`stop` (завершить все ветки) или `continue` (остановить только сбойную)

8.4.4. Структура ветки

{
  "name": "имя_ветки",
  "steps": [ /* массив шагов */ ]
}

8.4.5. Отличие от Loop

Характеристика	Loop	Parallel
Входные данные	Разные элементы массива	Одни и те же данные
Выполнение	Последовательное или параллельное	Всегда параллельное
Назначение	Обработать каждый элемент	Выполнить разные действия с одними данными

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 270352 «Параллель».

8.5. Шаг 4: Decision (Ветвление)

Согласно официальной документации (раздел 270354), шаг типа «Ветвление» выполняет шаги условно, в зависимости от jq-выражений.

8.5.1. Структура шага Decision

{
  "decision": {
    "conditions": [
      {
        "condition": "${incident.Severity == \"Critical\"}",
        "name": "Critical severity",
        "steps": [
          {
            "action": {
              "function": {
                "type": "isolateHost",
                "assets": "${[incident.Alerts[].Assets[] | select(.Type == \"host\") | .ID]}"
              }
            }
          }
        ]
      },
      {
        "condition": "${incident.Severity == \"High\"}",
        "name": "High severity",
        "steps": [
          {
            "action": {
              "function": {
                "type": "addComment",
                "params": {
                  "comment": "High severity incident detected"
                }
              }
            }
          }
        ]
      },
      {
        "condition": "${true}",
        "name": "Default case",
        "steps": [
          {
            "action": {
              "function": {
                "type": "addComment",
                "params": {
                  "comment": "Low or medium severity"
                }
              }
            }
          }
        ]
      }
    ]
  }
}

8.5.2. Обязательные параметры

Параметр	Тип	Описание
`conditions`	Массив	Условия выполнения

8.5.3. Структура условия

{
  "condition": "${jq-выражение}",
  "name": "название_условия",
  "steps": [ /* массив шагов */ ]
}

8.5.4. Особенности

Выполняется только первое сработавшее условие (как if-else if-else)
Условие ${true} используется как "else" (случай по умолчанию)
Можно вкладывать decision внутрь decision

8.5.5. Пример из документации: [KL] "Playbook for checking external IP addresses"

Из предустановленного плейбука [KL] "Playbook for checking external IP addresses":

{
  "decision": {
    "conditions": [
      {
        "condition": "${[.details.observableData[] | select(.status == \"ok\" and .ipObservableData.ipGeneralInfo.threatScore > 80)] | length > 0}",
        "name": "Condition 1",
        "steps": [
          {
            "decision": {
              "conditions": [
                {
                  "condition": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | length > 0}",
                  "name": "alert has host(s)",
                  "steps": [
                    {
                      "action": {
                        "function": {
                          "type": "getForensics",
                          "assets": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | map(.ID)}",
                          "params": {
                            "processes": {"collect": true},
                            "autoruns": {"collect": false}
                          }
                        }
                      }
                    },
                    {
                      "action": {
                        "function": {
                          "type": "netIsolateOn",
                          "assets": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | map(.ID)}"
                        }
                      }
                    }
                  ]
                }
              ]
            }
          }
        ]
      }
    ]
  }
}

Разбор:

Внешнее условие проверяет, есть ли наблюдаемые объекты с threatScore > 80
Если да — выполняется вложенное decision, которое проверяет наличие хостов
Если хосты есть — выполняется сбор форензики и изоляция

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] Playbook for checking external IP addresses».

8.6. Шаг 5: UpdateData (Обновление данных)

Согласно официальной документации (раздел 270355), шаг типа «Обновление данных» сохраняет промежуточные данные в операционные данные (.input).

8.6.1. Способ 1: jq-скрипт

{
  "updateData": "${.input | .hashes = [incident.Alerts[].Observables[] | select(.Type == \"sha256\") | .Value]}"
}

8.6.2. Способ 2: Объект Output

{
  "updateData": {
    "action": "merge",
    "filter": "${[incident.Alerts[].Observables[] | select(.Type == \"sha256\") | .Value]}",
    "key": "hashes"
  }
}

8.6.3. Параметры (Способ 2)

Параметр	Тип	Описание
`action`	Строка	`merge` (объединить) или `overwrite` (перезаписать)
`filter`	Строка (jq-выражение)	jq-выражение для извлечения данных
`key`	Строка	Имя поля в `.input` (опционально)

8.6.4. Пример из документации

Из плейбука, который мы разбирали ранее:

{
  "updateData": {
    "action": "merge",
    "filter": "${{
      \"filePath\": ([incident.Alerts[] | .Observables[]? | select(.Type == \"fileFullName\" and (.Value | contains(\"update.exe\"))) | .Value][0] // \"\"),
      \"hashes\": ([incident.Alerts[] | .Observables[]? | select((.Type == \"md5\" or .Type == \"sha256\") and .Details != null and .Details != \"\" and (.Details | contains(\"update.exe\"))) | .Value] | unique),
      \"assets\": ([incident.Alerts[] | .Assets[]? | select(.Type == \"host\") | .ID] | unique)
    }}"
  }
}

Разбор:

Сохраняет три поля в операционные данные: filePath, hashes, assets
Каждое поле извлекается через jq-выражение из инцидента
Дальше эти данные можно использовать как .input.filePath, .input.hashes, .input.assets

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 270355 «Обновление данных».

8.7. Обработка ошибок

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

8.7.1. Значения onError

Значение	Поведение
`stop`	Прервать выполнение плейбука
`continue`	Пропустить шаг и продолжить выполнение

8.7.2. Когда использовать stop

Используйте onError: "stop" для критичных действий, без которых дальнейшее выполнение плейбука не имеет смысла:

Блокировка учётной записи атакующего
Создание правила запрета
Изоляция хоста

8.7.3. Когда использовать continue

Используйте onError: "continue" для некритичных действий, которые можно пропустить:

Удаление файла (если файл уже удалён)
Сбор форензики (если не удалось собрать)
Добавление комментария

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

8.8. Таймауты

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

8.8.1. Таймаут плейбука

{
  "playbookRunTimeout": "24h"
}

Значения:

По умолчанию: 24h
Максимум: 48h
Формат: число + единица измерения (h — часы, m — минуты, s — секунды)

8.8.2. Таймаут шага

{
  "action": {
    "function": {
      "type": "getForensics"
    }
  },
  "timeout": {
    "scheduleToCloseTimeout": "24h"
  }
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

8.9. Практические рекомендации

8.9.1. Начинайте с простых алгоритмов

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

8.9.2. Используйте updateData для сложных вычислений

Если одно и то же jq-выражение используется несколько раз, вычислите его один раз и сохраните в .input:

{
  "updateData": {
    "action": "merge",
    "filter": "${{
      \"hostIds\": [incident.Alerts[].Assets[] | select(.Type == \"host\") | .ID]
    }}"
  }
}

Дальше используйте ${.input.hostIds} вместо повторного вычисления.

8.9.3. Настраивайте playbookRunTimeout

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

{
  "playbookRunTimeout": "48h"
}

8.9.4. Тестируйте в режиме «Обучение»

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

8.9.5. Проверяйте jq-выражения

Используйте кнопку «Найти» в триггере и тестируйте jq-выражения в алгоритме перед публикацией.

9. Действия по реагированию

В этом разделе разберём, какие действия доступны в плейбуках Kaspersky EDR Expert, как их классифицировать, как правильно извлекать активы и параметры для действий, и как применять глобальные правила.

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 314454 «Действия по реагированию, доступные в плейбуках»
Официальная справка Kaspersky EDR Expert 8.1, раздел 264315 «Действия по реагированию KATA/KEDR»
Официальная справка Kaspersky EDR Expert 8.1, раздел 261323 «Действия по реагированию через Active Directory»
Официальная справка Kaspersky EDR Expert 8.1, раздел 265935 «Назначение курса обучения KASAP»
Официальная справка Kaspersky EDR Expert 8.1, раздел 265824 «Выполнение скриптов»
Официальная справка Kaspersky EDR Expert 8.1, раздел 264288 «Обогащение данных через Kaspersky TIP»
Примеры из предустановленных плейбуков [KL] (разделы 271609–324934)

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

Согласно официальной документации (раздел 314454), в Kaspersky EDR Expert 8.1 доступно 19 действий по реагированию, которые можно использовать в плейбуках.

9.1.1. Сводная таблица действий

№	Действие	Тип	Назначение
1	`getFile`	KATA/KEDR	Получить файл с хоста
2	`getForensics`	KATA/KEDR	Собрать форензику (дампы, ключи реестра, процессы)
3	`getRegistryKey`	KATA/KEDR	Получить ключ реестра Windows
4	`getNTFSMetaFiles`	KATA/KEDR	Получить метафайлы NTFS
5	`getProcessMemoryDump`	KATA/KEDR	Получить дамп памяти процесса
6	`getDiskImage`	KATA/KEDR	Получить образ диска
7	`getMemoryDump`	KATA/KEDR	Получить дамп памяти
8	`killProcess`	KATA/KEDR	Завершить процесс
9	`deleteFile`	KATA/KEDR	Удалить файл
10	`quarantineFile`	KATA/KEDR	Поместить файл на карантин
11	`deleteQuarantinedFile`	KATA/KEDR	Удалить файл из карантина
12	`restoreQuarantinedFile`	KATA/KEDR	Восстановить файл из карантина
13	`isolateHost`	KATA/KEDR	Изолировать хост (сетевая изоляция)
14	`runYaraScan`	KATA/KEDR	Запустить YARA-проверку
15	`runIOCScan`	KATA/KEDR	Запустить IOC-проверку
16	`manageServices`	KATA/KEDR	Управлять службами Windows
17	`executeApplication`	KATA/KEDR	Выполнить приложение
18	`addFilePreventionRules`	KATA/KEDR	Создать правило запрета на запуск файла
19	`deleteFilePreventionRules`	KATA/KEDR	Удалить правило запрета
20	`blockLDAPAccount`	Active Directory	Блокировать учётную запись
21	`unblockLDAPAccount`	Active Directory	Разблокировать учётную запись
22	`resetLDAPPassword`	Active Directory	Сбросить пароль учётной записи
23	`assignKasapGroup`	KASAP	Назначить курс обучения
24	`updateBases`	Обновление баз	Обновить антивирусные базы
25	`executeCustomScript`	Выполнение скриптов	Выполнить пользовательский скрипт
26	`iocsEnrichment`	Обогащение данных	Обогатить данные через Kaspersky TIP
27	`moveDeviceToGroup`	Управление объектами	Переместить устройство в другую группу администрирования

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 314454 «Действия по реагированию, доступные в плейбуках».

9.2. Классификация действий по группам

9.2.1. Действия KATA/KEDR (19 действий)

Действия для работы с файлами, процессами, хостами и сбора форензики. Требуют наличия агента Kaspersky Endpoint Security (KES) или Kaspersky Anti Targeted Attack (KATA) на целевом хосте.

Подкатегории:

Сбор данных и форензика (7 действий):

getFile — получить файл с хоста
getForensics — собрать форензику (дампы памяти, образы дисков, ключи реестра, список процессов)
getRegistryKey — получить значение ключа реестра Windows
getNTFSMetaFiles — получить метафайлы NTFS ($MFT, $LogFile и т.д.)
getProcessMemoryDump — получить дамп памяти конкретного процесса
getDiskImage — получить образ диска
getMemoryDump — получить полный дамп оперативной памяти

Работа с файлами (4 действия):

deleteFile — удалить файл с хоста
quarantineFile — поместить файл на карантин
deleteQuarantinedFile — удалить файл из карантина
restoreQuarantinedFile — восстановить файл из карантина

Работа с процессами (1 действие):

killProcess — завершить процесс по пути или PID

Изоляция хоста (1 действие):

isolateHost — включить сетевую изоляцию хоста

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

runYaraScan — запустить проверку по YARA-правилам
runIOCScan — запустить проверку по IOC (Indicators of Compromise)

Управление службами (1 действие):

manageServices — запустить/остановить/перезапустить службу Windows

Выполнение приложений (1 действие):

executeApplication — выполнить приложение на хосте

Правила запрета (2 действия):

addFilePreventionRules — создать правило запрета на запуск файла по хешу
deleteFilePreventionRules — удалить правило запрета

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264315 «Действия по реагированию KATA/KEDR».

9.2.2. Действия Active Directory (3 действия)

Действия для управления учётными записями в Active Directory. Требуют настроенной интеграции с Active Directory.

blockLDAPAccount — блокировать учётную запись пользователя
unblockLDAPAccount — разблокировать учётную запись
resetLDAPPassword — сбросить пароль учётной записи

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 261323 «Действия по реагированию через Active Directory».

9.2.3. Действие KASAP (1 действие)

Действие для назначения курсов обучения через Kaspersky Automated Security Awareness Platform (KASAP).

assignKasapGroup — назначить пользователю курс обучения по информационной безопасности

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 265935 «Назначение курса обучения KASAP».

9.2.4. Действие обновления баз (1 действие)

updateBases — инициировать обновление антивирусных баз на хосте

9.2.5. Действие выполнения скриптов (1 действие)

executeCustomScript — выполнить пользовательский скрипт (PowerShell, Bash, Python и т.д.) на хосте

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 265824 «Выполнение скриптов».

9.2.6. Действие обогащения данных (1 действие)

iocsEnrichment — отправить наблюдаемые объекты (IP, хеши, домены, URL) в Kaspersky Threat Intelligence Portal для получения дополнительной информации

Требования:

Настроена интеграция с Kaspersky TIP или Kaspersky OpenTIP
Лицензия на использование TIP

Поддерживаемые типы наблюдаемых объектов:

domain
url
ip
md5
sha256

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264288 «Обогащение данных через Kaspersky TIP».

9.2.7. Действие управления объектами (1 действие)

moveDeviceToGroup — переместить устройство в другую группу администрирования

9.3. Как извлекать активы для действий

Большинство действий требуют параметр assets — jq-выражение, возвращающее массив ID активов, к которым применяется действие.

9.3.1. Извлечение ID хостов

Для плейбука с областью «Алерт»:

[alert.Assets[] | select(.Type == "host") | .ID]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Assets[] | select(.Type == "host") | .ID]

Пример из документации ([KL] P003):

{
  "action": {
    "function": {
      "type": "killProcess",
      "assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}"
    }
  }
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

9.3.2. Извлечение ID пользователей

Для плейбука с областью «Алерт»:

[alert.Assets[] | select(.Type == "user") | .ID]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Assets[] | select(.Type == "user") | .ID]

Пример из документации ([KL] P001):

{
  "action": {
    "function": {
      "type": "resetLDAPPassword",
      "assets": "${[ alert.Assets[] | select(.Type == \"user\") | .ID]}"
    }
  }
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P001».

9.3.3. Извлечение ID пользователей-атакующих

Для плейбука с областью «Алерт»:

[alert.Assets[] | select(.Type == "user" and .IsAttacker) | .ID]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Assets[] | select(.Type == "user" and .IsAttacker) | .ID]

Пример из документации ([KL] P003):

{
  "action": {
    "function": {
      "type": "blockLDAPAccount",
      "assets": "${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"
    }
  }
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

9.3.4. Извлечение ID пользователей-жертв

Для плейбука с областью «Алерт»:

[alert.Assets[] | select(.Type == "user" and .IsVictim) | .ID]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Assets[] | select(.Type == "user" and .IsVictim) | .ID]

ℹ️ Источник: Пример из официальной документации ([KL] P001).

9.4. Как извлекать параметры для действий

9.4.1. Извлечение хешей файлов

Извлечение хешей SHA256:

Для плейбука с областью «Алерт»:

[alert.Observables[] | select(.Type == "sha256") | .Value]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Observables[] | select(.Type == "sha256") | .Value]

Пример из документации ([KL] P004):

{
  "action": {
    "function": {
      "type": "addFilePreventionRules",
      "assets": ["selector": "execution-tenant"],
      "params": {
        "files": "${[alert.ScannedFiles[] | select(any(.DetectionTechnologies[] == \"SB\"; .)) | .Hashes | map(.Value)] | flatten}"
      }
    }
  }
}

Разбор:

alert.ScannedFiles[] — пройтись по всем просканированным файлам
select(any(.DetectionTechnologies[] == "SB"; .)) — оставить только файлы, обнаруженные через Sandbox
.Hashes | map(.Value) — извлечь значения хешей
| flatten — преобразовать в плоский массив

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

9.4.2. Извлечение путей к файлам

Для плейбука с областью «Алерт»:

[alert.Observables[] | select(.Type == "fileFullName") | .Value]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Observables[] | select(.Type == "fileFullName") | .Value]

Пример из плейбука, который мы разбирали ранее:

([incident.Alerts[] | .Observables[]? | select(.Type == "fileFullName" and (.Value | contains("update.exe"))) | .Value][0] // "")

Разбор:

Извлекает путь к файлу с именем update.exe
[0] — берёт первый элемент (если файлов несколько)
// "" — возвращает пустую строку, если ничего не найдено

9.4.3. Извлечение IP-адресов

Для плейбука с областью «Алерт»:

[alert.Observables[] | select(.Type == "ip") | .Value]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].Observables[] | select(.Type == "ip") | .Value]

Пример из документации ([KL] "Playbook for checking external IP addresses"):

[incident.Alerts[] | .Observables[] | {"type": .Type, "value": .Value} | select(.type == "ip" and (.value | test("^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)") | not))]

Разбор:

Извлекает все IP-адреса из наблюдаемых объектов инцидента
Фильтрует только внешние IP (исключает приватные диапазоны через регулярное выражение)
Приватные диапазоны: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] Playbook for checking external IP addresses».

9.4.4. Извлечение имён процессов

Для плейбука с областью «Алерт»:

[alert.OriginalEvents[] | .DestinationProcessName]

Для плейбука с областью «Инцидент»:

[incident.Alerts[].OriginalEvents[] | .DestinationProcessName]

Пример из документации ([KL] P003):

[alert.OriginalEvents[] | [select(.DestinationProcessName != null and .DestinationProcessName != "")][] | .DestinationProcessName]

Разбор:

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

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

9.5. Глобальные правила (selector: execution-tenant)

Некоторые действия (например, addFilePreventionRules) могут применяться не к конкретным хостам, а ко всему тенанту. Для этого используется специальный селектор.

9.5.1. Как использовать selector

Вместо jq-выражения в параметре assets указывается объект с селектором:

{
  "assets": {
    "selector": "execution-tenant"
  }
}

9.5.2. Когда использовать

Используйте selector: execution-tenant, когда нужно применить правило ко всем хостам в тенанте, а не к конкретным активам из алерта/инцидента.

Типичные сценарии:

Создание правила запрета на запуск файла по хешу (чтобы файл не запустился ни на одном хосте)
Применение YARA-правил ко всем хостам
Глобальная блокировка IOC

9.5.3. Пример из документации ([KL] P004)

{
  "action": {
    "function": {
      "type": "addFilePreventionRules",
      "assets": {
        "selector": "execution-tenant"
      },
      "params": {
        "files": "${[alert.ScannedFiles[] | select(any(.DetectionTechnologies[] == \"SB\"; .)) | .Hashes | map(.Value)] | flatten}",
        "notify": true
      }
    }
  }
}

Разбор:

assets: {"selector": "execution-tenant"} — применить правило ко всему тенанту
params.files — массив хешей для блокировки
params.notify: true — отправить уведомление о создании правила

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

9.6. Разбор 5 самых частых действий

9.6.1. deleteFile — Удаление файла

Назначение: Удаление вредоносного файла с хоста.

Параметры:

assets — массив ID хостов
params.path — путь к файлу для удаления

Пример:

{
  "action": {
    "function": {
      "type": "deleteFile",
      "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}",
      "params": {
        "path": "${alert.Observables[] | select(.Type == \"filepath\") | .Value}"
      }
    }
  },
  "onError": "continue"
}

Особенности:

Требует наличия агента KES на хосте
Файл удаляется безвозвратно
Рекомендуется onError: "continue", чтобы не прерывать плейбук, если файл уже удалён

9.6.2. isolateHost — Изоляция хоста

Назначение: Включение сетевой изоляции хоста (блокировка всех сетевых соединений, кроме связи с сервером управления).

Параметры:

assets — массив ID хостов
params.exclusions — список исключений (IP-адреса, с которыми разрешена связь)
params.exclusionsConflictBehavior — поведение при конфликте: replace или merge
params.isolationTimeoutSec — таймаут изоляции в секундах

Пример из документации ([KL] "Playbook for checking external IP addresses"):

{
  "action": {
    "function": {
      "type": "netIsolateOn",
      "assets": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | map(.ID)}",
      "params": {
        "exclusions": [],
        "exclusionsConflictBehavior": "replace",
        "isolationTimeoutSec": 28800
      }
    }
  },
  "manualApprove": {
    "timeout": "60m",
    "emailNotifications": {
      "enabled": true,
      "delay": "10m"
    }
  }
}

Разбор:

isolationTimeoutSec: 28800 — изоляция на 8 часов (28800 секунд)
manualApprove — требуется ручное подтверждение аналитика
emailNotifications — отправить email-уведомление с задержкой 10 минут

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] Playbook for checking external IP addresses».

9.6.3. addFilePreventionRules — Создание правила запрета

Назначение: Создание правила, запрещающего запуск файлов с указанными хешами.

Параметры:

assets — массив ID хостов или {"selector": "execution-tenant"} для применения ко всему тенанту
params.files — массив хешей (MD5 или SHA256)
params.notify — отправлять ли уведомление (true/false)

Пример из документации ([KL] P004):

{
  "action": {
    "function": {
      "type": "addFilePreventionRules",
      "assets": {
        "selector": "execution-tenant"
      },
      "params": {
        "files": "${[alert.ScannedFiles[] | select(any(.DetectionTechnologies[] == \"SB\"; .)) | .Hashes | map(.Value)] | flatten}",
        "notify": true
      }
    }
  },
  "onError": "stop"
}

Особенности:

Поддерживаются хеши MD5 и SHA256
Рекомендуется использовать selector: execution-tenant для глобального применения
Рекомендуется onError: "stop", чтобы прервать плейбук, если правило не создано

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

9.6.4. blockLDAPAccount — Блокировка учётной записи

Назначение: Блокировка учётной записи пользователя в Active Directory.

Параметры:

assets — массив ID пользователей

Пример из документации ([KL] P002):

{
  "action": {
    "function": {
      "type": "blockLDAPAccount",
      "assets": "${[ incident.Alerts[] | select(.OriginalEvents[] | .ExternalID == \"R050\") | .Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"
    }
  },
  "onError": "stop"
}

Разбор:

Извлекает ID пользователей-атакующих из алертов инцидента
Фильтрует только алерты от правила корреляции R050 (очистка журналов Windows)
Блокирует учётные записи атакующих

Требования:

Настроена интеграция с Active Directory

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P002».

9.6.5. iocsEnrichment — Обогащение через Kaspersky TIP

Назначение: Отправка наблюдаемых объектов в Kaspersky Threat Intelligence Portal для получения дополнительной информации об угрозах.

Параметры:

params.observables — массив наблюдаемых объектов в формате [{"type": "ip", "value": "1.2.3.4"}, ...]
params.fullEnrichment — запрашивать все записи (true) или только 100 самых популярных (false)

Пример из документации ([KL] "Playbook for checking external IP addresses"):

{
  "action": {
    "function": {
      "type": "iocsEnrichment",
      "params": {
        "fullEnrichment": true,
        "observables": "${[incident.Alerts[] | .Observables[] | {\"type\": .Type, \"value\": .Value} | select(.type == \"ip\" and (.value | test(\"^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)\") | not))] | unique_by(.value)}"
      }
    }
  },
  "onError": "stop",
  "timeout": {
    "scheduleToCloseTimeout": "24h"
  }
}

Разбор:

Извлекает все внешние IP-адреса из наблюдаемых объектов инцидента
Отправляет их в Kaspersky TIP
fullEnrichment: true — запрашивать все записи
unique_by(.value) — оставить только уникальные IP

Требования:

Настроена интеграция с Kaspersky TIP или OpenTIP
Лицензия на использование TIP

Результат:

Обогащённые данные сохраняются в инциденте
Доступны в деталях алерта/инцидента
Можно использовать для принятия решений (например, изоляция хоста при threatScore > 80)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264288 «Обогащение данных через Kaspersky TIP» и 318589 «[KL] Playbook for checking external IP addresses».

9.7. Практические рекомендации

9.7.1. Выбирайте правильное действие для сценария

Сценарий	Рекомендуемое действие
Удаление вредоносного файла	`deleteFile`
Блокировка файла по хешу	`addFilePreventionRules` с `selector: execution-tenant`
Изоляция заражённого хоста	`isolateHost` с `manualApprove`
Блокировка учётной записи атакующего	`blockLDAPAccount`
Сбор доказательств для расследования	`getForensics`
Обогащение данных о внешних IP	`iocsEnrichment`
Завершение подозрительного процесса	`killProcess`

9.7.2. Настраивайте обработку ошибок

Используйте onError: "stop" для критичных действий (блокировка учётной записи, создание правила запрета)
Используйте onError: "continue" для некритичных действий (удаление файла, сбор форензики)

9.7.3. Требуйте подтверждения для опасных действий

Для деструктивных действий (изоляция хоста, блокировка учётной записи) настраивайте manualApprove:

{
  "manualApprove": {
    "timeout": "60m",
    "emailNotifications": {
      "enabled": true,
      "delay": "10m"
    }
  }
}

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

Если нужно заблокировать файл на всех хостах, используйте selector: execution-tenant:

{
  "assets": {
    "selector": "execution-tenant"
  }
}

9.7.5. Проверяйте требования к интеграциям

Перед использованием действий проверьте, что настроены необходимые интеграции:

Действие	Требования
`blockLDAPAccount`, `unblockLDAPAccount`, `resetLDAPPassword`	Интеграция с Active Directory
`assignKasapGroup`	Интеграция с KASAP
`iocsEnrichment`	Интеграция с Kaspersky TIP или OpenTIP
Действия KATA/KEDR	Наличие агента KES/KATA на хосте

10. Тестирование и отладка

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

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 303867 «Тестовый режим (эмуляция запуска плейбука)»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249273 «История реагирований»
Официальная справка Kaspersky EDR Expert 8.1, раздел 264288 «Прерывание работы плейбуков»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249275 «Настройка ручного подтверждения плейбуков и ответных действий»

10.1. Режим «Обучение» — безопасный тест

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

10.1.1. Как работает режим «Обучение»

Плейбук находит алерт или инцидент, соответствующий триггеру.
Вместо выполнения действий плейбук создаёт «Запрос на подтверждение» для аналитика.
Аналитик просматривает, какие действия планировалось выполнить, и принимает решение:
- Подтвердить — плейбук выполнит действия
- Отклонить — запуск отменяется

10.1.2. Когда использовать режим «Обучение»

Сценарий	Рекомендация
Тестирование нового плейбука	Режим «Обучение»
Проверка корректности триггера	Режим «Обучение»
Отладка jq-выражений в алгоритме	Режим «Обучение»
Проверка перед переводом в «Автоматический»	Режим «Обучение»
Продуктивная эксплуатация отработанного сценария	Режим «Автоматический»
Разовое расследование	Режим «Ручной»

10.1.3. Преимущества режима «Обучение»

Безопасность: деструктивные действия (удаление файлов, изоляция хостов) не выполняются автоматически
Визуализация: аналитик видит, какие действия планировалось выполнить и с какими параметрами
Обучение: новые аналитики могут изучать работу плейбуков без риска повлиять на инфраструктуру
Отладка: можно проверить корректность jq-выражений и логику алгоритма

10.1.4. Время ожидания подтверждения

Согласно официальной документации (раздел 249275), по умолчанию запрос на подтверждение действует 60 минут. Если аналитик не подтверждает запуск в течение этого времени, запрос автоматически отменяется со статусом «Истекло время подтверждения».

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249275 «Настройка ручного подтверждения плейбуков и ответных действий».

10.2. Тестовый режим (эмуляция запуска плейбука)

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

10.2.1. Отличие от режима «Обучение»

Характеристика	Режим «Обучение»	Тестовый режим (эмуляция)
Автоматический запуск	Да (при срабатывании триггера)	Нет (запускается вручную)
Создание запроса на подтверждение	Да	Нет
Выполнение действий	После подтверждения — да	Никогда
Назначение	Тестирование в продуктивной среде	Отладка логики плейбука
Где сохраняются результаты	В «История реагирований» общего раздела	В «История реагирований» СВОЙСТВ плейбука

10.2.2. Роли для запуска в тестовом режиме

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

Роль	Возможность запуска
Главный администратор	Да
Аналитик 1-го уровня	Да
Аналитик 2-го уровня	Да
Администратор тенанта	Да

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 303867 «Тестовый режим (эмуляция запуска плейбука)».

10.2.3. Процесс запуска в тестовом режиме

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

Шаг 1. Перейти в раздел Мониторинг → Плейбуки.

Шаг 2. Выбрать плейбук и нажать кнопку «Запустить в тестовом режиме».

Шаг 3. Выбрать алерт или инцидент, на котором будет выполняться эмуляция.

Шаг 4. Опционально: включить опцию «Выберите целевые объекты» для выбора конкретных активов и наблюдаемых объектов.

Шаг 5. Нажать «Запустить».

Шаг 6. Просмотреть результат в «История реагирований» свойств плейбука.

10.2.4. Критическое отличие в сохранении результатов

Важно: Согласно официальной документации (раздел 303867), результаты тестового режима сохраняются в «История реагирований» СВОЙСТВ плейбука и НЕ отображаются в общем разделе «История реагирований» (Мониторинг → История реагирований).

Это означает, что для просмотра результатов эмуляции необходимо:

Открыть свойства плейбука
Перейти в раздел «История реагирований» внутри свойств плейбука
Просмотреть результаты там

10.2.5. Назначение тестового режима

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

Проверки логики плейбука без выполнения реальных действий с активами
Отладки jq-выражений в алгоритме
Проверки алгоритмов и триггеров перед переводом в продуктивную среду

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 303867 «Тестовый режим (эмуляция запуска плейбука)».

10.3. История реагирований

Согласно официальной документации (раздел 249273), «История реагирований» — это раздел, в котором отображаются результаты всех запусков плейбуков и действий по реагированию.

10.3.1. Где находится «История реагирований»

В системе есть два места для просмотра истории:

Место	Путь	Что отображается
Общий раздел	Мониторинг → История реагирований	Результаты всех запусков плейбуков в продуктивном режиме
Свойства плейбука	Плейбуки → [выбрать плейбук] → История реагирований	Результаты запусков конкретного плейбука, включая тестовый режим

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249273 «История реагирований».

10.3.2. Структура таблицы «История реагирований»

Согласно официальной документации, таблица содержит следующие столбцы:

Столбец	Описание
Действия	Название действия по реагированию
Параметры реагирования	Параметры, переданные в действие
Начало	Дата и время начала выполнения
Конец	Дата и время завершения выполнения
ID алерта или инцидента	Ссылка на детали алерта/инцидента
Запущено	Имя пользователя, запустившего плейбук
Подтверждающий	Имя пользователя, подтвердившего запуск (скрыт по умолчанию)
Время подтверждения	Дата и время подтверждения/отклонения (скрыт по умолчанию)
Статус	Статус выполнения

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249273 «История реагирований».

10.3.3. Статусы выполнения

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

Статус	Описание
Ожидание подтверждения	Плейбук ожидает одобрения аналитика
В обработке	Выполнение действий в процессе
Успешно	Все действия выполнены успешно
Предупреждение	Выполнено с предупреждениями
Ошибка	Выполнено с ошибками
Прервано	Пользователь прервал выполнение
Истекло время подтверждения	Время ожидания подтверждения истекло
Отклонено	Пользователь отклонил запуск

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249273 «История реагирований».

10.3.4. Просмотр деталей запуска

Согласно официальной документации:

Можно нажать на статус, чтобы открыть окно с результатом запуска
Идентификатор запуска используется техподдержкой для анализа проблем
Данные в «История реагирований» хранятся 72 часа

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249273 «История реагирований».

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

10.4. Прерывание работы плейбуков

Согласно официальной документации (раздел 264288), пользователь может прервать выполнение плейбука, находящегося в статусе «В обработке» или «Ожидание подтверждения».

10.4.1. Как прервать выполнение

Шаг 1. Перейти в раздел Мониторинг → История реагирований.

Шаг 2. Найти плейбук в статусе «В обработке» или «Ожидание подтверждения».

Шаг 3. Нажать кнопку «Прервать».

Шаг 4. Подтвердить прерывание.

После прерывания плейбук получает статус «Прервано».

10.4.2. Когда прерывать выполнение

Сценарий	Рекомендация
Плейбук выполняется слишком долго	Прервать
Обнаружена ошибка в алгоритме	Прервать
Алерт/инцидент оказался ложным	Прервать
Нужно запустить другую версию плейбука	Прервать
Плейбук успешно выполняется	Не прерывать

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264288 «Прерывание работы плейбуков».

10.5. Типичные сценарии отладки

10.5.1. Сценарий 1: Плейбук не срабатывает автоматически

Симптом: Плейбук в режиме «Автоматический» не запускается при появлении алерта/инцидента.

Диагностика:

Проверьте, что плейбук опубликован (не в статусе «Черновик»).
Проверьте, что область действия плейбука соответствует типу объекта (алерт или инцидент).
Проверьте синтаксис триггера через кнопку «Найти».
Убедитесь, что алерт/инцидент соответствует условиям триггера.
Проверьте, что плейбук не прерывается из-за ошибки в алгоритме.

Решение:

Исправить синтаксис триггера
Проверить, что алерт/инцидент соответствует условиям
Перевести плейбук в режим «Обучение» для тестирования

10.5.2. Сценарий 2: Плейбук запускается, но не выполняет действия

Симптом: Плейбук запускается, но в «История реагирований» отображается статус «Ошибка».

Диагностика:

Открыть «История реагирований» и найти проблемный запуск.
Нажать на статус «Ошибка» для просмотра деталей.
Проверить текст ошибки.
Проверить jq-выражения в алгоритме.

Типичные причины:

Неправильный регистр в jq-выражениях (например, alert.assets[] вместо alert.Assets[])
Пустой массив активов (нет хостов в алерте/инциденте)
Ошибка в параметрах действия
Отсутствие необходимых интеграций (Active Directory, Kaspersky TIP)

Решение:

Исправить jq-выражения с учётом регистра
Добавить проверки на пустые массивы
Настроить необходимые интеграции

10.5.3. Сценарий 3: Плейбук выполняется, но не на тех объектах

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

Диагностика:

Проверить jq-выражение в параметре assets.
Убедиться, что выражение извлекает правильные ID.
Проверить, что используется правильный ключевой слово (alert или incident).

Типичные причины:

Использование alert.Assets[] в плейбуке с областью «Инцидент» (или наоборот)
Неправильная фильтрация по .Type (например, type вместо Type)
Отсутствие фильтрации по .IsAttacker или .IsVictim

Решение:

Исправить ключевое слово в соответствии с областью действия
Проверить регистр полей
Добавить правильные фильтры

10.5.4. Сценарий 4: Время подтверждения истекло

Симптом: Плейбук в режиме «Обучение» не выполняется, статус «Истекло время подтверждения».

Диагностика:

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

Решение:

Увеличить время ожидания подтверждения в настройках плейбука
Настроить email-уведомления для быстрого реагирования
Назначить ответственных аналитиков для подтверждения

10.6. Чек-лист перед переводом в продуктивную среду

Перед переводом плейбука из режима «Обучение» в «Автоматический» рекомендуется выполнить следующие проверки:

10.6.1. Проверка триггера

Триггер проходит проверку синтаксиса (нет красной подсветки)
Кнопка «Найти» возвращает ожидаемые алерты/инциденты
Триггер не использует «тяжёлые» поля (OriginalEvents, Observables, Extra) без необходимости
Для автоматических плейбуков добавлено event.new (если нужно срабатывать только на новых объектах)

10.6.2. Проверка алгоритма

Алгоритм содержит все необходимые действия
jq-выражения используют правильный регистр (проверка по таблицам из Раздела 5)
jq-выражения возвращают непустые массивы (проверка через тестовый режим)
Для критичных действий настроено onError: "stop"
Для некритичных действий настроено onError: "continue"
Для опасных действий настроено manualApprove

10.6.3. Проверка в тестовом режиме

Плейбук запущен в тестовом режиме на реальном алерте/инциденте
Результаты в «История реагирований» свойств плейбука показывают ожидаемое поведение
Все jq-выражения возвращают корректные данные
Действия применяются к правильным объектам

10.6.4. Проверка в режиме «Обучение»

Плейбук переведён в режим «Обучение»
При появлении соответствующего алерта/инцидента создаётся запрос на подтверждение
После подтверждения плейбук выполняется успешно
В «История реагирований» отображается статус «Успешно»

10.6.5. Проверка интеграций

Для действий Active Directory настроена интеграция с AD
Для действия iocsEnrichment настроена интеграция с Kaspersky TIP
Для действия assignKasapGroup настроена интеграция с KASAP
На целевых хостах установлены агенты KES/KATA

10.6.6. Проверка ролей

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

11. Запуск и управление

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

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 249272 «Запуск плейбуков вручную»
Официальная справка Kaspersky EDR Expert 8.1, раздел 281686 «Запуск для выбранных объектов»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249275 «Настройка ручного подтверждения плейбуков и ответных действий»
Официальная справка Kaspersky EDR Expert 8.1, раздел 264272 «Подтверждение плейбуков и ответных действий»
Официальная справка Kaspersky EDR Expert 8.1, разделы 302860, 303374, 303375 (управление версиями)
Официальная справка Kaspersky EDR Expert 8.1, разделы 249268, 249270 (изменение и удаление)

11.1. Способы запуска плейбуков

Согласно официальной документации (раздел 249249), в Kaspersky EDR Expert существует несколько способов запуска плейбуков:

Способ	Описание	Когда использовать
Автоматический запуск	Плейбук срабатывает по триггеру при обнаружении соответствующих алертов/инцидентов	Для отработанных сценариев
Ручной запуск для алерта/инцидента	Аналитик вручную выбирает алерт/инцидент и запускает плейбук	Для разовых операций
Запуск для выбранных объектов	Плейбук запускается для конкретных активов и наблюдаемых объектов	Для точечных операций
Тестовый режим (эмуляция)	Плейбук обрабатывает объекты, но не выполняет действий	Для отладки

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249249 «Плейбуки».

11.2. Ручной запуск для алерта или инцидента

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

11.2.1. Роли для ручного запуска

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

Роль	Возможность запуска
Главный администратор	Да
Аналитик 1-го уровня	Да
Аналитик 2-го уровня	Да
Администратор тенанта	Да

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249272 «Запуск плейбуков вручную».

11.2.2. Запуск для алерта

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

Шаг 1. Перейти в раздел Мониторинг → Алерты.

Шаг 2. Найти нужный алерт и нажать на его идентификатор для открытия деталей.

Шаг 3. В панели действий выбрать пункт «Выбрать плейбук».

Шаг 4. Выбрать плейбук из списка доступных.

Шаг 5. Нажать «Запустить».

Шаг 6. Плейбук запускается, статус отображается в разделе «История реагирований» со статусом «В обработке».

11.2.3. Запуск для инцидента

Шаг 1. Перейти в раздел Мониторинг → Инциденты → XDR-инциденты.

Шаг 2. Найти нужный инцидент и нажать на его идентификатор.

Шаг 3. В панели действий выбрать «Выбрать плейбук».

Шаг 4. Выбрать плейбук из списка.

Шаг 5. Нажать «Запустить».

11.2.4. Поведение при уже запущенном плейбуке

Согласно официальной документации (раздел 249272), если для алерта/инцидента уже запущен плейбук, система предлагает три варианта:

Вариант	Описание	Когда использовать
Подождите и запустите	Новый экземпляр плейбука запускается после завершения текущего	Когда важно дождаться завершения текущего запуска
Прервать и запустить новый	Текущий запуск прерывается, начинается новый	Когда актуальна только последняя информация
Закрыть	Запуск отменяется	Когда запуск был ошибочным

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249272 «Запуск плейбуков вручную».

11.3. Запуск для выбранных объектов

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

11.3.1. Требования к плейбуку

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

Плейбук должен иметь область действия «Алерт» или «Инцидент».
Плейбук должен работать в режиме «Ручной».
В алгоритме плейбука должны использоваться jq-выражения для обращения к входным данным через .input.assets и .input.observables.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 281686 «Запуск для выбранных объектов».

11.3.2. Структура входных данных

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

{
  "input": {
    "observables": [
      {"type": "ip", "value": "127.0.0.1"},
      {"type": "ip", "value": "127.0.0.2"},
      {"type": "md5", "value": "29f975b01f762f1a6d2fe1b33b8e3e6e"}
    ],
    "assets": [
      {
        "ID": "c13a6983-0c40-4986-ab30-e85e49f98114",
        "Name": "VIM-W10-64-01",
        "Type": "host"
      }
    ]
  }
}

Ключевые особенности:

Наблюдаемые объекты доступны через .input.observables[]
Активы доступны через .input.assets[]
В операционных данных используется строчный регистр (type, value, а не Type, Value)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 281686 «Запуск для выбранных объектов».

11.3.3. Пример jq-выражения для работы с выбранными объектами

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

${ "-ip " + ([.input.observables[] | select(.type == "ip")] | map(.value) | join(",")) }

Разбор:

.input.observables[] — пройтись по всем наблюдаемым объектам
select(.type == "ip") — оставить только IP-адреса
map(.value) — извлечь значения
join(",") — объединить в строку через запятую

Результат: -ip 127.0.0.1,127.0.0.2

11.3.4. Пример использования в действии

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

{
  "action": {
    "function": {
      "type": "executeCustomScript",
      "params": {
        "commandLine": "./script.py",
        "commandLineParameters": "${ \"-ip \" + ([.input.observables[] | select(.type == \"ip\")] | map(.value) | join(\",\")) }",
        "workingDirectory": "/folder/with/script"
      }
    }
  }
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 281686 «Запуск для выбранных объектов».

11.3.5. Критическое предупреждение

Важно: Согласно официальной документации (раздел 281686), если объекты не указаны в алгоритме плейбука через jq-выражения, они будут проигнорированы. Это означает, что даже если аналитик выбрал объекты при запуске, плейбук их не использует, если в алгоритме нет обращения к .input.assets или .input.observables.

11.3.6. Процесс запуска

Шаг 1. Создать плейбук с областью действия «Алерт» или «Инцидент» и режимом «Ручной».

Шаг 2. В алгоритме использовать jq-выражения для обращения к .input.assets и .input.observables.

Шаг 3. Перейти в раздел Мониторинг → Алерты (или Инциденты).

Шаг 4. Выбрать алерт/инцидент и нажать «Выбрать плейбук».

Шаг 5. Включить опцию «Выберите целевые объекты».

Шаг 6. Выбрать активы и наблюдаемые объекты.

Шаг 7. Нажать «Запустить».

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 281686 «Запуск для выбранных объектов».

11.4. Настройка ручного подтверждения

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

11.4.1. Когда использовать ручное подтверждение

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

Действие	Причина
Перемещение устройств в другую группу администрирования	Изменение структуры управления
Помещение файлов на карантин	Потенциальная потеря данных
Включение/выключение сетевой изоляции	Блокировка сетевых соединений
Реагирование на учётные записи через Active Directory	Блокировка пользователей
Обогащение данных	Длительные операции

11.4.2. Настройка в JSON-алгоритме

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

Пример 1: Включить подтверждение (по умолчанию 60 минут)

{
  "action": {
    "function": {
      "type": "isolateHost",
      "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}"
    }
  },
  "manualApprove": true
}

Пример 2: Настраиваемое время подтверждения

{
  "action": {
    "function": {
      "type": "isolateHost"
    }
  },
  "manualApprove": {
    "timeout": "20h"
  }
}

Пример 3: Время с минутами

{
  "manualApprove": {
    "timeout": "2h30m"
  }
}

11.4.3. Настройка email-уведомлений

Согласно официальной документации, можно настроить отправку email-уведомлений о необходимости подтверждения.

Пример 4: Включить email-уведомления

{
  "manualApprove": {
    "emailNotifications": {
      "enabled": true
    }
  }
}

Пример 5: Email-уведомление с задержкой

{
  "manualApprove": {
    "emailNotifications": {
      "enabled": true,
      "delay": "20m"
    }
  }
}

Параметры email-уведомлений:

enabled — включить уведомления (true/false)
delay — задержка перед отправкой (например, 20m — 20 минут)

11.4.4. Полный пример из документации

Согласно официальной документации ([KL] "Playbook for checking external IP addresses"), полный пример настройки ручного подтверждения:

{
  "action": {
    "function": {
      "type": "netIsolateOn",
      "assets": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | map(.ID)}",
      "params": {
        "exclusions": [],
        "exclusionsConflictBehavior": "replace",
        "isolationTimeoutSec": 28800
      }
    }
  },
  "onError": "stop",
  "timeout": {
    "scheduleToCloseTimeout": "24h"
  },
  "manualApprove": {
    "timeout": "60m",
    "emailNotifications": {
      "enabled": true,
      "delay": "10m"
    }
  }
}

Разбор:

manualApprove.timeout: "60m" — время ожидания подтверждения 60 минут
emailNotifications.enabled: true — включить email-уведомления
emailNotifications.delay: "10m" — отправить email через 10 минут после создания запроса

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] Playbook for checking external IP addresses».

11.5. Подтверждение и отклонение плейбуков

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

11.5.1. Роли для подтверждения

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

Объект подтверждения	Роли
Плейбуки	Главный администратор, Аналитик 1-го уровня, Аналитик 2-го уровня, Администратор тенанта
Действия по реагированию	Главный администратор, Подтверждающий, Администратор тенанта

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264272 «Подтверждение плейбуков и ответных действий».

11.5.2. Процесс подтверждения

Шаг 1. Получить уведомление в верхней части консоли OSMP или по email.

Шаг 2. Нажать на уведомление или перейти в раздел «Запросы о подтверждении».

Шаг 3. Выбрать плейбук или действие из списка.

Шаг 4. Просмотреть параметры запуска (какие действия, для каких объектов).

Шаг 5. Нажать «Одобрить» или «Отклонить».

11.5.3. Таблица «Запросы о подтверждении»

Согласно официальной документации, таблица содержит следующие столбцы:

Столбец	Описание
Время запроса	Дата и время создания запроса
Срок утверждения	Дедлайн для подтверждения
Плейбук	Название плейбука
Действие по реагированию	Название действия (если подтверждается конкретное действие)
Активы	Количество активов, для которых выполняется действие
Параметры реагирования	Параметры, переданные в действие
ID алерта или инцидента	Ссылка на детали алерта/инцидента
Тенант	Тенант, к которому относится запрос

11.5.4. Поведение при истечении времени

Согласно официальной документации:

Если время подтверждения истекло, запуск автоматически отменяется
Статус в «История реагирований» — «Истекло время подтверждения»
Действия не выполняются

11.5.5. Подтверждение для конкретных активов

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

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

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

11.6. Управление версиями плейбуков

Согласно официальной документации (раздел 302860), Kaspersky EDR Expert автоматически хранит историю версий плейбуков.

11.6.1. Когда создаётся новая версия

Согласно официальной документации, новая версия создаётся автоматически в следующих случаях:

Событие	Результат
Создание плейбука	Создаётся версия 1
Сохранение изменений в существующем плейбуке	Создаётся новая версия с инкрементом номера

11.6.2. Просмотр истории версий

Согласно официальной документации, для просмотра истории версий:

Шаг 1. Перейти в раздел Мониторинг → Плейбуки.

Шаг 2. Выбрать плейбук.

Шаг 3. В правой панели нажать «История версий».

Отобразится список всех версий с датами и авторами изменений.

11.6.3. Сравнение версий

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

Процесс:

Шаг 1. Открыть историю версий плейбука.

Шаг 2. Выбрать две версии для сравнения (удерживая Ctrl или Shift).

Шаг 3. Нажать «Сравнить».

Система отобразит различия в параметрах, триггере и алгоритме.

11.6.4. Восстановление предыдущей версии

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

Процесс:

Шаг 1. Открыть историю версий плейбука.

Шаг 2. Найти нужную версию.

Шаг 3. Нажать «Восстановить».

Шаг 4. Подтвердить восстановление.

Система создаст новую версию с содержимым выбранной старой версии.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 302860, 303374, 303375.

11.7. Изменение плейбуков

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

11.7.1. Роли для изменения

Роль	Возможность изменения
Главный администратор	Да
Администратор тенанта	Да
Администратор SOC	Да
Аналитик SOC	Да
Аналитик 1-го уровня	Да
Аналитик 2-го уровня	Да

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков».

11.7.2. Что можно изменить

Согласно официальной документации, можно изменить:

Параметр	Описание
Имя	Название плейбука
Описание	Текстовое описание
Режим работы	Автоматический / Обучение / Ручной
Теги	Метки для фильтрации
Триггер	jq-выражение для автоматического запуска
Алгоритм	JSON-код выполнения
playbookRunTimeout	Максимальное время выполнения
Настройки наследования	Доступность в дочерних тенантах

11.7.3. Процесс изменения

Шаг 1. Перейти в раздел Мониторинг → Плейбуки.

Шаг 2. Найти плейбук и нажать «Изменить».

Шаг 3. Внести изменения в параметры, триггер или алгоритм.

Шаг 4. Нажать «Сохранить».

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

11.7.4. Ограничения для предустановленных плейбуков [KL]

Согласно официальной документации, для предустановленных плейбуков [KL]:

Операция	Доступна
Изменение режима работы	Да
Изменение триггера	Да
Изменение алгоритма	Нет
Изменение имени	Нет
Удаление	Нет

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

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков».

11.8. Удаление плейбуков

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

11.8.1. Роли для удаления

Роль	Возможность удаления
Главный администратор	Да
Администратор тенанта	Да

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249270 «Удаление плейбуков».

11.8.2. Процесс удаления

Шаг 1. Перейти в раздел Мониторинг → Плейбуки.

Шаг 2. Найти плейбук и нажать «Удалить».

Шаг 3. Подтвердить удаление.

Плейбук получает статус «Удалено».

11.8.3. Поведение удалённых плейбуков

Согласно официальной документации:

Удалённые плейбуки нельзя запустить
Удалённые плейбуки нельзя изменить
Удалённые плейбуки можно просматривать и копировать
Удалённые плейбуки отображаются в таблице с фильтром по статусу «Удалено»

11.8.4. Ограничения для предустановленных плейбуков [KL]

Согласно официальной документации, предустановленные плейбуки [KL] нельзя удалить.

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249270 «Удаление плейбуков».

11.9. Практические рекомендации

11.9.1. Когда использовать ручной запуск

Сценарий	Рекомендация
Разовое расследование конкретного инцидента	Ручной запуск
Тестирование плейбука на реальном объекте	Ручной запуск
Применение действий к выбранным объектам	Запуск для выбранных объектов
Массовая обработка типовых угроз	Автоматический запуск

11.9.2. Когда использовать ручное подтверждение

Действие	Рекомендация
Изоляция хоста	Ручное подтверждение
Блокировка учётной записи	Ручное подтверждение
Удаление файла	По ситуации (если файл критичен)
Создание правила запрета	Автоматически (если сценарий отработан)
Сбор форензики	Автоматически
Обогащение данных	Автоматически

11.9.3. Управление версиями

Регулярно просматривайте историю версий перед внесением изменений
Сравнивайте версии перед восстановлением
Документируйте изменения в описании плейбука
Тестируйте изменения в режиме «Обучение» перед публикацией

11.9.4. Работа с выбранными объектами

Всегда проверяйте jq-выражения в алгоритме на обращение к .input.assets и .input.observables
Используйте строчный регистр для полей в .input (.type, .value, а не .Type, .Value)
Тестируйте в тестовом режиме перед запуском в продуктивной среде

12. Предустановленные плейбуки [KL]

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

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P001 Creation of executable files by office applications»
Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003 Suspicious child process from wmiprvse.exe»
Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004 Sandbox Medium Detect»
Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] P005 Sandbox High Detect»
Официальная справка Kaspersky EDR Expert 8.1, раздел 318590 «[KL] Playbook for checking external IP addresses»
Официальная справка Kaspersky EDR Expert 8.1, раздел 324933 «[KL] Playbook for isolating a device where an infected file is detected»

12.1. Что такое предустановленные плейбуки

Согласно официальной документации, предустановленные плейбуки — это сценарии реагирования, созданные специалистами «Лаборатории Касперского» на основе правил корреляции KUMA. Они отмечены префиксом [KL] в названии и тегом Predefined.

12.1.1. Особенности предустановленных плейбуков

Характеристика	Описание
Автор	Лаборатория Касперского
Основа	Правила корреляции KUMA
Изменение алгоритма	Недоступно
Изменение триггера	Доступно
Изменение режима работы	Доступно
Удаление	Недоступно
Дублирование	Доступно
Наследование	Автоматически наследуются дочерними тенантами
Режим по умолчанию	Обучение

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249249 «Плейбуки».

12.1.2. Список предустановленных плейбуков

№	Название	Область действия	Назначение
1	`[KL] P001` "Creation of executable files by office applications"	Алерт	Реагирование на фишинг через офисные приложения
2	`[KL] P002` "Windows Event Log was cleared"	Инцидент	Блокировка учётной записи при очистке журналов
3	`[KL] P003` "Suspicious child process from wmiprvse.exe"	Алерт	Завершение процессов и AV-проверка
4	`[KL] P004` "Sandbox Medium Detect"	Алерт	Блокировка файлов с уровнем «Средний»
5	`[KL] P005` "Sandbox High Detect"	Алерт	Блокировка файлов с уровнем «Высокий»
6	`[KL] Playbook for checking external IP addresses`	Инцидент	Обогащение IP через Kaspersky TIP
7	`[KL] Playbook for isolating a device where an infected file is detected`	Инцидент	Изоляция устройства с заражённым файлом

12.2. Требования перед использованием

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

12.2.1. Настройка обогащения событий в KUMA

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

Плейбук	Требуемое обогащение
`[KL] P001`	`VictimUserID` — идентификатор атакуемого пользователя
`[KL] P002`	`AttackerUserID` — идентификатор атакующего пользователя
`[KL] P003`	`AttackerUserID` — идентификатор атакующего пользователя

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 271609–271611.

12.2.2. Настройка интеграций

Плейбук	Требуемая интеграция
`[KL] P001`	KASAP (для назначения курса обучения)
`[KL] P002`, `[KL] P003`	Active Directory (для блокировки учётных записей)
`[KL] Playbook for checking external IP addresses`	Kaspersky TIP или OpenTIP (для обогащения данных)

12.2.3. Настройка получения журналов событий Windows

Для работы плейбуков, анализирующих исходные события (например, [KL] P002), необходимо настроить получение журналов событий Windows в KUMA.

12.2.4. Настройка правил сегментации

Для плейбуков, работающих с инцидентами ([KL] P002, [KL] Playbook for checking external IP addresses, [KL] Playbook for isolating a device), необходимо настроить правила сегментации, которые определяют, какие алерты объединяются в инциденты.

12.3. Разбор плейбуков

12.3.1. [KL] P001 "Creation of executable files by office applications"

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

Область действия: Алерт

Триггер:

[.OriginalEvents[] | .ExternalID == "R350"] | any

Разбор триггера:

.OriginalEvents[] — пройтись по всем исходным событиям алерта
.ExternalID == "R350" — проверить, соответствует ли событие правилу корреляции R350
[...] | any — вернуть true, если хотя бы одно событие соответствует

Алгоритм:

{
  "dslSpecVersion": "1.1.0",
  "version": "1",
  "actionSpecVersion": "1",
  "executionFlow": [
    {
      "action": {
        "function": {
          "type": "resetLDAPPassword",
          "assets": "${[ alert.Assets[] | select(.Type == \"user\") | .ID]}"
        }
      },
      "onError": "stop"
    },
    {
      "action": {
        "function": {
          "type": "assignKasapGroup",
          "assets": "${[ alert.Assets[] | select(.Type == \"user\") | .ID]}",
          "params": {
            "groupId": "SET KASAP GROUP ID"
          }
        }
      },
      "onError": "continue"
    }
  ]
}

Разбор алгоритма:

Шаг 1: Сброс паролей всех пользователей из алерта через resetLDAPPassword
Шаг 2: Назначение курса обучения через assignKasapGroup

Особенности:

Содержит действие assignKasapGroup, требующее указания groupId (необходимо заменить "SET KASAP GROUP ID" на реальный ID группы в KASAP)
По умолчанию работает со всеми пользователями в алерте
Для работы только с атакуемым пользователем необходимо дублировать плейбук и добавить and .IsVictim в селектор активов
Требует настроенной интеграции с KASAP

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P001».

12.3.2. [KL] P002 "Windows Event Log was cleared"

Назначение: Предотвращение очистки журнала событий Windows атакующим. Журнал содержит критическую телеметрию для расследования.

Область действия: Инцидент

Режим по умолчанию: Ручной (не рекомендуется переключать в Автоматический или Обучение)

Триггер:

[.Alerts[] | .OriginalEvents[] | .ExternalID == "R050"] | any

Разбор триггера:

.Alerts[] — пройтись по всем алертам инцидента
.OriginalEvents[] — пройтись по всем исходным событиям каждого алерта
.ExternalID == "R050" — проверить, соответствует ли событие правилу корреляции R050 (очистка журналов Windows)
[...] | any — вернуть true, если хотя бы одно событие в любом алерте соответствует

Алгоритм:

{
  "dslSpecVersion": "1.1.0",
  "version": "1",
  "actionSpecVersion": "1",
  "executionFlow": [
    {
      "action": {
        "function": {
          "type": "blockLDAPAccount",
          "assets": "${[ incident.Alerts[] | select(.OriginalEvents[] | .ExternalID == \"R050\") | .Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"
        }
      },
      "onError": "stop"
    }
  ]
}

Разбор алгоритма:

Блокировка учётной записи атакующего пользователя через blockLDAPAccount
jq-выражение извлекает ID пользователей-атакующих из алертов инцидента, у которых исходные события содержат ExternalID == "R050"

Особенности:

Работает с инцидентами (не алертами)
Требует настройки правил сегментации для создания инцидентов
Если алерт создан другим правилом корреляции — плейбук не применяется
Требует обогащения AttackerUserID в KUMA
Требует настроенной интеграции с Active Directory

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271609 «[KL] P002».

12.3.3. [KL] P003 "Suspicious child process from wmiprvse.exe"

Назначение: Обнаружение и блокировка подозрительных дочерних процессов от wmiprvse.exe.

Область действия: Алерт

Триггер:

[.OriginalEvents[] | .ExternalID == "R297"] | any

Алгоритм:

{
  "dslSpecVersion": "1.1.0",
  "version": "1",
  "actionSpecVersion": "1",
  "executionFlow": [
    {
      "action": {
        "function": {
          "type": "blockLDAPAccount",
          "assets": "${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"
        }
      },
      "onError": "stop"
    },
    {
      "loop": {
        "input": "${ [alert.OriginalEvents[] | [select(.DestinationProcessName != null and .DestinationProcessName != \"\")][] | .DestinationProcessName] }",
        "batchSize": 1,
        "mode": "parallel",
        "onError": "stop",
        "steps": [
          {
            "action": {
              "function": {
                "type": "killProcess",
                "assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}",
                "params": {
                  "path": "${ .[0] }"
                }
              }
            }
          }
        ]
      }
    },
    {
      "action": {
        "function": {
          "type": "avScan",
          "assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}",
          "params": {
            "scope": {
              "area": "full",
              "allowScanNetworkDrives": false
            },
            "wait": false
          }
        }
      },
      "onError": "stop"
    }
  ]
}

Разбор алгоритма:

Шаг 1: Блокировка учётной записи атакующего через blockLDAPAccount
Шаг 2: Завершение подозрительных процессов через killProcess в цикле:
- input — извлекает имена процессов из исходных событий
- batchSize: 1 — обрабатывает по одному процессу за итерацию
- mode: "parallel" — выполняет итерации параллельно
- .[0] — текущий элемент (имя процесса)
Шаг 3: Полная антивирусная проверка через avScan:
- area: "full" — полная проверка
- allowScanNetworkDrives: false — не проверять сетевые диски
- wait: false — асинхронная проверка

Особенности:

Использует цикл для завершения нескольких процессов
По умолчанию не проверяет сетевые диски (allowScanNetworkDrives: false)
Для проверки сетевых дисков необходимо дублировать плейбук и установить allowScanNetworkDrives: true
Требует обогащения AttackerUserID в KUMA
Требует настроенной интеграции с Active Directory

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

12.3.4. [KL] P004 "Sandbox Medium Detect"

Назначение: Создание правила блокировки для файлов, которым Sandbox назначил уровень важности «Средний».

Область действия: Алерт

Триггер:

event.new and .Severity == "medium" and any(.DetectionTechnologies[] == "SB"; .)

Разбор триггера:

event.new — только для новых алертов
.Severity == "medium" — важность «medium»
any(.DetectionTechnologies[] == "SB"; .) — хотя бы одна технология обнаружения — Sandbox

Алгоритм:

{
  "version": "1",
  "dslSpecVersion": "1.1.0",
  "actionsSpecVersion": "1",
  "executionFlow": [
    {
      "action": {
        "function": {
          "type": "addFilePreventionRules",
          "assets": ["selector": "execution-tenant"],
          "params": {
            "files": "${[alert.ScannedFiles[] | select(any(.DetectionTechnologies[] == \"SB\"; .)) | .Hashes | map(.Value)] | flatten}",
            "notify": true
          }
        }
      },
      "onError": "stop"
    }
  ]
}

Разбор алгоритма:

type: "addFilePreventionRules" — создание правила запрета на запуск файла
assets: ["selector": "execution-tenant"] — применение правила ко всему тенанту
params.files — jq-выражение извлекает хеши файлов, обнаруженных через Sandbox:
- alert.ScannedFiles[] — пройтись по всем просканированным файлам
- select(any(.DetectionTechnologies[] == "SB"; .)) — оставить только файлы, обнаруженные через Sandbox
- .Hashes | map(.Value) — извлечь значения хешей
- | flatten — преобразовать в плоский массив
params.notify: true — отправить уведомление о создании правила

Особенности:

Использует selector: execution-tenant для создания глобального правила на весь тенант
Извлекает хеши из alert.ScannedFiles[]
Фильтрует только файлы, обнаруженные через Sandbox (DetectionTechnologies[] == "SB")

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

12.3.5. [KL] P005 "Sandbox High Detect"

Назначение: Создание правила блокировки для файлов, которым Sandbox назначил уровень важности «Высокий».

Область действия: Алерт

Триггер:

event.new and .Severity == "high" and any(.DetectionTechnologies[] == "SB"; .)

Алгоритм: Аналогичен P004, отличается только фильтром по .Severity == "high".

Особенности:

Аналогично P004, но для высокого уровня важности
Использует тот же механизм selector: execution-tenant

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] P005».

12.3.6. [KL] "Playbook for checking external IP addresses"

Назначение: Проверка внешних IP-адресов через Kaspersky TIP и изоляция хостов при высокой угрозе.

Область действия: Инцидент

Триггер:

event.new and ([ .Alerts[] | .Observables[] | select(.Value | test("^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)") | not) | .Value ] | length > 0)

Разбор триггера:

event.new — только для новых инцидентов
.Alerts[] — пройтись по всем алертам инцидента
.Observables[] — пройтись по всем наблюдаемым объектам
select(.Value | test("^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)") | not) — оставить только те, значение которых НЕ соответствует приватным IP-диапазонам
[...] | length > 0 — вернуть true, если есть хотя бы один внешний IP

Приватные диапазоны, которые исключаются:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.0/8

Алгоритм (упрощённо):

{
  "version": "1",
  "dslSpecVersion": "1.1.0",
  "actionsSpecVersion": "1",
  "playbookRunTimeout": "24h",
  "executionFlow": [
    {
      "action": {
        "function": {
          "type": "iocsEnrichment",
          "params": {
            "fullEnrichment": true,
            "observables": "${[incident.Alerts[] | .Observables[] | {\"type\": .Type, \"value\": .Value} | select(.type == \"ip\" and (.value | test(\"^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.)\") | not))] | unique_by(.value)}"
          }
        },
        "onError": "stop",
        "timeout": {"scheduleToCloseTimeout": "24h"},
        "output": {"filter": "${.}", "action": "overwrite"}
      }
    },
    {
      "decision": {
        "conditions": [
          {
            "condition": "${[.details.observableData[] | select(.status == \"ok\" and .ipObservableData.ipGeneralInfo.threatScore > 80)] | length > 0}",
            "name": "Condition 1",
            "steps": [
              {
                "decision": {
                  "conditions": [
                    {
                      "condition": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | length > 0}",
                      "name": "alert has host(s)",
                      "steps": [
                        {
                          "action": {
                            "function": {
                              "type": "getForensics",
                              "assets": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | map(.ID)}",
                              "params": {
                                "processes": {"collect": true},
                                "autoruns": {"collect": false}
                              }
                            }
                          }
                        },
                        {
                          "action": {
                            "function": {
                              "type": "netIsolateOn",
                              "assets": "${incident.Alerts | map(.Assets) | flatten | map(select(.Type == \"host\")) | map(.ID)}",
                              "params": {
                                "exclusions": [],
                                "exclusionsConflictBehavior": "replace",
                                "isolationTimeoutSec": 28800
                              }
                            },
                            "manualApprove": {
                              "timeout": "60m",
                              "emailNotifications": {
                                "enabled": true,
                                "delay": "10m"
                              }
                            }
                          }
                        }
                      ]
                    }
                  ]
                }
              }
            ]
          }
        ]
      }
    }
  ]
}

Разбор алгоритма:

Шаг 1: Обогащение внешних IP через iocsEnrichment:
- Извлекает все внешние IP из наблюдаемых объектов инцидента
- Отправляет их в Kaspersky TIP
- fullEnrichment: true — запрашивать все записи
- unique_by(.value) — оставить только уникальные IP
Шаг 2: Ветвление decision:
- Проверяет, есть ли наблюдаемые объекты с threatScore > 80
- Если да — проверяет наличие хостов в инциденте
- Если хосты есть — выполняет сбор форензики (getForensics) и изоляцию (netIsolateOn)
Шаг 3: Изоляция хоста через netIsolateOn:
- isolationTimeoutSec: 28800 — изоляция на 8 часов
- manualApprove — требуется ручное подтверждение аналитика (60 минут)
- emailNotifications — отправить email-уведомление с задержкой 10 минут

Особенности:

Сложный алгоритм с вложенными decision
Проверяет внешние IP (исключает приватные диапазоны через regex)
Использует Kaspersky TIP для обогащения
Изолирует хосты только если threatScore > 80
Требует ручного подтверждения для netIsolateOn (60 минут)
Отправляет email-уведомления с задержкой 10 минут
Требует настройки интеграции с Kaspersky TIP

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 318589 «[KL] Playbook for checking external IP addresses».

12.3.7. [KL] "Playbook for isolating a device where an infected file is detected"

Назначение: Изоляция устройства после обнаружения заражённого файла.

Область действия: Инцидент

Триггер: Отсутствует (ручной запуск)

Алгоритм (упрощённо):

{
  "version": "1",
  "dslSpecVersion": "1.1.0",
  "actionsSpecVersion": "1",
  "playbookRunTimeout": "24h",
  "executionFlow": [
    {
      "decision": {
        "conditions": [
          {
            "condition": "${((.input.assets // []) | length) > 0 and ([.input.observables[] | select(.type == \"md5\" or .type == \"sha256\" and .value != null and .value != \"\")] | length) > 0}",
            "name": "has input data",
            "steps": [
              {
                "loop": {
                  "input": "${[(.input.observables | map(select(.type == \"md5\" or .type == \"sha256\") | select(.value != null and .value != \"\") | .value))[] as $hash | [incident.Alerts[] | .Observables[]? | select((.Type == \"md5\" or .Type == \"sha256\") and .Value == $hash and .Details != \"\")][0] | {\"path\": .Details, \"hash\":.Value}]}",
                  "steps": [
                    {
                      "decision": {
                        "conditions": [
                          {
                            "condition": "${.[0].path? | length > 0}",
                            "name": "hash with path",
                            "steps": [
                              {
                                "updateData": {
                                  "action": "merge",
                                  "filter": "${.[0]}"
                                }
                              },
                              {
                                "action": {
                                  "function": {
                                    "type": "getFile",
                                    "asset": "${([incident.Alerts[] | .Assets[]? | select(.Type == \"host\")][0].ID // (.assets[0] // \"\"))}",
                                    "params": {
                                      "path": "${.path}"
                                    }
                                  },
                                  "onError": "continue",
                                  "timeout": {"scheduleToCloseTimeout": "24h"},
                                  "output": {
                                    "action": "merge",
                                    "filter": "${{\"fileID\": (.details[0].details.file.id // null), \"scanResult\": null}}"
                                  }
                                }
                              },
                              {
                                "decision": {
                                  "conditions": [
                                    {
                                      "condition": "${.fileID != null and .fileID != \"\"}",
                                      "name": "fileID exists",
                                      "steps": [
                                        {
                                          "action": {
                                            "function": {
                                              "type": "serverScan",
                                              "params": {
                                                "file": {
                                                  "id": "${.fileID}"
                                                }
                                              }
                                            },
                                            "onError": "continue",
                                            "timeout": {"scheduleToCloseTimeout": "24h"},
                                            "output": {
                                              "action": "merge",
                                              "filter": "${{\"scanResult\": .}}"
                                            }
                                          }
                                        },
                                        {
                                          "decision": {
                                            "conditions": [
                                              {
                                                "condition": "${[.scanResult.details.scanResult.technologies[] | .result] | contains([\"Infected\"])}",
                                                "name": "infected",
                                                "steps": [
                                                  {
                                                    "action": {
                                                      "function": {
                                                        "type": "addFilePreventionRules",
                                                        "assets": ["selector": "execution-tenant"],
                                                        "params": {
                                                          "files": "${[.hash]}"
                                                        }
                                                      },
                                                      "onError": "stop",
                                                      "timeout": {"scheduleToCloseTimeout": "24h"},
                                                      "manualApprove": true
                                                    }
                                                  },
                                                  {
                                                    "updateData": {
                                                      "action": "overwrite",
                                                      "filter": "${{\"isInfected\": true}}"
                                                    }
                                                  }
                                                ]
                                              }
                                            ]
                                          }
                                        }
                                      ]
                                    }
                                  ]
                                }
                              }
                            ]
                          }
                        ]
                      }
                    }
                  ],
                  "onError": "continue",
                  "batchSize": 1,
                  "aggregate": "${.}",
                  "output": {"filter": "${{\"scanResult\": .}}"}
                }
              },
              {
                "decision": {
                  "conditions": [
                    {
                      "condition": "${.scanResult | map(.isInfected) | any}",
                      "name": "isInfected",
                      "steps": [
                        {
                          "action": {
                            "function": {
                              "type": "netIsolateOn",
                              "assets": "${.input.assets | map(select(.Type == \"host\") | .ID)}",
                              "params": {
                                "exclusions": [],
                                "exclusionsConflictBehavior": "replace",
                                "isolationTimeoutSec": 28800
                              }
                            },
                            "onError": "stop",
                            "timeout": {"scheduleToCloseTimeout": "24h"}
                          }
                        }
                      ]
                    }
                  ]
                }
              }
            ]
          }
        ]
      }
    }
  ]
}

Разбор алгоритма:

Шаг 1: Проверка наличия входных данных (активы и наблюдаемые объекты)
Шаг 2: Цикл по хешам:
- Извлекает хеши MD5 и SHA256 из .input.observables
- Для каждого хеша находит путь к файлу в наблюдаемых объектах инцидента
- Получает файл с хоста через getFile
- Проверяет файл на сервере через serverScan
- Если обнаружена угроза (Infected):
  - Добавляет правило запрета на весь тенант через addFilePreventionRules
  - Требует ручного подтверждения (manualApprove: true)
  - Устанавливает флаг isInfected: true
Шаг 3: Если хотя бы один файл заражён — изолирует все выбранные хосты через netIsolateOn

Особенности:

Ручной запуск — нет триггера
Требует выбора целевых объектов (активы и наблюдаемые объекты)
Работает с хешами MD5 и SHA256
Использует цикл для обработки нескольких хешей
Получает файл, проверяет его, и если обнаружена угроза:
- Добавляет правило запрета на весь тенант
- Изолирует все выбранные хосты
Требует ручного подтверждения для addFilePreventionRules и netIsolateOn
Очень сложный алгоритм с множеством вложенных decision и loop

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 324933 «[KL] Playbook for isolating a device where an infected file is detected».

12.4. Как дублировать и модифицировать предустановленные плейбуки

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

12.4.1. Процесс дублирования

Шаг 1. Перейти в раздел Мониторинг → Плейбуки.

Шаг 2. Найти предустановленный плейбук [KL].

Шаг 3. Нажать кнопку «Дублировать».

Шаг 4. Система создаст копию плейбука с новым именем (например, My P003 Custom).

Шаг 5. В копии можно изменять:

Алгоритм
Триггер
Все параметры

Шаг 6. Оригинальный плейбук [KL] остаётся неизменным.

12.4.2. Типичные модификации

Модификация 1: Изменение области действия в селекторе активов

Оригинал (P001):

[ alert.Assets[] | select(.Type == "user") | .ID]

Модификация (только атакуемый пользователь):

[ alert.Assets[] | select(.Type == "user" and .IsVictim) | .ID]

Модификация 2: Включение проверки сетевых дисков (P003)

Оригинал:

"params": {
  "scope": {
    "area": "full",
    "allowScanNetworkDrives": false
  }
}

Модификация:

"params": {
  "scope": {
    "area": "full",
    "allowScanNetworkDrives": true
  }
}

Модификация 3: Изменение времени изоляции

Оригинал:

"params": {
  "isolationTimeoutSec": 28800
}

Модификация (24 часа):

"params": {
  "isolationTimeoutSec": 86400
}

Модификация 4: Указание реального groupId для KASAP (P001)

Оригинал:

"params": {
  "groupId": "SET KASAP GROUP ID"
}

Модификация:

"params": {
  "groupId": "actual-kasap-group-id-from-kasap"
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249249 «Плейбуки».

12.5. Практические рекомендации

12.5.1. Когда использовать предустановленные плейбуки

Сценарий	Рекомендация
Типовая угроза, описанная в [KL]	Использовать предустановленный плейбук
Требуется модификация алгоритма	Дублировать и модифицировать
Нет настроенных интеграций (AD, KASAP, TIP)	Не использовать плейбук, требующий интеграции
Специфичная инфраструктура	Дублировать и адаптировать

12.5.2. Проверка готовности к использованию

Перед включением предустановленного плейбука проверьте:

Настроены правила обогащения в KUMA (VictimUserID, AttackerUserID)
Настроена интеграция с Active Directory (для P002, P003)
Настроена интеграция с KASAP (для P001)
Настроена интеграция с Kaspersky TIP (для Playbook for checking external IP addresses)
Настроены правила сегментации (для плейбуков, работающих с инцидентами)
Настроено получение журналов событий Windows (для P002)
Указан реальный groupId для KASAP (для P001)

12.5.3. Тестирование предустановленных плейбуков

Переведите плейбук в режим «Обучение» (если он не в этом режиме)
Дождитесь срабатывания триггера на реальном алерте/инциденте
Проверьте запрос на подтверждение — какие действия планируются, для каких объектов
Подтвердите запуск и проверьте результат в «История реагирований»
При необходимости дублируйте и модифицируйте плейбук

12.5.4. Отключение наследования

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

Откройте модифицированный плейбук
Снимите флажок «Наследовать дочерними тенантами»
Сохраните изменения

13. Ролевая модель и права доступа

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

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249270 «Удаление плейбуков»
Официальная справка Kaspersky EDR Expert 8.1, раздел 249272 «Запуск плейбуков вручную»
Официальная справка Kaspersky EDR Expert 8.1, раздел 264272 «Подтверждение плейбуков и ответных действий»
Официальная справка Kaspersky EDR Expert 8.1, раздел 303867 «Тестовый режим (эмуляция запуска плейбука)»

13.1. Роли в Kaspersky EDR Expert

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

13.1.1. Список ролей

№	Роль	Назначение
1	Главный администратор	Полный доступ ко всем функциям системы
2	Администратор тенанта	Управление конкретным тенантом
3	Администратор SOC	Администрирование центра мониторинга безопасности
4	Аналитик SOC	Анализ инцидентов и реагирование
5	Аналитик 1-го уровня	Первичная обработка алертов
6	Аналитик 2-го уровня	Углублённый анализ инцидентов
7	Менеджер SOC	Управление процессами SOC
8	Подтверждающий	Подтверждение опасных действий
9	Аудитор	Просмотр и аудит без права изменения

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел «Ролевая модель».

13.2. Таблица прав доступа к плейбукам

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

13.2.1. Создание плейбуков

Роль	Возможность создания
Главный администратор	✅ Да
Администратор тенанта	✅ Да
Администратор SOC	✅ Да
Аналитик SOC	✅ Да
Аналитик 1-го уровня	✅ Да
Аналитик 2-го уровня	✅ Да
Менеджер SOC	❌ Нет
Подтверждающий	❌ Нет
Аудитор	❌ Нет

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249267 «Создание плейбуков».

13.2.2. Изменение плейбуков

Роль	Возможность изменения
Главный администратор	✅ Да
Администратор тенанта	✅ Да
Администратор SOC	✅ Да
Аналитик SOC	✅ Да
Аналитик 1-го уровня	✅ Да
Аналитик 2-го уровня	✅ Да
Менеджер SOC	❌ Нет
Подтверждающий	❌ Нет
Аудитор	❌ Нет

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249268 «Изменение плейбуков».

13.2.3. Удаление плейбуков

Роль	Возможность удаления
Главный администратор	✅ Да
Администратор тенанта	✅ Да
Администратор SOC	❌ Нет
Аналитик SOC	❌ Нет
Аналитик 1-го уровня	❌ Нет
Аналитик 2-го уровня	❌ Нет
Менеджер SOC	❌ Нет
Подтверждающий	❌ Нет
Аудитор	❌ Нет

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249270 «Удаление плейбуков».

13.2.4. Ручной запуск плейбуков

Роль	Возможность запуска
Главный администратор	✅ Да
Администратор тенанта	✅ Да
Администратор SOC	❌ Нет
Аналитик SOC	❌ Нет
Аналитик 1-го уровня	✅ Да
Аналитик 2-го уровня	✅ Да
Менеджер SOC	❌ Нет
Подтверждающий	❌ Нет
Аудитор	❌ Нет

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 249272 «Запуск плейбуков вручную».

13.2.5. Запуск в тестовом режиме (эмуляция)

Роль	Возможность запуска
Главный администратор	✅ Да
Администратор тенанта	✅ Да
Администратор SOC	❌ Нет
Аналитик SOC	❌ Нет
Аналитик 1-го уровня	✅ Да
Аналитик 2-го уровня	✅ Да
Менеджер SOC	❌ Нет
Подтверждающий	❌ Нет
Аудитор	❌ Нет

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 303867 «Тестовый режим (эмуляция запуска плейбука)».

13.2.6. Подтверждение плейбуков и действий

Объект подтверждения	Роли с правом подтверждения
Плейбуки	Главный администратор, Аналитик 1-го уровня, Аналитик 2-го уровня, Администратор тенанта
Действия по реагированию	Главный администратор, Подтверждающий, Администратор тенанта

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 264272 «Подтверждение плейбуков и ответных действий».

13.3. Сводная таблица прав доступа

Роль	Создание и изменение	Удаление	Запуск и подтверждение плейбуков	Подтверждение опасных действий
Главный администратор	✅	✅	✅	✅
Администратор тенанта	✅	✅	✅	✅
Аналитик 1-го / 2-го уровня	✅	❌	✅	❌
Администратор SOC / Аналитик SOC	✅	❌	❌	❌
Подтверждающий	❌	❌	❌	✅
Менеджер SOC / Аудитор	❌	❌	❌	❌

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 249267, 249268, 249270, 249272, 264272, 303867.

Ключевые выводы

Только администраторы (Главный администратор и Администратор тенанта) могут удалять плейбуки.
Аналитики 1-го и 2-го уровня — самая сбалансированная роль: могут создавать, запускать и подтверждать плейбуки, но не удалять их.
Администратор SOC и Аналитик SOC могут настраивать плейбуки, но не могут их запускать. Если нужен запуск — назначьте роль «Аналитик 1-го уровня».
Роль «Подтверждающий» создана для разделения ответственности: аналитик запускает, подтверждающий одобряет опасные действия (изоляция хоста, блокировка учётной записи).

Практические рекомендации

Принцип минимальных привилегий: назначайте только необходимые права.
Разделение ответственности: для опасных действий используйте роль «Подтверждающий», отдельную от аналитика.
Частая ошибка: назначение роли «Аналитик SOC» вместо «Аналитик 1-го уровня» — первая не даёт прав на запуск плейбуков.

13.4. Описание ролей и их назначение

13.4.1. Главный администратор

Назначение: Полный контроль над системой Kaspersky EDR Expert.

Права в контексте плейбуков:

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

Когда назначать:

Руководител SOC
Главному инженеру по безопасности
Администратору с полным доступом

13.4.2. Администратор тенанта

Назначение: Управление конкретным тенантом (организацией или подразделением).

Права в контексте плейбуков:

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

Когда назначать:

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

13.4.3. Администратор SOC

Назначение: Администрирование центра мониторинга безопасности.

Права в контексте плейбуков:

Может создавать и изменять плейбуки
Не может удалять плейбуки
Не может запускать плейбуки вручную или в тестовом режиме
Не может подтверждать плейбуки или действия

Когда назначать:

Техническому специалисту, отвечающему за настройку системы
Инженеру внедрения

Особенность: Эта роль имеет ограниченную функциональность по сравнению с аналитиками. Если нужно, чтобы администратор SOC мог запускать плейбуки, рассмотрите назначение роли «Аналитик 1-го уровня» или «Аналитик 2-го уровня».

13.4.4. Аналитик SOC

Назначение: Анализ инцидентов и реагирование на угрозы.

Права в контексте плейбуков:

Может создавать и изменять плейбуки
Не может удалять плейбуки
Не может запускать плейбуки вручную или в тестовом режиме
Не может подтверждать плейбуки или действия

Когда назначать:

Аналитику, который создаёт плейбуки, но не запускает их
Специалисту по разработке сценариев реагирования

Особенность: Аналогично администратору SOC, эта роль не имеет прав на запуск. Если аналитику нужно запускать плейбуки, назначьте роль «Аналитик 1-го уровня» или «Аналитик 2-го уровня».

13.4.5. Аналитик 1-го уровня

Назначение: Первичная обработка алертов и инцидентов.

Права в контексте плейбуков:

Может создавать и изменять плейбуки
Не может удалять плейбуки
Может запускать плейбуки вручную и в тестовом режиме
Может подтверждать плейбуки (но не действия по реагированию)

Когда назначать:

Аналитику первой линии поддержки
Оператору SOC, обрабатывающему алерты
Инженеру, тестирующему плейбуки

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

13.4.6. Аналитик 2-го уровня

Назначение: Углублённый анализ инцидентов и расследование сложных угроз.

Права в контексте плейбуков:

Аналогичны роли «Аналитик 1-го уровня»
Может создавать, изменять, запускать, подтверждать плейбуки
Не может удалять плейбуки
Не может подтверждать действия по реагированию

Когда назначать:

Опытному аналитику
Специалисту по расследованию инцидентов
Старшему аналитику SOC

13.4.7. Менеджер SOC

Назначение: Управление процессами SOC, отчётность, координация работы аналитиков.

Права в контексте плейбуков:

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

Когда назначать:

Руководителю смены SOC
Менеджеру по безопасности
Специалисту по отчётности

Особенность: Эта роль предназначена для управленческих задач и не предполагает работу с плейбуками. Если менеджеру нужен доступ к плейбукам (например, для просмотра), назначьте роль «Аудитор».

13.4.8. Подтверждающий

Назначение: Подтверждение опасных действий по реагированию.

Права в контексте плейбуков:

Может подтверждать только действия по реагированию (не плейбуки)
Не может создавать, изменять, удалять, запускать плейбуки
Не может подтверждать плейбуки

Когда назначать:

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

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

13.4.9. Аудитор

Назначение: Просмотр и аудит без права изменения.

Права в контексте плейбуков:

Не имеет никаких прав на работу с плейбуками
Может только просматривать информацию (в зависимости от настроек)

Когда назначать:

Аудитору безопасности
Внешнему консультанту
Сотруднику, которому нужен только просмотр без права изменения

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

13.5. Практические рекомендации по назначению ролей

13.5.1. Принцип минимальных привилегий

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

Примеры:

Сценарий	Рекомендуемая роль	Обоснование
Аналитик только просматривает плейбуки	Аудитор	Не нужно право изменения или запуска
Аналитик создаёт плейбуки, но не запускает	Аналитик SOC	Достаточно прав на создание и изменение
Аналитик создаёт и тестирует плейбуки	Аналитик 1-го уровня	Нужны права на запуск в тестовом режиме
Аналитик запускает плейбуки в продуктивной среде	Аналитик 1-го уровня или 2-го уровня	Нужны права на ручной запуск
Аналитик подтверждает опасные действия	Подтверждающий	Специализированная роль для подтверждения
Администратор управляет тенантом	Администратор тенанта	Полный контроль в рамках тенанта
Руководитель SOC	Главный администратор	Полный доступ ко всем функциям

13.5.2. Разделение ответственности

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

Пример 1: Изоляция хоста

Этап	Роль	Действие
1. Обнаружение угрозы	Аналитик 1-го уровня	Запуск плейбука для изоляции
2. Подтверждение изоляции	Подтверждающий	Одобрение опасного действия
3. Выполнение изоляции	Система	Автоматическое выполнение после подтверждения

Пример 2: Блокировка учётной записи

Этап	Роль	Действие
1. Обнаружение компрометации	Аналитик 2-го уровня	Запуск плейбука для блокировки
2. Подтверждение блокировки	Подтверждающий	Одобрение блокировки учётной записи
3. Выполнение блокировки	Система	Автоматическое выполнение после подтверждения

13.5.3. Типовые конфигурации ролей

Конфигурация 1: Малый SOC (3-5 человек)

Пользователь	Роль	Обоснование
Руководитель SOC	Главный администратор	Полный контроль
Старший аналитик	Аналитик 2-го уровня + Подтверждающий	Анализ и подтверждение
Аналитик 1	Аналитик 1-го уровня	Первичная обработка
Аналитик 2	Аналитик 1-го уровня	Первичная обработка

Конфигурация 2: Средний SOC (10-15 человек)

Пользователь	Роль	Обоснование
Руководитель SOC	Главный администратор	Полный контроль
Администратор SOC	Администратор SOC	Настройка системы
Старшие аналитики (2-3 чел.)	Аналитик 2-го уровня	Углублённый анализ
Аналитики (5-7 чел.)	Аналитик 1-го уровня	Первичная обработка
Подтверждающие (2 чел.)	Подтверждающий	Одобрение опасных действий
Аудитор	Аудитор	Внешний аудит

Конфигурация 3: Крупный SOC (20+ человек)

Пользователь	Роль	Обоснование
Руководитель SOC	Главный администратор	Полный контроль
Администраторы тенантов (по тенантам)	Администратор тенанта	Управление тенантами
Администраторы SOC (2-3 чел.)	Администратор SOC	Настройка системы
Старшие аналитики (5-7 чел.)	Аналитик 2-го уровня	Углублённый анализ
Аналитики 1-й линии (10-15 чел.)	Аналитик 1-го уровня	Первичная обработка
Подтверждающие (3-5 чел.)	Подтверждающий	Одобрение опасных действий
Менеджеры SOC (2-3 чел.)	Менеджер SOC	Управление процессами
Аудиторы (2-3 чел.)	Аудитор	Внешний аудит

13.5.4. Частые ошибки при назначении ролей

Ошибка 1: Назначение роли «Аналитик SOC» вместо «Аналитик 1-го уровня»

Проблема: Аналитик не может запускать плейбуки вручную или в тестовом режиме.

Решение: Если аналитику нужно запускать плейбуки, назначьте роль «Аналитик 1-го уровня» или «Аналитик 2-го уровня».

Ошибка 2: Назначение роли «Главный администратор» всем пользователям

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

Решение: Назначайте роль «Главный администратор» только тем, кому действительно нужен полный доступ.

Ошибка 3: Отсутствие роли «Подтверждающий»

Проблема: Аналитики сами подтверждают опасные действия, что создаёт риск ошибочных решений.

Решение: Назначьте роль «Подтверждающий» независимому специалисту или руководителю для разделения ответственности.

Ошибка 4: Назначение роли «Менеджер SOC» аналитикам

Проблема: Аналитики не имеют доступа к плейбукам вообще.

Решение: Роль «Менеджер SOC» предназначена для управленческих задач. Для аналитиков используйте «Аналитик 1-го уровня» или «Аналитик 2-го уровня».

13.6. Проверка прав доступа

13.6.1. Как проверить права пользователя

Шаг 1. Войти в Консоль OSMP под учётной записью администратора.

Шаг 2. Перейти в раздел Администрирование → Пользователи.

Шаг 3. Найти нужного пользователя и открыть его свойства.

Шаг 4. Проверить назначенные роли в разделе «Роли».

13.6.2. Как назначить роль

Шаг 1. Перейти в раздел Администрирование → Пользователи.

Шаг 2. Выбрать пользователя и нажать «Изменить».

Шаг 3. В разделе «Роли» выбрать необходимые роли.

Шаг 4. Нажать «Сохранить».

13.6.3. Как проверить доступ к плейбукам

Шаг 1. Войти в Консоль OSMP под учётной записью проверяемого пользователя.

Шаг 2. Перейти в раздел Мониторинг → Плейбуки.

Шаг 3. Проверить доступные действия:

Видна ли кнопка «Создать»?
Видна ли кнопка «Изменить»?
Видна ли кнопка «Удалить»?
Можно ли запустить плейбук вручную?
Можно ли запустить в тестовом режиме?

14. Типичные ошибки и их решение

В этом разделе разберём наиболее частые ошибки, возникающие при создании и эксплуатации плейбуков в Kaspersky EDR Expert. Информация основана на официальной документации и практическом опыте команды pre-sales и AntiAPT Community.

ℹ️ Источники информации:

Официальная справка Kaspersky EDR Expert 8.1, разделы 267548, 273327
Примеры из предустановленных плейбуков [KL] (разделы 271609–324934)
Практический опыт команды pre-sales и AntiAPT Community

14.1. Сводная таблица типичных ошибок

№	Ошибка	Симптом	Причина	Решение
1	Несоответствие области действия	Ошибка валидации jq-выражения	Используется `alert.*` в плейбуке с областью «Инцидент» (или наоборот)	Использовать ключевое слово, соответствующее области действия
2	Неправильный регистр полей	Пустой результат или ошибка	`assets` вместо `Assets`, `type` вместо `Type`	Использовать регистр из официальной документации
3	Отсутствие `any()` для массивов	Ошибка выполнения триггера	Сравнение с массивом без обёртки `[...] \| any`	Обернуть выражение в `[...] \| any`
4	Префикс в триггере	Ошибка валидации	Использование `alert.` или `incident.` в триггере	В триггере обращаться без префикса: `.Severity`
5	Отсутствие префикса в алгоритме	Ошибка выполнения	Обращение к `.Severity` вместо `alert.Severity` в алгоритме	В алгоритме использовать полные пути: `alert.Severity`
6	Тяжёлые поля в триггере	Деградация производительности	Использование `OriginalEvents`, `Observables` в триггере	Использовать лёгкие поля или выносить проверку в алгоритм
7	Пустой массив активов	Действие не выполняется	В алерте/инциденте нет хостов или пользователей	Добавить проверку `length > 0` перед действием
8	Истечение времени подтверждения	Статус «Истекло время подтверждения»	Аналитик не подтвердил запуск вовремя	Увеличить `timeout` или настроить email-уведомления
9	Объекты игнорируются при ручном запуске	Действие выполняется без выбранных объектов	В алгоритме нет обращения к `.input.assets`	Добавить jq-выражения для `.input.assets` и `.input.observables`
10	Синтаксические ошибки JSON	Ошибка парсинга алгоритма	Незакрытые скобки, неэкранированные кавычки	Проверить JSON через валидатор

14.2. Ошибка 1: Несоответствие области действия

Симптом

При сохранении плейбука система выдаёт ошибку валидации jq-выражения. Либо плейбук сохраняется, но не выполняется.

Причина

В плейбуке с областью действия «Алерт» используется ключевое слово incident, или наоборот.

Пример неправильного кода:

Плейбук с областью «Алерт», но в алгоритме:

incident.Alerts[].Assets[]

Решение

Использовать ключевое слово, соответствующее области действия:

Область действия	Ключевое слово
Алерт	`alert`
Инцидент	`incident`

Правильный код:

Для плейбука с областью «Алерт»:

alert.Assets[]

Для плейбука с областью «Инцидент»:

incident.Alerts[].Assets[]

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 267548 «Алгоритм плейбука».

14.3. Ошибка 2: Неправильный регистр полей

Симптом

jq-выражение выполняется без ошибок, но возвращает пустой результат. Или система выдаёт ошибку «Поле не найдено».

Причина

Kaspersky EDR Expert чувствителен к регистру. Assets и assets — это разные поля.

Пример неправильного кода:

alert.assets[]
select(.type == "host")
.Observables[].value

Решение

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

Неправильно	Правильно
`alert.assets[]`	`alert.Assets[]`
`.type == "host"`	`.Type == "host"`
`.value`	`.Value`
`incident.alerts[]`	`incident.Alerts[]`
`.id`	`.ID`

Правильный код:

alert.Assets[] | select(.Type == "host") | .ID

Особый случай: операционные данные

В операционных данных (.input) имена полей задаются разработчиком плейбука. В примерах документации обычно используется строчный регистр:

.input.assets[]
.input.observables[]

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, разделы 269125, 269168.

14.4. Ошибка 3: Отсутствие `any()` для массивов

Симптом

Триггер не срабатывает или система выдаёт ошибку: «Ожидается булево значение, получен массив».

Причина

При сравнении элемента массива со значением jq возвращает несколько результатов (по одному для каждого элемента). Система не может интерпретировать это как условие.

Пример неправильного кода:

.DetectionTechnologies[] == "SB"

Это выражение вернёт [false, true, false] для массива из трёх элементов, а не одно булево значение.

Решение

Обернуть выражение в [...] | any или использовать функцию any(...; ...):

Вариант 1:

[.DetectionTechnologies[] | . == "SB"] | any

Вариант 2 (более короткий):

any(.DetectionTechnologies[]; . == "SB")

Пример из документации ([KL] P004):

event.new and .Severity == "medium" and any(.DetectionTechnologies[] == "SB"; .)

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271772 «[KL] P004».

14.5. Ошибка 4: Префикс в триггере

Симптом

Ошибка валидации: «Выражение не соответствует выбранной области действия».

Причина

В триггере используется префикс alert. или incident., хотя в триггере контекстом является сам алерт/инцидент, и префикс не нужен.

Пример неправильного кода:

Триггер для плейбука с областью «Алерт»:

alert.Severity == "critical"

Решение

В триггере обращаться к полям без префикса:

Правильный код:

.Severity == "critical"

Примеры из документации:

Триггер [KL] P001 (область «Алерт»):

[.OriginalEvents[] | .ExternalID == "R350"] | any

Триггер [KL] P002 (область «Инцидент»):

[.Alerts[] | .OriginalEvents[] | .ExternalID == "R050"] | any

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

14.6. Ошибка 5: Отсутствие префикса в алгоритме

Симптом

Ошибка выполнения: «Поле не найдено» или «Неизвестное ключевое слово».

Причина

В алгоритме (executionFlow) используется обращение без префикса, хотя в алгоритме нужно явно указывать alert или incident.

Пример неправильного кода:

Алгоритм плейбука с областью «Алерт»:

.Assets[] | select(.Type == "host") | .ID

Решение

В алгоритме использовать полные пути с префиксом:

Правильный код:

alert.Assets[] | select(.Type == "host") | .ID

Пример из документации ([KL] P003):

{
  "action": {
    "function": {
      "type": "killProcess",
      "assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}"
    }
  }
}

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 271611 «[KL] P003».

14.7. Ошибка 6: Тяжёлые поля в триггере

Симптом

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

Причина

В триггере используются поля с большим объёмом данных: OriginalEvents, Observables, Extra, Alerts (для инцидентов).

Решение

Согласно официальной документации, не рекомендуется использовать эти поля в триггерах. Вместо этого:

Тяжёлое поле	Альтернатива
`OriginalEvents`	`BaseEvents` или обогащённые поля
`Observables`	`ScannedFiles` или `DetectionTechnologies`
`Extra`	Основные поля алерта/инцидента
`Alerts` (для инцидентов)	Агрегированные поля инцидента

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

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 273327 «Триггер плейбука».

14.8. Ошибка 7: Пустой массив активов

Симптом

Действие не выполняется. В «История реагирований» статус «Успешно», но действие не применено ни к одному объекту.

Причина

В алерте или инциденте нет хостов или пользователей, соответствующих фильтру. jq-выражение возвращает пустой массив [].

Пример:

[alert.Assets[] | select(.Type == "host") | .ID]

Если в алерте нет хостов, результат будет [], и действие не применится.

Решение

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

{
  "decision": {
    "conditions": [
      {
        "condition": "${[alert.Assets[] | select(.Type == \"host\") | .ID] | length > 0}",
        "name": "has hosts",
        "steps": [
          {
            "action": {
              "function": {
                "type": "isolateHost",
                "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}"
              }
            }
          }
        ]
      }
    ]
  }
}

Пример из документации ([KL] "Playbook for isolating a device where an infected file is detected"):

((.input.assets // []) | length) > 0

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 324933.

14.9. Ошибка 8: Истечение времени подтверждения

Симптом

Плейбук в режиме «Обучение» или с manualApprove не выполняется. Статус в «История реагирований» — «Истекло время подтверждения».

Причина

Аналитик не подтвердил запуск в течение заданного времени (по умолчанию 60 минут).

Решение

Вариант 1: Увеличить время подтверждения

{
  "manualApprove": {
    "timeout": "4h"
  }
}

Вариант 2: Настроить email-уведомления

{
  "manualApprove": {
    "timeout": "60m",
    "emailNotifications": {
      "enabled": true,
      "delay": "10m"
    }
  }
}

Вариант 3: Назначить ответственных аналитиков

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

14.10. Ошибка 9: Объекты игнорируются при ручном запуске

Симптом

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

Причина

В алгоритме плейбука нет обращения к .input.assets и .input.observables. Плейбук использует глобальные данные (alert.Assets[] или incident.Alerts[].Assets[]), игнорируя выбранные объекты.

Решение

Использовать jq-выражения для обращения к операционным данным:

Пример из документации:

${ "-ip " + ([.input.observables[] | select(.type == "ip")] | map(.value) | join(",")) }

Важно: в операционных данных используется строчный регистр (.type, .value), а не заглавный (.Type, .Value).

ℹ️ Источник: Официальная справка Kaspersky EDR Expert 8.1, раздел 281686 «Запуск для выбранных объектов».

14.11. Ошибка 10: Синтаксические ошибки JSON

Симптом

Ошибка парсинга алгоритма: «Invalid JSON» или «Unexpected token».

Причина

Незакрытые скобки, неэкранированные кавычки, пропущенные запятые в JSON-коде алгоритма.

Пример неправильного кода:

{
  "action": {
    "function": {
      "type": "deleteFile",
      "assets": "${[alert.Assets[] | select(.Type == "host") | .ID]}"
    }
  }
}

Здесь кавычки внутри jq-выражения не экранированы.

Решение

Экранировать кавычки внутри jq-выражений:

Правильный код:

{
  "action": {
    "function": {
      "type": "deleteFile",
      "assets": "${[alert.Assets[] | select(.Type == \"host\") | .ID]}"
    }
  }
}

Проверка JSON:

Использовать валидатор JSON (например, https://jsonlint.com)
Проверить все скобки на парность
Убедиться, что все строки в кавычках
Проверить экранирование кавычек внутри jq-выражений (\")

14.12. Чек-лист для самопроверки

Перед публикацией плейбука выполните следующие проверки:

Проверка синтаксиса

Все jq-выражения проходят проверку синтаксиса (нет красной подсветки)
JSON-код алгоритма проходит валидацию
Все скобки парные
Все кавычки внутри jq-выражений экранированы (\")

Проверка области действия

В триггере используется обращение без префикса (.Severity, а не alert.Severity)
В алгоритме используется префикс, соответствующий области действия (alert.* или incident.*)
Для инцидента используется incident.Alerts[].Assets[], а не incident.Assets[]

Проверка регистра

Все имена полей написаны с правильным регистром (проверка по таблицам из Раздела 5)
В глобальных данных используется заглавный регистр (Assets, Observables, Type, Value)
В операционных данных используется строчный регистр (если следуете соглашению)

Проверка работы с массивами

Все сравнения с элементами массивов обёрнуты в [...] | any
Добавлены проверки на непустоту массивов перед выполнением действий
Используется | unique для дедупликации, если нужно

Проверка производительности

В триггере не используются тяжёлые поля (OriginalEvents, Observables, Extra) без необходимости
Для длительных операций увеличен playbookRunTimeout
Протестирована производительность на реальных данных

Проверка в тестовом режиме

Плейбук запущен в тестовом режиме на реальном алерте/инциденте
Результаты в «История реагирований» свойств плейбука показывают ожидаемое поведение
Все jq-выражения возвращают корректные данные
Действия применяются к правильным объектам

Проверка в режиме «Обучение»

Плейбук переведён в режим «Обучение»
При появлении соответствующего алерта/инцидента создаётся запрос на подтверждение
После подтверждения плейбук выполняется успешно
В «История реагирований» отображается статус «Успешно»

Проверка интеграций

Для действий Active Directory настроена интеграция с AD
Для действия iocsEnrichment настроена интеграция с Kaspersky TIP
Для действия assignKasapGroup настроена интеграция с KASAP и указан реальный groupId
На целевых хостах установлены агенты KES/KATA

Проверка ролей

У аналитиков есть необходимые роли для запуска плейбука
У аналитиков есть необходимые роли для подтверждения (если настроено manualApprove)
Настроены email-уведомления для быстрого подтверждения

Миграция

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

ℹ️ Информация:

Приведенная на данной странице информация подготовлена на основании документации Kaspersky EDR Expert 8.1 и практического опыта внедрения решений Kaspersky.
Материал не является официальной инструкцией производителя и предназначен для упрощения планирования и выполнения миграции.

Официальная документация: Kaspersky EDR Expert 8.1

Переход с KEDR 7.1 на Kaspersky EDR Expert 8.1 представляет собой полноценную процедуру миграции, позволяющую перенести накопленные данные и основные объекты конфигурации в новую инфраструктуру.

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

При обновлении и переходе с KEDR 7.1 на Kaspersky EDR Expert 8.1 переносятся следующие данные:

Настройка SSH-доступа между серверами (для сценария без внешнего хранилища)

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

Данные алертов
Дополнительные данные алертов
- Хранилище 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-алерты, связанные с правилами, не соответствующими этим стандартам, не переносятся. Информация о таких алертах отображается в журнале ошибок миграции.

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

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

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

ℹ️ Важно: Переход на Kaspersky EDR Expert 8.1 не является обновлением "поверх" существующей установки KEDR 7.1. Процесс выполняется путем экспорта данных из существующей системы и их последующего импорта в новую инфраструктуру.

Поддерживаемые сценарии миграции

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

Переход с использованием того же сервера; - Существующий сервер KEDR 7.1 переиспользуется для установки Kaspersky EDR Expert 8.1.
Переход с использованием отдельного сервера; - Разворачивается новый сервер с Kaspersky EDR Expert 8.1, после чего выполняется перенос данных из KEDR 7.1.
Переход в распределенной инфраструктуре; - Используется, если KEDR 7.1 уже развернут как распределенное решение. В этом случае миграция выполняется с сохранением распределенной архитектуры.
Разделение KATA и Kaspersky EDR Expert; - Этот сценарий предназначен для случаев, когда вместо единой платформы необходимо получить два отдельных решения:
- KATA 8.0;
- Kaspersky EDR Expert 8.1.

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

Предварительная подготовка

1. Перед началом миграции рекомендуется обновить Endpoint Agent до последних поддерживаемых версий.

Важно: Поддержка передачи телеметрии, необходимой для работы Kaspersky EDR Expert 8.1, реализована только в актуальных версиях Endpoint Agent начиная с KES 12.12 и KESL 12.4. Использование устаревших версий может привести к некорректной работе решения после миграции.

2. Запросить в технической поддержке файлы инсталляционных пакетов и набор пакетов для переноса данных с KATA/KEDR 7.1 состоящий из:

Набор пакетов для инсталляции:
- Пакет развёртывания (KDT): bin.tar.gz
- Сборка KEDR 8+: xdr-2.+-ru.tar (Обратите внимание, что дистрибутив (файл вида xdr-2.0.6xx-yy.tar) отличается в зависимости от локализации).
- Дистрибутив Sandbox
- Образы Sandbox
- Плагины:
  - KES Mac CNAB plugin
  - KES Linux CNAB plugin
  - MDR (по запросу)
  - KICS for Nodes (по запросу)
Набор пакетов для миграции:
- img_kata_osmp_migrate.tar
- img_kata_osmp_migration_importer.tar
- kata-osmp-export.sh
- kata-osmp-import.sh
- gateway-migration_v2.0.+.tar

Обратите внимание, что перенос данных (настройки, правила, алерты, телеметрия) с предыдущей версии KEDR Expert 7.1 в KEDR Expert 8 возможен только на версию 8.0.1 и выше с помощью утилиты миграции. Для переноса телеметрии необходима временная лицензия на XDR! (запрашивается через саппорт), подробнее по ссылке.

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

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

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

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

Данные в 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`	Размер хранилища объектов (S3).	Веб-интерфейс KATA 7.1: значение, указанное в поле «Хранилище, ГБ» при настройке Central Node.
`N_ioa_alerts`	Количество поведенческих алертов (IOA).	Запрос к PostgreSQL: `SELECT count(*) FROM ioa_alerts;`
`N_ioc_alerts`	Количество алертов по IOC.	Запрос к PostgreSQL: `SELECT count(*) FROM ioc_scan_ep_alert;`
`N_ext_alerts`	Количество внешних алертов (SIEM/TI).	Запрос к БД. Если интеграций нет — значение `0`.

Пример расчета:
Вводные: 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 должен иметь свободные ресурсы для распаковки архивов и записи в БД.

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

Ресурс	Значение	Назначение
CPU	4 ядра	Обработка скрипта импорта.
RAM	4 ГБ	Буферы обработки потоков данных.
Disk	`Storage_GB`	Свободное место для записи объектов S3.

Правило масштабирования: При планировании постоянного дискового пространства на новом сервере выделите вдвое больше места, чем рассчитано по «Руководству по масштабированию». Это необходимо для стабильной работы баз данных и сервисов 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 дней.

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

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

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

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

Параметр	Сценарий А: С внешним хранилищем	Сценарий Б: Без внешнего хранилища
Суть процесса	Телеметрия выгружается в `.dump` файлы на внешний SSD, затем импортируется через коллектор KUMA типа `file`.	Телеметрия передаётся напрямую из старого Elasticsearch в новый через коллектор KUMA типа `elastic` по сети.
Требования к внешнему диску	Высокие. SSD RAID 0, ~1 ГБ/сек, объем = `ES_Data_Volume * 2.6`.	Низкие. Диск нужен только для базовой миграции (алерты + S3).
Доп. ресурсы CPU/RAM на OSMP	+18 ядер, +12 ГБ RAM (при скорости 40 000 EPS).	От +6 до +12 ядер, от +4 до +8 ГБ RAM (зависит от числа индексов).
Требования к сети	Не критичны.	Высокая пропускная способность между старым KATA и новым OSMP.
Настройка старого KATA	Не требуется.	Необходимо открыть внешний порт Elasticsearch.
Совместимость со Сценарием 1 (Тот же сервер)	Совместимо.	НЕСОВМЕСТИМО. Развертывание OSMP на том же сервере, где был KEDR 7.1, невозможно.
Когда выбирать	Большой парк, медленная сеть, есть быстрый SSD-массив.	Быстрая сеть (10 Гбит/с+), нет свободного SSD, готовность выделить CPU/RAM.

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

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

Количество индексов	Скорость передачи	Доп. CPU на OSMP	Доп. RAM на OSMP
1 индекс	9 000 EPS	+ 6 ядер	+ 4 ГБ
5 индексов	20 000 EPS	+ 12 ядер	+ 8 ГБ

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

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

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

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

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

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

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

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

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

Подробный разбор обоих сценариев приведён в разделе 4 выше (внутри блока «Требования к аппаратному обеспечению»).

5. Настройка SSH-доступа между серверами

Настройка SSH-доступа между серверами (для сценария без внешнего хранилища)

Если вы выбрали Сценарий Б: Перенос телеметрии без внешнего хранилища и планируете добавить отдельный сервер в кластер KUMA для установки коллектора, необходимо заранее настроить SSH-доступ без пароля между сервером управления KUMA и целевыми серверами.

Важно: Этот шаг обязателен для выполнения команд ./kdt invoke kuma --action addHosts и установки коллектора на удаленные серверы. Без настроенного SSH-доступа эти команды не выполнятся, и вы получите ошибку аутентификации.

5.1. Когда требуется этот шаг

Сценарий	Требуется настройка SSH?
Сценарий А: Телеметрия с внешним хранилищем	Не требуется
Сценарий Б: Телеметрия без внешнего хранилища (коллектор на отдельном сервере)	Обязательно
Сценарий Б: Телеметрия без внешнего хранилища (коллектор на OSMP)	Не требуется

5.2. Генерация SSH-ключа (без парольной фразы)

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

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""

Параметры команды:

-t rsa — тип ключа RSA
-b 4096 — длина ключа 4096 бит (рекомендуется для безопасности)
-f ~/.ssh/id_rsa — путь к файлу ключа
-N "" — пустая парольная фраза (обязательно для автоматизированных операций KUMA)

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

5.3. Копирование ключа на целевые устройства

Скопируйте публичный ключ на все целевые серверы, которые будут добавлены в кластер KUMA:

ssh-copy-id username@<IP_целевого_устройства>

Повторите команду для каждого целевого сервера.

💡 Пример: Если у вас есть два целевых сервера с IP 192.168.1.10 и 192.168.1.11, выполните:

ssh-copy-id admin@192.168.1.10
ssh-copy-id admin@192.168.1.11

5.4. Проверка подключения без пароля

Убедитесь, что подключение работает без запроса пароля:

ssh username@<IP_целевого_устройства> "sudo whoami"

Если команда выполнилась без запроса пароля и вернула имя пользователя (например, root) — настройка успешна.

5.5. Особые случаи

При установке от учётной записи root:

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

/root/.ssh/authorized_keys

Проверьте права доступа к файлу:

chmod 600 /root/.ssh/authorized_keys
chmod 700 /root/.ssh

Критически важно: Неправильные права доступа к файлу authorized_keys приведут к отказу SSH в подключении. Файл должен принадлежать пользователю root и иметь права 600.

Для закрытых контуров (Astra Linux SE):

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

На целевых серверах установлен пакет openssh-server
Служба SSH запущена: sudo systemctl status ssh
Файрвол разрешает подключения на порт 22

Проверка установки openssh-server:

dpkg -l | grep openssh-server

Если пакет не установлен, установите его из локального репозитория:

sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh

5.6. Чек-лист проверки

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

SSH-ключ сгенерирован на сервере управления KUMA
Публичный ключ скопирован на все целевые серверы
Подключение без пароля проверено для каждого сервера
Права доступа к файлам authorized_keys корректны (600)
Служба SSH запущена на всех целевых серверах
Файрвол разрешает подключения на порт 22

💡 Совет: Сохраните приватный ключ (~/.ssh/id_rsa) в безопасном месте. Он понадобится для повторного добавления серверов в кластер KUMA в случае необходимости.

6. Определите сценарий миграции:

Выбор сценария миграции

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

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

Сценарий	Суть процесса	Преимущества	Недостатки и влияние на простой
1. Тот же сервер	OSMP развертывается на существующем сервере KEDR 7.1 после завершения экспорта. Старый KEDR 7.1 удаляется с диска.	Экономия аппаратных ресурсов (не нужна новая VM).	Существенный простой. Сервер недоступен на время экспорта, удаления и установки. Несовместим с переносом телеметрии без внешнего хранилища (см. раздел 3.4).
2. Отдельный сервер (Рекомендуемый)	Экспорт данных со старого сервера и импорт на новый (заранее развернутый) сервер OSMP.	Минимальный простой. Старый сервер продолжает работать, пока идет импорт.	Требует выделения отдельного сервера/VM под OSMP.
3. Распределенное решение	Миграция кластера (PCN + SCN + Embedded SCN) с сохранением распределенной архитектуры.	Сохранение кластерной топологии и иерархии данных.	Сложность. Требуется маппинг тенантов между узлами и строгая очередность.
4. Разделение на два решения	Переход с единого KATA/KEDR 7.1 на KATA 8.0 (платформа) + Kaspersky EDR Expert 8.1 (EDR).	Архитектурное разделение функций SIEM и EDR.	Требует развертывания двух систем и перераспределения ресурсов (в т.ч. Sandbox).

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

Сценарий 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 дней.

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

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

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

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

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

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

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

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

Подробное руководство: Пошаговая инструкция по маппингу тенантов, включая узнавание структуры кластера KATA, создание тенантов в OSMP, правила маппинга, частые ошибки и чек-лист, приведена в разделе Этап 2 → подраздел 2.4.1.4 "Добавление тенантов". Рекомендуем ознакомиться с ней перед началом миграции кластера.

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

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

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

Развертывание нового сервера Kaspersky EDR Expert 8.1.
Перенос данных EDR из KATA 7.1 в новый Kaspersky EDR Expert 8.1.
Обновление старой KATA 7.1 до версии 8.0.
Критически важно: После обновления KATA до 8.0 функциональность и данные KEDR на этом сервере станут недоступны.
Переключение серверов 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:

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

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

7. Подготовка внешнего хранилища и выбор между Физическим диском или Сетевым хранилищем.

Выбора варианта хранилища

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

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

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

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

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

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

Подключите физический жесткий диск к хосту и установите его системное имя.
Найдите диск по размеру с помощью вывода команды:
```
lsblk
sudo fdisk -l
```
Пример найденного устройства: /dev/sdb1
Смените формат устройства на файловую систему Ext4, чтобы подготовить диск к записе данных:
```
sudo mkfs.ext4 /dev/<disk>
```
ВНИМАНИЕ: Эта команда полностью удалит все данные с диска!
Чтобы создать точку монтирования, создайте пустую директорию, в которую будет монтироваться диск:
```
sudo mkdir -p /mnt/external_disk
```
Выполните следующую команду (зависит от файловой системы диска):
```
sudo mount /dev/<диск> /mnt/external_disk
```

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

sudo umount /mnt/external_disk

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

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

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

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

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

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

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

Добавьте пользователя Samba с созданием домашней папки для этого пользователя. Эта папка будет служить общей папкой.
Важно: Не создавайте общую папку вручную от имени текущего пользователя. Это необходимо сделать с помощью следующей команды:
```
sudo useradd -m -d /home/<SHARE_FOLDER> -s /bin/bash <USER_NAME>
```
Задайте пароль и активируйте пользователя:
```
sudo smbpasswd -a <USER_NAME>
sudo smbpasswd -e <USER_NAME>
```
Добавьте следующий блок в файл конфигурации /etc/samba/smb.conf:
```
[<SHARE_FOLDER>]
comment = Сетевой ресурс
path = /home/<SHARE_FOLDER>
read only = no
browseable = yes
guest ok = no
```
где SHARE_FOLDER – имя общей директории.
Перезапустите сервис:
```
sudo systemctl restart smbd nmbd
```

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

Убедитесь, что консоль запущена от имени администратора.
Создайте пользователя и задайте пароль:
```
net user <USER_NAME> <PASSWORD> /add /expires:never
```

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

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

Создайте общий ресурс для пользователя:
```
net share <SHARE_NAME>=<SHARE_FOLDER> /grant:<USER_NAME>,full
```

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

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

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

Скачайте и установите следующие три пакета:
- 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 из общедоступных репозиториев или из частных репозиториев, поддерживаемых вашей организацией.
Создайте точку монтирования:
```
sudo mkdir -p <PATH_FOLDER>
```
Монтируйте сетевой ресурс:
```
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

8. Подготовка к переносу телеметрии без внешнего хранилища (опционально)

Сценарий Б: Перенос телеметрии без внешнего хранилища (напрямую через сеть)

Если вы планируете переносить сырую телеметрию (Этап 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. Проанализируйте вывод команды. Пример вывода:

Шаг 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-сервера для коллектора:

Количество индексов Elasticsearch	Скорость передачи	Ресурсы для отдельного хоста
1 индекс	9 000 EPS	5 ядер CPU, 1 ГБ RAM
5 индексов	20 000 EPS	10 ядер CPU, 1 ГБ RAM

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

Количество индексов Elasticsearch	Доп. CPU на OSMP	Доп. RAM на OSMP
1 индекс	+ 2 ядра	+ 4 ГБ
5 индексов	+ 4 ядра	+ 8 ГБ

💡 Совет: Если вы не хотите выделять отдельный сервер, можно установить коллектор прямо на узел 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, мониторинг, завершение миграции).

9. Поместите на хост с KATA/KEDR 7.1 необходимые файлы:

архив содержащего образ Docker для экспорта img_kata_osmp_migrate.tar
скрипт экспорта данных kata-osmp-export.sh

Рекомендация: Также рекомендуется завершить активные расследования и переносить преимущественно алерты со статусом «Закрыто», что позволит избежать несогласованности данных и упростит последующую проверку результатов миграции.

Этап 1. Экспорт данных из KATA/KEDR 7.1

На этом этапе мы подготовим архив миграции, содержащий все необходимые данные из старого решения KATA/KEDR 7.1. Этот архив будет использоваться на Этапе 2 для импорта в новый Kaspersky EDR Expert 8.1.

ℹ️ Важно: Процесс экспорта разделен на три этапа (steps), что позволяет минимизировать риски, правильно подготовить инфраструктуру к переключению и при необходимости перенести историческую телеметрию.

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

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

Завершен раздел «Предварительная подготовка» (обновлены 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, менять их группы и теги
Изменять список паролей архивов

1.2. Размещение скриптов и Docker-образов на сервере KATA/KEDR

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

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

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

chmod +x kata-osmp-export.sh

1.3. Запуск экспорта первого этапа (Step First)

На этом шаге экспортируются данные, необходимые для запуска 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.4. Подготовка ко второму этапу экспорта

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

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

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

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

1.5. Запуск экспорта второго этапа (Step Second)

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

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

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

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

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

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

1.6. Запуск экспорта третьего этапа (Step Third) — Опционально

Этот шаг выполняется только если вы планируете перенести историческую телеметрию и выбрали соответствующий сценарий в разделе 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 используйте формулу расчета из раздела «Требования для переноса телеметрии».

1.7. Отключение внешнего диска от сервера KEDR 7.1

После успешного завершения всех необходимых этапов экспорта, в режиме 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

1.8. Подготовка сервера KATA для переноса телеметрии без внешнего хранилища (опционально)

Если вы выбрали Сценарий Б: Перенос телеметрии без внешнего хранилища (напрямую через сеть), необходимо подготовить старый сервер 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

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

Для сценария с внешним хранилищем:

Скрипты и Docker-образы размещены на сервере KATA
Выполнен экспорт первого этапа (Step First)
Отключены внешние интеграции и Endpoint Agent
Выполнен экспорт второго этапа (Step Second)
(Опционально) Выполнен экспорт третьего этапа (Step Third)
Внешнее хранилище безопасно отключено

Для сценария без внешнего хранилища (телеметрия):

Все вышеперечисленные действия выполнены
Проверены необходимые файлы на сервере KATA
Создана директория /home/admin/elastic_script_dir
Загружен Docker-образ kata_osmp_migrate
Сгенерирован скрипт и получены учетные данные Elasticsearch
Открыт внешний доступ к Elasticsearch
Получен список индексов для последующего импорта

Этап 2. Импорт данных в Kaspersky EDR Expert 8.1

На этом этапе мы импортируем данные из архива миграции в новый Kaspersky EDR Expert 8.1 (OSMP). Процесс импорта выполняется с помощью отдельного Linux-сервера, который выступает в роли «шлюза» между архивом и целевой системой.

ℹ️ Важно: Процесс импорта, как и экспорт, разделен на этапы (steps), что позволяет минимизировать время простоя и правильно переключить агентов Endpoint Agent на новую систему.

Критическое правило: Скрипт импорта (kata-osmp-import.sh) не может выполняться на том же сервере, где развернут Kaspersky EDR Expert 8.1. Вам потребуется отдельный Linux-сервер с установленным Docker для выполнения импорта.

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

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

Завершен Этап 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)
Удалить KEDR 7.1 с диска
Развернуть OSMP на этом же сервере
Подготовить отдельный временный Linux-сервер для импорта
Выполнить импорт (Этап 2)

2.2. Подготовка сервера Linux для импорта

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

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

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

Ресурс	Минимальное значение
ОС	Linux (рекомендуется Astra Linux, Ubuntu, Debian)
Docker	Установлен и запущен
CPU	4 ядра (для базового импорта)
RAM	4 ГБ (для базового импорта)
Диск	Свободное место, равное размеру архива миграции

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

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

docker --version

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

2.3. Размещение скриптов импорта на сервере Linux

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

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

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

chmod +x kata-osmp-import.sh

2.4. Подключение внешнего хранилища к серверу импорта

Подключите внешнее хранилище с архивом миграции к серверу импорта. Используйте те же команды монтирования, что и на Этапе 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, в которые будут импортированы данные из KATA/KEDR 7.1.

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

Если у вас был развернут одиночный узел KATA/KEDR 7.1 (без кластера PCN + SCN), выполните следующие действия:

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

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

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

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

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

--tenant-name "Root tenant"

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

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

Если у вас был развернут кластер KATA (PCN + SCN), необходимо выполнить маппинг тенантов — сопоставить узлы старого кластера с тенантами в новой OSMP.

Шаг 1. Узнайте структуру кластера KATA 7.1

Подключитесь к серверу KATA 7.1 и выполните команду для получения списка узлов:

kubectl get nodes

Пример вывода:

NAME              STATUS   ROLES    AGE
pcn-node          Ready    master   365d
scn-node-1        Ready    worker   365d
scn-node-2        Ready    worker   365d

Запомните имена узлов — они понадобятся для составления tenant_config.json.

Шаг 2. Определите тенанты на каждом узле

В веб-интерфейсе KATA 7.1:

Перейдите в Настройки → Тенанты.
Для каждого узла (PCN и SCN) посмотрите, какие тенанты на нем размещены.

Пример структуры кластера KATA 7.1:

PCN (pcn-node):
  ├── Root tenant (корневой)
  └── Finance

SCN-1 (scn-node-1):
  ├── HR
  └── IT

SCN-2 (scn-node-2):
  └── Sales

💡 Совет: Составьте таблицу соответствия "узел → тенанты" — это упростит создание tenant_config.json.

Шаг 3. Создайте тенанты в OSMP

В веб-интерфейсе Kaspersky EDR Expert 8.1:

Перейдите в раздел Настройки → Тенанты.
Создайте тенанты с точно такими же именами, как в KATA 7.1.

Важно: Имена тенантов должны совпадать точно (включая регистр букв и пробелы). Например, Finance и finance — это разные тенанты.

Создайте тенанты согласно вашей структуре:

Root tenant (корневой, создается автоматически при установке OSMP)
Finance
HR
IT
Sales

Шаг 4. Составьте файл tenant_config.json

Создайте файл tenant_config.json с маппингом узлов KATA на тенанты OSMP.

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

{
  "globalTenantName": "Root tenant",
  "tenants": [
    {
      "scnName": "embedded_scn",
      "xdrTenantName": "Root tenant"
    },
    {
      "scnName": "embedded_scn",
      "xdrTenantName": "Finance"
    },
    {
      "scnName": "scn-node-1",
      "xdrTenantName": "HR"
    },
    {
      "scnName": "scn-node-1",
      "xdrTenantName": "IT"
    },
    {
      "scnName": "scn-node-2",
      "xdrTenantName": "Sales"
    }
  ]
}

Разбор полей:

Поле	Описание
`globalTenantName`	Имя корневого тенанта в OSMP (обычно `"Root tenant"`)
`tenants`	Массив сопоставлений узлов KATA с тенантами OSMP
`scnName`	Имя узла в KATA 7.1 (или специальное значение `embedded_scn` для PCN)
`xdrTenantName`	Имя соответствующего тенанта в OSMP

Правила маппинга тенантов

Правило 1. PCN всегда обозначается как embedded_scn

Это зарезервированное имя для главного узла управления (Primary Central Node). Не используйте реальное имя PCN (например, pcn-node) — скрипт импорта его не распознает.

Неправильно:

{
  "scnName": "pcn-node",
  "xdrTenantName": "Root tenant"
}

Правильно:

{
  "scnName": "embedded_scn",
  "xdrTenantName": "Root tenant"
}

Правило 2. Один SCN может иметь несколько тенантов

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

{
  "scnName": "scn-node-1",
  "xdrTenantName": "HR"
},
{
  "scnName": "scn-node-1",
  "xdrTenantName": "IT"
}

Правило 3. Имена должны совпадать точно

Имена scnName и xdrTenantName должны в точности соответствовать именам узлов в KATA 7.1 и тенантов в OSMP, включая регистр букв и пробелы.

Неправильно:

{
  "scnName": "SCN-Node-1",
  "xdrTenantName": "finance"
}

Правильно:

{
  "scnName": "scn-node-1",
  "xdrTenantName": "Finance"
}

Частые ошибки

Ошибка 1. Забыли указать embedded_scn для PCN

Если вместо embedded_scn использовать реальное имя PCN (например, pcn-node), данные с главного узла не импортируются.

Решение: Всегда используйте embedded_scn для PCN.

Ошибка 2. Не создали тенанты в OSMP

Если в tenant_config.json указан тенант, которого нет в OSMP, импорт завершится с ошибкой.

Решение: Создайте все тенанты в OSMP до запуска скрипта импорта.

Ошибка 3. Неправильные имена SCN

Если имя scnName в tenant_config.json не совпадает с реальным именем узла в KATA 7.1, данные с этого узла не импортируются.

Решение: Проверьте имена узлов командой kubectl get nodes в KATA.

Ошибка 4. Неправильный регистр или пробелы

JSON чувствителен к регистру. Finance и finance — это разные тенанты.

Решение: Копируйте имена тенантов из веб-интерфейса KATA 7.1 и OSMP, чтобы избежать опечаток.

Чек-лист маппинга тенантов

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

Узнал структуру кластера KATA 7.1 (PCN + SCN) командой kubectl get nodes
Определил тенанты на каждом узле через веб-интерфейс KATA
Создал все тенанты в OSMP с точно такими же именами
Составил файл tenant_config.json
Использовал embedded_scn для PCN (а не реальное имя узла)
Создал отдельные записи для каждого тенанта на SCN
Проверил, что имена совпадают точно (регистр, пробелы)
Проверил JSON-файл на корректность синтаксиса (например, через jsonlint.com)
Сохранил файл в надежном месте (понадобится при импорте)

Использование файла при импорте

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

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

💡 Совет: Сохраните файл tenant_config.json в директории /home/admin/ на сервере импорта, чтобы не указывать длинный путь.

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

2.5. Запуск импорта первого этапа (Step First)

На этом шаге импортируются данные конфигурации, правила и списки агентов. После этого шага новый 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 должен быть создан заранее. Подробная пошаговая инструкция по маппингу тенантов (узнавание структуры кластера, создание тенантов в OSMP, правила маппинга, частые ошибки) приведена в подразделе 2.4.1.4 "Добавление тенантов" → раздел "Для режима мультитенантности (кластер KATA)".

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

2.6. Действия после первичного импорта

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

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. Проверка подключения агентов

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

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

2.7. Запуск импорта второго этапа (Step Second)

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

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

./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 уже полноценно работает и обрабатывает новые события от агентов.

2.8. Импорт телеметрии с использованием внешнего хранилища (опционально)

Если вы выбрали Сценарий А: Перенос телеметрии с внешним хранилищем и выполнили экспорт третьего этапа (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:

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

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

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

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

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

2.9. Импорт телеметрии без внешнего хранилища (опционально)

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

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

Важно: Перед выполнением этого шага убедитесь, что настроен SSH-доступ без пароля между сервером управления KUMA и целевым сервером. Инструкция по настройке приведена в разделе "Предварительная подготовка" → пункт 5 "Настройка SSH-доступа между серверами". Без этого шага команда ./kdt invoke kuma --action addHosts не выполнится и вернет ошибку аутентификации.

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

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

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

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

kuma_collector:
  hosts:
    - 192.168.1.100  # IP-адрес или FQDN сервера для коллектора
kuma_correlator:
  hosts: []           # ⬅️ Оставляем пустым (коррелятор уже есть в кластере)
kuma_storage:
  hosts: []           # ⬅️ Оставляем пустым (хранилище уже есть в кластере)

Почему оставляем пустым:

Коррелятор и хранилище уже развернуты в вашем кластере KUMA (на основном сервере OSMP)
Вы добавляете отдельный сервер только для коллектора, чтобы разгрузить основной сервер
Это стандартная практика для масштабирования KUMA

Шаг 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. Открытие мастера настройки коллектора

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

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

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

Параметр	Значение
URL	`https://<KATA_server_ip>:8888/kata/elastic/`
Индекс	Имя индекса в Elasticsearch (из списка `_cat/indices`, полученного в шаге 1.8.6)
Запрос	`{"query": {"match_all": {}}, "size": 10000, "sort": {"_doc": "asc"}}`
Учетные данные Elastic	Создать новый секрет с user/password, полученными в шаге 1.8.4
Elastic fingerprint	Создать новый секрет типа `certificate` и загрузить `elastic.crt` из шага 1.8.4

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

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

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

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

[OOTB] Normalizer for KEDR events migration

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

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

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

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

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

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

Критически важно: Эта команда содержит уникальные параметры (--id и --api.port), которые генерируются автоматически для каждого коллектора. Обязательно скопируйте именно эту команду, а не используйте шаблон из документации.

Скопируйте рекомендуемую команду в буфер обмена (нажмите на иконку копирования в правом нижнем углу блока с командой).
Нажмите Сохранить.

Пример рекомендуемой команды из веб-интерфейса:

/opt/kaspersky/kuma/kuma collector --core https://kuma.xdr.sales.lab:7210 --id 8e134eb2-9e64-4826-b880-9cb05e4cff2a --api.port 7231 --install

💡 Обратите внимание: В этой команде уже заполнены все необходимые параметры:
--core https://kuma.xdr.sales.lab:7210 — FQDN сервера Ядра KUMA и порт
--id 8e134eb2-9e64-4826-b880-9cb05e4cff2a — уникальный идентификатор сервиса (генерируется автоматически)
--api.port 7231 — порт для связи с коллектором (генерируется автоматически)
--install — флаг установки

Сохраните эту команду в текстовый файл на сервере импорта (например, /home/admin/install-collector.txt), чтобы не потерять её и иметь возможность скопировать позже.

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

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

sudo /opt/kaspersky/kuma/kuma collector --core https://kuma.xdr.sales.lab:7210 --id 8e134eb2-9e64-4826-b880-9cb05e4cff2a --api.port 7231 --install

Важно: Используйте именно ту команду, которую вы скопировали из веб-интерфейса KUMA на Шаге 5 раздела 2.9.2. Не пытайтесь заполнить параметры вручную — это приведет к ошибке установки или созданию некорректного сервиса.

Разбор параметров команды:

Параметр	Значение	Описание
`--core`	`https://kuma.xdr.sales.lab:7210`	FQDN сервера Ядра KUMA и порт для внутренних коммуникаций
`--id`	`8e134eb2-9e64-4826-b880-9cb05e4cff2a`	Уникальный идентификатор сервиса коллектора (генерируется автоматически)
`--api.port`	`7231`	Порт API коллектора для связи с другими компонентами (генерируется автоматически)
`--install`	—	Флаг установки сервиса

После выполнения команды:

Дождитесь завершения установки (обычно занимает 30-60 секунд).
Проверьте, что установка завершилась успешно — вы увидите сообщение:

Collector service installed successfully.
Service ID: 8e134eb2-9e64-4826-b880-9cb05e4cff2a
API port: 7231

Проверка статуса коллектора:

systemctl status kuma-collector-8e134eb2-9e64-4826-b880-9cb05e4cff2a

Если статус active (running) — коллектор успешно установлен и запущен:

● kuma-collector-8e134eb2-9e64-4826-b880-9cb05e4cff2a.service - KUMA Collector Service
   Loaded: loaded (/etc/systemd/system/kuma-collector-8e134eb2-9e64-4826-b880-9cb05e4cff2a.service; enabled)
   Active: active (running) since Thu 2024-01-15 10:30:45 UTC; 5min ago

💡 Совет: Если коллектор не запустился автоматически, запустите его вручную:

sudo systemctl start kuma-collector-8e134eb2-9e64-4826-b880-9cb05e4cff2a
sudo systemctl enable kuma-collector-8e134eb2-9e64-4826-b880-9cb05e4cff2a

Проверка логов коллектора:

Если коллектор не запустился, проверьте логи:

journalctl -u kuma-collector-8e134eb2-9e64-4826-b880-9cb05e4cff2a -f

Или посмотрите логи в файле:

tail -f /var/log/kuma/collector/8e134eb2-9e64-4826-b880-9cb05e4cff2a/collector.log

После успешной установки коллектора переходите к разделу 2.9.4 "Мониторинг и проверка импорта".

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

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

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

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

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

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

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

На сервере 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. Завершение миграции телеметрии

Удаление коннекторов

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

В главном меню перейдите в раздел Мониторинг → Ресурсы и сервисы → Активные сервисы.
Найдите коллекторы, созданные для импорта телеметрии.
Щелкните правой кнопкой мыши на коллекторе и выберите Удалить.
Подтвердите удаление.

Удаление сервера из кластера KUMA (если использовался отдельный сервер)

Если вы использовали отдельный Linux-сервер для коллектора, его можно убрать из кластера KUMA:

В главном меню перейдите в раздел Мониторинг → Ресурсы и сервисы → Устройства.
Найдите сервер, который использовался для коллектора.
Щелкните правой кнопкой мыши и выберите Удалить из кластера.
Подтвердите удаление.

Очистка временных файлов

На сервере KATA выполните очистку временных файлов:

# Удаление директории со скриптами
sudo rm -rf /home/admin/elastic_script_dir

# Удаление Docker-образа (опционально)
docker rmi <имя_образа>

2.10. Отключение внешнего хранилища

После завершения всех этапов импорта (включая телеметрию, если она переносилась) безопасно отключите внешнее хранилище от сервера импорта.

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

sudo umount /mnt/external_disk

Для сетевого ресурса:

sudo umount /mnt/external_disk

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

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

Итоговый чек-лист Этапа 2

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

Базовая миграция (обязательно):

Подготовлен сервер Linux для импорта с установленным Docker
Скрипты импорта размещены на сервере
Внешнее хранилище подключено к серверу импорта
Установлен cnab gateway-migration на сервере OSMP
Получены три сертификата (ca.crt, tls.crt, tls.key) и скопированы на сервер импорта
Создан API-токен с необходимыми методами и сохранен на сервере импорта
Создан migration-url (https://migrate.<FQDN>) и добавлена DNS-запись
Созданы тенанты в OSMP (или подготовлен tenant_config.json)
Выполнен импорт первого этапа (Step First) с новыми параметрами
Импортированы исключения IOA из файла excludes.json
Переключены агенты Endpoint Agent на новый сервер (время простоя)
Проверено подключение агентов к новому серверу
Выполнен импорт второго этапа (Step Second) с новыми параметрами
Внешнее хранилище отключено

Для сценария с внешним хранилищем (телеметрия):

Настроен коллектор KUMA типа file
Указан путь к дампу телеметрии
Выбран нормализатор [OOTB] Normalizer for KEDR events migration
Запущен коллектор и проверен статус (🟢 зелёный)
Дождитесь завершения импорта телеметрии
Проверьте, что исторические события появились в Kaspersky EDR Expert 8.1
Остановите коллектор KUMA
Удалите коллектор из конфигурации KUMA
Отключите внешнее хранилище от сервера импорта

Для сценария без внешнего хранилища (телеметрия):

Добавлен отдельный сервер в кластер KUMA (рекомендуется)
Созданы коннекторы elastic в KUMA (до 5 одновременно)
Настроен нормализатор [OOTB] Normalizer for KEDR events migration
Настроена маршрутизация на [OOTB] OSMP Storage (Kubernetes gateway)
Установлен коллектор на отдельном сервере
Проверен статус коллектора (🟢 зелёный)
Убедились, что события поступают в новый Kaspersky EDR Expert 8.1
Дождитесь завершения импорта всех индексов
Закрыт доступ к Elasticsearch (kata-elastic-access.sh close)
Удалены коннекторы из KUMA
Удалён сервер из кластера KUMA (если использовался)
Очищены временные файлы на сервере KATA

KEDR (OSMP)

Установка и обновление

Гайд по установке Kaspersky EDR Expert (on-premise)

Часть 1. Типы установки

Роли узлов:

Часть 2. Критические требования инфраструктуры

2.1. СУБД PostgreSQL

2.2. Сетевые требования

2.3. Аппаратные требования (минимальные)

2.4. Программные требования

Часть 3. Подготовка устройств

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

Целевые устройства (OSMP):

СУБД PostgreSQL:

Подготовка инфраструктуры:

Часть 4. Этапы установки

Подготовка файла param.yaml:

Установка

Часть 5. Базовые действия после установки

Инструкции по настройке

Оптимизация дисковой подсистемы

Настройка доменной аутентификации Kerberos

Процесс установки и настройки компонента Sandbox (OSMP) на базе KES Windows

📦 Варианты подключения

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

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

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

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

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

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

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

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

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

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

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

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

📌 Полезные ссылки

Процесс установки и настройки компонента EDR (OSMP) на базе KES Windows

📦 Варианты подключения

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

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

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

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

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

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

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

Лицензия KEDR:

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

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

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

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

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

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

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

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

📌 Полезные ссылки

Процесс установки и настройки компонента EDR (OSMP) на базе KES Linux

📦 Варианты подключения

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

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

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

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

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

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

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

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

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

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

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

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

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

📌 Полезные ссылки

Процесс установки и настройки компонента Sandbox (OSMP) на базе KES Linux

📦 Варианты подключения

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

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

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

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

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

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

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

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

Шаг 1: Интерактивный мастер (`wizard`)

Шаг 2: Применение конфигурации (`apply`)

Выполнение действий над компонентами (`invoke`)

Резервное копирование и восстановление состояния (`state`)

Управление контекстами (`ctx`)

Распределенная трассировка (`traces`)