Практическое руководство

Как распределить права и историю действий в CRM

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

Материал WebexlabПодготовлено 5 мин чтения

Краткий ответ

Права CRM задают для действий и данных: чьи сделки доступны, какие поля можно менять и кто вправе выгружать информацию. История фиксирует значимые изменения и их исполнителя; наличие журнала не заменяет ограничение доступа.

Опишите доступ через действия

Названия «менеджер» и «руководитель» недостаточны. Уточните, видит ли сотрудник все сделки или только свои, может ли менять владельца, удалять запись и выгружать контакты. Для чувствительных действий задайте отдельные ограничения. Чтение карточки и массовый экспорт создают разные возможности, поэтому не должны автоматически объединяться в одно право.

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

Составьте матрицу

Составьте матрицу — сравнение
ДействиеМенеджерРуководительАдминистратор
Чтение сделкиНазначенные записиРазрешённая командаПо принятой политике
Смена владельцаПо ограниченному правилуВ пределах полномочийКонтролируемое действие
ЭкспортОтдельное разрешениеОтдельное разрешениеНе безусловное право
Управление ролямиНедоступноТолько при необходимостиС журналом изменений

Это учебная основа обсуждения, а не готовые права любой компании. Разберите замещение, совместную работу и несколько подразделений. Временное полномочие должно иметь срок или событие отзыва. Иначе обычный отпуск постепенно создаёт постоянный доступ к чужим клиентам без осознанного решения владельца.

Определите полезную историю

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

Установите права чтения журнала и правила хранения. История тоже содержит сведения о работе людей и клиентах. Её назначение — разбор процесса и ошибок в согласованных пределах. Нельзя считать наличие логов гарантией возможности восстановить любое состояние: для восстановления нужны соответствующие данные и проверенная процедура.

Учебный пример временной передачи

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

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

Решите, кто контролирует журнал

История действий полезна только при понятном составе и доступе к ней. Укажите, какие изменения фиксируются, как определяется действующий пользователь и кто может просматривать записи. Не включайте без необходимости полное содержимое чувствительных полей. Для разбора часто достаточно типа действия, объекта, времени и разрешённых изменений.

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

Проверьте правила на исключениях

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

При изменении структуры компании пересматривайте матрицу и назначенные исключения. Итогом работы становятся правила, проверки и управляемый журнал, а не только список ролей в настройках. Это помогает сохранять достоверность отчётов CRM и безопасно развивать совместную работу отдела.

Как проверять доступ к массовой выгрузке CRM

Закрытая карточка не защищает данные, если тот же сотрудник может выгрузить их через общий отчёт. Добавьте в матрицу прав поиск, экспорт, массовое изменение, вложения и API. Область разрешённых записей должна сохраняться во всех этих каналах.

В учебном наборе два менеджера работают с разными клиентами. Проверьте прямой адрес чужой записи, фильтр отчёта и скачивание файла после отзыва доступа. Серверная проверка прав необходима при каждом соответствующем запросе — этот принцип описан в рекомендациях OWASP. Для журнала задайте срок хранения и доступ ответственных; копирование всей карточки с персональными данными в каждый технический лог не делает аудит качественнее.

Термины из материала

Источники и документация

У каждого документа указана дата последней проверки. Состав функций и интерфейсы сервисов могут меняться. Ссылки открываются в новой вкладке.

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

Применить к вашему проекту

Разработаем матрицу прав CRM и проверяемую историю существенных изменений.

Обсудить задачу
Все материалы блога