Журналирование включено почти везде, а смотрит журналы почти никто. Причина не в лени: журнал по умолчанию пишет всё подряд, и в нём одинаково выглядят вход бухгалтера в понедельник утром и выгрузка всей клиентской базы в пятницу вечером. Чтобы журнал начал работать, из него нужно выделить конечный список событий, при которых система обязана позвать человека, и назначить каждому порог.
Список получается коротким — двенадцать позиций. У семи из них есть порог, который считается от вашей же медианы за последние 30 дней: то, что для отдела продаж норма, для бухгалтерии аномалия. У остальных пяти порога нет: такие события в компании происходят несколько раз в год, и каждое требует реакции.
Ниже — сам список с порогами, настройка оповещений так, чтобы их не отключили через месяц, регламент просмотра на 15 минут в неделю, вопрос защиты самих журналов и три вида событий, которых в журналах обычно нет.
Двенадцать событий и пороги
Медиана в таблице — это медианное значение показателя по конкретной роли за последние 30 дней. Считать её нужно один раз при настройке и пересчитывать раз в полгода: отдел растёт, объёмы меняются, и вчерашний порог начинает срабатывать на обычной работе.
| Событие | Когда это сигнал | Кто реагирует | Срок |
|---|---|---|---|
| Массовая выгрузка данных | Больше 200 строк или больше трёх медиан по роли за 30 дней | Руководитель направления | В тот же день |
| Серия просмотров карточек | Больше 120 карточек за час при медиане 25 | Руководитель направления | В тот же день |
| Доступ вне рабочего времени | Вход с 22:00 до 06:00 у роли без ночных смен | Администратор | Следующее утро |
| Вход с нового устройства или из нового региона | Первое появление устройства или подсети у этой учётной записи | Администратор | В течение часа |
| Создание учётной записи | Порога нет: реакция на каждое | Администратор | В тот же день |
| Повышение прав или добавление роли | Порога нет: реакция на каждое | Руководитель направления | В тот же день |
| Отключение или изменение настроек журналирования | Порога нет: реакция на каждое | Владелец системы | Немедленно |
| Массовое удаление или распроведение документов | Больше 10 документов за час или любое распроведение в закрытом периоде | Главный бухгалтер | Немедленно |
| Изменение банковских реквизитов контрагента | Порога нет: реакция на каждое | Бухгалтерия | До ближайшего платежа |
| Смена ключа интеграции, токена или пароля сервисной записи | Порога нет: реакция на каждое | Администратор | В тот же день |
| Подбор пароля | Пять и больше неудачных входов подряд, особенно если дальше был успешный | Администратор | В течение часа |
| Обращение интеграции вне расписания | Обмен, который идёт в 03:00, сработал днём или чаще обычного | Администратор | В тот же день |
Половина списка — про права и учётные записи, и это не случайность: почти каждая история начинается не с выгрузки, а с того, что кому-то тихо расширили доступ. Как устроена сама раздача прав и почему её решает руководитель направления, а не администратор, разобрано в материале про разграничение прав сотрудников.
Схема из двух вертикальных колонок. Левая, «Порог от медианы за 30 дней», семь блоков: выгрузка (200 строк или 3 медианы), серия просмотров (120 карточек в час при медиане 25), доступ вне рабочего времени, новое устройство или регион, массовое удаление (10 документов в час), подбор пароля (5 попыток), обращение интеграции вне расписания. Правая, «Порога нет — реакция на каждое», пять блоков: создание учётной записи, повышение прав, отключение журналирования, изменение банковских реквизитов, смена ключа интеграции. Внизу общая полоса «получатель оповещения и срок реакции». Чертёжный стиль, подписи по-русски.
Как не утонуть в ложных срабатываниях
Судьба системы оповещений решается в первые две недели. Если из неё сыплется по десять сообщений в день, руководитель сначала перестаёт их открывать, потом заводит правило в почте, а через месяц просит всё отключить. Дальше формально мониторинг есть, фактически его нет — и это худшее состояние из возможных, потому что на него ссылаются как на защиту.
- Порог — от своей медианы, а не из шаблона. Соберите статистику за 30 дней до включения оповещений. Медиана считается по роли: у оператора поддержки норма просмотров в разы выше, чем у бухгалтера.
- Исключения по ролям, а не по фамилиям. Бухгалтер выгружает реестры каждый месяц — это его работа, и порог у него другой. Исключение, привязанное к фамилии, переживёт увольнение и достанется преемнику вместе с учётной записью.
- Тихие часы для несрочного. Событие в 23:40 не требует, чтобы руководитель проснулся. Немедленной реакции достойны три события из двенадцати: отключение журналирования, массовое распроведение и вход с нового устройства у административной роли.
- Дайджест вместо потока. Всё, кроме этих трёх, собирается в одно письмо раз в сутки. Одно письмо в день читают, десять сообщений в день — нет.
- Обратная связь по каждой ложной тревоге. Разобрали, поняли, что это норма, — сразу поправили порог. Если этого не делать, через месяц список исключений придётся собирать заново.
Считаем на компании, где 60 пользователей в четырёх системах. Ставки: администратор — 1 200 ₽/час, руководитель направления — 1 800 ₽/час.
Строка про 240 оповещений — не преувеличение, а типовой результат включения журналирования «как есть»: каждый вход, каждый неуспешный пароль, каждое открытие отчёта. И главное, чего нет в расчёте: поток без порогов не просто дорог, он самоуничтожается. Через месяц его отключают, и компания остаётся без мониторинга, будучи уверенной, что он есть.
Кто смотрит журналы в компании без отдела ИБ
Ответ, который обычно не нравится: не системный администратор. Он в этом списке фигурант — половина событий про учётные записи и права, а их заводит и меняет он же. Смотреть журналы должен человек, который не может их наполнять: чаще всего это финансовый директор, руководитель одного из направлений или собственник в компании поменьше. Фамилия должна быть одна и записана в регламенте.
- 15 минут: дайджест за неделю
Сколько событий сработало по каждому из двенадцати правил. Интересуют не сами события, а всплески: было 2 в неделю, стало 14.
- 25 минут: беспороговые события
Все создания учётных записей, повышения прав, смены ключей и изменения реквизитов за неделю. По каждому — короткий вопрос: чья это была заявка. Если заявки нет, событие идёт в разбор.
- 33 минуты: активные учётные записи против кадрового списка
Раз в месяц, а не каждую неделю. Ищем записи уволившихся и подрядчиков закрытых проектов — как их находить, разобрано в материале про забытые учётные записи.
- 42 минуты: отметка о просмотре
Дата, фамилия, что смотрели, что взяли в работу. Одна строка в таблице. Именно она потом отвечает на вопрос, велось ли наблюдение фактически.
Формулировка для регламента: еженедельный просмотр сводки событий безопасности выполняет назначенный приказом сотрудник, не имеющий прав на изменение учётных записей и настроек систем. Результат просмотра фиксируется строкой в журнале наблюдения с датой, фамилией и перечнем событий, взятых в работу.
Горизонтальная лента на 15 минут с четырьмя отрезками разной длины: «5 мин — дайджест за неделю, ищем всплески», «5 мин — беспороговые события: учётные записи, права, ключи, реквизиты», «3 мин — сверка активных записей с кадровым списком, раз в месяц», «2 мин — отметка о просмотре: дата, фамилия, что взято в работу». Под лентой подпись: «смотрит тот, кто не может наполнять журнал». Чертёжный стиль, подписи по-русски.
Защита журналов и срок хранения
Журнал имеет смысл ровно до того момента, пока его не может отредактировать тот, чьи действия в нём записаны. В типовых системах это условие по умолчанию не выполняется: администратор с полными правами может очистить журнал регистрации, и следов этой операции в самом журнале не останется.
Свойство, при котором запись нельзя изменить или удалить незаметно. Достигается не настройкой внутри системы, а выносом копии наружу: журнал регулярно выгружается в хранилище, где у администраторов учётных систем есть право дописывать, но нет права изменять и удалять.
- Учётная система. Журнал регистрации ведёт платформа, но полные права позволяют его очистить. Практическое решение — регулярная выгрузка в отдельное хранилище по расписанию, раз в сутки.
- CRM. Журнал действий и отчёт по экспорту есть, но глубина хранения зависит от тарифа и обычно меньше, чем нужно. Выгружайте историю экспорта отдельно и не рассчитывайте на то, что она пролежит год сама.
- Серверы и почта. Системный журнал пересылается на отдельный узел. На основном сервере остаётся копия для удобства, доказательной силы у неё нет.
- Права на само хранилище журналов выдаются отдельно и не входят ни в одну роль — это ровно тот случай, когда работает принцип минимальных прав в чистом виде.
Срок хранения. Нижняя граница задана расследованием инцидента: часть 3.1 статьи 21 152-ФЗ отводит 24 часа на уведомление о факте и 72 часа на сведения о результатах внутреннего расследования, и восстановить состав и объём утечки можно только по журналам — подробно этот сюжет разобран в материале про уведомление об утечке данных. Верхняя граница задаётся сроками, в которые к вам ещё может прийти претензия. Рабочий ориентир для компании без специальных требований — 12 месяцев в системе и 24 месяца в архиве.
Журналы содержат персональные данные — как минимум фамилии сотрудников и IP-адреса, а часто и данные клиентов. Хранение без определённого срока противоречит принципу ограничения срока обработки: срок должен быть назван в документе и обоснован. Конкретную цифру и формулировку стоит согласовать с юристом один раз — это вопрос на десять минут, если задать его заранее.
Чего в журналах обычно нет
Три вида событий выясняются в самый неподходящий момент — когда журнал уже открыли и ищут в нём то, чего там не писалось. Все три включаются заранее и отдельно, потому что по умолчанию их нет.
- 1Выгрузка как отдельное событие. Во многих системах пишется «пользователь открыл отчёт», а не «пользователь выгрузил 640 строк в файл». Разница принципиальная: первое ничего не доказывает. Проверьте прямо сейчас — сделайте экспорт и посмотрите, как он выглядит в журнале.
- 2Обращения интеграций. Обмен с сайтом, маркетплейсом, телефонией и ЭДО идёт под сервисными учётными записями, и в журнале от него остаётся строка «обмен» без деталей. Нужны минимум три поля: какая интеграция, сколько объектов, каких.
- 3Действия сервисных записей и ИИ-агентов. Если агент пишет в учётную систему под общей учётной записью интеграции, его действия неотличимы от обычного обмена, и разобрать инцидент невозможно. Поэтому у агента должна быть своя именная служебная запись — это же требование разбирается в материале про права доступа ИИ-агента к системам.
Сравнение в две колонки, каждая — фрагмент строки журнала крупным планом. Левая, помечена «по умолчанию»: «10:42 Иванов И. — открыт отчёт «Клиенты»»; под ней подпись «объём неизвестен, файл не зафиксирован». Правая, помечена «после настройки»: «10:42 Иванов И. — экспорт отчёта «Клиенты», 640 строк, поля: наименование, телефон, сумма отгрузок; файл получил гриф»; под ней подпись «привязано к человеку, объёму и файлу». Внизу общая подпись: «то же действие, разная доказательная сила». Чертёжный стиль, подписи по-русски.
Когда порогов и оповещений не нужно
Двенадцать правил — не универсальный минимум. Есть случаи, когда их настройка не окупится, и честнее это сказать сразу.
- В компании меньше десяти человек и одна система. Всё видно и так. Разумный минимум здесь — включённый журнал экспорта и одно оповещение о выгрузке больше 200 строк, это настройка на полчаса.
- Некому реагировать. Если фамилии в регламенте нет, оповещения будут падать в общий ящик и накапливаться. Сначала назначается человек, потом настраиваются пороги, а не наоборот.
- Система меняется в ближайшие месяцы. Пороги и правила привязаны к конкретной системе и переносу не подлежат. Настраивайте на новой, после переезда пользователей.
- Журнал технически недоступен для выгрузки. Такое бывает на старых конфигурациях и на тарифах, где история хранится две недели. Тогда честный ответ — не настраивать оповещения, а сменить тариф или контур: наблюдение, которое нельзя предъявить, защитой не является.
