В практике сопровождения информационных баз 1С нередко возникают инциденты, когда неавторизованные лица или недобросовестные сотрудники удаляют важные документы и пытаются замести следы, очищая системный журнал регистрации. В такой ситуации перед системным администратором и разработчиком встает задача: установить виновника инцидента. Разберем детально, какую информацию можно извлечь из СУБД, почему журнал транзакций SQL не покажет имя пользователя 1С и где на самом деле сохраняются цифровые следы злоумышленника.
Первая мысль при расследовании удаления данных в клиент-серверном варианте — обратиться к журналу транзакций MS SQL Server (файлу .ldf). Однако здесь мы сталкиваемся с архитектурной особенностью взаимодействия платформы 1С и СУБД. Проанализируем, почему этот путь не даст прямого ответа на вопрос о виновнике:
rphost). Сервер 1С обращается к SQL Server от имени одной технической учетной записи (например, usr1cv8). Для СУБД все запросы на удаление, вставку или обновление выполняет один и тот же системный пользователь.CONTEXT_INFO или параметры подключения APP_NAME).FULL) с помощью системных функций, таких как fn_dblog, можно увидеть точное системное время транзакции, тип операции (например, LOP_DELETE_ROWS) и идентификатор удаленной строки в таблице документов (вида _Document123). Однако связать эту операцию с конкретным логином в 1С средствами СУБД невозможно.Журнал регистрации 1С в современных версиях платформы также не хранится внутри таблиц SQL Server — он вынесен в отдельное файловое хранилище на сервере приложений. Поэтому откат транзакций или анализ лога СУБД позволяет лишь восстановить физические данные, но не идентифицировать автора изменений.
Рассмотрим механизм очистки логов в 1С. В интерфейсе платформы журнал регистрации нельзя просто удалить — его можно только сократить до определенной даты (процедура «Сократить журнал регистрации»). При выполнении этой команды платформа штатно фиксирует служебное системное событие.
Так как злоумышленник срезает исторические события за прошлый период, сама операция сокращения выполняется в текущий момент времени. Это означает, что запись о факте сокращения попадает в актуальную, неудаленную часть журнала регистрации. Откроем журнал регистрации в режиме «Конфигуратор» или в режиме «1С:Предприятие» и установим отбор по системным событиям:
Журнал регистрации.Сокращение (системный идентификатор _$EventLog$_.Reduce)..elf или .lgp). Обязательно проверим локальные диски администраторских рабочих мест и общедоступные сетевые папки на наличие свежих файлов архивов.Если в конфигурации на базе «Библиотеки стандартных подсистем» было включено версионирование объектов, сведения об удаленных документах сохраняются независимо от журнала регистрации. Проанализируем регистр сведений ВерсииОбъектов:
ВерсииОбъектов автоматически не стираются (для их удаления предусмотрено отдельное регламентное задание).UUID), мы можем запросить данные среза последних версий из регистра сведений.АвторВерсии, дата и точное время сохранения последней редакции, а также упакованный XML-снимок всех реквизитов и табличных частей документа на момент его последнего изменения перед удалением. Это позволяет не только определить ответственного пользователя, но и восстановить содержание документов.Начиная с версии 8.3.5, журнал регистрации платформы 1С хранится в файле формата базы данных SQLite с именем 1Cv8.lgd, расположенном в каталоге данных информационной базы внутри папки srvinfo сервера 1С. Разберем низкоуровневые особенности работы SQLite:
freelist).VACUUM. Платформа 1С не запускает эту процедуру автоматически при каждом сокращении.1Cv8.lgd еще не успел перезаписаться новыми событиями, мы можем открыть его специализированными криминалистическими утилитами для анализа SQLite или выполнить поиск текстовых сигнатур по телу файла. В свободных страницах (unallocated space) часто удается обнаружить фрагменты текста, содержащие имя пользователя, GUID удаленных объектов и названия событий за удаленный интервал времени.Выясним состояние резервных копий файловой системы сервера приложений 1С. На серверах под управлением Windows Server очень часто функционирует служба теневого копирования томов (Volume Shadow Copy Service):
srvinfo (хранилище сеансовых данных и журналов 1С), могут присутствовать автоматические снимки состояния тома.vssadmin list shadows.1Cv8.lgd или каталоги со старыми файлами .lgp в исходном, несокращенном состоянии.Если злоумышленник выполнил удаление под чужой учетной записью 1С, необходимо связать программные действия с физическим рабочим местом. Для этого используем связку полученного времени сокращения журнала и системных логов операционной системы:
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational. Событие с кодом 21 (Session logon succeeded) и событие 25 (Session reconnection succeeded) содержат доменное имя пользователя, его учетную запись Windows, а главное — исходный IP-адрес и имя физического клиентского компьютера, с которого производилось подключение.4624 (Успешный вход в систему) на сервере терминалов или контроллере домена позволяет зафиксировать сетевой адрес рабочей станции и сопоставить его с учетной записью 1С, под которой производилось сокращение журнала или удаление документов.Если в информационной базе настроен обмен данными (РИБ или синхронизация с другими конфигурациями через планы обмена), проанализируем состояние узлов обмена. При непосредственном удалении элементов платформа регистрирует факт удаления в служебных таблицах изменений (_ChangeRec...). В этих записях сохраняются ссылки на удаленные объекты с признаком удаления. Это позволяет составить точный перечень удаленных документов, даже если они полностью стерты из основных таблиц базы данных.