🟩 Компьютерная экспертиза корпоративных информационных систем

Техническое руководство

Введение: когда цифровая экосистема становится яблоком раздора

Корпоративные информационные системы (КИС) — это не просто программы. Это сложнейшие цифровые экосистемы, объединяющие ERP (1С, SAP, Oracle, Dynamics), CRM (Salesforce, HubSpot), SCM, BI (Power BI, Tableau), HRM и десятки интеграционных шин. Они управляют финансами, закупками, продажами, складами, персоналом, логистикой — всей операционной деятельностью крупного бизнеса. Когда между участниками корпоративных отношений возникает спор (с интегратором, между акционерами, с налоговой), данные КИС становятся главным полем битвы. 🏗️

Но в отличие от изолированной ERP-системы, КИС — это распределённая, гетерогенная среда. Данные мигрируют из CRM в ERP через ETL, из ERP в BI через Data Warehouse, из BI — в дашборды для совета директоров. И на каждом этапе они могут быть искажены, потеряны, подделаны. Компьютерная экспертиза корпоративных информационных систем (КИС) — это не просто «посмотреть логи» одной программы. Это комплексное, многоуровневое исследование всех компонентов: от журналов транзакций СУБД до DAX-формул в Power BI, от ETL-пакетов Azure Data Factory до кэшей клиентских приложений. Союз «Федерация судебных экспертов» представляет техническое руководство по проведению такой экспертизы. Три кейса покажут, как эксперты находят истину в цифровом лабиринте. 🛡️

Глава 1. Архитектурная модель КИС как объекта исследования

Корпоративная информационная система в современном понимании — это не монолит, а совокупность взаимодействующих компонентов. Для целей компьютерной экспертизы выделяются следующие уровни: 🧩

1.1. Уровень источников данных. Это первичные системы учёта: ERP (1С, SAP, Dynamics), CRM, SCM, HRM. Каждая имеет свою модель данных, свои журналы аудита, свои механизмы хранения (файловые, SQL, облачные).

1.2. Уровень интеграции (ESB, ETL, API). Данные перемещаются между системами через корпоративную сервисную шину (ESB), ETL-процессы (Azure Data Factory, SSIS, Talend), или прямые API-вызовы. Этот уровень — частая причина потери и искажения данных.

1.3. Уровень хранилища данных (Data Warehouse / Data Lake). Централизованное хранилище для аналитики. Может быть реализовано на SQL Server, Azure Synapse, Snowflake, BigQuery.

1.4. Уровень бизнес-аналитики (BI). Power BI, Tableau, Qlik. Здесь данные визуализируются и агрегируются. Ошибки в DAX-формулах или LOD-выражениях могут исказить дашборды.

1.5. Уровень управления доступом (IAM, Active Directory). Управляет учётными записями пользователей, их правами в каждой из систем. Уязвимости здесь могут привести к несанкционированному доступу.

1.6. Уровень инфраструктуры. Серверы, СХД, сеть. Хранят системные журналы, логи входа, сетевые логи.

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

Глава 2. Типовые сценарии споров, требующих экспертизы КИС

На основе практики Союза можно выделить несколько категорий дел, где экспертиза КИС становится решающим инструментом. ⚔️

Сценарий 1: «Исчезнувшие данные» (спор с интегратором). Компания заплатила интегратору за создание КИС, объединяющей ERP, CRM и BI. После внедрения выясняется, что данные из CRM не попадают в BI, а из BI — в ERP. Интегратор утверждает, что «проблемы в исходных данных». Экспертиза анализирует ETL-логи, API-логи и находит ошибку.

Сценарий 2: «Корпоративный шпионаж» (утечка данных). Сотрудник с правами администратора скопировал базу клиентов из CRM и передал конкуренту. Экспертиза анализирует журналы доступа, логи экспорта, временные метки, IP-адреса.

Сценарий 3: «Манипуляции с отчётностью» (внутреннее мошенничество). Финансовый директор изменяет данные в ERP или в BI-модели, чтобы скрыть хищения. Экспертиза анализирует журналы транзакций СУБД, DAX-формулы, системные журналы.

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

Сценарий 5: «Сбой при миграции данных» (спор с подрядчиком). При переходе со старой ERP на новую (например, с 1С на SAP) часть данных была потеряна или искажена. Экспертиза сравнивает исходные данные, ETL-логи и конечные данные.

Глава 3. Кейс №1: Сквозная трассировка потери данных в КИС (ERP → ETL → BI)

Фабула дела: Крупный производственный холдинг (Истец) объединил свою ИТ-инфраструктуру: ERP (Microsoft Dynamics 365 F&O), CRM (Dynamics 365 Sales), ETL на Azure Data Factory, BI на Power BI. После внедрения финансовый директор заметил, что данные о себестоимости продукции в дашбордах Power BI систематически занижены на 20-25% по сравнению с данными в ERP. Убытки от неверных управленческих решений (занижение цен) — 150 млн рублей. Интегратор (Ответчик) утверждал, что «проблемы в исходных данных ERP». Суд назначил Компьютерная экспертиза корпоративных информационных систем (КИС). ⚖️

Техническое исследование (эксперты Союза):

Шаг 1. Верификация исходных данных в ERP (Dynamics 365 F&O). Эксперты выгрузили данные о себестоимости из SQL-базы ERP (таблица InventTrans). Данные были корректными: суммы соответствовали первичным документам.

Шаг 2. Анализ ETL-процесса (Azure Data Factory). Эксперты извлекли JSON-определение конвейера LoadCostData. В SQL-запросе на преобразование данных обнаружена ошибка:

sql

SELECT ProductId, CAST(TotalCost AS INT) AS TotalCost, Quantity

FROM ERP.ProductionCost

WHERE Status = ‘Approved’

Преобразование CAST(TotalCost AS INT) округляло себестоимость до целого числа. Для продукции с себестоимостью 125,75 рублей в BI попадало 125 рублей. Ошибка накапливалась.

Шаг 3. Анализ модели данных Power BI (DAX). Эксперты открыли файл.pbix. В мере Total Cost была найдена дополнительная ошибка:

dax

Total Cost = SUMX(Production, [TotalCost] * [Quantity]) / COUNTROWS(Production)

Вместо суммирования затрат формула вычисляла среднее значение. Это привело к занижению ещё на 15-20%.

Шаг 4. Сквозная трассировка (End-to-End). Эксперты выбрали 10 продуктов с наибольшим расхождением. Восстановили корректную себестоимость: из ERP, через ETL с исправленным преобразованием, через BI с исправленной DAX-формулой. Расхождение с исходным дашбордом подтвердилось (22-28%).

Результат для суда: Экспертное заключение доказало, что ошибки допущены интегратором на этапах ETL и модели BI. Иск удовлетворён. Компьютерная экспертиза корпоративных информационных систем (КИС) позволила проследить путь данных от ERP до BI и локализовать ошибки. 🏆

Глава 4. Технический метод сквозной трассировки данных

Сквозная трассировка (End-to-End Tracing) — это основной метод исследования КИС. Он позволяет проследить путь одной записи от источника через все интеграционные слои до конечного потребителя (дашборда, отчёта). 🗺️

4.1. Алгоритм сквозной трассировки:

Выбор реперной записи (Reperent Record). Выбирается документ (счёт-фактура, сделка, заказ), который гарантированно существует в исходной системе (ERP/CRM). Фиксируется его уникальный идентификатор (ID).

Поиск в ETL-логах. По ID находится запись в логах ETL (Azure Data Factory, SSIS, Talend). Проверяется: была ли запись извлечена (Extract), какие преобразования применялись (Transform), была ли загружена (Load) в хранилище.

Поиск в хранилище данных (Data Warehouse). По ID запись ищется в таблицах Data Warehouse. Сравниваются значения полей (сумма, дата, количество).

Поиск в BI-модели. Проверяется, проходит ли запись через фильтры отчёта (RLS). Проверяется, как вычисляются меры (DAX, LOD) с участием этой записи.

Проверка визуализации. Отображается ли запись на дашборде? Если нет — почему? Если да — соответствует ли сумма?

4.2. Инструменты для трассировки:

ETL-логи: Azure Monitor, SQL Server Agent Logs, Apache Airflow Logs.

Хранилище данных: SQL Server Management Studio, Azure Data Studio.

BI-модель: DAX Studio (Power BI), Performance Recorder (Tableau).

4.3. Типовые результаты трассировки:

Запись исчезла на этапе ETL: ошибка в JOIN или WHERE, потеря данных.

Запись есть в хранилище, но нет на дашборде: фильтр RLS, неправильная связь в модели.

Запись есть на дашборде, но сумма искажена: ошибка в DAX-мере.

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

Глава 5. Кейс №2: Расследование утечки клиентской базы через интеграционную шину

Ситуация: ООО «ТехноСнаб» (Истец) — дистрибьютор медоборудования. Уволился коммерческий директор Петров. Через месяц ключевые клиенты перешли к конкуренту. Внутренний аудит показал, что за 3 дня до увольнения Петров активно работал в CRM (Salesforce) и в интеграционной шине (Azure Service Bus). Было подозрение, что он выгрузил базу через интеграцию. Истец подал иск о взыскании убытков (120 млн рублей). Суд назначил Компьютерная экспертиза корпоративных информационных систем (КИС). 🕵️

Техническое исследование (эксперты Союза):

Шаг 1. Анализ журналов аудита Salesforce. Эксперты выгрузили Audit Log и Login History Salesforce. Обнаружили: 23 операции экспорта сущностей Contact и Opportunity в ночное время (22: 00-03: 00). IP-адрес — домашний провайдер Петрова. Время — за 3 дня до увольнения.

Шаг 2. Анализ логов Azure Service Bus (интеграционной шины). Эксперты выгрузили логи очередей (queues). Обнаружили, что в те же ночные часы из Salesforce в шину были отправлены сообщения с типами ContactExport и OpportunityExport. Тела сообщений содержали сериализованные JSON-массивы с контактами и сделками.

Шаг 3. Анализ логов Azure Data Factory (ETL). Эксперты нашли записи о том, что данные из Service Bus были выгружены во внешний Azure Blob Storage (контейнер с нестандартным именем temp-petrov). Доступ к контейнеру имел только сам Петров (через свою учётную запись).

Шаг 4. Анализ системных журналов Windows (рабочая станция Петрова). На изъятой рабочей станции в логах Event Viewer найдены записи о том, что Петров в ночное время подключался к Azure Portal и копировал файлы из Blob Storage на локальный диск.

Результат для суда: Сквозная трассировка: Salesforce → Service Bus → Data Factory → Blob Storage → локальный диск. Факт кражи доказан. Иск удовлетворён. Компьютерная экспертиза корпоративных информационных систем (КИС) разоблачила хитрого директора. 🔥

Глава 6. Технический метод анализа интеграционных логов

Интеграционная шина (ESB), очереди сообщений (Service Bus, RabbitMQ), ETL-процессы — это «нервная система» КИС. Здесь данные передаются между системами. Логи интеграций — ценный источник доказательств. 🌐

6.1. Источники интеграционных логов:

Azure Service Bus / Event Hubs: Логи сообщений (отправка, получение, ошибки). Хранятся в Azure Monitor.

Azure Data Factory: Логи выполнения конвейеров (строки на входе/выходе, ошибки).

Apache Kafka: Логи смещений (offsets), логи потребителей.

MuleSoft / Boomi / Workato: Встроенные логи выполнения.

6.2. Метод анализа:

Выгрузить логи интеграций за интересующий период.

Фильтровать по типу сообщения (например, ContactExport, OrderUpdate), по временным меткам.

Извлечь тела сообщений (если они не зашифрованы). Проанализировать объём переданных данных (количество записей).

Сопоставить временные метки с действиями пользователей в системах-источниках (CRM, ERP).

6.3. Что можно доказать:

Факт массовой выгрузки данных из CRM во внешнюю систему.

Факт потери данных при передаче (ошибки в ETL).

Факт несанкционированного доступа (сообщения, отправленные с нестандартного IP).

Глава 7. Кейс №3: Манипуляции с себестоимостью через модификацию хранимых процедур в Data Warehouse

Обстоятельства: В ООО «Альфа-Холдинг» (Истец) финансовый директор Смирнов (Ответчик) в течение двух лет искажал себестоимость продукции в отчётах, чтобы скрыть убытки от неэффективных закупок. Он действовал не через ERP (где аудит был включён), а через хранимые процедуры в Data Warehouse (Azure SQL Database), которые агрегировали данные перед отправкой в Power BI. Истец подал иск о взыскании убытков (80 млн рублей). Суд назначил экспертизу. 📉

Техническое исследование (эксперты Союза):

Шаг 1. Анализ исходных данных в ERP (Dynamics 365 F&O). Эксперты выгрузили данные о закупках. Реальная себестоимость была стабильна.

Шаг 2. Анализ хранимых процедур в Azure SQL Database (Data Warehouse). Эксперты получили доступ к Data Warehouse (по судебному решению). Проанализировали код хранимой процедуры sp_CalculateCost. Обнаружили, что в процедуру была добавлена строка:

sql

UPDATE ProductionCost SET Cost = Cost * 0.85 WHERE ProductCategory = ‘Electronics’

Это прямое искажение себестоимости для категории «Электроника» на 15%.

Шаг 3. Анализ логов SQL Server (журналов транзакций). Эксперты проанализировали LDF-файлы базы данных Data Warehouse. Нашли записи о выполнении ALTER PROCEDURE sp_CalculateCost в ночное время, за месяц до начала искажений. Пользователь — sql_admin, что соответствует учётной записи Смирнова.

Шаг 4. Анализ системных журналов Windows (сервер БД). В Event Logs нашли события 4624 (вход) для учётной записи Смирнова в ночное время, с IP-адреса его домашнего провайдера.

Результат для суда: Суд признал Смирнова виновным. Компьютерная экспертиза корпоративных информационных систем (КИС) выявила искажение на уровне Data Warehouse, минуя ERP и BI. 💰

Глава 8. Технический метод анализа хранимых процедур и ETL-кода

Хранимые процедуры в Data Warehouse и ETL-код — это «теневая кухня» КИС. Здесь данные преобразуются неочевидным для бизнес-пользователей способом. 💻

8.1. Что искать:

Скрытые преобразования. CAST из DECIMAL в INT (потеря точности).

Неправильные фильтры. WHERE Status = ‘Approved’ исключает важные записи.

«Закладки». IF User = ‘Admin’ THEN Cost = Cost * 0.85.

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

8.2. Метод анализа:

Извлечь код всех хранимых процедур, ETL-пакетов (SSIS, Azure Data Factory), функций.

Провести статический анализ (поиск подозрительных паттернов).

Сравнить код с эталоном (из резервной копии или из системы разработки).

Выполнить процедуры на тестовых данных и сравнить результаты с эталонными.

8.3. Эпистемическое значение: Анализ кода позволяет не только найти ошибку, но и определить, когда она была внесена (по журналам изменений) и кем.

Глава 9. Технический метод анализа журналов транзакций СУБД (LDF, redo logs)

Журналы транзакций СУБД (SQL Server LDF, Oracle redo logs, PostgreSQL WAL) — это «чёрный ящик» базы данных. Они фиксируют каждое изменение, даже если аудит на прикладном уровне отключён. 🗄️

9.1. Что можно узнать из журналов транзакций:

Операции INSERT, UPDATE, DELETE с точным временем.

Старые и новые значения изменённых полей (before image / after image).

Пользователя СУБД, выполнившего операцию (SID).

Имя приложения (например, SQL Management Studio — прямое вмешательство).

9.2. Метод анализа LDF (SQL Server):

Получить образ диска сервера БД или сам LDF-файл.

Использовать утилиту ApexSQL Log или функцию fn_dblog для выгрузки записей.

Отфильтровать по таблице (например, ProductionCost), типу операции (UPDATE), временному периоду.

Извлечь before images для восстановления удалённых/изменённых записей.

9.3. Эпистемическое значение: Журналы транзакций — это «золотой стандарт» доказательств. Они практически не поддаются фальсификации (требуют удаления самих файлов).

Глава 10. Технический метод анализа кэшей и клиентских логов

Даже если серверные логи очищены, на клиентских машинах могут сохраниться следы. 🖥️

10.1. Клиентские источники:

Кэш браузера: временные файлы, localStorage, IndexedDB (для веб-приложений).

Логи 1С (файлы.lgp,.lgf). Содержат историю действий пользователя.

Логи SAP GUI (saplog).

Файлы подкачки (pagefile.sys, swapfile.sys). Могут содержать фрагменты данных.

10.2. Метод анализа:

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

Создать образ диска (через write-blocker).

Проанализировать кэш браузера (Chrome/Edge: папка Cache, Local Storage).

Проанализировать логи 1С (утилитой lgf2txt).

Восстановить фрагменты данных из файла подкачки.

10.3. Эпистемическое значение: Клиентские следы часто забывают удалить. Они могут стать решающей уликой, когда серверные логи уже «подчищены».

Глава 11. Проблема гетерогенности: как исследовать КИС из разных вендоров

Самая большая сложность экспертизы КИС — гетерогенность. Одна КИС может включать: ERP от SAP, CRM от Salesforce, BI от Power BI, интеграцию на MuleSoft, базу данных Oracle. Эксперт должен владеть методами исследования всех этих платформ. 🔄

11.1. Стратегия исследования:

Начать с источника данных (ERP, CRM). Проверить целостность исходных данных.

Проанализировать интеграционный слой (ETL, ESB). Где данные потерялись?

Проверить хранилище данных (Data Warehouse). Не было ли модификаций на этом уровне?

Проанализировать BI-слой (DAX, LOD). Не искажают ли формулы?

Сравнить конечные дашборды с исходными данными.

11.2. Корреляция временных меток. Разные системы могут быть в разных часовых поясах. Эксперт должен нормализовать временные метки (привести к UTC) и учесть рассинхронизацию.

11.3. Унификация доказательств. Все выгрузки (из SAP, Salesforce, Power BI) должны быть подписаны экспертом, хеш-суммы зафиксированы. Это гарантирует их неизменность в суде.

Глава 12. Процессуальные аспекты экспертизы КИС

Из-за масштаба и гетерогенности КИС процессуальная подготовка особенно важна. 📝

12.1. Обеспечительные меры:

Наложить арест на все серверы, входящие в КИС (ERP, CRM, Data Warehouse, BI).

Запретить ответчику изменять ETL-код, хранимые процедуры, DAX-формулы.

Обязать ответчика предоставить эксперту read-only доступ ко всем компонентам.

12.2. Вопросы для эксперта (примеры):

«Имеются ли в ETL-процессах (Azure Data Factory) технические признаки потери данных при передаче из CRM (Salesforce) в Data Warehouse за период [дата], и если да, то восстановить потерянные записи?»

«Соответствуют ли DAX-формулы в модели Power BI методике расчёта себестоимости, утверждённой приказом №Х, и если нет, то в чём именно выражается несоответствие?»

«Имеются ли в журналах транзакций SQL Server (Data Warehouse) записи о модификации хранимой процедуры sp_CalculateCost пользователем [ФИО] за период [дата], и если да, то восстановить историю изменений кода?»

12.3. Стоимость и сроки. Экспертиза КИС — самая дорогая (от 1 до 5 млн рублей) и длительная (60-120 дней). Но когда на кону миллиарды, это разумные инвестиции.

Глава 13. Судебная практика по экспертизе КИС (обзор)

Анализ судебных актов (включая зарубежную практику) позволяет выделить следующие тенденции: 📈

13.1. Признание экспертизы КИС допустимым доказательством. Суды всё чаще назначают комплексную экспертизу, понимая, что без неё невозможно установить истину в гетерогенной среде.

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

13.3. Последствия отказа в доступе. Отказ ответчика предоставить доступ к одному из компонентов КИС расценивается как недобросовестное поведение (ст. 10 ГК РФ).

13.4. Прецеденты по искам к интеграторам. В делах о создании комплексных КИС экспертиза играет ключевую роль в распределении ответственности между ошибками интегратора и некорректностью исходных данных.

Глава 14. Часто задаваемые вопросы об экспертизе КИС

Вопрос 1: Можно ли провести экспертизу, если КИС полностью облачная (SaaS)? Ответ: Да, сложнее, но можно. Эксперт получает доступ через API и интерфейсы администрирования каждого компонента. Логи активности выгружаются через встроенные инструменты (Microsoft 365 Admin Center, Salesforce Audit Log, Power BI Activity Logs).

Вопрос 2: Как долго хранятся логи в облачных сервисах? Ответ: По-разному. Salesforce — 6-18 месяцев, Power BI — 30-90 дней, Azure Data Factory — до 90 дней. Истец должен действовать быстро.

Вопрос 3: Может ли эксперт восстановить данные, если ETL-код был удалён? Ответ: Если ETL-код удалён, но есть логи выполнения (Azure Monitor, SQL Server Agent Logs), можно восстановить логику преобразований (reverse engineering). Но это сложнее и дороже.

Вопрос 4: Какова стоимость экспертизы КИС? Ответ: От 1 до 5 млн рублей. Точную смету даём после ознакомления с объектами.

Вопрос 5: Нужно ли привлекать нескольких экспертов для разных компонентов? Ответ: Да, для комплексной КИС нужна команда: эксперт по ERP, по CRM, по BI, по ETL, по СУБД. Союз «Федерация судебных экспертов» предоставляет таких специалистов.

Глава 15. Заключение: КИС не убежище, а лабиринт, который можно пройти

Корпоративные информационные системы сложны. Но именно эта сложность оставляет множество цифровых следов: журналы аудита CRM, транзакционные логи ERP, логи ETL-процессов, DAX-формулы BI, хранимые процедуры Data Warehouse, системные журналы серверов, кэши клиентских машин. Компьютерная экспертиза корпоративных информационных систем (КИС) — это методология, позволяющая пройти этот лабиринт и восстановить истину. 🎯

Три кейса, представленные в этой статье, демонстрируют, как эксперты Союза «Федерация судебных экспертов» находят корень зла в самых недрах КИС: от ошибок ETL до «закладок» в хранимых процедурах, от кражи базы через интеграционную шину до сквозной трассировки данных.

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

📌 Наш сайт: https://kompexp.ru/

Статья подготовлена экспертами Союза «Федерация судебных экспертов» на основе реальных экспертиз КИС. Кейсы приведены с сохранением конфиденциальности. Методология соответствует научным стандартам.