Введение: актуальность независимого технического анализа структурированных массивов информации

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

Глава 1. Определение предметной области и объекты исследования

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

📌 Файлы данных основной области (DATA files): для MICROSOFT SQL SERVER — MDF, NDF; для ORACLE DATABASE — DBF; для POSTGRESQL — файлы в каталоге base; для MYSQL (INNODB) — IBD и FRM.

• 📌 Журналы транзакций: LDF (MICROSOFT), Redo Logs и Archive Logs (ORACLE), Write-Ahead Log (WAL) для POSTGRESQL, Binary Log (BINLOG) для MYSQL.
• 📌 Системные каталоги и словари данных: представления SYS.TABLES, PG_CLASS, INFORMATION_SCHEMA и соответствующие физические файлы.
• 📌 Резервные копии в проприетарных форматах (BAK, DMP, DUMP) и их метаданные.
• 📌 Дампы оперативной памяти серверов СУБД, полученные с использованием средств криминалистического копирования (например, LI-MEM, FMEM).
• 📌 Сетевые трассировки взаимодействия между прикладным уровнем и сервером БД (PCAP-файлы).

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

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

Современные СУБД (за исключением некоторых колоночных и in-memory систем) используют страничную модель хранения. Размер страницы фиксирован: 8 КБ для MICROSOFT SQL SERVER и POSTGRESQL, 16 КБ для MYSQL INNODB, 2–32 КБ для ORACLE. Каждая страница включает заголовок фиксированного формата, массив слотов (указателей на записи в пределах страницы) и область данных переменной длины.

Страничный заголовок содержит следующие критически важные сведения для эксперта:

🔹 Тип страницы (DATA_PAGE, INDEX_PAGE, IAM_PAGE, BITMAP_PAGE и др.).
🔹 LSN (LOG SEQUENCE NUMBER) — последний номер записи журнала, применённой к данной странице.
🔹 Флаги модификации, включая признак «грязной страницы» (DIRTY PAGE).
🔹 Номер объекта (OBJECT_ID) и идентификатор индекса (INDEX_ID), которым принадлежит страница.
🔹 Ссылки на предыдущую и следующую страницу в экстенте (LINK_PREV, LINK_NEXT).

Слоты представляют собой 2-байтовые смещения от начала страницы, указывающие на начало записи. При физическом удалении строки (DELETE) СУБД не обнуляет содержимое записи, а лишь устанавливает флаг удаления в заголовке слота и модифицирует карту свободного пространства (PFS — PAGE FREE SPACE). Сами данные остаются доступными для чтения до момента их перезаписи в ходе фоновых процессов (AUTOVACUUM, CHECKPOINT, LAZY WRITER).

Это свойство лежит в основе восстановления удалённых записей и выявления фактов модификации, выполненных в обход штатных механизмов журналирования.

Глава 3. Механизмы временной привязки транзакций: LSN, XID, COMMIT TIMESTAMP

Для восстановления хронологии событий и выявления аномалий временных меток используются следующие концепции:

⏱️ LSN (LOG SEQUENCE NUMBER) — монотонно возрастающее 64-разрядное значение, присваиваемое каждой записи журнала транзакций. В MICROSOFT SQL SERVER формат LSN: (4 байта VLF_ID):(4 байта LOG_BLOCK):(2 байта LOG_RECORD). В ORACLE — SCN (SYSTEM CHANGE NUMBER). LSN однозначно задаёт порядок применения изменений и не может быть изменён без остановки СУБД и прямого редактирования файлов журнала.

⏱️ XID (TRANSACTION IDENTIFIER) — 32-битный счётчик активных транзакций. В POSTGRESQL XID переполняется, однако для судебной экспертизы критично значение в пределах одного эпичного периода (порядка 2 миллиардов транзакций).

⏱️ COMMIT TIMESTAMP — физическое время фиксации транзакции, хранимое либо в системных таблицах (PG_COMMIT_TS), либо в самом журнале (ORACLE REDO LOGS). Этот timestamp не зависит от пользовательских полей типа DATETIME и не может быть изменён без нарушения целостности журнала.

Метод кросс-валидации заключается в построении регрессионной зависимости между LSN и COMMIT TIMESTAMP. Любое статистически значимое отклонение (например, аномальное приращение LSN при неизменном времени) свидетельствует о ручной правке пользовательских временных меток или о прямой модификации страниц данных.

Глава 4. Типология следов фальсификации в структурах СУБД

На основе анализа более 200 судебных экспертиз нами выделены следующие типы артефактов, указывающих на несанкционированные изменения:

1. Артефакты уровня журнала транзакций:

• Разрывы в последовательности LSN (пропущенные номера).
• Несоответствие контрольной суммы (CHECKSUM) в заголовке блока журнала.
• Наличие записей типа LOP_BEGIN_XACT без соответствующих LOP_COMMIT_XACT.
• Записи операций DDL (CREATE, ALTER, DROP) в журнале с таймстемпами, предшествующими созданию базы данных.

1. Артефакты уровня страниц данных:

• Несоответствие флага DIRTY_PAGE фактическому состоянию страницы.
• Обнаружение строк с типом GHOST_RECORD (удалённых, но не зачищенных) в таблицах, где автовакуум должен был их удалить.
• Наличие записей с нулевыми сдвигами в массиве слотов.
• Расхождение между временем модификации страницы (из атрибутов файловой системы NTFS или EXT4) и временем последнего LSN, применённого к странице.

1. Артефакты уровня системных каталогов:

• Модификация PG_CLASS.RELALLVISIBLE без соответствующей операции VACUUM.
• Изменение последовательностей (SEQUENCE) в обход NEXT VALUE FOR.
• Наличие триггеров с атрибутом IS_TRUSTED, но без валидной подписи (для SQL SERVER).

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

Глава 5. Кейс №1: Обнаружение модификации страниц через DBCC WRITEPAGE (MICROSOFT SQL SERVER)

🔬 Постановка задачи: В рамках арбитражного спора о неосновательном обогащении истец предоставил выгрузку из базы данных 1С, где фигурировала задолженность контрагента в размере 12,7 млн рублей. Ответчик настаивал на том, что первичные документы были удалены штатным образом, а сумма долга отсутствует.

🧪 Методика исследования: Экспертом были получены два образа дискового массива сервера БД (RAID 10, файловая система NTFS) с разницей в 14 дней. После выполнения байтового сравнения (TOOL: WINHEX, функция SYNCHRONIZE) обнаружены расхождения в трёх страницах файла MyDatabase.mdf, не связанные с нормальной работой СУБД.

При помощи ручного парсинга заголовка страницы (смещения 0x00–0x60) установлено:

• LSN страницы до изменения: 0x0000002F:000001C0:0003
• LSN страницы после изменения: 0x0000002F:000001C0:0003— значение не изменилось!
• Флаг DIRTY_PAGE (бит 0x08 в байте 0x14) был принудительно сброшен.

Далее проведён анализ журнала транзакций LDF с помощью разработанного парсера MSLSNREADER, который показал отсутствие каких-либо записей для соответствующих PAGE_ID за период между датами образов. Следовательно, модификация страниц выполнена не через SQL-запросы, а через команду DBCC WRITEPAGE (недокументированная возможность SQL SERVER), которая позволяет напрямую перезаписывать байты на странице без внесения записей в журнал.

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

Глава 6. Кейс №2: Восстановление записей после VACUUM FULL в POSTGRESQL

🗄️ Фабула: Гражданское дело о разделе бизнеса. За 48 часов до инвентаризации неизвестное лицо выполнило DELETE FROM orders WHERE created_at < ‘2023-01-01’, а затем VACUUM FULL. Удалению подверглись записи о заказах за 2 предыдущих года на сумму 23 млн рублей.

🛠️ Инструментарий: Получен образ диска сервера через FORENSIC IMAGER (LINUX DD). Выполнен анализ освобождённого пространства файловой системы EXT4 с помощью TOOL: SCALPEL (конфигурация с сигнатурами POSTGRESQL). Сигнатура начала кортежа POSTGRESQL: 0x1FFF (два байта, за которыми следует флаг отображения NULL).

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

1. Идентификацию всех блоков (размером 8 КБ) на диске, начинающихся с 0x1FFFи имеющих валидную контрольную сумму (CRC32C в заголовке страницы).
2. Извлечение системной таблицы PG_CLASS из повреждённой области — получен список OID удалённых таблиц.
3. Реконструкцию схемы таблицы ordersпо остаточным данным в PG_ATTRIBUTE (даже после DROP SCHEMA часть записей сохраняется в битых экстентах).
4. Парсинг кортежей с отображением столбцов согласно восстановленной схеме.

📈 Результат: Восстановлено 1 842 записи из 2 417 (76,2%). Недостающие 575 записей пришлись на страницы, перезаписанные системой после VACUUM. Экспертное заключение содержало вероятностную оценку (интервальная оценка с доверительной вероятностью 0,95) и полную распечатку восстановленных данных в виде таблицы. Суд принял заключение как допустимое доказательство.

Глава 7. Кейс №3: Анализ аномалий AUTO_INCREMENT и сдвигов временных меток в MYSQL INNODB

🎲 Контекст: Исследование факта накрутки голосов в системе электронного голосования некоммерческого партнёрства. В таблице votes (движок INNODB) зафиксировано 12 400 записей, из которых 3 200 были внесены в последние 20 минут голосования.

📊 Методология:

• Выполнен анализ страниц кластерного индекса первичного ключа vote_id. Установлено, что значения ID для «подозрительных» голосов идут кластеризованными блоками по 50–100 единиц, тогда как в нормальной работе приложения инкремент составляет 1–3 с естественным разбросом.
• Проанализирован журнал BINLOG в формате ROW: обнаружены записи типа WRITE_ROWS_EVENTс числом строк в событии > 40, что характерно для LOAD DATA INFILE, но не для вставки через веб-интерфейс.
• В файлах.ibdвыполнено чтение скрытых столбцов DB_TRX_ID и DB_ROLL_PTR. Для «аномальных» голосов значение DB_TRX_ID возрастало немонотонно, что указывает на вставку данных из нескольких транзакций с разными счётчиками, но с одинаковым временем COMMIT (подмена таймстемпов на уровне ОС).

⚖️ Юридический итог: Суд признал, что 2 987 голосов являются сфальсифицированными. Решение собрания об избрании председателя отменено. Эксперт привлечён для дачи пояснений в заседании в порядке ст. 187 ГПК РФ. Данный случай демонстрирует, что инженерная экспертиза баз данных и СУБД позволяет разоблачать даже согласованные атаки с использованием нескольких технических приёмов.

Глава 8. Инструментарий научной лаборатории: парсинг, сигнатуры, валидация

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

Основные компоненты:

🟢 Низкоуровневые редакторы и анализаторы:

• WINHEX 20.x (режим FORENSIC)
• HXD (с плагинами для проверки контрольных сумм страниц)
• BLESS HEX EDITOR (для анализа больших файлов > 4 ГБ)

🟢 Парсеры журналов транзакций (собственная разработка):

• MSSQL_LSN_EXTRACTOR (C++, чтение LDF без SQL SERVER)
• PGSQL_WAL_PARSER (Python, библиотека construct)
• MYSQL_BINLOG_DUMP (модифицированная версия mysqlbinlog с выводом сырых байтов)
• ORACLE_REDO_READER (интеграция с ORACLE LOGMINER на низком уровне)

🟢 Средства криминалистического копирования:

• DD, DCFLDD (LINUX)
• FTK IMAGER (WINDOWS)
• E01, AFF форматы с SHA256 хешированием

🟢 Средства анализа файловых систем:

• THE SLEUTH KIT (для восстановления удалённых файлов)
• AUTOPSY (для анализа MFT, LOGFILE,LOGFILE,USNJRNL)

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

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

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

Ни один из перечисленных методов не является абсолютно надёжным. Как показывает практика, в 94% случаев удаётся выявить следы противодействия или восстановить хотя бы часть данных.

Глава 10. Статистическая валидация выводов: доверительные интервалы и вероятности

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

📊 Уровень A (P ≥ 0,99) — вывод сделан на основании полных и непротиворечивых журналов, доступна вся цепочка LSN, есть кросс-валидация разными методами.

📊 Уровень B (0,95 ≤ P < 0,99) — не хватает части журналов, но есть множественные косвенные свидетельства (статистические аномалии, артефакты файловой системы, свидетели).

📊 Уровень C (0,80 ≤ P < 0,95) — данные восстановлены из фрагментов без журналов, с применением эвристик и мажоритарного голосования.

📊 Уровень D (P < 0,80) — вывод носит предположительный характер, используется только для ориентирования следствия, но не как судебное доказательство.

В заключении для каждого вывода указывается уровень достоверности и методы, используемые для расчёта доверительного интервала (например, метод Байеса для восстановления кортежей).

Глава 11. Сравнительная характеристика устойчивости различных СУБД к фальсификации

С научной точки зрения, различные СУБД обладают неодинаковой степенью защищённости от низкоуровневых модификаций:

🔒 MICROSOFT SQL SERVER — высокая сложность подделки при включённом параметре TORN_PAGE_DETECTION или PAGE_VERIFY = CHECKSUM. Однако возможность использования DBCC WRITEPAGE создаёт уязвимость для экспертов с административными привилегиями.

🔒 ORACLE DATABASE — наилучшая защищённость благодаря обязательной проверке блочных контрольных сумм и централизованному управлению архивными redo-логами. Для подделки требуется отключение архивирования, что оставляет следы в ALERT.LOG.

🔒 POSTGRESQL — открытый WAL и простота анализа являются одновременно и достоинством (для эксперта) и недостатком (для злоумышленника, который может перезаписать WAL-файлы). Уязвимость: pg_resetwal позволяет обнулить журнал.

🔒 MYSQL / MARIADB — низкая устойчивость к фальсификации при отключённом binlog (режим по умолчанию в некоторых сборках). INNODB UNDO-сегменты перезаписываются достаточно быстро (зависит от innodb_undo_retention).

Рекомендация для судебных экспертов: при выборе СУБД для корпоративных систем, где критична доказуемость, следует отдавать предпочтение ORACLE или MICROSOFT SQL SERVER с включённой полной проверкой страниц.

Глава 12. Организационно-процессуальные аспекты: цепочка хранения улик (CHAIN OF CUSTODY)

Для признания заключения допустимым доказательством необходимо строгое соблюдение процедур изъятия и передачи носителей. В союзе «Федерация судебных экспертов» принят следующий регламент:

1. Изъятиепроизводится с участием понятых (по УПК РФ) или под видеозапись (по ГПК РФ). Носитель отключается от питания штатным способом (без завершения работы ОС).
2. Копированиеосуществляется с применением аппаратного WRITE-BLOCKER (например, TABLEAU T8). Программные блокираторы записи (например, ENSAFE) не допускаются для уголовных дел.
3. Маркировка— каждой копии присваивается уникальный идентификатор, вычисляется хеш SHA256, который вносится в протокол.
4. Хранениеосуществляется в сейфовом помещении с ограниченным доступом и регистрацией температуры/влажности.
5. Передачадругому эксперту или в суд сопровождается актом приёма-передачи с фиксацией контрольных сумм.

Нарушение любого из этих этапов может послужить основанием для исключения заключения из материалов дела по ст. 75 УПК РФ (недопустимые доказательства).

Глава 13. Критерии научной обоснованности методики экспертизы

Методика, применяемая союзом «Федерация судебных экспертов», соответствует требованиям, предъявляемым к судебно-экспертным методикам согласно Приказу Минюста РФ № 346 от 27.12.2012:

✔️ Воспроизводимость — любой другой эксперт, имеющий доступ к тому же инструментарию, может повторить исследование и получить идентичные результаты (проверено на трёх независимых аттестованных экспертах).

✔️ Чувствительность — методика позволяет обнаруживать изменения вплоть до одного байта в странице данных (подтверждено на тестовых образцах с внесёнными изменениями).

✔️ Специфичность — минимальное количество ложных срабатываний (менее 0,1% на выборке из 10 000 тестовых страниц).

✔️ Валидность — результаты сопоставлены с «золотым стандартом» (исходные SQL-скрипты изменений в подопытной базе).

Методика прошла рецензирование в рецензируемом журнале «Теория и практика судебной экспертизы» (Вопросы экспертной практики, 2024, № 2, стр. 45-58). Инженерная экспертиза баз данных и СУБД признана самостоятельным родом (видом) судебной экспертизы на заседании Научно-методического совета при РФЦСЭ Минюста России.

Глава 14. Перспективные направления научных исследований

В рамках деятельности союза ведутся следующие научно-исследовательские и опытно-конструкторские работы:

🧪 Разработка формальной модели верификации LSN с использованием теории графов и марковских цепей для выявления аномальных последовательностей.

🧪 Создание парсера для распределённых ledger-СУБД (YUGABYTE, COCKROACHDB, SPANNER) с учётом распределённой природы хранения и отсутствия единого журнала.

🧪 Исследование возможности восстановления данных из NAND-чипов SSD после операции TRIM с использованием методов электронной микроскопии остаточного заряда (совместно с лабораторией физических методов исследования).

🧪 Разработка методологии экспертизы баз данных в контейнерной среде (DOCKER, KUBERNETES) с учётом эфемерности хранилищ и особенностей overlay-файловых систем.

Данные работы финансируются из средств союза и грантов РФФИ (проект № 23-27-00897 «Формальные методы цифровой криминалистики»).

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

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

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

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

На сайте также доступны для скачивания образцы заключений (с удалёнными персональными данными), перечень публикаций сотрудников в рецензируемых журналах и форма для заявки на исследование. Мы работаем на всей территории Российской Федерации, оказываем содействие в изъятии и транспортировке носителей, обеспечиваем полную конфиденциальность.