Сквозной пример настройки UBA
В примере настраивается выявление входа пользователя с нового IP-адреса. Значения можно использовать как шаблон, заменив имена индексов, полей и справочника на значения своей среды.
Работающий сценарий UBA состоит не из одной конфигурации. Необходимо согласованно настроить тип объекта, заполнение списка объектов, политику профилирования, задание выявления аномалий с начислением риск-балла и расчет скоринга.
Исходные данные
В примере используются следующие источники:
| Источник | Поля | Требование |
|---|---|---|
directory-events-* | @timestamp, user_id, full_name, department, status | исходные данные для формирования справочника |
employees-current | user_id, full_name, department, status | одна актуальная запись на пользователя |
auth-events-* | @timestamp, user_id, source.ip, event.action | события успешных и неуспешных входов |
В этом примере directory-events-* — исходный индекс с данными о пользователях. На его основе формируется актуальный справочник employees-current, который используется как источник для заполнения списка объектов UBA. Значение user_id должно иметь одинаковый формат в обоих источниках.
Для регулярного обновления справочника создайте задание, которое выполняет запрос:
source directory-events-*
| search user_id=="*" AND status=="active"
| dedup user_id sortby - @timestamp
| table user_id, full_name, department, status
| outputlookup employees-current
Команда outputlookup сохраняет подготовленный набор записей в employees-current. Настройте расписание задания в соответствии с требуемой частотой обновления данных.
1. Тип объекта и тип скоринга
Создайте тип объекта со следующими параметрами:
| Параметр | Значение |
|---|---|
| название типа | Пользователь |
| базовые поля | user_id |
| дополнительные поля | full_name, department |
| тип скоринга | UBA risk |
Создайте тип скоринга UBA risk, включите совместимость с UBA и привяжите его к типу объекта Пользователь. Поле user_id должно быть базовым и уникальным, а full_name и department могут повторяться.
Подробнее о настройке сущностей см. в разделе Основные сущности.
2. Конфигурация заполнения объектов
Создайте конфигурацию в разделе Навигационное меню - User Behavior Analytics - Конфигурации заполнения объектов.
| Раздел | Параметр | Значение |
|---|---|---|
| Основные | Название | UBA: активные пользователи |
| Расписание | Тип | Интервал, каждые 24 часа |
| Фильтрация | Индекс | employees-current |
| Фильтрация | Временной интервал и поле времени | не задавать для актуального снимка |
| Фильтрация | Фильтр | user_id=="*" AND status=="active" |
| Настройки объекта | Тип объекта UBA | Пользователь |
| Настройки объекта | Поле идентификатора объекта | user_id |
| Настройки объекта | Базовое поле | user_id → user_id |
| Настройки объекта | Дополнительные поля | full_name → full_name; department → department |
| Дополнительные настройки | Максимальное количество объектов | значение не меньше ожидаемого числа пользователей и в пределах лицензии |
| Дополнительные настройки | Длительность блокировки | 60 секунд |
| Дополнительные настройки | Запуск конфигурации | включен |
Нажмите Предпросмотр. В результате должна отображаться одна строка на каждый user_id, без пустых идентификаторов и дубликатов базового поля. Затем нажмите Заполнить и сохраните конфигурацию.
Подробное описание фильтрации и дедупликации приведено в разделе Заполнение списка объектов.
3. Политика профилирования
Создайте политику в разделе Навигационное меню - User Behavior Analytics - Политики профилирования.
Основные настройки политики
| Параметр | Значение |
|---|---|
| Имя | UBA: IP-адреса входа пользователей |
| Тип объекта | Пользователь |
| Индексы | auth-events-* |
| Поля для идентификации объекта в индексах | user_id |
| Игнорирование регистра | выключено, если user_id заранее нормализован |
| Временной интервал | от now-30d до now |
| Поле, содержащее метку времени | @timestamp |
| Расписание | Интервал, каждые 24 часа |
| Длительность блокировки | 7200 секунд |
| Количество потоков | 4 |
| Документов в одной итерации записи | 500 |
Алгоритм Словарь
| Параметр | Значение |
|---|---|
| Фильтр | event.action=="login" AND source.ip=="*" |
| Индекс для результатов | uba_profile_users_login_source_ip_dictionary |
| Название обрабатываемого поля | source_ip |
| Паттерн индекса | auth-events-* |
| Поле в источнике | source.ip |
| Частичное обновление | выключено, чтобы ежедневно перестраивать профиль за последние 30 дней |
Сохраните политику, выполните первый запуск вручную и дождитесь успешного завершения. В профильном индексе для каждого пользователя должны появиться известные сочетания user_id и source_ip. До успешного первого запуска переходить к выявлению аномалий не следует: задание не сможет сравнить события с пустым профилем.
4. Справочник профильного индекса
Создайте lookup для индекса uba_profile_users_login_source_ip_dictionary. Для сопоставления потребуются поля:
| Назначение | Поле профильного индекса |
|---|---|
| идентификатор пользователя | _meta.object.identity |
| известный IP-адрес | _calculation.source_ip |
| признак найденного профиля | _meta.object.id |
В примере далее используется имя справочника uba_users_login_source_ip. Настройки lookup должны обеспечивать точное сопоставление пары user_id + source.ip.
5. Задание выявления аномалий
Создайте задание, которое запускается каждые 5 минут и анализирует последние 10 минут. Базовый поисковый запрос:
source auth-events-*
| search event.action=="login" AND user_id=="*" AND source.ip=="*"
| lookup uba_users_login_source_ip _meta.object.identity AS user_id _calculation.source_ip AS source.ip OUTPUT _meta.object.id AS profile_object_id
| where isnull(profile_object_id)
Запрос оставляет входы, для которых в профиле пользователя отсутствует текущий IP-адрес. Если поля lookup настроены под другими именами, скорректируйте их в команде. Подробнее о синтаксисе см. в разделе lookup.
Добавьте активное действие начисления риск-балла:
| Параметр | Значение |
|---|---|
| Балл | 20 |
| Индекс | uba_scoring_users_login_new_ip |
| Тип скоринга | UBA risk |
| Объект UBA | user_id из результата поиска |
| Тип объекта UBA | Пользователь |
| Срок жизни | 24 часа |
| Детализация | Поиск |
Перед включением задания выполните тестовый поиск. Он не должен возвращать события с IP-адресами, уже присутствующими в профиле.
6. Расчет скоринга
Создайте расчет в разделе Навигационное меню - User Behavior Analytics - Расчеты скоринга.
| Параметр | Значение |
|---|---|
| Тип объекта | Пользователь |
| Тип скоринга | UBA risk |
| Описание | Суммарный риск пользователей по аномалиям входа |
| Индексы | uba_scoring_users_* |
| Временной интервал | не меньше максимального срока жизни начисляемых баллов |
| Поле, содержащее метку времени | поле времени начисления из документов скоринга |
| Расписание | Интервал, каждые 5 минут |
| Использовать функцию расчета | выключено для линейной суммы |
| Цветовые диапазоны | 0–19 — норма; 20–39 — предупреждение; 40 и выше — тревога |
| Длительность блокировки | 60 секунд |
| Количество потоков | 1 |
| Документов в одной итерации записи | 1000 |
Включите расчет после того, как задание создаст хотя бы одно тестовое начисление.
7. Проверка полного цикла
- Убедитесь, что объект пользователя присутствует в списке UBA только один раз
- Проверьте успешный запуск политики и наличие
source_ipв результатах алгоритмаСловарь - Выполните поисковый запрос задания на событии с известным IP-адресом — событие не должно считаться аномалией
- Повторите проверку с новым IP-адресом — запрос должен вернуть событие
- Убедитесь, что активное действие создало начисление в
uba_scoring_users_login_new_ip - Запустите расчет скоринга и откройте профиль объекта
- Проверьте итоговый балл, историю начисления и детализацию события
Если профиль не находится, сначала сопоставьте значения user_id в объекте UBA, событиях и lookup. Наиболее частые причины — различия регистра, доменный префикс и использование разных полей идентификации.