Журнал действий администраторов

Что умеет решение

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

Модуль «Журнал действий администраторов» отвечает точно: указывает конкретного пользователя, время действия, изменённое поле и его предыдущее значение.

РАЗНИЦА «БЫЛО — СТАЛО», А НЕ «ОБЪЕКТ ИЗМЕНЁН»

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

Сравнение выполняется корректно. Система Битрикс сохраняет объекты частями: в запросе передаются только изменённые поля. Поэтому модуль сравнивает именно пришедшие данные, а не полный снимок объекта. Иначе правка одного поля (например, названия) могла бы отразиться в журнале как восемь отдельных изменений, что сделало бы анализ бесполезным.

ВОЗВРАТ ОДНОГО ЗНАЧЕНИЯ

Рядом с каждым изменением доступна кнопка «Вернуть». Восстанавливается конкретное поле конкретной записи, а не состояние портала за вчерашний день. Полный откат объекта привёл бы к потере работы, выполненной другими пользователями после последнего изменения. Перед восстановлением модуль проверяет текущее значение поля: если оно было изменено повторно, система предупредит об этом, а не перезапишет данные без предупреждения. Факт возврата также фиксируется в журнале.

Семь областей аудита настраиваются независимо друг от друга. К ним относятся: контент инфоблоков (название, активность, тексты, раздел, символьный код); каталог (цены и остатки — данные, по которым чаще всего запрашивают информацию о том, кто изменил цену); заказы (статус, суммы, отмена, комментарии); пользователи; группы и права доступа; настройки модулей; вход в административный раздел.

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

Действия людей отделены от действий программных агентов. К каждому событию привязывается источник: административная панель, витрина, обмен с 1С, агент, консоль или REST. Обмен данными, агенты и консоль по умолчанию не записываются в журнал. В списке событий доступен фильтр «только люди». Без этой настройки ночной обмен, затрагивающий остатки всего каталога, за неделю заполнил бы журнал техническими записями, в которых невозможно найти действия человека. Учётную запись интеграции можно исключить из журнала отдельно.

Секретные данные в журнал не попадают.

Журнал действий администраторов (ozhogov.audit) автоматически скрывает чувствительные данные. Если имя поля содержит pass, token, key, secret, hash или другие слова из настраиваемого списка, значение заменяется точками до записи в базу. Это позволяет видеть факт изменения, но скрывает само значение. Журнал доступен более широкому кругу пользователей, чем настройки модулей, поэтому он не должен хранить пароли в открытом виде.

Уведомления о редких изменениях

Права доступа, настройки модулей и учётные записи изменяются осознанно и редко. Любое неожиданное изменение требует немедленного разбора, а не отложенного на конец квартала. Модуль группирует такие события и отправляет одно сводное письмо, а не отдельное сообщение на каждое действие. Это предотвращает потерю важной информации из-за потока писем, который возникает при частых уведомлениях.

Управление размером журнала

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

Уровни доступа

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

Ограничения функционала

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

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

Ограничения версии 1.0

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

Требования к системе

— 1С-Битрикс: Управление сайтом или Битрикс24 в коробке, главный модуль версии 20.0.0 и новее;

— PHP версии 8.2 и новее;

— MySQL 5.7+ / MariaDB 10.3+ либо PostgreSQL (для PostgreSQL требуется главный модуль версии 23.900.900 и новее);

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

— работающие агенты (рекомендуется запуск через cron): они обеспечивают очистку журнала и отправку уведомлений.

General iT может установить «Журнал действий администраторов», настроить параметры модуля и проверить его работу в существующем проекте.