При организации мониторинга информационной безопасности на предприятии специалисты по ИБ часто запрашивают прямой доступ к логам ИТ-систем. В случае с платформой 1С «Предприятие» это выливается в задачу подключить внешнее ПО (например, агенты SIEM-систем) напрямую к файлу журнала регистрации. Если ваша информационная база настроена на использование нового формата журнала регистрации SQLite (.lgd), такое прямое подключение на чтение может обернуться серьезными техническими проблемами для работающих пользователей.
В этой статье мы подробно разберем, почему одновременная запись сервером 1С и чтение сторонним процессом файла .lgd гарантированно приводят к коллизиям. Мы проанализируем архитектурные ограничения СУБД SQLite в контексте 1С и рассмотрим несколько надежных, проверенных на практике сценариев безопасной передачи логов сотрудникам ИБ.
Формат журнала регистрации на базе SQLite (файлы с расширением .lgd) появился в платформе 1С начиная с версии 8.3.5. Идея заключалась в том, чтобы предоставить разработчикам быстрый поиск по логам с использованием стандартных SQL-запросов. Однако на практике такое решение повлекло за собой существенные проблемы совместного доступа.
Проанализируем ключевые причины, почему нельзя давать стороннему ПО прямой доступ к активному файлу лога:
rphost) записывает событие в журнал, он накладывает блокировку на файл. Если в этот же момент сторонний софт (например, агент сбора логов) выполняет тяжелый запрос на чтение, он накладывает общую блокировку (SHARED lock). В результате процесс 1С не может повысить уровень своей блокировки до монопольной для совершения записи. Пользователи в этот момент увидят «песочные часы», а в логах сервера зафиксируются ошибки таймаута блокировок..lgd, транзакция в СУБД (MS SQL, PostgreSQL) остается открытой. Это лавинообразно вызывает блокировки на уровне всей СУБД, парализуя работу сотен пользователей..lgd с высокой долей вероятности повредится (ошибка database disk image is malformed). Восстановление многогигабайтного файла лога — трудоемкая процедура, которая далеко не всегда заканчивается успехом, что грозит полной потерей истории аудита за несколько лет.---
Это самый простой, надежный и рекомендуемый самой фирмой 1С способ решить проблему блокировок. Текстовый формат журнала регистрации (файлы с расширением .lgp) работает по принципу простого последовательного дописывания новых строк в конец файла. Операционная система позволяет другим процессам открывать такие файлы на чтение в режиме совместного доступа без накладывания жестких эксклюзивных блокировок на запись.
Для того чтобы перевести журнал регистрации в текстовый формат и настроить его правильную ротацию, выполним следующие шаги:
После применения настроек платформа создаст структуру каталогов, где каждый день (или неделю) будет формироваться новый файл с расширением .lgp. Это открывает отличную возможность для интеграции с ИБ:
---
Если ИБ-специалистам требуется мониторинг именно в реальном времени (Real-Time Monitoring) для оперативного реагирования в SIEM, лучшим архитектурным подходом будет связка «Текстовый формат ЖР + Log Shipper».
Разберем, как работает эта схема:
1Cv8Log внутри каталога описания базы данных)..lgp, осуществляет их парсинг, при необходимости структурирует в формат JSON и отправляет по сети в централизованное хранилище логов (например, Elasticsearch, OpenSearch, ClickHouse).---
Если перевод журнала регистрации в текстовый формат по каким-то причинам невозможен или ИБ-служба категорически требует передавать данные в структурированном виде из формата SQLite, мы можем организовать экспорт данных силами самой 1С. Для этого напишем регламентное задание, которое будет периодически выгружать новые записи во внешнюю базу данных (например, на MS SQL Server или ClickHouse).
Рассмотрим пример кода, который можно использовать в модуле регламентного задания. Мы будем использовать встроенный метод СкопироватьЖурналРегистрации(), который умеет эффективно отбирать записи за определенный период без риска нарушить целостность файлов лога:
Процедура ВыполнитьЭкспортЖурналаРегистрации() Экспорт
// Определяем период выгрузки (например, за последние 5 минут)
КонецПериода = ТекущаяДата();
НачалоПериода = КонецПериода - 300; // 5 минут в секундах
// Создаем структуру отбора для получения новых записей
ФильтрОтбора = Новый Структура;
ФильтрОтбора.Вставить("ДатаНачала", НачалоПериода);
ФильтрОтбора.Вставить("ДатаОкончания", КонецПериода);
// Определяем временную таблицу для выгрузки данных
ТаблицаЛогов = Новый ТаблицаЗначений;
// Копируем записи журнала во временную таблицу значений
СкопироватьЖурналРегистрации(ТаблицаЛогов, ФильтрОтбора);
Если ТаблицаЛогов.Количество() > 0 Тогда
// Вызываем процедуру записи полученных строк во внешнюю базу ИБ
ЗаписатьЛогиВоВнешнийИсточник(ТаблицаЛогов);
КонецЕсли;
КонецПроцедуры
В процедуре ЗаписатьЛогиВоВнешнийИсточник() разработчик может реализовать запись данных через ADO-соединение во внешнюю СУБД или отправку пакетов данных через REST API / HTTP-сервисы, развернутые на стороне службы информационной безопасности. Этот метод полностью безопасен, так как чтение лога выполняет сам рабочий процесс 1С, корректно управляя внутренними блокировками платформы.
---
Если требования к оперативности получения логов не жесткие (допускается задержка обновления данных раз в несколько часов или раз в сутки), оптимальным решением станет периодическое копирование активного файла лога. Однако просто скопировать файл .lgd средствами операционной системы в момент работы пользователей нельзя — файл будет заблокирован процессом 1С.
Для создания консистентной копии файла без остановки сервера 1С проанализируем следующий алгоритм:
.lgd во временную «песочницу», выделенную для ИБ-специалистов.При таком подходе ИБ-специалисты работают с точной, физически целостной копией базы SQLite, а рабочие процессы 1С не испытывают абсолютно никаких проблем с производительностью и блокировками.
Подводя итоги, дадим четкие рекомендации для администраторов 1С, к которым пришел менеджер по безопасности с требованием «подключиться к логам»:
.lgd (SQLite) на рабочей базе. Это неизбежно приведет к транзакционным ошибкам и зависанию сеансов у пользователей.