Менеджер должен работать со своими сделками, но при проверке видит чужие карточки или может выгрузить весь список клиентов. До подключения сотрудников к CRM нужно согласовать матрицу «роль — объект — действие — область доступа» и проверить её под обычными учётными записями. Скрытая кнопка сама по себе не подтверждает запрет: результат должен сохраняться при обращении к данным другими предусмотренными системой способами.
Начните с трёх безопасных действий:
- Выпишите рабочие обязанности каждой роли и операции, которые ей действительно нужны.
- Попросите администратора подготовить тестовый контур с вымышленными клиентами и отдельными учётными записями для проверки.
- Для каждой операции запишите два ожидаемых результата: что должно получиться и в чём система должна отказать.
Что именно ограничивать: роль, запись и действие
Роль описывает набор полномочий: например, менеджер продаж или руководитель отдела. Объект — то, с чем работают: сделка, контакт, документ. Действие — просмотр, изменение, удаление, экспорт или назначение ответственного. Область доступа отвечает на отдельный вопрос: со своими записями, с записями отдела или со всеми?
Формулировка «менеджеру доступен раздел сделок» слишком расплывчата для приёмки. Проверяемое правило выглядит так: «Менеджер читает и меняет закреплённые за ним сделки; чужие сделки не открывает; массовую выгрузку не запускает». Разрешение читать карточку не следует автоматически превращать в разрешение менять её или скачивать связанные документы.
OWASP в Authorization Cheat Sheet рекомендует минимально необходимые полномочия, запрет по умолчанию и проверку разрешений при каждом запросе. Для владельца CRM это означает: у каждого разрешения должно быть рабочее основание, а отсутствие согласованного правила не должно открывать доступ ко всему разделу.
Учебная матрица прав для отдела продаж
Ниже — пример для обсуждения с руководителем и разработчиком, а не готовая политика для любой компании. В нём менеджер ведёт свои сделки, руководитель перераспределяет работу внутри отдела, бухгалтер сверяет оплату. В вашей системе обязанности могут быть другими.
| Роль | Объект и область | Действие | Ожидаемый результат |
|---|---|---|---|
| Менеджер | Своя сделка | Просмотр и изменение этапа | Разрешено |
| Менеджер | Чужая сделка | Просмотр и изменение | Запрещено |
| Менеджер | Список клиентов | Массовый экспорт | Запрещено |
| Руководитель | Сделки своего отдела | Назначение ответственного | Разрешено |
| Руководитель | Сделки другого отдела | Просмотр и экспорт | Запрещено |
| Бухгалтер | Счета, переданные на сверку | Просмотр | Разрешено |
| Бухгалтер | Настройки пользователей | Изменение ролей | Запрещено |
Дополните каждую строку условием, если оно влияет на работу: подразделение, участие в сделке, статус документа, временное замещение. «Своя запись» тоже требует определения: созданная сотрудником и назначенная ему запись могут быть разными объектами.
Отдельно согласуйте доступ к чувствительным полям и вложениям. Например, возможность открыть сделку ещё не отвечает на вопрос, должен ли сотрудник видеть внутренний комментарий или договор. Не копируйте рабочую клиентскую базу в тестовую среду ради удобства проверки.
Если в CRM права приходят из нескольких ролей или групп, проверяйте их итоговое сочетание. Так, в Microsoft Dataverse разрешения суммируются: более узкая роль не отменяет доступ, полученный через другую роль или команду. Это пример конкретной реализации; правила объединения полномочий вашей CRM нужно уточнить в её документации.
Как проверить запреты на учебных записях
Для примера подготовьте двух тестовых менеджеров, руководителя и бухгалтера, а также сделки, принадлежащие разным ответственным и отделам. Используйте отдельные профили браузера, чтобы не перепутать учётные записи. Все испытания проводите в согласованной среде без настоящих писем, платежей и обменов с рабочими системами.
Просмотр. Первый менеджер открывает свою учебную сделку, затем известную прямую ссылку на учебную сделку второго менеджера. Во втором случае содержимое должно быть недоступно. Попросите разработчика проверить тот же запрет через API — программный интерфейс CRM, если он используется. В рекомендациях OWASP по IDOR отдельно разбирается проверка доступа к объекту: сложный или непредсказуемый адрес не заменяет такую проверку.
Изменение. На своей учебной сделке менеджер меняет разрешённое поле. На чужой выполняется согласованная отрицательная проверка: сервер должен отказать, а значение после проверки должно остаться прежним. Изменённый внешний вид кнопки или сообщение в браузере не доказывают, что данные защищены.
Экспорт. Проверьте не только наличие кнопки, но и состав полученного файла. В учебном примере менеджеру массовая выгрузка запрещена, а руководителю нельзя получить записи другого отдела. Если выгрузка создаётся фоновым заданием, разработчик отдельно проверяет получение готового файла по ссылке.
Связанные данные. Для закрытой сделки проверьте вложение, результаты поиска и доступные отчёты. Нужен конкретный ответ: какие сведения разрешено показывать этой роли? Название закрытого документа в подсказке тоже может быть нежелательным раскрытием.
Если обычная учётная запись получила запрещённые данные, остановите подключение этой роли к рабочей базе до разбора причины. Не продолжайте эксперимент на настоящих клиентах и не выгружайте их данные «для доказательства».
Как оформить результат, чтобы принять настройку
Для каждой строки матрицы заведите короткую запись проверки: роль, учебный объект, действие, ожидаемый результат, фактический результат и дата. Скриншот интерфейса полезен как дополнение; для изменения и экспорта важен ещё итог в данных или файле.
Пример такой записи: «Менеджер А → учебная сделка Б → изменение этапа → ожидается отказ; получен отказ; этап не изменился». Пароли, токены, персональные данные и полные ответы рабочей системы в отчёт не включают.
Настройку можно принимать в пределах согласованного объёма, когда:
- все разрешённые операции из матрицы выполняются под нужными ролями;
- запрещённые просмотр, изменение и экспорт не раскрывают данные и не меняют записи;
- проверены используемые пути доступа: интерфейс, API, отчёты и файлы;
- для сочетаний ролей результат совпадает с согласованными правилами;
- после изменения прав повторены затронутые проверки.
Если хотя бы одна строка остаётся без результата, у неё должны быть ответственный и решение о допустимости запуска. Пройденная матрица подтверждает проверенные сценарии, но не заменяет полноценную оценку безопасности системы.
Отключение сотрудника и отзыв уже открытых сессий — отдельная задача. Она разобрана в статье о доступе после блокировки пользователя; здесь проверяются полномочия действующих сотрудников.
Когда достаточно настройки, а когда нужна доработка
Если штатные роли CRM выражают вашу матрицу, а администратор может безопасно проверить её на тестовом контуре, начните с доступных настроек. Разработка не требуется только потому, что правил много. Общие критерии выбора решения есть в материале о настройке готовой CRM и разработке интеграций.
Помощь разработчика нужна, когда правило нельзя выразить штатными средствами, права расходятся между интерфейсом и API, выгрузка обходит ограничения или ошибка проявляется только при сочетании ролей. Выдавать всем права администратора ради устранения неудобства — неподходящий способ исправления.
OpenStart занимается доработкой CRM, ролей и рабочих процессов. Основа для обсуждения конкретной задачи — ваша матрица и один обезличенный пример расхождения между ожидаемым и фактическим доступом. По ним можно согласовать проверку и объём изменений; сроки и стоимость определяются после разбора системы. Передавать клиентскую базу или доступы в первом обращении не нужно.