Добро пожаловать в мир, где каждый бит имеет значение, каждая транзакция оставляет неизгладимый след, а удалённые данные продолжают существовать на физическом уровне. 🧬💾 Эта статья — не для поверхностного чтения. Она для технических специалистов, юристов, желающих разобраться в глубинах судебной экспертизы, и для всех, кто сталкивался с необходимостью доказать или опровергнуть факт манипуляции данными в системе управления базами данных. Мы — Союз «Федерация судебных экспертов» — рассмотрим компьютерную экспертизу баз данных и СУБД как строгую научно-техническую дисциплину, опирающуюся на методы низкоуровневого анализа файловых структур, журналирования и криминалистического восстановления информации. Вас ждут три реальных кейса из нашей практики, детальный разбор методологий и ответ на вопрос: почему штатные средства СУБД не всегда могут выявить следы вмешательства. 🔬⚙️

Глава 1. Определения и предметная область: что такое компьютерная экспертиза БД

Компьютерная экспертиза баз данных и СУБД — это вид судебной компьютерно-технической экспертизы, объектами которой являются:

• файлы данных СУБД (на физическом и логическом уровне);
• журналы транзакций (redo/undo, WAL, binlog, LDF);
• дампы памяти сервера БД;
• резервные копии;
• системные каталоги и метаданные;
• логи подключений и аудита.

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

Сферы применения: арбитражные споры (подтверждение факта хищения), уголовные дела (ст. 159, 272, 273 УК РФ), корпоративные расследования, споры между контрагентами о целостности общих баз данных.

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

Любая реляционная СУБД организует хранение данных в виде страниц (блоков) фиксированного размера: 8 КБ (MS SQL, Oracle), 16 КБ (InnoDB), 8 КБ (PostgreSQL). При выполнении операции DELETE строка не удаляется физически немедленно. Вместо этого в заголовке страницы устанавливается флаг «удалено», а сама строка помечается как свободное пространство. 🔖🗑️

Физическое освобождение места происходит либо при перестройке индекса (REBUILD), либо при фоновой очистке (purge thread в InnoDB, autovacuum в PostgreSQL, ghost cleanup в MS SQL). До этого момента удалённые строки доступны для прямого низкоуровневого чтения через дамп страниц. Это фундаментальное свойство, используемое в компьютерной экспертизе баз данных и СУБД.

Для чтения таких строк применяются:

• В MS SQL — команда DBCC PAGE (недокументированная, но легальная для экспертов);
• В PostgreSQL — расширение pageinspect и прямая работа с файлами в каталоге base/;
• В MySQL (InnoDB) — утилита innochecksum и парсер.ibd-файлов.

Пример: при анализе страницы InnoDB мы можем увидеть заголовок DELETE MARK и полное содержимое строки, включая скрытые системные колонки DB_TRX_ID (идентификатор транзакции) и DB_ROLL_PTR (указатель на сегмент отката). 🔍🧾

Глава 3. Журналы транзакций: хроника каждого изменения

Журнал транзакций — это последовательная запись всех модификаций данных. В зависимости от СУБД он может называться:

• Write-Ahead Log (WAL) в PostgreSQL;
• Redo/Undo журнал в Oracle;
• Transaction Log (.ldf) в MS SQL Server;
• Binary Log (binlog) и InnoDB Redo Log в MySQL.

Структура этих журналов задокументирована (частично) и поддаётся прямому анализу. Например, в MS SQL каждая запись журнала содержит:

• LSN (Log Sequence Number) — уникальный монотонно возрастающий номер;
• Transaction ID;
• Operation (LOP_BEGIN_XACT, LOP_MODIFY_ROW, LOP_DELETE_ROWS, LOP_COMMIT_XACT);
• Offset и длина изменённых данных;
• Старое и новое значение (для UPDATE).

Анализ LDF-файла даже после удаления операций возможен, если журнал не был усечён до перезаписи. Эксперт может восстановить полную историю изменений любой строки за определённый период. 🔄📜

КЛЮЧЕВАЯ ФРАЗА №1: Компьютерная экспертиза баз данных и СУБД базируется на неизменности журналов транзакций — пока они не перезаписаны циклически, экспертиза способна восстановить полную хронологию инцидента с точностью до порядка операций внутри одной миллисекунды.

Глава 4. Методы восстановления удалённых данных без использования бэкапов

В ряде случаев резервные копии отсутствуют или скомпрометированы. Эксперт прибегает к методам карактинга (carving) и низкоуровневого анализа:

1. Анализ файлов данных (.mdf,.ndf,.ibd,.dbf). Даже если запись помечена как удалённая и частично перезаписана, можно восстановить фрагменты.
2. Анализ теневых копий (Volume Shadow Copy) в Windows. Позволяет получить состояние файлов БД на момент до удаления.
3. Анализ журналов СУБД, даже если они обрезаны. В начале каждого журнального файла (например, pg_wal) есть заголовок, содержащий информацию о времени создания и последней транзакции.
4. Дамп оперативной памяти работающего сервера. Незакоммиченные транзакции, удалённые процедуры, временные таблицы — всё это может сохраняться в RAM.

Пример: в PostgreSQL, если параметр wal_keep_segments не установлен, WAL-файлы удаляются. Но файловый карактинг позволяет извлечь их фрагменты из нераспределённого пространства диска. Мы использовали этот метод для восстановления WAL-фрагментов с отформатированного жёсткого диска (случай с корпоративным шпионажем). 🔧💽

Глава 5. Кейс №1: Подмена сумм в платёжных поручениях через прямое редактирование.ibd

📁 Ситуация: Бухгалтерская система на MySQL с движком InnoDB. Обнаружено расхождение: в отчётах сумма платежа 100 000 руб., в выписке банка — 1 000 000 руб. Разница — 900 000 ушла на счёт третьего лица. Администратор утверждает: «сбой, логи не пишутся». Мы получаем образ диска.

🔧 Исследование: Проверяем включение binlog — отключён. Redo-log стандартно перезаписан. Остаются сами файлы таблиц (payments.ibd). Используем утилиту innochecksum -v payments.ibd для проверки целостности, затем собственный парсер InnoDB Page.

Находим страницу с записью о платеже ID=4455. В физическом дампе страницы видим:

• Заголовок страницы (FIL Header) с checksum и page number;
• Инфослоты (Infimum/Supremum) указывают на наличие двух версий строки с одним первичным ключом — это возможно только при прямом изменении файла в обход механизма MVCC.

Далее анализируем скрытые поля DB_TRX_ID и DB_ROLL_PTR. У одной и той же строки два разных DB_TRX_ID — признак ручной подмены страницы. Экспертиза устанавливает, что злоумышленник использовал hex-редактор для замены четырёх байт в поле суммы (с 0x186A0 на 0xF4240). Время модификации файла (по метаданным FS) совпадает с ночным дежурством администратора.

Вывод: прямое вмешательство в файл данных в обход СУБД. Администратор уволен и привлечён к ответственности по ч. 2 ст. 272 УК РФ (неправомерный доступ, повлёкший крупный ущерб). ✅⚖️

Глава 6. Технические особенности PostgreSQL: WAL и архивация

PostgreSQL использует Write-Ahead Log (WAL) — все изменения сначала попадают в WAL, и только потом — в основные файлы данных (кучи). WAL-файлы по умолчанию имеют размер 16 МБ и хранятся в каталоге pg_wal. Параметры:

• wal_level — уровень детализации (replica/logical);
• archive_mode — возможность архивации заполненных WAL-файлов;
• wal_keep_segments — количество сохраняемых WAL-сегментов.

При судебной экспертизе критически важно получить архив WAL за интересующий период. Если архивация не настроена, WAL-файлы перезаписываются циклически, и шанс восстановить историю падает. Однако мы используем метод «WAL mining» — извлечение транзакций из ещё существующих WAL-файлов с помощью утилиты pg_waldump. ⛏️📄

Пример вывода pg_waldump:

text

rmgr: Heap       len (rec/tot): 54/ 1130, tx: 7849231, lsn: 0/1C7E8D8, prev 0/1C7E860, desc: DELETE off 57 flags 0x02 KEYS_UPDATED

Эта запись означает операцию DELETE в транзакции 7849231, позицию в WAL (LSN) и смещение. Если у нас есть архив WAL, мы можем восстановить удалённые данные даже при отсутствии бэкапов.

КЛЮЧЕВАЯ ФРАЗА №2: Компьютерная экспертиза баз данных и СУБД на платформе PostgreSQL немыслима без экспертного анализа WAL-файлов — именно они хранят криминалистически значимую информацию при грамотно настроенной архивации.

Глава 7. Кейс №2: Массовая фальсификация оценок в учебном заведении через триггеры

📁 Ситуация: Вуз, БД успеваемости на MS SQL Server. Обнаружено, что группа студентов получила автоматом отличные оценки по сложному предмету, хотя не посещала экзамен. Журнал транзакций показывает обычные UPDATE от имени преподавателя. Но преподаватель клянётся, что не выставлял эти оценки. Внутренний аудит не дал результатов.

🔧 Исследование: Мы получаем образ БД в остановленном состоянии и копию журнала транзакций (.ldf) за два месяца. Анализ с помощью fn_dblog выявляет странность: записи об обновлении таблицы grades имеют формат LOP_MODIFY_ROW, но в поле Old Value указана дата изменения, отличающаяся от системной на 10 дней. Это указывает на то, что UPDATE выполнялся не через стандартный интерфейс, а через хранимую процедуру, которая изменяла системную временную метку.

Далее исследуем системную таблицу sys.sql_modules и находим процедуру sp_auto_grade, которая скомпилирована за 3 дня до инцидента. Код процедуры (восстановлен через sp_helptext, несмотря на попытку шифрования WITH ENCRYPTION — обход через DAC и дамп памяти) содержал:

sql

CREATE PROCEDURE sp_auto_grade @student_id INT, @grade INT

WITH ENCRYPTION

AS

BEGIN

SET NOCOUNT ON

UPDATE grades SET grade = @grade, modified_date = DATEADD(day, -10, GETDATE())

WHERE student_id = @student_id

— и также запись в скрытую таблицу log_private

END

Триггер на таблицу students срабатывал при зачислении нового студента и проверял, если фамилия начинается на определённую букву — запускал sp_auto_grade с высокой оценкой. Это была система взяток: родители платили, администратор базы данных вносил фамилию студента в список, и триггер автоматически «правил» оценки задним числом.

Вывод: Внедрение вредоносного триггера и шифрованной процедуры. Администратор БД уволен, материалы переданы в СК. Защита вуза в суде строилась на нашем заключении как на главном доказательстве. 🧑‍🎓📚

Глава 8. Oracle: восстановление удалённых строк через Flashback и прямые дампы

Oracle Database имеет мощнейший механизм Flashback, который позволяет «отматывать» состояние базы на определённый момент времени. Однако для судебной экспертизы не менее ценен прямой анализ дампов данных из файлов.dbf (табличные пространства). Мы используем:

• Oracle Data Unloader (ODU) — стороннее средство для извлечения данных напрямую из файлов;
• DBMS_LOB для чтения неструктурированных данных;
• анализ AWR-отчётов и журналов Listener.

Особенность Oracle: удалённые строки физически не удаляются до тех пор, пока блок не будет переиспользован. Более того, существует таблица SYS.DBA_OBJECTS, хранящая информацию о времени создания/удаления объектов (включая хранимые процедуры). Даже если процедура удалена через DROP PROCEDURE, её определение может оставаться в словаре данных, пока сегмент не будет очищен. 🔮🗃️

Пример из практики: при анализе табличного пространства SYSTEM мы нашли фрагменты удалённой процедуры, которая запускала экспорт данных каждую ночь на FTP. Процедура была удалена за два дня до аудита, но её код восстановлен из теневых копий UNDO-сегментов.

Глава 9. Кейс №3: Диверсия через удаление системного журнала и подделку LSN

📁 Ситуация: Логистическая компания. Основная база данных Oracle. Раз в месяц происходит списание топлива без реальной заправки. Общая сумма ущерба за полгода — 4,2 млн руб. Системный администратор удалил часть журналов redo и очистил таблицу аудита. Утверждает: «вирус всё стёр».

🔧 Исследование: Нам передан образ жёсткого диска сервера. Первым делом анализируем нераспределённое пространство файловой системы (NTFS). Находим фрагменты удалённых.log файлов redo, в которых сохранились заголовки. Используя структуру формата Oracle redo (VECTOR CHANGE), частично восстанавливаем записи:

• CHANGE #1: UPDATE инвентаризация.tank SET volume = volume — 500
• CHANGE #2: COMMIT с меткой времени

Далее находим в теневой копии (VSS) таблицу SYS.AUD$ за день до инцидента. Сравниваем с текущей таблицей аудита. Видим, что удалены все записи с ACTION# = 100 (UPDATE) за определённый период. Однако в UNDO-сегментах (которые циклически перезаписываются, но не полностью) сохранились старые версии строк из AUD$. Извлекаем их с помощью flashback transaction query.

Самое интересное: злоумышленник подделал LSN (Log Sequence Number) в заголовках файлов данных. В Oracle LSN хранится в заголовке каждого файла данных. Он инкрементально увеличивается. Мы обнаружили, что LSN двух разных файлов данных имеют разрыв в 1200 единиц — то есть между ними было выполнено 1200 операций, не отражённых в одном из файлов. Это доказывает факт подмены файла данных более старой версией с последующей подгонкой LSN вручную. 📏🔨

Итог: Заключение о прямом вмешательстве в файлы данных и подделке системных метаданных. Администратор привлечён к уголовной ответственности по ст. 273 (создание и распространение вредоносных программ — в данном случае скрипт подмены LSN). Компания взыскала ущерб через гражданский иск.

КЛЮЧЕВАЯ ФРАЗА №3: Даже в Oracle с его продвинутыми средствами аудита, компьютерная экспертиза баз данных и СУБД на низкоуровневом физическом анализе способна раскрыть манипуляции, скрытые через удаление журналов и подделку заголовков.

Глава 10. Методики дифференциации технического сбоя и умышленных действий

Одна из важнейших задач эксперта — отличить случайное повреждение данных от целенаправленной атаки. Критерии:

Для дифференциации применяется анализ корреляции: сопоставление времени изменений в БД с событиями в системном журнале (Event Log), логах доступа к серверу, графиками нагрузки ЦП и сети. Если в 03:15 ночи была операция UPDATE, а в 03:16 ночи был запущен Far Manager от имени администратора — это сильный индикатор умысла. 🖥️⏲️

Глава 11. Инструментальная база судебного эксперта по БД

Мы используем комбинацию штатных средств СУБД (для первичного осмотра) и специализированного ПО:

Криминалистические платформы:

• Belkasoft X — извлечение артефактов SQLite из мобильных устройств;
• Oxygen Forensic Detective — работа с БД мессенджеров;
• X-Ways Forensics — низкоуровневый анализ образов дисков, карактинг журналов.

Специализированные утилиты по СУБД:

• MS SQL: DBCC PAGE, fn_dblog, fn_dump_dblog, ApexSQL Log (для чтения LDF);
• PostgreSQL: pg_waldump, pageinspect, pg_resetwal (с осторожностью, только на копии);
• Oracle: ODU, PRM-DUL, oracle-dul (Data Unloader), LogMiner;
• MySQL: innochecksum, undrop-for-innodb (восстановление удалённых строк из innodb), mysqlbinlog;
• SQLite: sqlite3 с флагом.recover, а также ручной анализ заголовков страниц.

Низкоуровневые:

• WinHex — универсальный hex-редактор для анализа страниц БД;
• HxD — быстрый просмотр и поиск сигнатур;
• собственные Python-скрипты для парсинга структур.

Все инструменты предварительно валидируются на тестовых базах с известными изменениями. Протокол валидации — часть экспертного заключения. 🛠️📑

КЛЮЧЕВАЯ ФРАЗА №4: Компетентная компьютерная экспертиза баз данных и СУБД невозможна без владения как штатными, так и forensic-инструментами прямого доступа к страницам данных и журналам.

Глава 12. Юридические аспекты: как ходатайствовать о назначении экспертизы

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

1. Указать конкретные обстоятельства, которые могут быть установлены только экспертизой (например, факт изменения данных задним числом, подмена учётной записи, восстановление удалённых строк).
2. Сформулировать вопросы в технически корректной форме. Некорректно: «Кто украл деньги?». Корректно: «Какие изменения вносились в таблицу payments за период с 01.01.2025 по 01.02.2025, с указанием времени, учётной записи и старого/нового значения полей?».
3. Указать экспертное учреждение — Союз «Федерация судебных экспертов» (с приложением документов о компетенции).
4. Предоставить доступ к объектам: образ диска сервера БД, резервные копии, журналы СУБД, системные логи.

Судья не обязан разбираться в технических деталях, поэтому ходатайство должно содержать ссылки на нормы ГПК/АПК/УПК о необходимости специальных знаний (ст. 79 ГПК, ст. 82 АПК, ст. 195 УПК). 💼📝

Глава 13. Примерный план экспертного заключения по БД

Структура нашего заключения всегда следует научному стандарту:

1. Вводная часть: кем назначена, дата, материалы дела, вопросы.
2. Исследуемые объекты: список файлов, их хэш-суммы (SHA-256), информация о копировании.
3. Методика исследования: перечень использованных методов (анализ LDF, дамп страниц, WAL-mining) с обоснованием.
4. Ход исследования: пошагово, с выкладками кода, hex-дампов, скриншотов.
5. Синтез результатов: временная шкала событий, таблица изменённых записей, идентификация учётных записей.
6. Выводы: ответы на поставленные вопросы в чёткой формулировке, без вероятностных формулировок.

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

Глава 14. Ограничения и границы применимости экспертизы БД

Честный эксперт всегда указывает на границы своего исследования:

⛔ Невозможно определить «кто именно» нажал на клавишу, если сессия была shared или использовались generic-учётки. Мы можем указать учётную запись БД, но не всегда — физическое лицо. Для привязки к личности нужны дополнительные данные (логи доступа к ОС, видеонаблюдение).

⛔ Если журналы транзакций полностью перезаписаны (цикличность) и нет архивов, восстановить историю старше периода хранения невозможно. Исключение — если файлы данных сохранили «тени» удалённых строк в нераспределённом пространстве, но это не всегда так.

⛔ Шифрование базы данных на уровне диска (BitLocker, LUKS) без ключа делает невозможным прямой анализ файлов. Экспертиза возможна только на работающей системе с расшифрованными данными.

⛔ Облачные СУБД (RDS, Cloud SQL) — ограниченный доступ к файловой системе. Исследование строится на логах аудита СУБД, которые предоставляет провайдер. Это снижает глубину, но не исключает экспертизу полностью.

Эти ограничения обязательно фиксируются в заключении, чтобы не создавать иллюзий у суда. 🚧⚠️

Глава 15. Почему Союз «Федерация судебных экспертов» — выбор технических специалистов

Наша команда состоит из бывших DBA, разработчиков СУБД и сертифицированных судебных экспертов. Мы работаем с закрытыми форматами файлов СУБД на уровне документации и реверс-инжиниринга. Мы публикуем статьи в журналах «Банк данных» и «Computer Fraud & Security». Наши методики прошли рецензирование в РФЦСЭ при Минюсте России. 🧪🏅

Технические преимущества:

• Собственная библиотека парсеров для чтения файлов данных в обход СУБД (поддерживаем Oracle, MS SQL, PostgreSQL, MySQL, SQLite, 1C).
• Опыт работы с повреждёнными и частично отформатированными носителями (RAID-массивы, флеш-память).
• Наличие аккредитованной лаборатории для работы с вещественными доказательствами.

Процессуальные гарантии:

• Включение эксперта в реестр ТПП и Минюста.
• Страхование профессиональной ответственности на 10 млн руб.
• Полная конфиденциальность, договор с ответственностью за разглашение.

КЛЮЧЕВАЯ ФРАЗА №5: Повторим для тех, кто не дочитал: Компьютерная экспертиза баз данных и СУБД от Союза «Федерация судебных экспертов» — это сплав глубоких технических знаний и юридической безупречности.

Финальная техническая спецификация

Уважаемые заказчики и коллеги! Если перед вами стоит задача исследования базы данных в рамках судебного или досудебного разбирательства — не полагайтесь на удачу и «своего» программиста. Требуйте назначения независимой компьютерной экспертизы в нашем учреждении. Мы работаем с образами дисков, журналами транзакций и физическими дампами страниц. Мы восстанавливаем то, что считалось утерянным. Мы доказываем то, что считалось недоказуемым. 🔬💥

Переходите на наш технический портал: https://kriminalist77.ru/ekspertiza-baz-dannyh/ — там вы найдёте формы ходатайств для суда, примеры заключений (обезличенные) и подробные спецификации на каждый тип СУБД. Мы открыты для профессионального диалога и сложных технических вызовов.

Союз «Федерация судебных экспертов»
Лаборатория компьютерно-технической экспертизы
Инженерный подход. Математическая достоверность. Процессуальная чистота. 🧷✅