Зачем коробке отдельный разговор про логирование
Коробочный Битрикс24 стоит на вашем сервере. В этом и заключается разница с облаком: если завтра возникнет вопрос «кто вчера в 23:40 выгрузил базу контактов в Excel», ответ придётся искать самим. Вендор в эту историю не вмешивается, потому что физически не имеет доступа к вашим данным.
История, которая повторяется у клиентов с завидной регулярностью. Менеджер увольняется, через месяц у конкурента начинают звонить вашим клиентам с точным знанием сумм и сроков. Собственник просит поднять логи. Администратор открывает журнал событий, а там пусто: по умолчанию срок хранения записей семь дней, и половина типов событий вообще не записывается. Система логирование умеет, но восстанавливать картину уже нечем.
Логирование действий в Битрикс24 нужно не столько для слежки за сотрудниками, сколько для трёх вполне прикладных вещей. Расследовать инцидент постфактум. Проверить претензию, в том числе претензию к самому подрядчику. Заметить странность до того, как она превратится в потерю. Аудит пользователей в CRM на коробке устроен не одной кнопкой, а несколькими независимыми механизмами, у каждого из которых свои настройки.
Пять журналов, которые живут отдельно друг от друга
Единого «журнала всего» в коробке нет. Есть набор подсистем, и они не связаны между собой ни интерфейсом, ни настройками, ни сроком хранения.
- Журнал событий главного модуля отвечает за системный слой платформы: авторизации, ошибки входа, изменения настроек, события модулей. Живёт в разделе Настройки → Инструменты → Журнал событий.
- История входов с устройств пишет, откуда и с чего заходил конкретный сотрудник.
- История CRM работает на прикладном уровне: просмотры карточек, правки полей, экспорт, изменения по товарам. Раздел CRM → Ещё → История.
- Журнал вторжений входит в модуль «Проактивная защита» и фиксирует срабатывания фильтра на подозрительные запросы.
- Журнал изменений контента выводит правки страниц, меню, файлов, разделов и инфоблоков на отдельной странице сайта.
По документации 1С-Битрикс собственные журналы дополнительно ведут модули «Контроллер», «Проактивная защита» и «Техподдержка», а настройки логирования отдельно есть у главного модуля, инфоблоков, форума, облачных хранилищ, модуля управления структурой и даже у конкретного информационного блока.
Значит, включив что-то одно, вы закрываете лишь часть картины. Разбор реального инцидента почти всегда требует двух или трёх журналов сразу.
Журнал событий главного модуля: что он реально видит
Открывается по пути Настройки → Инструменты → Журнал событий. Список записей содержит: ID, время, срочность (SECURITY или WARNING), название события, источник, объект, IP-адрес, User Agent, URL страницы, сайт, пользователя и описание. Если на портале работает модуль веб-аналитики, добавляется идентификатор гостя.
Колонка с IP-адресом полезнее, чем кажется. Прямо из журнала адрес добавляется в стоп-лист, и это разумная первая реакция на серию неудачных попыток входа с одного адреса.
Настройки живут в другом месте: Настройки → Настройки продукта → Настройки модулей → Главный модуль, вкладка «Журнал событий». Там два принципиальных блока. Параметр «Сколько дней хранить события» задаёт глубину истории. Набор флажков вида «Записывать …» включает и отключает конкретные типы событий.
Значение по умолчанию равно семи дням. Это и есть та самая ловушка, из-за которой расследования упираются в пустой экран. Семь дней придуманы для того, чтобы таблица b_event_log не разрасталась на типовом сайте. Для корпоративного портала, где логи нужны как доказательная база, срок стоит поднимать осознанно.
Уровень безопасности продукта завязан на эту же вкладку. Чтобы получить высокий уровень, проект обязан включать журналирование событий главного модуля, защиту административной части, хранение сессий в базе данных и смену идентификатора сессии. Логирование в 1С-Битрикс, таким образом, входит в формальные требования к безопасной конфигурации, а не остаётся делом вкуса администратора.
История входов: кто, откуда и с какого устройства
Эта подсистема отвечает на вопрос «кто заходил в портал», и в коробке её нужно включать руками. Настройки лежат там же, в главном модуле, на вкладке «Журнал событий»:
- «Сохранять историю входов с устройств пользователя» включает сам механизм;
- «Сколько дней хранить историю входов» задаёт отдельный срок, никак не связанный со сроком хранения журнала событий;
- «Собирать IP-геоданные для истории входов» добавляет к записи географию.
Геоданные требуют обработчика. Он выбирается в разделе Настройки → Настройки продукта → Геолокация, доступны GeoIP2, MaxMind и Sypex Geo. Без обработчика географии в записях не будет, останутся дата, время, устройство, операционная система, браузер и IP.
Смотреть историю входов сотрудник может сам, в разделе с рабочим временем и отчётами. Администратор портала видит историю любого пользователя и при необходимости принудительно завершает его сессии на всех устройствах. Сам сотрудник тоже может одним действием выйти из Битрикс24 на всех устройствах, кроме текущего. Полезно, когда закрадывается мысль «кажется, я забыл выйти на чужом ноутбуке».
Отдельно отмечу нюанс, который часто всплывает при увольнениях: заблокированный пользователь перестаёт входить, но записи его прошлых входов остаются ровно столько, сколько указано в сроке хранения. Если срок стоит небольшой, а разбирательство начинается через месяц, смотреть будет нечего.
История CRM: просмотры, правки и выгрузки базы
Самый ценный журнал для коммерческого директора находится в разделе CRM → Ещё → История. Он фиксирует и изменения данных, и сами обращения к ним.
Что попадает в историю: просмотры карточек, экспорт, изменение полей (название, стадия, ответственный и другие), добавление и удаление связей между элементами, события таймлайна вроде дел, задач, звонков, писем и документов, а также операции с товарами: добавление позиций, изменение суммы и количества.
Фильтры позволяют сузить выборку по идентификатору элемента, типу элемента CRM (лиды, контакты, компании, сделки), типу изменения, автору и диапазону дат. Среди типов изменения есть отдельные значения для просмотра и для экспорта, и именно они закрывают вопрос «кто выкачал базу». Набор отображаемых колонок настраивается через шестерёнку.
Видимость привязана к правам. Администратор видит все изменения на портале, обычный сотрудник только те элементы, к которым у него есть доступ. Удалять записи из истории могут исключительно администраторы, через меню раздела.
На уровне отдельной сделки та же информация доступна во вкладке «История» карточки: дата, автор, тип и описание события. Плюс системные поля «Дата изменения» и «Кто изменил» показывают, кто трогал карточку последним. Для быстрой проверки одного спорного случая этого хватает. История раздела нужна, когда вопрос звучит шире: что вообще происходило с базой за прошлый квартал.
Настройте себе сохранённый фильтр по типу изменения «экспорт» и просматривайте его раз в неделю. Массовая выгрузка контактов почти никогда не бывает рабочей рутиной, а всплывает она обычно уже после увольнения.
Журнал вторжений и остальная проактивная защита
Модуль «Проактивная защита» отвечает за внешний контур. Проактивный фильтр анализирует данные, которые приходят от посетителя, распознаёт известные атаки на веб-приложения и блокирует их, а все попытки фиксирует в журнале вторжений. Записи появляются оперативно, то есть смотреть их можно сразу после срабатывания.
Рядом в модуле лежат инструменты, которые логирование дополняют. Контроль целостности файлов проверяет, менялись ли файлы ядра и публичной части. Контроль активности защищает от чрезмерно активных пользователей и перебора паролей. Стоп-лист блокирует доступ с конкретных IP-адресов. Защита административного раздела ограничивает вход в админку по сетям. Одноразовые пароли (OTP) добавляют второй фактор поверх обычной авторизации.
Модуль поддерживает три уровня безопасности: стандартный, высокий и повышенный. Переход на высокий как раз и вынуждает включить журналирование главного модуля, так что настройку логов и настройку защиты имеет смысл делать одним заходом, а не двумя разными задачами в разные месяцы.
Журнал изменений контента: страницы, файлы и инфоблоки
Коробочный портал почти всегда несёт на себе внутренний контент: базу знаний, регламенты, новости, файловые разделы, иногда публичный сайт на том же ядре. Правки в этом слое журнал событий главного модуля толком не показывает, потому что заточен под настройки системы.
Для контента у платформы есть свой инструмент, журнал изменений. Технически это компонент, который размещается на отдельной странице портала и выводит список правок. В него попадают добавление пользователей, изменение, добавление и удаление страниц, операции с меню, действия с файлами, правки разделов и элементов инфоблоков, а также сообщения и темы форумов.
Документация 1С-Битрикс разделяет зоны ответственности прямо: журнал изменений подходит для мониторинга изменений контента, журнал событий для мониторинга изменений настройки системы. Одно другое не заменяет.
Важная деталь для тех, кто ведёт на портале регламенты и инструкции: логирование правок инфоблоков включается на уровне самого информационного блока, а не глобальным переключателем. Свои настройки логирования есть и у модуля инфоблоков, и у форума, и у облачных хранилищ, и у модуля управления структурой. Если база знаний живёт в инфоблоке, а логирование в нём не включено, история правок регламента просто не ведётся, при том что остальные журналы на портале работают исправно.
Проверять это стоит после каждого крупного обновления и после переноса портала на новый сервер: настройки модулей переживают такие операции не всегда.
Сколько хранить и куда девать объём
Главный компромисс в логировании возникает между глубиной истории и весом базы. Записи журнала событий складываются в таблицу b_event_log, и на активном портале она растёт быстро. Отсюда и осторожная заводская настройка в семь дней.
Мы обычно предлагаем поднимать срок хранения журнала событий до значения, за которое реально успевают заметить проблему. Практика показывает, что от 60 до 90 дней покрывают почти все разбирательства. Срок истории входов ставится не меньше, потому что вопросы про доступ всплывают позже всех остальных. Одновременно отключаются флажки для типов событий, которые никто никогда не читает: шумные технические записи заполняют таблицу и мешают искать.
Если объём всё-таки давит, у платформы есть штатный способ вынести логи наружу. Bitrix Framework содержит набор логгеров: FileLogger пишет в файл с ротацией по размеру, SysLogger отправляет записи в системный журнал через syslog, EventLogger кладёт их в ту же b_event_log. Форматтер JsonLinesFormatter, доступный с версии платформы 25.300.0, выдаёт данные построчным JSON, который без переработки принимают внешние системы сбора логов.
В итоге в базе держат короткий оперативный срез для повседневных проверок, а долгую историю сливают в файл или во внешнее хранилище, где место дешевле и откуда её не удалит администратор портала. Для компаний, где безопасность проверяют аудиторы, второй пункт обычно оказывается решающим.
Разбор одного инцидента: как журналы работают вместе
Ситуация условная, но собрана из типовых обращений. Компания замечает, что три крупных клиента ушли к конкуренту почти одновременно. Общее у них одно: все три сделки вёл менеджер, который уволился шесть недель назад.
Первый шаг, история CRM с фильтром по автору изменений и диапазону дат за последние два месяца его работы. Здесь видно, смотрел ли он карточки, к которым не имел отношения, и был ли экспорт. Второй шаг, история входов того же пользователя: время, устройство, IP. Заходы в нерабочие часы с незнакомого устройства меняют характер разговора. Третий шаг, журнал событий главного модуля за те же даты: ошибки авторизации, изменения прав, действия под учётной записью после даты увольнения.
Дальше всё зависит от сроков хранения. Если журнал событий стоял на семи днях, а история входов не была включена вовсе, останется одна история CRM, и та в объёме, который определяется настройками портала. Именно поэтому логирование настраивают заранее, в спокойное время, а не в день, когда оно понадобилось.
Побочный эффект, о котором редко думают: журналы одинаково хорошо защищают и сотрудника. Когда есть записи, обвинение «это ты слил базу» проверяется за пятнадцать минут вместо затяжного конфликта на ощущениях.
Чего журналы не покроют
Журналы фиксируют операции внутри системы, и только их. Есть целый класс утечек, к которому они нечувствительны в принципе: сотрудник может сфотографировать экран телефоном, переписать десять ключевых контактов в блокнот, переслать одну сделку в мессенджере одним сообщением. По объёму это не выгрузка, поводом для тревоги в отчёте такое не станет. Наконец, менеджер с трёхлетним стажем просто помнит своих клиентов наизусть. Ни один журнал портала здесь не поможет, и обещать обратное было бы нечестно.
Поэтому логирование стоит воспринимать как элемент дисциплины, а не как непроницаемую защиту. Оно резко повышает цену массовых действий, потому что выкачать всю базу тихо уже не выйдет, и даёт фактуру для разбирательства. Но оно не отменяет ни разграничения прав, ни договорённостей с сотрудниками о том, что считается коммерческой тайной.
Второе ограничение организационное. Мы регулярно встречаем порталы, где журналы включили пару лет назад на этапе внедрения и с тех пор не открывали ни разу. Технически всё в порядке, но данные, которые никто не смотрит, ничем не отличаются от отсутствующих: к моменту первого инцидента срок хранения обычно успевает всё стереть.
Регламент, а не набор галочек
Назначьте ответственного за просмотр, обычно это администратор портала или подрядчик на сопровождении. Задайте периодичность: раз в неделю быстрый взгляд на экспорт из CRM и на неудачные авторизации, раз в месяц на журнал вторжений и контроль целостности файлов. Зафиксируйте сроки хранения письменно, чтобы после очередного обновления или переноса сервера настройки восстановили в прежнем виде. И договоритесь заранее, что считается поводом для эскалации: экспорт больше условленного числа записей, вход из незнакомой страны, действия под учётной записью уволенного.
Отдельным пунктом идёт ограничение прав. Логи фиксируют то, что произошло, а права определяют, что возможно в принципе. Если у половины отдела продаж стоит доступ на экспорт всей базы, журнал будет исправно записывать выгрузки, но остановить их не сможет.
Настройка журналов на коробке занимает несколько часов, но требует понимания, какие галочки на что влияют и во что обойдётся рост базы. Если заниматься этим внутри некому, эта задача входит в наши услуги по внедрению и настройке Битрикс24, вместе с правами доступа, регламентом просмотра и выносом длинной истории за пределы портала.
Проверить текущее состояние можно прямо сейчас и без подрядчика: откройте настройки главного модуля и посмотрите, какая цифра стоит в сроке хранения событий и включена ли история входов. Две минуты работы, зато без неприятных открытий в тот момент, когда логи действительно понадобятся.
Частые вопросы
Чем логирование в коробке отличается от облака?
Прикладные журналы, включая историю CRM и историю входов, устроены одинаково. Разница в управлении: в коробке вы сами задаёте сроки хранения, сами включаете сбор геоданных, сами отвечаете за объём базы и сохранность записей. И сами же можете вынести логи во внешнее хранилище, чего в облаке сделать нельзя.
Можно ли увидеть, кто выгружал базу контактов?
Да. В разделе CRM → Ещё → История есть фильтр по типу изменения, и среди значений присутствуют отдельно просмотр и экспорт. Отфильтруйте по экспорту и нужному периоду, чтобы получить список авторов выгрузок.
Сколько по умолчанию хранятся записи журнала событий?
Семь дней. Значение меняется в настройках главного модуля на вкладке «Журнал событий», параметром «Сколько дней хранить события».
Сильно ли логирование нагружает сервер?
Основная нагрузка приходится не на саму запись, а на объём таблицы b_event_log. Управляется он двумя рычагами: сроком хранения и отключением типов событий, которые вы всё равно не читаете. При долгой истории записи выносят в файл или syslog штатными логгерами платформы.
Может ли сотрудник удалить записи о своих действиях?
Из истории CRM записи удаляют только администраторы портала. Поэтому смысл имеет не одна лишь настройка журналов, но и ревизия того, у скольких людей на портале административные права.
Нужно ли предупреждать сотрудников, что действия логируются?
Мы советуем предупреждать, и не только из этических соображений. Открытое правило работает как профилактика: люди аккуратнее обращаются с базой, когда знают, что операции фиксируются. Плюс это снимает вопросы при разборе спорной ситуации, ведь сотрудник не может сослаться на то, что его не поставили в известность. Формулировку обычно добавляют в положение о коммерческой тайне или в регламент работы с CRM.