ВВЕДЕНИЕ: БАЗА ДАННЫХ КАК ЖИВОЙ ОРГАНИЗМ И ЕГО ДИССЕКЦИЯ

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

РАЗДЕЛ 1: СТРУКТУРНЫЙ АНАЛИЗ И РЕКОНСТРУКЦИЯ СХЕМЫ

1.1. Исследование системного каталога (System Catalog / INFORMATION_SCHEMA).
Это отправная точка. Запросы к метаданным позволяют получить карту всей БД без анализа каждой записи.

• Для PostgreSQL:

sql

— Все таблицы и их владельцы

SELECT schemaname, tablename, tableowner FROM pg_tables WHERE schemaname NOT IN (‘pg_catalog’, ‘information_schema’);

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

SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_name = ‘clients’;

— Внешние ключи

SELECT tc.table_name, kcu.column_name, ccu.table_name AS foreign_table_name, ccu.column_name AS foreign_column_name

FROM information_schema.table_constraints AS tc

JOIN information_schema.key_column_usage AS kcu ON tc.constraint_name = kcu.constraint_name

JOIN information_schema.constraint_column_usage AS ccu ON ccu.constraint_name = tc.constraint_name

WHERE tc.constraint_type = ‘FOREIGN KEY’;

• Для MySQL/MariaDB:

sql

SHOW TABLES;

DESCRIBE transactions;

SHOW CREATE TABLE clients; — Покажет всю DDL, включая ключи

• Для MS SQL Server:

sql

SELECT * FROM sys.tables;

SELECT * FROM sys.foreign_keys;

EXEC sp_help ‘transactions’; — Детальная информация о таблице

1.2. Анализ зависимостей объектов: представления, процедуры, триггеры.
Критически важно понять, какие объекты зависят от исследуемых таблиц.

• Поиск всех хранимых процедур и функций, обращающихся к таблице payments:

sql

— Для MS SQL

SELECT OBJECT_NAME(referencing_id) AS obj_name, o.type_desc

FROM sys.sql_expression_dependencies sed

JOIN sys.objects o ON sed.referencing_id = o.object_id

WHERE referenced_entity_name = ‘payments’;

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

sql

SELECT OBJECT_DEFINITION(OBJECT_ID(‘dbo.calculate_profit’));

• Анализ триггеров: Триггеры (ON INSERT/UPDATE/DELETE) часто содержат скрытую бизнес-логику (аудит, каскадные изменения). Их наличие на таблицах финансовых транзакций — ключевой объект исследования.

sql

SHOW TRIGGERS FROM database_name LIKE ‘transactions%’;

РАЗДЕЛ 2: ГЛУБОКИЙ АНАЛИЗ ДАННЫХ И ВЫЯВЛЕНИЕ АНОМАЛИЙ

2.1. Анализ временных рядов и паттернов транзакций.

• Выявление пиковой активности:

sql

SELECT DATE(timestamp) as day, HOUR(timestamp) as hour, COUNT(*) as tx_count, SUM(amount) as total_amount

FROM transactions

WHERE type = ‘IN’

GROUP BY DATE(timestamp), HOUR(timestamp)

ORDER BY total_amount DESC

LIMIT 100;

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

sql

— Упрощенный поиск замкнутых цепочек за короткий период

WITH Chain AS (

SELECT t1.from_acc, t1.to_acc, t1.amount, t1.timestamp as t1_time,

t2.timestamp as t2_time,

TIMESTAMPDIFF(SECOND, t1.timestamp, t2.timestamp) as diff_sec

FROM transactions t1

JOIN transactions t2 ON t1.to_acc = t2.from_acc AND t1.from_acc = t2.to_acc

WHERE t1.amount = t2.amount

AND t1.timestamp < t2.timestamp

AND TIMESTAMPDIFF(SECOND, t1.timestamp, t2.timestamp) BETWEEN 1 AND 300 — Цепочка длится до 5 минут

)

SELECT * FROM Chain;

2.2. Статистический анализ для выявления «особых» клиентов и манипуляций.

• Топ-20 клиентов по нетто-позиции (внесено минус выведено):

sql

SELECT client_id,

SUM(CASE WHEN type = ‘IN’ THEN amount ELSE 0 END) as total_in,

SUM(CASE WHEN type = ‘OUT’ THEN amount ELSE 0 END) as total_out,

(SUM(CASE WHEN type = ‘IN’ THEN amount ELSE 0 END) — SUM(CASE WHEN type = ‘OUT’ THEN amount ELSE 0 END)) as net_position

FROM transactions

GROUP BY client_id

ORDER BY net_position DESC — Самые пострадавшие

— ORDER BY net_position ASC — Те, кто вывел больше, чем внёс (подозрительно)

LIMIT 20;

• Поиск аномально круглых сумм или частых операций с одинаковой суммой (признак автоматизированного мошенничества):

sql

SELECT amount, COUNT(*) as frequency

FROM transactions

WHERE type = ‘IN’

GROUP BY amount

HAVING COUNT(*) > 10 — Порог частоты

ORDER BY frequency DESC;

2.3. Анализ качества и достоверности рыночных данных (для псевдоброкерских систем).

• Проверка актуальности котировок:

sql

SELECT symbol, COUNT(*) as records,

MIN(quote_timestamp) as first_date,

MAX(quote_timestamp) as last_date,

MAX(quote_timestamp) — MIN(quote_timestamp) as date_range

FROM quotes

GROUP BY symbol

ORDER BY last_date ASC; — Символы с устаревшими данными будут в начале

• Поиск артефактов генерации: одинаковые котировки для разных символов в одно время (невозможно на реальном рынке):

sql

SELECT quote_timestamp, COUNT(DISTINCT symbol) as unique_symbols, COUNT(*) as total_records

FROM quotes

GROUP BY quote_timestamp

HAVING COUNT(DISTINCT symbol) > 1 AND COUNT(DISTINCT bid_price) = 1 — У всех разный символ, но одинаковая цена

LIMIT 10;

РАЗДЕЛ 3: ДЕКОМПИЛЯЦИЯ И АНАЛИЗ БИЗНЕС-ЛОГИКИ (ХРАНИМЫЕ ПРОЦЕДУРЫ, ТРИГГЕРЫ)

Это ядро IT-экспертизы.

3.1. Реконструкция алгоритма начисления процентов.
Пример реальной процедуры и её анализ:

sql

CREATE PROCEDURE accrue_daily_interest()

BEGIN

DECLARE done INT DEFAULT FALSE;

DECLARE v_client_id INT;

DECLARE v_balance DECIMAL(18,2);

DECLARE cur CURSOR FOR SELECT client_id, balance FROM accounts WHERE status = ‘active’;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

OPEN cur;

read_loop: LOOP

FETCH cur INTO v_client_id, v_balance;

IF done THEN

LEAVE read_loop;

END IF;

— КРИТИЧЕСКИЙ БЛОК: Формула расчета

SET @interest = v_balance * 0.003; — Фиксированная ставка 0.3% в день (109.5% годовых!)

— Никаких ссылок на внешние рынки!

— Запись начисления

INSERT INTO transactions (client_id, type, amount, description)

VALUES (v_client_id, ‘INTEREST’, @interest, CONCAT(‘Daily interest accrue’));

— Обновление баланса

UPDATE accounts SET balance = balance + @interest WHERE client_id = v_client_id;

END LOOP;

CLOSE cur;

END;

IT-вывод: Алгоритм использует астрономическую фиксированную ставку, не зависящую от какой-либо рыночной деятельности. Это прямое доказательство финансовой пирамиды.

3.2. Анализ процедур, связанных с выводом средств.
Поиск «правил»: кому можно выводить, есть ли лимиты, комиссии.

sql

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

CREATE PROCEDURE request_withdrawal(IN p_client_id INT, IN p_amount DECIMAL(18,2))

BEGIN

DECLARE v_ref_count INT;

SELECT COUNT(*) INTO v_ref_count FROM referrals WHERE referrer_id = p_client_id;

IF v_ref_count >= 5 THEN — Можно выводить только при наличии 5 рефералов

INSERT INTO withdrawal_requests (client_id, amount, status)

VALUES (p_client_id, p_amount, ‘PENDING’);

ELSE

SIGNAL SQLSTATE ‘45000’ SET MESSAGE_TEXT = ‘Withdrawal condition not met’;

END IF;

END;

IT-вывод: Система ограничивает вывод средств, привязывая его к сетевой активности, что характерно для пирамид.

РАЗДЕЛ 4: ФОРЕНЗИК-АНАЛИЗ: ЖУРНАЛЫ, АУДИТ, ЦИФРОВЫЕ СЛЕДЫ ПОЛЬЗОВАТЕЛЕЙ

4.1. Анализ журналов транзакций СУБД (Transaction Logs, Binlog, WAL).
Даже если данные в таблицах удалены, следы могут оставаться в физических логах.

• Цель: Восстановление последовательности операций INSERT/UPDATE/DELETE с точностью до миллисекунды.
• Инструменты:
  • MySQL: mysqlbinlog утилита для парсинга бинарного лога.
  • PostgreSQL: Для чтения Write-Ahead Log (WAL) требуются специализированные утилиты или доступ к слотам репликации.
  • MS SQL: Файлы *.ldf могут быть проанализированы через fn_dblog (недокументированная функция) или специализированным софтом (ApexSQL Log, Quest Toad).
• Пример задачи: Найти момент удаления таблицы old_transactions и пользователя, который это сделал.

4.2. Анализ таблиц аудита внутри БД.

• Поиск встроенных механизмов аудита: Проверить наличие таблиц с именами audit_log, change_history, dml_log.
• Анализ триггеров на аудит: Часто аудит реализуется через триггеры, которые пишут копию измененной строки в лог-таблицу.

sql

— Пример триггера на аудит

CREATE TRIGGER audit_client_update AFTER UPDATE ON clients

FOR EACH ROW

BEGIN

INSERT INTO client_audit (client_id, changed_field, old_value, new_value, changed_by, changed_at)

VALUES (NEW.id, ‘balance’, OLD.balance, NEW.balance, CURRENT_USER(), NOW());

END;

IT-вывод: Если такие триггеры существуют, они — золотая жила для установления фактов изменений данных.

4.3. Анализ подключений и сессий.

• Запрос активных/исторических подключений (зависит от СУБД и настроек логирования):

sql

— PostgreSQL: pg_stat_activity (текущие сессии)

SELECT usename, client_addr, application_name, backend_start, query

FROM pg_stat_activity

WHERE state = ‘active’;

— MySQL: information_schema.processlist

SELECT * FROM information_schema.PROCESSLIST;

• Поиск в логах ошибок СУБД: Неудачные попытки входа, ошибки выполнения процедур могут указывать на время атаки или сбоя.

РАЗДЕЛ 5: ИНТЕГРАЦИОННЫЙ АНАЛИЗ И ВНЕШНИЕ СВЯЗИ

5.1. Анализ строк подключений (Connection Strings).
Поиск в конфигурационных файлах приложения (web.config, appsettings.json, .env) строк вида:

text

Server=db1.host.com;Database=finance_db;User Id=app_user;Password=***;

Это позволяет установить факт связи между фронтендом (сайтом) и конкретной БД, а также выявить все среды (production, staging, backup).

5.2. Анализ задач планировщика (Cron, SQL Agent).

• На уровне ОС: Просмотр заданий cron (Linux) или Task Scheduler (Windows) на сервере БД. Какие скрипты (*.sql, *.sh, *.ps1) запускались и с какой периодичностью (ежедневное начисление, еженедельный отчет)?
• Внутри СУБД:

sql

— MS SQL Server Jobs

SELECT * FROM msdb.dbo.sysjobs;

— Планировщик событий MySQL (Event Scheduler)

SHOW EVENTS;

5.3. Реконструкция ETL-процессов (Extract, Transform, Load).
Как данные попадали в БД?

• Наличие папок incoming, processed на сервере.
• Анализ BULK INSERT операций в логах.
• Поиск скриптов импорта (*.sql, *.py, *.csv).

РАЗДЕЛ 6: ПРАКТИЧЕСКИЕ ШАГИ И ИНСТРУМЕНТАРИЙ IT-ЭКСПЕРТА

1. Изоляция и клонирование: Работа только с криминалистической копией. Использование dd, FTK Imager, dcfldd. Валидация хэш-сумм (SHA-256).
2. Поднятие изолированной среды: Развертывание виртуальной машины с той же версией СУБД, что и оригинал. Восстановление БД из бекапа.
3. Инструментарий:
   • Основные клиенты СУБД: psql, mysql, sqlcmd, SQL Server Management Studio (SSMS), pgAdmin, DBeaver.
   • Для анализа метаданных и выполнения сложных запросов: DBeaver (универсальный), DataGrip.
   • Для логов и форензика: mysqlbinlog, ApexSQL Log, WAL анализаторы, Elastic Stack (для больших объемов логов).
   • Для визуализации графов и связей: draw.io, yEd, Gephi (на основе экспортированных данных о связях).
   • Для анализа кода процедур: Любой продвинутый текстовый редактор с подсветкой SQL (VSCode, Notepad++).
4. Документирование ВСЕГО: Каждый выполненный SQL-запрос, его цель и результат должны сохраняться в лог-файл сессии. Скриншоты ключевых структур. Это обеспечивает воспроизводимость и защищает эксперта от обвинений в манипуляции.

ЗАКЛЮЧЕНИЕ: ОТ СТРОК КОДА К СУДЕБНОМУ РЕШЕНИЮ

IT-экспертиза базы данных — это кропотливая работа археолога в мире битов и байтов. Эксперт должен мыслить как архитектор системы, пытаясь понять замысел её создателей, и как детектив, выискивая следы, которые они пытались замести. Результатом его работы должен стать не просто отчёт с цифрами, а технически безупречное, логически связанное повествование, в котором:

• Структура БД становится схемой преступного предприятия.
• Хранимые процедуры — это письменные приказы и инструкции.
• Данные в таблицах — это учётные книги и финансовые отчёты.
• Журналы аудита и логов — это свидетельские показания системы о действиях пользователей.

Только такой, предельно технически детализированный и методологически выверенный подход позволяет превратить сырые данные в неопровержимые, объективные доказательства, способные выдержать самую жесткую перекрестную проверку в суде. Эксперт-IT не дает правовую оценку, но он предоставляет тот самый цифровой «слепок реальности», на основе которого следствие и суд могут сделать обоснованные правовые выводы.