Для подачи иска в суд методологическое руководство

Системы Business Intelligence (BI) — Power BI, Tableau, Qlik Sense, SAP BusinessObjects — стали критически важными инструментами для принятия управленческих решений. Они агрегируют данные из множества источников (ERP, CRM, баз данных, Excel) и представляют их в виде дашбордов и отчетов. Когда возникает судебный спор — о фальсификации отчетности, о недостоверности KPI, о хищениях через искажение данных — именно BI-отчеты становятся ключевым доказательством. Однако суд не может принять распечатку дашборда как безусловную истину. Как инженерно доказать, что данные в отчете были сфальсифицированы? Как восстановить историю изменений? Как выявить подмену источника данных? Ответы на эти вопросы дает инженерная экспертиза систем Business Intelligence для подачи иска в суд.

Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/) разработал методологию исследования BI-систем. В данной статье, написанной в методологическом ключе, мы представим: классификацию объектов, методы извлечения и анализа, восстановление удаленных данных, перекрестную верификацию, а также приведем три реальных кейса. Статья предназначена для экспертов, юристов и IT-специалистов.

Глава 1. Методологические основы инженерной экспертизы BI-систем

BI-система — это многоуровневый программный комплекс. Уровни: источники данных (базы данных SQL, файлы Excel, облачные API); ETL/ELT (Power Query M, Tableau Prep, Qlik Load Script); семантическая модель (метаданные, связи, вычисляемые поля, меры DAX/MDX); визуализация (дашборды, отчеты); серверная часть (логи, репозиторий, управление доступом). Инженерная экспертиза систем Business Intelligence для подачи иска в суд требует владения инструментами анализа каждого уровня.

Глава 2. Классификация объектов экспертизы в BI-системах

Источники доказательств по степени надежности:

• Уровень A (наивысшая надежность) — логи BI-серверов (Office 365 Management Activity API для Power BI, база данных репозитория для Tableau и Qlik).

• Уровень B — резервные копии файлов отчетов и баз данных репозитория.

• Уровень C — файлы отчетов (.pbix, .twb/.twbx, .qvf).

• Уровень D — ETL-скрипты.

• Уровень E — распечатки и скриншоты (низшая надежность).

Эксперт обязан начинать исследование с наиболее надежных источников.

Глава 3. Методология консервации и извлечения данных из BI-систем

Консервация — первый критический этап. Методология:

• Для облачных BI — выгрузка метаданных через API (Power BI: Export-PowerBIReport), запрос логов через Office 365 Management Activity API, нотариальный осмотр дашбордов.

• Для on-premise — graceful shutdown сервера, создание побитовых образов дисков с помощью аппаратных write-blocker-ов, затем анализ файлов БД и логов.

• Для Desktop BI — изъятие файлов .pbix, .twbx, .qvf с фиксацией хеш-сумм SHA-256.

• Chain of custody — регистрация каждого файла, передача по акту.

Глава 4. Методология анализа файлов Power BI (.pbix)

Файл .pbix — ZIP-архив. Методология:

• Распаковка (7-zip).

• Анализ DataModelSchema (JSON) — поиск подозрительных мер DAX: IF(MAX(Table[Date]) = DATE(2023,12,31), [Revenue]*1.25, [Revenue]).

• Анализ DataModelStorage — извлечение сжатых данных, сравнение с исходными.

• Анализ Connections — проверка источника данных (Server, Database).

• Анализ метаданных — дата создания, автор.

• Сравнение версий — diff между .pbix.

Глава 5. Кейс № 1: Power BI — выявление DAX-формулы, завышающей KPI на 25%

Техническая фабула: Акционеры розничной сети заподозрили генерального директора в завышении KPI для получения бонуса (27 млн руб.).

Эксперты применили методологию:

• Изъяли файлы .pbix за 6 месяцев.

• Распаковали каждый.

• В DataModelSchema нашли меру DAX: KPI_Actual = IF(MAX(Table[Date]) = DATE(2023,12,31), [Revenue]*1.25, [Revenue]).

• Сравнили с версией от 01.12.2023 — этой меры не было, она появилась 20.12.2023.

• Метаданные ZIP-файла показали автора последнего изменения — пользователь с ID генерального директора.

• Дополнительно проверили журналы Power BI Service (Office 365 Management Activity API) — нашли запись UpdateReport от 20.12.2023 09:15 с IP-адреса директора.

Суд удовлетворил иск.

Глава 6. Методология анализа Tableau (.twb/.twbx)

Tableau использует .twb (XML) и .twbx (ZIP-архив с данными). Методология:

• Распаковка .twbx.

• Анализ XML-файла .twb: тег <connection> — источник данных (class, dbname, server). Тег <calculated-field> — вычисляемые поля. Поиск подозрительных формул: IF [Date] = #2023-12-31# THEN [Revenue]*1.25 ELSE [Revenue] END.

• Анализ экстрактов .hyper (база данных SQLite) — извлечение данных и сравнение с исходными.

• Анализ логов Tableau Server (база данных репозитория PostgreSQL) — таблицы _connections, _history. Запрос: SELECT * FROM _connections WHERE user=’fin_director’ AND date>’2023-12-09′.

Глава 7. Кейс № 2: Tableau Server — подмена источника данных, выявленная через логи репозитория

Техническая фабула: Финансовый директор перед налоговым аудитом изменил источник данных в дашборде Tableau с prod_db на audit_copy_db (где были скрыты убытки на 56 млн руб.).

Эксперты:

• Получили доступ к базе данных репозитория Tableau Server (PostgreSQL).

• Выполнили SQL-запрос: SELECT user, action, old_value, new_value, ip, time FROM _connections WHERE user=’fin_director’ AND action=’change_connection’ AND time > ‘2023-12-09’.

• Обнаружили запись: 10.12.2023 14:23:45 — old_value=’prod_db’, new_value=’audit_copy_db’.

• IP-адрес (192.168.1.100) совпал с рабочей станцией финдиректора.

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

Суд удовлетворил иск.

Глава 8. Методология анализа Qlik Sense (.qvf и Repository)

Qlik Sense: файл приложения .qvf (ZIP-архив) и база данных Repository (PostgreSQL). Методология:

• Распаковка .qvf.

• Анализ файла LoadScript — скрипты загрузки данных на языке Qlik. Поиск подозрительных строк: WHERE условия, отсекающие данные; SET переменные, изменяющие значения; IF условия в скриптах.

• Анализ Repository: таблица logs (история изменений приложений). Запрос: SELECT user, action, script_hash, time FROM logs WHERE app_name=’Sales_Report’.

• Восстановление удаленных приложений из бэкапов Repository (SQL-дампов).

Глава 9. Кейс № 3: Qlik Sense — восстановление удаленной истории из таблицы logs Repository

Техническая фабула: Экс-администратор BI перед увольнением удалил историю обновлений дашборда Qlik Sense, где были зафиксированы его манипуляции (завышение продаж на 15–20% перед квартальными отчетами).

Эксперты:

• Получили доступ к серверу Qlik Sense.

• Подключились к базе данных Repository (PostgreSQL).

• Выполнили запрос: SELECT user, action, script_diff, time FROM logs WHERE app_name=’Sales_Report’ AND user=’admin’ AND time > ‘2022-01-01’.

• Извлекли 345 записей за 2 года.

• Анализ script_diff показал, что администратор изменял Load Script, добавляя коэффициент 1.15 к сумме продаж перед каждым квартальным отчетом.

• Сопоставили временные метки с логами входа.

Суд удовлетворил иск.

Глава 10. Методология анализа логов BI-серверов (Power BI Service, Tableau Server)

Логи BI-серверов — «черный ящик». Методология:

• Power BI Service — Office 365 Management Activity API (PowerShell: Search-UnifiedAuditLog -Operations «CreateReport»,»UpdateReport»,»DeleteReport»,»ViewReport»). Выгрузка в CSV, анализ IP-адресов, пользователей.

• Tableau Server — доступ к базе данных репозитория (PostgreSQL). Таблицы: _history (запуски отчетов), _background_tasks (фоновые задачи), _connections (источники).

• Qlik Sense — таблица logs (Repository).

• Поиск аномалий: массовый экспорт отчетов (>100 за час), изменение источников данных, удаление отчетов перед аудитом, активность в нерабочее время (00:00–06:00).

Глава 11. Методология восстановления удаленных отчетов из резервных копий

Удаление отчета не всегда окончательно. Методология:

• Power BI Service — корзина (хранится 90 дней). Восстановление через интерфейс или API.

• Tableau Server — резервные копии репозитория (SQL-дампы). Восстановление базы данных на тестовом сервере, извлечение удаленных отчетов.

• Qlik Sense — резервные копии Repository (SQL-дампы).

• Desktop BI — теневые копии Windows (VSS), корзина, временные файлы.

• Оценка полноты восстановления: R = N_восстановленных / N_удаленных (по логам).

Глава 12. Методология анализа ETL-скриптов (Power Query M, Tableau Prep, Qlik Load Script)

ETL-скрипты — код, который загружает и трансформирует данные. Методология:

• Power Query M — извлечение из .pbix (файл DataModelSchema или Report). Поиск конструкций: Table.SelectRows с условиями (например, each [Value] >= 0 — отбрасывание отрицательных значений), Table.TransformColumns с вычислениями.

• Tableau Prep — анализ .tfl файлов (JSON).

• Qlik Load Script — анализ LoadScript из .qvf. Поиск WHERE, DROP, SET.

• Сравнение с эталонной версией — diff скриптов из резервных копий.

• Восстановление удаленных строк — запуск скрипта без фильтров на тестовых данных.

Глава 13. Методология перекрестной верификации с источниками данных

Самый надежный метод проверки — сравнение BI-отчета с первичными источниками (ERP, CRM, базы данных). Методология:

• Идентификация источников — анализ Connections в .pbix или .twb.

• Выгрузка данных из источников — SQL-запросы к базам данных, экспорт из ERP.

• Повторный ETL — запуск ETL-скрипта (Power Query, Tableau Prep) на тестовой среде.

• Сравнение — вычисление расхождения Δ = |X_bi — X_source| / X_source для каждого числового показателя.

• Документирование — таблица расхождений прикладывается к заключению.

Глава 14. Методология оценки достоверности и целостности отчетов BI

Метрологический подход:

• Хеш-суммы SHA-256 — для каждого файла отчета.

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

• Перекрестная верификация — сопоставление данных отчета с данными из первичных источников (≥2 источников).

• Статистическая оценка — для выявленных аномалий вычисляется p-value (вероятность случайного возникновения). При p < 0.001 аномалия считается значимой.

• Указание погрешности — для временных меток ±1 с, для сумм ±0,01%.

Глава 15. Заключение: инженерная экспертиза BI — фундамент правосудия

Инженерная экспертиза систем Business Intelligence для подачи иска в суд — это сложная, но формализованная методологическая дисциплина.

В статье представлена методология: классификация источников, консервация, анализ файлов Power BI (DAX), Tableau (XML, логи репозитория), Qlik (скрипты, Repository), анализ логов серверов, восстановление удаленных отчетов, анализ ETL-скриптов, перекрестная верификация с источниками. Три кейса (Power BI — завышение KPI; Tableau — подмена источника; Qlik — восстановление из логов) демонстрируют практическую применимость.

Повторим ключевую фразу: инженерная экспертиза систем Business Intelligence для подачи иска в суд — единственный способ получить инженерно обоснованные доказательства из BI-отчетов. Союз «Федерация судебных экспертов» (https://kompexp.ru/) готов помочь. Обращайтесь! 🟩