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

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

ВВЕДЕНИЕ. ЭВОЛЮЦИЯ СУДЕБНОЙ ЭКСПЕРТИЗЫ В УСЛОВИЯХ ЦИФРОВИЗАЦИИ ПРЕСТУПНОЙ ДЕЯТЕЛЬНОСТИ

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

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

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

1.1. Основания и порядок назначения.
Экспертиза БД назначается по постановлению следователя (дознавателя) или определению суда в соответствии со ст. 195-207 УПК РФ, когда для установления обстоятельств, имеющих значение для дела, требуются специальные познания в области информационных технологий и анализа структурированных данных. Поводами служат:

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

1.2. Объекты и материалы экспертизы.

Основной объект: Сама база данных в виде файлов СУБД (.mdf, .ldf, .ibd), логического дампа (SQL-файл) или резервной копии.

Производные объекты: Журналы транзакций, файлы конфигурации, документация к системе, скриншоты интерфейсов.

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

1.3. Требования к эксперту и экспертному учреждению.
Эксперт должен обладать специальными познаниями в области:

• Систем управления базами данных (Microsoft SQL Server, PostgreSQL, MySQL, Oracle).
• Языка SQL и теории баз данных.
• Основ программирования и реверс-инжиниринга.
• Финансового учета и основ экономического анализа.

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

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

Методика представляет собой систему последовательных стадий и методов, направленных на полное и всестороннее исследование БД.

СТАДИЯ 1. ПОДГОТОВИТЕЛЬНАЯ

Задача: Обеспечение условий для достоверного и неизменного исследования.

Методы и действия:

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

Создание изолированной экспертной среды: Развертывание БД на отдельном, не связанном с сетью сервере или в виртуальной машине. Использование аппаратных или программных write-blocker.

Документирование исходного состояния: Фиксация версии СУБД, кодировок, размера БД, даты последнего изменения.

СТАДИЯ 2. СТРУКТУРНО-МЕТАДАННЫЙ АНАЛИЗ

Задача: Реконструкция логической и физической схемы БД, понимание архитектуры системы.

Методы и действия:

Экстракция метаданных: Запросы к системным каталогам (sys.tables, INFORMATION_SCHEMA.TABLES, pg_class). Получение полного списка объектов: таблицы, представления, индексы, процедуры, функции, триггеры.

Анализ связей: Выявление первичных (PRIMARY KEY) и внешних ключей (FOREIGN KEY). Построение Entity-Relationship Diagram (ERD).

Анализ ограничений целостности: Изучение CHECK-ограничений, UNIQUE-индексов, значений по умолчанию (DEFAULT). Это позволяет понять бизнес-правила, заложенные на уровне схемы.

Пример SQL запроса для анализа связей (MS SQL Server):

sql

SELECT

fk.name AS FK_Name,

tp.name AS Parent_Table,

cp.name AS Parent_Column,

tr.name AS Referenced_Table,

cr.name AS Referenced_Column

FROM sys.foreign_keys fk

INNER JOIN sys.tables tp ON fk.parent_object_id = tp.object_id

INNER JOIN sys.tables tr ON fk.referenced_object_id = tr.object_id

INNER JOIN sys.foreign_key_columns fkc ON fk.object_id = fkc.constraint_object_id

INNER JOIN sys.columns cp ON fkc.parent_column_id = cp.column_id AND fkc.parent_object_id = cp.object_id

INNER JOIN sys.columns cr ON fkc.referenced_column_id = cr.column_id AND fkc.referenced_object_id = cr.object_id

ORDER BY tp.name, fk.name;

СТАДИЯ 3. СЕМАНТИЧЕСКИЙ И СОДЕРЖАТЕЛЬНЫЙ АНАЛИЗ

Задача: Установление фактического содержания БД, выявление ключевых данных, их классификация и оценка.

Методы и действия:

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

Анализ справочной информации: Критическая оценка таблиц-справочников (currencies, stock_symbols, interest_rates). Проверка их актуальности, источника обновления, соответствия реальным рыночным данным. Это ключевой метод для выявления фиктивности.

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

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

СТАДИЯ 4. ФУНКЦИОНАЛЬНО-ПРОЦЕДУРНЫЙ АНАЛИЗ (РЕВЕРС-ИНЖИНИРИНГ)

Задача: Исследование программной бизнес-логики, инкапсулированной в объектах БД.

Методы и действия:

Статический анализ исходного кода: Изучение текстов хранимых процедур (Stored Procedures), функций (Functions), триггеров (Triggers).

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

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

Анализ точек модификации данных: Определение, какие именно таблицы и поля изменяются в результате работы процедур.

Пример анализа процедуры начисления процентов:

sql

CREATE PROCEDURE accrue_dividend @client_id INT

AS

BEGIN

DECLARE @balance DECIMAL(18,2), @rate DECIMAL(5,2), @dividend DECIMAL(18,2);

SELECT @balance = balance FROM accounts WHERE client_id = @client_id;

SELECT @rate = 0.5; — Фиксированная ставка 0.5% в день

SET @dividend = @balance * @rate / 100;

UPDATE accounts SET balance = balance + @dividend WHERE client_id = @client_id;

INSERT INTO transactions (client_id, type, amount, date) VALUES (@client_id, ‘DIVIDEND’, @dividend, GETDATE());

END

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

СТАДИЯ 5. ФОРЕНСИК-АНАЛИЗ И РЕКОНСТРУКЦИЯ СОБЫТИЙ

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

Методы и действия:

Анализ журналов аудита СУБД: Исследование журналов транзакций, логов ошибок, следов SQL Server Audit или аналогичных механизмов.

Исследование пользовательских таблиц истории: Анализ таблиц, созданных разработчиками для аудита (audit_log, change_history).

Метод временных меток: Реконструкция последовательности событий на основе полей created_at, updated_at, transaction_date. Выявление аномалий (операции в нерабочее время, массовые однотипные действия).

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

СТАДИЯ 6. СИНТЕЗ И ФОРМИРОВАНИЕ ЗАКЛЮЧЕНИЯ

Задача: Обобщение результатов, формулировка ответов на поставленные вопросы, оценка доказательственной значимости.

Методы и действия:

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

Ответы на вопросы: Четкие, технически обоснованные ответы с прямыми ссылками на данные и код.

Оформление заключения: В соответствии с требованиями ст. 204 УПК РФ. Обязательные приложения: ER-диаграммы, листинги ключевых процедур, сводные таблицы по клиентам/операциям, графики финансовых потоков.

ГЛАВА 3. СИСТЕМА ВОПРОСОВ, РАЗРЕШАЕМЫХ В ХОДЕ СУДЕБНОЙ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

Вопросы формулируются следователем или судом и должны находиться в пределах специальных познаний эксперта.

КАТЕГОРИЯ I. ВОПРОСЫ ОБ ОБЩЕЙ ХАРАКТЕРИСТИКЕ И НАЗНАЧЕНИИ СИСТЕМЫ

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

Каковы ключевые взаимосвязи между таблицами базы данных (основные foreign key-ограничения)? Возможно ли предоставить схему данных (ER-диаграмму)?

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

КАТЕГОРИЯ II. ВОПРОСЫ О СОДЕРЖАНИИ ИНФОРМАЦИИ И ЕЕ ДОСТОВЕРНОСТИ

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

Содержатся ли в базе данных качественные актуальные биржевые котировки, кросс-курсы валют или иные внешние финансовые данные, на основе которых можно вести реальную инвестиционную деятельность? Если да, то каков источник их обновления? Если нет, какие данные используются для расчета «доходности»?

Какая информация о договорах (соглашениях) с клиентами, их условиях (суммы, сроки, процентные ставки) содержится в БД?

КАТЕГОРИЯ III. ВОПРОСЫ О БИЗНЕС-ЛОГИКЕ И АЛГОРИТМАХ РАБОТЫ СИСТЕМЫ

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

По какой конкретной математической формуле производится расчет начисляемого дохода? Зависит ли эта формула от каких-либо внешних переменных (рыночных данных) или является детерминированной (фиксированной, зависящей только от суммы и срока)?

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

КАТЕГОРИЯ IV. ВОПРОСЫ О ФИНАНСОВЫХ ПОТОКАХ И СТАТИСТИКЕ

Какова общая сумма денежных средств, зафиксированных в базе данных как привлеченные от клиентов (вкладчиков) за период с [дата] по [дата]?

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

Выделите 20 клиентов с наибольшим совокупным объемом внесенных средств и 20 клиентов с наибольшим совокупным объемом выведенных средств. Предоставьте по ним сводные данные (ФИО, суммы вложений/выводов, сальдо).

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

КАТЕГОРИЯ V. ВОПРОСЫ О ПОЛЬЗОВАТЕЛЬСКОЙ АКТИВНОСТИ И АУДИТЕ

Какие учетные записи пользователей заведены в базе данных и каковы их права доступа (роли)? Кто имел права администратора (db_owner, sysadmin)?

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

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

КАТЕГОРИЯ VI. ВОПРОСЫ О ПРИЗНАКАХ ПРОТИВОПРАВНОЙ ДЕЯТЕЛЬНОСТИ (С ОСТОРОЖНОСТЬЮ, В РАМКАХ ФАКТИЧЕСКИХ ОБСТОЯТЕЛЬСТВ)

Обнаружены ли в базе данных признаки, указывающие на то, что выплаты «доходов» одним клиентам технически зависимы от поступления средств от других, новых клиентов (например, отсутствие внешних источников дохода, прямой перерасчет входящих платежей в выплаты)?

Имеются ли в базе данных признаки, позволяющие выделить категории клиентов с особыми условиями (например, поле is_vip, is_relative, is_staff)? Если да, то каковы особенности начисления или выплат для этих категорий?

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

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

Кейс 1: Финансовая пирамида «Кэшберити» (по материалам реального уголовного дела)

Суть дела: Организация привлекала средства под 1% дневного дохода от «арбитражных сделок на фондовом рынке».

Ход экспертизы: Эксперту была предоставлена БД на MySQL. На стадии структурного анализа выявлены таблицы users, deposits, withdrawals, bonuses. Связи показали, что каждый deposit привязывался к user, а bonus — к user от которого пришел реферал.

Семантический анализ: В таблице users поле balance обновлялось ежедневно. Ключевая находка: Отсутствие каких-либо таблиц trades, quotes, portfolios.

Функциональный анализ: Процедура daily_profit содержала код: UPDATE users SET balance = balance * 1.01 WHERE status=’active’. Источник дохода — умножение на 1.01, а не внешние данные.

Статистический анализ: Расчет показал, что 92% входящих платежей за последний месяц были направлены на выплаты старым вкладчикам.

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

Использование в суде: Заключение стало основным доказательством по ст. 172.2 УК РФ (организация финансовой пирамиды).

Кейс 2: Мошенничество в сфере IT-аутсорсинга

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

Ход экспертизы: Изъята БД системы управления активами (ITSM) компании. Структурный анализ показал таблицы software_licenses, installations, devices.

Семантический анализ: Эксперт сформировал запрос на сопоставление лицензий и установок. Обнаружено, что 150 лицензий с ключами были внесены в БД (software_licenses), но только 40 записей об их установке (installations). При этом все 150 лицензий были отмечены как «активированные».

Форенсик-анализ: В журнале изменений (audit_log) обнаружены массовые записи от имени администратора о «пакетной активации» 110 лицензий одним действием в течение 2 минут. Поле activation_ip для всех этих записей содержало локальный IP-адрес сервера, а не внешние адреса.

Заключение эксперта: Данные БД свидетельствуют о фиктивном учете активации большей части ПО, что не соответствует реальному использованию.

Использование в суде: Заключение, вместе с показаниями свидетелей об отсутствии ПО на рабочих местах, доказало факт хищения денежных средств (ст. 159 УК РФ).

Кейс 3: Легализация средств, полученных от интернет-мошенничества

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

Ход экспертизы: Изъята центральная БД на PostgreSQL, управляющая сетью «магазинов». Функциональный анализ выявил процедуру distribute_revenue, которая автоматически распределяла поступившие платежи с агрегаторов (Яндекс.Касса, Robokassa) по разным счетам юрлиц не пропорционально заказам, а по сложному алгоритму, минимизирующему остатки.

Семантический анализ: Таблица orders содержала заказы, но связанная таблица shipments (отгрузки) была пуста для 85% записей. При этом в таблице customers большинство email-адресов были сгенерированы по шаблону (например, asdfgh[номер]@mail.ru).

Анализ связей: Была выявлена скрытая таблица bank_accounts, не связанная с интерфейсом, где хранились реквизиты для вывода средств, не соответствующие официальным реквизитам магазинов.

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

Использование в суде: Экспертиза подтвердила умысел на легализацию и стала доказательством по ст. 174.1 УК РФ.

Кейс 4: Незаконная банковская деятельность (криптообменный сервис)

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

Ход экспертизы: Исследована БД сервиса. Структурный анализ выявил таблицы user_wallets (рублевые «кошельки»), transfers (внутренние переводы), exchange_orders (обмен на криптовалюту).

Функциональный анализ: Процедура internal_transfer позволяла переводить рубли между user_wallets внутри системы без вывода на карты, фиксируя это как «транзакцию». Процедура calculate_yield начисляла «проценты на остаток» на рублевых кошельках.

Семантический анализ: В таблице users отсутствовали поля, обязательные для банковского идентифицирования (ИНН, паспорт – только email и телефон). Объем операций internal_transfer в 10 раз превышал объем операций exchange_orders.

Заключение эксперта: Функционал системы de facto реализует операции по приему денежных средств и осуществлению переводов именных денежных требований (признаки банковских операций), при отсутствии в архитектуре механизмов идентификации, требуемых 115-ФЗ.

Использование в суде: Заключение легло в основу обвинения по ст. 172 УК РФ (незаконная банковская деятельность).

Кейс 5: Манипуляции в системе госзакупок (ст. 159 УК РФ — Мошенничество)

Суть дела: Чиновник и предприниматель обвинялись в сговоре для завышения начальной максимальной цены контракта (НМЦК) через создание искусственных конкурентов с заведомо невыполнимыми предложениями.

Ход экспертизы: Получена БД коммерческой тендерной платформы, на которой проводился аукцион. Форенсик-анализ таблицы bid_log (журнал подачи заявок) показал, что заявки от 3 «конкурентов» были поданы с одного IP-адреса в течение 5 минут, при этом время между их подачей составляло ровно 10-15 секунд (автоматизированный сценарий).

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

Анализ бизнес-логики: Триггер after_bid_insert автоматически изменял статус заявки «основного» подрядчика с pending на recommended сразу после подачи последней фиктивной заявки.

Заключение эксперта: Данные БД объективно свидетельствуют о согласованных действиях по имитации конкурентной борьбы и технической подготовке аукциона в интересах одного участника.

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

ГЛАВА 5. ЗАКЛЮЧЕНИЕ: ЗНАЧЕНИЕ И ПЕРСПЕКТИВЫ РАЗВИТИЯ ЭКСПЕРТИЗЫ

Судебная экспертиза баз данных доказала свою высокую эффективность как инструмент расследования сложных экономических преступлений. Ее основное преимущество — способность перевести субъективные показания и предположения в плоскость объективного анализа машиночитаемых данных и алгоритмов.

Ключевые тенденции развития:

Усложнение объектов: Анализ распределенных БД (NoSQL, кластерные решения), облачных хранилищ (AWS RDS, Google Cloud SQL).

Интеграция методов: Сочетание с анализом big data, применением машинного обучения для выявления паттернов мошенничества.

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

Повышение роли на стадии ОРД: Использование экспертных методик в ходе оперативной разработки для сбора первичных доказательств.

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