library

Экспертиза баз данных по уголовному делу: Методология, цели и ключевые вопросы

ВВЕДЕНИЕ: МЕСТО И РОЛЬ ЦИФРОВЫХ СЛЕДОВ В СОВРЕМЕННОЙ ПРЕСТУПНОСТИ

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

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

РАЗДЕЛ 1. ФУНДАМЕНТАЛЬНЫЙ АНАЛИЗ: АРХИТЕКТУРА, ЛОГИКА И НАЗНАЧЕНИЕ СИСТЕМЫ

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

1.1. Деконструкция общей структуры: от таблиц до процедур. Эксперт начинает с анализа схемы данных (ER-диаграммы или системного каталога). Выявляются:

Таблицы (Tables): Фундаментальные сущности системы. Стандартный набор для финансовых схем включает clients, accounts, transactions, contracts, payments, securities (если заявлено). Наличие же таблиц bonuses, referral_links, manager_targets сразу указывает на маркетинговую или сетевую составляющую.
Представления (Views): Виртуальные таблицы, результат сохранённого запроса. Они могут служить как для упрощения отчётности (например, v_client_balance), так и для сокрытия сложной логики расчётов или фильтрации данных для разных групп пользователей (например, v_active_investors_top100).
Хранимые процедуры и функции (Stored Procedures/Functions): «Мозг» системы. Это автоматизированные сценарии, выполняющие бизнес-логику. Их анализ критически важен. Процедуры с названиями calculate_daily_profit, accrue_interest, process_withdrawal содержат алгоритмы, по которым работала схема.
Триггеры (Triggers): Автоматические реакции на события (вставка, обновление записи). Могут использоваться для ведения журнала изменений, каскадного обновления балансов или скрытого дублирования данных.

1.2. Ключевые взаимосвязи (Relationships). Анализ связей по первичным (PRIMARY KEY) и внешним ключам (FOREIGN KEY) позволяет восстановить каркас бизнес-процесса. Например, связь transaction → account → client → manager показывает цепочку подчинённости и контроля. Отсутствие ожидаемых связей (скажем, транзакции, не привязанной ни к какому договору) – признак нецелостности данных или наличия служебных, возможно, маскирующих операций.

1.3. Установление истинного назначения базы данных. На основе структуры делается вывод о природе системы. Является ли она:

Псевдоброкерской платформой: Присутствуют таблицы quotes, orders, trades, но необходимо проверить, заполнены ли они реальными биржевыми данными и ведут ли к реальным изменениям балансов.
Платформой инвестиционного пула (Ponzi/Pyramid): Акцент на таблицах investments, referrals, bonus_calculations. Процедуры начисления процентов часто зависят не от внешних рынков, а от даты вклада, суммы или привлечённых новых участников.
Учётной системой МФО или ломбарда: Чёткая структура по договорам займа, графикам платежей, расчёту процентов по дням.
Системой отмывания (структурирования): Множество таблиц с транзакциями, высокая частота операций, сложные цепочки внутренних переводов между счетами, процедуры автоматического дробления сумм.

1.4. Интеграция с внешним миром: подключения и сервисы. Изучение конфигурационных файлов, логов, расписаний заданий (jobs) позволяет выявить:

Подключение к API бирж, платежных систем, банков: Подтверждает или опровергает заявления о реальной деятельности.
Наличие сервисов отправки email/SMS (для рассылки рекламы, выписок, кодов подтверждения).
Синхронизацию с другими базами или приложениями: Указывает на масштаб и распределённость инфраструктуры.

РАЗДЕЛ 2. СОДЕРЖАТЕЛЬНЫЙ И ФИНАНСОВО-ЭКОНОМИЧЕСКИЙ АНАЛИЗ ДАННЫХ

После понимания «как устроено» наступает этап анализа «что хранится». Здесь экспертиза смыкается с финансово-экономической.

2.1. Анализ информации по клиентам – ядро расследования.

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

2.2. Выделение значимых клиентов и анализ потоков. Формирование рейтингов (Топ-10, Топ-20, Топ-100):

По объёму вложений: Крупнейшие инвесторы/потерпевшие.
По объёму изъятий: Лица, которые успели вывести больше, чем вложили (возможные выгодоприобретатели или «подставные» лица для обналичивания).
По полученным процентам (виртуальной «прибыли»): Показывает, на кого была ориентирована схема для создания видимости успешности.
Анализ транзакционных цепочек: Выявление цикличных переводов между счетами для искусственного накручивания оборотов, схемы «ломбарда» (быстрый вывод новым вкладчиком денег старому).

2.3. Критическая проверка биржевой или рыночной составляющей. Для дел, связанных с имитацией брокерской деятельности:

Наличие и актуальность данных: Существуют ли таблицы котировок (quotes, rates)? Заполнены ли они исторически достоверными данными? Как часто обновлялись? Использовался ли реальный API или статический «снимок»?
Логика торгов: Есть ли таблицы заявок (orders) и сделок (trades)? Привязаны ли они к балансам клиентов? Совпадает ли время «сделок» с режимом работы реальных бирж? Часто в мошеннических схемах «сделки» генерируются процедурой случайным образом в рамках заданного коридора, имитируя успешный трейдинг.

РАЗДЕЛ 3. ПРОЦЕДУРНАЯ ЛОГИКА И РЕКОНСТРУКЦИЯ ДЕЙСТВИЙ ЛИЦ

Самый технически сложный и доказательно значимый этап. Он отвечает на вопрос «как именно это работало и кто это делал».

3.1. Глубинный анализ хранимых процедур. Эксперт не просто перечисляет их, а анализирует исходный код (SQL, PL/pgSQL, T-SQL).

Механизм начисления процентов: В процедуре accrue_interest видна формула. Например: new_balance = old_balance * (1 + 0.01 * @rate * datediff(day, last_accrual, getdate())). Это доказывает, что проценты начислялись по времени, а не от реальной прибыли. Или выявляется ссылка на таблицу referrals, доказывающая пирамидальный характер начислений.
Маршрутизация платежей: Процедура process_withdrawal может содержать логику: если сумма > X, то перевести на счет менеджера Y; если клиент из реферальной сети Z, то удержать комиссию. Это прямая схема распределения средств.
Генерация фиктивной отчётности: Процедуры, формирующие «ежедневные выписки» или «отчёты о сделках», которые рассылались клиентам.

3.2. Аудит пользователей и операций: установление цифрового следа субъекта.

Данные о пользователях БД (sys.users, pg_roles): Не только логины (admin, manager1, accountant), но и их права (SELECT, INSERT, EXECUTE). Право на выполнение процедуры write_off_debt значимее, чем право на просмотр.
Журналы входов (Login Audit) и истории действий (DML Audit): Позволяют построить цифровой профиль активности:
- Время и IP-адрес входа. Аномалии: входы ночью, с иностранных IP, одновременные сессии.
- Статистика и тип операций: пользователь X ежедневно в 10:00 запускал процедуру начисления, пользователь Y вручную корректировал балансы клиентов.
- Связка «пользователь БД → конкретное действие → запись в таблице». Например: user ‘cashier’ INSERT INTO transactions VALUES (…500000 RUB…). Это неопровержимая привязка цифрового действия к учётной записи.

3.3. Анализ временных меток и синхронизации событий. Сопоставление временных штампов (timestamps) в БД с другими доказательствами (выписки банков, переписка в мессенджерах). Например, массовый запуск процедуры вывода средств за час до блокировки расчётного счета правоохранителями.

РАЗДЕЛ 4. ФОРМИРОВАНИЕ ЗАКЛЮЧЕНИЯ: ОТ ДАННЫХ К ДОКАЗАТЕЛЬСТВАМ

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

4.1. Типовые выводы экспертизы:

О механизме деятельности: «Исследованная БД реализует механизм привлечения денежных средств населения с обязательным начислением процентов, величина которых зависит исключительно от срока и суммы вклада, без какого-либо алгоритма инвестирования в активы или учёта рыночных рисков, что характерно для финансовой пирамиды (схемы Понци)».
О размере ущерба: «На основе анализа таблиц transactions и accounts установлен общий объём привлечённых средств – X рублей. Общий объём выведенных клиентам средств – Y рублей. Расчетный размер причинённого ущерба (невозвращённые средства) составляет Z рублей, распределённый среди N уникальных клиентов».
О распределении ролей: «Анализ журналов доступа показал, что учётная запись [логин], закреплённая за фигурантом [ФИО], использовалась для ручного утверждения крупных выводов средств (таблица withdrawal_approvals) и изменения процентных ставок для избранных клиентов (процедура change_client_rate), что свидетельствует об административных полномочиях и контроле над финансовыми потоками».
Об имитации деятельности: «В БД отсутствуют актуальные таблицы котировок ценных бумаг. Записи в таблице trades носят синтетический характер, генерируясь процедурой generate_random_trades без привязки к внешним данным. Выписки из таблицы trades использовались для формирования отчётов, вводивших клиентов в заблуждение относительно реальной торговой деятельности».

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

ЗАКЛЮЧЕНИЕ

Экспертиза баз данных по уголовным делам – это высокотехнологичный, многоэтапный процесс криминалистической реконструкции. Она требует от эксперта не только глубоких знаний в области СУБД и программирования, но и понимания финансовых механизмов, а также чёткого видения задач уголовного процесса. Правильно спланированное и исполненное исследование способно извлечь из «цифрового шума» неопровержимую картину преступного деяния: его замысел, техническую реализацию, масштабы и круг причастных лиц. В эпоху, когда преступление совершается нажатием клавиши, главным доказательством становится его цифровой след, а экспертиза БД – ключом к его расшифровке. Предложенная в статье методология, основанная на последовательном анализе архитектуры, контента, процедурной логики и аудита, служит основой для построения полного, объективного и доказательного заключения, способного выдержать судебную проверку.