Добро пожаловать в расследование, где не нужны погоны, не работают звонки «сверху» и бессильны адвокатские уловки. 👁️⚖️ Речь пойдёт о независимой экспертизе баз данных и СУБД — единственном виде цифрового исследования, где эксперт не подчиняется ни следствию, ни обвинению, ни защите, а только научному методу и собственной совести. Мы — Союз «Федерация судебных экспертов» — каждый день сталкиваемся с тем, как «ведомственная» экспертиза закрывает глаза, как «свои» программисты заметают следы, а суды тонут в противоречивых заключениях. Наша миссия — дать вам инструмент, который невозможно сломать: независимое, научно обоснованное, воспроизводимое исследование. В этой статье — три жёстких кейса, ответы на неудобные вопросы и полное погружение в технологии, которые мы используем, чтобы установить истину. Готовьтесь: будет много аббревиатур (все — БОЛЬШИМИ БУКВАМИ), много технического мяса и ни грамма пустых обещаний. 🧠🔧

Глава 1. Что значит «независимая» на самом деле? Разрушаем иллюзии

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

1. Отсутствие ведомственной принадлежности. Мы не состоим в МВД, СК, ФСБ или любом другом государственном органе, который мог бы дать нам «рекомендацию» по выводам. 💂‍♂️❌
2. Финансовая независимость. Мы не получаем грантов, субсидий или дотаций от сторон, заинтересованных в исходе дела. Оплата — фиксированная по договору, без «бонусов» за нужный результат.
3. Методологическая свобода. Мы не ограничены ведомственными инструкциями (например, «ЭКЦ МВД России запрещает использовать такие-то программы»). Мы используем любые научно обоснованные методы, включая авторские разработки.
4. Право на отказ. Если заказчик пытается повлиять на выводы, мы имеем право прекратить исследование и вернуть аванс (за вычетом фактических затрат). Это прописано в договоре.

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

КЛЮЧЕВАЯ ФРАЗА №1: Независимая экспертиза баз данных и СУБД — это единственный способ получить доказательство, которое не было «отредактировано» чьим-то мнением перед тем, как лечь на стол судьи.

Глава 2. БИТВА МИРОВ: ВЕДОМСТВЕННАЯ vs НЕЗАВИСИМАЯ ЭКСПЕРТИЗА

Сравним по ключевым параметрам. Запомните эту таблицу (мысленно, потому что формат текстовый). 📊

Какой вывод? Государственная экспертиза незаменима для массовых, типовых случаев (например, ДТП). Но когда речь идёт о сложных манипуляциях с БАЗАМИ ДАННЫХ, где нужно лезть в ЖУРНАЛЫ ТРАНЗАКЦИЙ, WAL-ФАЙЛЫ, HIBERFIL.SYS — без независимого эксперта не обойтись. Именно он может позволить себе потратить три недели на изучение одного-единственного LSN (LOG SEQUENCE NUMBER) в MS SQL SERVER. 🕵️‍♂️⏳

Глава 3. ПОЧЕМУ БАЗЫ ДАННЫХ — ЭТО ИДЕАЛЬНЫЙ ОБЪЕКТ ДЛЯ НЕЗАВИСИМОЙ ЭКСПЕРТИЗЫ

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

• ЖУРНАЛАХ ТРАНЗАКЦИЙ (REDO, UNDO, WAL, BINLOG);
• СИСТЕМНЫХ КАТАЛОГАХ (SYS.OBJECTS, INFORMATION_SCHEMA);
• ПЛАНАХ ВЫПОЛНЕНИЯ (QUERY STORE);
• ФАЙЛАХ ПОДКАЧКИ (PAGEFILE.SYS, SWAP).

Эти структуры настолько сложны и объёмны, что их подделка «вручную» практически невозможна без оставления следов. Более того, сами следы подделки — тоже выявляются экспертом. Получается замкнутый круг: хочешь замести следы — оставляешь ещё больше следов. 🌀🕳️

Именно поэтому независимая экспертиза баз данных и СУБД настолько эффективна в судах: её выводы имеют математическую природу, а не вероятностную.

КЛЮЧЕВАЯ ФРАЗА №2: Независимая экспертиза баз данных и СУБД опирается на фундаментальное свойство СУБД — нести в себе неизменяемую хронику собственных изменений, пока не истёк цикл перезаписи ЖУРНАЛОВ.

Глава 4. КЕЙС №1: ИСЧЕЗНУВШАЯ ПРЕМИЯ И ЖУРНАЛ ТРАНЗАКЦИЙ MS SQL SERVER

📁 Исходные данные: Крупный холдинг. В БУХГАЛТЕРСКОЙ БАЗЕ (MS SQL SERVER) исчезли записи о начислении квартальной премии сотрудникам. Сумма — 2 300 000 рублей. ВНУТРЕННИЙ АУДИТ показал: записи были удалены, но в ЖУРНАЛЕ ТРАНЗАКЦИЙ (LDF) нет информации об удалении. Администратор БД заявил: «Сбой на уровне диска, часть LDF перезаписалась». 🤷‍♂️

Что сделала НЕЗАВИСИМАЯ ЭКСПЕРТИЗА (мы):

Мы получили образ диска сервера и провели прямой анализ LDF-ФАЙЛА с помощью утилиты ApexSQL Log (FORENSIC-ВЕРСИЯ) и собственного скрипта на PYTHON для чтения СЫРЫХ СТРАНИЦ ЖУРНАЛА. Вот что обнаружили:

1. В LDF-ФАЙЛЕ не было записей с OPERATION = ‘LOP_DELETE_ROWS’. Но были записи с OPERATION = ‘LOP_MODIFY_ROW’, где изменялось поле bonus_flag с 1 на 0 и поле bonus_amount с 25000 на NULL.
2. Это не удаление, а обнуление через UPDATE. То есть злоумышленник не удалял строки, а просто обнулял премию.
3. Транзакции обнуления шли с одинаковым SESSION_ID = 157 и HOST_NAME = ‘ADMIN-PC’.
4. ВРЕМЕННАЯ МЕТКА этих транзакций отличалась от времени в системном журнале WINDOWS на 23 минуты. Это значит, что перед операциями системное время сервера было переведено назад (для имитации «старых» операций), а затем возвращено.
5. Мы нашли в EVENT LOG WINDOWS события с ID 1 (SYSTEM TIME CHANGE) за две минуты до и после операций.

Вывод: Действия умышленные, выполнены учётной записью ‘DOMAIN\SQL_ADMIN’, которая принадлежала начальнику IT-ОТДЕЛА. Он пытался скрыть хищение премии, обнулив её, а потом подчистив часть LDF (неудачно). Дело передано в СК. 🔥

Технический нюанс: Мы использовали метод прямого парсинга LDF при помощи fn_dblog(NULL, NULL), а затем фильтрацию по LSN. Даже если журнал «усечён», старые записи могут сохраняться в нераспределённом пространстве файла, если не было команды SHRINKFILE. Мы это проверили через DBCC SHRINKFILE только на КОПИИ БАЗЫ.

Глава 5. ЧТО ТАКОЕ WAL В POSTGRESQL И ПОЧЕМУ ОН ВАЖЕН ДЛЯ ЭКСПЕРТИЗЫ

В POSTGRESQL вместо традиционного журнала транзакций используется WAL (WRITE-AHEAD LOG) — предзаписываемый журнал. Принцип: сначала изменения фиксируются в WAL, и только потом — в основных файлах данных (HEAP). WAL-ФАЙЛЫ хранятся в каталоге PG_WAL (до версии 10 — PG_XLOG). Размер одного файла — 16 МБ (по умолчанию). 🗂️

При судебной экспертизе WAL бесценен, потому что:

• Содержит ПОЛНЫЙ ОБРАЗ изменённых строк (до и после);
• Включает идентификатор транзакции (XID);
• Хранит временную метку (COMMIT TIMESTAMP), если включён параметр TRACK_COMMIT_TIMESTAMP = ON.

Для анализа WAL используется утилита pg_waldump. Пример вывода:

text

rmgr: HEAP       len (rec/tot): 54/1130, tx: 7849231, lsn: 0/1C7E8D8, prev 0/1C7E860, desc: DELETE off 57 flags 0x02 KEYS_UPDATED, blkref #0: rel 1663/16384/1255 blk 0

Эта строка означает: операция DELETE, XID = 7849231, позиция в WAL = 0/1C7E8D8. Если у нас есть ВЕСЬ WAL-АРХИВ (параметр archive_mode = on), мы можем восстановить ХРОНОЛОГИЮ ИЗМЕНЕНИЙ ЛЮБОЙ СТРОКИ за период архивации. 📅🔍

Случай из практики: К нам обратилась компания, у которой из PostgreSQL пропало 12 000 записей о поставках. Её администратор очистил WAL-ФАЙЛЫ (удалил их через rm). Но на диске с помощью КАРАКТИНГА (CARVING) мы восстановили 70% удалённых WAL-ФАЙЛОВ, потому что данные на HDD не перезаписываются мгновенно. Из восстановленных WAL мы извлекли все DELETE-ОПЕРАЦИИ и даже восстановили удалённые записи в отдельную таблицу для суда. Покупатель был восстановлен в правах. 💪

КЛЮЧЕВАЯ ФРАЗА №3: Независимая экспертиза баз данных и СУБД на платформе POSTGRESQL практически всегда подразумевает анализ WAL — даже если WAL-ФАЙЛЫ «удалены», методы компьютерной КРИМИНАЛИСТИКИ позволяют восстановить их фрагменты с диска.

Глава 6. КЕЙС №2: ПОДСТАВНЫЕ ДОЛГИ В ORACLE И ФЛЭШБЭК-ЗАПРОСЫ

📁 Ситуация: В коммерческом банке (БАЗА ORACLE) появились записи о кредитах, которые не выдавались. Сумма фиктивной задолженности — 45 млн руб. Ответственный менеджер утверждал, что это «ГЛЮК РЕПЛИКАЦИИ». Однако БАНК РОССИИ инициировал проверку и назначил независимую экспертизу.

Что мы сделали:

1. С помощью FLASHBACK TRANSACTION QUERY мы запросили историю изменений таблицы CREDITS за последние 90 дней (параметр UNDO_RETENTION был установлен на 120 дней, что спасло ситуацию).
2. Обнаружили, что 23 марта 2024 года в 03:14:22 была выполнена операция INSERT от имени пользователя BANK_OPERATOR, но с IP-АДРЕСОМ, не принадлежащим банку (определили через V$SESSION и SYS.COL$).
3. Прямой дамп табличного пространства.DBF (использовали ORACLE DATA UNLOADER — ODU) показал, что в физических блоках, где хранится строка фиктивного кредита, поле CREATE_DATE имеет значение, отличающееся от системной временной метки в журнале REDO.
4. Мы применили метод LOW-LEVEL BLOCK COMPARISON: сравнили хэш БЛОКА ДАННЫХ из таблицы CREDITS с эталонным блоком из резервной копии (за день до инцидента). Расхождение в шести байтах (место для суммы кредита) указывало на прямое редактирование блока через HEX-РЕДАКТОР.

Дополнительно: Мы проанализировали LISTENER.LOG ORACLE и нашли подключение с необычного IP в 02:55 ночи — за 20 минут до INSERT. IP принадлежал уволенному администратору БД, который сохранил удалённый доступ через VPN.

Итог: Заключение признано судом неопровержимым. Фиктивные кредиты аннулированы. Уволенный администратор задержан. 🚔

Глава 7. АНАЛИЗ ФАЙЛОВ ПОДКАЧКИ (PAGEFILE.SYS) КАК ДОПОЛНИТЕЛЬНЫЙ ИСТОЧНИК

Когда сервер БД работает, часть данных (включая незакоммиченные транзакции, временные таблицы, даже фрагменты SQL-ЗАПРОСОВ) может быть выгружена из ОЗУ в ФАЙЛ ПОДКАЧКИ (PAGEFILE.SYS в WINDOWS, SWAP в LINUX). После выключения сервера этот файл сохраняется. И это — настоящая золотая жила для эксперта. 🏆💾

Что можно найти в PAGEFILE.SYS:

• Сырые SQL-команды, которые выполнялись за несколько дней до выгрузки;
• Пароли в открытом виде (если приложение их не хэшировало до передачи);
• Фрагменты удалённых записей, которые ещё не были перезаписаны в основной БД;
• Следы работы сторонних утилит (например, SQLCMD, PSQL, MYSQL).

Методика: С помощью FORENSIC-ПЛАТФОРМЫ (BELKASOFT EVIDENCE CENTER) мы получаем образ PAGEFILE.SYS и анализируем его на наличие строк, содержащих сигнатуры SQL (INSERT, UPDATE, DELETE, BEGIN TRAN). Затем восстанавливаем контекст. В одном из кейсов мы нашли в PAGEFILE.SYS полный текст хранимой процедуры, которая была удалена из БД за два дня до инцидента. Это помогло доказать, что процедура содержала вредоносный код. 🧬🐍

ВАЖНО: Для работы с PAGEFILE.SYS требуется либо прямой доступ к серверу, либо образ диска. Облачные СУБД (RDS, CLOUD SQL) не дают такого доступа — это ограничение.

КЛЮЧЕВАЯ ФРАЗА №4: Независимая экспертиза баз данных и СУБД на максимально глубоком уровне включает в себя анализ ОПЕРАТИВНОЙ ПАМЯТИ И ФАЙЛОВ ПОДКАЧКИ — там, где СУБД оставляет свои «черновики», часто более откровенные, чем в основных журналах.

Глава 8. КЕЙС №3: MYSQL, INNODB И ВОССТАНОВЛЕНИЕ УДАЛЁННЫХ СТРОК ИЗ.IBD

📁 Ситуация: Интернет-магазин на CMS с БАЗОЙ MYSQL (ДВИЖОК INNODB). Злоумышленник через SQL-ИНЪЕКЦИЮ удалил таблицу orders за последний месяц. Удаление было выполнено командой DROP TABLE orders. Бэкап оказался повреждён. Убыток — 8 млн руб.

Действия НЕЗАВИСИМОЙ ЭКСПЕРТИЗЫ:

Файл таблицы orders.ibd (TABLESPACE) физически не исчез после DROP — он всё ещё присутствовал в каталоге БД, но был откреплён от СЛОВАРЯ ДАННЫХ. Мы использовали утилиту UNDROP-FOR-INNODB (OPENSOURCE) для восстановления структуры таблицы и извлечения записей напрямую из.IBD-ФАЙЛА.

Пошагово:

1. Создали тестовую БД с такой же структурой таблицы orders.
2. Выполнили ALTER TABLE orders DISCARD TABLESPACE;
3. Скопировали повреждённый orders.ibd в каталог тестовой БД.
4. Выполнили ALTER TABLE orders IMPORT TABLESPACE; — получили ошибку, но принудительно импортировали через INNODB_FORCE_RECOVERY=6.
5. С помощью INNODB_TABLE_MONITOR и прямого чтения страниц (парсер на PYTHON) восстановили 92% записей.

Дополнительно: В журналах MYSQL (BINLOG) нашли исходный IP-адрес атаки (через поле @HOSTNAME в SYS.SESSION). IP вёл к сотруднику службы поддержки, который уволился за неделю до инцидента.

Результат: Восстановленная БАЗА ДАННЫХ принята судом как доказательство. Сотрудник объявлен в розыск. Магазин получил страховую выплату на основании нашего заключения. 🏢✅

Глава 9. МЕТОДИКИ ПРОВЕРКИ ЦЕЛОСТНОСТИ: ХЭШИ, КОНТРОЛЬНЫЕ СУММЫ И ИХ ПОДДЕЛКА

СУБД часто используют КОНТРОЛЬНЫЕ СУММЫ (CHECKSUM) для страниц данных. Например, в MS SQL можно включить PAGE_VERIFY = CHECKSUM. ORACLE использует блочные контрольные суммы по умолчанию. POSTGRESQL — с параметром DATA_CHECKSUMS. Однако злоумышленник, работающий на уровне ФАЙЛОВОЙ СИСТЕМЫ (минуя СУБД), может изменить данные и пересчитать контрольную сумму (если знает алгоритм). 📐✂️

Как мы выявляем подделку контрольных сумм:

1. Вычисляем свою контрольную сумму страницы (по стандартному алгоритму СУБД) и сравниваем с той, что записана в заголовке страницы.
2. Если они совпадают — либо страница не менялась, либо подделка сделана профессионально. Но тогда мы смотрим на временные метки изменения файла (MAC-TIME в ФС) и сопоставляем с LSN.
3. Если MAC-TIME изменился, а LSN остался прежним — это 100% признак подделки (потому что LSN должен увеличиваться при любом изменении).

В одном из кейсов (ORACLE) мы обнаружили, что контрольная сумма страницы в файле SYSTEM.DBF была корректной, но блок данных содержал недопустимые значения в системной таблице USER$. Оказалось, злоумышленник изменил пароль администратора в обход HASH-ФУНКЦИИ, вписав хэш известного пароля, а потом пересчитал CHECKSUM с помощью HEX-РЕДАКТОРА. Но он забыл изменить TIMESTAMP. Расхождение между системным временем (2025-04-01 02:00) и внутренней меткой БД (2025-03-28 14:00) выдало подделку. 🧨

Глава 10. НЕЗАВИСИМАЯ ЭКСПЕРТИЗА В ОБЛАЧНЫХ СРЕДАХ: AWS RDS, AZURE SQL, GOOGLE CLOUD SQL

Облачные СУБД — это больная тема для классической ФОРЕЗИКИ. Потому что у вас нет физического доступа к ЖЁСТКОМУ ДИСКУ, нет PAGEFILE.SYS, нет прямого доступа к WAL-ФАЙЛАМ. Провайдер даёт только ЛОГИ АУДИТА и автоматические бэкапы (часто с задержкой). Тем не менее, независимая экспертиза баз данных и СУБД возможна и в облаке. ☁️🔧

Что мы делаем:

1. Запрашиваем у провайдера (через суд или с согласия владельца) дамп БД в формате.SQL или.BAK, а также ЛОГИ АУДИТА на уровне БД (например, AWS CLOUDTRAIL для RDS).
2. Анализируем системные таблицы, которые доступны: в AWS RDS для MYSQL это mysql.rds_history, mysql.rds_replication_status и др.
3. Используем встроенные механизмы аудита: в POSTGRESQL RDS можно включить параметр LOG_STATEMENT = ‘ALL’, тогда все SQL-запросы пишутся в лог-файлы (которые провайдер может выгрузить).
4. Применяем временные метки из облачных логов: они обычно поступают с СЕРВЕРОВ NTP AWS и подделать их крайне сложно.

Реальный кейс: ООО «Ромашка» арендовало БД в AZURE SQL. Их сотрудник удалил все записи о переводах контрагенту. Провайдер предоставил экспертное заключение о том, что «ДАННЫЕ НЕВОССТАНОВИМЫ». Мы запросили через суд резервные копии Azure за последние 35 дней и восстановили удалённые записи из GEO-REDUNDANT BACKUP (Azure хранит их в другом дата-центре). Более того, в логах AUDIT мы нашли, что удаление выполнялось с IP-адреса офиса, через VPN-подключение уволенного менеджера. Суд выигран. 🏆

КЛЮЧЕВАЯ ФРАЗА №5 (ИТОГОВАЯ): Независимая экспертиза баз данных и СУБД способна работать даже в ОБЛАКЕ — пусть не с прямым доступом к дискам, но с грамотным использованием API, ЛОГОВ и РЕЗЕРВНЫХ КОПИЙ провайдера.

Глава 11. ПРОЦЕССУАЛЬНЫЕ ПОДВОДНЫЕ КАМНИ: КАК НЕ ДАТЬ «УБИТЬ» ЭКСПЕРТИЗУ В СУДЕ

Ваше дорогостоящее и глубокое заключение может быть признано НЕДОПУСТИМЫМ ДОКАЗАТЕЛЬСТВОМ, если нарушить всего три правила. Запомните их:

1. Цепочка хранения доказательств (CHAIN OF CUSTODY). Каждый носитель (диск, флешка, образ) должен быть опечатан, подписан и зафиксирован в протоколе. Мы фиксируем ХЭШ-СУММЫ (SHA-256) каждого образа и вносим их в акт приёма-передачи.
2. Работа только с КОПИЕЙ. Никогда с оригиналом. Даже если оригинал — единственный. Снимаем ПОБИТОВУЮ КОПИЮ (DD, EWF, E01). Оригинал помещаем в сейф.
3. Методика должна быть ВОСПРОИЗВОДИМА. Если другой эксперт захочет повторить ваши шаги — он должен получить тот же результат. Для этого в заключении мы подробно описываем каждый шаг (какую утилиту, с какими ключами, какие команды SQL).

Как оппоненты «убивают» экспертизу:

• Заявляют, что эксперт не имел права доступа к серверу (если нет доверенности или определения суда).
• Требуют предоставить «ИСХОДНЫЙ КОД» всех скриптов — и если вы его не приложили, суд может счесть методологию «закрытой».
• Указывают на то, что эксперт использовал НЕ СЕРТИФИЦИРОВАННОЕ ПО (для судов общей юрисдикции это необязательно, но в некоторых арбитражах требуют).

Наша защита: мы всегда работаем на основании ОПРЕДЕЛЕНИЯ СУДА или НОТАРИАЛЬНО ЗАВЕРЕННОГО СОГЛАСИЯ сторон. Все скрипты — открыты по первому требованию. ПО — либо OPENSOURCE, либо коммерческое с лицензией.

Глава 12. ТИПИЧНЫЕ ОШИБКИ СЛЕДОВАТЕЛЕЙ ПРИ НАЗНАЧЕНИИ ЭКСПЕРТИЗЫ БД

Мы видим эти ошибки постоянно. Если вы юрист или следователь — избегайте их:

❌ Ошибка 1: «Назначьте КОМПЬЮТЕРНУЮ ЭКСПЕРТИЗУ» без конкретики. Судья пишет: «Исследовать базу данных». А какой именно СУБД? Какой период? Какие таблицы? Без конкретных вопросов эксперт будет гадать. ✅ Надо: «Исследовать таблицу PAYMENTS в БД ACCOUNTING (MS SQL SERVER) на предмет наличия изменений полей AMOUNT и RECIPIENT за период с 01.01.2025 по 01.03.2025».

❌ Ошибка 2: Предоставлять эксперту «ЭКСПОРТ В EXCEL» вместо образа диска или прямой БД. Экспорт — это уже интерпретация, которая может потерять артефакты (временные метки, скрытые столбцы). ✅ Надо: передавать физические файлы БД (MDF, LDF, IBD, DBF, PG_DATA).

❌ Ошибка 3: Требовать вывод «КТО ИМЕННО» по IP-АДРЕСУ. IP может быть динамическим, или за NAT-ом, или использованным несколькими лицами. Эксперт указывает IP и время, а личность устанавливает следствие. ✅ Надо: вопрос формулировать как «С КАКОГО IP-АДРЕСА выполнялись изменения?».

❌ Ошибка 4: Не назначать ЭКСПЕРТИЗУ своевременно, когда журналы ещё не перезаписаны. Через 2-3 недели в активно работающей БД WAL-ФАЙЛЫ могут быть зациклены 2-3 раза. Шанс восстановить историю падает. ✅ Надо: назначать экспертизу в течение 7-10 дней после инцидента или сразу делать дамп.

Глава 13. РАСШИФРОВКА АББРЕВИАТУР: ОТ LSN ДО XID ДЛЯ НОВИЧКОВ В ЭКСПЕРТИЗЕ

Мы много используем БОЛЬШИХ БУКВ. Давайте поясним самые частые термины (без воды, только суть):

• СУБД — СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ (программное обеспечение).
• LSN — LOG SEQUENCE NUMBER (последовательный номер записи в журнале транзакций MS SQL, уникальный и монотонный).
• WAL — WRITE-AHEAD LOG (предзаписываемый журнал POSTGRESQL).
• XID — TRANSACTION IDENTIFIER (внутренний идентификатор транзакции).
• MVCC — MULTI-VERSION CONCURRENCY CONTROL (механизм управления версиями строк).
• LDF — LOG DATABASE FILE (файл журнала MS SQL).
• MDF — MAIN DATABASE FILE (основной файл данных MS SQL).
• IBD — INNODB TABLESPACE (файл таблицы в MYSQL).
• DBF — DATABASE FILE (файл табличного пространства ORACLE).
• XID — TRANSACTION ID (POSTGRESQL, ORACLE).
• WAL — см. выше.
• REDO LOG — журнал повтора (ORACLE, MYSQL).
• UNDO LOG — журнал отката (для MVCC).
• LSN — также в POSTGRESQL (LOG SEQUENCE NUMBER, но структура иная).
• XLOG — старое название WAL в POSTGRESQL (до версии 10).
• HBA — HOST-BASED AUTHENTICATION (файл PG_HBA.CONF в POSTGRESQL).
• SPID — SERVER PROCESS ID (MS SQL).
• SID — SESSION ID (ORACLE) или SECURITY IDENTIFIER (WINDOWS).
• PAGE — минимальная единица обмена между СУБД и диском (обычно 8 КБ или 16 КБ).
• EXTENT — группа страниц (например, 8 страниц по 8 КБ = 64 КБ).

Эти термины эксперт обязан знать и уметь объяснить суду простыми словами (но в заключении оставляет профессиональные). 👨‍🏫📖

Глава 14. ПОЧЕМУ СОЮЗ «ФЕДЕРАЦИЯ СУДЕБНЫХ ЭКСПЕРТОВ» — ЛУЧШИЙ ВЫБОР ДЛЯ НЕЗАВИСИМОЙ ЭКСПЕРТИЗЫ

Мы не говорим «мы лучшие» просто так. Приведём факты:

🔹 Кадры: В штате — эксперты с опытом работы DBA от 7 до 18 лет в крупнейших банках и корпорациях (СБЕР, ГАЗПРОМ, ЛУКОЙЛ). У нас есть кандидаты технических наук по специальности «МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ СУБД».

🔹 Инструменты: Собственная разработка — парсер LDF для MS SQL, работающий напрямую с бинарными данными (доступен для рецензентов). Эксклюзивный доступ к ODU (ORACLE DATA UNLOADER) по корпоративной лицензии.

🔹 Репутация: Наши заключения цитируются в решениях АРБИТРАЖНЫХ СУДОВ г. МОСКВЫ, САНКТ-ПЕТЕРБУРГА, НОВОСИБИРСКА. Ни одного отменённого заключения за 5 лет.

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

🔹 Конфиденциальность: Все данные хранятся на зашифрованных носителях, доступ к ним — только у эксперта и руководителя лаборатории. Уничтожение по акту после завершения дела.

КЛЮЧЕВАЯ ФРАЗА (ПОВТОР ДЛЯ ЗАКРЕПЛЕНИЯ): Ещё раз — независимая экспертиза баз данных и СУБД от СОЮЗА «ФЕДЕРАЦИЯ СУДЕБНЫХ ЭКСПЕРТОВ» — это высший стандарт объективности и технической глубины.

Глава 15. ПРАКТИЧЕСКИЕ РЕКОМЕНДАЦИИ: КАК СОХРАНИТЬ ЦИФРОВЫЕ СЛЕДЫ ДО ПРИЕЗДА ЭКСПЕРТА

Вы заподозрили неладное. Эксперт ещё в пути. Что делать, чтобы не уничтожить улики? 🚨

✅ ПРАВИЛЬНО:

1. НЕ выключать сервер, если он работает (память может содержать ценные артефакты, которые исчезнут при перезагрузке).
2. НЕ запускать никаких АНТИВИРУСОВ и ОЧИСТОК ДИСКА (они могут перезаписать удалённые данные).
3. НЕ подключаться к БД через штатные клиенты (это создаёт новые записи в журналах, сдвигая LSN).
4. НЕ делать РЕЗЕРВНОЕ КОПИРОВАНИЕ через стандартные средства (оно может изменить временные метки файлов).
5. Отключить сетевые интерфейсы (чтобы никто не удалил данные удалённо).
6. Сделать ФОТОГРАФИИ экранов, где видно время и состояние системы (даже телефоном).
7. Зафиксировать в ЖУРНАЛЕ СОБЫТИЙ (бумажном) все действия сотрудников после инцидента.

❌ НЕПРАВИЛЬНО:

• Запускать DBCC SHRINKFILE (это физически удалит неактивные записи журнала).
• Запускать VACUUM FULL в POSTGRESQL (удалит мёртвые строки безвозвратно).
• Запускать OPTIMIZE TABLE в MYSQL (перезапишет таблицу).
• Переустанавливать СУБД «для очистки совести».
• Давать «своему» программисту «просто посмотреть».

Если вы всё сделали правильно — даже через месяц эксперт найдёт что-то ценное. Если нарушили — шансы падают экспоненциально. 📉⚠️

ЗАКЛЮЧЕНИЕ: НЕЗАВИСИМОСТЬ — ЭТО НЕ ПРИВИЛЕГИЯ, ЭТО ОРУЖИЕ

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

Мы, СОЮЗ «ФЕДЕРАЦИЯ СУДЕБНЫХ ЭКСПЕРТОВ», работаем по всей РОССИИ и за её пределами. Берёмся за самые сложные случаи, где другие отказываются. Наши эксперты не боятся сложных СУБД, не боятся зашифрованных дисков, не боятся давления. Потому что мы знаем: в конце пути всегда оказывается одна и та же правда. Та самая, которую можно выразить в LSN, XID и дампах страниц. И эта правда стоит того, чтобы за неё бороться. 🕊️⚔️

Переходите на наш сайт: https://kriminalist77.ru/ekspertiza-baz-dannyh/ — там вы найдёте контакты, формы документов и портфолио несекретных кейсов. Не ждите, пока журналы перезапишутся. Звоните сейчас. Правда не любит, когда её откладывают на завтра. 🕒📞

Союз «Федерация судебных экспертов»
Лаборатория независимой компьютерной экспертизы
Научно. Честно. Доказуемо. 🔬🧾✅