Как обнаружить пользователя, удаляющего документы в 1С8.3, если Журнал регистрации чист?

Программист 1С v8.3 (Управляемые формы)
← На главную

Мы сталкиваемся с распространенной, но крайне неприятной ситуацией: в базе 1С8.3 эпизодически удаляются документы, а Журнал регистрации (ЖР) при этом остается чистым. Это может указывать на то, что злоумышленник отключает регистрацию событий, использует внешние обработки, запускаемые со своего компьютера, или имеет полные административные права, позволяющие обойти стандартные механизмы контроля. База опубликована, находится на полной поддержке, внешние отчеты и обработки не добавлены в конфигурацию, а пользователи работают через тонкий клиент по вебу. Наша задача — обнаружить виновника с поличным. Давайте разберем по шагам, какие действия мы можем предпринять для выявления и предотвращения несанкционированного удаления документов.

1. Пересмотр и ограничение прав пользователей

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

  1. Минимизация количества пользователей с полными правами: Мы должны значительно сократить число учетных записей, обладающих полными административными правами. Чем меньше таких пользователей, тем проще будет сузить круг подозреваемых. Идеальный вариант — оставить одну-две такие учетные записи для административных задач, а для остальных пользователей настроить максимально ограниченные права, соответствующие их должностным обязанностям.
  2. Отключение роли "Открытие внешних отчетов и обработок": Это критически важный шаг. Мы категорически рекомендуем полностью отключить роль Открытие внешних отчетов и обработок для всех пользователей, кроме тех, кому она действительно необходима (например, для запуска проверенных администратором служебных обработок). Запуск внешних обработок — это один из наиболее распространенных способов, позволяющих выполнять операции (в том числе удаление документов) без фиксации в стандартном Журнале регистрации.
  3. Периодическая смена паролей для административных учетных записей: Мы рекомендуем регулярно менять пароли для всех пользователей с полными правами. Это может помочь, если доступ злоумышленника основан на скомпрометированных учетных данных.

2. Анализ регламентных заданий

Мы не должны забывать о стандартных механизмах системы, которые могут выполнять действия по расписанию. Очень часто причиной "исчезновения" документов становится регламентное задание "Удаление помеченных объектов".

  1. Проверка настройки регламентного задания "Удаление помеченных объектов": Мы должны убедиться, что это регламентное задание не настроено на автоматическое удаление помеченных объектов без дополнительного подтверждения или в неподходящее время. Нередки случаи, когда пользователи просто помечают документы на удаление, вместо того чтобы отменять их проведение или изменять статус. Если это задание настроено на регулярный запуск, оно будет автоматически удалять все помеченные объекты, а виновным окажется пользователь, который их пометил.
  2. Обучение пользователей: Мы проведем инструктаж для пользователей о правильном обращении с пометкой на удаление и объясним последствия ее использования.

3. Реализация собственного логирования через расширение конфигурации

Поскольку Журнал регистрации "чист", нам потребуется создать собственный механизм логирования. Наиболее эффективным способом для этого будет использование расширения конфигурации.

  1. Создание расширения и подписки на событие "ПередУдалением": Мы создадим новое расширение конфигурации и добавим в него подписку на событие ПередУдалением для всех документов и других объектов, удаление которых мы хотим отслеживать (например, справочники). Это событие срабатывает непосредственно перед тем, как система удалит объект.
  2. Реализация записи в собственный регистр сведений или справочник: В обработчике события ПередУдалением мы реализуем запись детальной информации об удаляемом объекте в наш собственный регистр сведений или справочник. Такая информация может включать:
    • Вид удаляемого объекта (например, Документ.РеализацияТоваровУслуг).
    • Идентификатор объекта (Ссылка).
    • Представление объекта (ПредставлениеОбъекта).
    • Имя текущего пользователя (Пользователи.ТекущийПользователь() или ИмяТекущегоПользователя()).
    • Время события (ТекущаяДата()).
    • Рабочая станция пользователя (можно получить через ПолучитьЗначениеПараметра("ИмяКомпьютера"), если настроено).

    Для примера, создадим регистр сведений ЖурналУдаленияОбъектов с измерениями Пользователь (Справочник.Пользователи), ВидОбъекта (Строка), СсылкаОбъекта (Строка, для хранения UUID), ПредставлениеОбъекта (Строка) и ресурсом ДатаУдаления (Дата).

    Пример кода для модуля подписки на событие:

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

    Мы также можем усовершенствовать эту логику, чтобы фиксировать информацию о том, было ли удаление успешно (т.е., Отказ = Ложь).

  3. Обеспечение скрытности расширения: Оппонент справедливо заметил, что расширение можно увидеть и отключить в конфигураторе. Мы можем усложнить обнаружение и отключение нашего механизма. Например, мы можем создать расширение с большим количеством модулей, не связанных с логированием, и спрятать нужный функционал среди них. Также можно использовать неочевидные имена для объектов и процедур. Если конфигурация "на замке" и находится "на полной поддержке", то установка расширения администратором должна быть однократной, и обычные пользователи не смогут его отключить. Только пользователь с правами на изменение конфигурации сможет это сделать.

4. Мониторинг доступа к конфигуратору

Если Журнал регистрации чист, это может указывать на то, что злоумышленник имеет доступ к конфигуратору и может временно изменять код для отключения логирования или удаления документов напрямую, а затем возвращать изменения. Нам необходимо контролировать любой вход в конфигуратор.

  1. Логирование входов в конфигуратор: Мы можем реализовать механизм, который фиксирует каждый вход пользователя в режим конфигуратора. Для этого можно использовать обработчик события ПриНачалеРаботыСистемы в общем модуле или модуле сеанса, если мы можем добавить такой код. Однако, если конфигурация на полной поддержке и на замке, то добавление кода напрямую в конфигурацию невозможно. В этом случае мы можем попробовать использовать расширение для подписки на событие ПриНачалеРаботыСистемы, но его функциональность в расширении может быть ограничена для такого рода событий. Альтернативно, если есть доступ к серверу 1С, можно настроить логирование активности на уровне операционной системы или СУБД для отслеживания запуска процессов 1С с флагом запуска конфигуратора.
  2. Уведомления администратора: Мы можем настроить отправку уведомлений (например, на электронную почту) администратору при каждом входе в конфигуратор.
  3. Пример (если есть возможность модифицировать модуль сеанса или общий модуль, который запускается при старте системы):

    
    // В модуле сеанса или в общем модуле, который вызывается при старте
    Процедура ПриНачалеРаботыСистемы()
        Если Константы.РежимОтладки.Получить() Тогда // Пример условия для отладки
            Возврат;
        КонецЕсли;
    
        // Проверяем, запущен ли режим конфигуратора
        Если ОбщегоНазначения.ЭтоКонфигуратор() Тогда // Функция-обертка для проверки режима
            ИмяТекущегоПользователя = Пользователи.ТекущийПользователь().Наименование;
            Сообщение = "Пользователь '" + ИмяТекущегоПользователя + "' зашел в конфигуратор. Время: " + ТекущаяДата();
                
            // Запись в служебный регистр сведений или журнал сообщений
            // Можно также отправить по почте
            ЗаписатьВЖурналСобытий("ВходВКонфигуратор", Сообщение);
                
            // Отправка email (пример)
            // ОтправитьПисьмоАдминистратору("Вход в конфигуратор", Сообщение);
        КонецЕсли;
    КонецПроцедуры
    

    Примечание: функция ОбщегоНазначения.ЭтоКонфигуратор() не является стандартной. Её нужно реализовать самостоятельно или использовать НачатьПривилегированныйРежим() в связке с проверкой на наличие интерфейса конфигуратора, что сложнее и не всегда надежно. Более надежный способ – это отслеживать на уровне операционной системы или через службы сервера 1С.

5. Контроль опубликованных веб- и HTTP-сервисов

Поскольку база опубликована, и пользователи работают через веб-клиент, мы должны тщательно проверить все опубликованные веб-сервисы и HTTP-сервисы (если они используются).

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

6. Включение версионирования объектов

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

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

7. Регулярное резервное копирование

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

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

8. Проверка рабочих станций пользователей

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

  1. Аудит локальных компьютеров: Мы проведем проверку рабочих станций пользователей на наличие подозрительных утилит, скриптов или скомпилированных программ, которые могут взаимодействовать с 1С через COM-соединение или другие API.

9. Анализ удаляемых документов

Мы выясним, какие именно документы удаляются. Эта информация может дать нам важные подсказки о цели злоумышленника и, возможно, о используемом методе.

  1. Определение типа и характера удаляемых документов: Удаляются ли это специфические документы (например, только реализации или только приходные ордера)? Есть ли у них общие признаки? Это может навести нас на мысли о мотивации и круге лиц, заинтересованных в удалении именно этих данных.
  2. Связи удаляемых документов: Мы проанализируем, есть ли у удаляемых документов связи с другими объектами. Если документы удаляются "без связей", это может указывать на программный метод удаления, который игнорирует проверку ссылочной целостности, например, через метод Удалить() без предварительной проверки ссылок.

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

← На главную