В практике администрирования и поддержки баз данных на платформе 1С:Предприятие 7.7 иногда возникают загадочные ситуации, когда критически важные действия пользователей не отражаются в журнале регистрации (ЖР). Одной из наиболее частых проблем является отсутствие записи о пометке документа на удаление (например, Расходного кассового ордера — РКО). На первый взгляд это кажется невозможным, ведь платформа должна фиксировать любые изменения объектов метаданных.
В рамках данной статьи мы подробно разберем технические причины, по которым пометка на удаление могла «проскочить» мимо стандартного лога платформы, проанализируем архитектурные особенности ЖР в 1С 7.7 и рассмотрим практические методы защиты базы данных от скрытых манипуляций.
Если пометка на удаление была установлена программным путем, поведение платформы зависит от того, каким именно методом воспользовался разработчик. Рассмотрим два сценария:
Сценарий А: Использование метода Удалить(0)
При вызове стандартного метода Документ.Удалить(0) (где параметр 0 означает именно установку пометки на удаление, в отличие от непосредственного удаления при значении 1), платформа обязана инициировать стандартную запись в файл журнала регистрации. Однако, если данный код выполняется внутри транзакции, которая по каким-то причинам завершилась аварийно или была принудительно отменена инструкцией ОтменитьТранзакцию(), может возникнуть рассинхронизация. В некоторых случаях запись в лог-файл 1cv7.mlg не успевает физически зафиксироваться или откатывается самой операционной системой, хотя в СУБД (особенно при работе на SQL) транзакционные механизмы отрабатывают иначе.
Сценарий Б: Модификация реквизита через внешнюю обработку
Достаточно квалифицированный пользователь или программист может запустить внешнюю обработку через меню Файл -> Открыть. Если в этой обработке напрямую изменяется признак пометки на удаление (например, через прямое перестроение табличной части или обход стандартных процедур записи объекта), событие в ЖР может записаться не как специфическое действие «Пометка на удаление», а как рядовое изменение данных.
Это один из самых распространенных способов обхода бизнес-логики платформы 1С 7.7. Если база данных развернута на Microsoft SQL Server или используется файловый вариант (DBF), злоумышленник или сторонняя утилита могут внести изменения в таблицы СУБД напрямую, минуя сервер приложений 1С.
При прямом SQL-запросе к таблице журнала документов _1SJourn обновляется флаг пометки удаления ISMARK. Запрос выглядит следующим образом:
UPDATE _1SJourn
SET ISMARK = 1
WHERE IDDOC = :ВыбДокумент
Поскольку этот запрос выполняется непосредственно на уровне СУБД SQL Server, ядро платформы 1С:Предприятие 7.7 вообще не задействуется в обработке этой транзакции. Как результат, в файле 1cv7.mlg не появляется абсолютно никаких записей об изменении документа. Аналогичный результат достигается в файловой версии при редактировании таблицы 1sjourn.dbf через любой DBF-редактор (например, DBF Navigator или Excel).
Не стоит забывать, что журнал регистрации в 1С 7.7 — это обычный текстовый файл с именем 1cv7.mlg, расположенный в каталоге базы данных по пути ...\SYSLOG\1cv7.mlg. Он имеет крайне простую структуру, где каждое событие занимает ровно одну строку. Любой пользователь, имеющий доступ к каталогу базы данных на уровне операционной системы Windows, может совершить следующие действия:
1cv7.mlg в обычном Блокноте (Notepad) или текстовом редакторе Notepad++.DocMarkDel).1cv7.mlg во временное имя, заходит в базу данных под своей учетной записью, совершает несанкционированные действия (помечает документ на удаление), выходит из базы, удаляет созданный заново лог-файл и возвращает старому файлу исходное имя 1cv7.mlg.Иногда отсутствие записи является следствием невнимательности администратора или технических сбоев операционной системы:
1cv7.mlg очень быстро разрастается в активно работающих базах. При достижении размера файла лога критического объема (около 2 гигабайт) или при исчерпании свободного места на жестком диске сервера, операционная система блокирует запись новых строк в текстовый файл. При этом сама база данных продолжает функционировать без видимых ошибок, транзакции проходят, но новые события в ЖР «тихо» игнорируются.DocMarkDel. Однако стандартная обработка просмотра лога в режиме «1С:Предприятие» отображает это событие под общим заголовком «Данные -> Изменение». Если администратор при анализе накладывал строгий фильтр исключительно по ключевым словам или ожидал увидеть отдельный статус «Пометка на удаление», он мог просто пропустить нужную строку.Если на предприятии развернута распределенная информационная база (УРИБ), появление и исчезновение пометок на удаление подчиняется особым правилам обмена:
Если документ был помечен на удаление в периферийной базе, а затем эти изменения мигрировали в центральную базу через автообмен, то автором изменения в ЖР центральной базы будет значиться не тот пользователь, который физически нажал кнопку удаления в филиале, а учетная запись, под которой был запущен сеанс загрузки данных (например, «Администратор» или «Обмен»). Если администратор ищет событие по конкретному имени реального сотрудника в центральном журнале, он его не найдет.
Для предотвращения несанкционированных действий пользователей через внешние обработки (запускаемые через меню Файл -> Открыть), мы можем использовать внешнюю компоненту FormEx (или комплексную библиотеку 1С++), которая позволяет перехватывать системные события платформы.
Разберем по шагам, как настроить отслеживание запуска внешних отчетов и обработок в глобальном модуле конфигурации:
Шаг 1. Подключение компоненты
В процедуре ПриНачалеРаботыСистемы() глобального модуля необходимо инициализировать загрузку внешних компонент:
Процедура ПриНачалеРаботыСистемы()
// Загружаем внешнюю компоненту FormEx для расширения возможностей работы с формами
Если ЗагрузитьВнешнююКомпоненту("FormEx.dll") <> 1 Тогда
Предупреждение("Компонента FormEx не загружена! Некоторые функции будут недоступны.");
КонецЕсли;
КонецПроцедуры
Шаг 2. Использование предопределенной процедуры FormEx
После успешной загрузки компоненты FormEx нам становится доступна предопределенная процедура ПриЗагрузкеВнешнегоОтчета(), которую мы размещаем в Глобальном модуле нашей конфигурации. Она перехватывает попытку открытия любого файла .ert:
Процедура ПриЗагрузкеВнешнегоОтчета(ПутьКФайлу)
// Данная процедура вызывается автоматически при попытке загрузить внешний отчет/обработку
// Параметр "ПутьКФайлу" содержит полный путь к запускаемому файлу
ИмяПользователяТекущее = ИмяПользователя();
// Записываем событие в системный Журнал Регистрации программно
ЗаписьЖурналаРегистрации("Запуск внешней обработки: " + ПутьКФайлу, "ВнешниеОбработки", "Внимание", , 3);
// При необходимости можно ограничить запуск внешних обработок для определенных пользователей:
Если (ИмяПользователяТекущее <> "Администратор") И (Найти(Врег(ПутьКФайлу), "C:\APPROVED_REPORTS\") = 0) Тогда
Предупреждение("У вас нет прав на запуск внешних обработок из произвольных каталогов!");
СтатусВозврата(0); // Отменяем загрузку внешнего файла
Возврат;
КонецЕсли;
КонецПроцедуры
Благодаря этому несложному алгоритму, любая попытка открыть сторонний файл конфигурации будет не только гарантированно зафиксирована в журнале регистрации с указанием точного сетевого пути к файлу обработки, но и может быть заблокирована системой безопасности, если пользователь не обладает правами администратора.
Мы проанализировали основные уязвимости платформы 1С 7.7, приводящие к отсутствию записей в ЖР при пометке документов на удаление. Для обеспечения максимальной безопасности вашей учетной системы мы рекомендуем ограничить права пользователей на запуск внешних отчетов, настроить регулярную архивацию и усечение файла 1cv7.mlg, исключить прямой доступ пользователей к физическим файлам базы данных (DBF/SQL) на уровне операционной системы, а также внедрить механизмы логирования с использованием компоненты FormEx.