В практике технической экспертизы часто возникает вопрос: является ли предоставленный бэкап базы данных подлинным срезом на определенную дату или это результат манипуляций? Рассмотрим ситуацию, когда у нас есть две копии базы данных (от 01.07.2019 и 01.08.2019), и нам необходимо доказать или опровергнуть, что июльская копия не была создана путем удаления данных из августовской.
Многие ошибочно полагают, что простое удаление документов через интерфейс 1С или даже прямые DELETE запросы в MS SQL Server полностью стирают следы деятельности. На самом деле, архитектура SQL Server и механизмы работы платформы 1С оставляют глубокие «цифровые следы», которые практически невозможно полностью затереть без специализированных знаний и инструментов. Разберем основные методы проверки подлинности базы данных.
Проанализируем один из самых надежных механизмов контроля целостности и последовательности в MS SQL Server — Log Sequence Numbers (LSN). Каждая страница данных (размером 8 КБ) в файле .mdf содержит в своем заголовке значение LSN последнего изменения этой страницы. Это уникальный идентификатор, который монотонно увеличивается.
Выясним причину, почему это важно для экспертизы: если база от 01.07.2019 действительно была сделана в июле, то номера LSN на системных страницах не могут быть выше номеров в базе от 01.08.2019. Если же злоумышленник взял базу от 01.08.2019, удалил из нее данные за июль и сделал «новый старый» бэкап, то LSN многих страниц (включая системные таблицы и таблицы метаданных) окажутся больше (новее), чем в подлинной базе более позднего периода. Эксперт может проверить заголовки файлов с помощью системных функций:
RESTORE HEADERONLY FROM DISK = 'C:\Backup\July_Base.bak';
-- Анализируем поля: DatabaseBackupLSN, CheckpointLSN, RecoveryLSN
Сравнение этих цепочек номеров позволяет с высокой точностью определить, какая база является «предком», а какая — «потомком», независимо от того, какие даты установлены в операционной системе в момент создания бэкапа.
Рассмотрим специфику удаления данных в MS SQL Server. Когда в таблице удаляется строка, SQL Server не затирает её физически нулями. Он помечает запись как Ghost Record (запись-призрак). Это делается для оптимизации производительности: сервер просто помечает место как свободное, а физическим удалением занимается фоновый процесс Ghost Cleanup.
Если из августовской базы были массово удалены документы за целый месяц и сразу после этого сделан бэкап, то физические блоки данных в файле .mdf все еще будут содержать «удаленную» информацию. Эксперт, используя недокументированные команды, такие как DBCC PAGE, может прочитать содержимое этих страниц и увидеть фрагменты «удаленных» июльских документов в базе, которая якобы была создана 1 июля. Рассмотрим пример команды для анализа страницы:
-- Пример исследования конкретной страницы данных
DBCC TRACEON (3604);
DBCC PAGE ('ИмяБазы', 1, НомерСтраницы, 3);
В выводе данной команды можно обнаружить значения полей, которые уже не видны в 1С, но физически остаются в блоках данных до тех пор, пока эти блоки не будут перезаписаны новыми данными или не будет выполнено агрессивное сжатие базы.
Большинство таблиц 1С (особенно в части хранения метаданных и некоторых регистров) используют механизм автоинкремента. Посмотрим на работу команды DBCC CHECKIDENT. Каждый раз, когда в таблицу SQL добавляется новая запись, внутренний счетчик (Seed Value) увеличивается.
Если мы удаляем записи, этот счетчик не уменьшается автоматически. Проанализируем ситуацию: в августовской базе ID последнего документа был 5000. Если мы удалим документы, созданные в июле (например, с ID 4001 по 5000), то в «поддельной» июльской базе текущее значение счетчика IDENTITY все равно будет равно 5000. В то время как в настоящей базе от 1 июля этот счетчик должен быть в районе 4000. Любое несоответствие максимального ID в таблице и текущего значения Seed Value является прямым доказательством манипуляций.
-- Проверка текущего значения счетчика для таблицы
DBCC CHECKIDENT ('_Document150', NORESEED);
Платформа 1С:Предприятие генерирует ссылки (Уникальные Идентификаторы) определенным образом. В версиях 8.3 часто используются UUID версии 1, которые содержат в себе метку времени (timestamp) и MAC-адрес сервера.
Разберем по шагам, как это помогает нам: даже если злоумышленник удалил все «лишние» документы, в базе остаются записи в служебных таблицах, таблицах итогов, системных настройках или конфигурации. Если эксперт обнаружит в «июльской» базе ссылки (GUID), время генерации которых соответствует августу, это неопровержимо докажет факт использования более поздней базы в качестве исходника. Извлечь время из GUID можно программно, зная структуру хранения 1С (где младшие и старшие биты времени переставлены местами).
В сообщении форума упоминается, что лог транзакций (LDF) имеет размер 10 Гб при размере данных 20 Гб. Это очень важная деталь. Даже при «Простой» (Simple) модели восстановления, SQL Server записывает все операции удаления в лог, чтобы обеспечить возможность отката транзакции при сбое.
Проанализируем структуру лога: он состоит из Virtual Log Files (VLF). Массовое удаление данных за месяц — это тяжелая операция, которая оставляет записи в журнале. Если база не подвергалась процедуре полной очистки лога с последующим сжатием (Shrink), то в файле .ldf можно найти заголовки транзакций DELETE или TRUNCATE, которые выполнялись хронологически позже «даты создания» бэкапа. Более того, если был выполнен SHRINK, это само по себе является подозрительным фактом для «живой» рабочей базы, так как приводит к катастрофической фрагментации индексов, что редко допускается в штатном режиме.
Выясним, какие следы остаются в системных представлениях SQL Server. Таблицы sys.objects, sys.indexes и sys.partitions хранят даты создания и последней модификации.
При определенных манипуляциях, например, если для скрытия «хвостов» в ID использовалось пересоздание таблиц или индексов, даты изменения этих объектов в системном каталоге будут обновлены. Если дата изменения индекса в базе от 01.07.2019 — это 31.07.2019, то подлинность такой копии не выдерживает никакой критики.
SELECT name, create_date, modify_date
FROM sys.objects
WHERE type = 'U'; -- Просмотр дат изменения пользовательских таблиц
Подводя итог, можно утвердительно сказать: доказать факт подделки базы данных через SQL-экспертизу возможно. Основные точки контроля для эксперта:
Таким образом, простого удаления данных через интерфейс 1С недостаточно для того, чтобы выдать одну базу за другую перед лицом квалифицированной технической экспертизы.