Регистрирует ли журнал регистрации 1С выгрузку и загрузку информационной базы?

← На главную

Вопросы безопасности данных и контроля за действиями администраторов всегда стоят на первом месте в любой организации, использующей решения на платформе 1С:Предприятие. Одним из наиболее частых вопросов, вызывающих споры среди специалистов, является следующий: фиксирует ли штатный журнал регистрации (ЖР) операции по выгрузке и загрузке информационной базы через файлы .dt? И что происходит с накопленной историей логов, когда в систему загружается резервная копия?

В рамках этой статьи мы подробно разберем внутреннее устройство журнала регистрации, проанализируем поведение платформы при выполнении административных процедур и рассмотрим альтернативные методы контроля безопасности, которые помогут вовремя обнаружить несанкционированное копирование конфиденциальных данных.

Особенности физического хранения журнала регистрации

Чтобы понять, почему платформа ведет себя определенным образом во время резервного копирования, нам необходимо разобраться в архитектуре хранения данных. Начнем с ключевого факта: журнал регистрации физически не хранится внутри самой базы данных 1С.

Независимо от того, используете ли вы файловый вариант работы или клиент-серверный вариант под управлением СУБД (MS SQL, PostgreSQL, Oracle Database, IBM DB2), файлы журнала регистрации всегда располагаются обособленно:

В файловом варианте: Все логи хранятся в специальном каталоге 1Cv8Log, который находится внутри папки с самой информационной базой (рядом с основным файлом базы данных 1Cv8.1CD).
В клиент-серверном варианте: Файлы логов располагаются на сервере приложений «1С:Предприятие» в каталоге служебных файлов (по умолчанию это папка srvinfo). Они привязаны к уникальному идентификатору (GUID) конкретной информационной базы.

Начиная с версии платформы 8.3.5, основным и наиболее производительным форматом хранения журнала регистрации является формат базы данных SQLite. Файлы этого формата имеют расширение .lgd. В более старых версиях платформы логи сохранялись в виде последовательного набора текстовых файлов с расширениями .lgp или .lgf, разделенных по временным периодам.

Поскольку журнал регистрации вынесен за рамки основного хранилища данных, при выполнении стандартной операции «Выгрузить информационную базу» в создаваемый файл резервной копии (.dt) упаковываются исключительно метаданные конфигурации и сами прикладные данные. Файлы журнала регистрации из каталога 1Cv8Log в этот архив не попадают. Это фундаментальное свойство архитектуры платформы, которое необходимо учитывать при организации резервного копирования.

Фиксируются ли операции выгрузки и загрузки в самом журнале регистрации?

Давайте обратимся к возможностям встроенного языка и возможностям настройки системы. Если мы откроем встроенный Синтаксис-помощник (СП) и проанализируем доступные системные события, которые платформа способна регистрировать, мы увидим метод ВыгрузитьЖурналРегистрации() и перечисление системных событий.

Проанализировав состав системных событий, мы вынуждены констатировать: прямых системных событий для фиксации выгрузки или загрузки информационной базы в платформе 1С не существует. То есть запись вида «Пользователь Администратор выгрузил базу данных в файл» в журнале регистрации не появится.

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

Запуск и закрытие сеанса Конфигуратора. Любая интерактивная выгрузка или загрузка данных требует запуска Конфигуратора. В журнале регистрации обязательно останутся записи о начале сеанса и его завершении с типом приложения Конфигуратор. Если база выгружается в нерабочее время или пользователем, которому это не положено по должностным обязанностям, сам факт открытия Конфигуратора должен вызвать подозрения.
Изменение конфигурации. Если выполняется загрузка файла .dt, который был получен из базы с измененной конфигурацией (даже при незначительном отличии версий), платформа зафиксирует события Информационная база. Изменение конфигурации и Изменение конфигурации базы данных.
Блокировка работы с внешними ресурсами. При первом запуске информационной базы после ее загрузки из файла резервной копии (или при ее перемещении) платформа 1С распознает изменение окружения. Пользователю будет задан вопрос: «Информационная база перемещена или восстановлена из копии?». Если пользователь отвечает, что это копия, система автоматически блокирует регламентные задания, отправку почты и интеграцию с внешними сервисами. Это действие незамедлительно фиксируется в журнале регистрации событием Работа с внешними ресурсами заблокирована.

Таким образом, хотя прямого лога о выгрузке нет, совокупность записей о коротком сеансе Конфигуратора без проведения прикладных документов косвенно указывает на то, что производилось резервное копирование или выгрузка схемы метаданных.

Что происходит с журналом регистрации при загрузке новой базы?

Среди начинающих специалистов и администраторов 1С бытует устойчивое заблуждение, что при загрузке файла .dt старый журнал регистрации полностью удаляется или затирается. Давайте выясним реальное положение дел.

Согласно официальной технической документации фирмы 1С, при загрузке информационной базы из файла журнал регистрации не очищается. Однако на практике результат операции будет зависеть от режима работы вашей базы данных:

Поведение в клиент-серверном варианте (SQL)

При загрузке файла .dt в существующую базу на сервере 1С:Предприятия происходит перезапись таблиц внутри СУБД. При этом уникальный идентификатор базы (GUID) на уровне кластера серверов 1С остается неизменным. Сервер приложений продолжает использовать ту же самую папку srvinfo и тот же самый файл 1Cv8.lgd для записи логов. Соответственно, вся история журнала регистрации полностью сохраняется, а новые события просто дописываются в конец существующего файла лога.

Поведение в файловом варианте

Здесь возможно два сценария развития событий:

Сценарий А (Загрузка в существующую папку): Вы открываете существующую файловую базу в Конфигураторе и выбираете пункт меню «Восстановить информационную базу». Платформа заменяет файл базы данных 1Cv8.1CD, но каталог 1Cv8Log с файлами журнала регистрации остается нетронутым. В этом случае история логов сохраняется.
Сценарий Б (Загрузка в чистую папку): Вы создаете на диске абсолютно новую пустую папку, регистрируете её в стартере 1С, заходите в пустой Конфигуратор и загружаете туда .dt. Поскольку база создана с нуля, в этой папке изначально отсутствовал каталог 1Cv8Log. Платформа создаст его автоматически при первом обращении, и логирование начнется «с чистого листа».

Также важно отметить интересную особенность: хотя сами записи логов в файл .dt не переносятся, настройки формата журнала регистрации (например, выбор между последовательным форматом и форматом SQLite) хранятся в метаданных конфигурации. Соответственно, при загрузке .dt в новую пустую базу формат ведения логов автоматически изменится на тот, который был установлен в базе-источнике.

Как обеспечить надежный аудит и защититься от утечки данных?

Поскольку стандартный журнал регистрации бессилен против прямого копирования файла базы данных (1Cv8.1CD) силами операционной системы или создания бэкапов напрямую средствами СУБД (например, через SQL Server Management Studio), администраторам безопасности требуется внедрять дополнительные контуры контроля.

Давайте подробно рассмотрим эффективные инструменты контроля доступа:

1. Настройка Технологического журнала (ТЖ) 1С

Технологический журнал — это мощнейший низкоуровневый инструмент платформы «1С:Предприятие». Он позволяет фиксировать абсолютно все события, происходящие на уровне платформы, включая детальные действия конфигуратора, запуск конкретных исполняемых файлов и сетевую активность.

Для настройки ТЖ необходимо создать файл конфигурации logcfg.xml и поместить его в каталог установки платформы (в папку conf). Проанализируем пример такой настройки, которая будет фиксировать любые сессии работы с базой данных:


<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\v8logs\configurator_events" history="168">
        <event>
            <eq property="Name" value="CONF"/>
        </event>
        <property name="All"/>
    </log>
</config>

В данном примере конфигурационный файл приказывает платформе собирать все события категории CONF (действия Конфигуратора) и сохранять их в каталог C:\v8logs\configurator_events с глубиной хранения архива в 168 часов (7 дней). ТЖ записывает информацию на уровне операционной системы напрямую, обойти его стандартными средствами 1С невозможно.

2. Аудит действий на уровне СУБД

Если ваша база данных развернута в клиент-серверном варианте, обязательно настройте внутренний аудит на стороне сервера баз данных. Например, в Microsoft SQL Server вы можете создать правила аудита (SQL Server Audit), которые будут отслеживать попытки резервного копирования базы данных (команда BACKUP DATABASE) или экспорт таблиц.

Аналогичные политики мониторинга доступа к файлам табличного пространства необходимо настроить и для СУБД PostgreSQL.

3. Ограничение прав доступа в операционной системе

Самый простой способ «слямзить» базу данных — это банальное копирование файла 1Cv8.1CD на флешку или сетевой диск. Чтобы предотвратить этот сценарий в файловом варианте работы:

Ни в коем случае не предоставляйте конечным пользователям прямой доступ к каталогу, в котором лежит файл базы данных.
Для работы пользователей организуйте терминальный доступ (RDP) или публикуйте базу на веб-сервере (IIS / Apache) для работы через тонкий или веб-клиент. При публикации через веб-сервер пользователи вообще не имеют физического доступа к файлу базы, а работают исключительно по протоколу HTTP/HTTPS.
В клиент-серверном варианте ограничьте круг лиц, имеющих доступ к серверу СУБД и серверу приложений 1С. Доступ к рабочим каталогам сервера должен быть разрешен исключительно служебной учетной записи, от имени которой запущены службы 1С и СУБД.

Программный контроль выгрузки журнала регистрации

Если вам все же необходимо автоматизировать выгрузку логов для их последующего анализа во внешних системах мониторинга (например, в SIEM-системах), мы можем воспользоваться программными возможностями платформы. Разберем пример кода на встроенном языке 1С, который позволяет экспортировать события журнала регистрации по определенному фильтру:


// Создадим структуру для фильтрации событий лога
ПараметрыОтбора = Новый Структура;
ПараметрыОтбора.Вставить("ИмяПриложения", "Конфигуратор");

// Определим путь, куда будет сохранен выгруженный файл лога
ПутьКФайлуВыгрузки = "C:\temp\log_configurator.xml";

Попытка
    // Выполняем экспорт событий журнала регистрации во внешний XML-файл
    ВыгрузитьЖурналРегистрации(ПутьКФайлуВыгрузки, ПараметрыОтбора);
    Сообщить("Выгрузка журнала регистрации успешно завершена.");
Исключение
    Сообщить("Не удалось выгрузить журнал регистрации: " + ОписаниеОшибки());
КонецПопытки;

С помощью метода ВыгрузитьЖурналРегистрации мы можем регулярно выгружать события работы в Конфигураторе во внешние файлы, чтобы затем анализировать их специализированным защитным ПО на предмет подозрительной активности.

Резюмируя, отметим: штатный журнал регистрации 1С является хорошим инструментом для разбора пользовательских ошибок в бизнес-логике, но не может служить единственным барьером информационной безопасности. Для надежной защиты конфиденциальных баз данных всегда комбинируйте настройки прав доступа операционной системы, ведение технологического журнала 1С и аудит на уровне СУБД.