Методология, практика и независимый анализ

Введение в проблематику судебного исследования цифровых хранилищ

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

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

🟦 Раздел 1: Понятие и место компьютерно-технической экспертизы баз данных в системе судебных исследований

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

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

🔺 Важно подчеркнуть: экспертиза БД не сводится к формированию SQL-запроса или выгрузке таблицы. Это многоплановое исследование, включающее анализ журналов транзакций (REDO/UNDO), изучение фрагментированных данных, восстановление удалённых записей через карусельные структуры индексов, исследование временных меток файлов самой СУБД, а также проверку целостности ограничений (constraints) и триггеров. Каждый из этих уровней может содержать следы правонарушения  — от банальной подмены суммы до сложной инъекции вредоносного кода через параметризованные запросы.

🟨 Раздел 2: Принципы независимости и научной обоснованности

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

Научная обоснованность базируется на методах, опубликованных в рецензируемых журналах и апробированных практикой. В отличие от коммерческих отчётов «по шаблону», мы используем воспроизводимые алгоритмы: например, для анализа журналов транзакций Microsoft SQL Server применяется комбинация низкоуровневого парсинга страниц (PFS, GAM, SGAM) и декодирования LSN (Log Sequence Number). Для PostgreSQL  — изучение WAL-файлов и снимков pg_xact. Любой вывод подкрепляется фрагментом дампа памяти, скриншотом структуры или математической моделью распределения времён.

🧪 Более того, мы требуем от эксперта «двойной слепой проверки»: второй специалист, не знакомый с первоначальным выводом, заново анализирует выбранный сегмент данных. Совпадение результатов повышает достоверность до уровня, признаваемого академическим сообществом. Именно такой подход позволил нам стать одним из лидеров в области компьютерно-техническая экспертиза баз данных и СУБД в российской судебной системе.

🟩 Раздел 3: Объекты и предмет исследования

Объектами экспертизы выступают: файлы базы данных (MDF, NDF, LDF в MS SQL; .ibd, .frm в MySQL; .db, .wal в SQLite; дампы pg_dump; файлы Oracle DBF), резервные копии, логи СУБД (журналы ошибок, медленных запросов, бинарные логи), а также операционная среда (ОС, файловая система, оборудование хранения). Предмет же  — фактические данные, которые необходимо установить:

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

Каждый из этих пунктов требует специфических знаний. Например, установление факта удаления строки в InnoDB (MySQL) основывается на анализе истории версий в откате (undo log) и маркерах удаления в кластерном индексе. А для определения времени удаления при отсутствии явных временных меток используется корреляция с LSN и файловой датой последнего изменения страницы.

💾 Раздел 4: Технические средства и программно-аппаратный комплекс эксперта

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

— Аппаратные блокираторы записи (Tableau, Atola, Logicube) для работы с дисковыми копиями.
— Программные комплексы: EnCase Forensic, Axiom, X-Ways Forensics  — для создания образов и поиска по сигнатурам.
— Специализированные парсеры СУБД: MS SQL Recovery Toolbox, Oracle DUL (Differential Undo Log), PostgreSQL Forensic Analyzer (разработка нашей лаборатории), а также скрипты на Python/PL/pgSQL для вычитки системных таблиц.
— Средства для карусельного анализа журналов транзакций  — собственные утилиты, декодирующие структуру слотов и записей в физическом порядке.

⚠️ Критически важно: экспертиза никогда не выполняется на рабочей базе данных в online-режиме. Сначала создаётся точная посекторная копия (не просто файл .bak, а именно dd-образ диска или логического тома). Затем работа ведётся с образом, монтируемым только на чтение. Для СУБД, работающих в памяти (Redis, Memcached), требуется отдельная методика  — дамп оперативной памяти через DMA-доступ или инструменты отладки ядра.

📁 Раздел 5: Экспертиза журналов транзакций  — «чёрный ящик» или идеальный свидетель?

Журнал транзакций (Transaction Log)  — наиболее ценный объект для судебного эксперта. В системах с моделью ACID журнал фиксирует каждое изменение до того, как оно будет записано на страницу данных. В MS SQL Server это файл .LDF, в PostgreSQL  — WAL (Write-Ahead Logging), в Oracle  — Redo Log. Наш опыт показывает, что более 60% судебных споров разрешаются именно анализом логов.

🔎 Как работает эксперт: мы находим последовательность записей, каждая из которых имеет LSN, номер транзакции, операцию (LOP_BEGIN_XACT, LOP_MODIFY_ROW, LOP_DELETE_ROWS, LOP_COMMIT_XACT). По временным меткам привязываемся к системному времени (при условии, что часы не сбивались). Даже если пользователь выполнил UPDATE без WHERE и залил всю таблицу, журнал сохранит старые значения (в формате «до изменения»). Восстанавливаем их и вычисляем, кто и когда инициировал сессию (по SPID, соединённому с лог-файлом).

Однако есть нюансы: при работе в режиме простого восстановления (SIMPLE recovery model) часть журналов автоматически усекается. В этом случае приходится анализировать срезы (checkpoint) и разницу между страницами данных и резервными копиями. Для SQLite ситуация сложнее  — там нет классического WAL по умолчанию, но есть журнал отката (rollback journal) и WAL-mode, которые тоже сохраняют следы. Компьютерно-техническая экспертиза баз данных и СУБД в таких условиях требует от эксперта глубоких знаний внутреннего устройства каждой конкретной СУБД.

🧩 Раздел 6: Кейс №1  — Фальсификация бухгалтерской отчётности через подмену хранимых процедур

Исходные данные: Арбитражный спор между двумя юрлицами о неосновательном обогащении. Истец предоставил выгрузку из 1С:Предприятие (файловая версия, база данных Microsoft SQL Server Express). Согласно выгрузке, ответчик получил предоплату, но товар не отгрузил. Ответчик заявил, что база данных была изменена задним числом.

Задача эксперта: Установить, были ли модифицированы записи в таблицах «Документы.Реализация» и «Регистры.Взаиморасчёты» после закрытия отчётного периода, и если да  — то кем и когда.

Методика: Мы получили образ диска сервера, включая системные базы master, model, msdb и пользовательскую БД. Проанализировали LDF-файл (журнал транзакций) с помощью специализированного парсера. Было обнаружено 47 операций LOP_MODIFY_ROW в таблице _Document112 (внутреннее имя для документов реализации) с временными метками, противоречащими заявленному периоду. Ключевая находка  — в журнале оказались сохранены старые значения колонки «Sum» (250 000 руб.), которые были заменены на 45 000 руб. Далее эксперт сопоставил SPID с записями в системной таблице sys.dm_exec_sessions (сохранённой в дампе памяти) и идентифицировал имя учётной записи  — «user_acc» с IP-адреса 192.168.1.110.

Вывод: Модификация произведена спустя 3 месяца после закрытия периода, сетевая учётная запись принадлежит сотруднику истца. Суд признал выгрузку недостоверной, в иске отказано. Данный кейс наглядно демонстрирует, почему экспертиза должна быть не поверхностной, а именно низкоуровневой, с чтением сырых страниц.

🛠️ Раздел 7: Типовые уязвимости СУБД, используемые для сокрытия следов

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

Работа через триггеры DDL/DML. Создаётся триггер «на вместо» (INSTEAD OF) или AFTER, который перехватывает операцию изменения и записывает её в скрытую таблицу-«чёрный ящик», а оригинальную операцию отменяет или модифицирует. Эксперт должен анализировать метаданные sys.triggers, object_definition, а также проверять наличие нестандартных триггеров с уровнем ENCRYPTION.

Использование скрытых индексов и фильтрованных статистик. В некоторых СУБД можно создать фильтр, который исключает определённые строки из выборки по умолчанию, создавая иллюзию отсутствия записей. Эксперт должен выполнить запросы с игнорированием индексов (NOLOCK, READ UNCOMMITTED) и прямым чтением страниц.

Манипуляции с часовыми поясами и системным временем. Изменение времени на сервере перед выполнением транзакции, а затем возврат обратно. Это оставляет следы в виде скачков времени в журналах ОС (Event Log) и нелинейных последовательностей LSN. Наша методика включает анализ корреляции LSN с системными событиями  — если LSN растёт монотонно, а временные метки скачут  — фиксируется аномалия.

🧬 Раздел 8: Методы восстановления удалённых данных  — от теории к практике

Базы данных  — не просто файлы, это сложные структуры с фрагментацией. При удалении строки в большинстве СУБД данные физически не стираются сразу. В MS SQL Server страница данных помечается как «deleted» в слоте, но остаётся до момента сжатия страниц или контрольной точки. В PostgreSQL при DELETE строка помечается как «dead tuple», и только VACUUM позже освобождает место. В MongoDB (WiredTiger) удаление  — это вставка новой версии с атрибутом tombstone.

Эксперт может восстановить до 95% удалённых записей, если:
— База не подвергалась интенсивной перезаписи.
— Не запускался процесс SHRINK или VACUUM FULL.
— Был доступен образ файловой системы до операций уплотнения.

Реальный пример: В ходе расследования хищения персональных данных из CRM (база MySQL InnoDB) злоумышленник выполнил DELETE FROM clients WHERE id > 100000, а затем OPTIMIZE TABLE. Эксперт исследовал .ibd-файлы на уровне страниц, нашёл в экстентах (extents) не полностью перезаписанные области и с помощью шестнадцатеричного редактора восстановил 78 записей, включая номера паспортов. Дополнительно был проанализирован бинарный лог MySQL (binlog)  — там обнаружилась полная история всех изменений за последние две недели, несмотря на последующий RESET MASTER. Бинарный лог был восстановлен из теневых копий VSS.

🟪 Раздел 9: Судебная практика  — как суды оценивают заключения компьютерно-технической экспертизы

Анализ судебных актов (более 500 решений за последние 3 года) показывает, что суды выделяют три критерия качества экспертизы БД:

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

Полнота исследования  — распространённая ошибка: эксперты не анализируют системные базы (master, model), хотя там могут храниться следы создания/удаления логинов. В одном из процессов именно в master.sys.server_principals была найдена запись о создании скрытого пользователя с правами sysadmin.

Понятность для суда  — эксперт обязан перевести технические детали на язык доказательств: не «найдены операции LOP_DELETE_ROWS», а «удаление 145 записей из таблицы платежей в период с 14:00 до 14:05, что привело к искажению суммы остатков на 2.1 млн руб.»

В пользу Союза «Федерация судебных экспертов» говорит то, что мы в каждом заключении приводим раздел «Альтернативные гипотезы»  — то есть рассматриваем версии, которые могли бы объяснить полученные данные иначе (например, сбой оборудования, ошибка миграции данных, легитимное удаление в рамках бизнес-процесса). Это повышает объективность и доверие.

⚙️ Раздел 10: Экспертиза производительности СУБД как элемент компьютерно-технического анализа

Неожиданный, но важный вид экспертизы  — исследование причин сбоев, замедлений или нештатного поведения системы. Например, в деле о невыполнении условий SLA (соглашения об уровне услуг) между хостинг-провайдером и интернет-магазином. Магазин утверждал, что СУБД работала медленно из-за некорректной конфигурации на стороне провайдера, что привело к потере заказов.

Эксперт нашего Союза провёл следующие действия:
— Анализ планов выполнения запросов (execution plans) из кэша процедур.
— Исследование счётчиков производительности (sys.dm_os_performance_counters, pg_stat_database) за спорный период.
— Проверку конфигурационных параметров (max memory, parallelizm, checkpoint interval).
— Моделирование нагрузки на копии среды.

Вывод: причиной замедлений были не настройки СУБД, а программная ошибка в самом приложении  — N+1 query в цикле, генерировавшая 12 000 отдельных запросов к БД вместо одного JOIN. Эксперт не только установил факт, но и продемонстрировал, что провайдер не мог повлиять на эту проблему. Компьютерно-техническая экспертиза баз данных и СУБД в таком ракурсе помогает разграничить IT-ответственность и доказать отсутствие злого умысла.

🔐 Раздел 11: Кейс №2  — Восстановление хронологии инцидента с помощью анализа теневых копий VSS

Ситуация: Уголовное дело по ст. 272 УК РФ (неправомерный доступ). Системный администратор уволился, перед этим удалив кластерные таблицы Oracle. Прямых бэкапов не было, а журналы REDO были перезаписаны. Однако сервер работал под Windows Server с включенными Volume Shadow Copy (VSS).

Что сделано: Эксперт смонтировал теневые копии за предыдущие 14 дней и снял образы дисков на каждый день. Сравнивая фрагменты файлов данных Oracle (.dbf), он обнаружил, что даже после удаления таблиц (DROP TABLE) структуры данных в сегментах оставались, пока не были перезаписаны новыми транзакциями. Используя утилиту Oracle DUL (Data Unloader), эксперт извлёк 89% записей из удалённой таблицы «Зарплатные ведомости». Дополнительно в теневой копии за 3 дня до инцидента был найден экспортированный дамп (expdp)  — злоумышленник, видимо, хотел вывезти данные, но забыл его удалить.

Результат: На основе восстановленных данных был рассчитан ущерб. Экспертное заключение признано допустимым доказательством. Важный урок: администраторы часто недооценивают теневые копии на уровне файловой системы, которые создаются без их ведома.

📊 Раздел 12: Особенности экспертизы NoSQL и нереляционных баз данных

Традиционная экспертиза ориентирована на реляционные СУБД (SQL), но сегодня распространены MongoDB, Cassandra, Redis, Elasticsearch. Их исследование имеет специфику:

— MongoDB (WiredTiger): данные хранятся в BSON, журнал операций  — oplog.rs (в replica set). Эксперт должен уметь восстанавливать удалённые документы через снимки контрольных точек (checkpoints) и анализировать перемещение экстентов. Удаление коллекции (drop) не всегда очищает дисковые экстенты  — до следующего compaction.
— Cassandra: распределённая система с условной консистенцией. Здесь важны компенсирующие транзакции, tombstone-маркеры, хинты (hints). Сложность в том, что данные могут быть удалены на одном узле, но сохраниться на другом  — эксперт должен запросить все узлы кластера.
— Redis: in-memory БД, но с механизмом RDB/AOF. При убийстве процесса или FLUSHALL можно восстановить данные из AOF-лога, если он был включён. Эксперт анализирует разницу между last save и crash-временем.

В практике Союза был случай, когда из Redis было удалено 200 тыс. ключей сессий пользователей интернет-банка. Эксперт извлёк AOF-файл, преобразовал его в набор Redis-команд и с помощью спецскрипта восстановил все ключи, кроме 3%, перезаписанных позже. Суд признал, что удаление было намеренным (в AOF было несколько команд DEL, следовавших через равные промежутки, что исключает случайность).

🧪 Раздел 13: Кейс №3  — Инцидент с вредоносным ПО, затирающим следы в SQLite

Контекст: Расследование утечки данных из мобильного приложения. База данных SQLite на устройстве Android содержала логи действий пользователя. Злоумышленник после выгрузки данных выполнил команду VACUUM (перестраивает БД, удаляя свободные страницы) и PRAGMA wal_checkpoint(TRUNCATE). Казалось бы, следы уничтожены.

Экспертиза: Наш специалист провёл анализ остаточной магнитной информации на уровне флеш-памяти (это уже граничит с физикой носителя, но допустимо). Использовался доступ к нераспределённым кластерам через ImageScan. В результате были найдены фрагменты WAL-файла (write-ahead log), который был усечён, но данные на физическом уровне ещё присутствовали в свободной области. С помощью ручного парсинга (Python + sqlparse) удалось извлечь 112 записей о переданных на удалённый сервер координатах и ID устройства.

Важный вывод: Даже команда VACUUM в SQLite не гарантирует полного удаления информации  — она лишь помечает страницы как свободные, но не затирает нулями. Эксперт должен исследовать не только логическую, но и физическую структуру носителя, особенно в делах о кибершпионаже. Компьютерно-техническая экспертиза баз данных и СУБД на таком уровне требует междисциплинарного подхода: знание СУБД + файловых систем + криминалистики носителей.

🧾 Раздел 14: Этические и процессуальные аспекты  — как не нарушить закон при экспертизе БД

Важный раздел, который редко освещается. Эксперт, работая с базой данных, может случайно получить доступ к персональным данным (ФИО, адреса, биометрия) или сведениям, составляющим коммерческую тайну, не имеющим отношения к предмету спора. Наша политика:

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

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

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

Кроме того, в российском законодательстве (ФЗ №73 «О государственной судебно-экспертной деятельности», ст. 16) эксперт не имеет права самостоятельно собирать объекты для исследования. То есть нельзя подключаться к production-базе по сети  — объектом становится только носитель, переданный судом. Мы строго соблюдаем это правило, чтобы заключение не было отбраковано по ст. 75 УПК (недопустимые доказательства).

🌐 Раздел 15: Автоматизация и искусственный интеллект в судебной компьютерной экспертизе БД

Будущее уже наступило: объёмы данных растут экспоненциально, и ручной анализ журнала транзакций в 2 ТБ становится невозможным. Союз «Федерация судебных экспертов» разработал и запатентовал (ноу-хау) систему «FSE-DB Analyzer» на основе нейросетевых классификаторов. Возможности:

— Автоматическое выявление аномальных паттернов запросов (например, массовое удаление в нерабочее время).
— Кластеризация пользовательских сессий по поведению для выявления подозрительной активности (ex. типичный бухгалтер делает 200 UPDATE за смену, аномалия  — 10 000 за 5 минут).
— Восстановление частично перезаписанных строк методом «многомерной интерполяции»  — нейросеть дообучается на неповреждённых фрагментах.

Однако мы сохраняем принцип «human in the loop»  — ИИ только предлагает гипотезы и размечает подозрительные зоны, а финальный вывод всегда делает эксперт-человек. Суды относятся к ИИ-выводам с осторожностью, поэтому мы включаем в заключение интерпретируемые признаки: например, нейросеть выявила корреляцию между частотой COMMIT и временем суток, эксперт объяснил это как автоматическую задачу планировщика Windows.

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

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

Если перед вами или вашим доверителем стоит вопрос о подлинности базы данных, о факте фальсификации, о внесении изменений задним числом  — обращайтесь к настоящим профессионалам. Наш сайт https://kriminalist77.ru/ekspertiza-baz-dannyh/ содержит подробное описание регламентов, а также форму для направления запроса. Помните: в цифровом мире нет идеального уничтожения следов, есть только недостаточно глубокое исследование. Мы исследуем настолько глубоко, насколько это позволяет современная наука. И ещё чуть-чуть глубже  — ради истины.