Утром вы обнаруживаете, что на десятке ходовых товаров цена «съехала» вдвое, а один заказ на крупную сумму отменён. Кто это сделал — обмен с 1С, ошибка менеджера или недобросовестный сотрудник? Если в магазине не настроен аудит, ответа нет: вы правите цены обратно и живёте с ощущением, что это повторится. Логи и аудит действий превращают такие ситуации из детектива в пятиминутный разбор по журналу.
В этой статье разберём, как выстроить логирование и аудит действий сотрудников в админке магазина на 1С-Битрикс: что фиксируется штатно, как логировать изменения цен, остатков и заказов через обработчики событий, как хранить и защищать журнал и как быстро расследовать инциденты. Тема тесно связана с чистотой данных и обменом, поэтому затронем и аудит и оптимизацию 1С.
Коротко
- Аудит — это контроль постфактум: кто, что и когда изменил; он дополняет права доступа, а не заменяет их.
- Штатный журнал событий 1С-Битрикс закрывает безопасность и входы, но товарный и заказной контур логируют отдельно.
- Изменения цен, остатков и заказов пишут через обработчики событий D7 со старым и новым значением.
- Логи хранят отдельно, защищают от подчистки и настраивают уведомления по критичным действиям.
Зачем магазину аудит действий
Чем больше людей работает в админке, тем выше цена ошибки и злоупотребления. Контент-менеджеры правят карточки, менеджеры меняют статусы заказов и дают скидки, кладовщик корректирует остатки, подрядчик заходит «посмотреть». В такой среде рано или поздно случается инцидент — и вопрос лишь в том, сможете ли вы его расследовать.
Аудит решает три задачи бизнеса: разбор инцидентов (кто сломал цену или отменил заказ), дисциплина (сотрудники аккуратнее, зная, что действия фиксируются) и доказуемость (при споре с сотрудником или контрагентом есть объективная история). Это не про недоверие к людям, а про управляемость: без журнала любой сбой превращается в догадки.
Что штатно логирует 1С-Битрикс
Часть событий 1С-Битрикс фиксирует из коробки, и с этого стоит начать, прежде чем городить своё.
- Журнал событий. Входы и выходы пользователей, неудачные авторизации, изменения в модулях, ошибки.
- Проактивная защита. Подозрительная активность, срабатывания веб-антивируса и фильтра, события безопасности.
- Журнал вторжений. В старших редакциях — попытки атак и аномальные запросы.
- Логи веб-сервера и PHP. Технический уровень: ошибки, медленные запросы, доступ.
Этого достаточно для безопасности и входов, но не для бизнес-контура. Штатный журнал не скажет, что менеджер Иванов вчера в 14:20 поменял цену товара с 1000 на 500 рублей — такую детализацию по товарам, заказам и остаткам обычно настраивают отдельно.
Логи против прав доступа
Важно не путать два разных инструмента защиты. Они работают в паре, но по-разному.
| Аспект | Права доступа | Логи и аудит |
|---|---|---|
| Когда работает | До действия (профилактика) | После действия (контроль) |
| Что делает | Не даёт сделать лишнее | Фиксирует, что сделано |
| От кого защищает | От тех, кому не положено | В том числе от тех, кому положено |
| Механизм | Группы пользователей, уровни доступа | Журнал событий, обработчики |
| Пример | Кладовщик не видит цены закупки | Кто и когда изменил цену продажи |
Правильный порядок такой: сначала настроить минимально необходимые права по группам пользователей (принцип наименьших привилегий), а поверх — аудит легитимных, но рискованных действий. Права закрывают «нельзя», аудит контролирует «можно, но под запись».
Какие события логировать
Логировать всё подряд — плохая идея: журнал раздувается и его никто не читает. Фиксируйте бизнес-значимые действия, где ошибка или злоупотребление дорого стоят.
- Изменение цен и скидок. Цены товаров, торговых предложений, персональные и групповые скидки.
- Действия с заказами. Смена статуса, отмена, изменение состава и суммы, возвраты.
- Изменение остатков. Ручные корректировки складских количеств.
- Управление доступом. Создание пользователей, смена групп и прав, сброс паролей.
- Выгрузки данных. Экспорт клиентской базы, заказов, прайсов — самое чувствительное.
- Удаление объектов. Товаров, разделов, заказов, пользователей.
Как логировать изменения цен и заказов
Технически предметный аудит в 1С-Битрикс строят на обработчиках событий D7-ядра. На события изменения бизнес-объектов вешают обработчик, который пишет запись в отдельную таблицу аудита.
- Определите точки съёма. События обновления элемента инфоблока (товара), торгового предложения, цены, заказа и его статусов.
- Снимите старое значение. До сохранения зафиксируйте прежнее значение, чтобы записать «было → стало».
- Соберите контекст. Идентификатор пользователя, время, IP, тип действия, объект.
- Запишите в отдельную таблицу. Собственная сущность аудита, не связанная с боевыми таблицами.
- Не блокируйте основной поток. Запись должна быть лёгкой, тяжёлую обработку выносят в фон или на агент.
Регистрация обработчиков и работа с сущностями — это стандартная практика D7. Механику ORM и событий мы подробно разбирали в статье про D7 ORM в Битрикс, а вынос собственной логики в переносимый модуль — в материале про разработку модуля Битрикс.
Структура записи аудита
Ценность лога определяется тем, насколько по нему удобно расследовать. Хорошая запись отвечает на все вопросы сразу.
Отдельно стоит помечать источник изменения: сделал его человек в админке или оно пришло обменом из 1С. Эта пометка бесценна при разборе инцидентов интеграции — она сразу отсекает половину гипотез.
Хранение, ротация и защита логов
Лог, который можно незаметно подчистить, бесполезен — недобросовестный сотрудник просто удалит свои следы. Поэтому к хранению есть требования:
- Отдельное хранилище. Аудит хранят обособленно от боевых данных, в идеале с ограниченным доступом на запись.
- Защита от изменения. Рядовые сотрудники не должны иметь прав редактировать или чистить журнал.
- Ротация технических логов. Объёмные веб-логи ротируют и архивируют, чтобы не забить диск.
- Дольше хранить критичное. Бизнес-события (цены, заказы, доступы) держат дольше, чем технический шум.
Где именно и как хранить логи, зависит от инфраструктуры проекта. Особенности размещения, дисков и ротации на типовом стеке мы описывали в материале про инфраструктуру и BitrixVM.
Уведомления по критичным событиям
Аудит работает вдвойне, когда о самых опасных действиях вы узнаёте сразу, а не при разборе через месяц. Настройте алерты по событиям высокого риска:
- Массовое изменение цен. Правка десятков позиций за короткое время — повод для мгновенного уведомления.
- Выгрузка клиентской базы. Экспорт контактов — самое чувствительное действие, о нём стоит знать всегда.
- Изменение прав доступа. Новый администратор или расширение прав сотрудника.
- Отмена крупных заказов. Отмена или изменение заказа выше порога суммы.
Уведомления доставляют в почту, мессенджер или во внешнюю систему через вебхуки. Как делать такие исходящие вызовы безопасно и без задвоений, мы разбирали в статье про REST, вебхуки и безопасность в Битрикс.
Аудит и обмен с 1С
Отдельная большая польза аудита — разбор инцидентов интеграции. При обмене с 1С в магазин приходят цены, остатки, заказы и статусы; на сайте они же меняются вручную. Когда данные «поехали», без аудита невозможно понять, виноват обмен или человек.
Если каждое изменение помечено источником, разбор становится тривиальным: видно, что цена обнулилась именно во время выгрузки, а не по вине менеджера, — значит, проблема в маппинге обмена. Такой аудит удобно проектировать вместе с настройкой интеграции: он окупается на первом же спорном инциденте. Наведение порядка в обмене и данных — это автоматизация на 1С и профильный аудит систем.
Расследование инцидентов по логам
Когда журнал есть и структурирован, расследование инцидента становится коротким и предсказуемым:
- Зафиксируйте симптом. Что именно не так: цена, остаток, статус заказа, пропавший объект.
- Отфильтруйте по объекту и времени. Найдите записи по конкретному товару или заказу за нужный период.
- Определите источник. Человек или обмен; если человек — какой пользователь и с какого IP.
- Восстановите значение. По записи «было → стало» верните корректные данные.
- Устраните причину. Ошибка процесса — доработайте регламент; злоупотребление — ограничьте права; сбой обмена — почините маппинг.
Частые ошибки
- Аудита нет вовсе. Инциденты расследуются вслепую, злоупотребления остаются безнаказанными.
- Логируют всё подряд. Журнал раздувается, важное тонет в шуме, никто им не пользуется.
- Нет старого значения. Запись «цена изменена» без «было → стало» почти бесполезна.
- Логи может чистить любой. Недобросовестный сотрудник заметает следы, аудит теряет смысл.
- Нет пометки источника. Непонятно, изменил человек или обмен, разбор интеграции буксует.
- Нет уведомлений. О выгрузке базы или обвале цен узнают спустя недели.
- Логи убивают производительность. Синхронная тяжёлая запись без индексов и ротации тормозит боевую базу.
Чек-лист внедрения
- Права настроены. Минимально необходимые доступы по группам пользователей, принцип наименьших привилегий.
- Штатный журнал включён. Журнал событий и проактивная защита работают и просматриваются.
- Бизнес-события логируются. Цены, заказы, остатки, доступы и выгрузки пишутся через обработчики.
- Запись полная. Кто, что, было → стало, когда, откуда и источник (человек/обмен).
- Логи защищены. Отдельное хранилище, рядовые сотрудники не могут их чистить.
- Ротация настроена. Технические логи архивируются, критичные хранятся дольше.
- Алерты работают. Уведомления по массовым изменениям цен, выгрузкам базы и правкам доступа.
- Доступ к аудиту ограничен. Журнал видят только владелец, руководитель и ответственный за безопасность.
Вывод
Логи и аудит — это управляемость магазина. Права доступа не дают сделать лишнее, но не защищают от ошибок и злоупотреблений тех, у кого доступ есть. Аудит закрывает этот разрыв: он фиксирует, кто, что и когда изменил, со старым и новым значением и пометкой источника.
Начните с включения штатного журнала и настройки прав, затем добавьте предметный аудит бизнес-объектов через обработчики событий, защитите журнал от подчистки и настройте алерты по критичным действиям. Тогда любой инцидент — от съехавшей цены до слитой базы — будет разбираться за минуты, а не превращаться в детектив без улик.
