Аннотация. В данной статье рассматривается судебная экспертиза баз данных (БД) как самостоятельный и комплексный вид исследования в рамках уголовного судопроизводства по делам о мошенничестве (ст. 159 УК РФ), легализации денежных средств (ст. 174, 174.1 УК РФ), незаконной банковской деятельности (ст. 172 УК РФ), организации финансовой пирамиды (ст. 172.2 УК РФ) и иных экономических преступлениях. Автором детально проанализированы теоретические основы, правовые предпосылки и практические методологические подходы к проведению данного вида экспертиз. На основе системного анализа предложена детализированная структурно-функциональная модель исследования БД, охватывающая архитектурный, семантический, процессуальный, субъектно-ролевой и интеграционный аспекты. Особое внимание уделено решению специфических задач, таких как реконструкция алгоритмов начисления процентов, выявление признаков фиктивности операций, установление взаимосвязей между субъектами и анализ пользовательской активности. Статья носит междисциплинарный характер и предназначена для экспертов-криминалистов, следователей, судей, а также специалистов в области информационной безопасности и финансовых технологий.

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

Введение. Актуальность и правовая база экспертизы баз данных

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

Правовой основой для назначения и проведения экспертизы БД выступают нормы Уголовно-процессуального кодекса Российской Федерации (гл. 27), Федеральный закон от 31.05.2001 N 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации», а также соответствующие методические рекомендации и стандарты в области судебной экспертизы. Вопросы, поставленные перед экспертом, как правило, выходят за рамки классической компьютерно-технической экспертизы, требуя от специалиста синтеза знаний в области IT, финансового учета, криминалистики и конкретной предметной области (брокерская деятельность, коллекторство, микрофинансирование и т.д.).

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

Глава 1. Объект, предмет и классификационные параметры экспертизы баз данных

Объектом экспертизы является база данных как информационная система, представленная в виде криминалистической копии файлов СУБД (например, файлы *.mdf, *.ldf для Microsoft SQL Server, *.ibd для MySQL, дампы в формате SQL) или, в исключительных случаях, функционирующая («живая») система, доступ к которой осуществляется в контролируемых условиях с соблюдением принципа неизменности доказательственной информации.

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

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

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

Глава 2. Методологический фундамент: системный и структурно-функциональный подход

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

• Структуру: «Как это устроено?» (таблицы, связи).
• Содержание: «Что хранится?» (данные).
• Функции: «Как работает?» (процедуры, триггеры).
• Поведение: «Кто и что делал?» (журналы, логи).
• Интеграцию: «С чем взаимодействует?» (внешние сервисы).

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

Глава 3. Детализированный алгоритм и направления экспертного исследования

3.1. Анализ архитектуры и метаданных (Вопросы 1, 3)

Исследование начинается с реконструкции логической схемы БД. Эксперт анализирует:

Системные каталоги (INFORMATION_SCHEMA, sys.* в SQL Server, pg_catalog в PostgreSQL) для получения списка всех объектов.

Структуру таблиц: имена, типы данных, атрибуты (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL). Это позволяет выявить нормализованность или денормализованность структуры, что может говорить о степени профессионализма разработки или о подгонке под конкретную, возможно, неправомерную, схему работы.

Связи между таблицами: Детальный анализ FOREIGN KEY-ограничений или их логических аналогов. Построение ER-диаграммы (Entity-Relationship) является обязательным этапом, визуализирующим связи между сущностями «Клиент», «Договор», «Счет», «Транзакция», «Менеджер» и т.д. Нарушение принципов ссылочной целостности может свидетельствовать о манипуляциях с данными.

3.2. Семантический анализ содержимого (Вопросы 2, 6, 10, 14)

На данном этапе эксперт переходит к анализу непосредственно данных, заполняющих структуру.

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

Анализ клиентской информации (п.10): Эксперт определяет полноту и структуру данных о клиентах: ФИО, паспортные данные, контакты, статус. Исследуются связанные с клиентами транзакционные таблицы, содержащие информацию о входящих взносах (Deposit), исходящих выплатах (Withdrawal), внутренних оборотах (Transfer) и начисленных процентах (Interest). Формируются агрегированные показатели на каждого клиента: общая сумма вложений, общая сумма изъятий, сальдо, сумма начисленных процентов.

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

3.3. Функционально-процедурный анализ (Вопросы 5, 7, 8)

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

Исследование хранимых процедур (Stored Procedures): Эксперт проводит статический анализ исходного кода процедур на языке SQL (T-SQL, PL/pgSQL и др.). Цели:

Определение назначения каждой процедуры (например, CalculateDailyInterest, ProcessWithdrawal, GenerateReport).

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

Фиксация побочных эффектов: Процедуры могут не только рассчитывать, но и модифицировать данные. Необходимо отследить все INSERT, UPDATE, DELETE-операции, выполняемые процедурой.

Анализ триггеров (Triggers): Эти объекты автоматически выполняются при событиях (вставка, обновление, удаление). Они могут использоваться для скрытого аудита, каскадных изменений или, наоборот, для маскировки истинной природы операций (например, триггер, «очищающий» историю после выполнения определенного действия).

3.4. Субъектно-ролевой и статистический анализ (Вопросы 11, 12, 13)

Данное направление нацелено на выявление ключевых фигур в системе.

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

Выделение значимых клиентов (п.12): На основе агрегированных данных (см. п.3.2) формируются ранжированные списки (Топ-10, Топ-20, Топ-100) по критериям: общий объем вложений, сальдо (невыведенные средства), сумма полученных процентов, объем изъятий. Такой анализ выявляет основных вкладчиков (потерпевших) и, возможно, бенефициаров, выводивших средства на ранних этапах.

Анализ специфических категорий (п.13): Эксперт проверяет наличие в БД полей, меток или отдельных таблиц, позволяющих идентифицировать клиентов, связанных с конкретными лицами (например, родственниками руководителей). Это может реализовываться через служебные комментарии, специальные коды в поле client_type или через отдельную таблицу связей client_affiliations.

3.5. Анализ системного администрирования и интеграции (Вопросы 9, 15, 16)

Интеграция с внешними сервисами (п.9): В коде хранимых процедур, функциях или конфигурационных таблицах ищутся строки подключения (ConnectionString), URL API, названия внешних служб. Факт подключения к платежным агрегаторам, биржевым шлюзам или сервисам проверки данных подтверждает реальность операций. Их отсутствие при заявленной сложной деятельности – тревожный сигнал.

Аудит пользовательской активности (п.15, 16):

Анализ таблиц пользователей и ролей (sys.syslogins, sys.database_principals). Определение, кому принадлежат права db_owner, db_datawriter.

Исследование журналов СУБД и таблиц аудита, если они ведутся. Эксперт ищет записи о: времени входа/выхода (LOGON/LOGOFF), успешных и неуспешных попытках аутентификации, выполнении конкретных команд DML (INSERT, UPDATE, DELETE) и DDL (CREATE, ALTER). Восстановление хронологии действий ключевых пользователей в периоды, значимые для расследования (массовое начисление процентов, крупные выводы средств, изменения алгоритмов), имеет критически важное доказательственное значение.

3.6. Синтез: определение фактического назначения БД (Вопрос 4)

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

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

Глава 4. Практические сложности и рекомендации

Работа с объемами: Для анализа больших данных (Big Data) необходимо использование специализированного ПО (напр., Pentaho DI, специализированные SQL-клиенты с мощными средствами визуализации), написание сложных агрегирующих запросов и выборочный статистический анализ.

Недостаточность журналирования: Часто в БД преступных схем аудит намеренно отключен. В этом случае эксперт должен делать выводы на основе косвенных данных: временных меток (created_at) в транзакционных таблицах, анализа триггеров, которые могут служить «скрытым» журналом.

Интерпретационная осторожность: Эксперт устанавливает технические факты (наличие кода, связей, данных), но должен избегать прямых юридических оценок («действовал умышленно»). Его задача – представить следствию и суду четкую, объективную картину функционирования системы, на основе которой правовая квалификация может быть сделана самостоятельно.

Заключение

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