Роли и права доступа в CRM: практическая модель

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

Начните с принципа минимальных полномочий

Менеджеру продаж нужны клиенты и сделки, но обычно не требуется управление системными настройками или выгрузка всей базы. Финансисту нужен финансовый контур, руководителю — обзор и согласования. Административный доступ оставляют ограниченной группе и используют только для соответствующих задач.

Что включить в матрицу доступа

Матрица связывает роль, модуль, действие и область видимости.

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

Избегайте двух крайностей

Одна роль «всем всё» создаёт риск утечки и случайных изменений. Сотни индивидуальных исключений делают модель непрозрачной. Лучше иметь небольшой набор бизнес-ролей, отдельные чувствительные разрешения и редкие документированные исключения.

Пересматривайте доступ регулярно

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

Спроектируйте роли вместе с процессами

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

Приёмка ролевой модели

Матрица строится от бизнес-действий: просмотреть, создать, изменить, согласовать, экспортировать, администрировать. Для каждой роли задаются область данных и ограничения по состоянию объекта. Затем тестовые пользователи проходят позитивные и негативные сценарии, включая прямой URL, API, массовую операцию и старую активную сессию. Избыточные права не компенсируются обещанием «не нажимать». Повышение роли требует подтверждения, журналируется и периодически пересматривается; доступ уволенного сотрудника отзывается немедленно. Сервисные аккаунты отделяются от людей и получают минимальный scope.

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