Вступление: Почему традиционный аудит бессилен перед фальсификацией данных

Корпоративные войны, арбитражные споры, уголовные дела о хищениях — в центре каждого современного конфликта всегда оказываются базы данных. ERP-системы, бухгалтерские учёты, CRM, журналы событий — всё это хранилища цифровой истины, которая, однако, легко поддаётся искажению. Обычный ИТ-аудит видит только верхушку айсберга: логи приложений, которые можно подделать, и временные метки, которые можно сдвинуть. Инженерная компьютерная экспертиза баз данных и СУБД — это уровень ниже: работа с физической структурой страниц, байтовым анализом WAL-логов, изучением бинарных протоколов и недокументированных служебных записей. Союз «Федерация судебных экспертов» выполняет такие исследования на стыке компьютерной криминалистики, теории реляционных систем и низкоуровневого программирования.

Глава 1. Терминологический базис: что скрывается за формулировкой

В судебной практике под компьютерной экспертизой баз данных и СУБД понимают комплекс процессуальных действий, направленных на получение доказательств из структурированных массивов данных, а также из системного окружения, которое эти данные порождает. Объекты исследования:

• 🔹 Файлы данных (.mdf,.ndf,.ibd,.ora,.frm)
• 🔹 Журналы транзакций (.ldf, redo logs, WAL-сегменты, binlog)
• 🔹 Системные таблицы и словари данных
• 🔹 Дампы оперативной памяти СУБД
• 🔹 Резервные копии и их метаданные
• 🔹 Сетевые трассы между приложением и сервером БД

Инженерный подход означает, что мы не доверяем ни одному API-запросу СУБД — только прямое чтение байтов с физического носителя, полученного в ходе выемки или добровольной выдачи. Именно так достигается независимость от программных слоёв, которые могли быть скомпрометированы.

Глава 2. Физический уровень: как база данных хранит ложь

Любая промышленная СУБД (MS SQL, Oracle, PostgreSQL, MySQL, Firebird) хранит данные в страницах фиксированного размера — обычно 4, 8 или 16 Кбайт. Каждая страница имеет заголовок, содержащий:

• Тип страницы (данные, индекс, битовая карта, фрагмент лога)
• Sequence number и LSN (Log Sequence Number)
• Флаги модификации
• Ссылки на предыдущую и следующую страницу в экстенте

При обычном удалении строки (DELETE) СУБД не стирает данные физически — она лишь выставляет бит «удалено» в заголовке слота строки и модифицирует карту свободного пространства. Сами байты остаются на месте до момента, когда автовакуум или фоновый процесс очистки не перезапишет страницу. Это окно — от нескольких часов до недель — даёт эксперту возможность восстановить полную историю изменений.

Компьютерная экспертиза баз данных и СУБД в нашем исполнении извлекает такие «тени» строк даже после выполнения VACUUM FULL или REORGANIZE, если удаётся прочитать ещё не перезаписанные сектора диска.

Глава 3. Временные парадоксы: борьба с подделкой timestamp

Одна из частей экспертного исследования — анализ временных меток. В СУБД существует несколько типов времени:

⏱️ Системное время сервера — берётся из clock_gettime() на Linux или GetSystemTimeAsFileTime() на Windows. Его можно изменить через API, но в ядре остаются следы.

⏱️ Порядковый номер транзакции — например, XID в PostgreSQL или LSN в MS SQL. Это монотонно возрастающие счётчики, которые нельзя откатить без форматирования всей БД.

⏱️ Время фиксации (commit timestamp) — хранится в специальных системных таблицах или журналах.

Наша методика предполагает кросс-валидацию: строятся графики приращения LSN относительно реального времени из системных логов ОС. Если в какой-то интервал LSN растёт быстрее или медленнее физического таймера — это признак либо внешней нагрузки, либо подмены системного времени. В ряде кейсов мы обнаруживали «петли времени», когда после выполнения UPDATE запись получала timestamp на несколько дней раньше, чем реально — явный признак фальсификации через вызовы низкоуровневых драйверов.

Глава 4. Инструментарий инженера: от HEX-редактора до собственных скриптов

Мы не используем «волшебные коробки» без документации. Наш стек (каждый инструмент описан в заключении):

🛠️ WinHex / HxD — для побайтового просмотра raw-образов.
🛠️ Собственные парсеры LDF и WAL — написаны на C++/Python, исходный код депонирован в нотариальном порядке.
🛠️ pg_filedump / ora_parsers — модифицированные версии с расширенным выводом.
🛠️ Виртуальные среды с точной репликацией — на KVM с сохранением хешей RAM до старта экспертизы.
🛠️ Системы управления цепочками поставок улик (Chain of Custody) — блокчейн-хеширование каждого образа.

Каждое действие фиксируется в журнале с временем, подписью эксперта и контрольной суммой. Принцип «измерительный прибор не должен влиять на измерение» соблюдается безусловно.

Глава 5. Кейс №1: Дело о трёх миллионах пропавших заказов (Microsoft SQL Server)

🟦 Фабула: Крупный маркетплейс обнаружил расхождение в 3,2 млн заказов за квартал. Бухгалтерия предоставила выгрузки из 1С, где заказы якобы были удалены случайно. Ответчик — бывший технический директор — утверждал, что это сбой репликации.

⚙️ Действия экспертов:

• Получен образ диска сервера БД (RAID 10) с остановленной SQL-службой.
• Выполнен низкоуровневый анализ LDF-файлов с помощью разработанного парсера mslsn_reader.
• Обнаружено 47 000 операций DELETEс условием WHERE order_date BETWEEN ‘2022-03-01’ AND ‘2022-03-31’, выполненных не через приложение, а через прямое подключение по OLEDB с IP-адреса, принадлежащего рабочей станции ответчика.
• При этом в системных таблицах tran_end_logбыли обнаружены фальшивые записи о выполнении операций через хранимую процедуру sp_delete_old_orders — явная попытка мимикрии под регламентную чистку.

🔍 Результат: Восстановлена хронология каждого удаления с точностью до миллисекунды и имени учётной записи Windows. Доказано, что «случайное удаление» было целенаправленной акцией. Суд назначил компенсацию в размере 127 млн рублей, уголовное дело передано в следственный комитет.

Глава 6. Кейс №2: Восстановление уничтоженной базы членов ЖСК (PostgreSQL)

🏚️ Ситуация: В ЖСК произошёл конфликт председателя с правлением. База данных членов кооператива (взносы, лицевые счета, протоколы собраний) была удалена — выполнено DROP SCHEMA public CASCADE, а затем VACUUM FULL. Резервных копий не было.

🛠️ Наши действия:

• Изъят SSD-диск сервера через 36 часов после инцидента.
• Выполнен посекторный образ в формате E01 (сжатие без потерь, хеш SHA256).
• Анализ WAL-сегментов (pg_wal) показал, что физическое удаление данных ещё не завершилось — dead tuples в таблице pg_class остались.
• Ручной парсинг бинарных страниц (размер 8 КБ) позволил вычленить структуру таблиц: из заголовков страниц извлечены названия столбцов, а из фрагментов кортежей — числовые значения членских взносов.
• Дополнительно проанализированы системные каталоги pg_attributeи pg_type — сохранены даже после DROP.

📌 Итог: Восстановлено 78% записей — более 2400 лицевых счетов. Идентифицированы точное время удаления (03:17:52) и команда, запущенная из psql от пользователя postgres. Председатель признан виновным в неправомерном доступе и уничтожении данных. Экспертиза признана судом достаточным доказательством. Компьютерная экспертиза баз данных и СУБД позволила вернуть кооперативу финансовую отчётность.

Глава 7. Кейс №3: Вброс проголосовавших в онлайн-системе выборов (MySQL / InnoDB)

🗳️ Контекст: Профессиональное объединение юристов проводило электронное голосование по внесению поправок в устав. В последние 20 минут голосования количество голосов «ЗА» выросло на 1200 при общей активности 4000 членов. Противники поправок заявили о накрутке.

🔬 Инженерное исследование:

• Получен дамп базы MySQL (файлы.ibd и.frm) с сервера, изолированного от сети.
• Включён анализ бинарных логов (binlog_format=ROW) — они не были отключены.
• Выявлена аномалия: автоинкрементный первичный ключ vote_idимел пропуски. В нормальной вставке через веб-интерфейс номера идут подряд с шагом 1, а в спорных записях обнаружились блоки по 50–100 ID, вставленных одной транзакцией.
• Прямой парсинг файла ibdпоказал, что временные метки vote_time для этих записей имеют значение CURRENT_TIMESTAMP, записанное в момент фиксации, но сами данные в страницах расположены с нарушением порядка сортировки по кластерному индексу.
• В буфере изменений (change buffer) обнаружены следы LOAD DATA INFILEиз CSV-файла, который отсутствовал в штатных директориях сервера.

📊 Выводы: Доказан вброс 1187 голосов из внешнего источника. При этом установлено, что файл с голосами был подготовлен на компьютере, который имел доступ к членской базе, но не был авторизованным клиентом системы. Судебная коллегия отменила результаты голосования. Повторное голосование привело к отклонению поправок.

Глава 8. Особенности работы с зашифрованными базами данных

Шифрование данных (TDE в MS SQL, Oracle Transparent Data Encryption, LUKS на уровне тома) — серьёзный барьер. Если ключи шифрования не предоставлены или уничтожены, прямое чтение страниц даёт лишь хаотичный поток байтов. Однако и здесь есть методы:

• Поиск ключей в дампах оперативной памяти сервера (с помощью volatility или fmem).
• Анализ мастер-ключей в аппаратных модулях HSM — если мы получили доступ по доверенности суда.
• Исследование зашифрованного бэкапа вместе с системными базами, где часто хранятся сертификаты.

В одном из дел нам удалось расшифровать базу Sybase ASE, потому что ключ TDE был сохранён в файле конфигурации с правами чтения для службы. Этот файл не был удалён при инциденте. Компьютерная экспертиза баз данных и СУБД в таких случаях становится оперативно-разыскным мероприятием, требующим тесного взаимодействия со следователями.

Глава 9. Восстановление удалённых таблиц и целых схем

Когда таблица удалена через DROP TABLE, СУБД помечает её страницы как свободные, но сами данные могут сохраняться долгое время. Порядок восстановления:

1. Поиск системных записей в таблицах-словарях (например, objectsв MS SQL — если они ещё не перезаписаны).
2. Сканирование нераспределённых экстентов (IAM-страницы) на предмет заголовков, похожих на строки пользовательских данных.
3. Восстановление структуры столбцов по остаточным статистикам (гистограммам, которые хранятся в служебных таблицах даже после удаления).

Реальный кейс: в Oracle Database после DROP USER… CASCADE удалили схему с 48 таблицами. Через 2 недели после инцидента мы извлекли все таблицы, кроме трёх, перезаписанных в ходе нормальной работы. Для извлечения использовался Oracle LogMiner в режиме анализа архивных redo-логов, а также прямое чтение сегментов отмены (undo segments).

Глава 10. Противодействие экспертизе: известные уловки и как их раскрыть

Технически подкованные нарушители используют приёмы, затрудняющие анализ:

🕳️ Отключение журналирования — ALTER DATABASE SET RECOVERY SIMPLE или выключение binlog. Решение: анализ ОС-логов доступа к файлам базы, даже если сама СУБД не пишет логи.

🕳️ Использование «спящих» триггеров — триггеры, которые чистят следы при выполнении определённых условий. Решение: статический анализ тела триггеров из системных таблиц и сравнение с реальным поведением.

🕳️ Прямое редактирование файлов через HEX — изменение байтов без участия СУБД. Это самая сложная форма атаки. Раскрывается через несоответствие контрольных сумм страниц (Checksum), а также через сравнение времен модификации файлов с LSN-последовательностями.

🕳️ Модификация ядра ОС для подмены системных вызовов — Rootkit-уровень. Здесь требуется экспертиза на уровне гипервизора и анализ дампов ядра LiveKD.

В нашей практике был случай, когда администратор правил байты страницы напрямую в шестнадцатеричном редакторе, меняя сумму заказа. Его выдала CRC-ошибка контрольной суммы, которая не была пересчитана. СУБД не жаловалась (он отключил проверку страниц), но наш анализатор выявил аномалию.

Глава 11. Взаимодействие с правоохранительными органами и судом

Независимая экспертиза — это не только технический отчёт, но и процессуальный документ. Мы всегда:

• Готовим заключение по ст. 80 УПК РФ, ст. 86 ГПК РФ.
• При необходимости участвуем в допросах (очных ставках) с разъяснением выводов.
• Предоставляем демонстрационные стенды — виртуальные машины, на которых судья может увидеть процесс восстановления данных.
• Обеспечиваем трансляцию экрана при исследовании в судебном заседании (с разрешения суда).

Каждое заключение имеет раздел «Пределы и условия применимости», где честно указывается, что именно эксперт не смог восстановить и почему. Это повышает доверие к нам со стороны судей и оппонентов.

Глава 12. Специфика NoSQL и гибридных хранилищ

Хотя классические SQL-базы — основной объект, растёт число обращений по MongoDB, Cassandra, Redis. Инженерные особенности:

• MongoDB (WiredTiger)— данные хранятся в коллекциях как BSON-документы. Удаление документов просто выставляет флаг, физическое удаление при компакшне. Журнал предзаписи (WAL) в MongoDB работает иначе — он цикличен. Наш метод: поиск фрагментов BSON в свободных областях файлов.wt.
• Cassandra— распределённая система без единого журнала. Экспертиза требует анализа хинтов (hinted handoff), commitlog на каждом узле, а также дампов memtable. Сложность высока, но возможна.
• Redis— in-memory. Единственный шанс — дамп RDB или AOF-файл. Если их нет, а процесс перезапущен — данные теряются безвозвратно.

Несмотря на различия, компьютерная экспертиза баз данных и СУБД расширяется на эти системы, но с обязательной оговоркой о сниженной достоверности и необходимости применять вероятностные модели.

Глава 13. Экономика экспертизы: почему качество не бывает дешёвым

Средняя стоимость инженерно-судебной экспертизы (на 99 000 знаков — это ~15 страниц мелким шрифтом, но на самом деле детальное заключение может занимать 100+ страниц с приложениями) составляет от 300 000 до 1 500 000 рублей в зависимости от объёма данных и сложности восстановления.

В эту стоимость входит:

• Выделенный сервер для криминалистической копии.
• 2–3 эксперта (технолог, аналитик, процессуалист).
• Нотариальное заверение цепочки хранения улик.
• Партнёрство с лабораториями для разбора повреждённых носителей.

Попытки сэкономить (провести экспертизу «за 30 тыс. руб.») приводят к поверхностному анализу на уровне прикладного ПО, который опровергается в суде. Мы не торгуем качеством.

Глава 14. Пошаговый алгоритм действий для заказчика

Если вы столкнулись с необходимостью судебной или досудебной компьютерной экспертизы:

1️⃣ Не включайте сервер! Даже простая загрузка ОС может изменить временные метки и перезаписать свободные страницы.
2️⃣ Зафиксируйте признаки — скриншоты ошибок, сообщения СУБД, логи из консоли.
3️⃣ Обратитесь для предварительного анализа — мы на безвозмездной основе оценим шансы на успех (до 1 часа консультации).
4️⃣ Заключите договор — в нём прописываются конкретные вопросы суда или адвоката.
5️⃣ Обеспечьте изъятие — либо через судебного пристава, либо в добровольном порядке с видеозаписью.
6️⃣ Получите заключение — в среднем через 15–30 рабочих дней.

Важно: чем больше времени проходит с момента инцидента, тем меньше данных можно восстановить. Идеальный срок — первые 48 часов.

Глава 15. Заключение и призыв к действию

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

Мы не даём гарантий на 100% (это противоречило бы научной честности), но в 97% дел наши выводы ложатся в основу судебных решений. Оставшиеся 3% — случаи, где данные были необратимо уничтожены аппаратно или прошло слишком много времени.

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

🔗 https://kriminalist77.ru/ekspertiza-baz-dannyh/

Там же вы найдёте форму для быстрой связи и прайс-лист на типовые исследования. Мы работаем по всей Российской Федерации и за рубежом (по доверенности через консульства). Доверьте цифры профессионалам — восстановим истину вместе.