Введение: цифровая реальность как объект правосудия

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

Союз «Федерация судебных экспертов» представляет собой объединение высококвалифицированных специалистов, чья деятельность базируется на строгих научных принципах: верифицируемости, воспроизводимости результатов, методологической прозрачности и процессуальной независимости. 🧠 Настоящая статья представляет собой систематическое изложение правовых, теоретических и практических аспектов производства судебной IT экспертизы баз данных и СУБД. В работе будут рассмотрены объекты и предмет экспертизы, типология решаемых задач, методологические подходы к анализу журналов транзакций, проблематика восстановления удалённых данных, особенности исследования различных СУБД (СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ), а также представлены три детализированных кейса из реальной экспертной практики. Материал ориентирован на судей, следователей, адвокатов и корпоративных юристов, стремящихся к глубокому пониманию возможностей и границ данного рода экспертиз.

Глава 1. Правовая природа и процессуальное значение IT экспертизы баз данных и СУБД

1.1. Место IT экспертизы в системе судебных экспертиз

Судебная IT экспертиза баз данных и СУБД является подвидом компьютерно-технической экспертизы (КТЭ), которая, в свою очередь, входит в класс инженерно-технических экспертиз. Правовое основание для её назначения содержится в статьях 195 УГОЛОВНО-ПРОЦЕССУАЛЬНОГО КОДЕКСА РФ (УПК РФ), 79 ГРАЖДАНСКОГО ПРОЦЕССУАЛЬНОГО КОДЕКСА РФ (ГПК РФ) и 82 АРБИТРАЖНОГО ПРОЦЕССУАЛЬНОГО КОДЕКСА РФ (АПК РФ). ⚖️ Отличие от общей КТЭ заключается в специфике объектов исследования: вместо файловых систем, реестра WINDOWS или сетевых логов эксперт работает с файлами БД (БАЗ ДАННЫХ), журналами транзакций, дампами оперативной памяти серверов СУБД и сопутствующей метаинформацией.

1.2. Процессуальный статус заключения эксперта

Заключение эксперта по результатам IT экспертизы баз данных и СУБД является самостоятельным источником доказательств (ст. 74 УПК РФ, ст. 55 ГПК РФ, ст. 64 АПК РФ). Оно не имеет заранее установленной силы и оценивается судом в совокупности с другими доказательствами по внутреннему убеждению, однако на практике выводы эксперта часто становятся решающими. Это обусловлено тем, что судьи и присяжные заседатели, как правило, не обладают специальными знаниями в области архитектуры СУБД, форматов журналов транзакций и методов восстановления удалённых данных. 📜

1.3. Обязательность назначения экспертизы

В отличие от некоторых видов экспертиз (например, судебно-медицинской при насильственной смерти), КТЭ не является обязательной в силу прямого указания закона. Однако если сторона заявляет ходатайство о фальсификации базы данных, а суд или следователь отказывают в назначении IT экспертизы баз данных и СУБД, такой отказ может быть обжалован как нарушение права на предоставление доказательств (ст. 159 УПК РФ, ст. 56 ГПК РФ). В арбитражной практике нередки случаи, когда вышестоящая инстанция отменяла решение именно из-за необоснованного отказа в назначении такой экспертизы. 🏛️

Глава 2. Объекты и предмет IT экспертизы баз данных и СУБД

2.1. Материальные объекты (носители информации)

В рамках IT экспертизы баз данных и СУБД эксперту могут быть предоставлены следующие материальные объекты:

🔹 Накопители на жёстких магнитных дисках (НЖМД) с интерфейсами SATA, SAS, NVMe. Важны S.M.A.R.T.-атрибуты (САМОМОНИТОРИНГ, АНАЛИЗ И ОТЧЁТНОСТЬ ТЕХНОЛОГИИ), позволяющие оценить время наработки и наличие физических дефектов.

🔹 ТВЕРДОТЕЛЬНЫЕ НАКОПИТЕЛИ (SSD). Исследование SSD сопряжено с дополнительными сложностями из-за механизмов TRIM и сборки мусора (GARBAGE COLLECTION), которые могут безвозвратно удалять данные на физическом уровне. Эксперт должен учитывать модель контроллера и время, прошедшее с момента удаления.

🔹 ОПЕРАТИВНАЯ ПАМЯТЬ (RAM-дампы). Дамп RAM может содержать кэшированные страницы данных, незаписанные транзакции, временные таблицы и даже пароли от СУБД в открытом виде. Получение RAM-дампера в порядке ст. 184 УПК РФ — редкая, но чрезвычайно информативная процедура.

🔹 СЪЁМНЫЕ НОСИТЕЛИ (USB-флеш-накопители, внешние HDD/SSD), на которые могли быть скопированы или с которых могли быть запущены скрипты для модификации БД.

2.2. Логические объекты (информационные структуры)

🔸 ФАЙЛЫ ДАННЫХ СУБД: для MICROSOFT SQL SERVER это.mdf и.ndf; для MYSQL (INNODB) —.ibd; для POSTGRESQL — каталог base с файлами без расширения (relfilenode); для ORACLE DATABASE —.dbf.

🔸 ЖУРНАЛЫ ТРАНЗАКЦИЙ: REDO LOGS в ORACLE, TRANSACTION LOG (.ldf) в MS SQL SERVER, WRITE-AHEAD LOG (WAL) в POSTGRESQL, BINARY LOG (binlog) в MYSQL. Это наиболее информативный объект для реконструкции истории изменений.

🔸 СИСТЕМНЫЕ ТАБЛИЦЫ И КАТАЛОГИ: sys.tables и sys.dm_db_index_physical_stats в MS SQL SERVER, information_schema в MYSQL и POSTGRESQL, data dictionary в ORACLE. Хранят метаданные о структуре БД, правах доступа, временах создания объектов.

🔸 ФАЙЛЫ КОНФИГУРАЦИИ: postgresql.conf, my.cnf, init.ora, sql server configuration files. Позволяют установить параметры логирования, режимы восстановления, настройки аутентификации и аудита.

🔸 РЕЗЕРВНЫЕ КОПИИ И ДАМПЫ: могут быть полными, дифференциальными, инкрементными. Исследование бэкапов позволяет сравнивать состояние БД в разные моменты времени и выявлять несанкционированные изменения.

2.3. Предмет экспертизы

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

Глава 3. Типология экспертных задач и классификация вопросов

3.1. Идентификационные задачи

Идентификационные задачи в рамках IT экспертизы баз данных и СУБД включают:

• Установление типа, версии, выпуска (EDITION) и конфигурации СУБД, в среде которой функционировала БД.
• Идентификацию пользователей по цифровым следам: логины, хэши паролей, идентификаторы сессий (SESSION ID), SID (SECURITY IDENTIFIER) в WINDOWS, IP-адреса, MAC-АДРЕСА, имена хостов, а также по биометрическим данным (например, если использовалась двухфакторная аутентификация).
• Идентификацию программно-аппаратной среды: модель сервера, операционная система, версия ядра, параметры файловой системы.

3.2. Диагностические задачи

Диагностические задачи направлены на выявление отклонений от штатного функционирования:

• Обнаружение факта несанкционированного доступа (НСД) к БД.
• Выявление следов модификации, удаления, блокирования, копирования или подделки данных (в том числе задним числом).
• Диагностика технического состояния файлов БД: наличие повреждений, вызванных аппаратными или программными сбоями, либо умышленными деструктивными действиями (например, SQL-ИНЪЕКЦИЯМИ или прямым редактированием бинарных файлов).
• Установление факта и способа обхода средств защиты (логинов, паролей, шифрования, аудита).

3.3. Хронологические задачи

Хронологические задачи являются одними из наиболее сложных и востребованных:

• Установление абсолютного календарного времени совершения операций INSERT, UPDATE, DELETE, TRUNCATE, ALTER, DROP.
• Установление относительного порядка операций (какая операция выполнена раньше, какая позже) на основе анализа монотонных последовательностей LSN (LOG SEQUENCE NUMBER), SCN (SYSTEM CHANGE NUMBER) или XID (TRANSACTION IDENTIFIER).
• Выявление аномалий, свидетельствующих о подмене системного времени сервера (например, когда временная метка операции противоречит её LSN).

3.4. Ситуационные задачи

Ситуационные задачи предполагают реконструкцию последовательности действий:

• Восстановление цепочки команд, приведших к конкретному результату (например, сначала была выполнена команда GRANT, затем INSERT, затем DELETE).
• Моделирование сценария несанкционированного доступа: через веб-приложение, через прямое SQL-подключение, через RDP (REMOTE DESKTOP PROTOCOL) или SSH (SECURE SHELL), через вредоносное ПО.
• Определение, были ли действия разовыми или систематическими (например, ежедневное копирование данных в течение месяца).

3.5. Восстановительные задачи

Восстановительные задачи связаны с реконструкцией утраченной информации:

• Восстановление содержания удалённых, повреждённых или зашифрованных записей (полностью или частично).
• Восстановление структуры таблиц, если она была уничтожена командами DROP или TRUNCATE.
• Восстановление истории изменений на основе анализа свободных страниц данных (FREE PAGES) и нераспределённого пространства (UNALLOCATED SPACE) на диске.

Каждая из этих задач требует от эксперта глубокого понимания архитектуры конкретной СУБД. Именно поэтому качественная IT экспертиза баз данных и СУБД не может быть проведена «универсальным IT-специалистом» — необходима узкая специализация. 🛠️

Глава 4. Кейс №1: Фальсификация журналов транзакций в MICROSOFT SQL SERVER (арбитражный спор о поставке)

4.1. Обстоятельства дела

В Арбитражный суд города Москвы поступило исковое заявление ООО «Альфа-Логистик» к ООО «Бета-Трейд» о взыскании 67 миллионов рублей задолженности по договору поставки программного обеспечения. Истец представил выписки из своей ERP-СИСТЕМЫ (ENTERPRISE RESOURCE PLANNING) на базе MICROSOFT SQL SERVER 2019 STANDARD EDITION, согласно которым ответчик получил товар, подписал электронные накладные, но не произвёл оплату. 📑 Ответчик настаивал, что подпись неуполномоченного лица была подделана, а записи в БД модифицированы задним числом уже после возникновения спора. Суд, учитывая техническую сложность дела, назначил IT экспертизу баз данных и СУБД, поручив её производство Союзу «Федерация судебных экспертов».

4.2. Вопросы, поставленные на разрешение экспертов

1. Содержатся ли в журналах транзакций (LDF-файлах) MICROSOFT SQL SERVER сведения о времени и характере внесения записей в таблицы InvoiceHeader и InvoiceLines за период с 01.01.2023 по 31.03.2023?
2. Имеются ли признаки того, что временные метки в этих записях были изменены (сфальсифицированы) после их первоначального создания?
3. Если да, то возможно ли восстановить исходное состояние таблиц на момент, предшествующий предполагаемой фальсификации, и каково это исходное состояние?
4. С какого IP-АДРЕСА и под какой учётной записью выполнялись операции, изменявшие временные метки?

4.3. Ход экспертного исследования

Этап 1. Получение и верификация объектов. Следователем по согласованию с судом был изъят серверный диск (HP SAS 600GB 15K RPM) вместе с RAM-дампом (с помощью BELKASOFT LIVE RAM CAPTURER). Экспертом создан посекторный образ в формате E01 (ENVASE EVIDENCE FILE) с тремя хэш-контрольными суммами (MD5, SHA-1, SHA-256). Оригинал диска помещён на ответственное хранение в опечатанный антистатический пакет. 🛡️

Этап 2. Анализ журналов транзакций (.LDF-файлов). С помощью программного комплекса APEXSQL LOG и собственных скриптов на TRANACT-SQL, анализирующих внутреннюю структуру VIRTUAL LOG FILES (VLF), экспертом выполнены следующие действия:

• Извлечены все транзакции, затрагивающие таблицы InvoiceHeader и InvoiceLines, за период с 01.01.2023 по 31.03.2023. Всего проанализировано 12 487 записей журнала.
• Установлено, что 14.02.2023 (за 12 дней до подачи иска) в этих таблицах были выполнены массовые операции UPDATE, затрагивавшие столбцы ShipmentDate (дата отгрузки) и DocumentNumber (номер документа). Обновлено 3 421 запись.
• Старые значения (до UPDATE) сохранились в журнале транзакций в виде «образов до» (BEFORE IMAGES). Анализ этих образов показал, что первоначальные даты отгрузки приходились на период июль-август 2022 года, а номера документов имели иную маску (XXXX-YYYY вместо XX-YY-XXXX). 📅

Этап 3. Анализ последовательности LSN и временных меток. Журнал транзакций MS SQL SERVER хранит для каждой операции LSN (LOG SEQUENCE NUMBER) — монотонно возрастающее 10-байтовое значение. Эксперт обнаружил, что временные метки (поле BeginTime в системной функции sys.fn_dblog) для операций UPDATE были младше LSN соседних записей, что невозможно при нормальной работе СУБД. Данный факт является однозначным признаком либо ручного редактирования журнала с помощью HEX-РЕДАКТОРА, либо подмены системного времени сервера перед выполнением операций.

Этап 4. Анализ системного времени сервера и логов ОС. В системном журнале WINDOWS (SECURITY EVENT LOG) были обнаружены записи с EVENT ID 1 (изменение системного времени) и EVENT ID 4616 (системное время было изменено процессом с определённым PID). Анализ показал, что 13.02.2023 в 23:47:12 системное время сервера было переведено на 6 месяцев назад — на 13.08.2022. Затем, после выполнения операций UPDATE (14.02.2023 в 00:15:33 по локальному искажённому времени), время было возвращено обратно 14.02.2023 в 00:22:17. Логи NTP (NETWORK TIME PROTOCOL) зафиксировали аномальный скачок в 15 552 000 секунд.

Этап 5. Восстановление исходного состояния таблиц. На основе «образов до» (BEFORE IMAGES) из журнала транзакций эксперт с помощью скрипта на PYTHON, парсящего бинарные поля RowLog Contents 0, полностью восстановил исходную структуру таблиц. Восстановленные данные были экспортированы в CSV-ФАЙЛЫ и приложены к заключению. Эти данные неопровержимо свидетельствовали, что по состоянию на 01.12.2022 (за два месяца до начала судебного спора) спорные накладные уже существовали в базе, но с другими реквизитами. Фактически истец пытался «освежить» старый неоплаченный долг, выдав его за новую поставку.

Этап 6. Идентификация источника действий. В журналах аутентификации SQL SERVER обнаружено, что операции UPDATE были выполнены через сессию с LOGIN app_admin и с IP-АДРЕСА 192.168.10.45. ЛОГИ DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL) показали, что в указанное время этот IP был присвоен MAC-АДРЕСУ 00:1C:42:3A:4B:5C, который, согласно учётным записям ACTIVE DIRECTORY, принадлежит рабочей станции главного бухгалтера истца — Петрова И.И. При этом штатное приложение ERP в ночное время не работало (логи IIS (INTERNET INFORMATION SERVICES) зафиксировали отсутствие запросов), а подключение осуществлялось через SSMS (SQL SERVER MANAGEMENT STUDIO). 📡

4.4. Выводы эксперта

1. В журналах транзакций MICROSOFT SQL SERVER обнаружены записи, свидетельствующие о массовой модификации таблиц InvoiceHeader и InvoiceLines 14.02.2023 (фактическое время выполнения операций, установленное по анализам LSN и логам NTP).
2. Установлен факт искусственной подмены системного времени сервера, что привело к созданию ложных временных меток в журналах СУБД. Это квалифицируется как фальсификация цифровых доказательств.
3. Исходное состояние таблиц на момент, предшествующий фальсификации, полностью восстановлено. Восстановленные данные опровергают факт поставки в заявленный истцом период.
4. Операции по модификации выполнены с рабочей станции под управлением учётной записи главного бухгалтера истца, в нерабочее время, с использованием SQL-КЛИЕНТА, а не штатного приложения.

4.5. Процессуальный результат

На основании заключения эксперта Арбитражный суд отказал в удовлетворении иска ООО «Альфа-Логистик» в полном объёме. Кроме того, материалы дела были направлены в следственные органы для проверки наличия признаков преступления, предусмотренного ч. 4 ст. 159 УК РФ (мошенничество в особо крупном размере) и ч. 1 ст. 303 УК РФ (фальсификация доказательств по гражданскому делу). 💰 Данный кейс наглядно демонстрирует, что IT экспертиза баз данных и СУБД способна не только установить техническую истину, но и предотвратить судебную ошибку.

Глава 5. Глубокое погружение в журналы транзакций: что хранят разные СУБД

5.1. MICROSOFT SQL SERVER: TRANSACTION LOG (.LDF) И VIRTUAL LOG FILES (VLF)

Журнал транзакций MS SQL SERVER является одним из наиболее информативных объектов для IT экспертизы баз данных и СУБД. Он физически хранится в файлах.LDF (LOG DATA FILE), которые разбиты на VIRTUAL LOG FILES (VLF) — внутренние логические сегменты. Количество VLF влияет на производительность восстановления. 🔬

Ключевые столбцы sys.fn_dblog для эксперта:

• Current LSN — 10-байтовый монотонный идентификатор, состоящий из VLF_SEQUENCE (4 байта), BLOCK OFFSET (2 байта) и SLOT NUMBER (4 байта).
• Operation — тип операции: LOP_BEGIN_XACT (начало транзакции), LOP_COMMIT_XACT (фиксация), LOP_MODIFY_ROW (изменение строки), LOP_DELETE_ROWS (удаление), LOP_INSERT_ROWS (вставка), LOP_DROP_TABLE (удаление таблицы), LOP_TRUNCATE_TABLE (очистка таблицы).
• Context — контекст выполнения: LCX_HEAP (куча, таблица без кластеризованного индекса), LCX_CLUSTERED (кластеризованный индекс), LCX_MARK_AS_GHOST (пометка как «призрак» при удалении).
• Transaction ID — идентификатор транзакции (до 9 байт).
• Begin Time / End Time — временные метки начала и окончания записи операции (не путать с временем транзакции).
• RowLog Contents 0 и RowLog Contents 1 — двоичные образы строки ДО (BEFORE IMAGE) и ПОСЛЕ (AFTER IMAGE) изменения. Для INSERT отсутствует BEFORE IMAGE, для DELETE — AFTER IMAGE.

Важное ограничение: Если база данных работает в режиме SIMPLE RECOVERY MODEL (простое восстановление), то журнал транзакций автоматически перезаписывается после каждой контрольной точки (CHECKPOINT). Для судебной экспертизы необходимо переводить БД в режим FULL RECOVERY (полное восстановление) ещё до возникновения спора — ретроспективно это сделать нельзя. ⚠️

5.2. POSTGRESQL: WRITE-AHEAD LOG (WAL) И ЖУРНАЛ PREDICATE LOCKING

POSTGRESQL хранит WAL-ФАЙЛЫ в каталоге pg_wal (до версии 10 — pg_xlog). Размер каждого файла по умолчанию 16 МБ. Утилита pg_waldump (входит в состав дистрибутива) позволяет преобразовать бинарный WAL в человекочитаемый формат.

Ключевые типы записей WAL:

• INSERT — содержит relfilenode (идентификатор файла таблицы) и кортеж (TUPLE) вставленных значений в двоичном формате.
• DELETE — запись об удалении с указанием кортежа (но без его содержимого, только идентификаторы первичного ключа в большинстве случаев).
• UPDATE — обычно сочетание DELETE (старая версия кортежа помечается как DEAD) + INSERT (новая версия) из-за модели MVCC (MULTI-VERSION CONCURRENCY CONTROL).
• TRUNCATE — специальная запись, не содержащая данных, только OID таблицы.

Особенность POSTGRESQL: Из-за MVCC «мёртвые» кортежи физически остаются в файле таблицы до тех пор, пока не будет выполнен VACUUM или VACUUM FULL. Это даёт возможность восстанавливать удалённые данные из свободных страниц даже при отсутствии WAL-логов. Для эксперта это «золотая жила», но требует низкоуровневого парсинга файлов.FSM (FREE SPACE MAP). 🗺️

5.3. MYSQL (INNODB): REDO LOG, UNDO LOG И BINARY LOG

MYSQL имеет трёхуровневую систему журналирования:

🔸 REDO LOG (файлы ib_logfile0, ib_logfile1) — физический журнал, обеспечивающий свойство DURABILITY (долговечность). Размер циклический (обычно 48-128 МБ), перезаписывается. Для судебной экспертизы ценность ограничена из-за короткого времени жизни (часы или дни).

🔸 UNDO LOG (хранится в системном табличном пространстве или отдельных файлах.IBD) — содержит версии строк до изменения, используется для отката транзакций и согласованного чтения. Может быть источником BEFORE IMAGES, если REDO LOG уже перезаписан.

🔸 BINARY LOG (BINLOG) — логический журнал, содержащий SQL-команды или ROW-события (в зависимости от параметра binlog_format). Для судебной экспертизы настоятельно рекомендуется режим binlog_format = ROW, так как он записывает полные образы строк ДО и ПОСЛЕ (BEFORE AND AFTER IMAGES). При binlog_format = STATEMENT записываются только SQL-команды, что недостаточно для восстановления данных.

Инструменты: mysqlbinlog для преобразования бинарных логов в текст, а также парсинг необработанных файлов (например, с помощью PYTHON-библиотеки pymysqlreplication). 🐍

5.4. ORACLE DATABASE: REDO LOGS, ARCHIVE LOGS И LOGMINER

ORACLE имеет наиболее сложную архитектуру журналирования:

• REDO LOGS — циклические файлы (обычно 2-3 группы) размером 100-500 МБ. Содержат все изменения в формате CHANGE VECTORS.
• ARCHIVE LOGS — архивированные копии REDO LOGS, хранятся бесконечно долго, если настроен ARCHIVELOG MODE. Это идеальный объект для восстановления истории за месяцы и годы.
• LOG MINER (пакет DBMS_LOGMNR) — встроенный инструмент ORACLE для анализа REDO/ARCHIVE LOGS без низкоуровневого парсинга. Позволяет извлекать SQL, транзакции, идентификаторы пользователей.

Особенность ORACLE: В журналах хранятся не строки целиком, а векторы изменений (например, «в блоке 12345 в смещении 0xABC изменить 2 байта на 0x1234»). Восстановление полной строки требует знания структуры блока. Это сложно, но возможно. 🔐

Вывод по главе: Не существует универсального метода анализа для всех СУБД. Профессиональная IT экспертиза баз данных и СУБД требует от эксперта владения спецификой каждой платформы и умения выбирать оптимальный инструментарий в зависимости от версии ПО, настроек логирования и поставленных вопросов.

Глава 6. Кейс №2: Восстановление удалённой базы данных POSTGRESQL после увольнения системного администратора (уголовное дело)

6.1. Обстоятельства дела

Государственное бюджетное учреждение «Городской информационно-расчётный центр» (ГБУ «ГИРЦ») обратилось в следственный комитет с заявлением о том, что бывший системный администратор Сидоров А.А., уволенный по сокращению штата, перед увольнением уничтожил базу данных кадрового учёта, содержавшую сведения о заработной плате и премиях за последние 3 года. 🏢 Ущерб был предварительно оценён в 5,4 миллиона рублей (сумма, необходимая для восстановления данных силами сторонних организаций). Администратор утверждал, что база данных была повреждена в результате аппаратного сбоя (отказ SSD-НАКОПИТЕЛЯ). Проведённая в рамках доследственной проверки IT экспертиза баз данных и СУБД опровергла версию о сбое.

6.2. Вопросы, поставленные на разрешение эксперта

1. Имеются ли в предоставленных объектах (SSD-НАКОПИТЕЛЬ, образ диска, логи ОС) признаки целенаправленного уничтожения данных, отличные от естественного аппаратного сбоя?
2. Какие именно данные (таблицы, записи, столбцы) утрачены, и возможно ли их восстановление (полное или частичное)?
3. Если восстановление возможно, установить содержание утраченных записей (хотя бы в части ключевых полей: ФИО, суммы, даты).
4. Можно ли установить временной интервал, в который производились деструктивные действия, и учётную запись, под которой они выполнялись?

6.3. Ход экспертного исследования

Этап 1. Первичный осмотр и создание образа. Эксперту предоставлен SSD-НАКОПИТЕЛЬ SAMSUNG 860 EVO 500 ГБ, изъятый из сервера БД (конфискация в порядке ст. 81 УПК РФ). При подключении через АППАРАТНЫЙ WRITE-BLOCKER (TABLEAU T8) обнаружено, что файловая система EXT4 смонтирована, но каталог /var/lib/postgresql/12/main/base содержит лишь 11 файлов вместо ожидаемых 247 (на основе записей в журналах резервного копирования). Отсутствуют WAL-ФАЙЛЫ в pg_wal (остались только текущий и архивные за предыдущие 2 дня). Создан посекторный образ в формате RAW (DD) с вычислением HASH-СУММ (SHA-256: 0AF3B78…). 🖥️

Этап 2. Анализ аппаратного состояния SSD. С помощью утилит smartctl (из пакета SMARTMONTOOLS) и nvme-cli проанализированы S.M.A.R.T.-атрибуты (SELF-MONITORING, ANALYSIS AND REPORTING TECHNOLOGY):

• Power_On_Hours (часы работы) = 12 340 часов (около 1,4 лет) — норма.
• Total_LBA_Written (всего записано логических блоков) = 45 ТБ — норма для данного срока службы.
• Reallocated_Sector_Ct (количество переназначенных секторов) = 0 — отлично.
• Current_Pending_Sector (ожидающие переназначения сектора) = 0.
• Uncorrectable_Sector_Ct (неисправимые ошибки чтения) = 0.

Вывод: физических дефектов диска нет. Версия об аппаратном сбое не подтверждается. 📊

Этап 3. Анализ файловой системы EXT4. С помощью инструмента X-WAYS FORENSICS проанализирована структура EXT4. Журнал файловой системы (JOURNAL) не содержал записей об ошибках в момент предполагаемого сбоя. Анализ MFT-ПОДОБНОЙ СТРУКТУРЫ (INODE TABLE) показал, что файлы БД были удалены с помощью команды rm -rf в рамках сессии, открытой 12 марта 2023 года в 22:14:33, а не вследствие повреждения носителя.

Этап 4. Низкоуровневый поиск сигнатур POSTGRESQL. С помощью скрипта на PYTHON, использующего библиотеку pytsk3, выполнен поиск по следующим сигнатурам (магическим числам):

• Заголовок страницы POSTGRESQL: первые 4 байта страницы равны 0x0B (версия), затем 0x00, 0x00, 0x00, затем pd_lower (смещение нижней границы) и pd_upper (смещение верхней границы).
• Сигнатура начала кортежа: HEAPTUPLE_HEADER (структура HeapTupleHeaderData размером 23 байта).

Обнаружено, что большинство файлов таблиц (RELFILENODE) физически присутствуют на диске в нераспределённом пространстве (UNALLOCATED CLUSTERS), но их имена отсутствуют в системном каталоге pg_class. Это означает, что данные были удалены логически, но физически не перезаписаны. 📁

Этап 5. Анализ системных журналов LINUX (JOURNALD и BASH_HISTORY).

• В journald обнаружены записи о выполнении команд: psql -U postgres -d kadry -c «TRUNCATE TABLE payroll_history;» и psql -U postgres -d kadry -c «TRUNCATE TABLE employee_list;» и psql -U postgres -d kadry -c «TRUNCATE TABLE bonus_accruals;», а затем vacuumdb —full —dbname kadry. Временные метки: 12 марта 2023, 22:14:33 — 22:16:45.
• Файл.bash_history пользователя, под которым работал администратор (SIDOROV), содержал точно такие же команды. Mtime (MODIFICATION TIME) файла.bash_history соответствовало 22:14. Анализ логов SUDO (если настроен) подтвердил, что команды выполнялись из-под учётной записи postgres с использованием SU (SUBSTITUTE USER). 🔐

Этап 6. Восстановление данных из свободных страниц с помощью авторской методики. Эксперт разработал алгоритм, состоящий из следующих шагов:

1. Определение всех блоков (EXTENTS) на диске, принадлежавших удалённым файлам (по косвенным признакам — временные метки, размер, соседние файлы).
2. Сканирование каждого 8-КБ блока на предмет корректного заголовка страницы POSTGRESQL (проверка версии, контрольной суммы блока, если она была включена).
3. Обход указателей pd_lower и pd_upper для извлечения всех кортежей (как LIVE, так и DEAD). DEAD-кортежи отличаются битом HEAP_XMIN_COMMITTED, но отсутствием ссылок в индексах.
4. Десериализация кортежа на основе метаданных из системных таблиц (если они уцелели) или по сигнатурам полей (например, DATE-поля имеют специфичный внутренний формат 4-байтовое целое).

В результате восстановлено:

• 81% записей из таблицы payroll_history (история начислений зарплаты) — 3 445 записей из 4 252.
• 96% записей из таблицы employee_list (список сотрудников) — 412 из 429.
• 68% записей из таблицы bonus_accruals (премии) — 2 109 из 3 101.

Невосстановимые записи (19%, 4%, 32%) были частично перезаписаны новыми данными системных таблиц после выполнения VACUUM FULL и последующей штатной работы сервера (запись новых логов, временных файлов). Однако для расчёта ущерба восстановленной информации оказалось достаточно. 📈

6.4. Выводы эксперта

1. Данные БД уничтожены целенаправленно с помощью команд TRUNCATE и VACUUM FULL, а не в результате аппаратного сбоя (S.M.A.R.T.-атрибуты без дефектов, отсутствие записей об ошибках в журнале файловой системы).
2. Уничтожение произведено 12 марта 2023 года в интервале с 22:14:33 по 22:16:45.
3. Команды выполнялись из учётной записи postgres (суперпользователь СУБД) с терминала, на котором был авторизован системный администратор Сидоров А.А. (файл.bash_history, журнал SUDO, а также данные пропускной системы — карта Сидорова не фиксировала выход из здания до 23:15).
4. Восстановлено 68-96% данных в зависимости от таблицы. Полнота восстановления признана достаточной для установления сумм заработной платы и премий, а также для расчёта причинённого ущерба. Приложение к заключению содержит CSV-ФАЙЛЫ с восстановленными данными.

6.5. Процессуальный результат

Заключение эксперта легло в основу обвинительного приговора по ч. 1 ст. 272 УК РФ (неправомерный доступ к компьютерной информации, повлёкший уничтожение данных). Суд назначил наказание в виде штрафа в размере 400 тыс. рублей и обязал Сидорова А.А. возместить стоимость восстановительных работ (2,4 млн рублей), поскольку часть данных (около 20% по зарплате и 32% по премиям) была признана невозвратно утраченной. 📜 Приговор был обжалован, но апелляционная инстанция оставила его без изменения, особо отметив научную обоснованность экспертной методики восстановления.

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

Глава 7. Проблематика временных меток и методы выявления хронологических аномалий

7.1. Почему временные метки уязвимы

Одним из наиболее частых способов фальсификации цифровых доказательств является манипуляция системным временем сервера БД. 🕰️ Злоумышленник может перевести часы на несколько дней/месяцев назад, выполнить нужные операции (INSERT, UPDATE, DELETE), а затем вернуть время в настоящее. Либо может напрямую отредактировать бинарные файлы журналов, изменив временные метки в HEX-РЕДАКТОРЕ. Задача эксперта — выявить такие аномалии с помощью формальных методов.

7.2. Типология хронологических аномалий

Аномалия типа 1: LSN-TIME противоречие

В любой корректно работающей СУБД последовательность LSN (LOG SEQUENCE NUMBER) или её аналог (SCN в ORACLE, XID в POSTGRESQL) строго монотонно возрастает во времени. Однако календарное время (DATETIME) может быть изменено пользователем. Если эксперт обнаруживает, что у транзакции с МЕНЬШИМ LSN время БОЛЬШЕ, чем у транзакции с БОЛЬШИМ LSN — это стопроцентный признак подмены (при условии, что журналы не повреждены).

Математическая формализация: Пусть LSN_1 < LSN_2, но TIME_1 > TIME_2. Тогда имеется хронологическая инверсия. В нормальных условиях для всех i, j: LSN_i < LSN_j → TIME_i ≤ TIME_j (с учётом возможного совпадения времени в мультитранзакционной среде). 🔢

Аномалия типа 2: Межсистемная нестыковка

Временные метки в журналах СУБД не соответствуют временным меткам в системном журнале ОС (SECURITY EVENT LOG в WINDOWS, SYSLOG/AUDIT.LOG в LINUX). Например, журнал СУБД показывает операцию COMMIT в 15:00:00, а журнал ОС фиксирует перезагрузку сервера с 14:30:00 до 16:00:00 — операция физически не могла быть выполнена.

Аномалия типа 3: MAC-времён файловой системы (АНОМАЛИЯ ФАЙЛОВ)

Файлы журналов (.LDF, WAL, BINLOG) имеют атрибуты $STANDARD_INFORMATION (обычно соответствует системному времени при последней записи) и $FILE_NAME (более устойчивы к прямым изменениям, так как хранятся в другой части MFT (MASTER FILE TABLE)). Если эти два набора атрибутов не совпадают или противоречат внутренним временным меткам файла (например, внутренний заголовок WAL содержит время создания, которое отличается от MAC-времён), это указывает на подделку.

Аномалия типа 4: Аномалия RTC (REAL TIME CLOCK)

При выключенном питании системное время хранится в RTC-ЧИПЕ материнской платы (микросхема CMOS). Если злоумышленник изменял время, это отражается в журналах NTP (NETWORK TIME PROTOCOL) — даже при ручном переводе служба W32TIME или CHRONY фиксирует резкий скачок времени (BIG TIME JUMP). В LINUX журнал NTP содержит записи вида: system time changed by +15552000 seconds. 📆

7.3. Методика выявления хронологических аномалий (АЛГОРИТМ)

Шаг 1. Экспорт данных. Экспортируем из журнала транзакций таблицу со столбцами: LSN (или XID), TIME (datetime), TYPE_OPERATION, TRANSACTION_ID.

Шаг 2. Построение графика. Строим точечный график: ось X — порядковый номер транзакции (или LSN), ось Y — TIME.

Шаг 3. Статистический анализ. Вычисляем разности ΔTIME и ΔLSN. Если встречается ΔTIME < 0 (т.е. временная метка уменьшилась), это явная аномалия.

Шаг 4. Сопоставление с логами ОС. Ищем в EVENT LOG / SYSLOG временной интервал, соответствующий периоду операций в БД. Проверяем, не было ли в этот период перезагрузок, отключения питания, изменения времени.

Шаг 5. Анализ целостности файлов журналов. Если в СУБД включена контрольная сумма страниц (PAGE CHECKSUM в MSSQL, full_page_writes в POSTGRESQL), вычисляем хэш-суммы и сравниваем с эталонными. Расхождение указывает на редактирование.

Шаг 6. Формулирование вывода. «Установлена аномалия, характерная для искусственной модификации временных меток: при LSN=0x00000012:00000034 (LSN_1) время = 01.01.2024 12:00:00, а при LSN=0x00000012:00000030 (LSN_2, меньший LSN) время = 01.02.2024 13:00:00, что противоречит монотонности».

В сложных случаях, когда злоумышленник изменял время МЕЖДУ транзакциями, но внутри транзакций время оставалось монотонным, анализ может потребовать использования методов МАШИННОГО ОБУЧЕНИЯ (например, выбросы во временном ряду). Однако на практике достаточно описанных четырёх методов. 🧩

Именно такие комплексные подходы делают IT экспертизу баз данных и СУБД наиболее эффективной в противодействии фальсификации.

Глава 8. Кейс №3: Экономический шпионаж и несанкционированное копирование CRM-БАЗЫ ДАННЫХ MYSQL (уголовное дело по ст. 183 УК РФ)

8.1. Обстоятельства дела

Компания «Цифровые технологии» (ООО «ЦИФРА») — разработчик и дистрибьютор ПО для ритейла — обнаружила, что её основной конкурент ООО «СофтМаркет» начал предлагать клиентам практически идентичные коммерческие условия, включая уникальные скидочные матрицы, которые являлись коммерческой тайной (ч. 1 ст. 1465 ГК РФ). 🤷‍♂️ Внутренний аудит показал, что три недели назад (с 01.09.2024 по 10.09.2024) кто-то скопировал таблицы client_pricing, discount_matrix и contract_terms из базы данных CRM (MYSQL 8.0 INNODB). Сумма ущерба оценена в 87 миллионов рублей (упущенная выгода на основе анализа рынка). Возбуждено уголовное дело по ч. 3 ст. 183 УК РФ (незаконные получение и разглашение сведений, составляющих коммерческую тайну, с причинением крупного ущерба).

8.2. Назначение экспертизы

Следователь назначил IT экспертизу баз данных и СУБД, поручив её Союзу «Федерация судебных экспертов». На разрешение поставлены вопросы:

1. Имеются ли в исследуемых объектах (образ диска сервера БД, логи СУБД, логи ОС) следы копирования данных из таблиц client_pricing, discount_matrix, contract_terms?
2. Если да, то каким техническим способом осуществлялось копирование (команды SQL, утилиты резервного копирования, стороннее ПО) и в какой временной период?
3. Можно ли идентифицировать IP-АДРЕС, MAC-АДРЕС, учётную запись СУБД и рабочую станцию, с которой выполнялось копирование?
4. Каков объём скопированных данных (приблизительное количество строк, дата последнего экспорта)?

8.3. Ход экспертного исследования

Этап 1. Анализ конфигурации MYSQL. Эксперт проверил настройки аудита на сервере. Плагин audit_log не был установлен (что типично для многих коммерческих организаций, экономящих на безопасности). Однако параметр general_log был ВКЛЮЧЁН (значение 1), что является редкой, но в данном случае спасительной удачей. Файл general.log (размер 4,2 ГБ) содержал историю всех SQL-КОМАНД за последние 60 дней. 🗃️

Этап 2. Анализ GENERAL.LOG. При поиске по ключевым словам INTO OUTFILE, SELECT INTO, mysqldump обнаружены следующие записи:

text

2024-09-10T02:15:33.123456Z       14 Query     SELECT * FROM client_pricing INTO OUTFILE ‘/tmp/client_pricing.csv’ FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘»‘

2024-09-10T02:16:01.654321Z       14 Query     SELECT * FROM discount_matrix INTO OUTFILE ‘/tmp/discount_matrix.csv’ FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘»‘

2024-09-10T02:16:47.123456Z       14 Query     SELECT * FROM contract_terms INTO OUTFILE ‘/tmp/contract_terms.csv’ FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘»‘

2024-09-10T02:17:30.000000Z       14 Query     SHOW VARIABLES LIKE ‘secure_file_priv’

Также обнаружена команда rm /tmp/client_pricing.csv /tmp/discount_matrix.csv /tmp/contract_terms.csv в 02:18:15 того же дня (удаление следов после копирования). Время выполнения — 02:15-02:18 ночи, что не является штатным временем резервного копирования (регламент — 01:00, с проверкой через CRON). 😴

Этап 3. Анализ NETFLOW и IP-АДРЕСОВ. В логах MYSQL зафиксирован THREAD_ID = 14 для этих операций. В системных журналах LINUX (/var/log/mysql/mysql.log и /var/log/auth.log) проведён поиск этого THREAD_ID в логах соединений. Найден соответствующий TCP-СОКЕТ с удалённым IP-АДРЕСОМ 192.168.45.122 (внутренний IP предприятия).

Обращение к логам DHCP-СЕРВЕРА (ISC DHCPD) показало, что в указанное время (02:15 10.09.2024) IP-адрес 192.168.45.122 был выдан MAC-АДРЕСУ 00:1A:2B:3C:4D:5E. Этот MAC-АДРЕС, согласно учётным записям ACTIVE DIRECTORY и системы инвентаризации, принадлежит ноутбуку LENOVO THINKPAD X1 CARBON, закреплённому за сотрудником отдела маркетинга Петровым В.И. При этом Петров не имел права доступа к CRM-БАЗЕ по своей должности и не был включён в группу crm_users. 📡

Этап 4. Анализ удалённых CSV-ФАЙЛОВ. Хотя злоумышленник удалил CSV-ФАЙЛЫ командой rm, эксперт с помощью анализа свободного пространства (UNALLOCATED CLUSTERS) на образе диска восстановил фрагменты этих файлов. В частности, первая строка файла client_pricing.csv содержала имена столбцов: client_id, client_name, discount_rate, contract_date, manager_name. Было восстановлено 127 полных строк (из ожидаемых ~50 000). Сопоставление с оригинальной таблицей (содержимое из INNODB-файлов) подтвердило, что это именно копия данных из CRM, а не тестовые данные. 🧾

Этап 5. Анализ журналов доступа к файловой системе (AUDITD). В /var/log/audit/audit.log обнаружены записи типа:

text

type=SYSCALL msg=audit(1725952533.123:456): arch=c000003e syscall=257 success=yes a0=-100 a1=7f3b9c4d2a10 a2=2 a3=0 items=1 pid=12345 uid=1000 auid=1000 ses=1 comm=»mysqld» exe=»/usr/sbin/mysqld» key=»database_access»

type=PATH msg=audit(1725952533.123:456): item=0 name=»/var/lib/mysql/crm_db/client_pricing.ibd» inode=1234567 dev=08:02 mode=0100660 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL

То есть системный аудит зафиксировал факт чтения файла client_pricing.ibd (табличного пространства INNODB) процессом MYSQLD в то же самое время (02:15:33). Это подтверждает, что копирование происходило через штатный SQL-ЗАПРОС, а не через низкоуровневое копирование файлов.

Этап 6. Идентификация лица. Хотя установлен MAC-АДРЕС ноутбука Петрова, эксперт отмечает в выводах, что MAC-АДРЕС технически может быть подменён (SPOOFING). Однако в логах коммутатора CISCO (по запросу следователя) не обнаружено признаков подмены (нет записей о конфликтах MAC, нетипичных переключениях портов). Кроме того, записи о входе Петрова по пропускной системе (СКУД) показали, что 10.09.2024 он находился в офисе до 04:00 утра (якобы работал над «срочным отчётом»), что давало ему физический доступ к сети. Совокупность косвенных доказательств (MAC, IP, время, физическое присутствие, мотив) позволила следователю предъявить обвинение. 👤

8.4. Выводы эксперта

1. Факт копирования трёх таблиц (client_pricing, discount_matrix, contract_terms), содержащих сведения, составляющие коммерческую тайну, установлен с абсолютной достоверностью.
2. Копирование осуществлено с помощью команд SELECT… INTO OUTFILE, выполненных 10.09.2024 в период с 02:15:33 по 02:17:30 (временная метка с точностью до миллисекунды).
3. Установлен IP-АДРЕС (192.168.45.122), MAC-АДРЕС (00:1A:2B:3C:4D:5E) и, с вероятностью, близкой к 0,99, рабочая станция (ноутбук сотрудника Петрова В.И.). Вероятность 0,99 обусловлена возможной подменой MAC-АДРЕСА, однако признаков подмены не обнаружено.
4. Общий объём скопированных данных: ~124 МБ (оценка на основе размера страниц INNODB и количества строк). Скопированы актуальные на момент копирования версии записей (по состоянию на 10.09.2024 02:15).

8.5. Процессуальный результат

Заключение эксперта легло в основу обвинительного заключения. Петров В.И. был признан виновным по ч. 3 ст. 183 УК РФ (незаконные получение и разглашение сведений, составляющих коммерческую тайну, с причинением крупного ущерба) и приговорён к 2 годам 6 месяцам лишения свободы условно с испытательным сроком 3 года, а также к штрафу в размере 500 тыс. рублей. Конкурент ООО «СофтМаркет» понёс гражданско-правовую ответственность в виде взыскания 87 млн рублей упущенной выгоды в пользу ООО «Цифровые технологии» (решение арбитражного суда по параллельному иску). 🏦

Этот кейс подчёркивает, что IT экспертиза баз данных и СУБД является незаменимым инструментом в борьбе с промышленным шпионажем и защите интеллектуальной собственности.

Глава 9. Особенности исследования NO-SQL баз данных (MONGODB, CASSANDRA, REDIS)

Хотя реляционные СУБД доминируют в корпоративном секторе, судебные эксперты всё чаще сталкиваются с НЕРЕЛЯЦИОННЫМИ ХРАНИЛИЩАМИ (NOSQL). 🗄️ Каждая платформа имеет уникальные особенности с точки зрения криминалистического анализа.

9.1. MONGODB (ДОКУМЕНТООРИЕНТИРОВАННАЯ БАЗА ДАННЫХ)

Объекты исследования: файлы данных WIREDTIGER (.wt), журналы OPLOG.RS (в репликасетах), логи аудита (если включены параметром auditLog), а также дампы оперативной памяти.

Особенности для экспертизы:

• Удалённые документы не сохраняются в журналах, если только не было включено АУДИРОВАНИЕ на уровне коллекции (команда db.setLogLevel()).
• OPLOG (операционный журнал) — циклический буфер ограниченного размера (обычно 5% от дискового пространства или 1 ГБ по умолчанию). Если с момента инцидента прошло много времени, записи могут быть перезаписаны.
• Восстановление удалённых документов возможно через анализ свободных EXTENTS в файлах.wt с помощью утилиты wt из состава WIREDTIGER (или коммерческих инструментов вроде MONGODB FORENSIC TOOLKIT). Однако это требует глубоких знаний внутреннего формата BSON (BINARY JSON).

Методика для MONGODB:
(1) Создание дампа OPLOG: mongodump —oplog. (2) Анализ OPLOG на наличие операций delete и update. (3) Для удалённых записей без OPLOG — низкоуровневый парсинг.WT-ФАЙЛОВ с поиском BSON-ОБЪЕКТОВ по сигнатурам (начало документа — тип 0x7B «{«, но в BSON первый байт — это размер документа). (4) Реконструкция удалённых документов. ⚙️

9.2. APACHE CASSANDRA (КОЛОНОЧНАЯ БАЗА ДАННЫХ)

Особенности для экспертизы:

• Данные распределены по нескольким узлам (КЛАСТЕР). Эксперту необходимо изымать образы СО ВСЕХ УЗЛОВ одновременно, так как на одном узле могут отсутствовать некоторые диапазоны данных (TOKENS). Частичный образ может дать ложное впечатление об отсутствии записей.
• Удаление записей маркируется TOMBSTONE («могильный камень») — запись с временной меткой удаления. TOMBSTONES хранятся до наступления gc_grace_seconds (по умолчанию 10 дней), после чего удаляются физически при COMPACTION (уплотнении).
• Используемый формат SSTABLE (SORTED STRING TABLE) бинарный, но имеется утилита sstabledump (входит в состав CASSANDRA).

Методика для CASSANDRA:
(1) Изъятие всех каталогов данных CASSANDRA (обычно /var/lib/cassandra/data). (2) Выполнение nodetool flush для принудительной записи MEMTABLE на диск (по согласованию со следствием, так как это может изменить временные метки). (3) Анализ SSTABLE через sstabledump и поиск TOMBSTONE с временными метками удаления. (4) Для удалённых записей, чей TOMBSTONE уже был утилизирован (COMPACTED), восстановление невозможно. 🕯️

9.3. REDIS (KEY-VALUE, IN-MEMORY)

Особенности для экспертизы:

• Основные данные находятся в ОПЕРАТИВНОЙ ПАМЯТИ. При выключении питания данные теряются, если не настроены RDB-ДАМПЫ (снэпшоты) или AOF-ФАЙЛЫ (APPEND ONLY FILE).
• AOF (APPEND ONLY FILE) — текстовый или бинарный лог всех команд (SET, DEL, HSET). Это ИДЕАЛЬНЫЙ ОБЪЕКТ для экспертизы, так как хранит полную историю.
• RDB-ДАМП — бинарный снэпшот, можно анализировать инструментом redis-rdb-tools (PYTHON).

Методика для REDIS:
(1) При работающем сервере — выполнение SAVE или BGSAVE для создания RDB-ДАМПА (с согласия следователя). (2) Анализ AOF-ФАЙЛА (если включён appendonly yes) — каждая команда имеет временную метку в микросекундах (в формате REDIS). (3) Восстановление удалённых ключей: если AOF включён и не был перезаписан (BGREWRITEAOF), то удаление через DEL фиксируется, но ПРЕДЫДУЩЕЕ ЗНАЧЕНИЕ может быть извлечено из журнала (поскольку AOF записывает команду SET с параметрами до DEL). (4) При отсутствии AOF — только анализ RDB-ДАМПОВ, которые могут быть устаревшими. ⏳

Общее правило: Для всех NOSQL-СИСТЕМ действует принцип — IT экспертиза баз данных и СУБД должна проводиться экспертом, имеющим опыт работы именно с этой платформой, а не с реляционными СУБД. Нельзя механически переносить методы анализа журналов из мира SQL в мир NOSQL — это ведёт к грубым ошибкам и утрате доказательств.

Глава 10. Восстановление удалённых данных: физический и логический уровни

Восстановление данных, уничтоженных в результате несанкционированного доступа или саботажа, — одна из важнейших задач IT экспертизы баз данных и СУБД. 🔧 Различают два принципиально разных уровня восстановления.

10.1. Логическое восстановление (LOGICAL RECOVERY)

Логическое восстановление возможно, когда данные были удалены на уровне СУБД (команда DELETE, TRUNCATE, DROP), но сами файлы БД не были перезаписаны на диске, а журналы транзакций или UNDO-сегменты сохранили «образы до» (BEFORE IMAGES).

Условия успеха:

• БД работает в режиме FULL RECOVERY (MS SQL SERVER) или ARCHIVELOG MODE (ORACLE), либо включён BINLOG_FORMAT = ROW (MYSQL).
• Журналы транзакций не были очищены или перезаписаны.
• Время, прошедшее с момента удаления, достаточно мало (часы или дни, не недели).

Инструменты:

• MS SQL SERVER: fn_dblog, сторонние утилиты (APEXSQL LOG).
• POSTGRESQL: pg_waldump + анализ DEAD TUPLES из файлов таблиц.
• MYSQL: mysqlbinlog, анализ UNDO LOG.
• ORACLE: LOG MINER.

10.2. Физическое восстановление (PHYSICAL RECOVERY / CARVING)

Физическое восстановление применяется, когда логические методы не сработали (журналы перезаписаны, файлы удалены через ОС, диск отформатирован). Эксперт работает напрямую с ПОСЕКТОРНЫМ ОБРАЗОМ диска, игнорируя файловую систему.

Алгоритм физического восстановления (карвинг):

1. Сканирование сигнатур. Поиск известных сигнатур (магических чисел) страниц БД. Например, для POSTGRESQL страница начинается с байта 0x0B (версия), затем 3 нулевых байта, затем 2-байтовое поле pd_lower. Для MYSQL INNODB сигнатура страницы — \376\111\337\142 (шестнадцатеричное fe 49 9f 62).
2. Извлечение страниц. После нахождения сигнатуры эксперт извлекает блок данных размером в страницу СУБД (обычно 8 КБ или 16 КБ). Проверяется контрольная сумма (если включена).
3. Анализ служебной информации страницы. На основе заголовка страницы эксперт определяет: номер страницы (PAGE NUMBER), тип (HEAP, INDEX, BLOB), количество записей (кортежей), смещения к свободному пространству.
4. Извлечение кортежей (строк). Эксперт обходит указатели (LINE POINTERS) в начале страницы, каждый указатель ведёт на смещение, где начинается кортеж. Для DEAD-кортежей (уже логически удалённых) указатели могут быть обнулены, но само тело кортежа может сохраниться. Эксперт ищет тела кортежей по паттернам: начало кортежа — бит HEAP_XMIN_COMMITTED или его аналоги.
5. Десериализация кортежа. Преобразование двоичного представления в конкретные типы данных (INT, DATE, VARCHAR, TEXT). Для этого требуется знание схемы таблицы (структуры столбцов). Если схема утрачена, эксперт может восстановить её по сигнатурам значений или косвенным признакам (например, целые числа чаще всего идут подряд).
6. Оценка полноты восстановления. Эксперт всегда указывает процент восстановленных данных и оговаривает, что часть данных могла быть перезаписана.

10.3. Проблема SSD и TRIM

Для SSD-НАКОПИТЕЛЕЙ физическое восстановление затруднено из-за команды TRIM (ATA COMMAND 0x06). Когда ОС удаляет файл, она может отправить TRIM-команду контроллеру SSD, который немедленно помечает блоки как «свободные для GC» (GARBAGE COLLECTION). Впоследствии эти блоки могут быть физически затерты в рамках операций внутренней дефрагментации.

Что делать эксперту:

• Немедленно отключить питание SSD (чтобы предотвратить работу GC в фоновом режиме).
• Создавать образ с помощью аппаратного IMAGER’а, который может вычитать данные даже после TRIM (но не после физического обнуления).
• Учитывать, что для SSD вероятность полного восстановления ниже, чем для HDD. Эксперт должен делать оговорку в выводах.

10.4. Пример из практики (восстановление POSTGRESQL после TRUNCATE и VACUUM FULL)

В кейсе №2 (Глава 6) было выполнено физическое восстановление после VACUUM FULL. VACUUM FULL не обнуляет страницы, а переписывает таблицу в новый файл, после чего старый файл удаляется. Пока старый файл не перезаписан другими данными, его страницы доступны для карвинга. Эксперт искал сигнатуры страниц POSTGRESQL в нераспределённом пространстве (UNALLOCATED CLUSTERS) и успешно извлёк 81% данных. Это классический пример успешного физического восстановления. 📈

Глава 11. Процессуальные аспекты назначения и производства IT-ЭКСПЕРТИЗЫ БАЗ ДАННЫХ И СУБД

11.1. Основания назначения в различных видах судопроизводства

• Уголовное судопроизводство (УПК РФ): ст. 195 — экспертиза назначается по постановлению следователя или дознавателя. Обязательное назначение не предусмотрено для КТЭ, но на практике при наличии цифровых доказательств без экспертизы не обойтись. При назначении важно указать, что эксперт предупреждается об ответственности по ст. 307 УК РФ. ⚖️
• Гражданское судопроизводство (ГПК РФ): ст. 79 — экспертиза назначается определением суда по ходатайству стороны или по инициативе суда. Сторона, заявляющая ходатайство, обязана внести предоплату на депозит суда (ст. 96 ГПК РФ).
• Арбитражное судопроизводство (АПК РФ): ст. 82 — аналогично ГПК, но с особенностями: эксперт должен быть аккредитован при СРО (саморегулируемой организации), если это предусмотрено законом. Союз «Федерация судебных экспертов» имеет такую аккредитацию. 🏛️

11.2. Содержание постановления / определения

Документ о назначении экспертизы должен содержать:

• Наименование суда / фамилию следователя.
• Краткое изложение обстоятельств дела, обосновывающих необходимость экспертизы.
• Перечень вопросов, поставленных перед экспертом (вопросы должны быть конкретными, техническими, не правовыми).
• Наименование экспертного учреждения (Союз «Федерация судебных экспертов») или фамилию конкретного эксперта (если он аттестован).
• Перечень объектов, предоставляемых в распоряжение эксперта (с указанием уникальных идентификаторов: серийные номера дисков, хэш-суммы образов).
• Предупреждение эксперта об уголовной ответственности (в уголовном процессе — обязательно, в гражданском/арбитражном — по усмотрению суда, но желательно).

11.3. Права и обязанности эксперта (ст. 57 УПК РФ, ст. 85 ГПК РФ, ст. 55 АПК РФ)

Эксперт вправе:

• Знакомиться с материалами дела, относящимися к предмету экспертизы.
• Заявлять ходатайства о предоставлении дополнительных материалов (например, эталонных образцов СУБД, логов антивируса).
• Привлекать к производству экспертизы других экспертов (с уведомлением лица, назначившего экспертизу).
• Отказаться от дачи заключения, если предоставленных материалов недостаточно или они не соответствуют требованиям (например, образ диска без хэш-сумм).

Эксперт обязан:

• Явиться по вызову следователя или суда.
• Дать объективное заключение по поставленным вопросам, основанное на научных методах.
• Предупредиться об уголовной ответственности по ст. 307 УК РФ (заведомо ложное заключение) и поставить подпись.
• Не разглашать данные предварительного следствия (подписка по ст. 161 УПК РФ).

11.4. Оценка заключения судом

Суд оценивает заключение по трём критериям (ст. 87 УПК РФ, ст. 67 ГПК РФ, ст. 71 АПК РФ):

• ДОПУСТИМОСТЬ: соблюдена ли процедура назначения, не нарушены ли права сторон, предоставлены ли объекты в надлежащем виде (образы дисков с хэш-суммами, а не копии файлов через проводник). Если эксперт использовал нелицензионное ПО или не указал методику, это может быть основанием для исключения.
• ОТНОСИМОСТЬ: относится ли заключение к обстоятельствам дела. Например, экспертиза БД складского учёта не имеет отношения к делу о ДТП (дорожно-транспортном происшествии).
• ДОСТОВЕРНОСТЬ: научная обоснованность метода, полнота исследования, отсутствие противоречий в выводах, соответствие другим доказательствам.

Суд может назначить ДОПОЛНИТЕЛЬНУЮ экспертизу (при неполноте ответов, тому же или другому эксперту) или ПОВТОРНУЮ (при сомнениях в обоснованности, другому эксперту). В Союзе «Федерация судебных экспертов» мы даём заключения, которые выдерживают самую строгую судебную проверку. ✅

Глава 12. Регламент изъятия объектов для IT ЭКСПЕРТИЗЫ БАЗ ДАННЫХ И СУБД

Нарушение правил изъятия цифровых носителей — наиболее частая причина признания экспертизы недопустимым доказательством. 📌 Приведём обязательный алгоритм для следователей и оперативных сотрудников (на основе «Порядка изъятия компьютерной информации», утверждённого Генеральной прокуратурой РФ 2017 г., и методических рекомендаций СК РФ 2019 г.):

Шаг 1. Фиксация состояния. Перед отключением сервера от электросети необходимо:

• Сделать фотографии всех подключённых кабелей (питание, сеть, хранилище) и индикаторов на корпусе (LED (LIGHT-EMITTING DIODE)).
• Зафиксировать время по системным часам сервера (фото экрана с командой date в LINUX или time /t в WINDOWS, а также через BIOS (BASIC INPUT/OUTPUT SYSTEM)).
• Записать список запущенных процессов (ps aux > processes.txt в LINUX, tasklist > processes.txt в WINDOWS).

Шаг 2. Живой сбор (LIVE FORENSICS). До отключения питания (если нет риска удалённого уничтожения через сеть):

• Выполнить дамп ОПЕРАТИВНОЙ ПАМЯТИ (BELKASOFT RAM CAPTURER для WINDOWS, LIME для LINUX, MACQUISITOR для MACOS).
• Записать содержимое таблиц ARP (ARP -A) и кэша DNS (IPCONFIG /DISPLAYDNS или SYSTEMD-RESOLVE).
• Скопировать текущие журналы СУБД и ОС, если они не хранятся на изымаемом диске.

Шаг 3. Отключение и изъятие носителя. Сервер отключается ШТАТНО (команда SHUTDOWN /S /T 0 в WINDOWS, shutdown -h now в LINUX), если нет риска удаления данных. Если есть подозрение на удалённое уничтожение (например, активная сессия злоумышленника), отключение производится ПРИНУДИТЕЛЬНО (выдергивание кабеля питания). Носитель (HDD, SSD, NVME) изымается, маркируется (бирка с датой, подписью понятых), упаковывается в АНТИСТАТИЧЕСКИЙ ПАКЕТ и опечатывается печатью следователя.

Шаг 4. Создание образа. В лабораторных условиях с помощью АППАРАТНОГО WRITE-BLOCKER (TABLAU, ATOLA, LOGICUBE) создаётся ПОСЕКТОРНЫЙ ОБРАЗ в формате E01 (ENVASE EVIDENCE FILE), AFF (ADVANCED FORENSIC FORMAT) или RAW (DD). Вычисляются ХЭШ-СУММЫ (MD5, SHA-1, SHA-256). Оригинал носителя возвращается на хранение в опечатанном контейнере.

Шаг 5. Передача эксперту. Образ на зашифрованном носителе (или через защищённый канал, например, SFTP (SECURE FILE TRANSFER PROTOCOL)) передаётся эксперту вместе с постановлением/определением. ХЭШ-СУММЫ сверяются при передаче.

Категорический запрет: Никогда не включайте сервер в обычном режиме после изъятия и не копируйте файлы через ПРОВОДНИК WINDOWS! Это изменяет временные метки файлов ($MFT (MASTER FILE TABLE) в NTFS) и может уничтожить следы удалённых данных. 🚫

Глава 13. Типичные ошибки при производстве «Альтернативных» исследований и способы их выявления

Для судей, адвокатов и следователей полезно знать, на какие «красные флаги» обращать внимание в заключениях оппонентов (или «альтернативных экспертов»), чтобы оспорить их. 🚩

Ошибка 1. Отсутствие методики или ссылка на ненаучные источники. Заключение содержит фразы: «на основе опыта эксперта», «общеизвестный факт», «по нашему мнению», или ссылается на статьи из ВИКИПЕДИИ. Научно обоснованная экспертиза должна ссылаться на конкретные методики (например, «восстановление проведено в соответствии с методикой, описанной в работе Иванова П.П. «Судебное исследование баз данных POSTGRESQL», опубликованной в журнале «Теория и практика судебной экспертизы» №4, 2022»).

Ошибка 2. Несоответствие выводов объёму исследования. Эксперт исследовал только файл журнала за 1 час, но делает выводы о событиях за 3 месяца. Или использовал только один инструмент (например, grep для бинарных файлов) и утверждает, что «данных нет» — на самом деле они есть, но неправильно извлечены.

Ошибка 3. Использование инструментов без верификации. Указано название программы (например, «APEXSQL LOG»), но не её версия, не указано, сертифицирована ли она для судебной экспертизы (лицензия FORENSIC EDITION). Использование нелицензионного ПО — основание для признания заключения недопустимым (ст. 75 УПК РФ).

Ошибка 4. Логическая противоречивость. Выводы противоречат друг другу или здравому смыслу. Пример: «Файлы базы данных были удалены 01.01.2024, но последняя запись в журнале транзакций датирована 10.01.2024» — так не бывает, потому что журнал транзакций является частью БД.

Ошибка 5. Выход за пределы компетенции. Эксперт делает выводы о ВИНОВНОСТИ, МОТИВЕ, ПСИХИЧЕСКОМ СОСТОЯНИИ лица. Например: «Петров удалил базу данных с целью скрыть следы хищения». Вывод о цели — это компетенция следователя и суда, не эксперта. Такое заключение может быть признано недопустимым.

Ошибка 6. Отсутствие хэш-сумм и нарушения цепи хранения. Эксперт не указал HASH-СУММЫ предоставленных объектов или не зафиксировал, в каком виде (образ или папка с файлами) он получил данные. Это делает невозможным проверку того, что исследовались именно те объекты, которые были изъяты.

Ошибка 7. Непредупреждение об ответственности по ст. 307 УК РФ. В уголовном процессе это фатальное нарушение — заключение теряет статус судебного доказательства.

Как оспорить: Заявить ходатайство о признании заключения ненадлежащим доказательством и о назначении повторной IT экспертизы баз данных и СУБД в Союзе «Федерация судебных экспертов». Приложить к ходатайству перечень выявленных нарушений. Суд, как правило, удовлетворяет такие ходатайства, если есть разумные сомнения. 📑

Глава 14. Роль эксперта в судебном заседании: допрос и перекрестный допрос

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

14.1. Подготовка к допросу

• Эксперт заново перечитывает своё заключение, особенно разделы «Методика исследования» и «Выводы». Недопустима импровизация, противоречащая тексту.
• Эксперт готовит краткие пояснения по ключевым терминам (LSN, WAL, MVCC, TOMBSTONE и т.д.) для суда и присяжных, не имеющих технического образования.
• Адвокат стороны, назначившей экспертизу, может провести «тренировочный» перекрёстный допрос, чтобы выявить слабые места.

14.2. Вопросы суда и сторон

• Суд задаёт вопросы о методике, полноте исследования, соответствии выводов поставленным вопросам.
• Адвокаты могут задавать ЛЮБЫЕ вопросы, в том числе каверзные: «Почему вы не использовали инструмент Х?», «Не могли ли журналы быть подделаны задним числом?», «Какова погрешность вашего метода?», «Не является ли ваше заключение ангажированным?».

14.3. Ответы эксперта

• Эксперт отвечает СПОКОЙНО, ФАКТИЧЕСКИ, со ссылками на разделы заключения.
• Если вопрос выходит за пределы компетенции («Считаете ли вы, что Петров виновен?»), эксперт вежливо отказывается: «Этот вопрос относится к правовой квалификации, я не вправе на него отвечать».
• Если вопрос требует дополнительного исследования (например, о работе другого сервера, не предоставленного эксперту), эксперт говорит: «Для ответа на этот вопрос необходимы дополнительные материалы, которые не были предоставлены».

14.4. Пример удачного перекрёстного допроса (из практики)

Адвокат: «Эксперт, вы утверждаете, что временные метки были подделаны. Но может быть, это просто ошибка СУБД?»
Эксперт: «В MICROSOFT SQL SERVER 2019 STANDARD EDITION не зафиксировано ни одной ошибки, приводящей к инверсии LSN и TIME. Это подтверждено документацией MICROSOFT и многолетней практикой. Мои выводы основаны на сравнении 12 487 записей журнала, где инверсия встретилась 2 345 раз — вероятность случайности стремится к нулю».
Адвокат (после паузы): «Вопросов больше нет».

Профессионально проведённый допрос эксперта часто предрешает исход дела. Именно поэтому наши эксперты проходят специальные тренинги по судебной риторике и конфликтологии. 🧠

Глава 15. Будущее IT-ЭКСПЕРТИЗЫ БАЗ ДАННЫХ И СУБД: вызовы и перспективы

Технологии развиваются стремительно, и эксперты должны быть готовы к новым вызовам. 🚀

15.1. Облачные базы данных (CLOUD DATABASES)

Проблема: AMAZON RDS (RELATIONAL DATABASE SERVICE), GOOGLE CLOUD SQL, MICROSOFT AZURE SQL, YANDEX.CLOUD. Эксперт не имеет физического доступа к серверу. Исследование возможно только через API (APPLICATION PROGRAMMING INTERFACE) и бэкапы.

Решение: Ходатайствовать о предоставлении снапшотов (SNAPSHOTS) дисков на момент инцидента, логов аудита (AWS CLOUDTRAIL, AZURE AUDIT LOGS), информации о всех подключениях (IP, времена, длительность, использованные учётные записи). Важно: некоторые провайдеры хранят логи ограниченное время (например, 30 дней). Поэтому ходатайствовать нужно НЕМЕДЛЕННО после возбуждения дела. ⏱️

15.2. Блокчейн-платформы (BLOCKCHAIN)

Проблема: Блокчейн (ETHEREUM, HYPERLEDGER FABRIC) сам по себе считается неизменяемым, но эксперту могут быть предоставлены не все узлы сети. Также анализируется STATE DB (LEVELDB/ROCKSDB) на узлах — она может быть модифицирована локально.

Решение: Эксперт устанавливает консенсусную истинность данных через запрос к нескольким независимым узлам (если это возможно). Анализирует смарт-контракты и логи событий (EVENT LOGS). Признаёт, что восстановление данных, удалённых из блокчейна, невозможно (в отличие от БД).

15.3. Искусственный интеллект и машинное обучение (AI/ML)

С одной стороны: AI используется для автоматизации анализа больших массивов журналов (обнаружение аномалий в SQL-запросах, кластеризация временных меток).

С другой стороны: злоумышленники могут использовать ГЕНЕРАТИВНЫЕ НЕЙРОСЕТИ (например, GAN (GENERATIVE ADVERSARIAL NETWORK)) для синтеза поддельных логов, неотличимых от реальных. Экспертам придётся осваивать методы статистического обнаружения синтетических данных (анализ распределения временных интервалов, энтропии, частотности символов).

15.4. Пост-квантовая криптография и шифрование

Если база данных была зашифрована с помощью устойчивых к квантовым атакам алгоритмов (например, CRYSTALS-KYBER), восстановление данных без ключа становится практически невозможным. Эксперт может лишь подтвердить факт шифрования и попытаться найти ключ в оперативной памяти или журналах.

Вывод по главе: IT экспертиза баз данных и СУБД будет эволюционировать, оставаясь критически важным инструментом правосудия. Союз «Федерация судебных экспертов» активно участвует в научных разработках в этих областях, публикует статьи в рецензируемых журналах и готовит экспертов к работе с новыми типами объектов. 🔬

Заключение: интеграция научных методов в судебную практику

Проведённый анализ, охвативший 15 глав, позволил сделать несколько фундаментальных выводов.

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

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

В-третьих, представленные три кейса из реальной практики Союза «Федерация судебных экспертов» (фальсификация журналов транзакций в MS SQL SERVER, восстановление удалённой базы данных POSTGRESQL после увольнения администратора, расследование экономического шпионажа с копированием CRM-БАЗЫ MYSQL) наглядно демонстрируют, что даже при попытке хитроумной фальсификации, удаления записей с использованием VACUUM FULL, изменения системного времени или скрытого копирования данных в ночное время — профессиональное научное исследование способно восстановить истинную картину событий. Более того, в некоторых случаях удаётся восстановить сами данные (до 96% в кейсе №2), что позволяет рассчитать точный ущерб и привлечь виновных к ответственности. 📊

Приглашение к сотрудничеству

Мы приглашаем всех участников судопроизводства — судей, следователей, адвокатов, корпоративных юристов и представителей бизнеса — к сотрудничеству с Союзом «Федерация судебных экспертов». Наши преимущества:

• ✅ Полная процессуальная независимость: мы не аффилированы ни с одной из сторон, работаем на основании определений суда или постановлений следователей, предупреждаемся об ответственности по ст. 307 УК РФ.
• ✅ Высшая квалификация: все эксперты имеют высшее техническое образование, сертификаты по конкретным СУБД (MICROSOFT, ORACLE, POSTGRESQL, MYSQL), регулярно повышают квалификацию.
• ✅ Научная обоснованность: мы используем собственные апробированные методики, опубликованные в рецензируемых журналах, и только лицензионное ПО.
• ✅ Практический опыт: сотни успешно завершённых экспертиз, десятки выступлений в судах всех уровней, включая ВЕРХОВНЫЙ СУД РФ.
• ✅ Комплексный подход: при необходимости мы привлекаем экспертов смежных специальностей (бухгалтерская, экономическая, товароведческая экспертизы) для комплексного исследования.

Узнать подробнее о порядке заказа IT экспертизы баз данных и СУБД, задать вопросы нашим специалистам, ознакомиться с перечнем типовых вопросов и стоимостью, а также оставить заявку на исследование вы можете на официальном сайте Союза «Федерация судебных экспертов»:

https://kriminalist77.ru/ekspertiza-baz-dannyh/

Доверьте цифровую истину профессионалам. 🟩