Главное за минуту
- Путь к журналу обычно доступен в административной части: «Настройки» → «Проактивная защита» → «Журнал событий».
- В первую очередь включают авторизацию, ошибки входа, изменение пользователей и прав доступа.
- Лог не заменяет резервные копии и мониторинг: он отвечает на вопрос «кто и что сделал».
- При приемке проверяют тестовым действием, что запись содержит дату, пользователя, IP и тип события.
01
Когда журнал нужен маркетологу и владельцу сайта
Типовой сценарий из практики поддержки: после запуска акции пропала страница, а доступ к админке был у нескольких сотрудников и подрядчиков. Журнал событий не восстанавливает контент, но сужает поиск: показывает время действия, учетную запись, IP-адрес и описание операции.
Проверять его стоит после подозрительного входа, изменения прав, обновления, установки модуля или обращения «на сайте стало не так». Сначала фиксируют период и симптом, затем отбирают записи по пользователю, типу события и IP.
02
Путь к журналу
В типовой установке он находится в административной части, в разделе проактивной защиты.
03
Какие записи включить в первую очередь
Не нужно превращать журнал в бесконечный поток технических сообщений. Цель — сохранить следы действий, которые влияют на доступ, данные и работоспособность. Названия опций зависят от редакции, версии и подключенных модулей.
Доступ
Успешные и неуспешные входы, выходы, смена пароля, блокировки учетных записей.
Права
Создание и удаление пользователей, изменение групп и прав на административные разделы.
Защита
Срабатывания проактивной защиты, подозрительные запросы и блокировки по IP.
Доработки
Ошибки интеграций и критичные бизнес-события, добавленные разработчиком отдельно.
Стандартные записи не всегда покрывают изменения контента, цен или статусов заказа. Для таких операций разработчик должен явно добавить аудит через API журнала. Справка по механизму: документация 1С-Битрикс по журналу событий.
04
Минимальная политика событий для рабочего сайта
Начните с небольшого набора и расширяйте его после анализа инцидентов. Избыточный лог без ответственного быстро перестает быть полезным.
| Группа | Что фиксировать | Зачем |
|---|---|---|
| Авторизация | Входы, ошибки, смена пароля | Проверить доступ и подбор пароля |
| Пользователи | Создание, удаление, группы | Найти источник изменения прав |
| Защита | Атаки, блокировки, IP | Разобрать подозрительную активность |
| Бизнес-операции | Публикация, заказ, обмен с CRM | Требует отдельной доработки |
05
Не путайте журнал событий с другими логами
Журнал безопасности хранит аудит действий. Логи PHP, веб-сервера и интеграции нужны для поиска технической причины ошибки. В заявке на поддержку сразу укажите время сбоя, URL, пользователя и идентификатор записи из журнала.
Одна запись журнала — это повод для проверки, а не доказательство причины сбоя без сопоставления с серверными и CRM-логами.
Готовое сообщение
Готовая формулировка задачи подрядчику
Цель: настроить аудит действий в административной части сайта на 1С-Битрикс.
События: успешный и неуспешный вход, смена пароля, создание и удаление пользователей, изменение групп и прав, срабатывания защиты.
Дополнительно: оценить, какие критичные операции сайта не попадают в стандартный журнал, и предложить события для доработки.
Критерии приемки: после тестового неверного входа и изменения группы пользователя в журнале есть дата, пользователь или логин, IP, тип и понятное описание действия.
06
Как принять настройку за 15 минут
Попросите исполнителя не только включить опции, но и показать результат на тестовых действиях под отдельной учетной записью.
- 1
Проверьте доступ. Откройте журнал под ролью, которая отвечает за администрирование, но не выдавайте этот доступ всем редакторам.
- 2
Сделайте ошибку входа. Введите неверный пароль тестового пользователя и найдите соответствующую запись по времени.
- 3
Измените права. Временно поменяйте группу тестовой учетной записи и убедитесь, что действие зафиксировано.
- 4
Проверьте поля. В записи должны читаться дата, источник, пользователь, IP и описание — без необходимости смотреть код.
- 5
Согласуйте регламент. Назначьте ответственного и период проверки, например после обновлений и инцидентов.
07
Риски, которые часто остаются незамеченными
Сам факт включенного журнала не делает сайт управляемым. Критичнее ограничить круг администраторов и заранее определить, какие данные не должны попадать в записи.
Не логируйте секреты
В описания событий не должны попадать пароли, токены API, данные банковских карт и полные персональные данные. Для интеграций фиксируйте идентификатор операции и код ошибки, а не содержимое секретных полей.
08
Когда нужна доработка, а не настройка
Обращайтесь к разработчику, если нужно видеть в аудите изменения конкретных полей инфоблока, статусов заказа, цен, UTM или обмена с CRM. Такие события обычно проектируют отдельно: определяют объект, пользователя, старое и новое значение, а также срок хранения.
Проверить доступ к административной части; включить события авторизации и прав; ограничить просмотр журнала; провести два тестовых действия; назначить ответственного; не хранить в логах пароли и токены.
FAQ
Частые вопросы
Почему журнал событий пустой?
Проверьте, установлен ли и активен ли модуль безопасности, включены ли нужные типы записей и верно ли выбран период фильтра.
Можно ли удалить записи из журнала?
Технически это зависит от прав и настроек. Для расследований важнее заранее определить срок хранения и ограничить доступ к удалению.
Фиксирует ли журнал изменение каждой страницы?
Не обязательно. Аудит контента зависит от стандартных настроек и доработок проекта; критичные операции лучше описать отдельно.
Поможет ли журнал понять, почему не пришла заявка в CRM?
Он покажет часть действий на сайте, но причину нужно сопоставлять с логами формы, HTTP-запроса и CRM-интеграции.
