Безопасность и журнал действий

Журнал действий и настройки безопасности — это то, что отделяет управляемую CRM от системы, в которой невозможно понять, кто и когда изменил заказ или выгрузил базу клиентов. Разбираем, как в RetailCRM ограничить доступ, отследить операции менеджеров и подготовиться к расследованию инцидентов.

Зачем нужен контроль безопасности в CRM

RetailCRM хранит два самых чувствительных актива интернет-магазина: базу клиентов и историю заказов с суммами. Утечка или несанкционированное изменение этих данных бьёт и по деньгам, и по репутации, и по соответствию 152-ФЗ «О персональных данных». Поэтому безопасность в CRM — это не абстрактная опция, а конкретный набор ограничений и журналов, которые нужно осознанно настроить.

Типовые риски, которые закрываются штатными средствами:

• Слив базы — уволенный менеджер выгружает контакты клиентов в CSV перед уходом;
• Скрытое изменение заказа — правка суммы, скидки или состава без следов;
• Доступ с чужого устройства — вход по украденному паролю из другой страны;
• Забытые учётки — активные аккаунты сотрудников, которые давно не работают.

Ограничение доступа: IP, сессии и пароли

Первый рубеж — это правила входа. В RetailCRM они настраиваются глобально для всего аккаунта и позволяют сузить поверхность атаки ещё до того, как злоумышленник доберётся до данных.

Белый список IP — самый недооценённый инструмент. Если магазин работает из офиса и удалённых сотрудников подключает через корпоративный VPN, ограничение доступа по адресам делает бесполезным даже украденный пароль.

Журнал действий: что он фиксирует

Журнал действий (аудит-лог) — это хронология операций всех пользователей системы. Он отвечает на вопрос «кто, что и когда сделал» и является основным инструментом при разборе инцидентов.

В журнале фиксируются, в частности:

• входы и выходы пользователей, в том числе неудачные попытки;
• создание, изменение и удаление заказов и клиентов;
• массовые операции — экспорт, импорт, групповое редактирование;
• изменения настроек: справочников, прав, ролей, интеграций;
• операции через API с указанием ключа, от имени которого они выполнены.

Каждая запись содержит метку времени, пользователя (или API-ключ), тип действия и объект. Журнал доступен для фильтрации по дате, сотруднику и типу события, что позволяет быстро локализовать нужный отрезок.

История изменений заказа и клиента

Помимо общего журнала, RetailCRM ведёт локальную историю внутри каждого заказа и карточки клиента. Она отображается прямо на странице объекта и показывает пошаговую эволюцию: смену статуса, правку суммы, изменение состава, комментарии и действия триггеров.

Это принципиально удобнее общего журнала в трёх ситуациях:

1. Спор с клиентом — видно, кто и когда менял сумму или адрес доставки;
2. Разбор ошибки автоматизации — в истории видно, какой триггер сработал и что изменил;
3. Контроль оператора — руководитель видит, аккуратно ли ведётся заказ.

История отделяет ручные действия сотрудников от автоматических. Записи, сделанные триггерами или интеграциями, помечаются системным источником, а не именем менеджера — это важно, чтобы не обвинить человека в правке, которую на самом деле сделал робот.

Отзыв доступа при увольнении

Самый частый источник утечек — не хакеры, а бывшие сотрудники. Процедуру отзыва доступа стоит сделать регламентной, а не разовой импровизацией.

Чек-лист при увольнении менеджера:

• заблокировать учётную запись в Администрирование → Пользователи (не удалять, чтобы сохранить историю его действий);
• отозвать или сменить общие пароли и API-ключи, к которым он имел доступ;
• переназначить его активные заказы и задачи на другого оператора;
• проверить журнал за последнюю неделю на предмет массовых выгрузок.

Блокировка мгновенно завершает все активные сессии пользователя, поэтому даже открытый на его устройстве RetailCRM перестанет работать после следующей загрузки страницы.

Безопасность API и интеграций

Каждая интеграция работает через API-ключ, и этот ключ — фактически пароль с правами, которые вы ему выдали. В RetailCRM права ключа настраиваются гранулярно: можно ограничить его только чтением заказов или конкретными методами.

Принципы гигиены ключей:

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

Действия, выполненные через API, тоже попадают в журнал и подписываются именем ключа. Если вы видите в истории заказа изменение от имени ключа маркетплейса — это ожидаемо; изменение от неизвестного ключа — сигнал разобраться.

Итог

Безопасность RetailCRM складывается из трёх слоёв: ограничение входа (IP, сессии, пароли, двухфакторная аутентификация), аудит (журнал действий и история объектов) и дисциплина (регламент отзыва доступа и гигиена API-ключей). Ни один из них не работает в одиночку: белый список бесполезен без ротации ключей, а журнал бесполезен, если в него никто не заглядывает.

Мы в B2Bsite помогаем выстроить эту защиту как систему: настраиваем права и роли под реальную структуру команды, разграничиваем доступ к ценам и себестоимости, регламентируем работу с API и подключаем мониторинг подозрительных операций. Если нужно навести порядок в доступах или сопровождать систему на постоянной основе — поможем сделать это без остановки продаж.