Конфликтный разбор методов, подводных камней и решений

SAP. Одно слово, за которым стоят миллиарды долларов, тысячи сотрудников, сложнейшие логистические цепочки и… бесконечные судебные споры. Вы думаете, ваша SAP-система надежно защищена? Думаете, журналы аудита нельзя подделать, а разработчики ABAP всегда действуют в интересах бизнеса? Вы глубоко ошибаетесь. В этой статье мы не будем хвалить SAP. Мы будем говорить о том, как инженерная экспертиза SAP по запросу суда вскрывает истину там, где ее пытаются спрятать за горами кода, поддельными транзакциями и стертыми логами.

Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/ekspertiza-programmnyh-produktov-na-baze-sistemy-1s/) — это те, кто не боится идти против «священных коров» бизнеса. Мы проведем вас по минному полю инженерной экспертизы SAP, покажем, где поджидают фальсификации, как их выявить и как защитить свои права, даже если противник — гигант с армией администраторов.

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

Глава 1. Почему SAP — идеальная платформа для злоупотреблений и как эксперты это раскрывают

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

Инженерная экспертиза SAP по запросу суда — это единственный инструмент, который способен разделить правду и ложь. Эксперт должен уметь:

• читать ABAP-код как открытую книгу;

• восстанавливать удаленные записи из redo logs HANA, даже если их «затерли»;

• анализировать транспортные запросы, даже если их пытались удалить;

• находить артефакты подделки времени, даже если системные журналы очищены.

Без этого — суд слеп.

Глава 2. Конфликт интересов: почему аудит силами самой компании не работает

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

И здесь начинается самое интересное: сторона, которая что-то скрывает, начинает всячески препятствовать экспертизе. Не предоставляют доступ к серверам, «случайно» повреждают диски, «забывают» пароли от SAP, отключают аудит. Наша задача — быть готовыми к этому конфликту. Мы заявляем ходатайства, требуем обеспечения доказательств, работаем с остаточными данными. В одном из кейсов ответчик отключил сервер за час до приезда экспертов. Мы смонтировали теневые копии и восстановили данные за последние 3 дня — прямо из кэша контроллера.

Глава 3. Инженерный протокол: как заставить сторону не уничтожать доказательства

Конфликт начинается с изъятия. Наш протокол жесткий:

• Присутствие понятых, видеофиксация.

• Немедленное физическое отключение серверов от сети и ИБП (батарейные блоки) — чтобы избежать удаленной команды на уничтожение.

• Подключение write-blocker к каждому диску.

• Создание образов «прямо сейчас», без обсуждений.

• Проверка целостности контрольных сумм.

• Опечатывание оригинальных дисков в присутствии сторон.

Если сторона отказывается предоставить доступ — эксперт фиксирует это, и суд делает выводы (ст. 10 ГК РФ — эстоппель). Мы сталкивались с ситуациями, когда представитель ответчика пытался физически помешать изъятию. Вызывали судебных приставов. Так что наш совет: заручитесь поддержкой суда с самого начала.

Глава 4. Анализ журнала аудита SM20: что делать, если он пуст или подчищен

Самый частый конфликтный момент: сторона заявляет, что журнал аудита SM20 «не велся» или «случайно очищен». Давайте будем реалистами: в крупных SAP-системах аудит безопасности — это требование стандартов (ISO 27001, PCI DSS, внутренние регламенты). Если он «не велся» — это уже нарушение, которое может трактоваться как недобросовестность. Но эксперт не сдается.

Контрмеры:

• Анализ файлов журналов SM20 в файловой системе (они могут быть удалены, но не перезаписаны).

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

• Анализ бизнес-журналов CDHDR/CDPOS — они часто не зависят от настроек SM20.

• Анализ трассировки ST05/STAD — если она была включена.

• Допрос системных администраторов под присягой.

В одном из дел ответчик утверждал, что SM20 не велся. Но эксперты нашли в каталоге /usr/sap/<SID>/DVEBMGS00/work файлы аудита за 2 года, которые не были удалены. Суд расценил это как умышленное сокрытие.

Глава 5. Статический анализ ABAP-кода: как найти «бомбу», заложенную разработчиками

Это отдельный фронт борьбы. Разработчики SAP (как свои, так и подрядчики) могут внедрить в код логику, которая в определенный момент или при определенных условиях делает нечто, не предусмотренное бизнес-процессом. Например, при заказе у конкретного поставщика сумма автоматически увеличивается на 10%, а разница переводится на сторонний счет. Или при закрытии периода выполняется скрытая проводка.

Инженерная экспертиза SAP по запросу суда должна это найти. Методы:

• Сравнение кода с эталоном (SAP Standard или предыдущей версией).

• Поиск всех user-exit, BADI, enhancement spots, связанных с критическими транзакциями (FI, CO, MM, SD).

• Анализ кода на предмет «спящих» условий (if date > ‘2024-01-01’…).

• Проверка наличия скрытых вызовов RFC/BAPI на внешние системы.

• Анализ системы транспортов — кто, когда и зачем вносил изменения.

Если разработчик не хочет показывать изменения — эксперт может восстановить их из теневых копий системы.

Глава 6. Кейс № 1: Как директор по закупкам через user-exit в SAP обогатился на 340 млн рублей

Конфликтная фабула: В крупной металлургической компании был обнаружен рост себестоимости закупаемого сырья на 25–40% по отдельным позициям. Внутренний аудит развел руками. По иску акционеров суд назначил экспертизу. Эксперты Союза «Федерация судебных экспертов» взялись за дело.

Конфликт: IT-директор компании, лояльный генеральному директору, отказывался предоставлять доступ к коду ABAP, ссылаясь на коммерческую тайну. Суд вынес определение об изъятии серверов.

При анализе обнаружено: в user-exit для транзакции ME21N (создание заказа на поставку) внедрен код, который для трех поставщиков (аффилированных с директором по закупкам) умножал цену каждой позиции на коэффициент 1.25 и создавал скрытую позицию заказа с типом «Логистика». При этом в стандартных отчетах цена отображалась корректная, а в бухгалтерию уходила завышенная. Транспортный запрос на изменение был создан из учетной записи директора по закупкам, но с IP-адреса, который вел на компьютер разработчика.

Суд взыскал 340 млн руб. с директора и разработчика солидарно. Этот кейс — классика конфликтной экспертизы.

Глава 7. Анализ redo logs HANA: когда удаление не помогает

HANA — это in-memory база, но она тоже пишет журналы. И эти журналы — наше все. Конфликтный сценарий: сторона удалила документы (счета, заказы, платежные поручения) и утверждает, что их «никогда не было».

Эксперт:

• Локализует redo logs за период, когда документы предположительно существовали.

• Анализирует операции DELETE над нужными таблицами (например, VBRK, VBRP для счетов).

• Восстанавливает «мертвые версии» строк (MVCC в HANA).

• Предъявляет суду восстановленные документы в первоначальном виде.

В одном из дел ответчик даже сжег жесткие диски (физически). Но резервные копии на LTO-лентах хранились в другом городе. Эксперты вылетели туда, извлекли данные за 6 месяцев до уничтожения и восстановили всё. Сторона была привлечена к ответственности за уничтожение доказательств (ст. 125 УПК РФ).

Глава 8. Кейс № 2: Спор о фальсификации продаж в модуле SD — восстановление из redo logs HANA

Суть конфликта: Производитель дорогостоящего оборудования подал иск к дистрибьютору о взыскании 890 млн руб. якобы за отгруженную продукцию. Дистрибьютор утверждал, что продукцию не получал, а счета-фактуры (VBRK) были созданы в SAP истца в одностороннем порядке. Суд назначил экспертизу по ходатайству ответчика.

Эксперты получили доступ к серверу SAP истца (несмотря на сопротивление его IT-службы). Анализ redo logs HANA показал:

• Счета-фактуры были созданы в даты, указанные в иске, но LSN-номера (Log Sequence Number) этих операций были выше, чем у документов, созданных на неделю позже. Это прямо указывало на вставку задним числом.

• Журнал системного времени сервера зафиксировал перевод часов на 10 дней назад за 5 минут до создания документов и возврат обратно.

• Журнал SM20 был очищен, но в redo logs нашли операции DELETE из таблиц SM20.

Суд отказал в иске, применив ст. 10 ГК РФ (недобросовестность), и взыскал судебные расходы с истца. Кейс показал: даже если вы думаете, что «все замели», redo logs HANA выдаст правду.

Глава 9. Система транспортов (TMS): как выявить нелегальные изменения, даже если их попытались скрыть

Любое изменение в SAP, сделанное по правилам, оформляется транспортным запросом. Но злоумышленники могут пойти другим путем: изменить код или конфигурацию прямо в продуктивной системе (что категорически запрещено) или перенести транспорт без документации.

Экспертные методы выявления:

• Анализ таблицы E070 (записи о транспортных запросах). Даже если запрос удален, следы могут остаться.

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

• Анализ системных журналов (журнал изменений SM30 для таблиц настроек).

• Поиск объектов, у которых дата последнего изменения (timestamp) отличается от даты последнего транспортного запроса — это явное указание на прямое изменение.

• Анализ прав доступа: кто имеет полномочия на транзакцию SE38 (редактирование программ) и SE11 (словарь данных) в продуктивной системе.

В одном споре ответчик пытался доказать, что изменения «вносил системный администратор по ошибке», но эксперты нашли, что у администратора не было прав на SE38 — значит, изменения вносил кто-то другой, чьи права были скрыты.

Глава 10. Кейс № 3: Интегратор «забыл» внести функционал в SAP — анализ транспортов спас заказчика

Конфликт: Заказчик (нефтехимический холдинг) подал иск к интегратору о взыскании 600 млн руб., уплаченных за внедрение SAP S/4HANA, поскольку система не реализовывала критический функционал: многоуровневый расчет себестоимости с учетом возвратных отходов. Интегратор утверждал, что «всё работает, вы сами неправильно тестируете».

Эксперты сравнили техническое задание и транспортные запросы. Обнаружили:

• В техническом задании было 47 конкретных требований к модулю CO.

• В системе транспортов заказчика (Dev → QAS) были запросы, реализующие не более 12 требований.

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

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

• В ABAP-коде нашли заглушки-закомментированные участки, обещавшие функционал, но не реализованные.

Суд удовлетворил иск, взыскав полную стоимость. Кейс показал: система транспортов — не просто технический инструмент, а юридически значимый журнал работ.

Глава 11. Конфликтная экспертиза времени: как поймать на подделке дат даже при изменении системных часов

Подделка временных меток (backdating) — любимый прием фальсификаторов. Но современная экспертиза бьет по нему с трех сторон:

• Анализ последовательности LSN в redo logs HANA — строго возрастающие номера операций, их нельзя подделать.

• Анализ системного журнала времени (Event ID 1 в Windows, ntpd.log в Linux) — любое изменение времени фиксируется.

• Анализ «шумов» — следов выполнения операций в технологических журналах (STAD), которые имеют привязку к аппаратному времени.

• Сравнение времени создания документа в бизнес-журнале (CDHDR) и времени соответствующей операции в redo logs. Расхождение более чем на несколько секунд (при синхронизированных часах) — аномалия.

В одном деле ответчик перевел время на сервере на месяц назад, создал документы, а потом вернул время. Но redo logs зафиксировали эти операции с реальным временем (LSN-последовательность). Суд признал документы сфальсифицированными.

Глава 12. Противодействие экспертизе: самые грязные методы сторон и как мы их обходим

Конфликтная экспертиза — это война. Мы сталкивались с:

• Удалением дисков из RAID-массива «по ошибке» прямо перед нашим приездом. Контрмера: анализ SMART-логов, которые показывают, когда диск был отключен.

• Внесением изменений в код ABAP для маскировки схемы уже после начала суда. Контрмера: использование резервных копий из теневых копий или из систем разработки.

• Подкупом свидетелей из числа IT-администраторов, которые дают ложные показания. Контрмера: анализ всех журналов, поиск нестыковок.

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

• Шифрованием дисков BitLocker с отказом предоставить пароль. Контрмера: анализ дампа памяти работающего сервера, где ключ может храниться.

Мы готовы к любому развитию событий.

Глава 13. Облачные SAP: конфликт юрисдикций и невозможность изъять оборудование

Облачные SAP (S/4HANA Cloud, C4C) — головная боль для эксперта. Нет физического доступа, провайдер (SAP или партнер) может не сотрудничать. Конфликт: суд одного государства требует предоставить данные, которые хранятся на сервере в другой стране.

Решения:

• Запрос данных через правовую помощь (Гаагская конвенция, но это долго).

• Использование встроенных средств SAP Cloud для выгрузки audit logs (они есть).

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

• В крайнем случае — анализ скриншотов и API-логов, которые сторона может предоставить.

Но эксперт всегда делает оговорку о невозможности полной верификации. В российских судах это принимается, если нет альтернативы.

Глава 14. Как оспорить заключение эксперта SAP: чего не любят суды

Конфликтная экспертиза часто сопровождается попытками оспорить заключение. Типовые основания:

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

• Эксперт использовал невалидные методы.

• Эксперт не ответил на вопросы.

• Есть внутренние противоречия.

• Эксперт был заинтересован.

Наша защита: мы всегда строго соблюдаем методики, даем категоричные ответы, избегаем правовых оценок, декларируем независимость. Суды не любят, когда сторона просто заявляет «не согласны», но не приводит конкретных контраргументов или рецензию специалиста. Чтобы оспорить наше заключение, нужна такая же глубокая экспертиза. В 95% дел наши заключения принимаются судами.

Глава 15. Заключение: инженерная экспертиза SAP — ваш последний рубеж защиты

Подводя итог, можно сказать жестко: без инженерной экспертизы SAP по запросу суда вы беспомощны перед цифровым всесилием крупных корпораций. Зная сложность SAP, зная, как легко модифицировать код, очищать логи и уничтожать данные, суд не может положиться на простые распечатки. Только независимый, конфликтно-устойчивый, технически оснащенный эксперт способен восстановить истину.

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

Повторим ключевую фразу: инженерная экспертиза SAP по запросу суда — это не просто техническая процедура, это битва за справедливость в цифровую эпоху.

Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/ekspertiza-programmnyh-produktov-na-baze-sistemy-1s/) готов принять этот вызов. Мы не боимся конфликтов, мы умеем работать в условиях противодействия и всегда докапываемся до истины. Если вам нужна защита в суде — обращайтесь. Ваша правда имеет значение. 🟩