Кто, что и когда изменил в базе 1С — как это узнать

Кто и что менял в базе, показывает журнал регистрации: откройте Главное меню → Все функции → Стандартные → Журнал регистрации, поставьте отбор по пользователю, дате и метаданным — и увидите, кто добавлял, изменял, проводил и удалял объекты. Это штатный механизм платформы 8.3, включать ничего не нужно, данные копятся автоматически.

Отслеживание изменений решается тремя уровнями: журнал регистрации (кто и когда тронул объект), версионирование объектов (какое именно поле поменялось и на что), анализ на уровне СУБД (когда нужна полная картина запросов). Ниже — как настроить каждый и когда какой применять.

Чтобы сразу выбрать подходящий уровень контроля, сопоставьте задачу и инструмент:

Журнал включён всегда, версионирование и СУБД-аудит подключают по необходимости.

Что фиксирует журнал регистрации, а что нет

Журнал регистрации пишет события сеансов и работы с данными. По каждой записи видно: дату и время с точностью до секунды, пользователя, компьютер, сеанс, вид события и объект метаданных.

Для контроля изменений важны четыре события данных:

• 📝 Данные.Добавление — создан новый объект;
• ✏️ Данные.Изменение — объект перезаписан;
• 📊 Данные.Проведение — документ проведён (или отменено проведение);
• 🗑️ Данные.Удаление — объект удалён (пометка и физическое удаление — разные события записи).

Чего журнал не хранит: прежних значений реквизитов. Он фиксирует сам факт «документ № такой-то изменён пользователем Ивановым в 14:32», но не покажет, что сумма была 1000, а стала 10 000. Для сравнения «до и после» нужен отдельный механизм — версионирование объектов (см. ниже).

Физически журнал лежит в файле 1Cv8.lgd (база SQLite) в каталоге 1Cv8Log. В файловой базе — рядом с 1Cv8.1CD, в клиент-серверной — в рабочем каталоге кластера. Формат SQLite используется с платформы 8.3.5; на более старых номерах встречаются файлы .lgf.

Настройка журнала регистрации в Конфигураторе

По умолчанию журнал пишет не все события. Уровень регистрации задаётся только в Конфигураторе: Администрирование → Настройка журнала регистрации.

В диалоге два параметра:

1. Какие события регистрировать. Выберите уровень важности не ниже «Информация» — иначе события добавления, изменения, проведения и удаления данных писаться не будут (они имеют важность «Информация»). Уровни «Ошибка» и «Предупреждение» оставят в журнале только сбои и предупреждения.
2. Разделять хранение по периодам. Варианты: не разделять, день, неделя, месяц. Разделение по месяцу удобно: журнал не разрастается в один огромный файл, старые периоды можно архивировать и удалять по отдельности.

После настройки убедитесь, что на диске есть запас места: при активной работе и разделении «по дням» журнал за месяц легко набирает единицы гигабайт.

Чтение и фильтрация записей журнала

Открыв журнал, вы увидите ленту событий. Главное здесь — отбор, иначе в тысячах строк ничего не найти. Нажмите «Установить отбор» (кнопка с воронкой) и задайте условия:

• Пользователь — чьи действия ищем;
• Интервал — дата и время от/до;
• Метаданные — например, только «Документ.РеализацияТоваровУслуг»;
• События — отметьте «Данные.Изменение», «Данные.Удаление» и другие нужные;
• Прочие данные — поиск по тексту комментария или представлению объекта.

Чтобы перейти от записи к самому объекту, выделите строку и выберите команду открытия данных (в меню «Ещё» или по двойному щелчку по ссылке объекта) — откроется та самая изменённая форма, если объект ещё существует.

Журнал можно выгрузить в файл: команда сохранения в формате .mxl или через конфигуратор. Для разовой передачи аудитору удобнее сохранить отфильтрованный список в таблицу и отдать её.

Версионирование: что именно поменялось в документе

Когда нужно не просто «кто тронул», а «что конкретно исправили» — поле за полем, со старым и новым значением — включите версионирование объектов. Это механизм Библиотеки стандартных подсистем (БСП), он есть в Бухгалтерии 3.0, ЗУП 3.1, УТ 11 и других типовых.

Порядок:

1. В разделе Администрирование найдите настройку «Версионирование объектов» (в разных конфигурациях — в группе общих настроек или настроек работы с программой).
2. Выберите объекты, которые нужно версионировать (документы, справочники), и момент создания версии — при записи или при проведении.
3. Теперь при каждом сохранении объекта платформа запоминает его состояние целиком.

Чтобы сравнить версии, откройте нужный документ и в меню «Ещё» выберите команду истории изменений (в типовых — «История изменений» или «Версии объекта»). Система покажет список версий с автором и датой, а по кнопке сравнения — таблицу различий: какой реквизит был, каким стал.

Кроме истории по конкретному объекту, в типовых есть отчёт по версиям — он сводит правки за период по всем версионируемым объектам сразу. Через него удобно разбирать «что вообще меняли на прошлой неделе», не открывая документы по одному.

Отличие от журнала простое: журнал отвечает на вопрос «кто и когда», версионирование — на вопрос «что именно изменилось в значениях». Для полноценного аудита обычно нужны оба: по записи журнала вы находите подозрительную правку, а в версиях смотрите, что конкретно в ней поменяли.

Контроль изменений на уровне СУБД

Если базы на SQL Server или PostgreSQL и нужна картина глубже штатных средств — трассировку ведут на уровне СУБД. Это инструмент администратора и DBA, не рядового пользователя.

Для Microsoft SQL Server:

• Extended Events — современный и лёгкий способ ловить запросы; трассу настраивают в SQL Server Management Studio.
• SQL Server Profiler — старый трассировщик, нагляднее, но тяжелее для нагруженной базы.
• SQL Server Audit / Change Data Capture — встроенный аудит и захват изменений по таблицам.

Для PostgreSQL — расширение pgAudit, параметр log_statement и триггеры.

Главная сложность: в СУБД имена таблиц и полей обезличены — вместо «РеализацияТоваровУслуг» вы увидите что-то вроде _Document123, вместо реквизитов — _Fld456. Сопоставить их с метаданными помогает встроенный метод ПолучитьСтруктуруХраненияБазыДанных() — он возвращает соответствие объектов метаданных именам таблиц и полей СУБД. Выгрузите это соответствие один раз и держите под рукой.

СУБД-уровень оправдан, когда нужно поймать источник непонятных изменений, которые не видны в журнале, или разобрать производительность конкретных операций. Для повседневного «кто поправил документ» это избыточно — хватает журнала и версий.

Технологический журнал и внешние системы мониторинга

Рядом с журналом регистрации платформа ведёт технологический журнал — низкоуровневый лог событий сервера: тексты запросов (DBMSSQL), обращения к данным (SDBL), исключения (EXCP), блокировки. Включается файлом logcfg.xml в каталоге conf платформы: в нём описывают, какие события и в какой каталог писать.

Технологический журнал — про диагностику производительности и ошибок, а не про бизнес-смысл «кто изменил контрагента». Но по тексту DBMSSQL можно восстановить, какой именно запрос на запись выполнился и из какого сеанса.

Для постоянного контроля несколько подходов:

• Мониторинг кластера через rac — утилита администрирования сервера показывает сеансы, соединения и блокировки в реальном времени (rac session list, rac cluster list). Полезно видеть, кто сейчас в базе и что держит.
• Внешние системы аудита и DLP — отдельные продукты класса SIEM/DLP собирают события из журналов 1С и сопоставляют с действиями на рабочих местах. Это уже корпоративный уровень, настраивается силами службы безопасности.
• Выгрузка журнала во внешнее хранилище — журнал периодически выгружают в файл и грузят в систему аналитики (см. следующий раздел).

Автоматический аудит регламентным заданием

Чтобы не ходить в журнал руками, аудит автоматизируют регламентным заданием на сервере. Логика простая: по расписанию прочитать свежие события журнала, отобрать подозрительные (удаления, изменения ключевых документов, работа в нерабочее время) и отправить ответственному письмо или уведомление.

Прочитать и выгрузить журнал из встроенного языка помогают методы:

• ВыгрузитьЖурналРегистрации(ИмяФайла, Отбор) — сохраняет отобранные события в XML-файл;
• чтение журнала с отбором по интервалу, пользователю и событиям — чтобы собрать нужные записи в таблицу значений и обработать.

Дальше задание формирует сводку и шлёт её — например, по электронной почте через штатную подсистему работы с почтой в БСП.

Под «подозрительными» обычно понимают конкретный набор признаков: удаление проведённых документов, изменение сумм в закрытом периоде, вход в базу ночью или в выходные, массовая правка от одного пользователя за короткое время. Зашейте в отбор именно их — тогда письмо приходит только по делу, а не на каждую рутинную запись.

Чтобы регламентные задания вообще выполнялись, в клиент-серверной базе они работают автоматически на сервере; в файловой базе их выполняет отдельный сеанс (например, запущенный клиент с модулем заданий). Проверьте, что расписание задания задано и оно не отключено.

Такой аудит не заменяет журнал и версии — он их «озвучивает»: превращает молчаливое накопление событий в активные сигналы, которые приходят сами.

Чек-лист: контроль изменений под ключ

Частые вопросы