Аннотация. Настоящая статья посвящена техническим аспектам проведения экспертного исследования баз данных (БД) в рамках уголовных дел экономической направленности. Рассматриваются методологии анализа архитектуры СУБД, реверс-инжиниринга бизнес-логики, извлечения и верификации данных, а также реконструкции пользовательской активности. Особое внимание уделяется практическим техникам работы с различными типами СУБД (Microsoft SQL Server, PostgreSQL, MySQL), анализу хранимых процедур и функций, выявлению признаков сокрытия или фальсификации информации. Статья содержит детальные алгоритмы действий эксперта, примеры SQL-запросов для решения типовых экспертных задач и описание специализированного программного обеспечения. Материал предназначен для экспертов-криминалистов, специалистов в области информационной безопасности, forensic-аналитиков, а также следователей и судей, желающих углубить понимание технической составляющей данного вида доказательств.

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

ВВЕДЕНИЕ. БАЗА ДАННЫХ КАК СЛОЖНЫЙ ТЕХНИЧЕСКИЙ ОБЪЕКТ: ВЫЗОВЫ ДЛЯ ЭКСПЕРТА

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

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

1.1. Источники получения данных.
Эксперт может работать с:

Физическими файлами СУБД: Файлы данных (*.mdf, *.ndf для SQL Server; *.ibd для MySQL InnoDB; *.ORA для Oracle) и журналы транзакций (*.ldf, ib_logfile*). Требуют подключения к совместимому экземпляру сервера.

Логическим дампом (SQL Dump): Файл с последовательностью SQL-команд (CREATE, INSERT). Удобен для переноса, но может не содержать триггеров, хранимых процедур или быть неполным.

Резервной копией (Backup): Промышленные форматы бэкапов (*.bak, pg_dump). Наиболее надежны, так как содержат схему, данные, код и часто метаданные.

1.2. Критически важный шаг: верификация целостности и неизменности.
Перед началом работы эксперт обязан:

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

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

Убедиться в консистентности БД, запустив проверочные команды СУБД (напр., DBCC CHECKDB для SQL Server).

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

ГЛАВА 2. РЕКОНСТРУКЦИЯ СХЕМЫ БАЗЫ ДАННЫХ: МЕТАДАННЫЕ И ОТНОШЕНИЯ

2.1. Извлечение метаданных.
Использование системных представлений (System Views) и таблиц (Catalog):

Пример для SQL Server:

sql

— Список всех таблиц

SELECT s.name AS schema_name, t.name AS table_name, t.create_date, t.modify_date

FROM sys.tables t

JOIN sys.schemas s ON t.schema_id = s.schema_id

ORDER BY s.name, t.name;

— Список всех столбцов конкретной таблицы с типами данных

SELECT c.name AS column_name, ty.name AS data_type, c.max_length, c.is_nullable

FROM sys.columns c

JOIN sys.types ty ON c.user_type_id = ty.user_type_id

WHERE c.object_id = OBJECT_ID(‘dbo.Clients’);

— Внешние ключи и связи

SELECT

fk.name AS foreign_key_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;

2.2. Построение ER-диаграммы.
Автоматизация с помощью инструментов:

Встроенные средства: SQL Server Management Studio (SSMS) Database Diagram, pgModeler для PostgreSQL.

Сторонние инструменты: DbVisualizer, ER/Studio, Visio с надстройками.

Программная генерация: Использование Python-библиотек (sqlalchemy, graphviz) для скриптового построения диаграмм на основе извлеченных метаданных.

2.3. Анализ индексов и представлений (Views).

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

Представления: Маскируют сложность запросов. Необходимо извлечь их определение (SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID(‘ViewName’)) и проанализировать, какую информацию они агрегируют или скрывают.

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

3.1. Реверс-инжиниринг хранимых процедур.
Это ядро экспертизы. Алгоритм анализа:

Выявление всех процедур:

sql

SELECT name, create_date, modify_date, type_desc

FROM sys.procedures

ORDER BY name;

Извлечение исходного кода:

sql

SELECT OBJECT_DEFINITION(OBJECT_ID(‘dbo.CalculateInterest’)) AS procedure_definition;

Статический анализ кода. Эксперт ищет:

Ключевые таблицы: Какие таблицы участвуют в операциях SELECT, INSERT, UPDATE, DELETE.

Бизнес-правила: Условия в IF, CASE. Например, разные проценты для сумм выше/ниже порога или для VIP-клиентов.

Алгоритмы расчетов: Математические формулы в выражениях. Важно выписать их в чистом виде.

Внешние вызовы: Использование xp_cmdshell, OLE Automation, вызовы сторонних DLL – могут указывать на интеграцию.

Динамический SQL (EXEC, sp_executesql): Опасен, код может собираться во время выполнения. Необходимо анализировать строковые переменные, которые формируют запрос.

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

sql

— Пример упрощенной процедуры

CREATE PROCEDURE AccrueDailyInterest

AS

BEGIN

UPDATE ClientAccounts

SET Balance = Balance + (Balance * InterestRate / 365),

LastAccrualDate = GETDATE()

WHERE Status = ‘Active’

AND Balance > 0;

— Вставка записи в журнал начислений

INSERT INTO AccrualJournal (AccountID, AccrualDate, Amount, SourceProc)

SELECT AccountID, GETDATE(), Balance * InterestRate / 365, ‘AccrueDailyInterest’

FROM ClientAccounts

WHERE Status = ‘Active’

AND Balance > 0;

END

Выводы эксперта: Процедура начисляет ежедневный процент по формуле простого процента ((Balance * InterestRate / 365)). Результат записывается непосредственно в поле Balance таблицы ClientAccounts и дублируется в журнальную таблицу AccrualJournal. Начисление происходит только для активных счетов с положительным балансом.

3.3. Анализ функций и триггеров.

Функции (Scalar, Table-valued): Используются в вычислениях. Анализ аналогичен процедурам.

Триггеры (AFTER INSERT, INSTEAD OF UPDATE): Автоматические обработчики событий. Могут использоваться для:

Аудита: Запись истории изменений в отдельную таблицу (INSERTED, DELETED).

Валидации данных: Проверка сложных условий.

Каскадных изменений: Изменение связанных данных.

Сокрытия данных: INSTEAD OF триггер может подменить реальную операцию на фиктивную.

ГЛАВА 4. ЭКСТРАКЦИЯ И ВЕРИФИКАЦИЯ СОДЕРЖИМЫХ ДАННЫХ

4.1. Техники извлечения данных (Data Extraction).

Прямые SELECT-запросы: Для простых выборок.

Сложные джойны: Для объединения информации из нескольких таблиц (Клиент -> Договор -> Счет -> Транзакции).

Использование временных таблиц и Common Table Expressions (CTE): Для многоступенчатой обработки больших объемов.

Экспорт в аналитические форматы: Выгрузка результатов в CSV, Excel для последующего анализа в статистических пакетах (R, Python pandas).

4.2. Анализ финансовых данных и котировок (Вопрос 6).

Техническая проверка:

Источник: Есть ли таблицы-справочники StockSymbols, ExchangeRates?

Механизм обновления: Существуют ли процедуры с названиями типа UpdateQuotesFromYahoo, FetchRatesCBR? Проверить их код на наличие вызовов веб-сервисов.

Временные метки: Есть ли у котировок поля LastUpdated? Как часто они меняются?

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

Признаки фиктивности:

Отсутствие механизма автоматического обновления.

Котировки не изменяются со временем или изменяются детерминированно (простая последовательность).

В коде процедур используются захардкоженные (hardcoded) значения курсов.

4.3. Агрегация и анализ клиентской статистики (Вопросы 10, 12).
Создание сводного отчета:

sql

WITH ClientSummary AS (

SELECT

c.ClientID,

c.FullName,

SUM(CASE WHEN t.Type = ‘Deposit’ THEN t.Amount ELSE 0 END) AS TotalDeposits,

SUM(CASE WHEN t.Type = ‘Withdrawal’ THEN t.Amount ELSE 0 END) AS TotalWithdrawals,

SUM(CASE WHEN t.Type = ‘Interest’ THEN t.Amount ELSE 0 END) AS TotalInterestAccrued,

(SUM(CASE WHEN t.Type = ‘Deposit’ THEN t.Amount ELSE 0 END) —

SUM(CASE WHEN t.Type = ‘Withdrawal’ THEN t.Amount ELSE 0 END)) AS NetBalance

FROM Clients c

LEFT JOIN Transactions t ON c.ClientID = t.ClientID

GROUP BY c.ClientID, c.FullName

)

SELECT TOP 20 *,

RANK() OVER (ORDER BY TotalDeposits DESC) AS DepositRank,

RANK() OVER (ORDER BY NetBalance DESC) AS BalanceRank

FROM ClientSummary

ORDER BY TotalDeposits DESC;

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

5.1. Анализ встроенного аудита СУБД.

SQL Server Audit / Trace: Поиск файлов аудита (.sqlaudit, трассы). Настройка и чтение через sys.fn_get_audit_file.

PostgreSQL pgAudit: Анализ лог-файлов, сгенерированных расширением.

Журнал транзакций (Transaction Log): При наличии полной резервной копии и журналов можно попытаться прочитать историю операций с помощью специализированных утилит (ApexSQL Log, Log Rescue) или функций (fn_dblog). Позволяет увидеть, кто, когда и что изменил, даже если эти изменения позже были удалены.

5.2. Анализ пользовательских таблиц аудита.
Поиск таблиц с именами, содержащими Audit, Log, History. Анализ их структуры и содержания:

sql

— Найти все таблицы, связанные с аудитом

SELECT t.name AS TableName

FROM sys.tables t

WHERE t.name LIKE ‘%audit%’ OR t.name LIKE ‘%log%’ OR t.name LIKE ‘%history%’;

5.3. Реконструкция активности по временным меткам.
Критический анализ полей CreatedDate, ModifiedDate, TransactionDate.

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

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

Построение временной линии (Timeline Analysis): Использование инструментов типа Elastic Stack (ELK) или даже Excel Pivot Charts для визуализации последовательности событий.

5.4. Анализ связей с внешними системами (Вопрос 9).

В коде: Поиск строк подключения (ConnectionString), URL, имен серверов в текстах процедур и функций.

В конфигурации: Анализ связанных сервисов (Linked Servers в SQL Server), внешних источников данных.

Сетевой анализ: Если доступны логи сервера, поиск сетевых подключений к известным платежным шлюзам или биржевым API.

ГЛАВА 6. ИСПОЛЬЗОВАНИЕ СПЕЦИАЛИЗИРОВАННОГО ПО И АВТОМАТИЗАЦИЯ

6.1. Инструменты эксперта.

Основные СУБД-клиенты: SSMS, pgAdmin, MySQL Workbench, DBeaver (универсальный).

Форенсик-инструменты: Magnet AXIOM, EnCase, FTK – для извлечения файлов БД с носителей.

Специализированное ПО для анализа БД:

DBFrog SQL Examiner: Сравнение схем и данных.

Redgate SQL Toolbelt: Набор инструментов для анализа, сравнения, документирования.

Aqua Data Studio: Продвинутая аналитика и визуализация.

Языки программирования: Python (библиотеки pyodbc, sqlalchemy, pandas для анализа), R (для статистики), PowerShell (для автоматизации задач в экосистеме Microsoft).

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

Ежедневного мониторинга изменений в ключевых таблицах.

Массовой выгрузки данных по шаблону.

Проверки гипотез (например, «все клиенты, получившие более 20% годовых»).

Пример Python-скрипта для агрегации:

python

import pyodbc

import pandas as pd

conn = pyodbc.connect(‘DRIVER={SQL Server};SERVER=…’)

# Загрузка данных в DataFrame

df_transactions = pd.read_sql(«SELECT * FROM Transactions», conn)

# Агрегация с помощью pandas

summary = df_transactions.groupby(‘ClientID’).agg({‘Amount’: [‘sum’, ‘count’]})

# … дальнейший анализ …

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

Итоговый отчет должен быть технически точным, понятным и обоснованным.

7.1. Структура технической части заключения.

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

Реконструкция схемы: Приложенная ER-диаграмма и ее описание.

Анализ ключевых процедур: Приведенный код, его текстовое описание и выводы о реализованной логике.

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

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

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

7.2. Ключевые технические выводы.
На основе анализа эксперт может сформулировать технически корректные выводы, например:

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

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

«Анализ журнальных таблиц UserActivityLog выявил факты модификации записей о размере вкладов для клиентов из списка VIP пользователем с идентификатором admin в период с … по …».

ЗАКЛЮЧЕНИЕ

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