🟩 Компьютерная экспертиза баз данных и СУБД: архитектура, методы низкоуровневого анализа

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

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

Разрушить этот миф и предоставить суду реальные, неопровержимые доказательства способна только настоящая компьютерная экспертиза баз данных и СУБД, выполненная на инженерном уровне — то есть с прямым доступом к байтовой структуре файлов, журналов транзакций и системных каталогов. Союз «Федерация судебных экспертов» на протяжении 14 лет развивает это направление, объединяя теорию реляционных баз данных, компьютерную криминалистику и процессуальное право в единую научно-практическую дисциплину. В настоящей статье мы подробно разберём архитектурные особенности различных СУБД с точки зрения их уязвимости к фальсификациям, опишем конкретные методы обнаружения следов несанкционированных изменений, приведём три реальных кейса из нашей практики (с изменёнными идентифицирующими данными) и дадим практические рекомендации по назначению и проведению подобных исследований. 🧠💻🔍

Глава 1. Определение и границы понятия «компьютерная экспертиза баз данных» 📚⚖️

Прежде чем переходить к техническим деталям, необходимо чётко определить, что именно подразумевается под компьютерной экспертизой баз данных и СУБД в контексте судебного делопроизводства. Согласно методическим рекомендациям, разработанным Союзом «Федерация судебных экспертов» и одобренным Научно-консультативным советом при Арбитражном суде Московского округа, под данным термином понимается комплексное процессуальное и техническое исследование, объектами которого выступают:

1️⃣ Файлы, содержащие пользовательские и служебные данные СУБД: MDF, NDF (MICROSOFT SQL SERVER), DBF (ORACLE), IBD, FRM (MYSQL), файлы в каталоге BASE (POSTGRESQL), а также иные форматы, используемые конкретной системой управления базами данных.

2️⃣ Журналы транзакций всех типов: LDF, REDO LOGS, ARCHIVE LOGS, WAL (WRITE-AHEAD LOG), BINLOG, а также связанные с ними управляющие файлы (CONTROL FILES в ORACLE, PG_CONTROL в POSTGRESQL).

3️⃣ Системные каталоги и словари данных — как в виде предопределённых представлений (INFORMATION_SCHEMA, SYS.TABLES), так и в виде физических файлов (PG_CLASS, SYS.SYSOBJECTS).

4️⃣ Резервные копии баз данных (полные, дифференциальные, инкрементальные) в проприетарных форматах (BAK, DMP, SQL-дампы с расширенной информацией).

5️⃣ Дампы оперативной памяти серверов СУБД, полученные криминалистическими методами (без штатного завершения процессов).

6️⃣ Сетевые трассировки (PCAP/PCAPNG) взаимодействия между клиентскими приложениями и сервером СУБД, особенно при использовании шифрованных соединений (SSL/TLS) — в таких случаях анализируются метаданные TLS-рукопожатий.

Важнейшее методологическое требование: эксперт не должен доверять данным, возвращаемым через штатные интерфейсы СУБД (ODBC, JDBC, OLE DB, NPGSQL и т.д.), поскольку при наличии у злоумышленника прав администратора эти интерфейсы могут быть модифицированы (например, через внедрение DLL-прокси или модификацию системных хранимых процедур). Единственным надёжным источником является физический образ диска, полученный через WRITE-BLOCKER, с последующим прямым парсингом байтовых структур. Именно этот принцип отличает настоящую судебную экспертизу от поверхностного ИТ-аудита, который не имеет доказательственной силы в спорах высокой сложности. ⛓️🛡️

Глава 2. Физическая организация данных в реляционных СУБД: страницы, экстенты и слоты 🗂️🧩

Для понимания возможностей и ограничений экспертизы необходимо рассмотреть, как именно данные физически размещаются на носителе. Подавляющее большинство промышленных СУБД (MICROSOFT SQL SERVER, ORACLE DATABASE, POSTGRESQL, MYSQL с движком INNODB, FIRBIRD, INTERBASE) используют страничную организацию хранения. Основные параметры:

🔹 Размер страницы: фиксирован для каждой СУБД и обычно составляет 4 КБ (для некоторых конфигураций ORACLE), 8 КБ (MICROSOFT, POSTGRESQL), 16 КБ (MYSQL INNODB по умолчанию), 32 КБ (MAX-конфигурации). Размер страницы задаётся при создании базы данных и не может быть изменён без её пересоздания (за исключением ORACLE, где допускается несколько пулов с разным размером блоков).

🔹 Экстент — группа из 8 логически смежных страниц (для MICROSOFT и SYBASE) или 64 страниц (для ORACLE). Экстенты выделяются СУБД для таблиц и индексов блоками, чтобы снизить фрагментацию.

🔹 Заголовок страницы — область фиксированного размера (от 96 до 128 байт в зависимости от СУБД), содержащая:

Уникальный идентификатор страницы (PAGE_ID, BLOCK_ID).
Номер объекта (OBJECT_ID, TABLE_OID) и индекса (INDEX_ID, INDEX_OID), которому принадлежит страница.
LSN (LOG SEQUENCE NUMBER) — последний номер записи журнала, применённой к данной странице.
Контрольную сумму (CHECKSUM), вычисляемую по алгоритму CRC32, MD5 или аппаратно-зависимому.
Флаги состояния: «грязная страница», «только для чтения», «сжатая страница», «зашифрованная страница».
Ссылки на предыдущую и следующую страницу в экстенте (LINK_PREV, LINK_NEXT), что организует двусвязный список страниц для каждого объекта.

🔹 Массив слотов (SLOT ARRAY) — область в конце страницы (растёт сверху вниз, в то время как данные записей растут снизу вверх). Каждый слот — это 2-байтовое (реже 4-байтовое) смещение от начала страницы, указывающее на начало записи. Количество слотов равно количеству записей (строк) на странице.

🔹 Запись (ROW, TUPLE) — переменная область, содержащая фактические данные столбцов. Формат записи различается между СУБД и может быть:

Фиксированным (все столбцы имеют предопределённую длину, NULL-значения занимают место).
Переменным (каждое поле предваряется длиной или смещением).
Сжатым (PAGE COMPRESSION, ROW COMPRESSION).

При выполнении операции DELETE запись не удаляется физически. Вместо этого в заголовке слота выставляется бит удаления (обычно старший бит 2-байтового смещения), а в заголовке страницы увеличивается счётчик свободного пространства. Сами байты записи остаются нетронутыми до тех пор, пока фоновый процесс (AUTOVACUUM в POSTGRESQL, LAZY WRITER в MICROSOFT, PURGE в ORACLE) не решит, что страница нуждается в уплотнении (DEFRAGMENTATION, SHRINK). Это «окно уязвимости» может составлять от нескольких часов до нескольких недель, в зависимости от нагрузки и настроек СУБД. Именно в этот период эксперт может восстановить удалённые строки даже при отсутствии резервных копий и журналов. 🧬🔬

Глава 3. Журналы транзакций: анатомия и методы анализа 📜⚙️

Журнал транзакций — это наиболее ценный объект для эксперта, поскольку в нём фиксируется вся история изменений данных. Однако разные СУБД реализуют журналирование по-разному, что влияет на методы анализа.

MICROSOFT SQL SERVER (LDF-файлы) 🪟

Журнал разбит на виртуальные файлы журнала (VLF — VIRTUAL LOG FILES), которые циклически переиспользуются. Каждая запись журнала имеет уникальный LSN (LOG SEQUENCE NUMBER) формата VLF_ID (4 байта): LOG_BLOCK_ID (4 байта): LOG_RECORD_ID (2 байта). Типы записей (LOP_*):

LOP_BEGIN_XACT — начало транзакции.
LOP_COMMIT_XACT — фиксация транзакции.
LOP_INSERT_ROWS, LOP_MODIFY_ROW, LOP_DELETE_ROWS — операции с данными.
LOP_FORMAT_PAGE, LOP_DELTA, LOP_ROOT_CHANGE — низкоуровневые операции.

Особенность MS SQL: журнал может быть прочитан даже при отключённой базе данных с помощью недокументированной функции DBCC LOG или сторонних парсеров (например, APTARE, ApexSQL Log). Наша лаборатория использует собственный парсер MSLSNREADER на C++, который работает напрямую с бинарным файлом LDF, не требуя запуска SQL SERVER. Это исключает риск изменения данных при монтировании.

POSTGRESQL (WAL — WRITE-AHEAD LOG) 🐘

WAL-файлы имеют имена вида 000000010000000000000001 (24 шестнадцатеричных символа) и размер 16 МБ по умолчанию. Каждая запись WAL содержит:

XID (TRANSACTION ID) — 32-битный идентификатор транзакции.
Ресурсный менеджер (RMGR) — тип операции (HEAP, BTREE, XLOG, STORAGE).
PAGE_ID и
Смещение и длину изменяемых данных.

Ключевая особенность POSTGRESQL: WAL не хранит старые версии строк для UNDO (эту функцию выполняет журнал отката в таблицах). Поэтому восстановление старых версий возможно только через анализ мёртвых кортежей (DEAD TUPLES) в основных файлах данных. Для парсинга WAL мы используем модифицированную версию утилиты pg_waldump с ключом —raw, выводящую сырые байты изменений, а также собственный скрипт на PYTHON с библиотекой construct для декодирования записей.

ORACLE DATABASE (REDO LOGS и ARCHIVE LOGS) 💎

REDO LOGS — это бинарные файлы фиксированного размера (от 10 МБ до нескольких ГБ), которые перезаписываются циклически. ARCHIVE LOGS — это те же REDO LOGS, но сохранённые на диск перед перезаписью (если включён режим ARCHIVELOG). Каждая запись REDO содержит VECTOR CHANGE (изменение байтового диапазона в блоке данных). ORACLE не хранит в REDO полные строки, только изменения (дельта) — поэтому восстановление удалённой строки возможно только через UNDO SEGMENTS.

Для анализа REDO LOGS мы используем инструменты пакета ORACLE LOGMINER (вызываемые из SQL*PLUS), но на отключённой копии базы, работающей на изолированном сервере. Это штатный метод, однако он требует наличия запущенного экземпляра ORACLE, что увеличивает риск изменения данных. Альтернатива — использование проприетарного парсера REDO-PARSER (разработка нашей лаборатории), который анализирует файлы REDO без запуска СУБД, но его возможности ограничены версиями ORACLE до 19C.

MYSQL / MARIADB (BINLOG) 🐬

BINLOG существует в двух форматах: STATEMENT (хранятся тексты SQL-запросов) и ROW (хранятся изменения строк в бинарном виде). Для судебной экспертизы предпочтителен ROW, так как он позволяет точно определить, какие значения изменились. BINLOG-файлы нумеруются (mysql-bin.000001, mysql-bin.000002 и т.д.), а текущая позиция хранится в файле mysql-bin.index. Анализ выполняется штатной утилитой mysqlbinlog —verbose —base64-output=DECODE-ROWS, которая выводит изменения в читаемом виде. Однако эксперт должен всегда сравнивать вывод mysqlbinlog с сырым файлом BINLOG через HEX-редактор, поскольку утилита может интерпретировать данные неоднозначно (например, для BLOB и TEXT полей).

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

Глава 4. Типовые задачи, решаемые в ходе экспертизы 🎯📋

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

Вопросы о факте и способе внесения изменений ✍️

Имеют ли место в исследованной базе данных несанкционированные изменения записей (добавление, модификация, удаление)? Если да, то в какой период времени, с использованием каких учётных записей и с каких рабочих станций (IP-адресов, имен хостов) они выполнены?
Были ли изменены служебные поля временных меток (CREATED_AT, UPDATED_AT, MODIFIED_DATE) или системные атрибуты (LASTUPDATE, ROWVERSION, TIMESTAMP)? Если да, то каковы были реальные значения времени фиксации транзакций (COMMIT TIMESTAMP) в журнале?

Вопросы о восстановлении утраченной информации 🔄
3) Возможно ли восстановить удалённые записи из таблицы [НАИМЕНОВАНИЕ ТАБЛИЦЫ] за период с [ДАТА] по [ДАТА]? Если да, то восстановить их в виде отдельного файла данных (SQL-дамп, CSV, таблица EXCEL) с указанием для каждой записи времени удаления (по журналу транзакций).

Имеются ли в файлах базы данных, на резервных копиях или в нераспределённом пространстве диска фрагменты данных, позволяющие восстановить структуру удалённой таблицы (или всей базы данных), даже если команда DROP была выполнена с очисткой журналов?

Вопросы о соответствии данных 📊
5) Соответствуют ли данные в пользовательских таблицах правилам ссылочной целостности, заданным в схеме базы данных (FOREIGN KEY, CHECK CONSTRAINT)? Если нет, то в результате каких операций (DDL, DML, прямое редактирование страниц) возникли нарушения?

Соответствуют ли значения в столбцах типа AUTO_INCREMENT (SEQUENCE, IDENTITY, SERIAL) ожидаемой последовательности (монотонное возрастание без пропусков, если не было удалений)? Если обнаружены аномалии (блочные вставки, пропуски, сброс последовательности), то с чем они связаны?

Вопросы о целостности журналов 📜
7) Имеются ли в журналах транзакций (LDF, WAL, REDO, BINLOG) признаки их частичного или полного уничтожения, перезаписи, редактирования (разрывы последовательностей LSN, несоответствие контрольных сумм, аномальные временные метки)? Если да, то каков объём утраченной информации и возможно ли восстановление утраченных записей журналов?

Каждый из этих вопросов требует применения специфических методов, описанных в последующих главах. Важно отметить, что эксперт имеет право отказаться от ответа на вопрос, если объект исследования находится в состоянии, не позволяющем дать надёжный ответ (например, журналы полностью перезаписаны, а резервные копии отсутствуют). Однако в большинстве случаев (более 85%) удаётся получить информацию, достаточную для категорического вывода. 🎓📌

Глава 5. Кейс №1: Фальсификация реестра акционеров через DBCC WRITEPAGE (MICROSOFT SQL SERVER) 🏢📉💥

Обстоятельства дела: Акционерное общество «Северсталь-Инвест» (название изменено) обратилось в арбитражный суд с иском к бывшему генеральному директору о взыскании убытков в размере 187 млн рублей. Истец утверждал, что ответчик в период с 15.03.2022 по 10.06.2022 внёс в реестр акционеров ложные сведения о переходе прав на 15% акций на подставных лиц, после чего акции были проданы по заниженной цене. В качестве доказательства истец представил распечатки таблицы Shareholders из базы данных учёта ценных бумаг. Ответчик настаивал на том, что данные распечатки — фальсификация, так как оригинальная база данных содержит правильные сведения, а изменения были внесены уже после увольнения истца. Суд назначил компьютерную экспертизу баз данных и СУБД, поручив её проведение Союзу «Федерация судебных экспертов».

Исходные данные, предоставленные на экспертизу:

Два образа дисков сервера БД (SAMSUNG PM983 1,92 TB NVME SSD), выполненные через FORENSIC IMAGER с разницей в 21 день (образ №1 от 01.06.2022, образ №2 от 22.06.2022). Оба образа заверены нотариально, контрольные суммы SHA256: ..и 0x3B91….
Выгрузка таблицы Shareholdersв формате CSV, датированная 14.06.2022 (представлена истцом).
Логи доступа к серверу из системы WINDOWS SECURITY EVENT LOG.

Ход исследования 🔬

Этап 1. Восстановление цепочки LSN из журнала транзакций
С помощью парсера MSLSNREADER были извлечены все записи журнала LDF за период с 01.06.2022 по 22.06.2022. Общее количество записей — 1 847 203. Построен график зависимости COMMIT_TIMESTAMP (время фиксации транзакции, полученное из записей LOP_COMMIT_XACT) от LSN. График показал строго линейную зависимость (коэффициент корреляции Пирсона R² = 0,9997), что свидетельствует об отсутствии подмены системного времени и целостности журнала.

Этап 2. Сравнение выгрузки истца с данными из журнала
Для каждой записи из CSV-файла истца были определены LSN последней модификации соответствующей строки в таблице Shareholders. 47 записей (из 312) имели LSN, соответствующие периоду после увольнения ответчика (после 31.05.2022). Однако при анализе журнала было обнаружено, что для этих 47 записей отсутствуют операции LOP_MODIFY_ROW или LOP_INSERT_ROWS. Вместо этого найдены записи типа LOP_FORMAT_PAGE и LOP_DELTA, которые обычно соответствуют операциям перестроения индекса и дефрагментации, но не изменениям пользовательских данных. Это первое аномальное наблюдение.

Этап 3. Прямой анализ страниц данных
Выполнен дамп страницы (PAGE_ID = 0x15A3F), содержащей одну из «подозрительных» записей. Заголовок страницы:

LSN: 0x0000002F:000001D0:0003
Флаг DIRTY_PAGE: сброшен (0x00)
Контрольная сумма: 0x8F4A3C22

При повторном дампе той же страницы из образа №2 (от 22.06.2022) обнаружено:

LSN остался тем же (0x0000002F:000001D0:0003)
Контрольная сумма изменилась на 0x9B17E45F
Флаг DIRTY_PAGE остался сброшенным

Это физически невозможно: если страница была изменена, LSN должен увеличиться, а флаг DIRTY_PAGE должен быть установлен (и затем сброшен CHECKPOINT’ом). Следовательно, страница была отредактирована напрямую, минуя SQL ENGINE. Единственный способ сделать это в MS SQL SERVER — команда DBCC WRITEPAGE (недокументированная, доступна только членам предопределённой роли сервера SYSADMIN).

Этап 4. Поиск следов выполнения DBCC WRITEPAGE
В журнале ошибок SQL SERVER (ERRORLOG) за 14.06.2022 в 13:47:22 обнаружена запись: DBCC WRITEPAGE: database_id=5, file_id=1, page_id=0x15A3F, offset=0, length=8192, data=0x9B17E45F…. Этой записи не было в стандартном журнале транзакций, но она присутствовала в ERRORLOG, который не был предоставлен истцом, но был извлечён экспертами из образа системного диска (путь C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log\ERRORLOG).

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

Файл CSV, представленный истцом, содержит 47 записей, которые были сфальсифицированы путём прямого редактирования страниц данных с помощью команды DBCC WRITEPAGE. Редактирование выполнено 14.06.2022 в 13:47:22, то есть уже после увольнения ответчика.
Первоначальные (истинные) значения записей в таблице Shareholders(по состоянию на 31.05.2022) не содержали перехода прав на 15% акций. Эти значения восстановлены из резервной копии базы данных, сделанной 30.05.2022 (файл bak, также изъятый с сервера).
Ответчик не мог выполнить указанные действия, так как его учётная запись была деактивирована 31.05.2022 в 18:00. Прямой доступ к серверу в момент фальсификации имел только главный бухгалтер (учётная запись corp\glavbuh), который действовал в интересах истца.

Судебное решение ⚖️
Суд признал заключение эксперта допустимым и достоверным доказательством. В удовлетворении иска АО «Северсталь-Инвест» к бывшему генеральному директору отказано в полном объёме. Более того, суд передал материалы дела в правоохранительные органы для проверки факта фальсификации доказательств со стороны истца (ч. 3 ст. 303 УК РФ). Дело получило широкую огласку в корпоративных СМИ.

Этот кейс наглядно демонстрирует, что компьютерная экспертиза баз данных и СУБД способна не только выявить подделку, но и установить точное время, метод и, при определённых условиях, личность злоумышленника. 🧨👨‍⚖️

Глава 6. Кейс №2: Восстановление базы данных после DROP DATABASE и SHRED (POSTGRESQL) 🗑️💿🔄

Обстоятельства дела: Межрегиональная ассоциация перевозчиков «Дальнобойщик» (некоммерческая организация) в течение 5 лет вела учёт страховых полисов ОСАГО и добровольного страхования грузов в базе данных POSTGRESQL 13.4 на сервере под управлением LINUX UBUNTU 20.04. 15.08.2023 сотрудник, уволенный за систематические нарушения трудовой дисциплины, за 2 часа до окончания своего рабочего дня подключился к серверу по SSH, выполнил DROP DATABASE insurance_db; и, что самое критическое, запустил утилиту shred -z -n 3 /var/lib/postgresql/13/main/base/16384/* (тройная перезапись случайными данными с финальной записью нулей). Резервные копии в соответствии с регламентом должны были храниться на отдельном файловом сервере, но обнаружилось, что копии не делались в течение 8 месяцев (халатность системного администратора). Ассоциации грозил банкротство из-за невозможности подтвердить наличие страховок по 18 крупным ДТП на сумму 47 млн рублей.

Постановка вопроса перед экспертом: Возможно ли восстановить данные таблиц, удалённых командой DROP DATABASE с последующей перезаписью файлов данных утилитой SHRED, и если да — восстановить структуру и содержимое таблиц «Полисы ОСАГО» и «ДТП»?

Исходные данные: Физический образ SSD-накопителя SAMSUNG 870 EVO 500 ГБ, изъятого в ходе осмотра места происшествия через 72 часа после инцидента (к этому моменту сервер был выключен, SSD помещён в антистатический пакет). Дополнительно предоставлен дамп оперативной памяти сервера, полученный через LIME (LINUX MEMORY EXTRACTOR) перед выключением питания.

Ход исследования 🛠️

Этап 1. Анализ состояния SSD после SHRED
Утилита shred -z -n 3 выполняет три прохода перезаписи случайными данными и один проход нулями. При работе с SSD алгоритм SHRED неэффективен по двум причинам: (1) контроллер SSD выравнивает износ (WEAR LEVELING) и может перенаправлять запись на другой физический блок, не перезаписывая исходный; (2) команда TRIM (если была включена в ОС) могла уведомить SSD, что блоки свободны, но физическая перезапись происходит не сразу. На момент изъятия (через 72 часа) команда TRIM была отключена в файловой системе (проверено через cat /etc/fstab | grep discard — параметра discard не было). Следовательно, значительная часть исходных данных могла сохраниться на NAND-чипах.

Этап 2. Получение посекторного образа и анализ NAND-отображения
С помощью программатора PC-3000 SSD (компания ACE LAB) выполнен прямой доступ к NAND-чипам микросхемы контроллера. Получен образ низкого уровня (без учёта логического отображения LBA-PBA). После декодирования таблиц переназначения (FTL — FLASH TRANSLATION LAYER) восстановлена логическая структура разделов. Всего обнаружено 1 274 логических блока, помеченных как «свободные», но содержащих данные со временем записи, предшествующим инциденту.

Этап 3. Поиск сигнатур страниц POSTGRESQL
Размер страницы POSTGRESQL — 8 КБ, сигнатура заголовка: первые 4 байта — контрольная сумма (CRC32C), затем 4 байта — число, обратное контрольной сумме, затем идентификатор страницы. С помощью скрипта на PYTHON (библиотека scapy) просканировано всё свободное пространство на предмет блоков, содержащих валидную контрольную сумму (алгоритм CRC32C, полином 0x1EDC6F41). Найдено 47 223 страницы с валидной контрольной суммой. Из них 38 104 принадлежали объектам (таблицам, индексам) удалённой базы insurance_db.

Этап 4. Восстановление системных каталогов
Удаление базы данных выполнило DROP DATABASE, но структура каталога PG_CLASS (хранит метаданные о таблицах) на физическом уровне не была перезаписана полностью. Извлечены OID (OBJECT IDENTIFIER) для таблиц policies и accidents из фрагментов PG_CLASS, найденных в освобождённых блоках. OID = 16395 для policies, OID = 16412 для accidents. Затем собраны все страницы с этими OID в поле pg_class.relfilenode.

Этап 5. Декодирование кортежей
Страницы содержали кортежи с флагами: 0x1FFF — кортеж действителен, 0x0FFF — кортеж удалён (но данные сохранены). Извлечено 12 847 действительных записей из таблицы policies (85% от ожидаемого объёма) и 2 103 записи из таблицы accidents (78%). Для недостающих записей проведён анализ мёртвых кортежей (0x0FFF) — из них извлечено ещё 1 220 записей policies (8%) и 342 записи accidents (12%). Итого восстановлено 93% и 90% соответственно.

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

Данные, удалённые командами DROP DATABASE и частично перезаписанные SHRED, поддаются восстановлению в объёме более 90% благодаря особенностям работы SSD (WEAR LEVELING, отсутствие TRIM) и сохранности системных каталогов.
Восстановленные таблицы policiesи accidents позволяют в полном объёме подтвердить наличие страховых полисов на момент ДТП. Прилагаются SQL-дампы на DVD-диске (приложение №3 к заключению).
Установить, что именно уволенный сотрудник выполнил деструктивные команды, не представилось возможным, так как SSH-сессии не логировались. Однако время выполнения команд (15.08.2023 с 14:23 по 14:27) совпадает с периодом, когда его учётная запись была активна по данным сервера аутентификации LDAP.

Судебное решение ⚖️
Арбитражный суд принял восстановленные данные как допустимое доказательство, удовлетворил иск ассоциации к страховой компании о выплате 47 млн рублей. Уголовное дело в отношении бывшего сотрудника прекращено за примирением сторон (возместил ущерб добровольно после предъявления результатов экспертизы). Руководитель ИТ-отдела уволен за ненадлежащую организацию резервного копирования.

Данный случай доказывает, что даже при использовании утилит многократной перезаписи (SHRED, DD с /dev/urandom) эксперт имеет высокие шансы на восстановление данных, если действует быстро и применяет методы низкоуровневого доступа к NAND-памяти. Компьютерная экспертиза баз данных и СУБД в таких экстремальных условиях требует привлечения специалистов по физическому восстановлению данных и глубоких знаний архитектуры SSD. 🧲🔌

Глава 7. Кейс №3: Выявление накрутки голосов в системе электронного голосования (MYSQL INNODB) 🗳️📈🤖

Обстоятельства дела: Некоммерческое партнёрство «Садоводческое некоммерческое товарищество «Берёзка»» (СНТ) проводило внеочередное общее собрание в дистанционной форме с использованием веб-платформы на PHP и базы данных MYSQL 8.0. В голосовании по вопросу избрания нового председателя правления участвовало 1 840 членов СНТ. Результаты, объявленные организационной комиссией: «ЗА» — 1 450 голосов (78,8%), «ПРОТИВ» — 390. Группа членов СНТ в количестве 320 человек оспорила результаты, заявив, что реальное соотношение было примерно 50/50. По их словам, председатель комиссии (он же кандидат на должность) имел административный доступ к базе данных и мог внести фиктивные голоса. Назначена компьютерная экспертиза баз данных и СУБД в Союзе «Федерация судебных экспертов».

Исходные данные:

Образ диска сервера (VIRTUALBOX VMDK) с установленной MYSQL 8.0.28 на UBUNTU 22.04.
Бинарные логи (BINLOG): файлы mysql-bin.000042, mysql-bin.000043, mysql-bin.000044.
Файлы таблиц INNODB: ibd, members.ibdв каталоге /var/lib/mysql/snt_db/.
Архив веб-сервера (логи NGINX и PHP-FPM) за период голосования с 01.10.2023 по 05.10.2023.

Ход исследования 🔍

Этап 1. Предварительный анализ структуры таблиц
Таблица votes имела следующую схему:

SQL

CREATE TABLE votes ( vote_id INT AUTO_INCREMENT PRIMARY KEY, member_id INT NOT NULL, vote_value ENUM(‘YES’,’NO’) NOT NULL, vote_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP, ip_address VARCHAR(45), user_agent TEXT, FOREIGN KEY (member_id) REFERENCES members(member_id)) ENGINE=InnoDB;

Общее количество записей — 1 840. Первичный ключ vote_id — автоинкремент.

Этап 2. Анализ распределения AUTO_INCREMENT
Нормальное голосование (без накрутки) характеризуется равномерным или близким к равномерному распределением ID во времени. При накрутке типичны блоки последовательных ID, внесённых одной транзакцией. Построена гистограмма: для ID с 1 по 400 — средний интервал между вставками 14 секунд; для ID с 1150 по 1250 — интервал менее 0,1 секунды (фактически одномоментно). Этот блок из 100 голосов имел vote_timestamp = 2023-10-04 19:22:17 для всех 100 записей. Вероятность того, что 100 человек проголосовали в одну и ту же миллисекунду, ничтожно мала (менее 10^-12 при равномерном распределении).

Этап 3. Анализ BINLOG в формате ROW
Выполнена команда: mysqlbinlog —verbose —base64-output=DECODE-ROWS mysql-bin.000043 > decoded_log.txt. В декодированном файле обнаружено событие с timestamp=1696432937 (что соответствует 2023-10-04 19:22:17 UTC), тип WRITE_ROWS_EVENT, table_id=98 (таблица votes), rows=100. Содержимое строк: для всех 100 записей member_id увеличивается на 1, начиная с 1151 до 1250, vote_value=’YES’, ip_address=’192.168.1.200′ — один и тот же IP для всех. Это явное доказательство массовой вставки через LOAD DATA INFILE или многострочный INSERT.

Этап 4. Анализ скрытых столбцов INNODB (DB_TRX_ID, DB_ROLL_PTR)
Для таблиц INNODB каждая строка имеет скрытые столбцы:

DB_TRX_ID(6 байт) — идентификатор транзакции, создавшей версию строки.
DB_ROLL_PTR(7 байт) — указатель на UNDO-запись (для версионности).
DB_ROW_ID(6 байт) — монотонный идентификатор строки (если нет первичного ключа).

С помощью внутреннего инструмента INNODB_PARSER прочитаны страницы таблицы votes.ibd. Для «аномального» блока ID 1150-1250 все строки имеют одинаковый DB_TRX_ID = 0x1A3F5B2 (транзакция 27 518 258). Для остальных строк (нормальных) DB_TRX_ID варьируются и соответствуют разным транзакциям. Этот факт окончательно доказывает, что 100 голосов вставлены одной транзакцией — то есть одним лицом, имевшим прямой доступ к БД.

Этап 5. Сопоставление с логами веб-сервера
Логи NGINX за 2023-10-04 с 19:21:50 по 19:22:30 показывают обращения к скрипту vote.php только с IP 192.168.1.200 (серверная сеть, административная подсеть). При этом в логах PHP-FPM отсутствуют вызовы метода vote() для членов СНТ с ID 1151-1250. Следовательно, голосование выполнялось не через веб-интерфейс, а напрямую через SQL-клиент (например, mysql из командной строки).

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

В таблице votesобнаружен блок из 100 записей (ID 1150-1250), которые были вставлены одной транзакцией 2023-10-04 19:22:17 с IP-адреса административной сети (192.168.1.200) в обход веб-интерфейса.
Эти 100 записей являются фиктивными (накруткой) и должны быть исключены из подсчёта голосов. Истинное количество голосов «ЗА» — 1 350, «ПРОТИВ» — 390 (остальные 100 — недействительны).
Установить лицо, выполнившее вставку, не представляется возможным без анализа журналов подключений MYSQL (GENERAL LOG), который на сервере был отключён. Однако IP-адрес 192.168.1.200 статически закреплён за рабочей станцией председателя комиссии (подтверждено документацией по сетевой инфраструктуре).

Судебное решение ⚖️
Суд признал заключение эксперта достаточным основанием для отмены результатов голосования. Проведено повторное очное собрание, на котором председателем избран другой кандидат. Председатель комиссии исключён из членов СНТ за фальсификацию. В возбуждении уголовного дела отказано по малозначительности (ущерб не доказан), но гражданский иск о взыскании судебных расходов удовлетворён — 230 000 рублей с председателя комиссии в пользу СНТ.

Этот кейс иллюстрирует, как компьютерная экспертиза баз данных и СУБД на основе комплексного анализа AUTO_INCREMENT, BINLOG и скрытых столбцов INNODB позволяет однозначно доказать факт накрутки даже при отсутствии прямой записи SQL-команд. 🕵️‍♂️📡

Глава 8. Методы восстановления данных при частичном или полном отсутствии журналов транзакций 🧩🔨

Далеко не всегда эксперту предоставляются полные журналы транзакций. В реальной практике недобросовестные администраторы часто удаляют LDF, WAL, REDO LOGS перед передачей диска на экспертизу либо используют команды типа ALTER DATABASE SET RECOVERY SIMPLE, после чего журнал автоматически очищается. Тем не менее, существуют методы восстановления даже в таких неблагоприятных условиях. Рассмотрим их в порядке убывания эффективности.

Метод 1. Анализ свободных страниц в файлах данных (DATA FILES) 📄

Даже после VACUUM FULL в POSTGRESQL или SHRINKDATABASE в MS SQL SERVER, часть страниц, ранее содержавших удалённые строки, может остаться нетронутой (особенно если команда сжатия не смогла переместить все строки из-за фрагментации). Эксперт должен:

Просканировать все страницы файла данных (MDF, IBD, DBF) на предмет наличия валидного заголовка.
Извлечь записи с флагом «удалено» из массива слотов.
Попытаться сопоставить эти записи со схемой таблицы, полученной из системных каталогов или путём статистического анализа (распределение типов данных, NULL-паттерны).

Метод 2. Анализ теневых копий (VOLUME SHADOW COPY) для WINDOWS 💿

Служба VSS (VOLUME SHADOW COPY SERVICE) в WINDOWS SERVER создаёт автоматические теневые копии томов (по умолчанию каждые 12 часов, если не отключено). Эксперт может:

Подключить образ диска как том в среде FORENSIC (например, через vssshadowили shadowcopyview).
Извлечь файлы базы данных из момента времени, предшествующего удалению журналов.
Эти файлы будут содержать журналы транзакций в состоянии на момент снимка.

Метод 3. Анализ своп-файлов и файлов подкачки (PAGEFILE.SYS, SWAP) 🧠

Операционная система может выгружать страницы памяти процессов СУБД в файл подкачки (на WINDOWS) или в swap-раздел (на LINUX). В этих областях часто сохраняются фрагменты данных, включая недавно изменённые строки таблиц. Поиск проводится по сигнатурам (аналогично поиску в свободном пространстве диска). Эффективность метода невысока (менее 15% восстановленных записей), но в критических случаях может дать ключевую информацию.

Метод 4. Восстановление из оперативной памяти (LIVE FORENSICS) 🚨

Если сервер ещё работает, можно выполнить дамп памяти (например, через procdump или lime), а затем проанализировать буферные страницы INNODB, кэш буфера MS SQL, общий буфер POSTGRESQL. В кэше могут находиться страницы, которые ещё не сброшены на диск, включая те, что были удалены или изменены в последние минуты. Этот метод требует высокой квалификации и должен применяться с осторожностью, чтобы не нарушить работу сервера.

Метод 5. Эвристическое восстановление на основе статистических связей 📈

Когда ни один из вышеперечисленных методов не дал результата, эксперт может применить методы машинного обучения (наивный байесовский классификатор, метод случайного леса) для предсказания удалённых значений на основе корреляций с сохранившимися столбцами. Например, если известно, что amount в таблице платежей сильно коррелирует с category_id, можно построить регрессионную модель и заполнить пропуски с доверительным интервалом. Однако такие выводы всегда должны сопровождаться оговоркой о вероятностном характере и не могут служить единственным доказательством в уголовном деле.

Важно понимать: ни один из методов не даёт 100% гарантии, и эксперт обязан честно указывать в заключении долю восстановленных данных и доверительную вероятность для каждого вывода. Именно научная честность отличает нас от шарлатанов. 🎓🧾

Глава 9. Особенности работы с СУБД NO-SQL и NEW-SQL 🗃️🌐

Хотя классические реляционные СУБД составляют основную часть объектов экспертизы, в последние годы увеличивается количество дел, связанных с документоориентированными (MONGODB, COUCHBASE), столбцовыми (CLICKHOUSE, CASSANDRA) и графовыми (NEO4J, ARANGODB) базами данных. Методология экспертизы для них имеет существенные отличия.

MONGODB (WIREDTIGER STORAGE ENGINE) 🍃

Файлы данных: collection-<OID>.wt(WIREDTIGER), журналы предзаписи: 00000xxxx.
Особенность: удалённые документы помечаются как deleted, но физически перезаписываются только при компакшне (runCommand({compact: ‘collection’})). Поэтому восстановление возможно в течение длительного времени (месяцы при низкой нагрузке).
Анализ требует собственного парсера формата WIREDTIGER (BSON-блоки с контрольными суммами). Мы используем модифицированную версию утилиты wtиз исходников MONGODB.

CLICKHOUSE 🏛️

Данные хранятся столбцово в виде частей (PART) внутри каталога store/. Каждая часть — отдельная директория с файлами столбцов (.bin), маркеров (.mrk) и первичных ключей.
Удаление данных — асинхронное, до слияния (MERGE) часть сохраняется полностью. Таким образом, можно восстановить данные, удалённые за несколько дней до слияния.
Мы разработали скрипт CH_RECOVER, который сканирует каталог detachedи store на наличие частей, помеченных как неактивные, и собирает из них полные таблицы.

CASSANDRA 🍯

Распределённая система без единого журнала. Данные хранятся в SSTABLE-файлах (SORTED STRING TABLE) в каталоге/var/lib/cassandra/data/keyspace/table.
Удаление строки — это вставка TOMBSTONE (маркера удаления), который распространяется на другие узлы. До момента компакшна (GC_GRACE_SECONDS, по умолчанию 10 дней) исходные данные сохраняются в старых SSTABLE-файлах.
Восстановление возможно путём анализа SSTABLE с помощью утилиты sstable-tools(из комплекта CASSANDRA) или собственного парсера SSTABLE (формат сложный, использует сжатие LZ4 и алгоритм Блума).

Экспертиза NO-SQL систем требует глубокой специализации и, как правило, обходится заказчику дороже (в 1,5–2 раза выше стоимости). Тем не менее, компьютерная экспертиза баз данных и СУБД распространяется и на эти системы при условии, что эксперт имеет соответствующую квалификацию и аттестацию. Союз «Федерация судебных экспертов» аккредитован по 7 различным СУБД, включая перечисленные выше. 🌟🧑‍💻

Глава 10. Обеспечение неизменности объектов исследования: CHAIN OF CUSTODY 🔗🛡️

Любая, даже самая блестящая экспертиза будет признана недопустимым доказательством, если нарушена процедура изъятия, хранения и передачи объектов. Наша лаборатория строго соблюдает следующие правила, основанные на рекомендациях SWGDE (SCIENTIFIC WORKING GROUP ON DIGITAL EVIDENCE):

Правило 1. Изъятие с использованием WRITE-BLOCKER 🚫✍️
Любой носитель (HDD, SSD, USB-FLASH, SD-КАРТА) перед подключением к компьютеру эксперта подсоединяется через аппаратный блокиратор записи (TABLET T8, FORENSICS ULTIMATE WRITE-BLOCKER). Запрещается использование программных блокираторов на уровне ОС (например, mount -o ro) для уголовных дел, так как злонамеренно скомпрометированное ядро может игнорировать эти параметры.

Правило 2. Хеширование на всех этапах 🔢
Сразу после создания образа (DD, E01, AFF) вычисляются хеши MD5, SHA-1, SHA-256, которые вносятся в протокол изъятия. При каждой передаче носителя (от следователя эксперту, от одного эксперта другому, в суд) хеши пересчитываются и сверяются с эталонными. Любое расхождение означает, что носитель мог быть изменён, и такое доказательство исключается.

Правило 3. Изоляция от сети и внешних воздействий 📡🚫
После изъятия носитель помещается в антистатический пакет и хранится в сейфе с контролем температуры/влажности. Доступ к носителю имеют только лица, внесённые в реестр цепочки хранения (CHAIN OF CUSTODY LOG). Любое подключение к сети (даже локальной) запрещено — это может привести к изменению временных меток файлов (например, через NTP).

Правило 4. Работа только с копиями, не с оригиналами 📀
Оригинал носителя после создания образа помещается в сейф и более не используется. Все исследования (парсинг, монтирование, запуск СУБД) выполняются с образа, размещённого на выделенном FORENSIC-сервере. Это гарантирует, что даже при ошибке эксперта оригинал остаётся нетронутым.

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

Принципиальная позиция: ни один запрос «проведите экспертизу удалённо, по скайпу» или «пришлите мне бэкап по электронной почте» не принимается. Это несовместимо с понятием судебной независимости. Только физическое присутствие и соблюдение CHAIN OF CUSTODY гарантируют истинность выводов. 🎯🔒

Глава 11. Подготовка заключения: структура, требования к языку, иллюстрации 📑🖍️

Заключение эксперта — это процессуальный документ, который должен быть понятен судье и сторонам, не обладающим техническими знаниями, но при этом содержать все необходимые детали для проверки. Союз «Федерация судебных экспертов» придерживается следующей структуры (согласно ст. 204 УПК РФ с дополнениями для компьютерных экспертиз):

Вводная часть📌
- Дата и место составления, номер заключения.
- ФИО эксперта, образование, стаж, аттестация.
- Основания для проведения экспертизы (постановление или определение суда).
- Предупреждение об ответственности по ст. 307 УК РФ.
- Перечень поступивших материалов (с указанием контрольных сумм).
- Вопросы, поставленные перед экспертом (дословно, как в определении).
Исследовательская часть🔬
- Описание использованного оборудования (модель WRITE-BLOCKER, компьютер, ПО) с указанием версий и контрольных сумм исполняемых файлов.
- Детальное описание процесса получения образа и верификации хешей.
- Для каждого вопроса — последовательность действий, формулы, алгоритмы, ссылки на научные источники (список литературы не нужен, но ссылки на конкретные методики допустимы).
- Иллюстрации: скриншоты HEX-дампов, графики LSN, схемы страниц, таблицы восстановленных записей. Все иллюстрации должны быть подписаны и содержать легенду.
- Указание пределов применимости и вероятностных оценок (уровни A, B, C, D).
Выводы📝
- Ответы на каждый вопрос в той же нумерации, что и в вводной части.
- Выводы должны быть краткими, однозначными, без слов «возможно», «вероятно» (кроме случаев уровня C, D с обязательной оговоркой).
- Прилагается список восстановленных файлов (на отдельном носителе) с их контрольными суммами.

Требования к языку 🗣️

Избегать неоднозначных терминов, все аббревиатуры расшифровываются при первом упоминании (например, СУБД — система управления базами данных).
Не использовать оценочные суждения («злоумышленник», «фальсификация»), только констатацию фактов («обнаружено несоответствие LSN», «вставка выполнена одной транзакцией»). Однако в описательной части (не в выводах) возможны технические характеристики типа «аномальный блок».
Объём исследовательской части должен составлять не менее 70% от общего объёма заключения. Краткие заключения (менее 10 страниц) вызывают обоснованные сомнения в полноте исследования.

Пример качественного вывода: «В журнале транзакций LDF файла database_log.ldf за период с 01.03.2024 по 05.03.2024 обнаружено 47 записей типа LOP_MODIFY_ROW, для которых отсутствуют соответствующие записи COMMIT. Эти записи относятся к таблице “Orders” (OBJECT_ID=1973054691) и содержат изменения столбца “Amount” с 1250.00 на 3750.00. Время фиксации транзакций не установлено, что свидетельствует о незавершённых (ROLLBACK) транзакциях, выполнявшихся в обход штатного механизма COMMIT».

Правильно оформленное заключение — это половина успеха в суде. Наши эксперты проходят ежегодное повышение квалификации по написанию процессуальных документов. 📜✍️

Глава 12. Отличие независимой экспертизы от государственной и ведомственной ⚖️🏛️

Заказчики часто спрашивают: «Почему мы не можем обратиться в ЭКЦ МВД или в лабораторию Минюста?» Отвечаем прямо, без дипломатии.

Государственные эксперты 👮‍♂️

✅ Высокая квалификация в классических экспертизах (почерк, дактило, автотехническая).
✅ Бесплатно для государственных органов.
❌ Острая нехватка времени на глубокий анализ (средняя нагрузка — 40+ дел в месяц на одного эксперта).
❌ Ограниченный инструментарий (только утверждённые методики, многие из которых устарели — например, работа только с MS SQL 2008/2012).
❌ Нежелание давать категорические выводы при неполноте данных (преобладают формулировки «не представилось возможным»).
❌ Возможная зависимость от ведомственных интересов (например, экспертиза по уголовному делу, где обвиняемый — бывший сотрудник того же ведомства).

Независимые эксперты (Союз «Федерация судебных экспертов») ⭐

✅ Специализация исключительно на компьютерной экспертизе баз данных (и смежных областях: файловые системы, память, сети).
✅ Использование самого современного оборудования (PC-3000 SSD, TABLEAU, собственные парсеры).
✅ Глубокое исследование (одно дело может занимать 80–120 часов экспертного времени).
✅ Независимость: эксперты не состоят в штате государственных органов, не получают премий от исхода дела, работают только на основании договора.
✅ Прозрачность: по запросу суда предоставляются исходные коды скриптов и логи работы инструментов (конфиденциальные части могут быть закрыты, но общая логика проверяема).
❌ Стоимость выше (но это плата за качество и независимость).

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

Глава 13. Риски и ограничения: когда экспертиза невозможна или малоинформативна ⚠️🚫

Научная честность требует открыто говорить о случаях, когда экспертиза не может дать ответа или даёт его с низкой достоверностью.

Ситуация 1. Полное шифрование диска без предоставления ключей 🔐
Если сервер использует BITLOCKER (WINDOWS), LUKS (LINUX) или аппаратное шифрование SSD (SED — SELF-ENCRYPTING DRIVE) и ключи утеряны или не предоставлены, то даже при наличии образа диска данные нечитаемы. Единственный шанс — поиск ключа в дампе RAM, если он был получен до выключения питания. Без RAM — экспертиза невозможна.

Ситуация 2. Использование СУБД, работающих только в памяти (IN-MEMORY) 💾
REDIS, MEMCACHED, некоторые конфигурации SQL SERVER (HEKATON) хранят данные только в оперативной памяти. При выключении сервера данные безвозвратно теряются (если не настроена периодическая запись на диск). Экспертиза возможна только при условии LIVE-FORENSICS (дамп RAM работающего сервера), что часто запрещено правилами эксплуатации.

Ситуация 3. Истечение срока хранения журналов транзакций ⏳
Если с момента инцидента прошло несколько месяцев, а СУБД работала в режиме SIMPLE RECOVERY (MS SQL) или без архивации WAL (POSTGRESQL), журналы могли быть перезаписаны многократно. Восстановить хронологию изменений за давний период в таких условиях невозможно. Эксперт может лишь констатировать факт отсутствия информации.

Ситуация 4. Физическое уничтожение носителя (дробление, сжигание, кислотное травление) 🔥
При серьёзном физическом повреждении восстановление данных становится задачей криминалистической лаборатории, а не программной экспертизы. Даже в этом случае частичное восстановление возможно (например, для флеш-памяти с использованием электронной микроскопии), но стоимость такого исследования начинается от 5 млн рублей и не гарантирует успеха. Для большинства дел это экономически нецелесообразно.

Ситуация 5. Использование профессиональных инструментов анонимизации (TOR, I2P, прокси-цепочки) 🕵️‍♂️
Если злоумышленник подключался к СУБД через цепочку анонимных прокси, определить его реальный IP-адрес по сетевым логам невозможно. Эксперт может лишь указать, что источник подключения скрыт. Это ограничение неустранимо на современном уровне техники.

В каждом заключении мы обязаны перечислить эти риски и указать, какие из них имеют место в конкретном деле. Попытки скрыть ограничения или «притянуть за уши» выводы являются нарушением экспертной этики и могут привести к исключению заключения из дела. Будьте бдительны, если другой эксперт обещает 100% результат в заведомо безнадёжной ситуации. 🧐⚠️

Глава 14. Рекомендации по взаимодействию с экспертом до и во время суда 🤝⚖️

Чтобы экспертиза прошла максимально эффективно и её результаты были использованы судом, рекомендуем следователям, адвокатам и судьям придерживаться следующих правил.

На этапе назначения экспертизы 📋

Формулируйте конкретные вопросы, избегая общих фраз («проверить базу данных», «установить факт изменений»). Используйте типовые формулировки из Главы 4.
Предоставляйте эксперту максимально полный доступ: оригинал носителя (или его криминалистическую копию), а не выгрузки через СУБД. Если выгрузка — то обязательно с контрольными суммами и фиксацией времени.
Указывайте в постановлении, какой именно период времени подлежит исследованию. Исследование всего журнала транзакций за несколько лет может быть экономически нецелесообразным.
Если дело срочное (например, требуется блокировка счетов ответчика), запрашивайте предварительное исследование (не процессуальное, но ориентирующее).

В ходе производства экспертизы 🛠️

Обеспечьте эксперту доступ к изолированному рабочему месту без выхода в интернет (чтобы исключить утечку данных).
Будьте готовы предоставить дополнительные материалы: логи ОС, схемы сети, документацию на СУБД, образцы оборудования, если они запрошены (ст. 57 УПК РФ позволяет эксперту ходатайствовать о предоставлении дополнительных материалов).
Не давите на эксперта, не просите «подогнать» выводы под нужную сторону. Это не только аморально, но и уголовно наказуемо (ст. 302 УК РФ — принуждение к даче показаний).

При подготовке к судебному заседанию 🎙️

Изучите заключение вместе с техническим специалистом (сисадмином или ИТ-юристом), чтобы понять сильные и слабые места.
Подготовьте вопросы для эксперта на перекрёстном допросе. Хорошие вопросы: «Почему вы не использовали метод X?», «Какова вероятность ошибки при восстановлении записей?», «Могли ли данные быть изменены после изъятия носителя?».
Если оппонент заявляет ходатайство о назначении повторной экспертизы, требуйте, чтобы повторный эксперт имел доступ к оригинальным образам, а не только к заключению.

В судебном заседании 🏛️

Эксперт должен демонстрировать не только заключение, но и (по запросу) исходные коды, скрипты, логи работы. Отказ от демонстрации — повод усомниться в добросовестности.
Если эксперт использует сложные термины, судья вправе потребовать объяснений на доступном языке. Хороший эксперт способен пересказать суть даже самых сложных алгоритмов на примерах из жизни.

Союз «Федерация судебных экспертов» предоставляет услуги по экспертному сопровождению в суде — наш представитель будет присутствовать на заседаниях и давать пояснения. Стоимость сопровождения — отдельно или включена в договор по договорённости. 📞👨‍⚖️

Глава 15. Заключение: ценность инженерного подхода и приглашение к сотрудничеству 🌟🤝

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

Союз «Федерация судебных экспертов» за 14 лет работы выполнил более 1 200 экспертиз, из них 350 — по базам данных. Мы восстановили данные для 47 компаний, находящихся на грани банкротства, помогли осудить десятки недобросовестных сотрудников и оправдать невиновных. Наш средний процент заключений, принятых судами без критики (то есть положенных в основу решения) — 96,3%. Это не случайность, а результат системной работы по повышению качества.

Если вы столкнулись с необходимостью судебного или досудебного исследования базы данных, не рискуйте с «дешёвыми» экспертами, которые обещают всё и сразу. Обратитесь к нам. Мы проведём предварительный анализ (до 1 часа) бесплатно, оценим шансы на успех и предложим оптимальный план действий.

Посетите наш официальный сайт, где вы найдёте:

Подробные описания всех видов экспертиз с примерами.
Реестр аттестованных экспертов с их специализациями и стажем.
Бланки заявок и договоров.
Калькулятор стоимости для типовых задач.
Отзывы клиентов (скан-копии благодарственных писем).

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

Звоните, пишите, приезжайте. Мы работаем по всей России, выезжаем на место изъятия в любой регион в течение 24 часов. Ваши данные в безопасности, ваша тайна защищена, ваши шансы на победу в суде максимальны.

Помните: цифры не лгут, лгут те, кто их интерпретирует. Дайте слово настоящим экспертам. 🧾⚖️💯