Вход пользователя в систему не даёт ему права видеть все сведения. Аутентификация подтверждает личность, а разрешение определяет доступ к конкретному действию. В CRM различие проявляется в клиентах, финансовых записях, отчётах и выгрузках. Скрытия кнопки для решения задачи недостаточно.
Руководство OWASP рекомендует минимально необходимые права, запрет по умолчанию и проверку каждой операции. Бизнес должен объяснить, какие данные нужны роли и для какой задачи.
Разделяйте роль и пользователя
«Айcель видит все заказы» — личное исключение, а «руководитель филиала видит заказы филиала» — правило. Ролевая модель упрощает замену сотрудника. Один человек может совмещать обязанности, но их сочетание не должно незаметно создавать чрезмерный доступ.
Должность и программная роль не обязательно совпадают. Временное замещение может требовать дополнительных полномочий на определённый срок. Следует сохранять, кто и до какого момента их выдал. У исключений тоже должны быть понятные границы.
Подготовьте матрицу операций
Просмотр, создание, изменение, удаление и выгрузка клиента — разные действия. Разрешение смотреть карточку не означает автоматического права удалить её или скачать всю базу. Таблица основных действий по группам данных упрощает первоначальное согласование.
- Каких клиентов видит менеджер?
- Кто меняет ответственного за клиента?
- Кто редактирует суммы и записи оплаты?
- Кто может выгрузить всю клиентскую базу?
- Кто восстанавливает удалённую запись?
У данных есть собственные границы
Два пользователя могут иметь функцию просмотра заказов, но видеть разные записи. Проверка относится не только к действию, но и к конкретному объекту. Границы могут зависеть от филиала, команды, ответственного или участия в проекте.
Объясняющий пример: у компании есть филиалы Баку и Гянджи. Менеджер видит свои работы, руководитель филиала — работы подразделения, общая дирекция — согласованные итоги. Это условная модель. Правило должно одинаково работать в поиске, отчёте, уведомлении и выгрузке.
Отдельно продумайте экспорт и документы
Экран может показывать немного информации, тогда как файл экспорта раскрывает всю базу. Назначение массовой выгрузки, её поля и ответственная роль требуют отдельного согласования. Даже итог отчёта способен косвенно сообщить сведения о записях, которые пользователь не должен видеть.
Если любой знающий адрес скачивает документ, права карточки не защищают файл. Доступ к договорам и персональным материалам — часть модели приложения. Его устройство необходимо заранее описать в техническом задании.
История и согласование
Для важных изменений полезно видеть автора, время и действие. История не должна превращаться в бессрочное хранилище всех секретных сведений: назначение и срок хранения записей согласуются. Пароли и токены доступа не следует записывать в обычный журнал изменений.
Иногда изменение и его подтверждение относятся к разным обязанностям. Например, новая сумма заказа может требовать согласования. Если добавить подтверждение ко всем операциям без необходимости, ежедневная работа усложнится. Правило должно соответствовать реальному риску и процессу.
Как проверять разрешения?
- Создайте пример пользователя каждой роли.
- Выберите доступные и запрещённые записи.
- Проверьте прямой переход по адресу страницы.
- Сравните поиск, отчёты и экспорт.
- Проверьте прежний доступ после смены роли.
- Посмотрите поведение сессии при закрытии аккаунта.
Пример исключения: временное замещение
Представим сотрудника, которому на время отсутствия руководителя нужно выполнять некоторые согласования. Это условный случай. Вместо передачи чужого аккаунта следует определить дополнительные операции и срок. Работа под чужим именем смешивает авторство истории.
После окончания замещения право необходимо отозвать. Чтобы действие не зависело только от памяти, задают конечную дату, ответственного и проверку. Отзыв разрешения не равен удалению уже выгруженных сведений с устройства, поэтому экспорт рассматривается отдельно.
- Запишите временно доступные виды подтверждения.
- Укажите начало и окончание полномочия.
- Проверьте реального автора в истории.
- После завершения повторите проверку доступа.
Пример показывает, что разрешения не являются однажды настроенным и забытым списком. При изменении рабочих условий их обоснование продолжается. То же относится к переходу сотрудника в другой филиал, смене должности и закрытию учётной записи.
Отдельная ситуация — уже открытая страница. Если права изменились, сохранённая кнопка в браузере не должна позволять новое запрещённое действие. Проверяют не только обновлённое меню, но и повторную операцию из прежнего состояния интерфейса. Это практический сценарий, который помогает увидеть разницу между визуальной настройкой и действительным контролем.
Частые вопросы
Видит ли администратор всё?
Это зависит от согласованной модели. Технический администратор и руководитель, анализирующий бизнес-данные, могут иметь разные задачи.
Достаточно ли старой роли для новой функции?
Новая операция оценивается отдельно. Название прежней роли не следует автоматически считать широким разрешением.
HR Proqramı — пример продукта с контекстом конфиденциальных данных; запись не раскрывает его внутренние механизмы. Матрица проверяется при внедрении CRM, а в разработке системы правила учитываются на сервере и в интерфейсе вместе.
