SAP — это высокоинтегрированная ERP-система, используемая крупнейшими корпорациями для управления финансами, логистикой, производством и персоналом. Когда возникает судебный спор — о хищении, неисполнении контракта, некачественном внедрении или фальсификации отчетности — данные SAP становятся центральным доказательством. Однако суд не может принять распечатку транзакции как безусловную истину. Необходима глубокая, технически выверенная верификация. Именно эту задачу решает компьютерно-техническая экспертиза SAP для обращения с иском в суд, выполняемая независимыми экспертами Союза «Федерация судебных экспертов» (сайт: https://kompexp.ru/). Настоящая статья, написанная в техническом стиле, детально описывает методы и инструменты такой экспертизы: от анализа журналов аудита SM19/SM20 и redo logs HANA до статического анализа ABAP-кода и исследования системы транспортов. Приведены три реальных кейса.

Глава 1. Техническая архитектура SAP как объект экспертизы

SAP имеет трехуровневую архитектуру: уровень базы данных (SAP HANA, Oracle, DB2), уровень сервера приложений (ABAP Application Server) и клиентский уровень (SAP GUI, Fiori). Для компьютерно-технической экспертизы SAP для обращения с иском в суд критичны следующие компоненты:

• База данных HANA — колоночная in-memory СУБД, хранящая данные и журналы.

• Репозиторий ABAP — исходные коды, функциональные модули, классы.

• redo logs — последовательная запись всех изменений.

• Система транспортов (TMS) — журнал изменений конфигурации и разработок.

• Журналы аудита SM19/SM20 — действия пользователей.

• Бизнес-журналы CDHDR/CDPOS — изменения документов.

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

Глава 2. Технический протокол консервации объектов SAP

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

• Документирование серверной инфраструктуры (фото, видео).

• Определение режима работы: on-premise или cloud.

• При on-premise: graceful shutdown сервера приложений и сервера БД.

• Подключение аппаратных write-blocker-ов (Tableau T8, Atola Insight) к каждому диску.

• Создание побитовых образов всех дисков (системные, диски данных HANA, диски логов). Инструменты: FTK Imager, dd под Linux.

• Для работающих систем — создание «горячих» образов через Volume Shadow Copy или LVM-снапшоты.

• Для баз данных — создание логического дампа через SAP HANA backup или expdp.

• Вычисление хеш-сумм SHA-256 для каждого образа.

• Заполнение chain of custody.

• Для облачных SAP — запрос через суд выгрузки базы и всех доступных журналов.

Глава 3. Технический анализ журналов аудита SAP (SM19/SM20)

Журналы аудита SAP — первый уровень исследования. Технические детали:

• Настройка аудита через SM19 — фильтры на события: вход в систему, запуск транзакций, изменение полномочий, чтение критических таблиц.

• Просмотр через SM20 — экспорт в файл (формат CSV или ASCII).

• Парсинг файлов с помощью скриптов на Python (обработка логов до сотен гигабайт).

• Фильтрация по временному диапазону, пользователям, транзакциям, IP-адресам.

• Построение временной линии (timeline) действий каждого пользователя.

• Выявление аномалий: запуск SE16 (прямой доступ к таблицам) пользователем бухгалтерии, массовые изменения за короткое время, вход в нерабочее время.

• Сопоставление с redo logs HANA и STAD.

Если аудит не включен или очищен, эксперт фиксирует этот факт — он сам по себе значим.

Глава 4. Технический анализ redo logs SAP HANA

redo logs HANA — наиболее надежный источник для компьютерно-технической экспертизы SAP для обращения с иском в суд. Техническая методология:

• Локализация файлов redo logs: /usr/sap/<SID>/HDB/work/ (файлы log_*.dat).

• Использование встроенных инструментов HANA: SQL-функция M_REDO_LOG_VIEW для чтения логов. Команда: SELECT * FROM M_REDO_LOG_VIEW WHERE TIME > ‘…’.

• Утилита hdbreplaylog для воспроизведения логов.

• Извлечение всех операций INSERT, UPDATE, DELETE за период.

• Фильтрация по таблицам: VBRK (счета), BSEG (проводки), EKBE (история закупок), CDHDR (журналы изменений).

• Восстановление «мертвых версий» строк: HANA использует MVCC (Multi-Version Concurrency Control), старые версии хранятся до выполнения VACUUM.

• Преобразование сырых данных в осмысленные поля с помощью словаря данных SAP (SE11).

• Анализ LSN-последовательности для выявления backdating.

Глава 5. Кейс № 1: Восстановление 8 500 удаленных счетов-фактур из redo logs HANA

Техническая фабула: ООО «Торговый дом «Энергия» подало иск к ООО «СтройРесурс» о взыскании 340 млн руб. Истец представил счета-фактуры из SAP SD. Ответчик утверждал, что товар не получал. Суд назначил экспертизу.

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

• Доступ к серверу SAP HANA истца.

• Анализ redo logs за период, включающий даты документов и дату предполагаемой фальсификации.

• Обнаружены операции DELETE над таблицами VBRK/VBRP, выполненные через 2 дня после создания документов.

• Восстановлены «мертвые версии» — 8 512 счетов-фактур.

• Анализ LSN: LSN удаленных документов был выше, чем LSN документов, созданных на неделю позже (доказательство backdating).

• Системный журнал зафиксировал изменение времени сервера за 30 минут до операций DELETE.

• IP-адрес, с которого выполнялись DELETE, совпал с IP-адресом бухгалтера истца.

Суд отказал в иске, применив ст. 10 ГК РФ.

Глава 6. Технический анализ ABAP-кода: статические методы

ABAP-код часто содержит недокументированные изменения. Техническая методология:

• Получение эталонной версии объектов из системы разработки или из SAP Standard (транзакция SE80).

• Сравнение текущей версии с эталонной: SE39 (сравнение объектов), SE03 (транспорты), SCM (SAP Version Management).

• Анализ user-exit (транзакция SMOD/CMOD), BADI (SE18/SE19), enhancement spots (SE24).

• Поиск подозрительных конструкций: условные операторы с жестко закодированными датами, именами пользователей, ИНН контрагентов.

• Вызовы RFC/BAPI (транзакция SM59) на внешние системы.

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

• Документирование каждого изменения в виде листинга с подсветкой (diff).

• Восстановление истории изменений через систему транспортов (таблица E070).

Глава 7. Кейс № 2: Выявление модификации расчета цены в модуле MM через user-exit

Техническая фабула: Производственный холдинг подал иск к экс-директору по закупкам о взыскании 280 млн руб. Эксперты провели статический анализ ABAP-кода. Методология:

• Идентифицировали все user-exit для транзакции ME21N (создание заказа на поставку) — в частности, EXIT_SAPLXM06_002.

• Сравнили код с SAP Standard. Обнаружено: добавлен условный оператор IF EKKO-LIFNR IN Z_FAKE_VENDORS.

• Внутри условного оператора: EKPO-NETWR = EKPO-NETWR * 1.23 (увеличение на 23%) и создание скрытой позиции заказа с типом Z_HIDDEN.

• Анализ таблицы Z_FAKE_VENDORS (создана пользователем) — 12 ИНН аффилированных поставщиков.

• Анализ транспортного запроса: запрос был перенесен 3 года назад, автор — пользователь, совпадающий с подозреваемым.

• Восстановлены все заказы, затронутые модификацией, — 2 340 заказов на сумму 280 млн руб.

Суд удовлетворил иск.

Глава 8. Технический анализ системы транспортов (TMS)

TMS — журнал всех изменений в системе SAP. Техническая методология:

• Анализ таблицы E070 (основная таблица транспортных запросов) через SE16.

• Извлечение запросов за период: SELECT * FROM E070 WHERE AS4DATE BETWEEN ‘…’ AND ‘…’.

• Анализ таблицы E071 (объекты в запросе) для понимания, что именно изменилось.

• Поиск удаленных запросов: в E070 есть поле TRSTATUS = ‘D’ (deleted).

• Анализ системного журнала SM20 на предмет работы с транзакциями SE09, SE10.

• Сравнение временных меток объектов (программ, функциональных модулей) из таблицы TADIR с датами транспортных запросов.

• При несоответствии — доказательство прямого изменения в продуктивной системе.

• Восстановление истории изменений объекта через Version Management (транзакция SE38 → Version).

Глава 9. Кейс № 3: TMS-анализ в споре о некачественном внедрении SAP PS

Техническая фабула: Заказчик (нефтегазовая компания) подал иск к интегратору о взыскании 420 млн руб. за невыполненные работы по внедрению модуля SAP PS (Project System).

Эксперты выполнили TMS-анализ:

• Выгрузили все транспортные запросы из системы заказчика за период внедрения (14 месяцев).

• Сопоставили список объектов, перенесенных интегратором, с требованиями технического задания (87 требований).

• Обнаружено: только 34 требования имеют соответствующие транспортные запросы.

• По 22 требованиям транспортные запросы были созданы, но не перенесены в продуктивную среду (остались в статусе «разработка»).

• По 31 требованию транспортных запросов не было вообще.

• Интегратор утверждал, что изменения вносились напрямую в PRD. Эксперты проанализировали временные метки объектов в PRD — они не совпадали с датами подписанных актов приемки.

Суд удовлетворил иск.

Глава 10. Технический анализ бизнес-журналов изменений (CDHDR/CDPOS)

CDHDR/CDPOS — журналы изменений бизнес-объектов. Техническая методология:

• Определение, для каких таблиц включено журналирование (таблица TBE01).

• Запрос к CDHDR: SELECT * FROM CDHDR WHERE OBJECTCLAS = ‘…’ AND UDATE BETWEEN…

• Получение позиций из CDPOS: SELECT * FROM CDPOS WHERE CHANGENR =…

• Восстановление истории документа: создание, изменения полей, старые и новые значения.

• Анализ аномалий: массовые изменения одного документа (например, 50 изменений за минуту), изменения после закрытия периода.

• Сопоставление с SM20 (какой транзакцией выполнено изменение).

• Поиск удаленных записей CDHDR — анализ redo logs на операции DELETE над таблицами CDHDR/CDPOS.

Бизнес-журналы часто сохраняются, даже когда технические логи очищены.

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

Backdating — подделка дат документов. Техническая методология:

• Сравнение даты документа (поле BUDAT в BSEG, FKDAT в VBRK) с временем создания записи в таблицах (поле ERDAT).

• Анализ LSN-последовательности в redo logs: строго возрастающие LSN не могут быть подделаны. Документ с более ранней датой, но большим LSN — подделка.

• Анализ системного журнала Windows (Event ID 1 — System Time Changed) или логов ntpd в Linux.

• Анализ журнала STAD (транзакция STAT) — время выполнения транзакции на сервере приложений.

• Анализ последовательности номеров документов: если номер документа больше, а дата меньше — аномалия.

• Использование внешних источников: EDI-логи, почтовые логи, логи банк-клиента.

• Статистическая оценка вероятности случайного совпадения (обычно <0,0001).

Глава 12. Технический анализ облачных SAP (S/4HANA Cloud)

Облачные SAP требуют специальных методов. Техническая методология:

• Запрос через суд к провайдеру (SAP SE или партнеру) выгрузки дампа базы данных (формат .zip).

• Для S/4HANA Cloud: использование Audit Log Viewer (приложение, доступное через Fiori). Выгрузка логов в CSV.

• Анализ предоставленных данных на изолированном стенде.

• Проверка цифровых подписей выгрузки (если провайдер предоставил УКЭП).

• Восстановление данных из client-side cache (SAP GUI cache, Fiori cache).

• Оценка полноты: эксперт делает оговорку, что физический доступ к серверам отсутствовал.

• При отказе провайдера — ходатайство о наложении штрафа (ст. 119 АПК РФ).

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

Недобросовестные стороны могут пытаться препятствовать экспертизе. Типовые методы и контрмеры:

• Очистка SM20. Контрмера: redo logs HANA и бизнес-журналы CDHDR.

• Удаление транспортных запросов. Контрмера: таблица E070 сохраняет следы, анализ теневых копий.

• Модификация кода ABAP с последующим удалением истории. Контрмера: сравнение с SAP Standard, анализ временных меток файлов.

• Шифрование дисков BitLocker. Контрмера: дамп оперативной памяти (содержит ключ).

• Физическое уничтожение серверов. Контрмера: резервные копии (LTO-ленты, облачные).

• Использование удаленного доступа (RDP/VPN) для маскировки IP. Контрмера: анализ логов прокси-серверов и маршрутизаторов.

Эксперт должен быть готов к любому сценарию.

Глава 14. Техническая метрология и оценка достоверности

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

• Коэффициент восстановления данных: на тестовой базе SAP с известным содержимым удаляются документы, затем восстанавливаются. Указывается процент успеха.

• Вероятность ложного срабатывания: при анализе кода оценивается, сколько ложных срабатываний дает метод (например, 0,1%).

• Перекрестная верификация: факт считается доказанным, если подтвержден двумя независимыми методами (например, SM20 + redo logs).

• Метрологическая неопределенность: для временных меток указывается погрешность (±1 мс), для сумм — точность до копейки.

• Статистическая значимость: при выявлении аномалий вычисляется p-значение. При p < 0,001 вывод категорический.

Глава 15. Заключение: роль компьютерно-технической экспертизы SAP в судебной практике

Подводя итог, можно утверждать, что компьютерно-техническая экспертиза SAP для обращения с иском в суд является сложнейшим, но крайне востребованным видом судебной экспертизы. В данной статье мы представили технические методы: от протоколов консервации и анализа redo logs HANA до статического анализа ABAP-кода, TMS, бизнес-журналов и выявления backdating. Три кейса (восстановление из redo logs, выявление user-exit в MM, TMS-анализ в споре о внедрении) демонстрируют практическую эффективность.

Повторим ключевую фразу: компьютерно-техническая экспертиза SAP для обращения с иском в суд — это единственный способ превратить цифровые данные SAP в юридически значимые, научно обоснованные доказательства. Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/) обладает уникальными компетенциями в этой области. Доверяя нам, вы выбираете техническую точность, независимость и победу. Обращайтесь! 🟩