Глава 1: Пролог в мире таблиц и транзакций

Привет, коллега! 👋 Давай сразу к делу: ты когда-нибудь задумывался, сколько преступлений прячется за обычным SQL-запросом? Сколько махинаций скрыто в недрах INSERT, UPDATE и DELETE? 🤔 Мир, в котором мы с тобой живем  — мир айтишников, девопсов, дата-сайентистов и сеньоров  — давно уже стал полем битвы за правду. И на этом поле Экспертиза баз данных и СУБД  — это тяжелая артиллерия, которая стреляет не снарядами, а фактами. 💥

Мы, команда Союза «Федерация судебных экспертов», каждый день вскрываем цифровые трупы баз данных. Звучит жестко? А оно и есть жестко. Потому что за каждой подозрительной транзакцией стоят реальные деньги, судьбы людей, иногда даже свобода. ⚖️

И сегодня я приглашаю тебя в увлекательное путешествие по закоулкам судебной компьютерной экспертизы. Будет много кода, логики, сломанных иллюзий и, конечно, крутых кейсов, от которых у некоторых горе-админов волосы шевелятся. 🧔‍♂️💨

Пристегни ремни  — мы начинаем. 🚀

Глава 2: Почему обычный DBA не справится с судебной экспертизой?

Некоторые думают: «Зачем платить каким-то экспертам? У нас есть свой администратор баз данных, он всё покажет!». Стоп. Стоп-стоп-стоп. ✋ Это как попросить водителя автобуса сделать операцию на сердце. DBA  — крутой парень, он знает про индексы, про оптимизацию запросов, про шардирование и репликацию. Но судебная экспертиза  — это другая лига. 🏆

Экспертиза баз данных и СУБД требует:

🧠 Понимания криминалистики: как фиксировать доказательства, чтобы они не потеряли силу в суде.

📜 Знания процессуального законодательства: протоколы, постановления, ходатайства.

🛡️ Опыта работы со следами: мы ищем не баги, а умысел.

🔬 Научной базы: наши выводы должны быть воспроизводимы и проверяемы.

DBA может случайно запустить VACUUM FULL и уничтожить полжурнала. А мы придем с write-blocker’ом, снимием образ диска и будем работать как саперы  — ошибка недопустима. 💣

Поэтому, когда речь идет о суде, арбитраже или уголовном деле, доверяй профессионалам. Доверяй нам. 🤝

Глава 3: Анатомия СУБД: где живут улики?

Давай заглянем под капот любой серьезной базы данных. Неважно, PostgreSQL это, MySQL, Microsoft SQL Server или Oracle. У всех есть общие черты, которые мы, эксперты, используем как карту сокровищ. 🗺️

Журналы транзакций (WAL, REDO, UNDO)  — это наша библия. 📖
Сюда записывается каждое действие: вставка, обновление, удаление. Даже если ты сделал ROLLBACK, след остался. Даже если ты запустил DELETE без WHERE, мы найдем, что было удалено.

Системные каталоги и таблицы метаданных  — они хранят структуру, права доступа, историю изменений схемы. Преступники часто ломают структуру, чтобы скрыть следы. Мы это видим. 👀

Временные метки (timestamps)  — здесь кроется магия. Разница времен на сервере, на клиенте, в запросах. Один из наших кейсов (будет ниже) раскрылся именно благодаря анализу времени. ⏰

План выполнения запросов  — иногда сам оптимизатор СУБД сохраняет историю выполнения. Это как черный ящик самолета. 🛩️

И наконец, файлы на диске. Да, даже если база думает, что данные удалены, физически они могут лежать на HDD или SSD, помеченные как свободные. И вот тут начинается магия low-level анализа. ✨

Глава 4: Кейс №1  — Арбитражный спор поставщиков: кто подменил накладные?

🏭 История первая, реальная (с измененными деталями). Две компании: ООО «Рога и Копыта» и ООО «Золотой Теленок». Спор на 120 миллионов рублей. «Рога» говорят: вы поставили бракованный товар, мы его не принимали. «Теленок» тычет в базу: смотрите, в нашей 1С (а там MSSQL) все накладные подписаны, товар отгружен.

✅ Наша задача: провести Экспертиза баз данных и СУБД на сервере истца и ответчика.

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

• Сняли образы дисков серверов с помощью write-blocker’а. 🔒
• Проанализировали журналы транзакций MSSQL (файлы .ldf).
• Обнаружили, что в ночь перед судом кто-то запустил скрипт, который массово обновил даты подписания накладных с NULL на ‘2023-05-15 14:30:00’.
• В логах операционной системы нашли вход под учетной записью sql_admin с IP-адреса, который принадлежал бывшему сотруднику «Теленка», уволенному за два месяца до этого. 🕵️

Итог: Суд признал накладные сфальсифицированными. «Золотой Теленок» не только не получил 120 миллионов, но и заплатил штраф за фальсификацию доказательств. А мы получили благодарность от судьи. 🧑‍⚖️

Вывод: Никогда не думай, что твой скрипт не найдут. Журналы СУБД помнят всё. Даже если ты удалишь их, останутся следы в ОС, в бэкапах, в теневых копиях. 💾

Глава 5: Независимость  — наше всё (и точка!)

Слушай, сейчас будет важная мысль. В судебной экспертизе есть страшный зверь  — ангажированность. 🐉 Это когда эксперт работает на того, кто платит. Мы таких не любим. Более того, мы с ними боремся.

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

• Не берем заказы, где результат предрешен.
• Предупреждаем заказчика: «Если вы виноваты, мы это найдем».
• Даем подписку об уголовной ответственности за ложное заключение (статья 307 УК РФ). Тюрьма  — плохой мотиватор врать. 😱

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

Мы не продаем «удобные» заключения. Мы продаем правду. Цена правды  — наша репутация. 💎

Глава 6: Технические тонкости: как мы не даем себя обмануть?

Представь: подозреваемый говорит: «Я ничего не трогал, это само сломалось». Ха-ха-ха. Три раза ха. 😂

Мы смотрим на:

Контрольные суммы страниц данных (в MSSQL  — DBCC CHECKDB, в PostgreSQL  — проверка страниц). Если страница повреждена, но контрольная сумма сошлась  — значит, повреждение было легальным (сама СУБД так записала). А если не сошлась  — привет, внешнее вмешательство.

LSN (Log Sequence Numbers)  — последовательность номеров логов. Разрывы в LSN говорят о подмене или удалении журналов.

Сравнение с бэкапами. Если у нас есть бэкап за вчера и сегодня, и мы видим 10 000 изменений за 5 минут  — это не человек работал, это скрипт запустили. 🤖

Один из наших любимых методов  — анализ свободного пространства внутри файлов БД. InnoDB (MySQL) помечает удаленные строки, но не затирает их до следующей вставки. Мы с помощью утилит типа undrop-for-innodb восстанавливаем эти строки как милые картинки. 🖼️

И да, мы работаем с SSD. Да, там TRIM. Да, есть нюансы. Но мы знаем, как обойти даже их. Не будем раскрывать все секреты, но скажем так: у нас есть методики работы на низком уровне, включая чтение чипов памяти. 🔬

Глава 7: Кейс №2  — Уголовное дело о хищении персональных данных

👤 Вторая история. Крупный телеком-оператор. Утекли персональные данные 50 000 абонентов: паспорта, адреса, номера телефонов. Внутреннее расследование показало, что утекли через базу данных биллинга на PostgreSQL.

Подозреваемый  — уволенный аналитик, который обиделся на компанию. Его ноутбук изъяли, но он сказал: «Я не брал, я ничего не знаю».

✅ Наша экспертиза: Экспертиза баз данных и СУБД сервера биллинга и ноутбука аналитика.

Что мы нашли:

• В логах PostgreSQL (pg_log)  — выполнение необычных запросов с IP-адреса, который через VPN вел на квартиру аналитика. 🏠
• В журналах аудита (расширение pgaudit)  — выборка всех полей passport_series, passport_number, address за 2 минуты. Это не работа, это дамп.
• На ноутбуке аналитика  — файл dump.csv с этими же данными. Файл был удален в корзину, но не затерт. Восстановили. 🗑️➡️♻️
• Метаданные файла: дата создания совпадала с датой выполнения подозрительных запросов на сервере.

Финал: Аналитик получил 3 года условно + штраф 2 млн рублей. Компания провела аудит безопасности и наняла нас уже на постоянной основе для мониторинга. 💼

Мораль: Никогда не храни украденное на том же ноутбуке, где ищешь работу. И не думай, что корзина  — это безопасно. 😉

Глава 8: Работа с NoSQL и новомодными хранилищами

Мир не стоит на месте. SQL  — это классика, джаз, рок-н-ролл. 🎸 Но появляются MongoDB, Cassandra, Redis, ClickHouse. И туда тоже лезут преступники.

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

• Меньше журналирования (и это боль). В Redis вообще нет WAL по умолчанию, только RDB-снапшоты и AOF-логи, которые часто отключают.
• Динамические схемы  — сложнее понять, что изменилось.
• Распределенные системы  — данные могут быть на 50 серверах, и нужно собрать всё воедино. 🕸️

Но мы справляемся. Например, в MongoDB мы анализируем oplog  — это коллекция, где хранятся все операции репликации. Она есть почти всегда. И она не врет.

В Cassandra  — изучаем commit-логи и хинты (hinted handoff). Даже если данные удалены, hint может сохранить их призрак. 👻

Экспертиза баз данных и СУБД сегодня  — это не только про реляционные базы. Это про весь стек хранения данных. И мы держим руку на пульсе. 🩺

Глава 9: Научная обоснованность: как мы доказываем суду?

Судьи  — умные люди, но они не айтишники. Им не расскажешь про LSN и контрольные суммы. Им нужен перевод с IT на человеческий. 🗣️

Наше заключение строится так:

• Вводная часть  — кто, когда, на основании чего проводил экспертизу.
• Исследовательская часть  — сухие факты, скриншоты, хэши, команды, которые мы запускали. С указанием версий ПО, инструментов, параметров.
• Синтез  — мы объясняем, что означают эти факты на простом языке. «Запрос X выполнился в 3:15 ночи с IP Y»  — значит, кто-то посторонний имел доступ.
• Выводы  — четко, по пунктам, без «возможно», «вероятно». Только «да», «нет», «следует», «не следует».

При этом каждый вывод подкреплен:

📸 скриншотом

🧮 математическим расчетом (например, количество изменений за единицу времени)

📚 ссылкой на методическую литературу (но не на сторонние сайты, а на ГОСТы и аттестованные методики)

Судьи нас любят за это. Прокуроры  — тоже. Адвокаты  — боятся (в хорошем смысле). 😎

Глава 10: Кейс №3  — Фальсификация голосования в СНТ

🏡 Третий кейс, почти детективный. Товарищество собственников жилья, председатель СНТ «Березка» уже 10 лет у власти. Вдруг появляется конкурент, проводит онлайн-голосование через сайт на MySQL. Результат: старый председатель проиграл. Он кричит: «Нарушения! Боты!».

Приходят к нам. ✅

Экспертиза баз данных и СУБД сайта голосования.

Что мы увидели:

В таблице votes было поле ip_address и user_agent. 80% голосов пришли с одного /24 подсети, причем user agent был одинаковый  — «Python-urllib/3.9». Это не браузер, это скрипт. 🐍

В журналах MySQL (general log) нашли выполнение вставок в votes с 2-секундными интервалами  — ровно время, за которое скрипт делал POST-запрос.

Анализ временных меток показал, что голоса от реальных людей (с разными user-agent) были вперемешку со скриптовыми, но скриптовые шли пачками по 50–100 штук.

Кроме того: мы нашли на сервере конкурента (по постановлению суда его диск изъяли) скрипт vote_bot.py. В коде были username/password от административной панели голосования. 🔐

Итог: Выборы признаны недействительными. Старый председатель вернул кресло. Конкурент теперь фигурант уголовного дела по статье 159 УК РФ (мошенничество). 💰

Мораль: Если ты решил сфальсифицировать голосование, хотя бы используй разные user-agent и прокси. Но лучше не пытайся  — мы всё равно найдем. 👮

Глава 11: Психология цифрового взломщика и защита от него

Знаешь, за годы работы мы заметили интересную закономерность. 💡 Преступники, которые трогают базы данных, делятся на три типа:

Умные, но ленивые  — они знают, что логи пишутся, но надеются, что их никто не прочитает. Пишут скрипты прямо на сервере, не маскируют IP. 🙈

Параноики  — используют VPN, Tor, удаляют логи, чистят bash_history. Но всегда допускают одну ошибку. Например, забывают про журналы СУБД на репликах. 🕵️‍♂️

Инсайдеры  — у них есть легальный доступ. Они думают, что их действия не вызовут подозрений. Но мы смотрим на аномалии: почему финансовый аналитик в 3 часа ночи делает SELECT * FROM salaries? 🤨

Наша методика защиты (для компаний, которые хотят предотвратить, а не разгребать последствия):

• Включите аудит на уровне СУБД (pgaudit для PostgreSQL, Audit для Oracle, Extended Events для MSSQL).
• Настройте оповещения на нехарактерные запросы (например, массовые выборки).
• Храните логи на отдельном, защищенном от админов БД сервере.
• Делайте криптографические слепки базы данных на регулярной основе.
• Но если беда уже случилась  — зовите нас. Мы разберем всё до винтика. 🔧

Глава 12: Как мы работаем с поврежденными и шифрованными базами?

А теперь жесткая тема. 🔥 Преступники иногда не только удаляют, но и шифруют базы. Или повреждают их физически. «Ничего не прочитаешь»,  — думают они. Ошибаются.

Шифрование на уровне СУБД (TDE, файловое шифрование):

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

Поврежденные базы (битые страницы, разрушенные файлы):

• Используем утилиты pg_rewind, innodb_force_recovery, DBCC CHECKDB с флагами.
• На низком уровне: читаем диск побайтово, ищем сигнатуры таблиц и восстанавливаем данные фрагментами.
• Если база была на RAID  — работаем с образами каждого диска, эмулируем контроллер.

Ручное восстановление  — это адский труд. Но иногда только так можно спасти доказательства. И мы это делаем. Потому что Экспертиза баз данных и СУБД не про «быстро и дешево». Она про «точно и честно». 💯

Глава 13: Мифы о судебной экспертизе БД (разрушаем)

Миф 1️⃣: «Если данные удалены, их нельзя восстановить»
Неправда. В HDD магнитные домены сохраняют остаточную намагниченность. В SSD  — есть вероятность восстановления из кэша контроллера. Но даже если физически данные затерты, остаются логи, резервные копии, теневые файлы. Не сдавайтесь без нас! 🦸

Миф 2️⃣: «СУБД не хранит историю изменений, если не включить аудит»
Чушь. WAL, binlog, redo log  — это история по умолчанию. Просто не все знают, как ее читать. А мы знаем. 📖

Миф 3️⃣: «Экспертиза стоит бешеных денег»
Сравните со стоимостью проигранного суда на 100 млн рублей. Или с уголовным сроком. Наши услуги  — это инвестиция в правду. И да, у нас есть бюджетные варианты для физлиц. 💸

Миф 4️⃣: «Любой DBA может дать заключение»
Может. Только суд его не примет, потому что нет аттестации, нет методики, нет процессуального статуса. А наше заключение  — это юридический документ. 📑

Глава 14: Как заказать экспертизу в «Федерации судебных экспертов»?

• Всё просто, как SELECT * FROM clients WHERE need_help = true; 😉
• Ты звонишь или пишешь нам через сайт: https://kriminalist77.ru/ekspertiza-baz-dannyh/
• Описываешь ситуацию: что случилось, какие базы данных, какая цель (судебный спор, внутреннее расследование, досудебная подготовка).
• Мы консультируем бесплатно  — говорим, возможно ли вообще исследование, какие сроки, какие документы нужны.
• Заключаем договор. Даем гарантии конфиденциальности. 🤐
• Проводим экспертизу. Сроки: от 5 дней до месяца, зависит от объема.
• Выдаем заключение в бумажном и электронном виде. При необходимости  — даем пояснения в суде, участвуем в заседаниях.

Наши преимущества:

⚡ Скорость: работаем 24/7 при авралах.

🧠 Компетенции: эксперты с 10+ лет опыта.

🏛️ Независимость: не связаны ни с какой стороной.

🔬 Научность: методики утверждены на уровне Федерации.

Не жди, пока цифровые следы остынут. Время  — враг доказательств. 🕰️

Глава 15: Заключение (или почему мы любим свою работу)

Знаешь, что самое кайфовое в нашей работе? 😊

Не деньги. Не слава. А момент, когда ты смотришь на распечатку логов, видишь ту самую строку, тот самый запрос, который рушит ложь. И понимаешь: сейчас правда восторжествует.

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

Экспертиза баз данных и СУБД для нас  — это не рутина. Это детектив, наука и искусство одновременно.

Если ты дочитал до сюда  — спасибо за внимание. Если столкнулся с проблемой  — не откладывай. Приходи к нам. Разберемся.

А если просто интересно  — подпишись на наши статьи. Мы пишем редко, но метко. 🎯

До связи, коллега! И помни: данные не лгут, лгут люди. Но мы научились читать данные. 😉

🟩 Союз «Федерация судебных экспертов»  — твой цифровой детектив. https://kriminalist77.ru/ekspertiza-baz-dannyh/