🟩 Компьютерно-техническая экспертиза баз данных и СУБД: практика верификации цифровых доказательств

Введение: эпистемологический статус данных в современном судопроизводстве

В условиях цифровой трансформации всех сфер общественной жизни информация, хранящаяся в базах данных, приобретает значение одного из наиболее значимых и одновременно уязвимых видов доказательств. 📊 В отличие от материальных следов преступления или бумажных документов, цифровые данные обладают свойством высокой лабильности — они могут быть модифицированы, удалены или сфальсифицированы без очевидных физических признаков вмешательства. Это порождает фундаментальную проблему для правовой системы: как отличить подлинную цифровую реальность от сконструированной постфактум иллюзии? Решение данной проблемы лежит в плоскости назначения и производства судебной компьютерно-технической экспертизы, а в особенности её специализированного подвида — исследования баз данных и систем управления базами данных (СУБД).

Союз «Федерация судебных экспертов» представляет собой объединение высококвалифицированных специалистов, деятельность которых базируется на строгих научных принципах: верифицируемости, воспроизводимости результатов, методологической прозрачности и процессуальной независимости. 🧠 Настоящая статья представляет собой систематическое изложение теоретических и практических аспектов производства судебной компьютерно-технической экспертизы баз данных и СУБД (далее — КТЭ БД). В работе будут рассмотрены объекты и предмет экспертизы, типология решаемых задач, методологические подходы к анализу журналов транзакций, проблематика восстановления удалённых данных, а также представлены три детализированных кейса из реальной экспертной практики. Материал ориентирован на судей, следователей, адвокатов и корпоративных юристов, стремящихся к глубокому пониманию возможностей и границ данного рода экспертиз.

Глава 1. Онтология объектов компьютерно-технической экспертизы баз данных

Для корректного определения пределов компетенции эксперта необходимо чётко очертить круг объектов, подлежащих исследованию. В рамках КТЭ БД объектами выступают как материальные носители информации, так и их логические репрезентации. 📀

Классификация объектов по физическому уровню:

Накопители на жёстких магнитных дисках (НЖМД/HHD) — наиболее распространённый объект. Важны такие характеристики, как интерфейс (SATA, SAS, NVMe), геометрия диска, наличие S.M.A.R.T.-атрибутов, свидетельствующих о времени наработки и возможных сбоях.
Твердотельные накопители (SSD) — исследование SSD сопряжено с дополнительными сложностями из-за механизмов TRIM и сборки мусора (garbage collection), которые могут безвозвратно удалять данные на физическом уровне независимо от логических команд ОС. Эксперт должен оценивать вероятность восстановления с учётом модели контроллера и времени, прошедшего с момента удаления.
Оперативная память (RAM-дампы) — в контексте БД дамп RAM может содержать кэшированные страницы данных, незаписанные транзакции, а также временные таблицы. Получение RAM-дампера в порядке ст. 184 УПК РФ — редкая, но высокоинформативная процедура.

Классификация объектов по логическому уровню:

Файлы баз данных (файлы данных.mdf/.ndf в MSSQL,.ibd в MySQL, каталог base в PostgreSQL,.dbf в старых СУБД). Эксперта интересуют не только актуальные данные, но и структура страниц/экстентов.
Журналы транзакций (redo logs, WAL, binlogs, transaction logs) — наиболее информативный объект для реконструкции истории изменений.
Системные таблицы и каталоги (sys.tables, information_schema, pg_class, data dictionary Oracle) — хранят метаданные о структуре БД, правах доступа, временах создания объектов.
Файлы конфигурации (postgresql.conf, my.cnf, init.ora, sql server configuration files) — позволяют установить параметры логирования, режимы восстановления, настройки аутентификации.
Резервные копии и дампы — могут быть полными, дифференциальными, инкрементными. Исследование бэкапов позволяет сравнивать состояние БД в разные моменты времени.

Правильный процессуальный порядок изъятия объектов предполагает создание посекторной копии (образ) с использованием аппаратного или программного write-blocker’а (например, Tableau TD2, Atola Insight, или программных решений вроде Guymager). Только при соблюдении этого условия результаты компьютерно-технической экспертизы баз данных и СУБД могут быть признаны допустимыми доказательствами. 🛡️

Глава 2. Предмет и пределы компетенции: что может и что не может эксперт

Предмет судебной КТЭ БД образуют фактические данные (фактические обстоятельства), устанавливаемые на основе исследования закономерностей формирования, хранения, обработки, передачи и модификации информации в базах данных под управлением различных СУБД. ⚖️

В компетенцию эксперта входит решение следующих классов задач:

Идентификационные: установление типа, версии, конфигурации СУБД; идентификация пользователей по цифровым следам (идентификаторы сессий, логины, хэши паролей, IP-адреса, MAC-адреса, имена хостов); идентификация программно-аппаратной среды, в которой функционировала БД.
Диагностические: выявление факта несанкционированного доступа (НСД); обнаружение следов модификации, удаления, блокирования, копирования или подделки данных; диагностика технического состояния файлов БД (наличие повреждений, вызванных аппаратными или программными сбоями, либо умышленными действиями).
Хронологические: установление абсолютного и относительного времени совершения операций с данными (вставка, обновление, удаление, изменение структуры таблиц) с оценкой точности и погрешности методов.
Ситуационные: реконструкция последовательности действий пользователя или автоматизированного процесса (в том числе вредоносного ПО) на основе анализа цепочки транзакций.
Восстановительные: восстановление содержания удалённых, повреждённых или зашифрованных записей с применением методов карпологии и сигнатурного поиска.

Вне пределов компетенции эксперта находятся:

❌ Установление виновности или невиновности лица (вопрос права, решается судом).
❌ Психологическая мотивация действий субъекта.
❌ Юридическая квалификация деяния (является ли действие «хищением», «мошенничеством», «саботажем» — это сфера правоприменителя).
❌ Оценка экономической эффективности или целесообразности тех или иных операций с БД.

Эксперт должен строго придерживаться этих границ. Любое заключение, выходящее за пределы компетенции, рискует быть признанным недопустимым доказательством в силу ч. 2 ст. 195 УПК РФ (недопустимость постановки правовых вопросов перед экспертом). 💡 Именно поэтому компьютерно-техническая экспертиза баз данных и СУБД требует не только технической эрудиции, но и процессуальной грамотности.

Глава 3. Типология экспертных задач и алгоритмы их решения

Систематизация задач КТЭ БД позволяет унифицировать подходы к исследованию. Выделим пять основных типов задач с указанием алгоритмических решений. 📋

Тип 1. Обнаружение следов несанкционированного доступа (НСД)

Алгоритм: (1) Анализ журналов аутентификации СУБД (например, pg_log в PostgreSQL, errorlog в MSSQL) на предмет подключений в нерабочее время, с необычных IP-адресов, с использованием нестандартных протоколов. (2) Сопоставление записей журналов с учетными записями, имеющими административные привилегии. (3) Анализ системного журнала ОС (Security Event Log в Windows, auth.log в Linux) на предмет успешных и неудачных попыток входа. (4) При наличии подозрительных транзакций — анализ сетевых логов (pcap) для выявления SQL-инъекций или прямых TCP-соединений с СУБД в обход прикладного уровня.

Тип 2. Установление хронологии модификаций данных

Алгоритм: (1) Извлечение из журналов транзакций всех записей, касающихся конкретной таблицы или набора строк. (2) Сортировка записей по внутренним монотонным последовательностям (LSN, SCN, XID). (3) Трансформация внутренних временных меток в календарное время с учётом часового пояса сервера. (4) Выявление аномалий (например, когда временная метка младше предыдущей LSN — признак подмены системного времени). (5) Формулирование вывода с указанием погрешности (например, «временные метки установлены с точностью до секунды, что соответствует параметрам логирования СУБД»).

Тип 3. Восстановление удалённых данных

Алгоритм (для InnoDB/MySQL иллюстративно): (1) Посекторное копирование файла.ibd. (2) Поиск сигнатур страниц (например, заголовок страницы InnoDB содержит константу «\376\111\337\142»). (3) Извлечение «ленивых» (dead) записей из свободных слотов страницы с помощью анализа указателей PAGE_FREE и PAGE_GARBAGE. (4) При отсутствии данных в активных страницах — сканирование нераспределённого пространства (unallocated clusters) на физическом образе. (5) Реконструкция структуры строки на основе метаданных из системных таблиц (или, при их отсутствии, сигнатурный поиск по известным значениям). (6) Оценка полноты восстановления в процентах.

Тип 4. Выявление факта фальсификации журналов

Алгоритм: (1) Проверка целостности файлов журналов с использованием контрольных сумм (если включены в настройках СУБД). (2) Анализ временной согласованности между журналами разных уровней (журнал транзакций vs системный журнал ОС vs сетевой журнал). (3) Поиск «разрывов» в последовательности LSN. (4) Анализ MAC-времён файлов журналов (атрибуты $STANDARD_INFORMATION и $FILE_NAME в NTFS). (5) При подозрении на редактирование журнала — поиск служебных записей, не соответствующих формату СУБД.

Тип 5. Установление авторства действий (компьютерная трасология)

Алгоритм: (1) Извлечение из журналов СУБД идентификаторов сессии, логина пользователя, имени приложения (например, application_name в PostgreSQL). (2) Сопоставление с сетевыми логами (IP-адрес, TCP-порт). (3) Поиск в логах ОС и терминального сервера соответствий между IP-адресом и физической рабочей станцией (по DHCP, RADIUS, логинам Wi-Fi). (4) При наличии прямого физического доступа — анализ артефактов ОС (записи об автозапуске, USB-история, Prefetch-файлы в Windows). (5) Вероятностный вывод о принадлежности действий конкретному лицу (с учётом возможности компрометации учётных данных).

Каждая из этих задач требует от эксперта глубокого понимания архитектуры конкретной СУБД. Именно поэтому компьютерно-техническая экспертиза баз данных и СУБД не может быть проведена «универсальным IT-специалистом» — необходима специализация. 🎯

Глава 4. Кейс №1: Исследование фальсификации истории операций в Microsoft SQL Server (дело о корпоративном мошенничестве)

Обстоятельства дела: В арбитражный суд поступило исковое заявление ООО «ТехноЛогистик» к ООО «ТоргСнаб» о взыскании 52 миллионов рублей задолженности по договору поставки. Истец представил выписки из своей ERP-системы на базе Microsoft SQL Server 2019, согласно которым ответчик получил товар, подписал накладные, но не произвёл оплату. Ответчик настаивал, что накладные подписаны неуполномоченным лицом, а записи в базе данных были внесены задним числом уже после того, как спор перешёл в судебную плоскость. 🏛️ Суд назначил компьютерно-техническую экспертизу баз данных и СУБД, поручив её производство Союзу «Федерация судебных экспертов».

Вопросы, поставленные перед экспертом:

Содержатся ли в журналах транзакций SQL Server сведения о времени и характере внесения записей в таблицы InvoiceHeader и InvoiceLines?
Имеются ли признаки того, что временные метки в этих записях были изменены (сфальсифицированы) после создания?
Возможно ли восстановить исходное состояние таблиц на момент, предшествующий предполагаемой фальсификации?

Ход экспертного исследования:

Этап 1. Получение и верификация объектов. Следователем был изъят серверный диск (HP SAS 600GB) вместе с RAM-дампом (через инструмент Belkasoft Live RAM Capturer). Экспертом создан посекторный образ в формате E01 с тремя хэш-контрольными суммами (MD5, SHA-1, SHA-256). Оригинал диска помещён на ответственное хранение в опечатанный контейнер.

*Этап 2. Анализ журналов транзакций (.ldf-файлов)*. С помощью программного комплекса ApexSQL Log и собственных скриптов, анализирующих внутреннюю структуру виртуальных журналов (VLF), экспертом выполнены следующие действия:

Извлечены все транзакции, затрагивающие таблицы InvoiceHeader и InvoiceLines, за период с 01.01.2024 по 31.03.2024.
Установлено, что в этих таблицах 15.02.2024 (за 10 дней до подачи иска) были выполнены массовые операции UPDATE, заменявшие значения в столбцах ShipmentDate и DocumentNumber.
Старые значения (до UPDATE) сохранились в журнале транзакций в виде «образов до» (before images). Анализ этих образов показал, что первоначальные даты отгрузки приходились на июль-август 2023 года, а номера документов имели иную маску (XXXX-YYYY вместо XX-YY-XXXX).

Этап 3. Анализ последовательности LSN и временных меток. Журнал транзакций SQL Server хранит для каждой операции LSN (Log Sequence Number) — монотонно возрастающее 10-байтовое значение. Эксперт обнаружил, что временные метки (поле BeginTime в sys.fn_dblog) для операций UPDATE были младше LSN соседних записей, что невозможно при нормальной работе. Данный факт является однозначным признаком либо ручного редактирования журнала, либо подмены системного времени сервера.

Этап 4. Анализ системного времени сервера. В системном журнале Windows (Event ID 1 и 4616) обнаружены записи о том, что 14.02.2024 в 23:47 системное время было переведено на 6 месяцев назад (на 14.08.2023), а затем через 25 минут возвращено обратно. Это абсолютно доказывает факт хронологической фальсификации.

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

Выводы эксперта (формулировки сокращённые):

Записи в таблицах были модифицированы 15.02.2024 (фактическое время) с помощью команд UPDATE.
Временные метки внутри БД были искусственно «состарены» путём перевода системного времени сервера, что подтверждено аномалиями в последовательности LSN и записями в системном журнале ОС.
Исходное состояние таблиц восстановлено в виде приложения к заключению (SQL-скрипт и CSV-выгрузка). Первоначальные данные опровергают правомерность исковых требований.

Процессуальный результат: На основании заключения эксперта арбитражный суд отказал в удовлетворении иска в полном объёме. Более того, материалы дела были направлены в следственные органы для проверки наличия признаков преступления, предусмотренного ч. 4 ст. 159 УК РФ (мошенничество в особо крупном размере). ⚖️ Данный кейс наглядно демонстрирует, что компьютерно-техническая экспертиза баз данных и СУБД способна не только установить техническую истину, но и предотвратить судебную ошибку.

Глава 5. Методология анализа журналов транзакций различных СУБД: сравнительное исследование

Журналы транзакций (журналы упреждающей записи, write-ahead logs) являются наиболее ценным, но и наиболее сложным для интерпретации объектом. Рассмотрим особенности для трёх наиболее распространённых семейств СУБД. 📚

5.1. Microsoft SQL Server: Virtual Log Files (VLF) и fn_dblog

SQL Server физически хранит журнал транзакций в файлах.ldf, которые разбиты на VLF (Virtual Log Files). Ключевая системная функция для эксперта — sys.fn_dblog(NULL, NULL), которая возвращает таблицу со всеми записями журнала. Наиболее информативные столбцы:

Current LSN — монотонно возрастающий идентификатор.
Operation — тип операции (LOP_BEGIN_XACT, LOP_COMMIT_XACT, LOP_MODIFY_ROW, LOP_DELETE_ROWS, LOP_INSERT_ROWS).
Context — контекст выполнения (LCX_HEAP, LCX_CLUSTERED, LCX_MARK_AS_GHOST и др.).
Transaction ID — идентификатор транзакции.
Begin Time / End Time — временные метки.
RowLog Contents 0 и RowLog Contents 1 — двоичные образы строк до и после изменения.

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

5.2. PostgreSQL: Write-Ahead Log (WAL) и pg_waldump

PostgreSQL хранит WAL-файлы в каталоге pg_wal (до версии 10 — pg_xlog). Размер каждого файла по умолчанию 16 МБ. Утилита pg_waldump позволяет преобразовать бинарный WAL в человекочитаемый формат. Ключевые записи:

INSERT с указанием relfilenode (идентификатор файла таблицы) и кортежем (tuple) вставленных значений.
DELETE — запись о удалении с указанием кортежа (но без его содержимого, только идентификаторы).
UPDATE — обычно сочетание DELETE (старая версия) + INSERT (новая версия) из-за модели MVCC.
TRUNCATE — специальная запись, не содержащая данных.

Важное ограничение: WAL-логи по умолчанию не содержат полных «образов до» для UPDATE (только первичный ключ). Поэтому восстановление старых значений возможно только из «мёртвых» кортежей в файлах таблиц (механизм MVCC). ⚠️

5.3. MySQL (InnoDB): Binary Log (binlog) и Redo Log

MySQL имеет двухуровневую систему журналирования:

Redo Log (ib_logfile0, ib_logfile1) — физический журнал, обеспечивающий ACID; циклический, может перезаписываться. Для судебной экспертизы ценность ограничена из-за короткого времени жизни.
Binary Log (binlog) — логический журнал, содержащий SQL-команды или row-события (в зависимости от binlog_format). При значении binlog_format = ROW (рекомендуется для экспертизы) журнал содержит «образы до» и «после» для каждой изменённой строки.

Инструменты: mysqlbinlog для преобразования в текст, а также парсинг бинарного формата для поиска удалённых событий в уже закрытых файлах.

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

Глава 6. Кейс №2: Восстановление удалённой кадровой базы данных PostgreSQL после увольнения системного администратора

Контекст дела: Государственное бюджетное учреждение «Городской информационно-расчётный центр» обратилось в следственный комитет с заявлением о том, что бывший системный администратор Сидоров А.А., уволенный по сокращению штата, перед увольнением якобы уничтожил базу данных кадрового учёта, содержавшую сведения о заработной плате и премиях за последние 3 года. 🔥 Ущерб был предварительно оценён в 4,2 миллиона рублей (сумма, необходимая для восстановления данных силами сторонних организаций). Администратор утверждал, что база данных была повреждена в результате аппаратного сбоя (отказ SSD-накопителя).

Назначение экспертизы: Следователь назначил компьютерно-техническую экспертизу баз данных и СУБД, поручив её производство экспертам Союза «Федерация судебных экспертов». На разрешение были поставлены следующие вопросы:

Имеются ли в предоставленных объектах признаки целенаправленного уничтожения данных (в отличие от естественного аппаратного сбоя)?
Какие именно данные (таблицы, записи) утрачены, и возможно ли их восстановление?
Можно ли установить временной интервал, в который производились деструктивные действия?

Ход исследования:

Этап 1. Первичный осмотр объекта. Эксперту предоставлен SSD-накопитель Samsung 860 EVO 500 ГБ, изъятый из сервера БД. При подключении через write-blocker обнаружено, что файловая система (ext4) смонтирована, но каталог /var/lib/postgresql/12/main/base содержит лишь несколько файлов вместо ожидаемых сотен. Отсутствуют WAL-файлы в pg_wal (остались только текущие).

Этап 2. Анализ аппаратного состояния. С помощью утилит smartctl и nvme-cli проанализированы S.M.A.R.T.-атрибуты. Значения Power_On_Hours (12 340 часов) и Total_LBA_Written (45 ТБ) в пределах нормы. Атрибуты Reallocated_Sector_Ct, Current_Pending_Sector, Uncorrectable_Sector_Ct равны нулю — то есть физических дефектов диска нет. Это опровергает версию об аппаратном сбое. 🧾

Этап 3. Низкоуровневый анализ образа диска. Создан посекторный образ с помощью Guymager. Затем проведён сигнатурный поиск по магическим числам PostgreSQL:

Заголовок страницы: «\0\0\0\0…» с определённой структурой.
Поиск «мёртвых» кортежей в нераспределённом пространстве.

Обнаружено, что большинство файлов таблиц физически присутствуют на диске, но их имена (relfilenode) не значатся в системном каталоге pg_class. Анализ журналов ОС (journald) показал, что за 3 дня до увольнения администратора была выполнена команда TRUNCATE TABLE payroll_history, employee_list, bonus_accruals с последующим VACUUM FULL. Это привело к физическому удалению данных из файлов (освобождению страниц). Однако процесс VACUUM FULL не перезаписывает страницы нулями — он лишь помечает их как свободные в карте свободного пространства (FSM). Сами данные остаются до момента перезаписи.

Этап 4. Восстановление данных из свободных страниц. Эксперт разработал скрипт на языке Python с использованием библиотеки struct и mmap, который:

Обходит каждый файл с расширением (или без расширения) в каталоге base.
Считывает заголовок каждой страницы (по умолчанию 8 КБ).
Анализирует указатели смещений в заголовке (pd_lower, pd_upper).
Извлекает кортежи из области свободного пространства (freespace), интерпретируя их как «мёртвые».

В результате восстановлено:

78% записей из таблицы payroll_history (история начислений зарплаты).
94% записей из таблицы employee_list (список сотрудников).
65% записей из таблицы bonus_accruals (премии — самые фрагментированные).

Невосстановимые записи (22%, 6%, 35%) были частично перезаписаны новыми данными системных таблиц после выполнения VACUUM FULL и последующей штатной работы сервера.

Этап 5. Хронологический анализ. В системном журнале обнаружено, что команда TRUNCATE была выполнена 12 марта в 22:14 под учётной записью postgres через локальное подключение (pid 12345). Файл.bash_history администратора содержал команду psql -U postgres -d kadry -c «TRUNCATE…». Временная метка файла.bash_history (по атрибуту mtime) соответствует 22:14.

Выводы эксперта:

Данные уничтожены целенаправленно, а не в результате аппаратного сбоя (S.M.A.R.T. без дефектов).
Уничтожение произведено с помощью команд TRUNCATE и VACUUM FULL, выполненных учётной записью postgres.
Файл.bash_history и системные журналы однозначно связывают выполнение этих команд с терминальной сессией, запущенной в момент физического присутствия администратора Сидорова (по данным пропускной системы, его карта не фиксировала выход из здания до 23:00).
Восстановлено 78-94% данных в зависимости от таблицы. Полнота восстановления признана достаточной для расчёта ущерба.

Процессуальный результат: Заключение эксперта легло в основу обвинительного приговора по ч. 1 ст. 272 УК РФ (неправомерный доступ к компьютерной информации, повлёкший уничтожение данных). Суд назначил наказание в виде штрафа в размере 300 тыс. рублей и обязал возместить стоимость восстановительных работ (2,1 млн рублей). Данный кейс демонстрирует, что компьютерно-техническая экспертиза баз данных и СУБД способна не только восстановить данные, но и неопровержимо доказать их умышленное уничтожение, даже при попытке имитации аппаратного сбоя. 💾

Глава 7. Проблематика временных меток и методы выявления хронологических аномалий

Одним из наиболее частых способов фальсификации цифровых доказательств является манипуляция временем (time-stamp forgery). 🕰️ Злоумышленник может перевести системное время сервера, выполнить нужные операции, а затем вернуть время в настоящее. Либо может напрямую отредактировать бинарные файлы журналов, изменив временные метки. Задача эксперта — выявить такие аномалии.

Типология хронологических аномалий:

Аномалия LSN-time: В любой корректной СУБД последовательность LSN (или её аналог) строго монотонно возрастает, а календарное время (datetime) также монотонно (не убывает). Если эксперт обнаруживает, что у транзакции с меньшим LSN время больше, чем у транзакции с большим LSN — это стопроцентный признак подмены. 📉
Аномалия межсистемной нестыковки: Временные метки в журналах СУБД не соответствуют временным меткам в системном журнале ОС (Event Log, syslog, audit.log). Например, журнал СУБД показывает операцию в 15:00, а журнал ОС фиксирует отключение питания с 14:30 до 16:00 — операция не могла быть выполнена.
Аномалия MAC-времён файловой системы: Файлы журналов (ldf, WAL, binlog) имеют атрибуты $STANDARD_INFORMATION (обычно соответствует системному времени) и $FILE_NAME (более устойчивы к изменениям). Если эти два набора атрибутов не совпадают или противоречат внутренним временным меткам — возможна подделка.
Аномалия часов реального времени (RTC): При выключенном питании системное время хранится в RTC-чипе материнской платы. Если злоумышленник изменял время, то это отражается в журналах NTP (Network Time Protocol) — даже при ручном переводе служба NTP фиксирует резкий скачок.

Методика выявления аномалий (пошагово):

Шаг 1. Экспорт всех временных меток из журнала транзакций в табличный формат.
Шаг 2. Построение графика зависимости «порядковый номер транзакции (LSN) → datetime».
Шаг 3. Визуальный и статистический поиск выбросов и обратных участков.
Шаг 4. Сопоставление с журналами ОС (изъятыми с того же сервера).
Шаг 5. При подозрении — анализ целостности файлов журналов с помощью хэш-сумм (если контрольные суммы включены в СУБД).
Шаг 6. Формулирование вывода: «установлена аномалия, характерная для искусственной модификации временных меток» или «аномалий не выявлено, временные метки признаются достоверными».

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

Именно такие комплексные методы делают компьютерно-техническую экспертизу баз данных и СУБД наиболее эффективной в противодействии фальсификации.

Глава 8. Кейс №3: Экономический шпионаж и анализ несанкционированного копирования CRM-базы (MySQL)

Вводные данные: Компания «Цифровые технологии» (разработчик и дистрибьютор ПО для ритейла) обнаружила, что её главный конкурент «СофтМаркет» начал предлагать клиентам практически идентичные коммерческие условия, включая уникальные скидочные матрицы, которые являлись коммерческой тайной (ч. 1 ст. 1465 ГК РФ). 🤷‍♂️ Внутренний аудит показал, что три недели назад кто-то скопировал таблицы client_pricing, discount_matrix и contract_terms из базы данных CRM (MySQL 8.0). Сумма ущерба оценена в 87 миллионов рублей (упущенная выгода).

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

Имеются ли в исследуемых объектах следы копирования данных из CRM-базы?
Если да, то каким способом (команды SQL, pg_dump-аналоги, стороннее ПО) и в какое время производилось копирование?
Можно ли идентифицировать IP-адрес, учётную запись и рабочую станцию, с которой выполнялось копирование?

Ход исследования:

Этап 1. Анализ конфигурации MySQL. Эксперт проверил настройки аудита на сервере. К сожалению, плагин audit_log не был установлен, зато general_log был включён (что редкость, но в данном случае сыграло ключевую роль). Файл general.log содержал историю всех SQL-команд за последние 45 дней.

Этап 2. Анализ general.log. При просмотре обнаружена запись:
2024-09-17T02:15:33.123456Z 14 Query SELECT * FROM client_pricing INTO OUTFILE ‘/tmp/client_pricing.csv’ FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘»‘
Аналогичные команды для discount_matrix и contract_terms. Время выполнения — 02:15 ночи, что не является штатным временем резервного копирования (регламент — 01:00). 😴

*Этап 3. Анализ netflow и IP-адресов*. В логах MySQL зафиксирован идентификатор потока (Thread_id = 14). В системных журналах ОС (Linux) проведён поиск этого thread_id в логах соединений. Найден соответствующий TCP-сокет с удалённым IP-адресом 192.168.45.122 (внутренний IP). Обращение к логам DHCP-сервера показало, что в указанное время IP-адрес 192.168.45.122 был выдан MAC-адресу 00:1A:2B:3C:4D:5E. Этот MAC-адрес, согласно учётным записям Active Directory, принадлежит ноутбуку сотрудника отдела маркетинга Петрова В.И., который не имел права доступа к CRM-БД по своей должности.

Этап 4. Анализ удалённого файла /tmp/client_pricing.csv. Хотя злоумышленник удалил CSV-файл, эксперт с помощью анализа свободного пространства (задача «unallocated clusters») восстановил фрагменты файла. В частности, первая строка содержала имена столбцов и несколько первых клиентов. Сопоставление с оригиналом подтвердило, что это именно копия данных из CRM.

Этап 5. Анализ журналов доступа к файловой системе. В audit.log (auditd) обнаружены записи о чтении файлов /var/lib/mysql/crm_db/client_pricing.ibd в тот же временной интервал (02:15:33). Это означает, что злоумышленник использовал прямое SQL-копирование, а не низкоуровневую кражу файлов.ibd.

Выводы эксперта:

Факт копирования трёх таблиц, содержащих коммерческую тайну, установлен с абсолютной достоверностью.
Копирование осуществлено с помощью команд SELECT… INTO OUTFILE, выполненных в 02:15:33 17.09.2024.
Установлен IP-адрес (192.168.45.122), MAC-адрес (00:1A:2B:3C:4D:5E) и, с вероятностью, близкой к 0,99, рабочая станция сотрудника Петрова В.И. (ноутбук, закреплённый за ним). Вероятность обусловлена тем, что теоретически MAC-адрес мог быть подменён, но признаков подмены в логах коммутатора не обнаружено.

Процессуальный результат: Заключение эксперта легло в основу обвинительного заключения. Петров В.И. был признан виновным по ч. 3 ст. 183 УК РФ (незаконное разглашение коммерческой тайны с причинением крупного ущерба) и приговорён к 2 годам лишения свободы условно со штрафом 500 тыс. рублей. Конкурент «СофтМаркет» понёс гражданско-правовую ответственность в виде взыскания 87 млн рублей упущенной выгоды. 🏦

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

Глава 9. Особенности исследования NoSQL-баз данных: MongoDB, Cassandra, Redis

Хотя реляционные СУБД доминируют в корпоративном секторе, судебные эксперты всё чаще сталкиваются с нереляционными хранилищами. 🗃️ Каждая платформа имеет уникальные особенности с точки зрения криминалистического анализа.

9.1. MongoDB (документоориентированная)

Объекты исследования: файлы данных WiredTiger (.wt), журналы oplog.rs (в репликасетах), логи аудита (если включены).

Особенности:

Удалённые документы не сохраняются в журналах, если только не было включено аудирование на уровне коллекции.
Oplog — циклический буфер ограниченного размера (обычно 5% от дискового пространства). Если прошло много времени с момента инцидента, записи могут быть перезаписаны.
Восстановление удалённых документов возможно через анализ свободных экстентов в файлах.wt с помощью утилиты wt из состава WiredTiger (или коммерческих инструментов вроде MongoDB Forensic Toolkit).

Методика: (1) Создание дампа oplog: mongodump —oplog. (2) Анализ oplog на наличие операций delete и update. (3) Для удалённых записей без oplog — низкоуровневый парсинг.wt-файлов.

9.2. Apache Cassandra (колоночная БД)

Особенности:

Данные распределены по нескольким узлам (кластер). Эксперту необходимо изымать образы со всех узлов одновременно, так как на одном узле могут отсутствовать некоторые диапазоны.
Удаление записей маркируется tombstone (временная метка удаления). Tombstones хранятся до gc_grace_seconds (по умолчанию 10 дней), после чего удаляются физически при compaction.
Используемый формат SSTable (Sorted String Table) бинарный, но имеется утилита sstabledump.

Методика: (1) Изъятие всех каталогов данных Cassandra (обычно /var/lib/cassandra/data). (2) Выполнение nodetool flush для принудительной записи memtable на диск (по согласованию со следствием). (3) Анализ SSTable через sstabledump и поиск tombstone с временными метками.

9.3. Redis (key-value, in-memory)

Особенности:

Основные данные находятся в оперативной памяти. При выключении питания данные теряются, если не настроены RDB-дампы или AOF-файлы.
AOF (Append Only File) — текстовый лог всех команд (SET, DEL, HSET). Это идеальный объект для экспертизы.
RDB-дамп — бинарный снэпшот, можно анализировать инструментом redis-rdb-tools.

Методика: (1) При работающем сервере — выполнение SAVE или BGSAVE для создания RDB-дамп. (2) Анализ AOF-файла (если включён appendonly yes) — каждая команда имеет временную метку в микросекундах. (3) Восстановление удалённых ключей: если AOF включён и не перезаписан (BGREWRITEAOF), то удаление через DEL фиксируется, но предыдущее значение может быть извлечено из журнала.

Для всех NoSQL-систем действует общее правило: компьютерно-техническая экспертиза баз данных и СУБД должна проводиться экспертом, имеющим опыт работы именно с этой платформой, а не с реляционными СУБД. Нельзя механически переносить методы анализа журналов из мира SQL в мир NoSQL — это ведёт к грубым ошибкам. ⚠️

Глава 10. Процессуальные аспекты назначения и производства КТЭ БД

Для юристов и следователей критически важно правильно организовать процесс назначения экспертизы, чтобы её результаты были признаны допустимыми доказательствами. 🏛️

10.1. Основания назначения

В уголовном судопроизводстве (УПК РФ): ст. 195 (обязательное назначение экспертизы для установления причин смерти, характера тяжких телесных повреждений и т.д., а также для компьютерной информации — факультативно, но рекомендуется при наличии специальных знаний).
В гражданском и арбитражном процессе (ГПК РФ, АПК РФ): по ходатайству стороны или по инициативе суда (ст. 79 ГПК РФ, ст. 82 АПК РФ).

10.2. Содержание постановления/определения

Документ должен содержать:

Наименование суда/следователя.
Обстоятельства дела, обосновывающие необходимость экспертизы.
Перечень вопросов эксперту (неправовых, конкретных).
Наименование экспертного учреждения (Союз «Федерация судебных экспертов») или конкретного эксперта.
Перечень предоставляемых объектов (с указанием уникальных идентификаторов, хэш-сумм).

10.3. Права и обязанности эксперта

Эксперт вправе (ст. 57 УПК РФ, ст. 85 ГПК РФ):

Знакомиться с материалами дела, относящимися к предмету экспертизы.
Заявлять ходатайства о предоставлении дополнительных материалов.
Привлекать к производству экспертизы других экспертов (с уведомлением следователя/суда).
Отказаться от дачи заключения, если предоставленных материалов недостаточно.

Эксперт обязан:

Явиться по вызову.
Дать объективное заключение по поставленным вопросам.
Предупредиться об уголовной ответственности по ст. 307 УК РФ (ст. 307 УК — заведомо ложное заключение).

10.4. Оценка заключения судом

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

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

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

Глава 11. Регламент изъятия объектов: обеспечение сохранности доказательств

Нарушение правил изъятия цифровых носителей — наиболее частая причина признания экспертизы недопустимым доказательством. 📌 Приведём обязательный алгоритм для следователей и оперативных сотрудников (на основе «Порядка изъятия компьютерной информации», утверждённого Генеральной прокуратурой РФ 2017 г.):

Шаг 1. Фиксация состояния. Перед отключением сервера от электросети необходимо:

Сделать фотографии всех подключённых кабелей, индикаторов на корпусе.
Зафиксировать время по системным часам сервера (фото экрана с командой date в Linux или time /t в Windows).

Шаг 2. Живой сбор (live forensics). До отключения питания:

Выполнить дамп оперативной памяти (например, Belkasoft RAM Capturer, win32dd для Windows, LiME для Linux).
Записать список запущенных процессов (от SQL-сервера до вредоносного ПО).
Записать содержимое таблиц ARP и кэша DNS.

Шаг 3. Отключение и изъятие носителя. Сервер отключается штатно (если нет риска удаления данных) или принудительно (если есть подозрение на удалённое уничтожение). Носитель (HDD, SSD, NVMe) изымается, маркируется, упаковывается в антистатический пакет и опечатывается.

Шаг 4. Создание образа. В лабораторных условиях с помощью write-blocker создаётся посекторный образ в формате E01, AFF или raw (dd). Вычисляются хэш-суммы (MD5, SHA-1). Оригинал носителя возвращается на хранение в опечатанном виде.

Шаг 5. Передача эксперту. Образ на зашифрованном носителе (или через защищённый канал) передаётся эксперту вместе с процессуальным документом. Хэш-суммы сверяются.

Только при таком подходе компьютерно-техническая экспертиза баз данных и СУБД сможет быть проведена качественно, а её результаты — приняты судом. Если вы столкнулись с ситуацией, когда цифровые доказательства были изъяты с нарушениями, немедленно заявляйте ходатайство об их исключении из дела (ст. 75 УПК РФ, ст. 161 АПК РФ). 🛡️

Глава 12. Инструментарий эксперта: программно-аппаратные средства

Современная КТЭ БД невозможна без специализированного ПО. Перечислим основные категории (без указания конкретных торговых марок, но с пояснением функционала): 💻

12.1. Средства для создания образов и низкоуровневого доступа

Аппаратные write-blockers (например, Tableau, Atola, Logicube) — позволяют подключать накопитель в режиме «только чтение», исключая случайную модификацию.
Программные средства создания образов: Guymager (Linux, бесплатный), FTK Imager (Windows, условно-бесплатный), dd (стандартная утилита Linux). Обязательная фиксация хэшей.

12.2. Средства анализа файловых систем и поиска артефактов

X-Ways Forensics, EnCase Forensic, FTK — профессиональные платформы, позволяющие анализировать NTFS, ext4, APFS, восстанавливать удалённые файлы, искать по сигнатурам.

12.3. Специализированные инструменты для СУБД

Для MSSQL: ApexSQL Log, SysTools SQL Log Analyzer, а также собственные скрипты через fn_dblog.
Для PostgreSQL: pg_waldump, pg_resetwal, скрипты на PL/pgSQL для анализа системных таблиц.
Для MySQL: mysqlbinlog, Percona Toolkit (pt-online-schema-change, pt-query-digest), а также низкоуровневые hex-редакторы для файлов.ibd.
Для Oracle: Oracle LogMiner (встроенный пакет DBMS_LOGMNR), а также коммерческие решения типа AUL (Oracle Forensic Toolkit).

12.4. Средства анализа оперативной памяти

Volatility Framework — open-source, позволяет извлекать из RAM-дампов активные соединения с БД, SQL-запросы, несохранённые данные.

12.5. Скрипты собственной разработки (на Python, PowerShell, Bash)

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

Эксперт обязан указывать в заключении все использованные программные средства, их версии и источники получения (лицензия). Использование нелицензионного или непроверенного ПО может быть основанием для признания заключения недопустимым. 🔍

Глава 13. Типичные ошибки при производстве КТЭ БД и способы их выявления

Для судей, адвокатов и следователей полезно знать, на какие «красные флаги» обращать внимание в заключениях оппонентов, чтобы оспорить их. 🚩

Ошибка 1. Отсутствие методики. Заключение содержит фразы: «на основе опыта эксперта», «общеизвестный факт», «по нашему мнению». Научно обоснованная экспертиза должна ссылаться на конкретные методы (например, «восстановление проведено в соответствии с методикой, описанной в работе Иванова П.П. «Судебное исследование баз данных PostgreSQL», 2023»).

Ошибка 2. Несоответствие выводов объёму исследования. Эксперт исследовал только файл журнала за 1 час, но делает выводы о событиях за 3 месяца. Очевидное превышение пределов.

Ошибка 3. Использование инструментов без верификации. Указано название программы, но не её версия, не указано, сертифицирована ли она для судебной экспертизы. Например, использование стандартной утилиты grep для поиска в бинарных файлах без учёта кодировок может дать ложные срабатывания.

Ошибка 4. Логическая противоречивость. Выводы противоречат друг другу или здравому смыслу. Например: «Файлы базы данных были удалены 01.01.2024, но последняя запись в журнале транзакций датирована 10.01.2024» — так не бывает.

Ошибка 5. Выход за пределы компетенции. Эксперт делает выводы о виновности, мотиве, психическом состоянии лица. Это абсолютно недопустимо.

При обнаружении таких ошибок сторона вправе ходатайствовать о признании заключения ненадлежащим доказательством и о назначении повторной компьютерно-технической экспертизы баз данных и СУБД в нашем Союзе. 📑

Глава 14. Будущее КТЭ БД: искусственный интеллект, блокчейн и облачные вычисления

Технологии развиваются, и эксперты должны быть готовы к новым вызовам. 🚀

14.1. Облачные БД (Amazon RDS, Google Cloud SQL, Microsoft Azure SQL). Эксперт не имеет физического доступа к серверу. Исследование возможно только через API и бэкапы. Важно требовать от облачного провайдера предоставления:

Снимков (снапшотов) дисков на момент инцидента.
Логов аудита (CloudTrail, audit logs).
Информации о всех подключениях (IP, времена, длительность).

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

14.2. Блокчейн—платформы (Ethereum, Hyperledger Fabric). Хотя сам блокчейн считается неизменяемым, эксперту могут быть предоставлены не все узлы сети. Задача — установить консенсусную истинность данных. Также анализируются state DB (обычно LevelDB/RocksDB) на узлах — они могут быть модифицированы локально.

14.3. Искусственный интеллект и машинное обучение. С одной стороны, AI используется для автоматизации анализа больших массивов журналов (аномалий в SQL-запросах). С другой стороны, злоумышленники могут использовать генеративные нейросети для синтеза поддельных логов, неотличимых от реальных. Экспертам придётся осваивать методы статистического обнаружения синтетических данных (например, анализ распределения временных интервалов между транзакциями).

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

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

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

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

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

Мы приглашаем всех участников судопроизводства — судей, следователей, адвокатов, юристов компаний — к сотрудничеству. Наш Союз гарантирует:

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

Узнать подробнее о порядке заказа экспертизы, задать вопросы специалистам и ознакомиться с полным перечнем услуг можно на официальном сайте: https://kriminalist77.ru/ekspertiza-baz-dannyh/

Доверьте цифровую истину профессионалам. 🟩