🟩 Инженерная экспертиза корпоративных информационных систем для иска

🟩 Инженерная экспертиза корпоративных информационных систем для иска

Методы выявления цифровых следов КИС в суде

Глава 1. Введение: КИС как объект инженерного анализа 🏢🔧

Корпоративные информационные системы (КИС) — ERP (SAP, Oracle, 1С, Microsoft Dynamics), CRM (Salesforce, HubSpot, AmoCRM), BI (Power BI, Tableau), SCM, HRM и другие — стали цифровым скелетом современного предприятия. Они аккумулируют финансовые, логистические, производственные и управленческие данные. Когда возникает спор — о некачественном внедрении, о хищении базы клиентов, о манипуляции с отчётностью — данные из КИС становятся ключевыми доказательствами. Инженерная экспертиза корпоративных информационных систем (КИС) для подачи иска в суд — это комплексное исследование, основанное на анализе низкоуровневых источников: моделей данных, логов аудита, транзакционных журналов, дампов памяти, файловых систем. Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/) разработал инженерную методологию для таких исследований. 🎯

Глава 2. Инженерная классификация КИС по способу хранения и архитектуре 🏗🔬

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

Локальные КИС (on-premise): Серверы и базы данных находятся на территории организации. Эксперт может работать с образами дисков, базами данных, логами ОС. 🖥️

Облачные КИС (SaaS): Данные у провайдера (Salesforce, HubSpot, AmoCRM, Power BI Service). Эксперт работает через API, логи аудита, экспорт метаданных. ☁️

Гибридные. Часть данных локально, часть в облаке. 🔄

2.2. По типу СУБД:

Реляционные СУБД (MS SQL, Oracle, PostgreSQL, MySQL). Транзакционные логи (LDF, redo logs, WAL, BInlog) фиксируют каждое изменение. 🗄️

NoSQL (MongoDB, Cassandra). Специфические механизмы аудита.

Файловые базы (1С файловый вариант,.1CD). Carving, анализ структуры файла. 📁

2.3. По архитектуре приложения:

Модульные КИС (SAP, Dynamics). Разные модули (FI, CO, MM, SD) могут иметь разные источники следов.

CRM-системы (Salesforce, HubSpot, AmoCRM). Журналы аудита, API-логи, Connected Apps.

BI-системы (Power BI, Tableau)..BIm, M-код, DAX, RLS.

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

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

3.1. Журналы аудита прикладного уровня:

SAP: CDHDR/CDPOS (журнал изменений документов), SM21 (системный журнал), STAD (журнал производительности). 🗒️

Microsoft Dynamics 365: AudIT Logs (Dataverse), Power Automate Run History. 📊

1С: Журнал регистрации (1Cv8.lgd), таблицы аудита в SQL.

CRM (Salesforce, HubSpot, AmoCRM): AudIT Log, API Logs, Connected Apps.

BI (Power BI, Tableau): AudIT Logs, Refresh History, Version History.

3.2. Транзакционные логи СУБД (для on-premise):

MS SQL: .ldf (файлы логов транзакций) — читаются через fn_dblog, ApexSQL Log. 🗄️

Oracle: Redo logs, archived logs — читаются через LogMiner. 🔐

PostgreSQL: WAL (WrITe-Ahead Log) — pg_waldump. 📁

MySQL: BInlog — mysqlBInlog. 📊

3.3. Системные журналы ОС и веб-серверов:

Windows: Event Logs (SecurITy, Application, System), логи IIS. 💻

Linux: syslog, auth.log, логи Nginx/Apache. 🐧

3.4. Файлы метаданных и конфигурации:

Power BI: .pBIx →.zip →.BIm (JSON), M-код. 📐

Tableau: .twb (XML). 📁

1С: .cf,.dt,.1CD. 🗂️

SAP: транспортные запросы (TMS), настройки транзакций.

3.5. Клиентские устройства (компьютеры пользователей): История браузера, загруженные файлы, pagefile.sys, hiberfil.sys. 💾

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

Глава 4. Кейс первый: Логическая бомба в 1С — взыскание ущерба с уволенного программиста 💣👨💻

Фабула дела: ООО «ПромТех» после увольнения программиста 1С (Орлова) через три недели обнаружило, что из системы пропали все счета по крупному клиенту — на 50 млн рублей. Орлов отрицал. Суд назначил инженерная экспертиза корпоративных информационных систем (КИС) для подачи иска в суд. 🧐

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

Анализ файла базы.1CD (до и после увольнения). Эксперт получил резервную копию базы за день до увольнения Орлова и текущую базу. Сравнил структуру и код модулей. Обнаружил, что в текущей базе в модуле документа «Реализация» добавлен фрагмент кода:

1c

Если ТекущаяДата() > Дата(2023,10,15) и Пользователь <> «Администратор» Тогда

СуммаДокумента = 0;

ЗаписатьВЖурнал(«Ошибка: документ не проведён»);

Отказ = Истина;

КонецЕсли;

Это классическая «логическая бомба»: после 15 октября (дата увольнения + 3 дня) для всех, кроме администратора, обнулять сумму документа и не проводить его. 💣

Анализ журнала регистрации 1С (файл 1Cv8.lgd). Эксперт восстановил удалённые записи журнала (carving с использованием hex-редактора). Нашёл, что изменение внесено пользователем ORLOV_DEV 12 октября в 19: 30. IP-адрес совпадает с его рабочим компьютером. 🧬

Анализ компьютера Орлова (изъят по определению суда). Создан образ диска (wrITe-blocker, хеш SHA-256). В дампе оперативной памяти (файл hiberfil.sys) найден открытый Конфигуратор 1С с этим кодом. Также файл notes.txt на рабочем столе: «Активация 15.10. Если уволят — пусть мучаются». 🗒️

Восстановление удалённых счетов. Эксперт восстановил счета из резервной копии. Пересчитал ущерб — 50 млн рублей. 🔄

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

В конфигурацию 1С внесена «логическая бомба».

Код внедрён пользователем ORLOV_DEV за 3 дня до увольнения.

Ущерб — 50 млн рублей.

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

Инженерный вывод: Анализ.1CD, журнала регистрации и дампа памяти позволяет инженерно доказать факт внедрения «логической бомбы» в 1С. 🔐

Глава 5. Инженерная методология анализа транзакционных логов СУБД 🗄🔬

Транзакционные логи — один из наиболее надёжных источников, так как они фиксируют каждое изменение данных, даже если аудит на прикладном уровне был отключён. Методология:

5.1. MS SQL Server (.ldf):

Утилита fn_dblog (функция SQL Server) для чтения лога.

ApexSQL Log — коммерческий инструмент с GUI.

Поиск операций DELETE, UPDATE, INSERT в интересующих таблицах. 🔍

5.2. Oracle (redo logs, archived logs):

LogMiner (встроенный инструмент Oracle).

Поиск SQL-запросов, восстановление удалённых записей. 🗄️

5.3. PostgreSQL (WAL):

pg_waldump — утилита для чтения WAL.

Поиск изменений по временным меткам. 📊

5.4. MySQL (BInlog):

mysqlBInlog — утилита для чтения BInlog.

Поиск операций, восстановление данных. 📁

5.5. Инженерные аномалии: 🔍

Массовые DELETE в нерабочее время.

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

Запросы от имени неожиданных пользователей.

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

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

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

Анализ 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-кода, истории версий и логов обновления доказывает подмену источника данных. 🔑

Глава 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. Кейс третий: Хищение базы клиентов из AmoCRM — взыскание ущерба с бывшего менеджера 🗂👨💼

Фабула дела: ООО «ТоргСервис» уволило менеджера Иванова. Через месяц крупный клиент, с которым Иванов вёл переговоры, перешёл к конкуренту — новому работодателю Иванова. Ущерб от потери клиента составил 25 млн рублей. Иванов утверждал: «Я не копировал базу клиентов». Суд назначил инженерная экспертиза корпоративных информационных систем (КИС) для подачи иска в суд. 🧐

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

Выгрузка аудита AmoCRM. Эксперт через API выгрузил записи аудита за 3 месяца. Обнаружил: 15 марта в 23: 30-02: 00 пользователь Ivanov выполнил экспорт 150 контактов. В поле action — export, в object — contact. Количество экспортированных записей — 150. 📊

Анализ API-логов. В API-логах (доступны в настройках AmoCRM) эксперт нашёл вызовы метода /api/v4/contacts/export. Параметры: limIT=150. IP-адрес вызовов — 85.xx.xx.xx. По данным провайдера, IP принадлежит домашнему компьютеру Иванова. 🌐

Анализ компьютера Иванова (изъят по определению суда). Создан образ диска (wrITe-blocker, хеш SHA-256). В файловой системе найден файл clients_export_ivanov.csv. Анализ метаданных: дата создания — 16 марта 03: 00, автор — Ivanov. Хеш-сумма файла вычислена и сверена с эталонным экспортом из CRM (восстановлен из временных файлов). Совпадение. 🔐

Анализ истории браузера. В файле History (Chrome) найдены записи посещения страницы экспорта AmoCRM в ту же ночь. URL содержал параметры экспорта. 🌍

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

Иванов произвёл массовый экспорт контактов в ночь перед увольнением.

Файл экспорта обнаружен на его компьютере.

Установлена причинно-следственная связь между экспортом и переходом клиента к конкуренту.

Результат: Суд взыскал с Иванова 25 млн рублей. Возбуждено уголовное дело по ст. 183 УК РФ. 🚔

Инженерный вывод: Анализ аудита, API-логов и компьютера доказывает факт копирования базы клиентов. 🔑

Глава 9. Инженерная методология анализа клиентских устройств 💻🔍

При подозрении на копирование базы (кейс 3) исследуется компьютер сотрудника. Методология:

9.1. Создание образа диска. WrITe-blocker, побитовое копирование. Хеш-суммы SHA-256. 💾

9.2. Поиск файлов экспорта. Поиск по маскам (*.csv, *.xlsx, *.json), содержащим данные из КИС. Анализ метаданных (дата создания, автор). 📁

9.3. Анализ истории браузера. Файлы History (Chrome), places.sqlITe (Firefox). Поиск URL страниц экспорта. 🌐

9.4. Анализ файла подкачки (pagefile.sys) и гибернации (hiberfil.sys). Поиск фрагментов CSV-файлов, которые были в памяти. 🔍

9.5. Анализ переписки (при предоставлении доступа). Поиск вложенных файлов с данными из КИС. 📧

9.6. Сравнение хеш-сумм. Хеш файла на компьютере сотрудника сравнивается с хешем эталонного экспорта из КИС. Совпадение — доказательство копирования. 🔐

Глава 10. Инженерная методология анализа RLS (Row-Level SecurITy) 🎭🔧

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

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

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

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

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

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

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

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

Глава 11. Типовые инженерные вопросы суда к эксперту по КИС 📝❓

Группа 1. Анализ кода и логических бомб: 💣

Содержит ли код КИС (модули, скрипты, хранимые процедуры) недокументированные фрагменты, изменяющие результат в зависимости от даты или имени пользователя? Если да, то какова их логика? Кто и когда внёс изменения? (Подтверждение: сравнение резервных копий, метаданные изменений.)

Группа 2. Подключение к источникам данных: 🔗
2. К какому источнику данных подключена КИС? Соответствует ли это договору/ТЗ? Если нет, то когда и кем было изменено подключение? (Подтверждение: M-код, история версий.)

Группа 3. Аудит и фальсификация данных: 🔍
3. Имеются ли в журналах аудита, транзакционных логах СУБД записи о внесении изменений в учётные данные задним числом? Если да, то какие изменения, когда, с какой учётной записи, с какого IP-адреса? (Подтверждение: аудит, транзакционные логи.)

Группа 4. RLS (Row-Level SecurITy): 🎭
4. Настроены ли правила RLS? Если да, то какие роли, правила, кто в какие роли входит? Были ли созданы новые роли перед предоставлением отчёта в суд? (Подтверждение: .BIm, AudIT Logs.)

Группа 5. Массовый экспорт данных: 📤
5. Производил ли пользователь X массовый экспорт контактов/сделок за период? Если да, то сколько записей, в какое время, с какого IP-адреса? (Подтверждение: аудит, API-логи.)

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

12.1. Отключенный аудит / отсутствие истории версий. Эксперт анализирует системные журналы КИС (кто отключил, когда). Для BI — анализирует теневые копии (Volume Shadow Copy). 💾

12.2. Удалённые файлы.pBIx /.1CD / бэкапы. Анализ Refresh History (Power BI) или логов аудита (публикации). Carving из нераспределённого пространства. 📜

12.3. Шифрование базы данных. Запрос ключей через суд. Если утеряны — анализ дампов оперативной памяти. 🔐

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

12.5. Отсутствие доступа к КИС ответчика. Ходатайство об истребовании доказательств (ст. 66 АПК). Суд может обязать ответчика предоставить образы дисков, выгрузки, логи. 📜

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

Штатные инструменты КИС (на предоставленном доступе): 🟢

SAP: SE16N, SM21, CDHDR/CDPOS, SUIM, DBACOCKPIT, AL11.

1С: Конфигуратор, журнал регистрации, выгрузка.dt.

Microsoft Dynamics 365: AudIT Logs (Dataverse), Power Automate Run History.

CRM (Salesforce, HubSpot, AmoCRM): AudIT Log, API Logs.

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

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

X-Ways Forensics / EnCase — анализ образов дисков, carving.

VolatilITy Framework — анализ дампов оперативной памяти.

WinMerge / Beyond Compare — сравнение кода, файлов.

ApexSQL Log / LogMiner / pg_waldump / mysqlBInlog — анализ транзакционных логов.

Python (pandas, requests) — массовый анализ выгрузок.

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

Неразрушающий контроль: работа с образами и копиями.

Chain of Custody.

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

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

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

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

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

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

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

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

Уважаемые юристы, специалисты, руководители! Мы представили инженерную методологию инженерная экспертиза корпоративных информационных систем (КИС) для подачи иска в суд: анализ кода, транзакционных логов, M-кода, RLS, аудита, клиентских устройств. Три кейса:

✅ Кейс 1 (логическая бомба в 1С) — анализ.1CD, журнала регистрации, дампа памяти.
✅ Кейс 2 (подмена источника в Power BI) — M-код + история версий + логи обновления.
✅ Кейс 3 (хищение базы из AmoCRM) — аудит + API-логи + анализ компьютера.

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

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

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

Chain of Custody.

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

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

Сертифицированные инженеры по SAP, 1С, Dynamics, CRM, BI.

100+ экспертиз КИС.

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

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

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

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

Инженерная экспертиза корпоративных информационных систем (КИС) для подачи иска в суд — это единственный способ превратить данные КИС в бесспорные судебные доказательства. 🦾

🟩 Союз «Федерация судебных экспертов» — инженерная истина в КИС. 🟩

Похожие статьи

Новые статьи

🟩 Разоружение лжеэкспертизы:  стратегическое рецензирование судебно-психиатрической экспертизы как инструмент отмены первичного заключения

Методы выявления цифровых следов КИС в суде Глава 1. Введение: КИС как объект инженерного анализа 🏢🔧 Кор…
независимая экспертиза, судебная экспертиза, техническая экспертиза

🟩 Строительный подход к экспертизе: профессиональный расчет несущей способности грунта основания

Методы выявления цифровых следов КИС в суде Глава 1. Введение: КИС как объект инженерного анализа 🏢🔧 Кор…

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

Методы выявления цифровых следов КИС в суде Глава 1. Введение: КИС как объект инженерного анализа 🏢🔧 Кор…

🟩 Судебная экспертиза коробки передач:  методологический алгоритм установления причин отказов

Методы выявления цифровых следов КИС в суде Глава 1. Введение: КИС как объект инженерного анализа 🏢🔧 Кор…

🟩 Экспертное исследование мостовых сооружений: расчет несущей способности моста как ключевой элемент судебной и независимой экспертизы

Методы выявления цифровых следов КИС в суде Глава 1. Введение: КИС как объект инженерного анализа 🏢🔧 Кор…

Задавайте любые вопросы

0+12=