Обзор Dataplan 2.4: аналитической платформы для поиска скрытых угроз и аномалий

1. 1. Введение
2. 2. Что такое Dataplan
3. 3. Архитектура Dataplan 2.4
4. 4. Функциональные возможности Dataplan 2.4
   1. 4.1. Подключение источников данных
   2. 4.2. Обработка и обогащение данных
   3. 4.3. Модули анализа
      1. 4.3.1. Модуль аналитики
      2. 4.3.2. Модуль xBA
      3. 4.3.3. Модуль Role mining
   4. 4.4. Объекты и системы
   5. 4.5. Администрирование
      1. 4.5.1. Система разграничения доступа
      2. 4.5.2. Аутентификация
      3. 4.5.3. Аудит и мониторинг
      4. 4.5.4. Лицензирование и обновление
      5. 4.5.5. Служебные настройки
5. 5. Системные требования Dataplan 2.4
6. 6. Применение Dataplan 2.4
   1. 6.1. Контроль доступа к ресурсам мейнфреймов
   2. 6.2. Оценка состояния и выявление аномалий в службе каталогов
   3. 6.3. Мониторинг работы с внутренними веб-ресурсами
7. 7. Выводы

Введение

Современные средства защиты информации (СЗИ), такие как антивирусы, EDR, DLP, SIEM, эффективно выявляют известные угрозы: вредоносные файлы, сигнатурные атаки и явные нарушения политик безопасности. Но существует класс рисков, который они практически не покрывают по своей природе: действия легитимных пользователей, выполняемые в рамках предоставленных им прав доступа. Например:

• инсайдер, выгружающий базу клиентов под своей учётной записью в рабочее время;
• скомпрометированная учётная запись бухгалтера, обращающаяся к зарплатным данным ночью без запуска подозрительных процессов;
• сотрудник, годами «накапливающий» избыточные права в службе каталогов.

Это не атаки в классическом понимании, а отклонения от нормального поведения, которые теряются на фоне большого объёма легитимной активности.

В таком случае классические правила корреляции бессильны:

• порог «скачано больше 100 МБ» сработает на бухгалтера, выгружающего отчёт, но пропустит инсайдера, который 30 дней подряд скачивает по 50 МБ;
• правило «доступ к зарплатной БД» сработает для всех сотрудников отдела кадров, но не позволит выделить того, кто впервые за 2 года обратился к этой таблице ночью;
• аудит прав доступа вручную в среде из 5 000 пользователей и сотен групп безопасности — задача, требующая месяцев работы команды аналитиков.

Именно эту «серую зону» — действия, которые по отдельности выглядят легитимно, но аномальны в контексте поведения и привилегий, — и призван закрывать Dataplan. Аналитическая платформа NGR Softlab сочетает поведенческую аналитику, аудит привилегий с учётом специфики бизнеса и расширенные инструменты работы с big data в области ИБ, что позволяет выявлять аномалии и скрытые угрозы, которые сложно отследить только классическими СЗИ.

Dataplan включён в реестр отечественного ПО (№ 9438 от 04.03.2021).

Ранее мы делали обзор версии 1.10, с того момента вендор продолжил развивать платформу как зрелый инструмент приоритизации действительно важных событий по безопасности с учётом бизнес-процессов каждой конкретной компании. В апреле 2026 года было выпущено масштабное обновление. В продукт внедрили собственную ИИ-модель для анализа отклонений во временных рядах, которая учитывает контекст, уменьшает число ложных срабатываний и снижает нагрузку на аналитика. Об этом изменении и других актуальных возможностях Dataplan 2.4 — далее в обзоре.

Что такое Dataplan

Dataplan — аналитическая платформа для выявления инсайдеров, компрометаций и других скрытых угроз информационной безопасности (ИБ). Она ориентирована на работу с событиями и объектами, которые формально не нарушают правила и не попадают под стандартные сценарии детектирования, но становятся значимыми при рассмотрении в контексте поведения и привилегий. В результате платформа позволяет аналитикам ИБ выделять аномалии из общего потока легитимной активности и фокусироваться на действительно нетипичных отклонениях.

Решение NGR Softlab работает поверх существующих систем.

Таблица 1. Сопоставление возможностей СЗИ и Dataplan 2.4

Ключевой принцип Dataplan заключается в том, что он не заменяет средства защиты информации, а дополняет их, формируя отдельный аналитический слой. Основной вопрос, на который он отвечает: «Это событие, пользователь или действие выглядят корректно, но является ли это нормой именно для данного объекта с учётом его контекста?»

Рассмотрим пример. При интеграции с SIEM Dataplan выступает поставщиком событий о выявленных отклонениях в поведении пользователей, хостов и других объектов инфраструктуры. Это решает 2 ключевые задачи:

1. Настройка правил корреляции. Аналитик опирается на объективные данные о фактическом поведении пользователей при взаимодействии с объектами инфраструктуры: используемые параметры, частоту обращений, объёмы операций. Это позволяет формировать обоснованные пороговые значения и повышать точность правил, одновременно снижая число ложноположительных срабатываний.
2. Динамическая оценка риска. Сведения из Dataplan используются в правилах корреляции SIEM для повышения или понижения уровня риска. Если по объекту одновременно зафиксированы отклонения в поведении (из Dataplan) и другие подозрительные условия (из самой SIEM), общий риск повышается. При отсутствии поведенческих аномалий риск снижается. Это позволяет фокусировать внимание аналитика на действительно значимых событиях.

В крупных инфраструктурах с разрозненными бизнес-процессами DLP-системы формируют значительный поток событий, что усложняет ручное определение приоритетов для анализа. Dataplan, отслеживая поведенческие параметры объектов в инфраструктуре, позволяет выделять пользователей и процессы, требующие первоочередного внимания, и тем самым упорядочивать работу с массивом событий ИБ.

Чаще всего Dataplan применяется при анализе работы прикладных систем, где традиционные средства защиты и мониторинга представлены в меньшей степени. Платформа в этом случае выступает в качестве инструмента для контроля доступа к данным и принятия обоснованных решений о блокировании подозрительных действий.

Архитектура Dataplan 2.4

У решения NGR Softlab взаимосвязанная модульная структура с единым графическим веб-интерфейсом управления. Она включает ряд заимствованных компонентов, интегрированных с модулями собственной разработки:

• серверный конвейер обработки данных Logstash для сбора и нормализации данных для анализа;
• систему управления базами данных (СУБД) ClickHouse для хранения анализируемых данных;
• СУБД PostgreSQL для хранения служебной информации;
• веб-сервер Nginx для обработки пользовательских запросов;
• брокер сообщений, обеспечивающий асинхронное взаимодействие между сервисами.

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

Структурная схема взаимодействия описанных компонентов решения между собой и с внешними источниками данных приведена ниже.

Рисунок 1. Структурная схема взаимодействия компонентов Dataplan

Функциональные возможности Dataplan 2.4

Возможности Dataplan 2.4:

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

Они позволяют получать информацию для оценки текущего состояния системы защиты, формировать поведенческий и функциональный профиль пользователей и элементов инфраструктуры, а также детектировать признаки скрытых угроз ИБ. На основе этого создаётся контекст для проведения расследований ИБ-инцидентов и обоснования решений по оптимизации затрат на внедрение и использование СЗИ.

Для доступа к веб-интерфейсу в адресной строке браузера необходимо ввести доменное имя или IP-адрес сервера с установленной платформой.

Рисунок 2. Окно авторизации Dataplan 2.4

Вход в интерфейс осуществляется с использованием реквизитов доменной учётной записи (УЗ) пользователя. Для УЗ должна быть назначена роль с правами доступа к разделу «Данные». Если УЗ с необходимой ролью отсутствует, необходимо обратиться к администратору платформы для её предоставления.

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

Подключение источников данных

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

• Logstash-коннекторы. Используются все поддерживаемые плагины Logstash — для сбора журналов событий операционных систем (Windows, Linux и др.), средств защиты информации и любых других источников.
• JDBC-коннекторы. Используются для подключения к базам данных.
• Сетевые протоколы. Приём данных по TCP/UDP.
• Python-движок. Используется для нестандартных источников или специфических сценариев подключения. Коннекторы на Python запускаются по расписанию, выполняют приём и предварительную обработку данных.

Привязка к какой-либо отдельной экосистеме продуктов отсутствует. Это соответствует общей политике вендора, направленной на интероперабельность своих решений, — исключение привязки к единому вендору и свободу выбора решений для заказчика.

Рисунок 3. Взаимодействие Dataplan с другими системами

По словам вендора, основной объём интеграций закрывается через сборщик событий Logstash. Он используется как базовый механизм подключения и обработки телеметрии и в большинстве случаев покрывает порядка 80 % типовых источников, встречающихся в проектах. Оставшиеся около 20 % источников относятся к нестандартным сценариям. Это могут быть проприетарные решения, кастомные интеграции или самописные системы. Для работы с ними используется дополнительный механизм — Python-скрипты, которые позволяют реализовывать индивидуальные коннекторы и напрямую извлекать данные из таких систем.

Рисунок 4. Источники данных

Рисунок 5. Редактирование источника данных

Рисунок 6. Настройка подключения

Маппинг полей настраивается визуально в веб-интерфейсе. Все коннекторы можно сохранять как шаблоны и переносить между инсталляциями.

Рисунок 7. Маппинг данных в Dataplan 2.4

Встроенный набор готовых коннекторов меньше, чем у классических SIEM-систем, и это осознанное дизайн-решение. Dataplan не использует жёсткую схему данных: платформа забирает только те поля, которые необходимы для анализа поведения. Это снижает нагрузку на систему и позволяет избежать дублирования полных журналов событий. При этом экспертиза коннекторов из решения Alertix (SIEM) легко адаптируется для использования в Dataplan.

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

Обработка и обогащение данных

Хранилище данных предназначено для централизованного хранения сведений обо всех объектах, поступающих из 1 или нескольких источников, подключённых к платформе. Оно обеспечивает обогащение и консолидацию данных, формирование технической инвентаризации, а также подсчёт количества объектов различных типов и расчёт совокупных рисков, что в итоге позволяет получить целостное представление о состоянии ИБ в организации.

После поступления данные могут дополнительно обрабатываться с использованием Python-скриптов, для чего применяются широко распространённые библиотеки для обработки и анализа данных, такие как Pandas и scikit-learn. Это позволяет выполнять доочистку данных, а также применять базовые методы машинного обучения и алгоритмы искусственного интеллекта (ИИ) к информации, поступающей в хранилище.

Примерами таких скриптов могут быть:

Скрипты обогащения. Например, обращение к внешним ресурсам (при наличии интернет-доступа) для получения сведений о Tor-узлах с последующим обогащением NetFlow-данных и построением профилей трафика.

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

Любые другие варианты постобработки данных (нормализация, структурирование, очистка и т. д.).

Рисунок 8. Пример редактирования скрипта

Рисунок 9. Пример редактирования скрипта (продолжение)

Скрипты запускаются по расписанию. Результат обработки используется для построения аналитической отчётности.

В разделе «Данные» после настройки источников и скриптов обогащения доступен подраздел «Хранилище». Он предоставляет полный контроль над структурой и содержимым аналитической базы.

Структура. В одноимённой вкладке можно изучить состав таблиц, типы полей, выполнить предварительный просмотр записей без перехода в консоль. Реализовано управление временем хранения — настройка срока хранения данных (time-to-live, TTL) для каждой таблицы в зависимости от регламентных требований. Функция представлений (view) позволяет создавать виртуальные таблицы через SQL-запросы для предварительной обработки и нормализации данных. На её базе строится аналитическая отчётность.

Рисунок 10. Просмотр структуры

Статистика. Можно мониторить объёмы данных (количество строк), динамику поступления и историю изменений. Функция особенно полезна при подключении нового источника: можно быстро убедиться, что данные поступают, корректно парсятся и распределяются по полям маппинга.

Рисунок 11. Статистика

Управление сценариями. Доступны сценарии генерации отчётности: автоматизированные шаблоны аналитики, которые запускаются при наличии необходимых данных в хранилище. Система проверяет состав полей, типы данных и при соответствии автоматически формирует профили поведения и дашборды. На текущий момент доступны сценарии для:

• файловых хранилищ (на базе журналов Windows);
• Exchange (журналы Message Tracking);
• NetFlow (статистика передаваемого / получаемого трафика);
• управления УЗ (события с контроллеров домена);
• службы каталогов (в связке с модулем Role Mining).

Контент постоянно расширяется. Все сценарии создаются без необходимости программирования — достаточно наличия соответствующих журналов событий.

Управление словарями — механизм обогащения данных внешними справочниками. Словари загружаются в хранилище и используются в скриптах или запросах для дополнения событий контекстной информацией (например, принадлежность IP к подразделению, критичность ресурса и т. п.).

Такая модель хранилища закрывает полный цикл работы с данными: от приёма и первичной проверки до контроля структуры и мониторинга наполнения. Через веб-интерфейс доступны просмотр схемы, предварительный просмотр данных и статистика их поступления по таблицам и источникам, что обеспечивает оперативный контроль корректности маппинга и факта загрузки без необходимости использования внешних инструментов или консольных утилит.

Модули анализа

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

• Аналитика — общие инструменты визуализации и исследования данных.
• Поведенческая аналитика (xBA) — выявление отклонений и аномалий в действиях пользователей и объектов.
• Анализ привилегий (Role Mining) — анализ избыточных и необоснованных прав доступа.

Эти модули формируют риски для объектов контроля, которые централизованно отображаются в разделе «Объекты системы» для последующего расследования аналитиком.

Модуль аналитики

Модуль по своей функциональности сопоставим с базовыми возможностями платформ класса Business Intelligence (BI). Ключевое отличие заключается в типе обрабатываемых данных. Классические BI-платформы ориентированы преимущественно на числовые и категориальные данные и ограниченно применимы для анализа неструктурированной текстовой информации. В Dataplan 2.4 акцент сделан на работе с журналами событий и другими текстовыми данными.

Модуль аналитики платформы — гибкий инструментарий для исследования данных. Он позволяет формировать срезы данных для выявления корреляций разных параметров, обнаружения инсайтов и получения дополнительного контекста для принятия data-driven-решений при расследовании ИБ-инцидентов. Реализована возможность строить отчётность в 2 направлениях:

• Сверху вниз — когда создаётся дашборд и в него добавляются чарты, для которых формируются датасеты.
• Снизу вверх — когда сперва формируется датасет (выборка данных), на его основе строится чарт, а несколько чартов объединяются в дашборд.

Датасеты. Работа в модуле аналитики начинается с формирования датасета, в котором определяются параметры для генерации текстового запроса к хранилищу данных. Именованная выборка данных из хранилища создаётся 2 способами:

• Редактор (SQL) — прямой ввод запросов на диалекте ClickHouse с подсветкой синтаксиса и валидацией. Запрещены деструктивные операции (удаление, опасные функции).
• Конструктор — визуальный интерфейс без написания кода: выбор базы, таблицы, полей, фильтрация (равно / не равно, содержит / не содержит, регулярные выражения, интервалы времени, числовые диапазоны), группировка и агрегация (сумма, среднее, количество, уникальные значения), сортировка и ограничение количества записей.

Рисунок 12. Редактирование датасета в редакторе

Рисунок 13. Редактирование датасета в конструкторе

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

Чарты. На базе датасета формируются чарты (визуализация данных):

• таблицы и сводные таблицы (с настройкой подуровней вложенности до 3 уровней);
• линейные, столбчатые, комбинированные диаграммы (с подгруппами, например, разбивкой по департаментам, протоколам обмена данными и т. п.);
• круговые и кольцевые диаграммы, радары, облака тегов;
• метрики / KPI;
• Markdown-блоки (для описаний, ссылок на другие отчёты);
• изображения.

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

Рисунок 14. Настройки диаграммы в Dataplan 2.4

Рисунок 15. Редактирование чарта «Динамика изменения объектов»

Рисунок 16. Редактирование чарта по группам безопасности службы каталогов

Рисунок 17. Примеры редактирования чарта с markdown-разметкой 

Дашборды. Они полностью настраиваемы: поддерживается изменение структуры и состава виджетов, применение локальных и глобальных фильтров, настройка автообновления, разграничение прав доступа вплоть до отдельных элементов, а также экспорт данных. Все операции выполняются через веб-интерфейс без использования внешних инструментов.

Дашборды позволяют формировать интерактивные информационные панели, на которых могут быть размещены данные определённой категории, позволяющие отслеживать важные показатели в реальном времени:

• компоновка — чарты размещаются на сетке с фиксированной минимальной размерностью;
• права доступа к дашборду распространяются на входящие чарты и датасеты;
• глобальный фильтр — применяется ко всем чартам дашборда;
• локальный фильтр — работает в рамках 1 чарта;
• проброс значений между дашбордами — ключевой приём при расследовании: например, можно выбрать интересующий объект (пользователь, хост, процесс или любой другой) на общем дашборде и передать его в детализирующие дашборды, где платформа автоматически применяет фильтр, минимизируя ручные клики;
• автообновление — настраивается интервал (1, 3, 5, 10 минут) для динамических данных;
• экспорт — дашборд или отдельные чарты можно выгрузить в PDF, PNG, XLSX;
• рассылки — автоматическая отправка дашбордов или выбранных чартов ответственным лицам по расписанию. Поддерживается уведомление об изменениях в данных.

Рисунок 18. Редактирование дашборда

Рисунок 19. Меню работы с дашбордом

Рисунок 20. Настройка рассылки

Также доступен дополнительный вид рассылки: отправка новых событий по протоколу Syslog во внешние системы, например, в SIEM для параллельного анализа. Данный сценарий актуален при работе с нестандартными источниками данных.

Рисунок 21. Пример полного отчёта

Модуль xBA

Модуль xBA (eXtended Behavioural Analytics) реализует расширенную поведенческую аналитику на основе алгоритмов машинного обучения (Machine Learning, ML) и анализа исторически накопленных данных. В отличие от решений, работающих по жёстким правилам, xBA строит профили поведения. Они формируются динамически на основе временных рядов из различных источников, включая журналы событий операционных систем, сетевой трафик и данные прикладных систем.

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

Отметим, что модуль работает с ретроспективными данными. Расчёт профилей запускается по расписанию после поступления данных (например, ночная выгрузка из БД — утренний расчёт профилей за предыдущий день). Это осознанное дизайн-решение: агрегация полного объёма данных за выбранный период обеспечивает точность, позволяя избежать недостоверных промежуточных результатов.

Настройка профилей. Профиль — оценка поведения сущностей по 1 параметру (например, объём переданных данных, число уникальных получателей писем и др.). Профили являются ключевым инструментом для выявления отклонений в поведении объектов контроля. Ограничений на их количество нет. Профили формируются на базе:

• источника данных — таблицы или представления в хранилище данных;
• поля временной метки — обязательного условия для анализа временных рядов;
• категории сущности и поля идентификатора, например, user_sid для пользователей, host_name для хостов;
• функции профилирования — ключевого параметра, определяющего, что именно анализируется.

Таблица 2. Функции профилирования

Рисунок 22. Создание профиля в Dataplan 2.4

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

Рисунок 23. Изменение подписей осей графика

Реализована функция фильтрации исходных данных. 

Рисунок 24. Фильтрация данных

Параметры времени запуска расчётов устанавливаются в соответствующем разделе. Можно выполнять регулярный запуск (например, каждые 10 минут) или запуск по определённым дням недели. Это позволяет снизить и распределить нагрузку на инстанс, а также выполнять расчёты только после поступления и накопления необходимого объёма данных.

Рисунок 25. Расписание запуска расчёта

При необходимости профиль может быть добавлен в метапрофиль (о метапрофилях подробнее см. ниже), который объединяет результаты нескольких профилей одной категории сущностей (например, только пользователей) с назначением весов. Так, например, профилями могут быть группы пользователей — HR, бухгалтеры, секретари, которые отслеживаются в рамках метапрофиля обращений к критичным базам данных. Один профиль может быть добавлен в несколько метапрофилей с разными весами. Так, в метапрофиле, контролирующем риски отклонений при доступе к критичным данным, могут быть профили со следующими весами:

• Профиль «Обращения к критичной таблице БД» — вес 5 (высокая значимость).
• Профиль «Время работы с БД» — вес 1 (вспомогательный параметр).

Визуализация результатов профилирования. 1-й уровень представления информации «Обзор профиля» используется для первичного анализа и принятия быстрых решений по сущностям с наибольшим риском. Он включает топ-10 сущностей по риску, усреднённый график поведения всех объектов, динамику отклонений относительно границ нормы и детализацию:

• распределение сущностей с отклонениями по цветовым зонам (красная — высокий риск, жёлтая — средний, зелёная — низкий, синяя — без отклонений);
• для каждой зоны доступен перечень объектов и график их поведения с привязкой ко времени расчёта.

Рисунок 26. Уровень 1 «Обзор профиля»

Уровень 2 «Детали поведения» отображает сведения о поведении конкретной сущности в рамках профиля. Используется для детального изучения исторических значений по контролируемому параметру, выявления трендов и скрытых паттернов:

• график поведения сущности с границами нормального поведения, а также расчётными точками с отклонениями и без них;
• табличное представление рассчитанных значений.

Рисунок 27. Уровень 2 «Детали поведения»

Уровень 3 «Исходные данные по отклонению» используется для анализа данных, которые послужили причиной формирования найденного отклонения (например, просмотра всего перечня ресурсов доступа, скачанных файлов или таблиц обращений) и принятия решения об ИБ-инциденте:

• сырые записи из хранилища с возможностью перехода в режим редактора датасетов для увеличения выборки, дополнительной фильтрации, агрегации и др.;
• расчётное значение и нарушенная граница (подсвечиваются);
• интерпретация отклонения (настраивается при создании профиля, например, «аномально большой объём переданных данных за день»).

Рисунок 28. Уровень 3 «Исходные данные»

Метапрофиль — это кастомная риск-скоринговая модель, объединяющая результаты нескольких профилей одной категории сущностей (только пользователи, только хосты или только процессы и др.) с назначением весов. Это позволяет перейти от «точечных» аномалий к комплексной оценке поведения.

Использование 1 категории сущностей ограничивает точность поведенческого анализа, поскольку профили для различных типов объектов имеют разную природу и набор значимых параметров. Для пользователей характерны метрики, связанные с их активностью при работе с данными и ресурсами: объём скачанных данных, время активности, количество уникальных ресурсов и другие поведенческие признаки. Для хостов применяются иные параметры, отражающие их роль в инфраструктуре: объём сетевого трафика, количество сетевых соединений, частота запуска процессов.

Соответственно, для корректной оценки поведения требуется раздельное формирование профилей с учётом специфики каждой категории сущностей.

Таблица 3. Построение метапрофиля «Рискованная работа с критичными данными»

Расчёт итогового риска: «Риск = (92 × 5 + 75 × 4 + 88 × 3 + 60 × 2 + 80 × 3) / (5 + 4 + 3 + 2 + 3) = 81» (например, из 100 или другого максимального значения среди других сущностей).

Веса можно корректировать «на лету» прямо в интерфейсе метапрофиля и мгновенно пересчитывать оценку без перезапуска расчётов или пересоздания профилей.

Уровень 1 «Обзор метапрофиля» используется для общей оценки рисков заданной модели:

• топ-10 аномальных объектов по взвешенному риску за выбранный период;
• динамика изменения рисков за период, что позволяет увидеть, растёт ли общая «температура» в инфраструктуре;
• распределение сущностей по цветовым зонам исходя из рассчитанных взвешенных рисков (цветовая схема описана выше);
• для каждой зоны — детали по рискам сущностей. Например, в красной зоне находятся 3 пользователя из отдела продаж. Тогда гипотеза будет следующей: сменился бизнес-процесс (новая CRM), требуется скорректировать профили или исключить отдел из статистики.

Рисунок 29. Уровень 1 «Обзор метапрофиля»

Уровень 2 «Детали рисков по метапрофилю» используется для анализа конкретных параметров (профилей) поведения сущности и их рисков в рамках метапрофиля. Исходя из целей объединения профилей в метапрофиль и интерпретаций выявленных отклонений аналитик получает комплексную картину изменения паттернов поведения сущности для более взвешенного принятия решения по дальнейшим действиям.

Уровень 2 содержит сводную таблицу по конкретной сущности:

• перечень профилей с отклонениями и их вклад в итоговый риск;
• интерпретацию отклонений (настраивается в шаблоне профиля), прямые ссылки для углублённого анализа, переход в карточку сущности (полная история), переход в конкретный профиль для деталей аномалии.

Рисунок 30. Уровень 2 «Детали рисков по метапрофилю»

Карточка сущности. Она является централизованным представлением всех отклонений по конкретной сущности за период времени (текущий день и неделя назад) в рамках модуля xBA:

динамика изменения общего риска во времени за неделю;

распределение рисков по профилям (какие параметры поведения вызывают отклонения);

таймлайн выявленных аномалий за день с привязкой ко времени расчёта профиля (не к атомарным событиям — профили работают с агрегированными данными);

прямые ссылки на профиль и детали аномалии для углублённого анализа.

Рисунок 31. Карточка сущности

Разберём на примере расследования:

1. В карточке пользователя «ivanov_a» видим рост риска с 20 до 85 за 3 дня.
2. Основные профили-виновники: «Объём данных» и «Время активности».
3. Переходим в детали аномалии по «Объёму данных», видим скачивание аномального объёма данных — 1,8 ГБ — из папки «\server\finance\Q4_reports».
4. Дополнительно проверяем в модуле «Аналитика», какие именно файлы были скачаны (через датасет с выборкой по полю «file_path»).
5. Решение: временная блокировка и запрос на подтверждение легитимности действия.

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

Таблица 4. Настройка правил

Таблица 5. Выстраивание логики расчёта

Рисунок 32. Настройка правила

Рассмотрим настройку правила «Критичный доступ к финансовым данным»:

• Источник — метапрофили «Рискованная работа с критичными данными» и «Объём скачанных данных».
• Логика — суммарный риск.
• Порог — 75.
• Результат — система проверяет всех пользователей в рамках выбранных метапрофилей и суммирует значения взвешенных рисков. Если у пользователя «ivanov_a» итоговый взвешенный риск равен 81, то он попадает в раздел «Контроль» с пометкой о срабатывании правила. У одних и тех же сущностей могут быть срабатывания по нескольким правилам.

Без правил контроля аналитик видит:

• 120 пользователей с риском больше 40 по разным профилям;
• 30 хостов с аномалиями по трафику;
• 15 подразделений с отклонениями по активности.

С правилами контроля аналитику доступно только следующее: 7 пользователей с комплексным риском больше 75 по критичным данным и 2 хоста с массовыми исходящими соединениями в нерабочее время.

Правила позволяют сократить шум на 85–90 %, сосредоточив внимание на сущностях, требующих немедленного расследования.

Модуль Role mining

Role Mining — это модуль анализа избыточных и аномальных прав доступа через службу каталогов. Объект анализа ограничен пользователями без учёта компьютеров, принтеров и других системных объектов. Анализ строится на взаимосвязи «пользователь — группа безопасности» с учётом иерархической структуры (вложенности) групп.

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

Модуль не заменяет аудиторские скрипты или отчётность. Он решает конкретную задачу: выявить аномалии в правах относительно однородных групп пользователей (коллег по должности, подразделению, организационной единице). Это помогает находить избыточные права, «забытые» доступы уволенных сотрудников и нетипичные назначения.

Таблица 6. Применение модуля в задачах специалистов

Для служб каталогов с числом пользователей до 500 ручной аудит часто эффективнее. Модуль Role Mining является более подходящим решением при тысячах пользователей и десятках информационных систем, где права разграничиваются через группы службы каталогов. Он поддерживает сложные инфраструктуры:

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

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

Изолированные контуры. Полная поддержка работы без интернета — все алгоритмы и библиотеки включены в дистрибутив.

Таблица 7. Решение проблем в инфраструктуре при помощи Role Mining

Role Mining позволяет перейти от несистемного управления доступом к ролевой модели с последующей структуризацией, анализом и аудитом прав доступа.

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

Рисунок 33. Подключение службы каталогов

Далее — выполняется базовая настройка параметров анализа: включение заблокированных пользователей, исключения для ролевой модели и др.

Рисунок 34. Настройка метрик

Результаты анализа. Они представляются в нескольких вкладках в привязке к анализируемому домену (службе каталогов): статистика, группы, пользователи, должности, подразделения, организационные единицы (Organizational Units, OU), ролевая модель.

Рисунок 35. Главный дашборд, сводка по состоянию службы каталогов

На одноимённой вкладке расположен дашборд со статистикой, на котором собраны данные, показывающие общее состояние службы каталогов:

• количественные показатели по составу службы каталогов;
• индикатор общего состояния службы каталогов;
• ключевые метрики службы каталогов;
• топ-10 аномальных групп и топ-10 аномальных пользователей;
• рекомендации по оптимизации службы каталогов.

Вкладка «Группы» содержит сведения по всем группам безопасности: риск, содержимое, число вложенных групп и др. Вкладка «Пользователи» отображает всех пользователей с учётом настройки вывода заблокированных. Для каждого из них выведен базовый набор параметров, который может быть расширен: риск пользователя, динамика состава групп и др.

Во вкладках «Должности», «Подразделения», «Организационные единицы» (Organizational Units, OU) указаны число пользователей, однородность, количество уникальных групп. В карточках объектов представлена детализация.

Алгоритмы машинного обучения объединяют пользователей по схожести набора групп и формируют предложения по ролям, что отражено во вкладке «Ролевая модель». Реализованы 2 режима формирования проекта модели ролевого управления доступом (Role-Based Access Control, RBAC).

Таблица 8. Режимы формирования проекта модели RBAC

Экспорт результатов выполняется в единый Excel-файл с листами:

• Summary — сводка по ролевой модели, пользователям и группам.
• Роли — состав групп и пользователей для каждой роли.

При этом в интерфейсе отображается детализация по каждой роли в табличном и графовом видах.

Отметим, что алгоритмы работают на CPU (без GPU), но формирование ролевой модели для службы каталогов с более чем 10 000 пользователей может занимать часы. Рекомендуется сначала выполнить серию оценок состояния, привести службу каталогов в порядок и только потом запускать формирование ролей.

Объекты и системы

Модуль реализует объектоцентричную (entity-centric) модель — единую точку агрегации рисков из всех аналитических модулей платформы (xBA, Role Mining). Его задача — не генерировать новые аномалии, а собирать, связывать и визуализировать риски в контексте реальных объектов инфраструктуры.

Таблица 9. Информация об объектах в Dataplan 2.4

Принцип работы модуля: пользователь работает через учётную запись на хосте. Связь строится только через УЗ: прямая привязка «пользователь — хост» невозможна (физическое лицо не может работать на устройстве без логического представления).

Модуль «Объекты системы» не является самостоятельным инструментом анализа. Он — интегрирующий (связывающий) слой, превращающий разрозненные аномалии из разных модулей в целостную картину рисков инфраструктуры. Исторический трекинг связей в модуле отсутствует, отслеживается только их текущее состояние («кто с кем связан сейчас»), а не история изменений. Ценность модуля раскрывается при совместной работе с xBA и Role Mining — именно тогда появляется возможность отследить полный путь угрозы: от изменения поведения к эскалации привилегий и доступу к критичным данным.

Настройка. Сведения о 3 типах объектов подключаются через таблицы в хранилище (предварительно заполненные коннекторами).

Таблица 10. Источники объектов

Доступна фильтрация «мусора» на этапе подключения, например:

• исключение локальных GUID ОС;
• фильтрация хостов по маске подсети;
• исключение системных учётных записей и др.

Источник указывается в карточке объекта — аналитик всегда видит, откуда взяты сведения (например, данные из службы каталогов, обновлено 11.02.2026 в 09:15). Если нет возможности выполнить автоматическое наполнение сведениями об объектах системы, то можно добавить их вручную.

Рисунок 36. Ручное добавление сведений об объекте системы

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

Граф связей в карточке объекта позволяет быстро оценить «поверхность атаки»:

• Один пользователь — несколько учётных записей — признак привилегированного доступа (администраторы). Если это не так, то это аномалия, требующая расследования.
• Одна учётная запись — несколько пользователей — нарушение принципа персональности. Требует расследования.
• Один хост — множество учётных записей — возможное совместное использование устройства. Это может означать, например, посменную работу разных операторов или инсайдерскую деятельность, когда 1 пользователь использует учётные данные другого для сокрытия действий или получения неправомерного доступа.

Рисунок 37. Граф связей в карточке объекта

Таблица 11. Формирование риска объекта

Детали по каждому источнику видны в карточке объекта. Для учётных записей и хостов доступен переход в карточку сущности в модуле xBA и карточку соответствующей учётной записи в Role Mining.

Статистика. Раздел содержит главный дашборд, на котором отображаются сведения по общему количеству объектов и по видам объектов, а также сведения по объектам, не содержащим связей. По каждому типу объектов приводится статистика по 10 наиболее критичным значениям, а также общее распределение по типам.

Рисунок 38. Статистика по 10 наиболее критичным объектам

Администрирование

Интерфейс администратора включает в себя панель навигации и логотип продукта, поисковую строку, разделы «Пользователь», «Управление уведомлениями», «Избранное» и общую сводку по состоянию системы.

Система разграничения доступа

Ролевая модель доступа. В Dataplan 2.4 реализована ролевая модель разграничения доступа:

• есть предустановленные роли и возможность создания произвольного числа кастомных ролей;
• ограничение — 1 пользователь может принадлежать только 1 роли. Такой подход упрощает аудит прав;
• гранулярность прав. Предусмотрены доступы к разделам интерфейса — «только чтение» / «чтение + запись», к данным — разрешение / запрет на определённые базы данных и таблицы в хранилище.

Так, например, если дашборд построен на данных из нескольких таблиц, а у пользователя нет доступа к части из них, то соответствующие чарты отобразятся с пометкой «Нет доступа к данным». Это предотвращает «слепые» дашборды с пустыми графиками. На уровне датасетов, чартов и дашбордов также есть возможность выдавать права доступа отдельным ролям и отдельным пользователям.

Аутентификация

В платформе реализованы разные варианты аутентификации пользователей:

• Доменная. Интеграция с контроллером домена. Есть возможность приглашать пользователей через выбор групп / УЗ из службы каталогов и автоматически отправлять уведомления по электронной почте (при настройке почтового сервиса).
• Локальная. Для изолированных контуров без доменной авторизации. Создание УЗ вручную с назначением пароля и роли.
• Атрибут «Администратор». Отдельный флаг для УЗ. Без него недоступны некоторые настройки платформы.

Рисунок 39. Варианты аутентификации пользователей

Карточка пользователя. Для каждой УЗ, доменной или локальной, отображается определённая информация. При доменной аутентификации показаны стандартные атрибуты из службы каталогов, включая должность, телефон и подразделение. Видна статистика входов: дата / время последнего успешного и неудачного входа, источник (IP-адрес, User-Agent). Отображены пользовательские объекты (дашборды, датасеты, чарты, рассылки, скрипты), к которым назначен доступ, и события аудита — действия пользователей в платформе.

Сессии. В системе реализована функция просмотра активных сессий: браузер, IP-адрес, время последнего действия. Возможно принудительное завершение сессий, что полезно при увольнении сотрудника или подозрении на компрометацию учётных данных.

Аудит и мониторинг

Предлагаются 2 типа подписок:

• системные события — запуск задач, изменение настроек, ошибки компонентов;
• события по объектам — уведомления о действиях с дашбордами, скриптами и др., созданными пользователем.

Уведомления отображаются в ленте интерфейса.

Для контроля инстанса есть базовая панель мониторинга состояния компонентов.

Рисунок 40. Базовая панель мониторинга состояния компонентов

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

Управление сервисами осуществляется через интерфейс: остановка / перезапуск компонентов без входа в консоль ОС.

Лицензирование и обновление

Во вкладке отображается информация о лицензии: срок действия, идентификация и др. Обновление лицензии возможно через загрузку файла без перезапуска платформы.

На странице размещён список всех компонентов с версиями и статусом совместимости.

Таблица 12. Встроенные пакеты для быстрого старта

Служебные настройки

Во вкладке можно настроить пароли суперпользователя, длительность сессии, резервное копирование, интеграцию с почтовыми сервисами, Syslog-рассылку и хранилище секретов.

Системные требования Dataplan 2.4

Платформа разворачивается в среде ОС Ubuntu 20.04 LTS, 22.04 LTS. Поддерживаются ОС отечественной разработки: Astra Linux (версия 1.7 и выше), ALT Linux, РЕД ОС. Развёртывание осуществляется полностью в контуре заказчика (on-premises) и не требует подключения к сети Интернет или взаимодействия с инфраструктурой вендора, что позволяет использовать решение в изолированных сегментах.

Технология — развёртывание в контейнерной среде (Docker).

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

Свободно распространяемое ПО Logstash, СУБД ClickHouse, СУБД PostgreSQL и веб-сервер Nginx, входящие в состав компонентов платформы, включены в дистрибутив платформы и устанавливаются автоматически.

Сервер, предназначенный для установки ПО (при типовой нагрузке 1 ГБ входных данных в сутки), должен соответствовать следующим требованиям.

Таблица 13. Аппаратные требования к серверу для установки Dataplan 2.4

Для комфортной работы NGR Softlab рекомендует использовать монитор с диагональю не менее 24 дюймов и разрешением экрана Full HD 1920×1080.

Применение Dataplan 2.4

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

• организации с более чем 1 000 пользователей и разветвлённой инфраструктурой прав доступа;
• изолированные контуры (в т. ч. ГИС, АСУ ТП), где требуется полностью автономное решение;
• команды ИБ, которые уже имеют SIEM / DLP, но нуждаются в «аналитическом слое» для поиска скрытых угроз;
• администраторы и подразделения эксплуатации инфраструктуры, которым нужно быстро оценить «здоровье» службы каталогов без ручных скриптов.

Рассмотрим использование решения NGR Softlab на конкретных примерах.

Контроль доступа к ресурсам мейнфреймов

У заказчика — крупная распределённая инфраструктура: более 100 баз данных и более 80 прикладных систем, работающих в изолированном сегменте. Доступ к ресурсам осуществляется пользователями со всей страны, что формирует высокий и постоянно изменяющийся поток запросов. Ситуация была осложнена следующими моментами:

• логирование отключено из-за высокой нагрузки;
• вендор прекратил поддержку, экспертиза ограничена;
• периодически фиксируются утечки данных.

Внедрение Dataplan обеспечило выявление скомпрометированных УЗ и инсайдерской деятельности, хранение данных о доступе пользователей к БД, анализ запросов, поведенческую аналитику и статистическую отчётность, а также отправку уведомлений по электронной почте и в интерфейс.

Оценка состояния и выявление аномалий в службе каталогов

У заказчика — распределённая инфраструктура, где более 100 000 пользователей и свыше 90 000 групп безопасности. Служба каталогов эксплуатируется более 15 лет и за это время прошла через несколько этапов развития, включая слияния организаций и присоединение доменных структур. Были и другие изменения: смена подразделений, отвечающих за эксплуатацию и сопровождение. На момент внедрения — большое число администраторов.

В результате в каталоге сформировались неоднородные и трудно контролируемые модели прав доступа, включая аномальные привилегии и случаи «мимикрии» УЗ.

После интеграции Dataplan для анализа состояния службы каталогов и выявления аномалий были реализованы следующие функции:

• ежедневная оценка состояния службы каталогов;
• выявление аномальных групп и пользователей с нетипичными или избыточными привилегиями;
• формирование статистики по устаревшим сервисным и административным УЗ;
• подготовка данных для построения целевой модели ролевого управления доступом (Role-Based Access Control, RBAC).

В результате ИБ- и ИТ-подразделения получили инструмент регулярного контроля состояния AD и основу для последующей нормализации и перестройки модели управления доступом.

Мониторинг работы с внутренними веб-ресурсами

У заказчика — организация с численностью 2 000 пользователей, при этом порядка 80 % сотрудников работают в удалённом формате. Внутренняя цифровая среда включает веб-сервисы с чувствительной информацией: корпоративные вики, системы управления задачами, системы контроля версий и др. Большая часть доступа осуществляется с личных устройств без дополнительных средств защиты информации и агентов. Были зафиксированы случаи обхода функциональности со стороны конкурентов и анализа коммерческих предложений через доступные интерфейсы.

Внедрение Dataplan позволило выполнить постобработку данных (agent source + URL parsing), агрегацию событий доступа, реализовать поведенческую аналитику на основе агрегированных данных, сформировать статистическую отчётность по использованию веб-ресурсов, выявить инсайдерскую деятельность. Обеспечена передача данных во внешние системы.

Выводы

Dataplan 2.4 — аналитическая платформа, позволяющая оперативно выявлять аномалии в поведении объектов, инсайдерские угрозы и компрометацию. Её возможности позволяют понять, что происходит внутри инфраструктуры, кто и что представляет опасность, и на основании этого принимать обоснованные data-driven-решения при расследовании инцидентов.

Платформа NGR Softlab — не замена классических средств защиты информации, а дополнение для поиска того, что они не выявляют. Она работает там, где классические правила корреляции неэффективны: при анализе «серой зоны» между легитимной и явно вредоносной активностью.

Достоинства:

• гибкость подключения источников без зависимости от вендоров;
• минимизация нагрузки на инфраструктуру (забирает только поля, необходимые для анализа поведения, не дублирует полные журналы событий);
• работа в изолированных контурах без интернета;
• интеграция поведенческого анализа и анализа привилегий;
• сценарии генерации аналитики «из коробки»;
• объектоцентричная модель — вместо переключения между модулями единый интерфейс со всеми рисками по пользователю / хосту;
• включение в реестр отечественного ПО.

Недостатки:

• меньше готовых коннекторов, чем у классических СЗИ;
• ретроспективный анализ (не в реальном времени);
• ограниченная гранулярность ролевой модели;
• отсутствие исторического трекинга связей в «Объектах системы».