Контроль работы сотрудников с чужими клиентами

Почему одного права доступа недостаточно

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

Риск появляется, когда человек за короткое время охватывает много чужих объектов, движется по ним последовательно или сочетает просмотры с изменениями, экспортом либо удалением.

Нормальные объяснения

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

Эти ситуации следует зарегистрировать заранее: определить владельца, область, срок и допустимые действия.

Признаки, требующие проверки

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

Первые действия

1. Зафиксируйте временное окно и доступные примеры объектов.
2. Сравните действия с ролью, подразделением и назначенными задачами.
3. Проверьте отпуск, замещение, реорганизацию и плановые операции.
4. Сохраните доступные журналы без создания лишних копий клиентской базы.
5. Назначьте владельца проверки и критерии завершения.

Если риск продолжается, изменение прав выполняйте по внутренней процедуре и только уполномоченным администратором.

Что может показать штатный Bitrix24

Начните с ролевой модели доступа, списка ответственных и истории CRM. Администратор видит больше записей истории, чем обычный сотрудник, но доступность конкретных действий зависит от прав и настроек. Штатный экспорт и массовые действия могут отражаться в истории, однако одна запись не показывает весь бизнес-контекст последовательности.

Не используйте отсутствие записи как доказательство отсутствия действия: часть интерфейсов и каналов имеет другое покрытие.

Что добавляет Veriqon

При доступном канале телеметрии Veriqon анализирует уникальные карточки, владельцев, подразделения и последовательность web-просмотров. Система связывает эти сигналы с изменениями и другими доступными событиями и показывает фактическое покрытие источника.

Проверяющий видит:

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

Veriqon не следит за экраном, файлами на устройстве и личной активностью сотрудника. Риск-профиль относится только к наблюдаемым CRM-событиям.

Решение по результатам проверки

Закрывайте проверку одной из понятных классификаций: штатная операция, ошибка процесса, недостаток прав, неизвестный источник, подтвержденный инцидент или недостаточно данных. Для каждой классификации фиксируйте владельца и корректирующее действие.

Если данных недостаточно из-за частичного покрытия, это нужно указать прямо. Нельзя заменять неизвестность выводом о безопасности или виновности.

Профилактика

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

Подробнее о системном подходе — в статье «Как защитить клиентскую базу от сотрудников». Для фиксации фактов используйте комплект расследования инцидента CRM.

Следующий шаг

Проведите диагностику роли, фактического охвата и доступных журналов. На первом обращении достаточно описать размер отдела и риск-сценарий; клиентские данные и учетные секреты не нужны.