ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ПРОВЕДЕНИЕ КОМПЬЮТЕРНОЙ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

1. ОПРЕДЕЛЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

Компьютерная экспертиза баз данных — это инженерная дисциплина, направленная на системное исследование структурированных информационных систем (баз данных) с применением формализованных методов извлечения, анализа и интерпретации данных. В отличие от общих подходов digital forensics, компьютерная экспертиза баз данных фокусируется на реляционных и NoSQL-системах как на сложных инженерных объектах, требующих глубокого понимания их внутренней архитектуры, механизмов хранения и бизнес-логики.

Область применения:

• Судебные и досудебные расследования экономических преступлений
• Арбитражные споры по IT-контрактам
• Инциденты информационной безопасности
• Due diligence при сделках M&A
• Технический аудит корпоративных систем

2. АРХИТЕКТУРА ПРОЦЕССА КОМПЬЮТЕРНОЙ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

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

2.1. Фаза 1: ПОДГОТОВКА ИНЖЕНЕРНОЙ СРЕДЫ

Вход: Исходные файлы БД, документация, журналы.
Инструменты: Изолированный стенд, СУБД, средства анализа.
Выход: Восстановленная БД, верифицированная копия.

text

Технологическая цепочка:

1. Валидация исходных данных → проверка хэш-сумм (SHA-256)
2. Создание изолированной среды → Docker/VirtualBox с идентичной ОС
3. Восстановление БД →

— Для SQL Server: ATTACH .mdf/.ldf файлов

— Для PostgreSQL: psql -f dump.sql

— Для MySQL: mysql < backup.sql

4. Настройка инструментов →

— Профилировщики запросов (SQL Profiler, pg_stat_statements)

— Мониторы производительности (Prometheus + Grafana)

— Анализаторы кода (SonarQube, PMD)

2.2. Фаза 2: РЕВЕРС-ИНЖИНИРИНГ СХЕМЫ ДАННЫХ

Метод: Анализ системных каталогов СУБД.
Цель: Построение полной модели данных.

sql

— Пример инженерного запроса для анализа схемы в PostgreSQL

WITH table_analysis AS (

SELECT

t.table_schema,

t.table_name,

t.table_type,

COUNT(c.column_name) as columns_count,

SUM(CASE WHEN c.is_nullable = ‘YES’ THEN 1 ELSE 0 END) as nullable_columns,

SUM(CASE WHEN pk.column_name IS NOT NULL THEN 1 ELSE 0 END) as pk_columns

FROM information_schema.tables t

LEFT JOIN information_schema.columns c

ON t.table_schema = c.table_schema

AND t.table_name = c.table_name

LEFT JOIN (

SELECT ku.table_schema, ku.table_name, ku.column_name

FROM information_schema.key_column_usage ku

WHERE ku.constraint_name IN (

SELECT constraint_name

FROM information_schema.table_constraints

WHERE constraint_type = ‘PRIMARY KEY’

)

) pk ON c.table_schema = pk.table_schema

AND c.table_name = pk.table_name

AND c.column_name = pk.column_name

WHERE t.table_schema NOT IN (‘pg_catalog’, ‘information_schema’)

GROUP BY t.table_schema, t.table_name, t.table_type

)

SELECT * FROM table_analysis

ORDER BY columns_count DESC;

2.3. Фаза 3: АНАЛИЗ ПРОГРАММНОЙ ЛОГИКИ

Инженерный подход: Статический + динамический анализ кода.

sql

— Инженерный анализ хранимой процедуры в MS SQL Server

CREATE PROCEDURE AnalyzeProcedureLogic

@ProcedureName NVARCHAR(255)

AS

BEGIN

— Получение полного текста процедуры

SELECT

definition,

OBJECT_DEFINITION(OBJECT_ID(@ProcedureName)) as proc_code,

— Анализ зависимостей

OBJECT_NAME(referencing_id) as referencing_object,

referenced_entity_name

FROM sys.sql_expression_dependencies

WHERE referenced_entity_name = @ProcedureName

— Построение графа вызовов

;WITH CallGraph AS (

SELECT

OBJECT_NAME(object_id) as caller,

referenced_entity_name as callee

FROM sys.sql_expression_dependencies

WHERE referenced_id IS NOT NULL

)

SELECT * FROM CallGraph

WHERE callee = @ProcedureName OR caller = @ProcedureName;

END;

3. ИНЖЕНЕРНЫЕ МЕТОДЫ КОМПЬЮТЕРНОЙ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

3.1. МЕТОД ТРАНЗАКЦИОННОГО АНАЛИЗА

Назначение: Восстановление полной хронологии изменений данных.

Алгоритм для SQL Server:

sql

— Анализ журнала транзакций через недокументированную функцию fn_dblog

SELECT

[Current LSN],

[Operation],

[Context],

[Transaction ID],

[Begin Time],

[End Time],

[Transaction Name],

[Transaction SID],

[Num Elements],

[RowLog Contents 0],

[RowLog Contents 1]

FROM fn_dblog(NULL, NULL)

WHERE [Transaction Name] = ‘UPDATE’

AND [Begin Time] > ‘2024-01-01’

ORDER BY [Current LSN] DESC;

Инженерная интерпретация:

Операция LOP_MODIFY_ROW → изменение данных

Контекст LCX_HEAP/LCX_CLUSTERED → тип объекта

RowLog Contents → бинарное представление изменений

3.2. МЕТОД СРАВНИТЕЛЬНОГО АНАЛИЗА СОСТОЯНИЙ (DIFF ANALYSIS)

Инженерная реализация через временные таблицы:

sql

— Создание снимков состояния на разные даты

CREATE TABLE #Snapshot1 (

id INT PRIMARY KEY,

data NVARCHAR(MAX),

checksum INT

);

CREATE TABLE #Snapshot2 (

id INT PRIMARY KEY,

data NVARCHAR(MAX),

checksum INT

);

— Расчет дельты изменений

WITH DeltaAnalysis AS (

SELECT

COALESCE(s1.id, s2.id) as record_id,

CASE

WHEN s1.id IS NULL THEN ‘INSERTED’

WHEN s2.id IS NULL THEN ‘DELETED’

WHEN s1.checksum != s2.checksum THEN ‘MODIFIED’

ELSE ‘UNCHANGED’

END as change_type,

s1.data as old_value,

s2.data as new_value

FROM #Snapshot1 s1

FULL OUTER JOIN #Snapshot2 s2 ON s1.id = s2.id

)

SELECT * FROM DeltaAnalysis

WHERE change_type != ‘UNCHANGED’;

3.3. МЕТОД СТАТИСТИЧЕСКОГО ВЫВОДА О БИЗНЕС-ПРОЦЕССАХ

Инженерный подход: Применение машинного обучения для кластеризации транзакций.

python

# Пример Python-скрипта для анализа паттернов в БД

import pandas as pd

from sklearn.cluster import DBSCAN

from sqlalchemy import create_engine

class TransactionPatternAnalyzer:

def __init__(self, connection_string):

self.engine = create_engine(connection_string)

def extract_features(self, start_date, end_date):

«»»Извлечение признаков для анализа паттернов»»»

query = f»»»

SELECT

user_id,

transaction_type,

amount,

DATEPART(hour, timestamp) as hour,

DATEPART(dow, timestamp) as day_of_week,

COUNT(*) OVER(PARTITION BY user_id) as user_total_tx,

AVG(amount) OVER(PARTITION BY user_id) as user_avg_amount

FROM transactions

WHERE timestamp BETWEEN ‘{start_date}’ AND ‘{end_date}’

«»»

df = pd.read_sql(query, self.engine)

return self.normalize_features(df)

def detect_anomalies(self, features):

«»»Обнаружение аномальных паттернов через кластеризацию»»»

clustering = DBSCAN(eps=0.5, min_samples=10)

labels = clustering.fit_predict(features)

return labels

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

4.1. СТЕНДОВАЯ АРХИТЕКТУРА

text

Схема инженерного стенда:

┌─────────────────────────────────────────────────────┐

│                 ИЗОЛИРОВАННАЯ СЕТЬ                  │

├─────────────┬──────────────┬───────────────────────┤

│  ХОСТ-МАШИНА│   КОНТЕЙНЕР  │      КОНТЕЙНЕР        │

│             │    СУБД      │    АНАЛИТИЧЕСКИЙ      │

│  VMware     │  PostgreSQL  │    Jupyter + Python   │

│  ESXi       │  SQL Server  │    R Studio           │

│             │  MySQL       │                       │

└─────────────┴──────────────┴───────────────────────┘

Технические требования к стенду:

Минимум 32 ГБ RAM

SSD NVMe 1 ТБ

Поддержка вложенной виртуализации

Сетевая изоляция (air-gap)

Резервное питание (UPS)

4.2. ИНСТРУМЕНТАЛЬНЫЙ СТЕК

Для реляционных БД:

Анализ производительности:

SQL Server: Query Store, Extended Events

PostgreSQL: pg_stat_statements, auto_explain

MySQL: Performance Schema, Slow Query Log

Анализ структуры:

SchemaCrawler (автоматическое построение ERD)

Redgate SQL Toolbelt

JetBrains DataGrip

Динамический анализ:

pt-query-digest (MySQL)

pgBadger (PostgreSQL)

SQL Server Profiler

Для NoSQL БД:

MongoDB: mongodump, mongorestore, Compass Aggregation Pipeline

Cassandra: nodetool, cqlsh, SSTabledump

Redis: redis-rdb-tools, redis-cli —bigkeys

5. ПРАКТИЧЕСКИЕ ИНЖЕНЕРНЫЕ КЕЙСЫ

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

Проблема: Анализ таблицы с 500+ млн записей приводит к таймаутам.
Инженерное решение: Применение оконных функций и временных таблиц.

sql

— Неэффективный запрос (full scan)

SELECT user_id, SUM(amount), COUNT(*)

FROM transactions

WHERE date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’

GROUP BY user_id

HAVING SUM(amount) > 1000000;

— Оптимизированный инженерный подход

WITH daily_aggregates AS (

SELECT

user_id,

date,

SUM(amount) as daily_total,

COUNT(*) as daily_count

FROM transactions

WHERE date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’

GROUP BY user_id, date

),

user_totals AS (

SELECT

user_id,

SUM(daily_total) as total_amount,

SUM(daily_count) as total_count

FROM daily_aggregates

GROUP BY user_id

)

SELECT * FROM user_totals

WHERE total_amount > 1000000;

— Индекс: CREATE INDEX idx_transactions_user_date ON transactions(user_id, date, amount)

КЕЙС 2: АНАЛИЗ РАСПРЕДЕЛЕННОЙ БАЗЫ ДАННЫХ (SHARDED CLUSTER)

Проблема: Исследование данных, распределенных по 12 шардам.
Инженерное решение: Параллельный сбор и агрегация данных.

bash

#!/bin/bash

# Параллельный сбор данных с шардов

declare -a SHARDS=(«shard1:27017» «shard2:27017» «shard3:27017″)

RESULT_DIR=»/forensics/shard_analysis_$(date +%Y%m%d_%H%M%S)»

mkdir -p $RESULT_DIR

for shard in «${SHARDS[@]}»; do

# Параллельный дамп каждой шарды

mongodump —host $shard —db target_db —collection transactions \

—out «$RESULT_DIR/$shard» &

done

wait

# Агрегация результатов

for shard_dir in $RESULT_DIR/*; do

mongoexport —collection transactions \

—file «$shard_dir/target_db/transactions.json» \

—jsonArray |

jq ‘[.[] | {user: .userId, amount: .amount, date: .timestamp}]’ \

>> «$RESULT_DIR/combined_analysis.json»

done

КЕЙС 3: ВОССТАНОВЛЕНИЕ УДАЛЕННЫХ ДАННЫХ ИЗ БИНАРНЫХ ЛОГОВ

Инженерный алгоритм:

Извлечение бинарных логов: mysqlbinlog —base64-output=DECODE-ROWS mysql-bin.000001

Фильтрация по времени и таблице: | grep -A 20 -B 5 ‘DELETE FROM target_table’

Реконструкция SQL: Преобразование бинарного формата в SQL-команды

Валидация: Сравнение с backup (если есть)

sql

— Инженерный запрос для поиска следов удаления в SQL Server

SELECT

[Transaction ID],

[Begin Time],

[End Time],

[Transaction Name],

[Operation],

[RowLog Contents 0],

[RowLog Contents 1]

FROM fn_dblog(NULL, NULL)

WHERE [Operation] IN (‘LOP_DELETE_ROWS’, ‘LOP_MODIFY_ROW’)

AND [Transaction Name] != ‘CREATE INDEX’

AND [Begin Time] BETWEEN @start_time AND @end_time

AND [RowLog Contents 0] LIKE ‘%ключевое_значение%’;

6. МЕТРОЛОГИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРНОЙ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

6.1. СТАНДАРТЫ ИЗМЕРЕНИЯ

Точность временных меток: Погрешность ≤ 1 мс

Полнота выборки: 100% для таблиц < 1 млн записей, 95% доверительный интервал для больших объемов

Воспроизводимость: Все запросы должны давать идентичный результат при повторном выполнении

6.2. КАЛИБРОВКА ИНСТРУМЕНТОВ

Процедура калибровки SQL-анализатора:

python

class SQLAnalyzerCalibration:

def __init__(self):

self.reference_datasets = {

‘small’: 1000,    # 1K записей

‘medium’: 100000, # 100K записей 

‘large’: 10000000 # 10M записей

}

def run_calibration(self, analyzer):

«»»Калибровка инструмента анализа»»»

results = {}

for dataset_name, record_count in self.reference_datasets.items():

test_data = self.generate_test_data(record_count)

# Измерение точности

start_time = time.time()

analysis_result = analyzer.process(test_data)

execution_time = time.time() — start_time

# Измерение погрешности

error_rate = self.calculate_error_rate(analysis_result)

results[dataset_name] = {

‘records’: record_count,

‘time_sec’: round(execution_time, 3),

‘error_rate’: round(error_rate, 5)

}

return self.validate_calibration(results)

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

7.1. CI/CD ПАЙПЛАЙН ДЛЯ ЭКСПЕРТНЫХ ИССЛЕДОВАНИЙ

text

Pipeline as Code (GitLab CI):

stages:

— preparation

— analysis

— reporting

prepare_environment:

stage: preparation

script:

— docker-compose -f forensics-stack.yml up -d

— sleep 30

— ./scripts/restore_database.sh $DB_BACKUP_FILE

run_analysis:

stage: analysis

script:

— python ./analyzers/schema_analyzer.py —input $DB_HOST

— python ./analyzers/data_profiler.py —tables «transactions,users,accounts»

— python ./analyzers/timeline_reconstructor.py —start-date «2023-01-01»

artifacts:

paths:

— ./reports/*.json

— ./reports/*.html

generate_report:

stage: reporting

script:

— python ./reporting/expert_report_generator.py

artifacts:

paths:

— ./final_report.pdf

7.2. ШАБЛОНЫ ИНЖЕНЕРНЫХ ОТЧЕТОВ

Структура технического отчета:

markdown

# ТЕХНИЧЕСКИЙ ОТЧЕТ ПО КОМПЬЮТЕРНОЙ ЭКСПЕРТИЗЕ БАЗ ДАННЫХ

## Экземпляр: [Имя БД]

## Период исследования: [Дата начала] — [Дата окончания]

## 1. МЕТРИКИ СИСТЕМЫ

| Параметр | Значение |

|———-|———-|

| Общий объем данных | 245.7 ГБ |

| Количество таблиц | 142 |

| Количество строк (суммарно) | 1.2 млрд |

| Период данных | 2019-01-01 — 2024-01-15 |

## 2. РЕЗУЛЬТАТЫ АНАЛИЗА

### 2.1. Аномалии производительности

«`sql

— Выявленные проблемные запросы

SELECT TOP 5 query_hash, total_elapsed_time_ms/execution_count as avg_time

FROM sys.query_store_runtime_stats

ORDER BY avg_time DESC;

2.2. Паттерны доступа к данным

https://activity_pattern.png
*Пиковая нагрузка: 14:00-16:00 UTC*

3. ИНЖЕНЕРНЫЕ ВЫВОДЫ

Найдено 3 неиспользуемых индекса (overhead 12.5 ГБ)

Обнаружены транзакции без COMMIT (длительность > 24ч)

Выявлен паттерн массового обновления в нерабочие часы

**8. ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНЖЕНЕРНЫХ МЕТОДОВ**

**8.1. ИНТЕГРАЦИЯ С OBSERVABILITY-СТЕКОМ**

Современная **компьютерная экспертиза баз данных** интегрируется с системами:

*   **OpenTelemetry** для сбора телеметрии

*   **Prometheus/Grafana** для мониторинга в реальном времени

*   **Jaeger** для трассировки распределенных транзакций

**8.2. ПРИМЕНЕНИЕ ФОРМАЛЬНЫХ МЕТОДОВ ВЕРИФИКАЦИИ**

Перспективное направление — использование:

*   **TLA+ (Temporal Logic of Actions)** для спецификации поведения систем

*   **Alloy** для анализа структурных свойств БД

*   **Coq/Agda** для доказательства корректности экспертных выводов

**8.3. АДАПТАЦИЯ К СОВРЕМЕННЫМ АРХИТЕКТУРАМ**

**Компьютерная экспертиза баз данных** развивается в направлении поддержки:

*   **Serverless БД** (Amazon Aurora Serverless, Google Cloud Spanner)

*   **Multi-model БД** (Azure Cosmos DB, ArangoDB)

*   **Blockchain-based хранилищ** (BigchainDB, Amazon QLDB)

**9. ЗАКЛЮЧЕНИЕ**

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

Ключевые инженерные принципы **компьютерной экспертизы баз данных**:

1. **Воспроизводимость** — все операции документируются и могут быть повторены
2. **Масштабируемость** — методы работают как на малых, так и на эксабайтных объемах
3. **Верифицируемость** — каждый вывод имеет четкую техническую основу
4. **Адаптивность** — поддержка новых технологий и архитектур

Развитие **компьютерной экспертизы баз данных** в инженерном ключе требует постоянной работы по стандартизации, созданию специализированного инструментария и подготовке инженеров-экспертов, сочетающих глубокие знания СУБД с навыками software engineering и системного анализа.