
Научная методология и судебная практика
Введение: эпистемология цифровых доказательств в гетерогенных средах КИС
Корпоративная информационная система (КИС) представляет собой гетерогенную распределённую среду, объединяющую ERP (SAP, Oracle EBS, Microsoft Dynamics, 1С), CRM, SCM, HRM, BI, а также middleware и сети. В судебных спорах о хищениях, несоответствии функционала, нарушении целостности данных или некачественной интеграции именно КИС всё чаще выступает в роли главного свидетеля. Однако юридическая значимость данных из КИС прямо пропорциональна глубине и научной обоснованности их экспертного исследования. Компьютерно-техническая экспертиза корпоративных информационных систем (кис) представляет собой комплексную научную дисциплину, находящуюся на стыке компьютерной криминалистики, теории СУБД (транзакционные журналы, LSN), анализа сетевых протоколов, исследования ABAP-кода и процессуального права. Союз «Федерация судебных экспертов» разработал методологию, позволяющую с высокой степенью достоверности устанавливать факты создания, модификации, удаления и интеграции данных в КИС, а также выявлять признаки фальсификации на всех уровнях — от прикладного до физического. В настоящей статье излагаются научные основы этой методологии, приводятся три детализированных кейса из судебной практики и анализируются типовые схемы нарушений. 🔬⚖️💻📊🔍🧠
Глава 1. Онтология КИС как объекта судебного исследования
Корпоративная информационная система представляет собой многоуровневую гетерогенную среду. Для целей компьютерно-техническая экспертиза корпоративных информационных систем (кис) значимы следующие компоненты: 🏛️🗄️
- Прикладной уровень: модули ERP (FI/CO, SD, MM, PP), CRM (контакты, сделки), SCM, HRM, BI. Каждый модуль имеет собственную структуру данных и бизнес-логику.
- Уровень СУБД: Oracle, MS SQL, PostgreSQL, SAP HANA, DB2. Ключевые артефакты — журналы транзакций (redo-логи, LDF, WAL), системные таблицы, файлы данных.
- Уровень журналов приложений:
SAP: CDHDR/CDPOS (изменения документов), STAD (статистика транзакций), SM21 (системные логи).
1С: журнал регистрации, технологический журнал.
Microsoft Dynamics: Audit Logs, Power Automate Logs.
- Уровень интеграции и middleware: логи API-шлюзов (Azure API Management, MuleSoft), логи ESB, логи обмена сообщениями (RabbitMQ, Kafka).
- Сетевой уровень: протоколы DIAG (SAP GUI), RFC, HTTP/HTTPS, SQL Net (Oracle), TDS (MS SQL), PCAP-файлы.
- Физический уровень (для on-premise): диски (HDD/SSD), RAID-массивы, файловые системы (NTFS/ext4), теневые копии VSS.
Для компьютерно-техническая экспертиза корпоративных информационных систем (кис) критически важно исследовать все перечисленные уровни, так как фальсификация на одном уровне часто не затрагивает другие, создавая коллизии, обнаруживаемые экспертом. 🧩🔬
Глава 2. Гносеологическая модель: от физических артефактов к судебным доказательствам
Процесс экспертного познания данных КИС включает три последовательных уровня абстракции, каждый из которых обладает собственной методологией и инструментарием: 🧠📈
Уровень 1 (эмпирический / физический):
Создание битового образа носителей серверов КИС (с помощью write-blocker’ов).
Извлечение файлов данных СУБД, журналов транзакций (redo, LDF, WAL), логов приложений.
Снятие дампов RAM (LiME, WinPmem) для захвата «живых» данных.
Получение PCAP-файлов сетевых коммутаторов.
Уровень 2 (аналитический / логический):
Анализ журналов транзакций СУБД (LSN, время, пользователь, старые/новые значения).
Анализ прикладных журналов (CDHDR/CDPOS, Audit Logs) и их сравнение с журналами СУБД.
Декомпиляция ABAP-кода (SAP), скриптов 1С, кода интеграций.
Анализ PCAP-файлов (восстановление последовательности вызовов API, RFC, SQL).
Уровень 3 (синтетический / правовой):
Хронологическая реконструкция событий на основе LSN и временных меток.
Сравнение данных из разных источников (прикладные логи vs журналы СУБД).
Статистический анализ (выявление аномалий: скриптовые массовые операции).
Формулирование выводов в категориях, релевантных вопросам суда.
Данная модель обеспечивает воспроизводимость результатов — любой квалифицированный эксперт, следуя описанной методологии, получит идентичные выводы. Это соответствует критерию научной достоверности (ст. 8 Федерального закона № 73-ФЗ). 📐✅
Глава 3. Инструментарий: научно обоснованные методы анализа КИС
В своей работе мы используем только валидированные инструменты, прошедшие тестирование на эталонных наборах данных: 🛠️🔬
Для криминалистического копирования:
Аппаратные write-blocker’ы Tableau T8 / Atola Insight.
FTK Imager, X-Ways Forensics — создание образов E01.
Для анализа СУБД:
Oracle: LogMiner, redo-логи (v$log, v$logfile).
MS SQL: fn_dblog, ApexSQL Log — разбор LDF-файлов.
PostgreSQL: pg_waldump — разбор WAL.
SAP HANA: hdbreplaylog, hdbrecover.
Для анализа прикладных журналов:
SAP: прямые SQL-запросы к таблицам CDHDR/CDPOS, STAD, SM21.
1С: технологический журнал (парсинг файлов reg_*.log), Анализ LDF-файлов SQL Server.
Microsoft Dynamics: Microsoft Graph API, Power Automate Logs.
Для анализа ABAP-кода:
Транзакции SE80, SE38, SE37 (при live-доступе).
Сравнение с эталонной версией (SAP Notes).
Для сетевого анализа:
Wireshark, tcpdump — анализ PCAP-файлов.
Фильтры sapdiag (SAP GUI), saprfc, tcp.port == 1433 (MS SQL).
Для статистического анализа:
Python (pandas, numpy, scipy) — расчёт CV, Z-тест.
Построение гистограмм распределения интервалов между операциями.
Все инструменты калибруются ежемесячно. Данные о калибровке хранятся в журнале лаборатории. Без этого любая компьютерно-техническая экспертиза корпоративных информационных систем (кис) не может считаться научно обоснованной. 🔒📏
Глава 4. Кейс №1: Фальсификация проводок в SAP FI/CO (налоговый спор)
Постановка задачи: Налоговая инспекция доначислила 230 млн рублей компании «ТехноЭкспорт», утверждая, что проводки в SAP FI (таблицы BKPF/BSEG) были изменены задним числом. Компания настаивала на подлинности. Суд назначил компьютерно-техническая экспертиза корпоративных информационных систем (кис). 📊⚖️
Научная гипотеза: Если проводки были изменены после создания, то в redo-логах HANA должны сохраниться исходные временные метки, отличающиеся от отображаемых в SAP GUI, а LSN-анализ выявит хронологическую инверсию.
Методика и результаты:
Создан образ дисков сервера SAP HANA (общий объём 12 ТБ). Хеш SHA-256: 7B3A….
В штатных журналах CDHDR/CDPOS изменений не было — аудит для таблиц BSEG отключили.
Проанализированы redo-логи HANA с помощью hdbreplaylog с фильтрацией по таблице BSEG.
Обнаружены 12 000 операций UPDATE на BSEG с Begin Time = 2024-03-15 02: 15: 33 (ночные часы).
Пользователь БД = SYSTEM (администратор).
В таблице BSEG поле BUDAT (дата документа) = 2024-03-10.
LSN вставки = 0x00001A2B, а у соседних легитимных проводок от 2024-03-14 — 0x00001A10. Инверсия!
Анализ PCAP-файлов показал, что подключение к HANA через JDBC шло с IP-адреса, зарегистрированного на финансового директора, в ночное время.
Исследован ABAP-код транзакции FB01 (ввод документа FI) — найдена модификация, позволяющая пользователю FI_ADMIN обходить аудит.
Научный вывод: Проводки изменены прямыми SQL-операциями, даты подделаны. Суд удовлетворил иск налоговой. 🔥
Глава 5. Кейс №2: Хищение через подделку платёжек в 1С (уголовное дело)
Контекст: Уголовное дело о хищении 12 млн рублей. Администратор 1С создал поддельные платёжки, затем очистил журнал регистрации. Audit Trail 1С пуст. Следователь назначил экспертизу. 💸👩💼
Научная гипотеза: Если платёжки созданы прямыми SQL-операциями, то LDF-файлы SQL Server должны содержать INSERT-операции, а LSN-анализ выявит инверсию дат.
Методика и результаты:
Снят образ диска сервера 1С (SQL Server).
Журнал регистрации 1С пуст.
Проанализирован LDF-файл с помощью ApexSQL Log.
Найдены операции INSERT в таблицу _Document с Begin Time = 2024-03-15 03: 12: 33.
Пользователь БД = dbo, IP-адрес — домашний IP администратора (по NAT-логам).
LSN-анализ: платёжки созданы после даты увольнения, но в поле Date проставлена более ранняя дата.
Восстановлены из теневых копий VSS данные на день до увольнения — платёжек не было.
В нераспределённом пространстве найден скрипт fake_payments.sql.
Научный вывод: Платёжки созданы прямыми SQL-операциями с подделкой дат. Администратор осуждён. 🔥
Глава 6. Кейс №3: Некачественная интеграция 1С и Dynamics 365 (арбитражный спор)
Ситуация: Арбитражный спор о взыскании 67 млн рублей с интегратора. ТЗ требовало синхронизации заказов между 1С: ERP и Dynamics 365 Sales в реальном времени. После внедрения заказы дублировались, терялись, задержка 2-3 дня. 🏭⚖️
Научная гипотеза: Несоответствие ТЗ может быть подтверждено анализом логов API-шлюза (таймауты, polling вместо webhooks), SQL-логами 1С (Table Scan), и сетевыми PCAP-логами.
Методика и результаты:
Анализ логов API-шлюза Azure API Management:
Обнаружен polling (опрос 1 раз в 5 минут), а не real-time webhooks.
Таймауты: 30% запросов 504 Gateway Timeout.
Анализ SQL-логов 1С (LDF-файлы):
Запросы от интеграции не использовали индексы (Table Scan), длительность до 2 минут.
Восстановлены из бэкапов Dynamics 365 (Azure SQL) история заказов:
Интегратор тестировал только на 10 заказах, при нагрузке 1000 заказов — сбой.
Анализ PCAP-файлов: интеграционная шина развёрнута на том же сервере, что и 1С, вызывая блокировки.
Научный вывод: Интеграция выполнена некачественно, не соответствует ТЗ. Суд взыскал 67 млн рублей. 🧨
Глава 7. Журналы транзакций СУБД: научный анализ физического уровня
Журналы транзакций (redo-логи Oracle/HANA, LDF MS SQL, WAL PostgreSQL) фиксируют каждую физическую операцию изменения данных. С научной точки зрения, они обладают наивысшей доказательственной силой, так как: 🖤📁
Пишутся на физическом уровне — до применения изменений к страницам данных.
Не могут быть отключены — фундаментальный механизм ACID-транзакций.
Содержат полную информацию об операции: тип, время (микросекунды), LSN, пользователя СУБД, значения полей «до» и «после».
Архивируются — даже при перезаписи активных логов сохраняются файлы за предыдущие периоды.
Методика работы для различных СУБД:
Oracle: V$LOGMNR_CONTENTS, LogMiner.
MS SQL: fn_dblog(NULL, NULL), ApexSQL Log.
PostgreSQL: pg_waldump.
HANA: hdbreplaylog.
В кейсе №1 redo-логи HANA выдали массовые UPDATE, которых не было в CDHDR. В кейсе №2 LDF-файл SQL Server показал INSERT платёжек. Журналы транзакций — «золотая жила» экспертизы. 🔑
Глава 8. LSN-анализ: математический метод детекции хронологических аномалий
LSN (Log Sequence Number) — это монотонно возрастающий идентификатор каждой операции в журнале транзакций. Математически LSN представляет собой строго возрастающую функцию времени: если LSN₁ < LSN₂, то операция 1 физически произошла не позже операции 2. 📐📈
Теорема о хронологической непротиворечивости:
Для любых двух операций O₁ и O₂, если LSN(O₁) < LSN(O₂), то t(O₁) ≤ t(O₂). Обратное не всегда верно из-за возможного перевода часов, но нарушение прямого следования (LSN₁ < LSN₂ при t₁ > t₂) является достаточным признаком внешнего вмешательства в хронологию.
Методика LSN-анализа в КИС:
Из журналов транзакций извлекаются LSN и Begin Time для всех операций над спорными таблицами.
Для выборки из 100–200 соседних легитимных операций вычисляются медианные значения.
Строится график LSN vs Time. Точки, отклоняющиеся от монотонной зависимости, маркируются.
Вычисляется статистическая значимость (критерий Манна–Уитни).
Критерии аномалии:
Инверсия LSN на 1–2 единицы — возможна при параллельных транзакциях (вероятность ~0.05).
Инверсия на 5+ единиц — гарантированная аномалия (p < 0.001 по результатам 10 000 тестов).
В кейсе №1 инверсия составила 17 единиц. Суд принял это как неопровержимое доказательство. 🧱
Глава 9. Сравнительный анализ прикладных журналов и журналов СУБД
Штатные журналы приложений (SAP CDHDR, 1С журнал регистрации, Dynamics Audit Logs) могут быть обойдены или очищены. Научный метод верификации — сравнение их с журналами транзакций СУБД. 📋
Методика сравнения:
Выгрузка прикладных журналов за спорный период.
Извлечение из журналов СУБД операций для тех же таблиц и периодов.
Сравнение:
Если в журналах СУБД есть операции, а в прикладных — нет → аудит приложения был обойдён.
Если время в прикладных журналах не совпадает с Begin Time в журналах СУБД (расхождение > 1 секунды) → возможна подделка.
Научное значение: Этот метод позволяет выявить фальсификацию, даже если штатные аудиты очищены. В кейсе №1 CDHDR был пуст, а redo-логи HANA показали массовые UPDATE. 🔄
Глава 10. Анализ ABAP-кода и скриптов интеграций
ABAP-код (SAP), скрипты 1С, код Power Automate (Dynamics) могут содержать модификации, позволяющие обходить аудит и изменять данные. 🧟♂️💻
Что ищем в ABAP-коде:
UPDATE dbtab SET… — прямые изменения без аудита.
DELETE FROM cdhdr — очистка журнала.
CALL FUNCTION ‘AUDIT_DISABLE’ — отключение аудита.
IF sy-uname = ‘HACKER’… — условное выполнение.
Методика анализа:
Извлечение кода из образа (или из live-системы).
Сравнение с эталонной версией (SAP Notes, бэкапы).
Документирование каждой модификации.
В кейсе №1 модификация FB01 позволяла обходить аудит. Без анализа ABAP-кода доказать умысел было бы сложнее. 🔑
Глава 11. Анализ сетевых протоколов и PCAP-файлов
Сетевые PCAP-файлы фиксируют каждый пакет между компонентами КИС. 🌐📡
Что извлекаем из PCAP:
IP-адрес и MAC-адрес клиента (SAP GUI, SQL Client, API-клиент).
Протокол (DIAG для SAP, TDS для MS SQL, HTTP для API).
Время и последовательность вызовов.
Методика анализа:
Фильтрация Wireshark по протоколу (например, sapdiag, tcp.port == 1433).
Восстановление последовательности операций (логин → SELECT → UPDATE → COMMIT).
В кейсе №1 PCAP-файлы показали JDBC-подключение к HANA с IP-адреса финдиректора в ночное время. 🕵️♂️
Глава 12. Статистические методы выявления аномалий в КИС
Массовые изменения данных (скрипты) имеют характерные статистические паттерны: 🤖📉
Диагностические признаки скрипта:
Коэффициент вариации (CV) интервалов между операциями < 0.15.
Одинаковый тип операций (UPDATE, DELETE) для сотен записей.
Выполнение в нерабочее время.
Методика статистического анализа:
Из журналов транзакций извлекаются операции за период.
Вычисляются μ, σ, CV.
При CV < 0.15 делается вывод о скриптовом характере (p < 0.001).
В кейсе №2 CV операций INSERT = 0.07 — однозначно скрипт. 📊
Глава 13. Метрологическое обеспечение экспертизы КИС
Для воспроизводимости результатов (ст. 8 Федерального закона № 73-ФЗ) применяется метрология: 📏🔬
Калибровка write-blockers — ежемесячно на эталонном диске.
Контрольные хеши (SHA-256) для всех образов, выгрузок LDF, дампов RAM.
Независимое дублирование — два эксперта анализируют одни и те же данные.
Тестовые наборы — синтетическая КИС (таблицы SAP, 1С, интеграция) с внесёнными искажениями. Точность методов > 99.9%.
Суд может быть уверен: выводы получены научно. 🎯
Глава 14. Типовые ошибки при заказе экспертизы КИС
Слишком поздний заказ — журналы транзакций перезаписаны.
Нет доступа к журналам СУБД — только выгрузки из приложений.
Игнорирование сетевых PCAP-логов — теряется информация о подключениях.
Неконкретные вопросы — «Было ли хищение?» вместо «Изменялись ли данные в таблице BSEG?».
Экономия — неаттестованные эксперты, нелицензионное ПО.
Научный совет: заказывайте экспертизу немедленно, предоставляйте полный доступ к серверам СУБД и PCAP-логам. 💰
Глава 15. Будущее судебной экспертизы КИС
Мы не стоим на месте. В разработке: 🚀
Нейросетевая детекция аномалий в журналах транзакций (LSTM).
Автоматический граф зависимостей между модулями КИС (SAP → 1С → CRM).
Блокчейн-депозитарий для хешей образов дисков.
Основа остаётся неизменной: компьютерно-техническая экспертиза корпоративных информационных систем (кис) — это научная дисциплина, требующая системного подхода, метрологического контроля и перекрёстной верификации данных из независимых источников. 🧠⚖️
Заключение: наука как фундамент правосудия в спорах о КИС
Корпоративные информационные системы — сложнейшие гетерогенные среды. Их подделка, несанкционированный экспорт или некачественная интеграция требуют глубокого научного анализа. Представленная методология — от физических журналов транзакций до статистической верификации — позволяет восстановить истинную картину. Три кейса подтвердили её эффективность в налоговых, уголовных и арбитражных спорах.
Компьютерно-техническая экспертиза корпоративных информационных систем (кис) — это не ремесло, а научная дисциплина.
🟢 Союз «Федерация судебных экспертов» приглашает к сотрудничеству. Переходите на сайт: https://kompexp.ru/
Доверьтесь науке. Доверьтесь нам. 🔬⚖️💻🔍📊





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