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

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

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

Экспертиза баз данных – это не спонтанный поиск информации, а строго регламентированный, методичный процесс, основанный на научных принципах и криминалистических рекомендациях. От четкого следования процедуре напрямую зависит доказательственная сила заключения, его объективность, полнота и защищенность от критики в суде. Настоящая статья систематизирует этот процесс, представляя его в виде детального алгоритма, подкрепленного конкретными методиками и иллюстрированного реальными случаями из экспертной практики.

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

ЭТАП 0. ПРОЦЕССУАЛЬНО-ОРГАНИЗАЦИОННЫЙ (ПОДГОТОВИТЕЛЬНЫЙ)

1.1. Основание для начала работы: Получение постановления следователя (определения суда) с приложенными материалами.

1.2. Изучение постановления: Тщательный анализ поставленных вопросов, оценка их исполнимости, определение необходимого объема специальных познаний. При необходимости – заявление ходатайства о предоставлении дополнительных материалов или уточнении вопросов.

1.3. Формирование рабочей гипотезы и плана исследования: На основе вопросов и первичных данных о деле эксперт формулирует предварительные гипотезы (например, «БД реализует схему Понци») и составляет план их проверки.

ЭТАП 1. КРИМИНАЛИСТИЧЕСКАЯ ПОДГОТОВКА ОБЪЕКТА ИССЛЕДОВАНИЯ

1.1. Получение и верификация цифровых носителей: Фиксация хэш-сумм (MD5, SHA-256) полученных файлов. Сверка с протоколом изъятия.

1.2. Создание рабочей копии и изолированного окружения:

Восстановление БД из резервной копии (.bak, pg_dump) или подключение файлов данных (.mdf, .ibd) к тестовому экземпляру СУБД, развернутому на виртуальной машине или в Docker-контейнере.

Критическое правило: Работа только с копией. Исходные носители помещаются в сейф (электронное хранилище).

1.3. Документирование исходного состояния: Скриншоты, запись версии СУБД, сбор системной информации. Создание первой резервной точки (snapshot виртуальной машины).

ЭТАП 2. ПРЕДВАРИТЕЛЬНЫЙ (ОБЗОРНЫЙ) АНАЛИЗ

2.1. Определение типа и версии СУБД.

2.2. Получение перечня всех объектов БД: Таблицы, представления, процедуры, функции, триггеры. Использование системных каталогов (sys.tables, INFORMATION_SCHEMA).

2.3. Оценка общего объема и структуры данных: Количество записей в ключевых таблицах, временной диапазон данных.

ЭТАП 3. ДЕТАЛЬНОЕ ИССЛЕДОВАНИЕ (ПО ГЛУБИННЫМ НАПРАВЛЕНИЯМ)

3.1. Направление А: Анализ схемы данных и метаданных. Построение ER-диаграммы, анализ связей, индексов, ограничений целостности.

3.2. Направление Б: Семантический анализ содержимого. Выборка, фильтрация, агрегация данных. Формирование сводных отчетов по клиентам, операциям, договорам. Проверка справочников (котировки, валюты).

3.3. Направление В: Функциональный анализ программной логики. Реверс-инжиниринг хранимых процедур, функций, триггеров. Анализ алгоритмов расчетов (начисление процентов), бизнес-правил, внешних вызовов.

3.4. Направление Г: Форенсик-анализ пользовательской активности. Исследование журналов СУБД (аудит, трассировка), пользовательских таблиц аудита. Реконструкция действий по временным меткам. Анализ истории изменений данных (при возможности).

3.5. Направление Д: Анализ системной интеграции. Поиск следов подключения к внешним API, платежным шлюзам, биржевым системам. Исследование связанных серверов (Linked Servers), агентских заданий (Jobs).

ЭТАП 4. СИНТЕЗ И ПРОВЕРКА ГИПОТЕЗ

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

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

4.3. Выявление аномалий, закономерностей и признаков, свидетельствующих о преднамеренных действиях (напр., массовое изменение данных «задним числом», отключение журналирования в ключевые периоды).

ЭТАП 5. ФОРМИРОВАНИЕ И ОФОРМЛЕНИЕ ЗАКЛЮЧЕНИЯ

5.1. Структурирование отчета:

Вводная часть (основание, вопросы, объекты).

Исследовательская часть (ход исследования по этапам/направлениям).

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

Выводы (четкие ответы на поставленные вопросы).

5.2. Приложения: ER-диаграммы, листинги ключевых процедур, полные SQL-скрипты для формирования сводок, скриншоты интерфейсов (если есть).

5.3. Экспертный контроль: Проверка заключения на соответствие вопросам, отсутствие противоречий, ясность и доказательность изложения.

ГЛАВА 2. ЧАСТНЫЕ И СПЕЦИАЛЬНЫЕ МЕТОДИКИ ИССЛЕДОВАНИЯ

2.1. Методика ретроспективного анализа данных (Temporal Analysis).

Цель: Реконструкция состояния БД на определенную прошлую дату.

Инструменты: Использование полей ValidFrom/ValidTo (темпоральные таблицы в SQL:2011), анализ журналов транзакций, сопоставление дат в смежных таблицах (например, дата договора и дата первого взноса).

Метод: Формирование SELECT-запросов с условием AS OF (для темпоральных таблиц) или реконструкция через последовательное применение записей из журнала изменений.

2.2. Методика сравнительного анализа алгоритмической и фактической модели.

Цель: Выявление расхождений между заявленной (в документации, на сайте) и реальной бизнес-логикой.

Инструменты: SQL-запросы, средства сравнения данных.

Метод:

• Фиксация заявленных правил (например, «доход 0.5% в день от суммы вклада»).
• Анализ кода соответствующей хранимой процедуры.
• Выборка реальных начислений по группе клиентов.
• Сравнение расчетных (по формуле из кода) и фактических сумм. Выявление исключений и особых условий.

2.3. Методика выявления скрытых взаимосвязей (Social Network Analysis в данных).

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

Инструменты: Python (библиотеки networkx, pandas), Graph Databases (Neo4j).

Метод: Преобразование реляционных данных в графовую модель (узлы – клиенты, счета; ребра – транзакции, общий менеджер). Анализ центральности узлов, выявление кластеров.

2.4. Методика анализа целостности и согласованности данных (Data Integrity Forensics).

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

Инструменты: SQL-запросы с проверочными условиями (CHECK), скрипты на Python.

Метод:

• Проверка ссылочной целостности (наличие «висячих» ссылок FOREIGN KEY).
• Поиск дубликатов по уникальным полям.
• Проверка арифметической согласованности (например, сходится ли баланс клиента как сумма всех приходных и расходных операций).
• Анализ последовательности идентификаторов (ID) на наличие пропусков, что может указывать на удаление записей.

2.5. Методика «Следа обновления» (Update Trace Methodology).

Цель: Определение, какие именно поля и записи изменялись в ходе ключевых операций.

Инструменты: Триггеры аудита, журналы, сравнение снимков (snapshots) БД.

Метод: Если ведется детальный аудит, анализ таблицы AuditLog. При ее отсутствии – сравнение двух резервных копий БД, сделанных до и после ключевого события (например, обновления версии ПО), с помощью инструментов сравнения схем и данных (Redgate SQL Compare, ApexSQL Diff).

ГЛАВА 3. ТИПОВЫЕ ВОПРОСЫ НА ЭКСПЕРТИЗУ БАЗ ДАННЫХ: КЛАССИФИКАЦИЯ И ФОРМУЛИРОВКИ

Блок 1. Вопросы об архитектуре и назначении системы

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

Блок 2. Вопросы о данных и их содержании

• Какая информация о клиентах (вкладчиках, инвесторах) содержится в базе данных? Предоставьте структурированную выгрузку.
• Какова общая статистика по финансовым операциям: общая сумма привлеченных средств, общая сумма выплаченных средств, количество уникальных клиентов за указанный период?
• Содержатся ли в базе данных сведения о договорах с клиентами? Если да, то какова их структура и какие условия (срок, процентная ставка) в них зафиксированы?

Выделите Топ-20 клиентов по следующим критериям: а) общий объем внесенных средств; б) общий объем выведенных средств; в) текущий остаток (сальдо).

Блок 3. Вопросы о бизнес-логике и алгоритмах

• Каким образом в системе реализован механизм начисления дохода (процентов) клиентам? Предоставьте текст соответствующих хранимых процедур/функций и их словесное описание.
• По какой математической формуле производится расчет начисляемого дохода? Зависит ли формула от суммы, срока, категории клиента?
• Какие операции (транзакции) могут быть проведены в системе (ввод, вывод, перевод между счетами, начисление)? Опишите алгоритм каждой из них.

Блок 4. Вопросы о пользователях и их активности (форенсик)

• Какие учетные записи пользователей заведены в базе данных и каковы их права доступа (роли)?
• Имеется ли в системе журналирование действий пользователей? Если да, то зафиксируйте все действия, совершенные под учетной записью [ФИО/логин] в период с [дата] по [дата].
• Кто из пользователей имел техническую возможность изменять алгоритмы начисления дохода (хранимые процедуры) и изменял ли их в указанный период?
• Содержатся ли в базе данных признаки привязки клиентов к конкретным менеджерам (кураторам)? Если да, составьте соответствующие списки.

Блок 5. Вопросы о целостности и внешних связях

• Обнаружены ли в базе данных признаки нарушения целостности данных (например, операции без привязки к договору, несоответствие итоговых сумм)?
• Подключается ли база данных к каким-либо внешним системам (платежные шлюзы, биржевые терминалы, SMS-рассылка)? Если да, то к каким и с какой целью?
• Имеются ли в данных признаки, указывающие на особый статус некоторых клиентов (метки, комментарии, особые условия в договорах)?

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

Кейс 1: «Крипто-пирамида “BitVault”»

Суть дела: Компания привлекала средства в BTC и ETH под обещание дохода от арбитражной торговли.

Задача экспертизы: Установить, велся ли реальный учет крипто-активов и была ли возможна заявленная деятельность.

Ход экспертизы:

Обнаружена БД на PostgreSQL. Таблицы users, wallets, transactions, promises.

Ключевая находка: В таблице transactions были поля btc_amount, eth_amount, но все они имели тип NUMERIC(20,8). Отсутствовали поля для хранения хэша транзакции (txid), адреса кошелька отправителя/получателя, подтверждений. Это технически исключало возможность верификации операций в блокчейне.

Процедура accrue_daily_profit начисляла фиксированный процент от «баланса», который сам был лишь записью в БД.

Анализ логов показал массовое создание «транзакций» внутренним администратором вручную через SQL-консоль.

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

Кейс 2: «Мошенничество в госзакупках («Откатная схема»)»

Суть дела: Подозрение в завышении цен и откатах при закупках медицинского оборудования через аффилированных поставщиков.

Задача экспертизы: Выявить в БД тендерной платформы и БД компании-поставщика связи, указывающие на сговор.

Ход экспертизы:

Получены две БД: от платформы (tenders, bids, companies) и от поставщика (invoices, clients, special_payments).

Методика кросс-анализа: Эксперт искал совпадения по косвенным признакам. В БД поставщика в таблице special_payments были записи с назначением «консультационные услуги» на суммы, составлявшие ~10% от конкретных счетов.

Сопоставление дат платежей из special_payments и дат выигрыша тендеров в БД платформы выявило корреляцию.

В БД платформы в комментариях к заявкам (bids) у «победивших» компаний находились служебные отметки, невидимые заказчику, с внутренними кодами, совпадавшими с кодами контрагентов в БД поставщика.

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

Кейс 3: «Незаконная банковская деятельность («Черный кредитор»)»

Суть дела: Организация выдавала займы под грабительские проценты без лицензии ЦБ, используя агрессивные методы коллекции.

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

Ход экспертизы:

• БД содержала таблицы loans, payments, penalties, call_center.
• Анализ процедуры apply_penalty показал алгоритм: при просрочке > 1 день начислялся штраф в размере 5% от суммы долга ежедневно (что в годовом исчислении давало астрономические проценты).
• В таблице call_center хранились не только контакты заемщика, но и номера телефонов его родственников, коллег, извлеченные, как выяснилось, из памяти телефона через мобильное приложение.
• Найден триггер, который при изменении статуса займа на «просроченный» автоматически формировал задание на обзвон всех связанных контактов из call_center.

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

Кейс 4: «Финансовая пирамида в формате MLM («Сетевой проект»)»

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

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

Ход экспертизы:

• БД имела рекурсивную структуру таблицы users с полями sponsor_id, left_child_id, right_child_id (бинарная матрица).
• Сложная хранимая процедура calculate_bonus осуществляла обход дерева. Ее анализ показал, что 80% выплат производились за счет «бонуса за привлечение» с прямых рефералов и «бонуса за объем» с нижележащих уровней.

Статистический анализ: Эксперт сгенерировал отчет, показавший, что >70% участников, присоединившихся позже 3-го месяца работы схемы, внесли деньги, но не получили ни одной выплаты, так как не смогли привлечь нужное количество людей.

Отсутствовали таблицы учета реальных товарооборотов или внешних активов.

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

Кейс 5: «Манипуляции на электронных торгах по банкротству»

Суть дела: Сговор группы лиц для приобретения активов банкротов по заниженной цене путем сдерживания конкуренции.

Задача экспертизы: Исследовать БД аналитического сервиса, использовавшегося группой, для выявления признаков сговора.

Ход экспертизы:

• БД сервиса содержала историю всех торгов, прогнозы цен, а также служебную таблицу client_tags.
• Анализ client_tags выявил присвоение цифровых меток (tag_id) определенным компаниям-участникам торгов.
• Процедура generate_recommendation для участников с определенными tag_id формировала «рекомендацию» не подавать заявку на конкретный лот или подавать ее с минимальным шагом.
• Журнал использования API показал, что запросы от разных юридических лиц, но с одинаковыми tag_id, приходили с одного IP-адреса.

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

ГЛАВА 5. ПРОБЛЕМЫ И ПЕРСПЕКТИВЫ РАЗВИТИЯ ПРОЦЕДУРЫ

Проблема «живых» облачных БД (SaaS): Сложность изъятия, юрисдикция данных. Требует новых протоколов взаимодействия с провайдерами (Microsoft Azure, Amazon AWS).

Большие данные (Big Data): Анализ распределенных систем (Hadoop, Spark). Необходимость в новых инструментах и методиках семплирования.

Шифрование данных на уровне БД: Прозрачное шифрование (TDE), шифрование столбцов. Требует легального получения ключей или сотрудничества с разработчиком.

Использование AI/ML в экспертизе: Применение машинного обучения для автоматического выявления аномальных паттернов в транзакциях, кластеризации пользователей по поведению.

ЗАКЛЮЧЕНИЕ

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