ВВЕДЕНИЕ: ЭКСПЕРТИЗА КАК ПРОЦЕССУАЛЬНО-ТЕХНИЧЕСКИЙ КОМПЛЕКС

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

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

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

ЭТАП 1: ПРОЦЕССУАЛЬНОЕ ИНИЦИИРОВАНИЕ И ПОСТАНОВКА ЗАДАЧ

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

Предоставление материалов. Эксперту передается:

• Криминалистическая копия носителя информации с базой данных (с фиксацией хэш-сумм MD5/SHA-256).
• Протоколы изъятия, осмотра носителей.
• При наличии — документация на ПО, учетные данные для доступа.
• Материалы дела, относящиеся к предмету экспертизы (договоры, рекламные проспекты, показания).

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

ЭТАП 2: ПОДГОТОВИТЕЛЬНЫЙ (ОРГАНИЗАЦИОННО-ТЕХНИЧЕСКИЙ)

Создание изолированной экспертной среды. Развертывание на отдельном, не связанном с сетью компьютере необходимого ПО:

• Аппаратно-программный комплекс (АПК) для работы с цифровыми копиями (Tableau, FTK Imager).
• Соответствующая СУБД (MS SQL Server Developer, PostgreSQL, MySQL) для восстановления дампов.
• Инструменты для анализа (IDE для БД — DBeaver, DataGrip; средства для просмотра логов).
• Верификация и подготовка объекта исследования.
• Проверка целостности копии путем сравнения хэш-сумм.
• Определение типа и версии исходной СУБД по файлам или описанию.

Ключевое решение: Выбор способа доступа к данным:

• Восстановление файлов БД в СУБД (присоединение .mdf/.ldf, монтирование ibdata) — дает полный доступ к системным представлениям.
• Работа с дампом в виде SQL-скриптов — обеспечивает логическую целостность.
• Прямой парсинг бинарных файлов БД (для SQLite, например, через специализированные утилиты) — применяется, когда восстановление в СУБД невозможно.
• Создание рабочей копии. Все исследования проводятся только с рабочей копией, созданной от криминалистической. Исходная копия хранится в неизменном виде.

ЭТАП 3: ЭКСПЕРИМЕНТАЛЬНЫЙ (ИССЛЕДОВАТЕЛЬСКИЙ) АНАЛИЗ

Это основной этап, реализуемый циклически: выдвижение гипотезы → проверка запросами/анализом кода → интерпретация результатов.

Структурный анализ (Метаданные). Исследование схемы БД: списка таблиц, их полей, типов данных, первичных и внешних ключей. Построение ER-диаграммы.

Содержательный анализ (Данные). Выборочное и сплошное изучение содержимого таблиц. Определение семантики полей (что на практике означают значения status=5, type=’A’).

Анализ бизнес-логики. Изучение программных объектов: хранимых процедур, функций, триггеров, представлений. Реконструкция алгоритмов.

Анализ пользовательской активности. Исследование таблиц пользователей, журналов аудита, временных меток (created_at, updated_at).

Статистический и аналитический синтез. Выполнение комплексных SQL-запросов для агрегации данных, построения рейтингов, выявления связей и паттернов.

ЭТАП 4: СИНТЕТИЧЕСКИЙ (ОЦЕНОЧНЫЙ)

Сопоставление и интеграция данных. Объединение результатов всех линий анализа. Например, сопоставление алгоритма начисления процентов (из кода процедуры) с реальными данными в таблице транзакций и данными из рекламных материалов дела.

Формулировка промежуточных выводов по каждому поставленному вопросу.

Проверка выводов на непротиворечивость и полноту.

ЭТАП 5: ЗАКЛЮЧИТЕЛЬНЫЙ (ОФОРМЛЕНИЕ РЕЗУЛЬТАТОВ)

Составление заключения эксперта в соответствии со ст. 204 УПК РФ.

Структура заключения:

Вводная часть: основания, вопросы, материалы.

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

Выводы: четкие, последовательные ответы на вопросы.

Приложения: Скрипты SQL, диаграммы, выдержки из логов, ER-диаграммы — всё, что иллюстрирует ход исследования.

РАЗДЕЛ 2: СПЕЦИАЛЬНЫЕ МЕТОДИКИ, ПРИМЕНЯЕМЫЕ В ХОДЕ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

МЕТОДИКА 1: СТРУКТУРНО-СЕМАНТИЧЕСКОГО АНАЛИЗА (ССА)

Назначение: Восстановление логической схемы данных и её смыслового наполнения.

Процедура:

• Запрос к системным каталогам СУБД (sys.tables, INFORMATION_SCHEMA.COLUMNS).
• Автоматизированное построение ER-диаграммы с помощью инструментов реверс-инжиниринга.
• Контент-анализ значений в ключевых полях для расшифровки справочников (SELECT DISTINCT status FROM clients).
• Результат: Карта данных (Data Map) с аннотациями.

МЕТОДИКА 2: АНАЛИЗА ПРОГРАММНЫХ ОБЪЕКТОВ (АПО)

Назначение: Реконструкция бизнес-логики и автоматизированных процессов.

Процедура:

• Извлечение исходного кода объектов (SELECT definition FROM sys.sql_modules).
• Синтаксический разбор и декомпозиция кода. Выявление:
• Ключевых таблиц-источников и приемников.
• Математических и логических формул.
• Условий срабатывания (в триггерах).
• Создание блок-схем алгоритмов для сложных процедур.
• Результат: Описание механизма функционирования системы в виде алгоритмов.

МЕТОДИКА 3: ТРАНЗАКЦИОННО-ВРЕМЕННОГО АНАЛИЗА (ТВА)

Назначение: Установление хронологии событий, выявление аномальных паттернов активности.

Процедура:

• Выявление всех полей с временными метками.
• Построение временных рядов (графиков) по ключевым метрикам: объем входящих транзакций, количество регистраций, активность пользователей.
• Корреляционный анализ событий (например, массовое начисление процентов -> всплеск выводов средств).
• Анализ журналов транзакций СУБД для восстановления истории изменений (использование fn_dblog в MS SQL).

Результат: Временная линия событий и выявленные статистические аномалии.

МЕТОДИКА 4: СЕТЕВОГО И КОРРЕЛЯЦИОННОГО АНАЛИЗА (СКА)

Назначение: Выявление скрытых связей между клиентами, менеджерами, счетами.

Процедура:

• Построение графов связей «клиент-менеджер», «отправитель-получатель перевода».
• Применение алгоритмов кластеризации для выявления групп.
• Расчет сетевых метрик (центральность узла) для определения ключевых фигур в системе.
• Поиск цикличных транзакций (A->B->C->A).

Результат: Визуализированные схемы взаимосвязей, списки аффилированных лиц.

МЕТОДИКА 5: ВЕРИФИКАЦИИ ВНЕШНИХ ДАННЫХ И ИНТЕГРАЦИЙ

Назначение: Установление наличия/отсутствия связи БД с реальными рыночными данными или внешними сервисами.

Процедура:

• Поиск в структуре БД таблиц с котировками, курсами валют.
• Анализ кода процедур на наличие HTTP-запросов, вызовов внешних API (по ключевым словам).
• Проверка конфигурационных файлов и таблиц настроек на наличие ключей API, URL внешних служб.

Результат: Заключение о степени изолированности системы или её интеграции с внешним миром.

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

КЕЙС 1: ФИНАНСОВАЯ ПИРАМИДА («ИНВЕСТИЦИОННЫЙ КЛУБ»)

Поставленные вопросы: Какова логика начисления «доходов»? Есть ли привязка к реальным активам? Каков объем привлеченных средств и круг основных вкладчиков?

Процедура и находки:

ССА: Выявлены таблицы investors, transactions, daily_profit.

АПО: В процедуре apply_daily_profit обнаружен алгоритм: UPDATE investors SET balance = balance * 1.015 WHERE rank > 3. Ключ: Начисление зависит от ранга (уровня в сети), а не от рыночных данных.

ТВА: График показал экспоненциальный рост привлечений перед коллапсом.

СКА: Построена иерархическая сеть по полю referrer_id. Выделены топ-10 агентов по привлечению.

Верификация: Таблиц котировок не обнаружено. В коде нет ссылок на финансовые API.

Вывод: Система реализует пирамидальную схему с сетевым маркетингом, начисления носят виртуальный характер.

КЕЙС 2: МОШЕННИЧЕСТВО С ИСПОЛЬЗОВАНИЕМ ПЛАТЕЖНОГО СЕРВИСА

Вопросы: Каким образом происходило списание средств со счетов клиентов? Какова роль администраторов?

Процедура и находки:

АПО: Обнаружен триггер on_payment_success, который после успешного платежа из внешней системы запускал процедуру internal_fee, списывающую дополнительную «комиссию» на внутренний счет компании.

ТВА: Анализ логов аудита показал, что размер комиссии (fee_percent) менялся администратором (admin_login) вручную через интерфейс, а изменения логировались в отдельную скрытую таблицу config_changes.

ССА: Найдена таблица hidden_fee_accounts, куда аккумулировались эти средства, не отраженные в публичных отчетах.

Вывод: Установлен технический механизм скрытого незаконного списания средств и доказаны целенаправленные действия администратора по его настройке.

КЕЙС 3: ЛЕГАЛИЗАЦИЯ ПРЕСТУПНЫХ ДОХОДОВ ЧЕРЕЗ ОНЛАЙН-КАЗИНО

Вопросы: Имеются ли в БД признаки подделки игровых результатов? Можно ли выделить клиентов с аномально высокими «выигрышами»?

Процедура и находки:

АПО: Процедура game_roll содержала вызов генератора случайных чисел, но его начальное значение (seed) задавалось не от аппаратного источника, а из таблицы seed_control, куда администратор мог вписать заранее известное значение.

СКА: Найдены клиенты, у которых в 100% случаев значение seed для их игровой сессии соответствовало значению из seed_control. Их выигрыши были на порядки выше среднего.

ТВА: Выявлены паттерны: зачисления крупных сумм от «выигравших» клиентов на счета подставных фирм в один день с последующим выводом.

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

КЕЙС 4: НЕЗАКОННОЕ ПРЕДПРИНИМАТЕЛЬСТВО (НЕЛИЦЕНЗИРОВАННАЯ МФО)

Вопросы: Каков реальный размер предоставленных займов и начисленных процентов? Соответствует ли алгоритм расчета требованиям закона о потребительском кредите?

Процедура и находки:

ССА: Обнаружены таблицы loans, payments, penalties.

АПО: В функции calculate_penalty выявлена формула, начисляющая сложный процент на просроченную сумму и тело займа, что в несколько раз превышает разрешенную законом неустойку.

ТВА: Статистический расчет показал, что эффективная процентная ставка (ЭПС) по всем договорам превышала 500% годовых.

Сформирован полный реестр заемщиков с детализацией нарушений.

Вывод: Установлен системный характер нарушения норм права, расчетным путем определен размер незаконно начисленных процентов.

КЕЙС 5: ВНУТРЕННИЙ САБОТАЖ И УНИЧТОЖЕНИЕ ДОКАЗАТЕЛЬСТВ

Вопросы: Производилось ли удаление данных накануне проверки? Кто из пользователей инициировал эти операции?

Процедура и находки:

ТВА: Анализ временных меток в таблице transactions выявил отсутствие записей за последние 3 дня перед изъятием сервера, в то время как журнал приложений показывал активную работу.

Исследование журнала транзакций СУБД: С помощью утилиты чтения лога (fn_dblog, mysqlbinlog) найдены записи LOP_DELETE_ROWS, относящиеся к критическим таблицам, выполненные за 2 часа до изъятия.

Анализ пользовательской активности: В журнале подключений СУБД зафиксирован вход под учетной записью sa (admin) с IP-адреса офиса в момент, соответствующий удалению.

АПО: Обнаружена процедура purge_old_data, но время ее вызова не соответствовало времени удаления.

Вывод: Установлен факт целенаправленного удаления данных вручную с высокой долей вероятности конкретным администратором.

РАЗДЕЛ 4: ПРИМЕРНЫЙ ПЕРЕЧЕНЬ ВОПРОСОВ, СТАВЯЩИХСЯ НА РАЗРЕШЕНИЕ ЭКСПЕРТА

Блок А: Вопросы общего характера об объекте

Какова тип, версия и конфигурация системы управления базами данных, в которой функционирует представленный объект?

Какова общая логическая структура (схема) базы данных: перечень основных таблиц, их назначение и взаимосвязь?

Каков временной период, охватываемый записями в базе данных, и её общий информационный объем?

Блок Б: Вопросы о содержании информации
4. Какую информацию о клиентах (физических/юридических лицах) содержит база данных (персональные данные, идентификаторы, статусы)?
5. Какую информацию о финансово-хозяйственных операциях (транзакциях) содержит база данных (тип, дата, время, сумма, стороны, назначение)?
6. Какие сведения о договорных отношениях (договорах, счетах, тарифах) зафиксированы в базе данных?
7. Содержит ли база данных биржевые котировки, данные о ценных бумагах, курсах валют или иную внешнюю экономическую информацию? Если да, то какова её природа и источник обновления?

Блок В: Вопросы о бизнес-логике и алгоритмах
8. Каковы функциональное назначение и логика работы выявленных хранимых процедур, функций и триггеров?
9. Какой конкретный алгоритм (формула, последовательность действий) используется для начисления процентов (доходности, бонусов, штрафов) на средства клиентов?
10. Какие автоматизированные процессы, влияющие на состояние счетов клиентов, заложены в базу данных, и по каким правилам (расписанию, условиям) они выполняются?

Блок Г: Вопросы о пользователях и активности
11. Какие учетные записи пользователей, роли и права доступа зарегистрированы в системе?
12. Имеется ли в базе данных информация о действиях пользователей (журналы аудита, истории изменений, логи подключений)? Если да, то какие действия, кем и когда совершались?
13. Возможно ли выделить периоды аномально высокой или низкой активности в системе?

Блок Д: Вопросы аналитического и расчетного характера
14. Возможно ли определить общий объем денежных средств, внесенных клиентами в систему, и общий объем средств, выведенных из системы, за указанный период?
15. Возможно ли сформировать перечень клиентов, внесших максимальные (топ-10, топ-20) и изъявших максимальные суммы, с указанием этих сумм?
16. Имеются ли в данных признаки внутреннего движения средств между клиентами (трансферы) без вывода вовне? Если да, то можно ли выделить цепочки таких переводов?
17. Соответствует ли алгоритм начисления процентов, реализованный в базе данных, условиям, указанным в договорах с клиентами (или рекламных материалах, предоставленных для исследования)?

Блок Е: Вопросы о целостности и модификации данных
18. Обнаружены ли признаки удаления или существенной модификации записей в ключевых таблицах в определенные периоды времени?
19. Сохраняет ли база данных историю изменений ключевых настроек (например, процентных ставок)?

ЗАКЛЮЧЕНИЕ: КРИТЕРИИ КАЧЕСТВА ПРОВЕДЕННОЙ ЭКСПЕРТИЗЫ

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

• Процессуальная безупречность: Строгое соблюдение процедуры изъятия, фиксации и исследования.
• Методическая обоснованность: Применение апробированных, научно обоснованных методик, соответствующих объекту и задачам.
• Полнота: Исследование всех значимых аспектов БД (структура, данные, код, логи).
• Документированность и воспроизводимость: Любой вывод должен быть подтвержден конкретными данными, запросами, скриншотами, позволяющими проверить ход рассуждений эксперта.
• Ясность и адресность выводов: Выводы должны непосредственно и однозначно отвечать на поставленные вопросы, избегая избыточной технической сложности, но сохраняя научную точность.

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