Методы выявления цифровых следов в судебном процессе

Глава 1. Введение: BI как объект инженерного анализа 📊🔧

Системы Business Intelligence (Power BI, Tableau, Qlik Sense, SAP Analytics Cloud, Looker, OLAP-кубы SSAS) агрегируют данные из ERP, CRM, 1С и других источников. Когда возникает спор — о манипуляции с отчётностью, о завышении KPI для бонусов, о «логических бомбах» уволенного разработчика — BI-система становится полем битвы. Инженерная экспертиза систем Business Intelligence для подачи иска в суд — это комплексное исследование, основанное на анализе низкоуровневых источников: моделей данных, DAX/MDX-формул, M-кода, RLS-настроек, логов обновления и аудита. Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/) разработал инженерную методологию для таких исследований. 🎯

Глава 2. Инженерная классификация BI-систем по способу хранения и логики 🏗️🔬

2.1. По способу развёртывания:

Облачные BI: Power BI Service, Tableau Cloud, Qlik Cloud. Данные и модель у провайдера. Эксперт работает через API, логи аудита, экспорт метаданных. ☁️

Локальные BI (on-premise): Power BI Report Server, Tableau Server, Qlik Sense Enterprise, SSAS. Эксперт работает с образами дисков, базами данных, файлами метаданных. 🖥️

2.2. По типу модели:

Табличные модели (Power BI, SSAS Tabular): Данные в колоночных базах VertiPaq. Логика — на DAX (Data Analysis Expressions). 📐

Многомерные модели (SSAS Multidimensional): Данные в кубах. Логика — на MDX (Multidimensional Expressions). 🧊

Интерактивные модели (Tableau, Qlik): Свои языки формул и скриптов.

Инженерный принцип: Способ развёртывания и тип модели определяют набор доступных источников цифровых следов. 🧩

Глава 3. Инженерная классификация источников цифровых следов в BI 📊🔍

3.1. Файлы метаданных модели:

Power BI: .pBIx (ZIP-архив), внутри — DataModelSchema (файл.BIm — JSON-представление модели), M-код в Power Query, DAX-формулы. 🗄️

Tableau: .twb (XML) — вся логика отчёта. 📁

Qlik: .qvf (приложение),.qvd (данные). Скрипты на Qlik Script.

3.2. Журналы аудита и логи обновления:

Power BI Service: AudIT Logs, Refresh History. 🌐

Tableau Server: AudIT Logs, Revision History. 📊

3.3. Параметры подключения к источникам данных (M-код / Tableau Connection): SQL-запросы, сервера, базы данных, таблицы. 🔗

3.4. Настройки безопасности RLS (Row-Level SecurITy): Правила, по которым разным пользователям показываются разные данные. 🎭

3.5. История версий (Version History): Power BI (OneDrive/SharePoint), Tableau (Revision History), Qlik (Qlik Cloud). ⏪

3.6. Системные журналы сервера (для on-premise): Логи ОС, логи веб-сервера (IIS, Nginx). 💾

Инженерный принцип: Максимальное количество независимых источников для перекрёстной верификации. 🔄

Глава 4. Кейс первый: Подмена источника данных в Power BI — завышение прибыли на 30 млн 💼💔

Фабула дела: АО «СтройГигант» заказало внедрение Power BI у интегратора «ИТ-Решения». После внедрения отчёты показывали прибыль 100 млн, а реальная (по 1С) — 50 млн. Ущерб — 30 млн. Интегратор: «Клиент сам всё сломал». Суд назначает инженерная экспертиза систем Business Intelligence для подачи иска в суд. 🧐

Инженерное исследование (Союз «Федерация судебных экспертов»):

Анализ M-кода в Power Query. Эксперт открыл.pBIx. Вместо = Sql.Database(«ProdServer», «RealDB») было = Sql.Database(«TestServer», «TestDB»). В TestDB суммы продаж завышены в 2 раза. 🗄️

Анализ истории версий.pBIx (OneDrive). Эксперт восстановил историю через SharePoint. Переключение с RealDB на TestDB сделано пользователем integrator_admin 15 марта. Комментарий — «Для демонстрации». После приёмки (20 марта) — не переключили. 📅

Анализ Refresh History (Power BI Service). Отчёт обновлялся каждую ночь с 21 марта по 20 апреля, источник — TestDB. Ни одного обновления с RealDB. 📊

Анализ AudIT Logs (Power BI Service). 20,21,25 марта пользователь integrator_admin заходил в настройки источника, но не менял. Знал о проблеме, не исправлял. 🕵️

Инженерные выводы: 🎯

Подключение изменено интегратором с продуктивной на тестовую.

Изменение до подписания акта, не исправлено после.

Отчёт обновлялся из тестовой базы весь период.

Результат: Ущерб 30 млн рублей взыскан. 🏆

Инженерный вывод: Анализ M-кода, истории версий и логов обновления доказывает подмену источника данных. 🔑

Глава 5. Инженерная методология анализа DAX-формул 📐🔬

5.1. Выгрузка модели в.BIm..pBIx →.zip → DataModelSchema (.BIm — JSON). 📁

5.2. Декомпиляция.BIm. Поиск подозрительных DAX-выражений:

dax

// Логическая бомба: проверка на дату

IF( TODAY() > DATE(2025, 1, 1) && USERPRINCIPALNAME() <> «admin@company.com»,

[Revenue] * 0.5 — [Costs] * 1.2,

[Revenue] — [Costs]

)

// Фальсификация: подстановка бюджета вместо продаж

ProfIT = SUM( ‘Sales'[Amount] ) * 1.5 — SUM( ‘Expenses'[Amount] ) / 2

5.3. Инженерный поиск аномалий: 🔍

Проверки на TODAY(), NOW(), DATE() — логические бомбы.

Умножение/деление на константы без обоснования.

USERPRINCIPALNAME() — разный результат для разных пользователей.

Сложные вложенные IF без комментариев.

5.4. Сравнение с резервными копиями. WinMerge, Beyond Compare. Выявление изменённых формул, автора («modifiedBy»), времени. 🔄

5.5. Верификация через историю версий.pBIx. OneDrive/SharePoint. Восстановление версии, где формула корректна. 🔐

Глава 6. Кейс второй: Логическая бомба в DAX-формуле при увольнении 💣👨‍💻

Фабула дела: АО «ТехноПром» после увольнения BI-разработчика Орлова через 2 недели отчёты показывали заниженную прибыль. Ущерб — 200 млн. Орлов отрицает. Суд назначает инженерная экспертиза систем Business Intelligence для подачи иска в суд. 🧐

Инженерное исследование (Союз «Федерация судебных экспертов»):

Выгрузка.BIm (до и после увольнения). В текущем.BIm в мере ProfIT:

json

«expression»: «IF( TODAY() > DATE(2024, 10, 15) && USERPRINCIPALNAME() <> \»admin@company.com\»,\n    [Revenue] * 0.5 — [Costs] * 1.2,\n    [Revenue] — [Costs]\n)»

Активация после 15 октября (увольнение + 3 дня) для всех, кроме администратора. 💣

Метаданные.BIm. «modifiedBy»: «ORLOV_DEV», «modifiedTime»: «2024-10-12T19: 33: 22Z» (за 3 дня до увольнения). 🧬

История версий.pBIx (OneDrive). Версия от 12 октября — формула корректна. Версия от 13 октября — с «бомбой». Автор — ORLOV_DEV. 📅

AudIT Logs Power BI Service. После увольнения отчёты публиковали другие, модель оставалась старой. «Бомба» не обнаружена. 🕵️

Восстановление корректных данных. Пересчёт по корректной формуле за 2 месяца. Разница — 200 млн. 🔄

Инженерные выводы: 🎯

В DAX-формулу внесена «логическая бомба».

Изменение внесено ORLOV_DEV за 3 дня до увольнения.

Ущерб — 200 млн.

Результат: Ущерб взыскан. Возбуждено уголовное дело по ст. 273 УК РФ. 🚔

Инженерный вывод: Анализ.BIm и истории версий доказывает внедрение «логической бомбы» в DAX. 🔐

Глава 7. Инженерная методология анализа M-кода (Power Query) 🔗🔬

7.1. Выгрузка M-кода. Из.pBIx или Power Query EdITor. 📁

7.2. Анализ подключений: 🔍

Sql.Database(«ProdServer», «RealDB») — правильно. Если «TestServer» — подмена.

Анализ SQL-запросов: WHERE amount > 0 — скрывает возвраты и расходы.

7.3. Анализ преобразований:

Table.SelectRows с фильтром, удаляющим часть данных.

Table.TransformColumns с изменением значений.

Table.RemoveRows — удаление строк без причины.

7.4. Поиск аномалий: M-код, подключающийся к нестандартным серверам, с закомментированной альтернативной логикой. 🔍

7.5. Сравнение с резервными копиями. Аналогично DAX. 🔄

Глава 8. Кейс третий: Манипуляция с RLS (Row-Level SecurITy) 🎭📊

Фабула дела: ООО «ТоргСервис». Гендиректор предоставил суду отчётность из Power BI с убытками. Миноритарий утверждал: компания прибыльна, директор скрывает прибыль через RLS. Суд назначает инженерная экспертиза систем Business Intelligence для подачи иска в суд. 🧐

Инженерное исследование (Союз «Федерация судебных экспертов»):

Анализ RLS-ролей в.BIm. Секция «roles»:

json

{ «name»: «Director», «memberShipRules»: [ { «memberShipRule»: «true()» } ] },

{ «name»: «MinorITyShareholder», «memberShipRules»: [ { «memberShipRule»: «[ProfIT] < 0» } ] }

Роль Director видит всё, MinorITyShareholder — только убытки. 🎭

Членство в ролях (Power BI Service). Директор — Director. Истец — MinorITyShareholder. 📊

AudIT Logs. Роль MinorITyShareholder создана пользователем admin (учётка директора) за 2 дня до передачи отчёта в суд. Изменения ночью. 🌙

Восстановление полных данных. Эксперт установил роль Director, обновил данные. Реальная прибыль — 50 млн. 🔄

Инженерные выводы: 🎯

RLS ограничивает доступ миноритария к прибыльным сделкам.

Суду предоставлен скриншот от урезанной роли.

Реальная прибыль — 50 млн.

Результат: Стоимость доли миноритария определена исходя из реальной прибыли. Директор привлечён за фальсификацию доказательств. 🚔

Инженерный вывод: Анализ RLS-настроек через.BIm и логов доказывает манипуляцию с правами доступа. 🔐

Глава 9. Инженерная методология анализа RLS 🎭🔧

9.1. Источники RLS:

.BIm (секция «roles») — Power BI.

.twb (XML-теги <securITy>) — Tableau.

Логи аудита (создание ролей, назначение пользователей). 📁

9.2. Анализ правил фильтрации. Проверка на искажающие условия ([ProfIT] < 0). 🔍

9.3. Анализ членства в ролях. Кто в какой роли. Выявление предоставления суду данных от урезанной роли. 🧑‍💻

9.4. Анализ времени создания ролей. Если роль создана перед судом — признак фальсификации. 📅

9.5. Восстановление полных данных. Имитация роли с максимальными правами (или отключение RLS). 🔄

Глава 10. Типовые инженерные вопросы суда к эксперту по BI 📝❓

Группа 1. Подключение к источникам данных: 🔗

К какому источнику данных подключён отчёт? Соответствует договору/ТЗ?

Имеются ли в истории изменений записи о переключении источника? Кто, когда, с какого IP?

Группа 2. Анализ формул DAX/MDX: 📐
3. Содержат ли меры условия, изменяющие результат в зависимости от даты или имени пользователя? Какова их логика?
4. Имеются ли в истории изменений DAX-формул записи о внесении изменений? Кто, когда, старые/новые значения?

Группа 3. RLS: 🎭
5. Настроены ли правила RLS? Какие роли, правила, кто в какие роли входит?
6. Были ли созданы новые роли или изменены правила перед предоставлением отчёта в суд?

Группа 4. Логи обновления и аудит: 📊
7. Какова история обновления данных? Какой источник использовался?
8. Кто и когда просматривал отчёт, публиковал новые версии, изменял настройки?

Глава 11. Инженерная методология анализа Tableau и Qlik 🔬📊

11.1. Tableau:

.twb (XML): параметры подключения, вычисляемые поля, RLS (<securITy>). 📁

Tableau Server: AudIT Logs, Revision History. 📊

Поиск в XML тегов <calculation> с подозрительными формулами, <connection> с нестандартными серверами, <securITy> с ограничениями. 🔍

11.2. Qlik Sense:

.qvf (ZIP): скрипты загрузки (Qlik Script). 📁

Логи выполнения скриптов, логи доступа Qlik Cloud. 🌐

Поиск в Qlik Script условий на дату (if today() >…), подмены источников (SQL SELECT…). 🔍

Инженерный принцип: Независимо от платформы, эксперт ищет: подмена источников, «бомбы» в формулах, манипуляции с RLS, изменения перед судом. 🎯

Глава 12. Инженерные ограничения и пути их преодоления 🚧🧠

12.1. Отсутствие истории версий. Анализ резервных копий сервера (бэкапы) или теневых копий (Volume Shadow Copy). 💾

12.2. Удалённые.BIm /.pBIx. Анализ Refresh History (схема данных) и AudIT Logs (публикации). 📜

12.3. Шифрование.pBIx. Запрос пароля через суд. Если утерян — анализ логов Power BI Service. 🔐

12.4. Облачная среда (нет прямого доступа). Удалённая экспертиза через API. Судебный запрос к провайдеру. ☁️

12.5. Отсутствие доступа к BI-системе ответчика. Ходатайство об истребовании доказательств (ст. 66 АПК). 📜

Глава 13. Инструментарий инженера-эксперта по BI 🛠️💻

Штатные инструменты BI: 🟢

Power BI: .pBIx,.BIm, M-код, AudIT Logs, Refresh History, Version History (OneDrive).

Tableau: .twb, AudIT Logs, Revision History, Tabcmd.

Qlik: .qvf, Qlik Script, AudIT Logs.

Внешние инструменты: 🔵

WinMerge / Beyond Compare — сравнение.BIm /.twb.

Python (json, xml, zipfile) — массовый анализ.

DAX Studio — анализ DAX из.BIm.

Power Shell: Export-PowerBIAudITLog.

Инженерные принципы: 🔒

Неразрушающий контроль: копии файлов.

Chain of Custody.

SHA-256 хеш-суммы.

Глава 14. Обеспечение допустимости инженерных доказательств 🔒⚖️

14.1. Лицензионное ПО. Никаких «пираток». 🚫

14.2. Chain of Custody. Фиксация: когда, у кого, в каком состоянии получены файлы. Хеш-суммы в протоколе. 🔐

14.3. Документирование методики. Каждый шаг описан для повторяемости. Ссылки на документацию. 📄

14.4. Изолированная среда. Для on-premise — образы дисков, виртуальная среда. 🛡️

14.5. Эксперт предупреждён по ст. 307 УК РФ. Уголовная ответственность за ложное заключение. ⚖️

Глава 15. Заключение: инженерная экспертиза BI как основа объективности 🏁📚

Уважаемые юристы, специалисты, руководители! Мы представили инженерную методологию инженерная экспертиза систем Business Intelligence для подачи иска в суд: .BIm, M-код, DAX, RLS, логи аудита. Три кейса:

✅ Кейс 1 (подмена источника) — M-код + история версий + логи обновления.
✅ Кейс 2 (логическая бомба в DAX) —.BIm + история версий + AudIT Logs.
✅ Кейс 3 (манипуляция RLS) —.BIm + членство в ролях + AudIT Logs.

Инженерные принципы: 🏆

Несколько независимых источников.

Работа с метаданными (.BIm,.twb) и логами.

Chain of Custody.

Независимость и ст. 307 УК РФ.

Почему Союз «Федерация судебных экспертов»: 🎯

Сертифицированные инженеры Power BI, Tableau, Qlik, SSAS.

50+ экспертиз BI.

Рецензированные методики.

Лицензионное ПО.

Независимость и ответственность.

Как заказать экспертизу: 📝 https://kompexp.ru/. Бесплатная консультация. Поможем сформулировать вопросы и подготовить ходатайство.