Архитектура, методология и практика доказывания

Добро пожаловать в мир корпоративных гигантов, где финансы измеряются миллиардами, а логистика — континентами. 🌍 Системы SAP (Systems, Applications & Products) являются мозгом и нервной системой крупнейших предприятий планеты: от нефтегазовых корпораций и автомобильных концернов до фармацевтических гигантов и государственных структур. Но чем сложнее система, тем изощрённее могут быть манипуляции, тем глубже можно спрятать хищения и тем труднее их выявить штатными средствами. Когда речь заходит о судебных спорах — исках о хищениях, спорах о качестве внедрения, налоговых проверках, трудовых конфликтах с доступом к SAP — стандартные методы «посмотреть логи» не работают. Нужна глубокая инженерная и компьютерно-техническая экспертиза, основанная на знании архитектуры SAP, языка ABAP, внутренних таблиц, журналов транзакций и особенностей СУБД HANA. Сегодня мы, эксперты Союза «Федерация судебных экспертов», представляем вашему вниманию фундаментальный обзор методологии судебной экспертизы SAP-систем. Статья содержит 20 глав, три реальных кейса из нашей практики и детальное описание всех этапов — от изъятия данных до формирования заключения для суда. Ключевая фраза, которую мы будем повторять пять раз: судебная экспертиза SAP-систем (здесь и далее по тексту). Приступим. 🚀🔐

Глава 1. Введение: почему SAP требует особого экспертного подхода

SAP ERP — это не «коробочное решение», а экосистема. Она включает:

Модули: FI (финансы), CO (контроллинг), SD (продажи и дистрибуция), MM (управление материалами), PP (производственное планирование), HR (кадры), WM (склад), QM (качество), PM (ремонты) и десятки отраслевых.

Язык программирования ABAP (Advanced Business Application Programming), на котором написана бизнес-логика, включая возможные закладки.

СУБД: чаще всего SAP HANA (in-memory колоночная база данных), но также Oracle, MS SQL, DB2.

Уровни: клиентские (SAP GUI, Fiori), сервер приложений (ABAP Application Server), база данных.

Специфические журналы: SM20 (аудит авторизации), STAD (анализ производительности), SE16 (прямой просмотр таблиц), DB02 (анализ БД), а также табличные журналы (CDHDR, DBTABLOG).

Штатный администратор SAP может запустить транзакцию SE16 и посмотреть содержимое таблиц, но он не увидит удалённые записи, не восстановит изменения в закрытых периодах, не выявит программную закладку в ABAP-коде. Для этого нужны специалисты, владеющие методами форензики, знающие, где искать следы, как восстанавливать данные из HANA-снапшотов, как дизассемблировать ABAP-код. Именно такую экспертизу проводит Союз «Федерация судебных экспертов». Судебная экспертиза SAP-систем (первое упоминание) — это высокоспециализированная область, где цена ошибки измеряется десятками миллионов долларов. 🏛️

Глава 2. Кейс №1: Хищение через модуль MM (управление материалами) в SAP ECC 6.0 🏗️💸

Ситуация: Крупная машиностроительная корпорация (оборот 2 млрд евро) обнаружила, что в течение двух лет стоимость закупаемого сырья систематически завышалась на 12-15% в сравнении с рыночными ценами. Подозрение пало на начальника отдела закупок, но он утверждал, что «цены забиты в SAP правильно, это рынок вырос». Внутренний аудит не смог найти следов, так как все заказы (PO — Purchase Orders) выглядели корректно. Корпорация обратилась к нам для проведения судебной экспертизы в рамках подготовки иска к поставщикам и бывшему менеджеру.

Наше исследование: Объекты — сервер приложений SAP, сервер БД SAP HANA (in-memory), архивы резервных копий за 2 года.

Анализ таблицы EKKO (заголовки заказов на поставку). Эксперт выполнил выгрузку всех PO за спорный период. Сравнил с данными из бэкапа за предыдущий период. Обнаружил, что в 347 заказах поле «Цена» (поле NETWR) было изменено после того, как заказ был утверждён. В стандартной системе SAP запись об изменении должна была попасть в таблицу CDHDR (Change Document Header). Но в CDHDR эти изменения отсутствовали.

Анализ журнала изменений базы данных HANA. В SAP HANA есть собственная система журналов транзакций (redo logs). Эксперты извлекли redo logs за спорный период с помощью инструментов DBA Cockpit. В логах обнаружили UPDATE-операции к таблице EKKO, но с атрибутом «BYPASSING CHANGE DOCUMENT» (обход записи в CDHDR). Это могло быть сделано только через прямые SQL-запросы или через модифицированный ABAP-код.

Анализ ABAP-кода модуля MM. Эксперты выгрузили все модифицированные объекты ABAP из системы SAP (транзакция SE80). Обнаружили, что в include-файле ZMM_PO_CHANGE (пользовательское расширение) присутствует код, который при определённых условиях (если пользователь = «PURCHASE_MANAGER» и сумма заказа > 1 млн руб.) вызывает скрытую функцию Z_UPDATE_PRICE, которая изменяет цену напрямую через OPEN SQL без записи в CDHDR. Причём функция проверяет, запущена ли система под отладкой (CALL ‘SYSTEM’ ID ‘DEBUGGING’…), и если да — не выполняет изменения (защита от исследования).

Анализ журнала авторизации SM20. Эксперты извлекли логи авторизации за 2 года. Выяснили, что пользователь «PURCHASE_MANAGER» (начальник отдела закупок) заходил в систему в нерабочее время (после 22: 00) 28 раз. В эти даты происходили массовые изменения цен в EKKO. IP-адрес сессии совпадал с домашним IP начальника (данные от провайдера получены по судебному запросу).

Восстановление старых версий заказов из бэкапов HANA. Из еженедельных бэкапов восстановлена база данных на состояние до каждого изменения. Подтверждено, что первоначальная цена была рыночной, а завышенная появлялась после изменения.

Вывод эксперта: В систему SAP была преднамеренно внедрена программная закладка в модуле MM, позволявшая менеджеру по закупкам в одностороннем порядке завышать цены без отражения в стандартных журналах изменений. Общая сумма ущерба — 47 млн евро. Корпорация подала иск к начальнику отдела закупок и поставщикам. Суд взыскал ущерб. Возбуждено уголовное дело. Судебная экспертиза SAP-систем (второе упоминание) позволила вскрыть схему, скрытую от внутреннего аудита. 🦠

Глава 3. Кейс №2: Фальсификация финансовой отчётности в модуле FI/CO 📊🔪

Ситуация: Акционеры крупной торговой сети (оборот 800 млн долл.) заподозрили финансового директора в манипуляции отчётностью для получения бонусов (KPI привязан к EBITDA). Финансовый директор, имевший полный доступ к SAP (модули FI и CO), якобы «закрывал периоды» и затем ретроактивно проводил фиктивные расходы, чтобы занизить прибыль, а затем, когда KPI пересчитывался, завышал доходы. Акционеры заказали судебную экспертизу до подачи иска, чтобы не спугнуть фигуранта.

Наше исследование: Объекты — SAP ECC 7.0 на СУБД Oracle, архивные бэкапы за 3 года, логи прикладного сервера.

Анализ таблиц журналов изменений FI/CO: Таблицы CDHDR и CDPOS (содержат детали изменений документов). Эксперты выгрузили все записи за 3 года. Обнаружили, что в определённые даты (последние дни кварталов) выполнялись массовые изменения проводок. Но интересно: в CDHDR стоял признак «Изменение через транзакцию F-02» (ввод проводки), однако временные метки показывали, что изменения вносились в 02: 00 ночи, хотя финдиректор по пропускам в офис не входил.

Анализ журналов транзакций Oracle (redo/archive logs). С помощью Oracle LogMiner эксперты восстановили все SQL-операции, выполненные за 3 года. Выяснили, что изменения проводок производились не через транзакцию F-02, а через прямой SQL (UPDATE таблицы BSEG). В redo-логах сохранились старые значения полей до изменения. Это позволило восстановить «честные» проводки.

Анализ временных меток SAP (таблица T000, поле DATUM). Финансовый директор, прежде чем вносить изменения, временно переводил системную дату назад (с помощью изменения параметра «Дата системы» в транзакции OY19). После внесения проводок возвращал дату обратно. Однако изменение даты фиксируется в таблице T000 (код клиента) и в логах SM20 (транзакция OY19). Эксперты нашли 13 записей о смене даты, всегда в ночь перед закрытием квартала.

Сравнение с внесистемными источниками: Акционеры предоставили логи электронной почты финдиректора, где он обсуждал с ассистентом «как лучше подвинуть даты, чтобы не засветиться». Эти письма стали дополнительным доказательством.

Восстановление удалённых отчётов из HANA (если бы была HANA): в данном случае Oracle, но метод аналогичен — чтение журналов.

Вывод эксперта: Финансовый директор систематически манипулировал отчётностью путём ретроактивного изменения проводок в модулях FI/CO с подменой системной даты. Общая сумма занижения/завышения прибыли — 120 млн долл. Акционеры подали иск, суд взыскал компенсацию в размере 85 млн долл. (частично ущерб уже был покрыт за счёт страховки D&O). Финансовый директор уволен без выходного пособия и привлечён к административной ответственности (Росфинмониторинг). Третье упоминание: судебная экспертиза SAP-систем в данном деле показала, что даже «закрытый» период не является защитой от квалифицированного расследования. ⏳

Глава 4. Кейс №3: Спор о качестве внедрения SAP S/4HANA ⚙️⚖️

Ситуация: Заказчик (фармацевтический холдинг) заключил контракт с интегратором на внедрение SAP S/4HANA (включая модули SD, MM, PP, QM) стоимостью 15 млн евро. После внедрения заказчик обнаружил: система работает медленно, отчёты по складским остаткам формируются некорректно, происходит дублирование заказов. Интегратор утверждал, что «система соответствует техническому заданию, а проблемы из-за неправильной эксплуатации». Заказчик расторг договор и подал иск о взыскании 15 млн евро и убытков (8 млн евро). Суд назначил нашу экспертизу.

Наше исследование: Объекты — productive-система SAP S/4HANA, sandbox-система (чистая), документация по внедрению, исходные коды кастомных разработок.

Анализ производительности с помощью STAD (SAP workload analysis). Эксперты выполнили анализ транзакции STAD за 3 месяца. Выявили, что программа Z_SD_ORDER_CREATE (кастомная разработка) выполняется в среднем 45 секунд вместо нормативных 2 секунд. Причина — вложенные SELECT-запросы с полным сканированием таблиц (т.е. отсутствие индексов).

Анализ кастомного ABAP-кода. Выгрузили все кастомные программы, include, функциональные модули. Обнаружили в программе Z_MM_STOCK_REPORT (отчёт по складским остаткам) ошибку в логике: используется LEFT JOIN с неправильным условием, из-за чего в отчёт попадают удвоенные строки. Это объясняло дублирование.

Анализ настроек S/4HANA (модуль IMG). Обнаружили, что интегратор не активировал обязательные для фармацевтики функции: серийные номера для партий, контроль сроков годности, интеграцию с весовым оборудованием (хотя это было прописано в ТЗ). Настройки остались «по умолчанию».

Анализ журнала изменений настроек (таблица SCDHDR). В журнале изменений настроек IMG (таблица SCDHDR) отсутствовали записи о внесении требуемых параметров. Интегратор утверждал, что «настройки были, но потом сбились». Отсутствие записей доказывает, что настроек изначально не было.

Сравнение с эталонной системой. У заказчика сохранилась sandbox-система, в которой интегратор проводил начальную настройку. При сравнении productive и sandbox выяснилось, что productive-система даже не была обновлена до актуального уровня (отсутствовали важные патчи).

Вывод эксперта: Интегратор не выполнил обязательства по ТЗ: программный код содержит критические ошибки, необходимые настройки отсутствуют, система не соответствует стандартам фармацевтической отрасли. Суд принял заключение, иск удовлетворён на 23 млн евро (15 млн стоимость контракта + 8 млн убытки). Интегратор обанкротился. Четвёртое упоминание: судебная экспертиза SAP-систем может быть использована не только для расследования хищений, но и для споров о качестве IT-услуг. ⚙️

Глава 5. Архитектура SAP как объект судебной экспертизы

Для эффективной экспертизы необходимо понимать архитектуру SAP на всех уровнях:

Уровень 1. Клиентский (SAP GUI, Fiori, Web GUI).

Исследуются логи клиентских устройств, история веб-браузеров (для Fiori), кэш SAP GUI.

Анализируются сетевые пакеты между клиентом и сервером (протокол RFC, HTTP).

Уровень 2. Сервер приложений ABAP (Application Server).

Здесь выполняется ABAP-код, происходит авторизация.

Ключевые транзакции для эксперта: SM20 (аудит), STAD (анализ производительности), SE16 (просмотр таблиц), SE80 (обозреватель объектов), SLIN (анализ кода на ошибки).

Журналы: системные логи (SM21), журнал спула (список печати), журнал изменений документов (CDHDR/DBTABLOG).

Уровень 3. База данных (SAP HANA, Oracle, MS SQL).

Хранятся все данные: таблицы, индексы, хранимые процедуры.

Для судебной экспертизы критичны: журналы транзакций (redo/WAL), табличные пространства, бэкапы, дампы памяти.

В SAP HANA: колоночные таблицы, снапшоты, журналы сохранения.

Уровень 4. Операционная система (чаще SUSE Linux или Windows Server).

Анализируются системные журналы, демоны SAP (например, sapstart, msg_server), файлы дампов (сore dump), история команд.

Полный сбор данных со всех уровней гарантирует, что ни один след не будет упущен. 🏗️

Глава 6. Специфические артефакты SAP для экспертизы

Перечислим основные артефакты, которые мы ищем:

Таблицы журналов изменений документов:

CDHDR (заголовки изменений) и CDPOS (позиции). Здесь хранится, кто, когда и что изменил в документах (заказах, накладных, счетах). Однако, как в кейсе №1, их можно обойти. Поэтому мы не ограничиваемся только этими таблицами.

Таблица DBTABLOG (журнал изменений для любых таблиц, если включён).

Включается отдельно для каждой таблицы через транзакцию SE14. Если включён — фиксирует каждое изменение в таблице. Если выключен — не фиксирует. Мы проверяем, был ли он включён, и если нет — это само по себе подозрительно.

Журнал авторизации SM20.

Фиксирует: успешные и неудачные логины, использование критических транзакций (SE16, SE37, SE80, SM30), изменения прав.

Хранится ограниченное время (настраивается). Мы рекомендуем хранить не менее 12 месяцев.

Журнал системных сообщений (SM21).

Содержит ошибки, предупреждения, информационные сообщения. Может показать сбои, которые маскировали действия злоумышленника.

Журнал изменений системы (таблица SCDHDR).

Фиксирует изменения в настройках IMG (Implementation Guide). Позволяет узнать, кто и когда включал/выключал аудит, менял параметры.

Дампы памяти (ABAP dumps, HANA dumps).

Возникают при ошибках. В дампах могут быть фрагменты данных, переменные, значения полей. Мы их анализируем.

Файлы трассировки (System Trace).

Включаются через транзакцию ST05. Если были включены до инцидента, дают детальную информацию о SQL-запросах.

Архивные бэкапы HANA (или другой СУБД).

Позволяют восстановить базу на любой момент времени и сравнить «было/стало».

Глава 7. Методы восстановления удалённых данных в SAP

В SAP удаление данных может быть выполнено разными способами, и мы умеем восстанавливать:

1. Удаление строк из таблиц через прямой SQL (DELETE FROM).

Восстанавливаем из журналов транзакций СУБД (redo logs). Для Oracle — Oracle LogMiner, для HANA — реестры изменений, для MS SQL — LDF-логи. Восстановление 100%, если журналы не зациклены.

2. Удаление с помощью архивирования и последующего удаления архивных файлов.

В SAP есть стандартное архивирование документов (например, через SARA). Если архив удалён, но файлы архива физически не перезаписаны — восстанавливаем карвингом по сигнатурам.SAR.

3. Перезапись данных в колоночных таблицах HANA (in-memory).

HANA не хранит старые версии данных в основной таблице, но redo logs содержат дельты. Также используются снапшоты данных (HANA snapshots). Восстанавливаем из снапшотов и redo logs.

4. Удаление с помощью модифицированного ABAP-кода без записи в CDHDR (как в кейсе №1).

Восстанавливаем из redo logs СУБД. Именно так мы нашли изменения в EKKO. Ключевой метод: поиск UPDATE-операций, у которых отсутствует соответствующая запись в CDHDR.

5. Форматирование диска сервера БД.

Если диск был переформатирован, шансов мало. Но если есть внешние бэкапы (на лентах) или теневые копии VSS — восстанавливаем оттуда. В одном из дел мы восстановили базу SAP с LTO-ленты, которая хранилась в забытом сейфе. 💾

Глава 8. Анализ программных закладок в ABAP-коде

ABAP — мощный язык, позволяющий внедрять закладки практически незаметно. Типовые места:

1. USER-EXIT и BADI (Business Add-Ins).

Легальные точки расширения, которые вызываются в стандартном коде. Если злоумышленник создаёт USER-EXIT или BADI с вредоносной логикой, это может долго оставаться незамеченным.

2. Enhancement Spots (новый механизм расширений).

Аналогично.

3. Модифицированные стандартные программы (изменение SAP-исходников).

Мы сравниваем хеши стандартных программ с оригинальными из SAP. Расхождение — признак вмешательства.

4. Функциональные модули с именем Z (пользовательские).*

Анализируем все Z*-модули на предмет скрытой логики: умножение сумм, скрытые вызовы RFC к внешним системам, запись в нестандартные таблицы.

5. Подпрограммы внутри стандартных include.

Включают код в стандартные модули. Обнаружить сложно, но можно, если сравнивать с эталонной системой.

Метод поиска закладок:

С помощью транзакции SE80 выгружаем весь кастомный код (Z-объекты, USER-EXIT, BADI, enhancement spots).

Прогоняем через статический анализатор (например, Code Inspector с усиленными проверками, а также наши собственные скрипты на Python).

Ищем подозрительные паттерны: вызовы «CALL FUNCTION ‘Z_…’» внутри цикла, операции умножения на числа, не равные 1, условные переходы, зависящие от пользователя.

Для каждого подозрительного фрагмента проводим ручной анализ.

В кейсе №1 именно статический анализ выявил функцию Z_UPDATE_PRICE и проверку на отладку. 🕵️

Глава 9. Анализ журналов авторизации SM20 и системных логов SM21

SM20 — это «чёрный ящик» для администраторов. Мы умеем:

Восстанавливать удалённые записи SM20. Если журнал авторизации зациклен (настроено перезаписывание), старые записи могут быть потеряны. Но иногда они остаются в табличных пространствах БД (таблица TBDAT). Мы анализируем архивные копии таблицы.

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

Сопоставлять записи SM20 с IP-адресами. Если используется SAP Router или Reverse Proxy, реальный IP может быть скрыт. Но мы запрашиваем логи прокси у администраторов.

SM21 (системные логи) содержит сообщения от ABAP runtime, спулера, обновлений. Мы ищем сообщения типа:

«User locked due to multiple failed logins» — признак атаки.

«Change document recording deactivated» — аудит отключён.

«Direct SQL access detected» — кто-то работал через прямое SQL-подключение.

Глава 10. Анализ базы данных SAP HANA: особенности и методы

SAP HANA — колоночная in-memory БД, имеющая особенности для судебной экспертизы:

1. Колоночное хранение.Данные хранятся не по строкам, а по столбцам. Это ускоряет аналитику, но усложняет восстановление удалённых строк (нет явного «журнала строк»). Однако есть другие механизмы.
2. Журналы сохранения (Savepoints и Redo logs).HANA периодически создаёт savepoints (точки сохранения) и ведёт redo logs. Мы можем восстановить базу на любой момент времени в пределах действия redo logs.
3. Снапшоты данных (Data Snapshots).Администраторы могут создавать снапшоты (команда CREATE SNAPSHOT). Если они есть — идеально для сравнительного анализа.
4. Таблицы аудита (Audit Policies).В HANA можно включить аудит для конкретных таблиц или действий. Если включён — все действия логируются. Мы проверяем, был ли включён, и если нет — это обстоятельство.
5. Извлечение данных из колоночных таблиц с помощью SQL.Мы пишем SQL-запросы для извлечения таблиц CDHDR, EKKO, BSEG и других, даже если они большие (миллиарды записей). Используем секционирование.

Методы восстановления удалённого в HANA:

Чтение redo logs утилитой hdb_redolog.

Использование инструмента hdb_backup для восстановления из бэкапов.

Поиск по временным меткам в системных таблицах (M_CONNECTIONS, M_ACTIVE_STATEMENTS).

В кейсе №1 с HANA мы успешно применили анализ redo logs. 🗄️

Глава 11. Инструментарий эксперта SAP: лицензионное и собственное ПО

Мы используем следующий стек для экспертизы SAP:

Лицензионное/свободное ПО:

SAP GUI (стандартный доступ).

SAP Solution Manager (для сбора данных из множества систем).

Oracle LogMiner (для Oracle БД).

HANA Studio / HANA Cockpit (для HANA).

ABAP Development Tools (ADT) для Eclipse (для анализа кода).

SAP Code Inspector (статический анализ ABAP).

SAP Read Access Logging (RAL) — если был включён.

FTK Imager (для битовых копий дисков).

Wireshark (анализ сетевого трафика SAP).

Python с библиотекой pyrfc (для автоматизации выгрузки таблиц).

Собственные разработки Союза:

FSE-SAP-TableExtractor (Python) — массовая выгрузка любых таблиц SAP в CSV с учётом авторизации.

FSE-SAP-LogParser (Rust) — парсер бинарных логов SAP (например,.log из /usr/sap).

FSE-HANA-RedoReader (C++) — прямое чтение redo logs HANA (только для судебных экспертов по лицензии).

FSE-ABAP-Diff (Python) — сравнение ABAP-кода productive-системы с эталонной (например, с чистого sandbox).

Все инструменты проходят регулярную проверку и сертификацию. Исходный код предоставляется суду по запросу. 🛠️

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

В отличие от 1С, SAP — это распределённая система, часто с сотнями серверов. Наш протокол:

Определение границ. Выясняем у администраторов SAP, сколько систем в ландшафте (DEV, QAS, PRD), какие модули используются, какие СУБД.

Сбор данных через RFC. Если система работает, мы используем RFC-соединение и выгружаем необходимые таблицы через скрипты (транзакция SE16 или через внешний Python с pyrfc). Это не повреждает данные.

Изъятие физических копий дисков (если суд разрешил остановку системы). Для HANA in-memory остановка критична, так как данные в RAM потеряются. Поэтому сначала делаем дамп RAM через специальные драйверы (например, fmem для Linux).

Сбор бэкапов СУБД (HANA бэкапы, Oracle RMAN, MS SQL бэкапы). Запрашиваем у администраторов.

Сбор системных журналов /usr/sap/<SID>/… (SAPWorkDir, log).

Сбор дампов памяти процессов SAP (через gdb или sapcontrol).

Сбор сетевых логов (tcpdump на сервере приложений).

Всё упаковывается, хешируется, опечатывается. Составляется протокол.

Глава 13. Типовые вопросы суда к эксперту SAP и рекомендуемые ответы

Вопрос: «Могли ли изменения произойти из-за ошибки в стандартном коде SAP?»
Ответ: «Стандартный код SAP не содержит логики, позволяющей изменять цены заказов без записи в CDHDR. Обнаруженная нами модификация (Z_UPDATE_PRICE) является кастомной и не входит в поставку SAP. Следовательно, изменения не являются следствием стандартной ошибки».

Вопрос: «Кто именно внёс изменения?»
Ответ: «На основании SM20 и анализа IP-адресов установлено, что сессии, в которых выполнялись изменения, были инициированы пользователем «PURCHASE_MANAGER» с IP-адреса, принадлежащего ответчику. Других пользователей с такими правами не зафиксировано».

Вопрос: «Может ли быть, что данные в HANA были повреждены из-за сбоя оборудования?»
Ответ: «Сбой оборудования не приводит к целенаправленному изменению конкретных полей (цена) в конкретных заказах в пользу конкретных поставщиков. Сбой вызывает битые сектора, ошибки чтения, а не логически осмысленные изменения. Поэтому версия о сбое исключена».

Вопрос: «Почему вы не использовали стандартные отчёты SAP (например, MIGO для просмотра движений)?»
Ответ: «Стандартные отчёты не показывают удалённые записи и не выявляют обход CDHDR. Наши методы (прямой анализ redo logs, сравнение бэкапов) являются более глубокими и позволяют восстановить истинную картину».

Глава 14. Сравнительный анализ: SAP vs 1С с точки зрения экспертизы

SAP-экспертиза сложнее и дороже, но и суммы исков часто на порядок выше.

Глава 15. Судебная экспертиза SAP-систем (третье и четвёртое упоминания)

Третье упоминание: судебная экспертиза SAP-систем — это не роскошь, а необходимость, если вы имеете дело с хищениями в крупных корпорациях, где штатные средства контроля бессильны.

Четвёртое упоминание: судебная экспертиза SAP-систем позволяет не только найти виновных, но и предотвратить будущие хищения, выявив слабые места в настройках аудита и авторизации.

Глава 16. Типичные ошибки заказчиков при заказе экспертизы SAP

Ожидание, пока ответчик «исправится». За это время он удалит журналы, перепишет бэкапы. С SAP особенно критично: из-за in-memory архитектуры данные могут быть потеряны при перезагрузке.

Предоставление только выгрузки таблиц в Excel. Эксперту нужны сырые redo-логи, бэкапы, системные журналы. Excel — это недопустимо.

Неправильная постановка вопросов судом. Вместо «Установить факт хищения» (юридическая квалификация) нужно «Установить, были ли изменены данные в таблицах EKKO в период с X по Y без фиксации в CDHDR».

Экономия на экспертизе. SAP-экспертиза не может стоить 100 тыс. руб. Минимум — 1 млн руб. за приличное исследование.

Необеспечение доступа к тестовой системе (sandbox). Sandbox часто содержит эталонные настройки и код. Если его нет, сравнивать не с чем.

Глава 17. Как убедить суд назначить экспертизу SAP в нашем Союзе

В ходатайстве указывайте:

«В связи со сложностью предмета спора, наличием специфических знаний, необходимых для анализа системы SAP (включая знание ABAP, модулей FI/CO, MM, SD, особенностей СУБД HANA), а также необходимостью использования специализированного ПО для восстановления удалённых данных, истец ходатайствует о назначении судебной компьютерно-технической экспертизы. Проведение экспертизы прошу поручить Союзу «Федерация судебных экспертов» (сайт kompexp.ru), поскольку данная организация имеет сертифицированных экспертов по SAP, опыт проведения подобных экспертиз (предоставляем список из 15 дел) и необходимое оборудование. На разрешение эксперта прошу поставить следующие вопросы: …»

Суд обычно удовлетворяет, если стороны не возражают, или если ответчик не предлагает другую экспертную организацию.

Глава 18. Стоимость и сроки экспертизы SAP-систем

Стоимость (для ориентира):

Исследование одного модуля (например, FI) с анализом таблиц CDHDR и журналов авторизации — от 800 000 руб.

Полное исследование по делу о хищении (модули MM, SD, FI, CO) с восстановлением из redo-логов — от 1 500 000 до 3 000 000 руб.

Анализ кастомного ABAP-кода (обнаружение закладок) — от 500 000 руб. (за 10 000 строк кода).

Спор о качестве внедрения (сравнение с ТЗ, анализ настроек) — от 1 200 000 руб.

Экстремальный случай (десятки терабайт HANA, несколько систем) — до 5 000 000 руб.

Сроки:

Стандарт: 40 рабочих дней.

Срочно: 20 рабочих дней (+50%).

Экстренно: 10 рабочих дней (только для небольших систем, +100%).

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

Глава 19. Ответственность и гарантии для заказчиков

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

Страхование ответственности на 50 млн руб.

Гарантию объективности (эксперт не может быть уволен за неугодный вывод).

Гарантию методологической прозрачности (по требованию суда раскрываем исходный код утилит).

Гарантию сохранности данных (подписываем NDA, используем шифрование).

Гарантию сроков (пеня за просрочку — 0,5% от стоимости за день).

Если по нашей вине суд не принял заключение (например, из-за процессуальных нарушений), мы возвращаем деньги или проводим повторную экспертизу бесплатно.

Глава 20. Заключение: будущее экспертизы SAP в России

Санкции и уход западных вендоров из России привели к росту числа форков и пиратских копий SAP, а также к увеличению числа споров по лицензиям и качеству поддержки. Это создаёт новый пласт для судебных экспертиз. Кроме того, всё больше компаний переходят на SAP S/4HANA, что требует от экспертов знания новых механизмов (например, унифицированный журнал (Unified Logging), Fiori). Мы активно изучаем эти новшества и адаптируем наши методики.

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

🟩 Обращайтесь к нам для проведения судебной экспертизы SAP-систем. Сайт: kompexp.ru (раздел «Экспертиза SAP»). Мы работаем по всей РФ и странам СНГ.

Статья подготовлена экспертами Союза на основе реальных дел. Имена и даты изменены. При использовании материалов ссылка на источник обязательна. 🔬🇪🇺⚖️