СУДЕБНАЯ ЭКСПЕРТИЗА БАЗ ДАННЫХ В УГОЛОВНОМ СУДОПРОИЗВОДСТВЕ: ПОЛНЫЙ АЛГОРИТМ ОТ ИЗЪЯТИЯ ДО ЗАКЛЮЧЕНИЯ

ВВЕДЕНИЕ

Экспертиза базы данных (БД) — это сложный процессуальный акт, требующий строгого соблюдения как норм уголовно-процессуального закона, так и специальных методик цифровой криминалистики. Её результатом является заключение эксперта — самостоятельное доказательство по делу (ст. 80 УПК РФ). Настоящая статья детально регламентирует поэтапную процедуру проведения такой экспертизы, предоставляя следователю, эксперту и суду четкий алгоритм действий для обеспечения законности, обоснованности и достоверности выводов.

РАЗДЕЛ 1. ПРОЦЕДУРНЫЕ ЭТАПЫ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

1.1. Подготовительный этап (до назначения экспертизы).

Инициация. Осознание следователем того, что БД является ключевым носителем информации. Обычно это происходит после выявления у потерпевших доступа к веб-интерфейсу, получению «личных кабинетов», автоматических выписок.
Привлечение специалиста. Для грамотного изъятия носителей информации (серверов, винчестеров, облачных бекапов) на месте обыска или выемки необходимо присутствие специалиста в области IT и СУБД (ст. 168 УПК РФ). Его задача — помочь:
- Идентифицировать все компоненты системы хранения данных.
- Безопасно обесточить оборудование для сохранения данных в оперативной памяти (при необходимости).
- Изъять аппаратные средства и носители с соблюдением цепочки custody.

1.2. Этап изъятия и обеспечения сохранности цифровых следов.
Критически важный этап, ошибки на котором фатальны.

Фиксация контекста: Фото- и видеофиксация исходного состояния оборудования, кабельных соединений, индикаторов.
Изъятие носителей:
- Физические серверы/ПК: Изъятие всего системного блока или, в идеале, всего сервера. Маркировка всех извлекаемых жестких дисков (HDD/SSD), указание их расположения в RAID-массиве.
- Виртуальные серверы: Получение доступа к гипервизору (VMware vSphere, Hyper-V) и изъятие файлов виртуальных машин (.vmdk, .vhdx) вместе с файлами конфигурации.
- Облачные БД: Немедленное направление юридически оформленного запроса провайдеру (Amazon AWS, Google Cloud, Microsoft Azure, Yandex.Cloud) на блокировку аккаунта и предоставление полной копии БД (snapshot) и логов. Это единственный способ получить данные, минуя физический носитель.
Создание криминалистической копии (образ): Все последующие действия проводятся ТОЛЬКО с копией. Используются аппаратные или программные блокираторы записи (write-blockers). Создается посекторная копия носителя (образ в формате E01, dd, AFF). Обязательно вычисление и документация криптографических хэш-сумм (MD5, SHA-1, SHA-256) как оригинала, так и копии для последующего доказательства их тождества.
Оформление протокола: В протоколе выемки/обыска должны быть детально описаны все изъятые предметы, их серийные номера, состояние, а также примененные методы обеспечения сохранности данных.

1.3. Этап назначения экспертизы.
Следователь выносит постановление (ст. 195 УПК РФ), в котором:

Обосновывает необходимость экспертизы.
Формулирует вопросы эксперту. Вопросы должны быть конкретными, технически грамотными и соответствовать специальным знаниям эксперта. (Примерный перечень — в Разделе 4 данной статьи).
Предоставляет материалы: 1) Криминалистическую копию носителя с БД; 2) Документацию, если она была изъята; 3) Возможно, логи веб-сервера; 4) Постановление.

1.4. Этап организации и проведения исследований (работа эксперта).

Предварительное исследование: Эксперт оценивает объем и характер представленных данных, определяет тип СУБД (MySQL, PostgreSQL, MS SQL Server, Oracle, MongoDB), планирует ход исследования.
Восстановление работоспособности БД в изолированной среде: Эксперт разворачивает виртуальную машину с аналогичной ОС и версией СУБД. Восстанавливает БД из дампа или подключает файлы данных. Важно: среда должна быть изолирована от сети (air-gapped), чтобы исключить случайную модификацию или утерю данных.
Проведение исследований по методикам (см. Раздел 2). Эксперт последовательно применяет методики, отвечая на поставленные вопросы. Все действия документируются: записываются выполняемые SQL-запросы, делаются скриншоты, выводы промежуточных результатов.
Анализ полученных данных: Систематизация и анализ информации, полученной на предыдущем шаге. Построение сводных таблиц, графиков, диаграмм взаимосвязей.

1.5. Этап формулирования выводов и составления заключения.

Структура заключения должна соответствовать требованиям ст. 204 УПК РФ и включать:
1. Вводная часть: Основание, данные об эксперте, вопросы.
2. Исследовательская часть: Самая объемная. Подробное описание всех действий: какая БД обнаружена, её структура, проведенный анализ данных, исследованные процедуры, изученные журналы. Здесь же приводятся выявленные факты (например: «В результате анализа хранимой процедуры accrue_profit установлено, что начисление дохода производится по фиксированной ставке 1% в день от остатка на счете»).
3. Выводы: Четкие, последовательные ответы на каждый поставленный вопрос. Выводы должны вытекать из исследовательской части и не содержать правовой оценки (например, эксперт констатирует факт отсутствия записей о реальных биржевых сделках, но не пишет «деятельность являлась мошеннической»).

РАЗДЕЛ 2. МЕТОДИКИ ПРОВЕДЕНИЯ ИССЛЕДОВАНИЙ В РАМКАХ ЭКСПЕРТИЗЫ

2.1. Методика структурно-функционального анализа.

Цель: Восстановление схемы данных и понимание назначения объектов.
Действия:
1. Анализ метаданных СУБД (системных таблиц INFORMATION_SCHEMA, pg_catalog, sys).
2. Составление перечня таблиц, представлений, хранимых процедур, функций, триггеров.
3. Построение ER-диаграммы (сущность-связь) для визуализации структуры.
4. Анализ именования объектов (номенклатура может указывать на назначение: pyramid_payout, fake_quote_generator).

2.2. Методика анализа фактических данных (контент-анализ).

Цель: Получение количественных и качественных характеристик деятельности.
Действия:
1. Определение объема данных (количество записей в ключевых таблицах).
2. Выборка и анализ записей-образцов для понимания формата.
3. Выполнение агрегирующих SQL-запросов для подсчета сумм, количества клиентов, дат первой и последней операции.
4. Построение временных рядов (обороты по дням).
5. Сегментация клиентов (топ-20 по вкладам, топ-20 по выводам).

2.3. Методика реверс-инжиниринга бизнес-логики.

Цель: Установление алгоритмов функционирования системы.
Действия:
1. Получение исходного кода всех хранимых процедур и функций.
2. Декомпозиция кода: анализ переменных, условий, циклов, формул расчета.
3. Сопоставление логики процедур с данными в таблицах (например, сравнение результата работы процедуры начисления с фактическими записями в таблице transactions).
4. Анализ триггеров: какие события запускают автоматические действия.

2.4. Методика анализа журналов и аудита (форензик-анализ).

Цель: Установление действий конкретных пользователей и администраторов системы.
Действия:
1. Поиск и анализ специализированных таблиц аудита внутри БД.
2. Исследование встроенных механизмов журналирования СУБД (бинарные логи MySQL, WAL PostgreSQL, журналы транзакций MS SQL).
3. Анализ таблиц истории входов (login_history), если они ведутся.
4. Корреляция событий по времени (например, запуск процедуры начисления → массовая рассылка email-уведомлений).

2.5. Методика верификации внешних данных.

Цель: Проверка достоверности данных внутри БД (особенно для псевдоброкерских систем).
Действия:
1. Идентификация источника данных о котировках, курсах валют.
2. Сравнение внутренних данных с официальными историческими данными бирж или ЦБ РФ.
3. Анализ периодичности и правдоподобности обновления данных.

РАЗДЕЛ 3. ПРАКТИЧЕСКИЕ КЕЙСЫ ПРОВЕДЕНИЯ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

Кейс 1: Финансовая пирамида под видом инвестиционного клуба.

Обстоятельства: Компания «XYZ Капитал» привлекала средства под 5% в месяц, обещая торговлю на Форекс.
Действия эксперта:
1. Обнаружена БД с таблицами investors, transactions, referral_bonus.
2. Методика 2: Анализ показал 5000 клиентов, оборот 200 млн руб. Топ-20 вкладчиков внесли 40% средств.
3. Методика 3: Процедура calculate_daily_profit начисляла проценты по формуле сумма * 0.05 / 30. Ссылок на API брокеров нет. Процедура pay_referral перечисляла 10% от вклада новичка пригласившему.
4. Методика 4: В логах найдены команды DELETE FROM transaction_log WHERE date < ‘2023-01-01’, выполняемые ежемесячно.
Выводы экспертизы: Система автоматически начисляла фиксированный доход и реферальные бонусы. Данные о торговых операциях на финансовых рынках отсутствуют. Регулярно производилась очистка журналов.

Кейс 2: Псевдоброкерская платформа с имитацией торгов.

Обстоятельства: Платформа «CryptoTrade» предлагала торговлю криптовалютой с «гарантированной» доходностью.
Действия эксперта:
1. Обнаружены таблицы users, wallets, orders, trades, crypto_prices.
2. Методика 5: Данные в crypto_prices обновлялись раз в сутки и не соответствовали волатильности реального рынка (резкие скачки отсутствовали).
3. Методика 3: Процедура match_orders формировала «сделки» не по лучшей рыночной цене, а в диапазоне ±0.5% от последней загруженной котировки, что технически невозможно на реальной бирже.
4. Методика 2: Анализ trades показал, что 95% клиентов за 2 месяца получили «прибыль» от 3% до 8%, что статистически невероятно.
Выводы экспертизы: Торговый движок платформы использовал устаревшие и сглаженные котировки для симуляции торгов. Результаты «сделок» не соответствуют реальной рыночной модели и носят признаки генерации.

Кейс 3: Система структурирования денежных средств (обналичивание).

Обстоятельства: Расследование деятельности фирм-«однодневок».
Действия эксперта:
1. В БД бухгалтерской программы обнаружены таблицы invoices, payments, counterparties.
2. Методика 2: Анализ payments выявил тысячи транзакций на суммы, чуть ниже 600 000 руб. (порог контроля). Частые повторяющиеся суммы.
3. Методика 4: Логи БД показали массовое создание фиктивных накладных (invoices) одним пользователем в ночное время.
4. Методика 1: Обнаружена скрытая таблица temp_agents, не связанная с основной схемой, содержащая списки физических лиц и номера карт.
Выводы экспертизы: БД использовалась для формирования фиктивного документооборота и проведения целенаправленных платежей на карты физических лиц в обход установленных лимитов, что характерно для операции структурирования.

Кейс 4: Взлом и неправомерный доступ к БД интернет-магазина.

Обстоятельства: Утечка персональных данных и данных карт клиентов.
Действия эксперта:
1. Получены копии БД и логов веб-сервера.
2. Методика 4: Анализ логов СУБД выявил аномальные запросы SELECT * FROM users и SELECT * FROM orders с IP-адреса, не принадлежащего администраторам, в 03:00 ночи.
3. Методика 2: Сравнение двух дампов БД, сделанных до и после инцидента, показало создание новой учетной записи с правами администратора.
4. Методика 3: Изучение триггеров выявило подозрительный триггер, который при каждом новом заказе отправлял его данные на внешний email-адрес.
Выводы экспертизы: Установлен факт несанкционированного доступа извне, способ (SQL-инъекция, судя по логам веб-сервера), время и объем похищенных данных (все пользователи за период).

Кейс 5: Конфликт в IT-стартапе: хищение баз данных клиентов и алгоритмов.

Обстоятельства: Уволенный IT-директор скопировал и удалил основную БД.
Действия эксперта:
1. Исследование рабочей станции уволенного сотрудника и корпоративного сервера.
2. Методика 4: На сервере в логах резервного копирования обнаружена попытка удаления последнего бекапа. В журналах ОС рабочей станции найдены записи о подключении внешнего SSD-накопителя и копировании на него файлов .sql.
3. Методика 1 и 2: На внешнем накопителе найдена полная копия БД со всеми таблицами клиентов (leads, conversions) и исходным кодом уникальных алгоритмов машинного обучения (ml_models).
4. Методика 4: Анализ логов Git выявил, что перед увольнением пользователь сделал git push всей кодовой базы в свой приватный репозиторий.
Выводы экспертизы: Установлен факт копирования и попытки уничтожения БД и исходного кода, способ и средства совершения действий, а также объем похищенной информации.

РАЗДЕЛ 4. ПРИМЕРНЫЕ ВОПРОСЫ, СТАВЯЩИЕСЯ НА РАЗРЕШЕНИЕ ЭКСПЕРТА

Блок А: Вопросы об архитектуре и общих характеристиках.

Какая система управления базами данных (СУБД) и её версия использовались для создания и функционирования представленной базы данных?
Какова общая структура базы данных: перечислите пользовательские таблицы, представления (view), хранимые процедуры (stored procedures) и функции?
Каковы ключевые взаимосвязи между таблицами (первичные и внешние ключи)? Представьте схему данных.
Каково назначение базы данных, исходя из анализа её структуры и содержимого?

Блок Б: Вопросы о данных и бизнес-логике.
5. Какая информация содержится в таблицах, относящихся к клиентам и их финансовым операциям (вклады, выводы, начисления)?
6. Каков общий объем привлеченных и выведенных денежных средств, зафиксированный в базе данных за период с [ДАТА] по [ДАТА]?
7. Каков алгоритм (формула) начисления процентов (дохода) на счета клиентов, реализованный в хранимых процедурах или иным способом? От каких параметров он зависит (срок, сумма, активность других клиентов)?
8. Содержит ли база данных актуальные биржевые данные (котировки ценных бумаг, валютные пары)? Если да, то какова их периодичность обновления и источник?
9. Реализованы ли в базе данных механизмы реферальных (партнерских) начислений? Если да, опишите их логику.

Блок В: Вопросы о пользователях и действиях.
10. Какие учетные записи пользователей (логины) имели привилегированный доступ (права на изменение данных, выполнение ключевых процедур) к базе данных?
11. Имеется ли в базе данных журнал (логи) входов пользователей и/или журнал выполненных операций (DML-аудит)? Если да, то какие действия, кем и когда совершались в период [ДАТА] — [ДАТА]?
12. Подключалась ли данная база данных к каким-либо внешним сервисам (API платежных систем, бирж, email-рассылки)? Если да, то к каким и с какой целью?

Блок Г: Вопросы для конкретных кейсов.
13. (Для пирамид) Имеется ли взаимосвязь между суммой начисленного дохода конкретному клиенту и объемом средств, привлеченных им от других клиентов (реферальная сеть)?
14. (Для псевдоброкеров) Соответствуют ли записи о «сделках» (таблицы trades, orders) реальным биржевым данным за соответствующий период времени?
15. (Для дел о хищении) Имеются ли в системных или прикладных журналах следы копирования, удаления или модификации базы данных в период около [ДАТА УВОЛЬНЕНИЯ/ИНЦИДЕНТА]? Каковы источник и направление этих действий?

ЗАКЛЮЧЕНИЕ

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