Методологическое руководство по подготовке неопровержимых доказательств

Введение: почему без методологии вы тонете в цифровом океане

SAP ERP — это не просто программа. Это экосистема, в которой ежесекундно фиксируются миллионы бизнес-событий: от закупки канцелярской скрепки до отгрузки вагона металлопродукции. Когда между контрагентами возникает спор, каждая сторона приносит в суд «свою правду» в виде распечаток, скриншотов и выгрузок из SAP. Судья, не обладающий специальными знаниями, оказывается в затруднительном положении. Кому верить? Тому, у кого красивее оформлены документы? Или тому, кто громче кричит? 🤔

Ответ: ни тому, ни другому. Верить нужно только научно обоснованной методологии. IT экспертиза SAP для подачи в суд — это не набор случайных действий, а стройная, воспроизводимая и проверяемая система методов, позволяющая извлечь цифровую истину из самых глубоких слоёв SAP. Союз «Федерация судебных экспертов» представляет вашему вниманию методологическое руководство по проведению такой экспертизы. Мы разберём каждый этап, каждый инструмент, каждый источник доказательств. Три реальных кейса покажут, как методология работает на практике, превращая разрозненные байты в бронебойные судебные аргументы. 🛡️

Глава 1. Методологические основы IT-экспертизы SAP

Любая научная деятельность начинается с определения понятий и границ. IT-экспертиза SAP — это род компьютерно-технической экспертизы, объектами которой являются: 🧬

Аппаратное обеспечение серверов SAP (накопители, RAID-массивы, сетевое оборудование).

Системное программное обеспечение (операционные системы, драйверы).

Программное обеспечение СУБД (Oracle, MS SQL Server, SAP HANA, DB2).

Программное обеспечение SAP (код ABAP, настройки SPRO, бизнес-данные).

Журналы событий (SM21, системные журналы ОС, сетевые логи, redo logs).

Методологические принципы, которых придерживается Союз «Федерация судебных экспертов»: 📐

Принцип полноты. Исследование охватывает все возможные источники цифровых следов — от физического уровня диска до бизнес-логики ABAP.

Принцип неизменности (chain of custody). Работа ведётся только с побитовыми копиями оригинальных носителей, созданными через аппаратный write-blocker. Хеш-суммы фиксируются на каждом этапе.

Принцип верифицируемости. Все используемые методики и инструменты либо являются открытыми (open source), либо имеют документированные алгоритмы. Любой другой эксперт может повторить исследование и получить тот же результат.

Принцип научной обоснованности. Методики базируются на публикациях в рецензируемых научных журналах, ГОСТах и рекомендациях Минюста РФ.

IT экспертиза SAP для подачи в суд — это реализация этих принципов в условиях конкретного судебного спора. Без методологии — хаос. С методологией — истина. 🎯

Глава 2. Метод сбора доказательств: от выемки до создания образа

Первый и, возможно, самый важный этап — это сбор исходных данных. Ошибка здесь делает всё дальнейшее исследование бесполезным. 🚨

2.1. Обеспечительные меры. До выезда эксперта истец должен добиться от суда определения о наложении ареста на сервер SAP ответчика. Это запрещает ответчику удалять или изменять данные.

2.2. Выезд на место. Эксперт приезжает в дата-центр или офис ответчика. Фиксирует состояние оборудования (фото, видео).

2.3. Создание побитового образа (forensic imaging).

Аппаратный write-blocker (например, Tableau TD3) подключается между оригинальным диском и криминалистическим копировщиком. Он блокирует любые команды записи, гарантируя неизменность оригинала.

Копировщик (Atola Insight, Logicube Forensic Falcon) создаёт посекторную копию диска в формате E01 (EnCase) или dd.

Расчёт хеш-сумм: MD5, SHA-1, SHA-256. Хеши сверяются до и после копирования.

2.4. Опечатывание оригиналов. Оригинальные диски упаковываются в антистатические пакеты, опечатываются подписью эксперта и понятых (если они есть).

2.5. Сбор дополнительных данных.

Выгрузка системных журналов Windows/Linux (Event Logs, syslog).

Выгрузка журналов SAP (SM21 через транзакцию).

Получение резервных копий баз данных (бэкапов) за период, предшествующий спору.

Только следуя этой методологии, эксперт может гарантировать, что доказательства не были сфальсифицированы на этапе сбора. IT экспертиза SAP для подачи в суд начинается с методологически чистого сбора. 🧼

Глава 3. Кейс №1: Методологическое исследование удалённых отгрузок в SAP SD (СУБД Oracle)

Фабула дела: Истец (поставщик) отгрузил товар на 340 млн рублей. Ответчик (покупатель) оплату не произвёл, заявив, что в его SAP (модуль SD) нет записей о получении товара. Суд назначил IT экспертиза SAP для подачи в суд. ⚖️

Методологический план экспертов Союза:

Сбор объектов. Получен образ диска сервера SAP ответчика (СУБД Oracle). Создана копия redo log файлов за спорный период.

Анализ redo logs Oracle с помощью LogMiner. LogMiner — это стандартный инструмент Oracle для анализа журналов повтора. Эксперты выполнили запрос:

sql

SELECT * FROM V$LOGMNR_CONTENTS WHERE SEG_NAME = ‘MSEG’ AND OPERATION IN (‘INSERT’, ‘DELETE’);

Обнаружение операций. Найдены тысячи записей INSERT в таблицу MSEG (проводки движения материалов) в даты отгрузки. Через несколько дней — записи DELETE тех же строк.

Восстановление удалённых записей (метод карвинга). Для каждой операции DELETE в redo log сохраняется «старый образ» строки (before image). Эксперты извлекли эти before images и восстановили полные записи о движении материалов: даты, количество, номенклатуру, склад.

Анализ пользователя. В redo log зафиксирован SID пользователя Oracle, выполнявшего DELETE. Сопоставление с системными журналами Windows показало — это учётная запись SAP_SD_ADMIN, которая принадлежала менеджеру по сбыту ответчика.

Анализ SM21. Журнал SM21 зафиксировал вход этого пользователя в ночное время в дни удаления. IP-адрес совпал.

Результат: Суд удовлетворил иск. Методология позволила восстановить данные, которые ответчик считал уничтоженными навсегда. IT экспертиза SAP для подачи в суд победила. 🏆

Глава 4. Метод анализа транспортных запросов SAP (таблицы E070/E071)

Транспортные запросы — это методологический ключ к пониманию истории изменений в SAP. Любое легальное изменение кода, настроек или данных оформляется запросом. 📦

4.1. Структура транспортного запроса.

Таблица E070: заголовок запроса. Поля: TRKORR (номер), AS4USER (автор), AS4DATE (дата), AS4TIME (время), STRKORR (описание).

Таблица E071: объекты запроса. Поля: OBJECT (тип: PROG — программа, TABL — таблица, VIEW — представление), OBJ_NAME (имя).

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

Выгрузить содержимое таблиц E070 и E071 за интересующий период (через SQL или транзакцию SE16).

Отфильтровать запросы по дате, автору, описанию.

Для подозрительного запроса (например, Z_CO_MANIPULATION) извлечь изменённые объекты.

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

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

Факт намеренного изменения. Если запрос называется «Исправление ошибки», а меняет код расчёта себестоимости, добавляя коэффициент 1,35 — это улика.

Личность разработчика. Поле AS4USER — это конкретный пользователь SAP.

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

4.4. Ограничения метода: Записи из E070/E071 можно удалить. Но сам факт удаления (операции DELETE) останется в redo logs СУБД. IT экспертиза SAP для подачи в суд всегда включает проверку целостности этих таблиц.

Глава 5. Кейс №2: Методологическое выявление закладки в коде ABAP (модуль CO)

Ситуация: Миноритарный акционер подал иск о взыскании 280 млн рублей убытков с директоров, которые через манипуляции в SAP CO завышали себестоимость. Суд назначил IT экспертиза SAP для подачи в суд. 📈

Методология экспертов Союза:

Анализ транспортных запросов. В таблице E070 найден запрос Z_CO_CALC_MANIP, созданный за месяц до начала роста себестоимости. Автор — DEV_PETROV. Описание: «Оптимизация расчёта».

Извлечение кода ABAP. Из объекта ZCO_CALC (программа расчёта себестоимости) извлечён исходный код через транзакцию SE38.

Сравнение с эталоном. Эксперты сравнили код из продуктивной системы с кодом из системы разработки (DEV) и типовой поставкой SAP. Обнаружено добавление:

abap

SELECT SINGLE coeff FROM zco_params INTO lv_coeff WHERE material = gs_material.

IF sy-subrc = 0.

cost = cost * lv_coeff.

ENDIF.

Анализ данных в таблице ZCO_PARAMS. В этой пользовательской таблице для спорной группы материалов был установлен коэффициент 1.35.

Анализ журнала SM21. Обнаружены записи о выполнении транспортного запроса Z_CO_CALC_MANIP в продуктивной системе пользователем SAP_ADMIN (системный администратор). Это указывает на сговор.

Результат: Суд удовлетворил иск. Методология позволила связать изменение кода (транспортный запрос), данные в пользовательской таблице и временную линию. IT экспертиза SAP для подачи в суд вскрыла схему, спрятанную в дебрях ABAP. 🧩

Глава 6. Метод анализа системного журнала SAP (SM21)

SM21 — это «чёрный ящик» системы SAP. Методология его анализа должна быть системной. 📟

6.1. Что фиксирует SM21:

Входы и выходы пользователей (успешные и неудачные).

Запуск и остановка системы.

Ошибки и предупреждения.

Выполнение транзакций (например, SE16, SE38, SE11).

Проблемы с авторизацией.

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

Выгрузить журнал SM21 за интересующий период через транзакцию SM21 -> меню «System» -> «List» -> «Save» -> «Local File».

Отфильтровать записи по дате, пользователю, IP-адресу (Terminal ID), типу события.

Построить временную линию (timeline) событий.

Сопоставить события SM21 с операциями, найденными в redo logs СУБД. Совпадение временных меток и пользователей создаёт неразрывную цепочку.

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

Пользователь заходил в систему в определённое время.

Пользователь выполнял подозрительную транзакцию (например, SE16 для просмотра/изменения таблиц).

Журнал был очищен (событие очистки).

6.4. Ограничения метода: SM21 можно очистить. Поэтому IT экспертиза SAP для подачи в суд всегда дополняет SM21 анализом redo logs — даже очищенный журнал не может уничтожить следы на уровне СУБД.

Глава 7. Кейс №3: Методологическое исследование изменения дат в SAP MM (СУБД MS SQL Server)

Обстоятельства: Арендодатель подал иск о взыскании задолженности. Арендатор предъявил встречный иск о переплате, представив выгрузку из SAP (модуль MM), где даты приходных накладных были изменены на более ранние. Истец заявил о фальсификации и ходатайствовал об экспертизе. 🏢

Методология экспертов Союза (СУБД MS SQL Server):

Анализ LDF-файлов (журнал транзакций SQL Server). Эксперты использовали утилиту ApexSQL Log для анализа LDF-файла базы данных SAP ответчика.

Обнаружение операций UPDATE. Найдены операции UPDATE для таблицы MSEG (проводки движения материалов). Старое значение поля BUDAT (дата документа) — реальные даты поступления. Новое значение — более ранние даты.

Анализ имени приложения. В LDF-файле поле ClientApplicationName содержало «Microsoft SQL Server Management Studio» — прямое вмешательство в обход SAP.

Анализ пользователя. Операции UPDATE выполнены от учётной записи sa (администратор SQL Server).

Анализ системных журналов Windows Security. Найдены события 4624 (успешный вход) для учётной записи sa с IP-адреса, принадлежащего рабочей станции главного бухгалтера ответчика.

Анализ журнала изменений SAP (CDHDR/CDPOS). Для таблицы MSEG механизм отслеживания изменений был отключён — что является аномалией и свидетельствует о подготовке к манипуляциям.

Результат: Суд отказал во встречном иске и взыскал задолженность. Методология позволила доказать, что даты изменялись намеренно, а не в результате «технического сбоя». IT экспертиза SAP для подачи в суд сработала как детектор лжи. 🔍

Глава 8. Метод сравнительного анализа кода ABAP

В спорах о манипуляциях с бизнес-логикой (себестоимость, ценообразование) ключевым доказательством становится код ABAP. Методология его анализа должна быть строгой. 💻

8.1. Источники кода для сравнения:

Продуктивная система (PROD): текущий код.

Система разработки (DEV): код до предполагаемых манипуляций (если транспортные запросы не были перенесены).

Хранилище конфигурации: история всех изменений.

Типовая поставка SAP: эталон для сравнения (загружается с SAP Support Portal).

8.2. Метод сравнения:

Извлечь код из PROD через транзакцию SE38 (для программ) или SE80 (для классов).

Извлечь код из DEV или из хранилища.

Использовать утилиту diff (Linux) или встроенный компаратор SAP (System -> Utilities -> Compare).

Проанализировать различия. Обратить внимание на:

Добавленные условия (IF…).

Изменённые арифметические операции (умножение на коэффициент).

Вызовы новых, нестандартных функций.

Чтение из пользовательских таблиц (Z*).

8.3. Документирование результата: Эксперт фиксирует в заключении точные строки кода, которые были изменены, и объясняет, как эти изменения повлияли на бизнес-логику (например, «добавленный код увеличивает себестоимость на 35% для материалов из группы X»).

8.4. Важно: Код ABAP может быть обфусцирован (запутан). Эксперты Союза обучены распознавать такие техники. IT экспертиза SAP для подачи в суд всегда включает глубокий семантический анализ.

Глава 9. Метод анализа redo logs SAP HANA

SAP HANA становится стандартом. Методология анализа HANA redo logs отличается от Oracle или MS SQL. 🗄️

9.1. Особенности HANA:

In-memory архитектура, но critical operations (commit) всегда пишутся в redo log.

Закрытый формат redo logs, нет стандартного инструмента вроде LogMiner.

Требуется reverse engineering.

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

Локализовать redo log файлы (обычно в каталоге /hana/data).

Использовать утилиту hdbreplaylog (входит в состав HANA studio) для частичного декодирования.

Написать скрипт на Python для поиска и фильтрации записей по таблицам (например, MSEG, BSEG), операциям (INSERT, UPDATE, DELETE), временным меткам.

Извлечь before images (старые версии строк) для восстановления удалённых данных.

Сопоставить полученные данные с прикладными журналами (SM21, CDHDR).

9.3. Что можно доказать: То же самое, что и для Oracle: факт изменения/удаления данных, реальное время операции, имя пользователя.

9.4. Важно: Не все эксперты владеют методологией анализа HANA. Союз «Федерация судебных экспертов» — одна из немногих организаций в России, которая успешно проводит IT экспертиза SAP для подачи в суд на HANA.

Глава 10. Метод построения временной линии (timeline) для суда

Финальный аккорд методологии — синтез всех данных в единую хронологию. Судье нужна ясная, наглядная картина событий. 📅

10.1. Источники данных для timeline:

Redo logs / LDF / WAL (время операций INSERT, UPDATE, DELETE).

SM21 (время входа пользователей, выполнения транзакций).

Системные журналы ОС (Event Logs, syslog).

Транспортные запросы (даты создания и переноса).

Файловые системы (MAC-времена файлов).

10.2. Метод построения:

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

Нормализовать временные метки (привести к единому часовому поясу).

Отсортировать события по времени.

Представить в виде таблицы:

Время	Источник	Событие	Пользователь	IP-адрес
2024-01-15 10: 00: 00	Redo log	INSERT в MSEG (поступление товара)	SAP_MM_USER	10.0.1.10
2024-01-18 02: 15: 22	Redo log	DELETE из MSEG (удаление)	SAP_SD_ADMIN	10.0.1.200
2024-01-18 02: 10: 00	SM21	Вход пользователя	SAP_SD_ADMIN	10.0.1.200

10.3. Выявление аномалий: Эксперт анализирует timeline на предмет несоответствий:

Операция DELETE выполняется спустя несколько дней после INSERT — аномалия.

Вход пользователя в нерабочее время — аномалия.

Отсутствие записей в SM21 при наличии операций в redo log — аномалия.

10.4. Представление в суде: Timeline визуализируется в виде графика или таблицы в приложении к заключению. IT экспертиза SAP для подачи в суд становится наглядной и убедительной.

Глава 11. Метод оценки целостности журналов: обнаружение факта очистки

Ответчик, уничтожая следы, часто оставляет новые. Методология эксперта должна включать проверку целостности всех журналов. 🚮

11.1. Проверка целостности redo logs:

Для Oracle: проверить, не переключилась ли база в режим NOARCHIVELOG (журналы не сохраняются). Это само по себе подозрительно.

Для MS SQL Server: проверить настройку Recovery Model. Если она была Simple, а потом стала Full — возможно, журналы обрезались намеренно.

Для HANA: проверить настройки log_mode. normal — журналы сохраняются, overwrite — перезаписываются.

11.2. Проверка целостности SM21:

В SM21 есть запись об очистке журнала (архивации). Если такая запись есть в период спорных событий — это улика.

Если записи об очистке нет, но журнал подозрительно пуст — эксперт фиксирует: «установить причину отсутствия записей не представилось возможным».

11.3. Проверка целостности CDHDR/CDPOS:

Проверить, были ли отключены механизмы отслеживания изменений для критических таблиц (транзакция SCDO). Если отключены — зафиксировать.

Попытаться найти записи об удалении из CDHDR (в redo logs).

Экспертное правило: В IT экспертиза SAP для подачи в суд сам факт уничтожения или отключения журналов является самостоятельным доказательством недобросовестности ответчика. Суды учитывают это при распределении бремени доказывания.

Глава 12. Метод формулирования вопросов для экспертизы: от теории к практике

От того, как сформулированы вопросы, зависит, получите ли вы ответы, которые сможете использовать в иске. Методология формулирования вопросов должна быть известна и юристам, и экспертам. 📝

12.1. Признаки хорошего вопроса (методологический чек-лист):

Конкретность. Указаны таблицы, поля, документы, период.

Измеримость. Ответ может быть проверен.

Техничность. Вопрос относится к сфере специальных знаний, а не к праву.

Воспроизводимость. Другой эксперт, следуя той же методике, получит тот же ответ.

12.2. Пример хорошего вопроса:
«Имеются ли в системе SAP ERP ООО «Ромашка» (на базе СУБД Oracle) за период с 01.01.2024 по 31.03.2024 технические признаки (в журналах повтора Oracle, системном журнале SM21, таблицах изменений CDHDR/CDPOS или транспортных запросах) модификации или удаления записей о движении материалов (таблица MSEG) по документам отгрузки №№ 450000001-450000100, и если да, то восстановить эти записи с указанием даты, контрагента, номенклатуры и количества, а также установить учётную запись, с которой были выполнены операции модификации/удаления?»

12.3. Пример плохого вопроса:
«Были ли манипуляции с данными в SAP?» (оценочный, правовой).

Совет юристам: перед подачей ходатайства проконсультируйтесь с экспертом. Мы поможем сформулировать вопросы так, чтобы они были методологически корректны. IT экспертиза SAP для подачи в суд начинается с правильных вопросов.

Глава 13. Метод оценки стоимости и сроков экспертизы

Стоимость и сроки IT-экспертизы SAP зависят от многих факторов. Методология их расчёта должна быть прозрачной. 💰

13.1. Факторы, влияющие на стоимость:

Тип СУБД (HANA сложнее и дороже Oracle/MS SQL).

Объём данных (терабайты или гигабайты).

Необходимость восстановления удалённых данных (карвинг).

Срочность (коэффициент 1,5-2).

Выезд эксперта (транспорт, проживание).

Сложность кода ABAP (обфускация, объём).

13.2. Методика расчёта стоимости (в Союзе):

Базовый тариф за час работы эксперта (с учётом амортизации оборудования и ПО).

Повышающий коэффициент за сложность (например, HANA — 1,5).

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

13.3. Ориентировочные сроки:

Простая экспертиза (только SM21 и CDHDR) — 15-20 дней.

Средняя сложность (с анализом redo logs, без карвинга) — 30-40 дней.

Высокая сложность (с карвингом, HANA, обфусцированным кодом) — 60-90 дней.

Совет истцу: Не гонитесь за дешевизной. Качественная IT экспертиза SAP для подачи в суд не может стоить 200 тысяч рублей. Экономия на экспертизе — потеря иска.

Глава 14. Метод процессуального взаимодействия: эксперт и суд

Эксперт не существует в вакууме. Он взаимодействует с судом и сторонами. Методология этого взаимодействия должна быть чёткой. ⚖️

14.1. До назначения экспертизы:

Эксперт консультирует истца по формулировке ходатайства и вопросов.

Эксперт готовит обоснование необходимости экспертизы.

14.2. В ходе экспертизы:

Эксперт уведомляет суд о ходе исследования (если требуется).

Эксперт запрашивает дополнительные материалы (через суд).

14.3. После завершения экспертизы:

Эксперт направляет заключение в суд.

Эксперт вызывается в суд для дачи пояснений (по ходатайству стороны или инициативе суда).

14.4. В судебном заседании:

Эксперт даёт пояснения по заключению, отвечает на вопросы сторон и суда.

Эксперт не даёт правовой оценки («виновен», «не виновен»).

Эксперт не выходит за пределы своей компетенции.

Экспертное правило: Участие в судебном заседании — не менее важная часть работы, чем само исследование. Эксперт должен уметь защитить свои выводы. Союз «Федерация судебных экспертов» готовит своих экспертов к перекрёстным допросам.

Глава 15. Заключение: методология как путь к истине

Мы рассмотрели методологию IT экспертиза SAP для подачи в суд от А до Я: от сбора объектов до построения временной линии, от анализа redo logs до оценки целостности журналов. Три кейса показали, как эта методология работает на практике, превращая цифровой хаос в стройную картину преступления. 🧠

Союз «Федерация судебных экспертов» не просто владеет этой методологией — мы её развиваем. Мы публикуем статьи в рецензируемых журналах, обмениваемся опытом с коллегами, обучаем новых экспертов. Наша методология открыта для проверки и критики.

Если вы истец, готовящий иск к контрагенту, использующему SAP, помните: без методологии вы тонете. С методологией — вы плывёте к победе. Доверьтесь профессионалам. Доверьтесь Союзу «Федерация судебных экспертов».

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

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