Научное введение: КИС как сложная кибернетическая система и объект судебного исследования

Корпоративная информационная система (КИС) современного предприятия представляет собой распределённую кибернетическую систему, интегрирующую множественные подсистемы: ERP (1С, SAP, Oracle EBS), CRM (Salesforce, Microsoft Dynamics), BI (Power BI, Tableau), системы управления документами, интеграционные шины и специализированные отраслевые решения. В условиях цифровой экономики хозяйственные споры всё чаще опираются на данные, хранящиеся в таких системах. Парадоксальным образом, именно сложность КИС создаёт как возможности для злоумышленного сокрытия следов хозяйственных операций, так и возможности для их выявления с использованием методов компьютерной экспертизы. 🧠📊

В настоящей статье, написанной в научном стиле, мы, эксперты Союза «Федерация судебных экспертов», представляем методологию компьютерной экспертизы корпоративных информационных систем (кис). Рассматриваются теоретические основы исследования КИС, классификация следовой информации, эмпирические методы восстановления удалённых и изменённых данных в 1С и SAP, а также процессуальные аспекты использования заключения эксперта в арбитражном процессе. Три реальных кейса иллюстрируют практическую реализацию разработанной методологии. 🔬⚖️

Глава 1. Теоретическая модель КИС как источника цифровых доказательств

С точки зрения теории цифровой криминалистики, любая КИС представляет собой многоуровневую систему, каждый уровень которой оставляет специфические следы. Предложена следующая иерархическая модель. 🏗️

Уровень L0 (физический): носители информации (HDD, SSD, NVMe, RAID-массивы), оперативная память (RAM) серверов КИС. Следы: остаточная намагниченность, данные в буферном кэше.

Уровень L1 (логический): файловые системы (NTFS, ext4, XFS). Следы: MFT, inode, журналы USN, теневые копии (VSS), расширенные атрибуты.

Уровень L2 (СУБД): файлы баз данных (.1CD,.mdf,.ldf), транзакционные логи (redo log, WAL), дампы памяти процессов СУБД.

Уровень L3 (прикладной): таблицы учётных данных (BSEG, BKPF, MSEG в SAP; документы в 1С), таблицы изменений (CDHDR, CDPOS), прикладные журналы.

Уровень L4 (интеграционный): логи EDI-шлюзов, API-логи, логи RFC-вызовов, сообщения очередей.

Уровень L5 (сетевой): трафик между компонентами КИС, логи межсетевых экранов.

Научная гипотеза: любые действия по модификации или удалению учётной информации в КИС оставляют следы на нескольких уровнях. Степень сохранности следов обратно пропорциональна времени, прошедшему с момента модификации, и числу циклов перезаписи.

Компьютерная экспертиза корпоративных информационных систем (кис) базируется на этой гипотезе и использует методы многоуровневой триангуляции следов.

Глава 2. Классификация следовой информации в КИС

На основе анализа более 500 экспертиз КИС, проведённых Союзом «Федерация судебных экспертов» в 2020-2025 гг., предложена следующая классификация цифровых следов. 📊

Категория 1. Следы удаления документов в 1С

Файловый режим: свободные страницы.1CD (бит в карте распределения = 0, но данные сохранены)

Клиент-серверный режим: записи DELETE в транзакционном логе SQL (.ldf)

Журнал регистрации: записи о помечивании на удаление (даже после очистки — восстановление из деаллоцированных секторов)

Теневые копии (VSS): более ранние версии файла.1CD

Категория 2. Следы изменения данных в SAP

Таблицы изменений: CDHDR (заголовки) и CDPOS (позиции) — USERNAME, UDATE, UTIME, VALUE_OLD, VALUE_NEW

Транзакционные логи СУБД: redo log HANA,.ldf SQL Server — фиксируют каждую операцию независимо от способа доступа

Дампы памяти: старые версии строк в буферном кэше

Категория 3. Следы SQL-вмешательства (прямой доступ к БД)

Отсутствие записей в CDHDR при наличии изменений в таблицах

user_name = SYSTEM (администратор БД) в redo log

client_host (IP-адрес) в логах СУБД

Категория 4. Следы отката базы данных

Расхождение атрибутов MFT: STANDARDINFORMATIONvsSTANDARDI​NFORMATIONvsFILE_NAME

GUID базы данных (совпадает у текущей и бэкапной копии)

Журналы восстановления SQL Server (msdb.dbo.restorehistory)

Категория 5. Следы интеграционных сбоев

Логи EDI-шлюза: статусы отправки, доставки, обработки

Логи RFC-вызовов в SAP

Логи API (для облачных интеграций)

Понимание этой классификации позволяет эксперту выбрать оптимальный маршрут исследования.

Глава 3. Кейс №1: Эмпирическое восстановление удалённых документов из свободных страниц.1CD

🔬 Научная проблема: Определить возможность восстановления удалённых документов из файла.1CD в 1С после выполнения операции сжатия базы («Тестирование и исправление» со сжатием) и оценить полноту восстановления как функцию числа циклов сжатия.

Эмпирические условия (АО «ТрейдМеталл» vs ООО «СтройРесурс», иск 87 млн руб.):

Файл.1CD размером 48 ГБ

Размер страницы: 4096 байт

Число циклов сжатия по данным MFT: 3

Общее количество страниц: 12 582 912

Количество свободных страниц: 4 321 789 (34,4%)

Методология эксперимента 🔬

Этап 1. Анализ MFT файла.1CD
Атрибуты STANDARDINFORMATION(SI)иSTANDARDI​NFORMATION(SI)иFILE_NAME (FN). SI: Modified = 15.03.2025 14: 23: 17; FN: Modified = 20.02.2025 09: 12: 14. Расхождение в 23 дня подтверждает факт модификации файла после последней записи.

Этап 2. Картографирование свободных страниц
Карта распределения страниц (первые 4 КБ файла) содержит битовую маску: 1 — страница используется, 0 — свободна. Выявлено 4 321 789 свободных страниц.

Этап 3. Сканирование сигнатур таблицы Document_Invoice
Определена сигнатура таблицы как последовательность байтов [0x4D, 0x4C, 0x4F, 0x47, 0x01] в заголовке страницы. Выполнено линейное сканирование всех свободных страниц.

Результаты сканирования:

Найдено 3 456 страниц с валидной сигнатурой

Из них 3 234 страницы содержат полные записи (93,6%)

Восстановлено 1 234 документа на сумму 87 000 000 руб.

Этап 4. Зависимость от числа циклов сжатия
Эмпирическая функция: R(k) = R₀ × exp(-k / τ), где τ ≈ 1,8. При k=3, R≈78% от теоретического максимума. В эксперименте восстановлено 93,6% — выше теоретического из-за неравномерной перезаписи.

Научный вывод: восстановление данных из свободных страниц.1CD возможно после 3 циклов сжатия с полнотой >90% при условии, что свободные страницы не были полностью перезаписаны новыми данными.

Компьютерная экспертиза корпоративных информационных систем (кис) подтвердила применимость метода.

Глава 4. Кейс №2: Выявление SQL-вмешательства в SAP через анализ redo log HANA

🔬 Научная проблема: Разработать метод обнаружения массового изменения сумм проводок в таблице BSEG SAP HANA, выполненного через прямой SQL-доступ, при отсутствии записей в CDHDR/CDPOS.

Эмпирические условия (АО «НефтеХим» vs бывший ИТ-директор, иск 112 млн руб.):

СУБД: SAP HANA 2.0

Режим archive log: включён (сохранены за 6 месяцев)

Изменено: 50 000 записей BSEG (суммы занижены на 15-20%)

Время между изменением и экспертизой: 45 дней

Методология 🧪

Этап 1. Гипотеза
При включённом archive log, redo log сохраняет все операции изменения данных, независимо от способа доступа (штатный SAP или прямой SQL).

Этап 2. Извлечение redo log
С помощью утилиты hdbrecovery извлечены все операции UPDATE, DELETE, INSERT за период с 01.01.2025 по 31.03.2025. Объём обработанных логов — 1,2 ТБ.

Этап 3. Фильтрация по таблице BSEG
Извлечено 50 000 операций UPDATE. Каждая операция содержит:

transaction_id

user_name = SYSTEM (администратор БД)

client_host = 10.0.0.88

timestamp (UTC)

OldValue (исходная сумма)

NewValue (изменённая сумма)

Этап 4. Верификация через дамп памяти
Дамп памяти процесса hdbindexserver (96 ГБ) содержал старые версии строк. Извлечены 50 000 записей. Коэффициент корреляции Пирсона r = 0,999 (p < 0,001).

Этап 5. Идентификация пользователя
Сопоставление client_host = 10.0.0.88 с логами доступа: IP принадлежит рабочей станции ИТ-директора. На его компьютере в истории PowerShell найден скрипт update_bseg.sql.

Научный вывод: при включённом archive log, redo log HANA является надёжным источником для восстановления истории изменений, даже в обход прикладного аудита SAP.

Компьютерная экспертиза корпоративных информационных систем (кис) успешно реализовала эту методологию.

Глава 5. Кейс №3: Анализ интеграционных потерь в связке 1С-SAP

🔬 Научная проблема: Установить причину потери данных при передаче из 1С в SAP через EDI-шлюз и определить, на чьей стороне (отправитель, шлюз, получатель) произошёл сбой.

Эмпирические условия (ООО «ПромЛогистик» vs интегратор, иск 45 млн руб.):

2 345 счетов-фактур на сумму 45 млн руб.

Маршрут: 1С → XML → EDI-шлюз → SAP

Результат: данные не отобразились в SAP

Методология 🔬

Этап 1. Анализ логов 1С
Журнал регистрации 1С (файлы.lgd/.lgf) восстановлены. Обнаружены 2 345 записей о выгрузке счетов через обработку «Обмен с SAP». Время, пользователь, IP — всё совпадает. Гипотеза: отправитель свою функцию выполнил.

Этап 2. Анализ логов EDI-шлюза
Логи EDI-шлюза (интегратор) показали: XML-файлы отправлены, доставлены на сервер SAP, статус 200 OK. Но записи о дальнейшей обработке отсутствуют.

Этап 3. Анализ логов SAP (через судебный запрос)
В SAP получены логи RFC-вызовов. Обнаружено, что входящие XML-файлы были приняты, но не обработаны. В логах ошибок: USER_ERROR: field amount exceeds threshold 1000000.

Этап 4. Анализ ABAP-кода интеграции
Код содержал условие: IF amount > 1000000 THEN SKIP. Счета истца были на суммы от 1,2 млн до 5 млн руб. — все проигнорированы.

Этап 5. Формулировка вывода
Потеря произошла на стороне SAP из-за ошибки в коде интегратора. Истец и EDI-шлюз свою функцию выполнили.

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

Глава 6. Типовые вопросы суда при экспертизе КИС

На основе анализа судебной практики выделены наиболее частые вопросы. 🗂️

Категория «Удаление/изменение данных»:

Имеются ли в КИС следы удаления или изменения финансовых транзакций за период [период]?

Если да, то кем (учётная запись), когда и с какого IP-адреса были выполнены операции?

Возможно ли восстановить удалённые данные и определить суммы?

Категория «SQL-вмешательство»:
4. Имеются ли в журналах СУБД (redo log,.ldf) следы прямого доступа к таблицам?
5. Каковы старые и новые значения изменённых полей?

Категория «Интеграционные потери»:
6. Были ли данные переданы из системы А в систему Б?
7. На каком этапе произошла потеря?

Категория «Откат базы данных»:
8. Имеются ли признаки восстановления базы данных из резервной копии?

Компьютерная экспертиза корпоративных информационных систем (кис) даёт ответы на все эти вопросы.

Глава 7. Методология сбора доказательств в КИС

Для файловых 1С:

Образ диска сервера (Tableau T8)

Файлы.1CD,.lgd,.lgf

Теневые копии (VSS)

MFT анализ атрибутов STANDARDINFORMATIONиSTANDARDI​NFORMATIONиFILE_NAME

Для клиент-серверных 1С/SAP:

Образ диска сервера

Дамп памяти СУБД

Транзакционные логи (redo log,.ldf)

Резервные копии

Алгоритм сбора:

Судебный запрос к стороне

При отказе — запрос к вендору (ст. 66 АПК РФ)

Выезд эксперта, фото/видеофиксация

Расчёт хэш-сумм SHA-256

Глава 8. Судебный запрос к вендору КИС

Процедура:

Ходатайство об истребовании доказательств (ст. 66 АПК РФ)

Суд выносит определение

Вендор предоставляет данные (30-90 дней)

Сложности: отказ вендора → суд делает выводы против оппонента (ст. 65 АПК РФ)

Глава 9. Ограничения методов (научная честность)

Когда восстановление невозможно:

Более 4-5 циклов сжатия 1С

Перезапись redo log (SAP HANA без archive log — 48-72 часа)

Отсутствие бэкапов у вендора (30-90 дней)

Процент восстановления:

Глава 10. Инструментарий эксперта КИС

Программное обеспечение:

EnCase Forensic, X-Ways Forensics

ApexSQL Log, hdbrecovery

1CD_Raw_Extractor (собственная разработка)

Python, PowerShell

Аппаратные средства:

Tableau T8, PC-3000

WriteBlocker

Глава 11. Часто задаваемые научные вопросы

Вопрос: Можно ли восстановить данные в 1С после 5 циклов сжатия?
✅ Ответ: Теоретически — менее 10%. Практически — только если есть теневые копии или бэкапы.

Вопрос: Как долго SAP HANA хранит redo log?
✅ Ответ: При включённом archive log — неограниченно. Без archive log — 48-72 часа.

Вопрос: Может ли эксперт определить использование чужой учётной записи?
✅ Ответ: Да, по IP-адресу, времени доступа, СКУД, а также по типу выполняемых операций.

Глава 12. Экономическая эффективность экспертизы КИС

Формула: EV = S × q — C — (1-q) × F

Эмпирические значения (n=500):

q (с нашей экспертизой) = 0,97

q (без экспертизы) = 0,30

C (средняя) = 500 000 руб.

Пример (иск 50 млн руб.):
EV(с экспертизой) = 50×0,97 — 0,5 — 0,03×0,3 = 48,5 — 0,5 — 0,009 = 47,991 млн руб.
EV(без экспертизы) = 50×0,30 — 0 — 0,70×0,3 = 15 — 0,21 = 14,79 млн руб.
Выигрыш: 33,2 млн руб.

Глава 13. Сравнительный анализ КИС

Глава 14. Стандартизация методик

Разработан стандарт «СЭ-КИС-2025» (проект):

Раздел 1. Требования к изъятию данных

Раздел 2. Методика анализа 1С (файловый и клиент-серверный)

Раздел 3. Методика анализа SAP HANA

Раздел 4. Методика анализа интеграционных потерь

Раздел 5. Требования к оформлению заключения

Глава 15. Алгоритм действий при подготовке к экспертизе

Шаг 1. Сохранение данных — не удалять, не сжимать базы, не перезагружать сервер.
Шаг 2. Консультация с экспертом (бесплатно)
Шаг 3. Досудебное исследование (опционально)
Шаг 4. Подача ходатайства в суд
Шаг 5. Судебный запрос к вендору (при необходимости)
Шаг 6. Проведение экспертизы
Шаг 7. Использование заключения в суде

Глава 16. Новые вызовы

Искусственный интеллект в КИС, блокчейн-интеграции, квантовая криптография — новые задачи. Мы инвестируем в R&D.

Глава 17. Этический кодекс эксперта

Принципы: независимость, честность, конфиденциальность, законность.

Глава 18. Заключение: научный подход как гарантия истины

Три кейса показали возможности компьютерной экспертизы корпоративных информационных систем (кис):

✅ Восстановление удалённых документов из свободных страниц.1CD (87 млн руб.).
✅ Выявление SQL-вмешательства через redo log HANA (112 млн руб.).
✅ Анализ интеграционных потерь в связке 1С-SAP (45 млн руб.).

🟩 Мы — Союз «Федерация судебных экспертов». Сайт: https: //kompexp.ru/

Научный подход — ключ к истине в цифровую эпоху. 🔧⚖️