Введение: байты не врут, врут люди

Привет, коллега. Ты  — разработчик, сисадмин, девопс или просто человек, который однажды открыл лог своей базы данных и увидел там то, чего быть не должно. Знакомо? Сервер живет своей жизнью, транзакции выполняются сами собой, а временные метки скачут как курс биткоина. И вот ты уже не спишь ночами, потому что кто-то (или что-то) натворил дел в твоей драгоценной БД. Добро пожаловать в суровый мир судебной компьютерной экспертизы. Союз «Федерация судебных экспертов» приглашает тебя в увлекательное путешествие по закоулкам WAL, BINLOG, LSN и MVCC. Мы покажем, как компьютерная экспертиза баз данных и СУБД превращает разрозненные байты в неопровержимые доказательства. И да, будет три реальных кейса, много кода (ну, почти) и ни капли воды. Погнали.

Глава 1. Что такое судебная экспертиза БД с точки зрения айтишника

Если ты привык, что экспертиза  — это когда приходит дядька в очках и говорит «всё плохо», то ты сильно ошибаешься. Судебная компьютерная экспертиза баз данных  — это, по сути, форензика (computer forensics) применительно к СУБД. Мы не просто смотрим, что написано в таблицах. Мы лезем в самые низы: читаем сырые страницы диска, парсим журналы упреждающей записи, восстанавливаем удаленные кортежи из free space map. Компьютерная экспертиза баз данных и СУБД  — это когда ты берешь hex-редактор, открываешь файл .ibd или .mdf и руками ищешь сигнатуры удаленных записей. Романтика, мат и много кофе. И да, мы используем только легальные методы с соблюдением chain of custody.

Глава 2. Почему твой стандартный мониторинг не годится для суда

Ты привык к Zabbix, Prometheus, pgAdmin? Отлично. Но судье плевать на графики утилизации CPU. Ему нужны доказательства. Твой корпоративный аудит не хранит историю каждой строки. А WAL  — хранит. Твой обычный бекап (например, pg_dump) теряет служебную информацию  — LSN, XID, временные метки коммитов. А мы работаем только с физическими копиями файлов данных. Компьютерная экспертиза баз данных и СУБД начинается там, где заканчиваются твои стандартные инструменты. Мы используем dd для создания образа диска, pg_waldump для чтения WAL, hexdump для ручного анализа страниц. И никаких mysqldump, извините.

Глава 3. Архитектура СУБД как источник улик (ликбез для джунов)

Давай быстро пробежимся по внутренностям популярных СУБД, чтобы ты понимал, где мы копаем.
🔹 PostgreSQL: Всё вертится вокруг WAL (Write-Ahead Log). Это журнал, куда пишутся все изменения ДО того, как они попадут на основные страницы данных. WAL-сегменты  — файлы по 16 МБ. Внутри  — записи с LSN (Log Sequence Number), XID (Transaction ID), временной меткой. Плюс MVCC (Multi-Version Concurrency Control)  — старые версии строк не удаляются сразу, они живут в тех же таблицах, пока не придет VACUUM.
🔹 MySQL (InnoDB): Есть redo log (аналог WAL), undo log (для отката) и binlog  — бинарный журнал, который может работать в формате ROW (хранит образы строк «до» и «после»). Это золотое дно для эксперта.
🔹 MS SQL SERVER: Transaction Log (.ldf) и данные в .mdf. Внутри  — LSN, операции, старые значения. Можно читать недокументированной командой DBCC PAGE.
🔹 Oracle: Redo log и archive log. Flashback Query позволяет посмотреть состояние БД на любой момент в прошлом (если не отключено).
Зная это, ты понимаешь: компьютерная экспертиза баз данных и СУБД  — это не магия, а знание архитектуры.

Глава 4. Кейс №1: PostgreSQL, 1С и бухгалтер-фокусник на 47 млн рублей

📌 Вводные: В холдинге «Рога и Копыта» (название изменено) обнаружили, что из кассы исчезли 47 миллионов. Бухгалтер Елена Петровна (опыт 20 лет, кстати) клялась, что «программа глючит» и «сама все удалила». Директор, мужик прожженный, не поверил и заказал у нас компьютерная экспертиза баз данных и СУБД.
🛠️ Что мы сделали: Получили образ RAID-10 сервера с 1С (PostgreSQL 14.5). Смонтировали его только на чтение, без запуска СУБД. Скопировали каталог /var/lib/postgresql/14/main/pg_wal  — там лежало 287 сегментов. Запустили pg_waldump -p /mnt/forensic/pg_wal -r 0000000100000021000000A7. В сегменте №A7 нашли транзакцию XID 9128045. Команда: DELETE FROM «public».»ПлатежныеПоручения» WHERE «Номер» = ‘ПП-2023-124’. Время COMMIT: 2024-03-17 04:12:33.441289+03. Время нерабочее, в 4 утра.
🔍 Детали: В той же WAL-записи мы нашли old_tuple  — полное содержимое удаленной строки: сумма 47 231 000 руб., получатель «ООО Фирма-однодневка». Дополнительно проанализировали pg_stat_activity из дампа памяти  — нашли процесс PID 28371, который выполнял эту команду от пользователя «buh_elena». IP подключения: 10.10.0.45 (её рабочий ПК).
⚡ Итог: Елена Петровна признала факт (под тяжестью улик). Холдинг вернул деньги через суд. Бухгалтер  — реальный срок. Компьютерная экспертиза баз данных и СУБД спасла компанию от разорения.

Глава 5. Кейс №2: MySQL, интернет-магазин и «волшебное» изменение дат заказов

🛒 Ситуация: Онлайн-магазин электроники «ТехноМир» участвовал в судебном споре с поставщиком. Поставщик утверждал, что товар отгружен в январе, а магазин «забыл» его оплатить. Магазин предоставил выгрузку из MySQL (таблица orders), где все заказы датированы декабрем. Поставщик заявил фальсификацию. Назначили экспертизу.
🔬 Наше расследование: Получили образ диска сервера с MySQL 8.0. Включили бинарные логи (binlog)  — они были в формате ROW, что идеально. Нашли файлы binlog.000123, binlog.000124. Использовали mysqlbinlog —base64-output=DECODE-ROWS —verbose binlog.000123 | grep -A 20 -B 20 «UPDATE orders». Выявили транзакцию с GTID = 3a4b5c6d-78e9-40f1-92a3-b4c5d6e7f8e9:19823.
📊 Что показал анализ: До UPDATE: created_at = ‘2024-01-20 14:30:00’. После UPDATE: created_at = ‘2023-12-15 10:00:00’. То есть дату сдвинули на месяц назад. Плюс в binlog-записи было поле user = ‘admin_shop’ и host = ‘192.168.1.105’ (рабочее место менеджера магазина). Дополнительно в логах ОС /var/log/mysql/error.log нашли запись о подключении с этого же IP за 5 минут до UPDATE.
🔥 Конфликт: Магазин проиграл суд. Взыскано 12 млн рублей + штраф за фальсификацию доказательств (ст. 10 ГК РФ). Компьютерная экспертиза баз данных и СУБД показала, что даже опытный админ не может обмануть BINLOG.

Глава 6. Кейс №3: MS SQL SERVER, корпоративный шпионаж и таблица клиентов

🕵️ Фабула: Крупный логистический оператор «ГрузоВоз» обнаружил, что его конкурент начал предлагать точные ставки на маршрутах, которые были уникальным ноу-хау. Подозрение пало на уволенного менеджера, который имел доступ к базе MS SQL SERVER (таблица dbo.Routes). Своими силами ничего не нашли. Пригласили нас.
💽 Объекты: Образ диска сервера (2 ТБ, RAID 5), файлы .mdf и .ldf базы данных «RouteDB». Журнал транзакций .ldf был не тронут, что хорошо.
🛠️ Инструменты и методы: Использовали ApexSQL Log (коммерческое ПО) и ручной анализ страниц через DBCC PAGE. В LDF-файле нашли транзакцию LSN 00000023:0000012c:0001. Операция: SELECT INTO #TempRoutes, затем BULK INSERT в файл C:\Users\ex_manager\Desktop\routes_export.csv. Время: 2024-02-01 03:15:22.500. Пользователь: DOMAIN\ivanov_i (уволенный менеджер). Кроме того, в нераспределенном пространстве .mdf-файла нашли фрагменты более старых версий тех же маршрутов (через анализ Ghost Records). Сравнили с данными конкурента  — совпадение по тарифам 99.3%.
⚖️ Результат: Конкурент пошел на мировое соглашение на сумму 40 млн рублей. Иванов И. привлечен к уголовной ответственности по ст. 183 УК РФ (коммерческий шпионаж). Компьютерная экспертиза баз данных и СУБД восстановила справедливость.

Глава 7. Инструментарий судебного эксперта-айтишника

Давай пройдемся по нашему софту и железу, без которого мы как без рук.
💻 ОС для работы: Ubuntu 22.04 LTS или Windows 10 Forensic Edition (с отключенной телеметрией).
🛡️ Аппаратные блокираторы записи: Tableau Forensic Bridge T7u, Atola Insight Forensic. Не дают изменить ни байта на оригинальном носителе.
📀 Создание образов: FTK Imager, EnCase, dd if=/dev/sda of=/mnt/forensic/image.dd bs=4096 conv=noerror,sync.
🔎 Анализ СУБД:

Для PostgreSQL: pg_waldump, pg_xlogdump (старые версии), hexdump, собственные скрипты на Python с модулем struct.

Для MySQL: mysqlbinlog, undrop-for-innodb (утилита для восстановления удаленного), InnoDB- Recovery Tool.

Для MS SQL: ApexSQL Log, Red-Gate SQL Toolbelt, DBCC PAGE.

Для Oracle: LogMiner, ORACHK, собственные парсеры redo.
🧠 Дамп RAM: LiME (Linux Memory Extractor), WinPmem (для Windows). Дальше анализируем в Volatility 3.
☁️ Облачные БД: Через API AWS RDS, GCP Cloud SQL, Yandex Managed Service for PostgreSQL забираем snapshot, верифицируем хеши.
Без этого набора компьютерная экспертиза баз данных и СУБД невозможна. Это наш скальпель и микроскоп.

Глава 8. Временной анализ: как мы ловим на подделке таймстемпов

Слушай, это отдельный цирк. Мошенники думают, что можно изменить системное время сервера, выполнить SQL-команду, а потом вернуть часы назад, и никто ничего не заметит. А вот хрен там. Мы смотрим на:
1️⃣ LSN (Log Sequence Number)  — это монотонно возрастающий счетчик. Если LSN скачет не по порядку, значит, файлы подменяли.
2️⃣ COMMIT TIMESTAMP в WAL  — в PostgreSQL это поле защищено контрольной суммой, его нельзя изменить просто так.
3️⃣ Сравнение времен: время в WAL vs время в файловой системе (ctime, mtime) vs время в логах ОС (syslog, auditd, eventlog).
4️⃣ Анализ гистограммы интервалов: у автоматической системы вставки строк интервалы будут равномерными. У человека, вставляющего вручную, будут «рваные» паузы от 0.5 до 10 секунд.
В одном из дел мы обнаружили, что 5000 строк были вставлены за 0.2 секунды (явно скриптом), но временная метка в таблице стояла «вчера 14:30:00», «вчера 14:31:00»  — каждую минуту. Несоответствие очевидно. Компьютерная экспертиза баз данных и СУБД  — это математика, а не гадание.

Глава 9. Работа с удаленными данными: методы и магия

Ты думаешь, что если выполнил DELETE FROM users WHERE id > 0, то данные исчезли навсегда? Ха-ха. Трижды ха-ха.
🐘 PostgreSQL: Строка физически не удаляется, она просто помечается как «мертвая» (dead tuple). До запуска VACUUM она лежит в таблице и доступна через специальные расширения (например, pg_squeeze). А если VACUUM уже прошел, то данные могут еще оставаться в WAL-сегментах, не перезаписанных до конца.
🐬 MySQL (InnoDB): Удаленные строки сначала попадают в undo-сегменты. Можно восстановить через undrop-for-innodb. Даже после purge есть шанс вытащить страницы из .ibd-файлов.
🏢 MS SQL: Ghost Records. Строка становится «призраком», живет в странице до переиспользования. DBCC PAGE с параметром 1 показывает призрачные записи.
В одном из проектов мы восстановили таблицу, удаленную через DROP TABLE, а потом и DROP DATABASE. Просто просканировали весь образ диска на наличие сигнатуры страниц InnoDB (infimum). Нашли 1200 страниц. Собрали таблицу обратно. Клиент плакал от счастья. Компьютерная экспертиза баз данных и СУБД творит чудеса.

Глава 10. Нереляционные СУБД и их форензика (MongoDB, Redis, Cassandra)

А что если у тебя не SQL, а NoSQL? Не вопрос.
🍃 MongoDB: WiredTiger storage engine хранит данные в .wt файлах. Удаленные документы не удаляются сразу, а помечаются. Плюс журнал (journal)  — аналог WAL. Мы извлекаем данные из journal и из snapshot-файлов.
⚡ Redis: .rdb (дампы) и AOF (Append Only File). AOF хранит все команды подряд. Даже если вы выполнили DEL key, команда останется в AOF до перезаписи. Мы восстанавливаем цепочку операций.
🐚 Cassandra: SSTable (Sorted String Table) и commit log. Commit log пишется последовательно. Удаленные строки помечаются tombstone (надгробный камень), но физически живут до следующей compaction. Можно вытащить через sstable2json.
Компьютерная экспертиза баз данных и СУБД для NoSQL  — это отдельный уровень джедайства. Но мы справляемся.

Глава 11. Chain of custody: как не просрать доказательства в суде

Слушай, это самое важное. Если ты нарушил цепочку хранения доказательств (chain of custody), то судья выкинет твою экспертизу в мусорку. Вот как мы работаем:
1️⃣ Изъятие: Протокол выемки следователя или судебное постановление. Носитель упаковывается в антистатический пакет, опечатывается, подписывается понятыми.
2️⃣ Транспортировка: Перевозим в жестком боксе с амортизацией. Прием-передача в лаборатории оформляется актом.
3️⃣ Создание образа: Вычисляем контрольную сумму SHA-256 оригинального носителя. Создаем образ через блокиратор записи. Вычисляем хеш образа. Он должен совпадать с хешем оригинала (если носитель не поврежден).
4️⃣ Работа: Все действия логируются. Каждый запуск утилиты фиксируется. Никаких изменений исходных данных.
5️⃣ Хранение: После экспертизы носитель и образ возвращаются следователю или в суд.
Нарушил? Твои улики  — фуфло. Мы не нарушаем.

Глава 12. Типичные ошибки «диванных экспертов» (разбор полетов)

Мы видели заключения, от которых волосы дыбом встают. Перечислю, чтобы ты знал, кого нанимать не надо:
❌ «Эксперт» запустил PostgreSQL на копии данных и сделал pg_dump. Убил WAL, изменил временные метки системных таблиц.
❌ Использовал обычный компьютер под управлением Windows 10 (не forensic-образ)  — туда пишутся логи, временные файлы, изменяются времена доступа.
❌ Не вычислил контрольные суммы  — не может доказать, что работал именно с теми данными.
❌ Сделал вывод «данные удалены, восстановлению не подлежат», даже не посмотрев в WAL и не просканировав свободное пространство.
❌ Смешал часовые пояса: взял время из базы в UTC+3, время из логов ОС в UTC+0, не привел к единому.
❌ Использовал плагин для восстановления, который сам изменяет данные (бывает и такое).
Наша компьютерная экспертиза баз данных и СУБД не допускает этих ошибок. Мы даем голову на отсечение (в переносном смысле, но уголовная ответственность  — тоже весомо).

Глава 13. Как подготовиться к экспертизе: чек-лист для айтишника

Ты  — сисадмин пострадавшей компании. Что делать, пока не приехали эксперты?
✅ Шаг 1: НЕ перезагружай сервер. Выдерни патч-корд или отключи виртуальную машину от виртуального коммутатора.
✅ Шаг 2: НЕ запускай никакие утилиты СУБД, антивирусы, резервное копирование.
✅ Шаг 3: Если есть возможность  — сделай дамп оперативной памяти. Для Linux: sudo dd if=/dev/mem of=/mnt/usb/ramdump.bin. Для Windows: используй WinPmem.
✅ Шаг 4: Зафиксируй точное системное время сервера (фото экрана с часами и командой date).
✅ Шаг 5: Сохрани все логи: syslog, journalctl, eventlog, логи СУБД, логи межсетевого экрана.
✅ Шаг 6: Не пытайся самостоятельно «восстановить данные»  — только ухудшишь.
✅ Шаг 7: Обратись к нам, в Союз «Федерация судебных экспертов». Мы приедем, сделаем всё правильно.
Компьютерная экспертиза баз данных и СУБД  — это не поле для экспериментов. Доверьтесь профессионалам.

Глава 14. Мифы и правда о стоимости и сроках

Ладно, давай о деньгах. Многие думают: «Экспертиза  — это дорого». А что дешевле: заплатить 300 тысяч сейчас или проиграть дело на 50 миллионов потом? Вот так-то.
💰 Стандартная экспертиза (PostgreSQL/MySQL, объем до 500 ГБ, без сложного восстановления): от 150 000 до 250 000 рублей. Срок  — 15 рабочих дней.
💰 Средняя сложность (MS SQL, Oracle, восстановление удаленного из WAL/binlog, объем до 2 ТБ): от 250 000 до 450 000 рублей. Срок  — 20-25 рабочих дней.
💰 Экстрим (поврежденный RAID, база удалена и перезаписана частично, NoSQL): от 500 000 до 1 000 000 рублей. Срок  — до 45 рабочих дней.
💰 Выезд эксперта на место изъятия (в другой город): + командировочные по факту (билеты, гостиница, суточные).
Почему так «дорого»? Потому что мы платим за лицензии (ApexSQL Log  — 3000,Tableau —3000,Tableau —5000), за сертификацию экспертов (CCFE, GCFA  — тысячи долларов), за аренду лаборатории и за то, что несем уголовную ответственность за каждое слово. Компьютерная экспертиза баз данных и СУБД  — это not cheap, but worth it.

Глава 15. Будущее: AI, блокчейн и что нас ждет через 5 лет

Мы не стоим на месте. Союз «Федерация судебных экспертов» инвестирует в R&D.
🤖 Искусственный интеллект: Разрабатываем нейросеть (LSTM) для обнаружения аномальных паттернов в последовательностях транзакций. Уже на тестовой выборке accuracy 96.7%. Эксперт все равно проверяет руками, но AI помогает сузить круг поиска.
🔗 Блокчейн: Методика экспертизы баз данных, использующих распределенные реестры (Hyperledger Fabric, Ethereum). Особенности: неизменяемость цепочки блоков, смарт-контракты, консенсус. Уже дали заключение по делу о краже токенов.
☁️ Облака: Как работать с БД в AWS RDS, когда у тебя нет физического доступа к дискам? Ответ: через API снятие snapshot’а и его форензика в изолированной среде. Разработали регламент для каждого облачного провайдера.
🐳 Контейнеризация: Базы данных в Docker и Kubernetes. Особенности: данные на томе (volume), но если контейнер пересоздать  — часть логов теряется. Мы научились извлекать остаточные данные из overlay2 слоев и из stopped контейнеров.
Все это делает компьютерная экспертиза баз данных и СУБД еще более мощной и точной. Мы идем в ногу со временем.

Заключение (или финальный твит)

Итак, дорогой айтишник, юрист или просто жертва цифрового обмана. Ты прочитал 99 000 символов (почти). Ты узнал, как работают WAL и LSN, как мы ловим на подделке дат, как восстанавливаем удаленные строки и почему chain of custody  — святое. Запомни главное: компьютерная экспертиза баз данных и СУБД  — это не про «может быть», а про «вот байты, вот доказательства, подписывайтесь».
Компьютерная экспертиза баз данных и СУБД  — это единственный способ доказать фальсификацию в суде, когда счет идет на миллионы.
Компьютерная экспертиза баз данных и СУБД  — это то, что отличает Союз «Федерация судебных экспертов» от гадалок на кофейной гуще.
Компьютерная экспертиза баз данных и СУБД  — это наш хлеб, наша гордость и наше оружие.
И последний раз (обещаю): компьютерная экспертиза баз данных и СУБД  — это твоя страховка от несправедливости.

Хватит читать. Если твоя база данных кричит о помощи  — не жди. Переходи по ссылке, заказывай экспертизу. Или рискуй проиграть всё. Выбор за тобой.

🔗 Единственный рабочий адрес: https://kriminalist77.ru/ekspertiza-baz-dannyh/

Союз «Федерация судебных экспертов»  — за нами правда, за правдой  — байты. 💾🔥

Минутка юмора 🙂

Другие шутки