Экспертиза баз данных в ходе расследований: Методика, инструменты и практика для IT-экспертов

Введение: База данных как сложная система — почему стандартные методы изъятия недостаточны

В контексте цифрового расследования традиционный подход, фокусирующийся на файловой системе и артефактах ОС, часто оказывается поверхностным при столкновении с серверными системами управления базами данных (СУБД). База данных — это не просто файл с расширением .mdf или .sqlite. Это живая, работающая система со своей внутренней логикой, состоянием в памяти, транзакционными журналами, конфигурацией и процессами. Ее исследование требует от эксперта глубоких знаний в области архитектуры СУБД, теории реляционных баз данных, языка SQL и системного администрирования.

Данная статья представляет собой техническое руководство для IT-экспертов и специалистов по кибербезопасности, вовлеченных в процессы расследований. Мы сконцентрируемся на практических аспектах извлечения, анализа и интерпретации данных, рассматривая БД как многослойный объект исследования.

Часть 1: Подготовительный этап и корректное изъятие данных

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

1.1. Идентификация окружения
Первая задача — понять экосистему:

Тип СУБД: Microsoft SQL Server, Oracle, PostgreSQL, MySQL/MariaDB, SQLite, NoSQL (MongoDB, Cassandra). Каждая имеет кардинально разные механизмы хранения и инструменты анализа.

Версия: Версия определяет доступные функции, синтаксис SQL и структуру системных таблиц.

Способ развертывания: Локальный сервер, облачный инстанс (AWS RDS, Azure SQL), контейнеризированное приложение (Docker). От этого зависит метод доступа и изъятия.

Операционная система сервера: Windows Server, Linux-дистрибутив.

1.2. Стратегия создания доказательной копии (Forensic Image)
НЕДОПУСТИМО просто копировать файлы данных через проводник во время работы СУБД. Они могут быть повреждены или находиться в неконсистентном состоянии.

Предпочтительный метод №1: Дамп через административные инструменты.

Для MySQL: mysqldump —single-transaction —routines —events —triggers —all-databases > full_dump.sql

Для PostgreSQL: pg_dumpall -U postgres > full_dump.sql

Для MS SQL Server: Генерация скриптов через SQL Server Management Studio (SSMS) или sqlpackage.exe.

Преимущество: Получаем логически целостный снимок в виде SQL-скриптов, включая схему, данные, процедуры, триггеры и права доступа.

Метод №2: Остановка службы и копирование файлов.

Остановить службу СУБД.

Создать побитовую копию (с помощью FTK Imager, dd, Guymager) всех связанных файлов:

Файлы данных (.mdf, .ndf для SQL Server; ibdata1 для MySQL InnoDB).

Файлы журналов транзакций (.ldf для SQL Server; бинарные логи для MySQL).

Файлы конфигурации (my.ini, postgresql.conf, sqlservr.conf).

Зафиксировать хэш-суммы (SHA-256) всех файлов.

Метод №3: Работа с «горячей» системой (если остановка невозможна).

Использование встроенных механизмов резервного копирования СУБД (BACKUP DATABASE в T-SQL, CREATE BACKUP в Oracle).

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

1.3. Восстановление копии в лабораторной среде
Работать необходимо с изолированной копией, развернутой на контролируемом экспертом стенде.

Установить идентичную или совместимую версию СУБД.

Восстановить дамп или присоединить файлы БД.

Важно: Задокументировать все шаги для обеспечения воспроизводимости.

Часть 2: Глубинный анализ архитектуры и метаданных

Ответы на большинство вопросов следователя начинаются с изучения системного каталога (Data Dictionary).

2.1. Реверс-инжиниринг схемы данных
Использование SQL-запросов к системным представлениям:

sql

— Для MySQL/PostgreSQL (INFORMATION_SCHEMA — стандарт ANSI)

SELECT TABLE_NAME, TABLE_TYPE, ENGINE, TABLE_ROWS

FROM INFORMATION_SCHEMA.TABLES

WHERE TABLE_SCHEMA = ‘название_базы’;

 

SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_KEY

FROM INFORMATION_SCHEMA.COLUMNS

WHERE TABLE_NAME = ‘название_таблицы’;

 

— Для MS SQL Server

SELECT t.name AS TableName, s.name AS SchemaName, p.rows

FROM sys.tables t

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

INNER JOIN sys.indexes i ON t.object_id = i.object_id

INNER JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id;

 

SELECT fk.name AS FK_Name,

tp.name AS Parent_Table,

tr.name AS Referenced_Table

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;

Результат: Строится Entity-Relationship Diagram (ERD) — карта всех таблиц, их столбцов и связей. Это основа для понимания предметной области.

2.2. Анализ программных объектов

Хранимые процедуры и функции: Их код — это бизнес-логика системы.

sql

— Для MS SQL Server

SELECT name, type_desc, definition

FROM sys.sql_modules m

INNER JOIN sys.objects o ON m.object_id = o.object_id

WHERE o.type IN (‘P’, ‘FN’, ‘IF’); — Процедуры, скалярные и табличные функции

 

— Для PostgreSQL

SELECT proname, prosrc

FROM pg_proc

WHERE pronamespace = (SELECT oid FROM pg_namespace WHERE nspname = ‘public’);

Анализ:

Поиск ключевых операторов INSERT, UPDATE, DELETE, SELECT INTO.

Выявление математических формул (расчет процентов, комиссий).

Анализ потоков данных: источники (FROM) и приемники (INTO).

Поиск динамического SQL (EXEC, sp_executesql) — может указывать на сложную или намеренно скрытую логику.

Триггеры: Автоматические обработчики событий. Критически важны для понимания «скрытой» логики.

sql

SELECT name, object_name(parent_id) AS parent_table, type_desc, is_instead_of_trigger

FROM sys.triggers;

Анализ триггера показывает: «При обновлении таблицы accounts автоматически делается запись в таблицу audit_log».

Представления (Views): Анализ сложных VIEW показывает, какие данные и в каком агрегированном виде были важны для пользователей.

Планы выполнения (Execution Plans): В некоторых СУБД можно найти кэшированные планы выполнения запросов. Они показывают, какие индексы использовались и как оптимизировались запросы, что косвенно говорит о нагрузке и паттернах доступа.

Часть 3: Практическое расследование: отвечая на вопросы следователя через SQL и анализ кода

3.1. Назначение БД и ключевые взаимосвязи (Вопросы 1-4, 6)

Метод: Анализ ERD, построенной на этапе 2.1.

Вывод: «База является ядром системы учета клиентов инвестиционного клуба. Центральные сущности: clients (клиенты), contracts (договоры), transactions (транзакции). Связь contracts.client_id -> clients.id обеспечивает учет всех договоров клиента.»

3.2. Содержание информации (Вопросы 2, 10, 14)

Метод: Селективные запросы и анализ моделей данных.

sql

— Структура клиентской информации

SELECT COLUMN_NAME, DATA_TYPE

FROM INFORMATION_SCHEMA.COLUMNS

WHERE TABLE_NAME = ‘clients’;

 

— Выборка реальных данных (первые 10 строк с маскировкой PII)

SELECT id, date_created, status, country_code

FROM clients

LIMIT 10;

3.3. Анализ хранимых процедур (Вопрос 5)

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

sql

CREATE PROCEDURE AccrueDailyInterest

AS

BEGIN

UPDATE accounts

SET balance = balance * (1 + @daily_rate) — @daily_rate берется из таблицы settings

WHERE status = ‘active’;

INSERT INTO interest_accruals (account_id, amount, date) — Логирование начисления

SELECT id, balance * @daily_rate, GETDATE()

FROM accounts

WHERE status = ‘active’;

END

Что делает: Ежедневно увеличивает баланс на фиксированный процент.

Куда записывает: Логирует каждое начисление в таблицу interest_accruals.

Ключевой вывод: Алгоритм не зависит от внешних рыночных данных.

3.4. Поиск биржевых данных (Вопрос 6)

Метод: Поиск таблиц или процедур, связанных с внешними API.

sql

— Поиск таблиц с котировками

SELECT TABLE_NAME

FROM INFORMATION_SCHEMA.TABLES

WHERE TABLE_NAME LIKE ‘%quote%’ OR TABLE_NAME LIKE ‘%price%’ OR TABLE_NAME LIKE ‘%symbol%’;

 

— Поиск в коде процедур упоминаний внешних URL или API

SELECT name, definition

FROM sys.sql_modules

WHERE definition LIKE ‘%api.finance%’ OR definition LIKE ‘%yahoo%’ OR definition LIKE ‘%alphavantage%’;

Отсутствие результатов — само по себе значимый вывод.

3.5. Операции и алгоритмы начисления процентов (Вопросы 7, 8)

Метод: Корреляционный анализ между таблицами транзакций, начислений и остатков.

sql

— Паттерн операций «ввод-вывод»

SELECT type, COUNT(*) as count, SUM(amount) as total_sum

FROM transactions

GROUP BY type

ORDER BY total_sum DESC;

 

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

SELECT

(SELECT SUM(amount) FROM transactions WHERE type = ‘deposit’) as total_deposits,

(SELECT SUM(amount) FROM interest_accruals) as total_interest_accrued,

(SELECT SUM(amount) FROM transactions WHERE type = ‘withdrawal’) as total_withdrawals;

3.6. Подключение к внешним сервисам (Вопрос 9)

Метод:

Анализ таблиц api_keys, service_configs.

Поиск в конфигурационных файлах строк подключения (connection strings) к внешним хостам.

Анализ задач (Jobs) в планировщике СУБД (SQL Server Agent, pgAgent) на наличие вызовов внешних скриптов или URL.

3.7. Аудит пользователей и статистика (Вопросы 15, 16)

Источники информации:

Таблицы users, logins.

Журналы аудита СУБД (SQL Server Audit, PostgreSQL Audit Extension).

Стандартные журналы ошибок и запросов.

Таблицы-аудита, созданные триггерами внутри самой БД.

Анализ:

sql

— Статистика входов по пользователям (если логи ведутся в таблицу)

SELECT user_id, COUNT(*) as login_count, MIN(login_time) as first_login, MAX(login_time) as last_login

FROM user_login_audit

GROUP BY user_id

ORDER BY login_count DESC;

 

— Поиск подозрительных активностей (ночные часы, множество операций за короткий период)

SELECT *

FROM transaction_audit

WHERE DATEPART(HOUR, operation_time) BETWEEN 0 AND 5

ORDER BY operation_time DESC;

3.8. Выделение значимых клиентов и анализ связей (Вопросы 11-13)

Метод: Сложные аналитические запросы.

sql

— Топ-20 клиентов по вложениям с указанием их менеджеров

SELECT TOP 20

c.id,

c.name,

m.name as manager_name,

SUM(CASE WHEN t.type = ‘deposit’ THEN t.amount ELSE 0 END) as total_deposit,

SUM(CASE WHEN t.type = ‘withdrawal’ THEN t.amount ELSE 0 END) as total_withdrawal

FROM clients c

LEFT JOIN managers m ON c.manager_id = m.id

LEFT JOIN contracts cont ON c.id = cont.client_id

LEFT JOIN transactions t ON cont.id = t.contract_id

GROUP BY c.id, c.name, m.name

ORDER BY total_deposit DESC;

 

— Выявление цепочек транзакций между клиентами (признак «переливов»)

SELECT

t1.client_id as from_client,

t2.client_id as to_client,

COUNT(*) as transaction_count,

SUM(t1.amount) as total_amount

FROM transactions t1

INNER JOIN transactions t2 ON t1.description LIKE CONCAT(‘%Transfer to ‘, t2.client_id, ‘%’)

WHERE t1.type = ‘outgoing’ AND t2.type = ‘incoming’

GROUP BY t1.client_id, t2.client_id

HAVING COUNT(*) > 5;

Часть 4: Специальные случаи и сложные сценарии

4.1. Анализ удаленных и измененных данных

Исследование журналов транзакций (Transaction Log): При наличии полного резерва и файлов логов можно восстановить историю изменений пооперационно, используя функции типа fn_dblog (SQL Server) или инструментов типа binlog2sql (MySQL).

Временные таблицы и Soft Delete: Проверка наличия флагов is_deleted или перемещения записей в архивные таблицы.

4.2. NoSQL базы данных (MongoDB)

Подход кардинально меняется. Используются native tools (mongodump, mongoexport).

Анализ коллекций вместо таблиц, документов вместо строк.

Фокус на вложенных структурах и массивах внутри документов.

4.3. Шифрование данных

Шифрование на уровне СУБД (TDE — Transparent Data Encryption): Файлы данных зашифрованы. Требуются сертификаты и ключи для расшифровки при восстановлении на другом сервере.

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

4.4. Облачные БД (AWS RDS, Azure SQL Database)

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

Важно запросить у провайдера логи аудита и журналы производительности.

Заключение и рекомендации для IT-эксперта

Исследование базы данных — это методичный процесс, сочетающий навыки администратора, разработчика и аналитика.

Ключевые принципы:

Не навреди: Работай только с копией. Любое прямое подключение к «живой» БД расследуемого дела может изменить доказательства.

Документируй всё: От команды подключения до каждого значимого SQL-запроса. Отчет должен позволять воспроизвести твои шаги.

Проверяй гипотезы данными: Любое предположение о работе системы должно быть подтверждено конкретным запросом.

Используй правильные инструменты: От специализированных (ApexSQL Log, Redgate SQL Prompt) до классических (Adminer, DBeaver, собственные скрипты).

Мысли как архитектор системы: Постарайся понять не только «что» хранится, но и «зачем» и «как» это использовалось.

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