Принцип минимальных привилегий означает, что пользователь получает только те возможности, которые нужны для его задач. Это не запрет на работу, а способ ограничить последствия ошибки, захвата аккаунта или ненужной выгрузки.
Опишите реальные роли
Начните с действий: просмотр заказов, изменение цены, экспорт клиентов, управление пользователями. Затем сопоставьте их должностям. Названия ролей в программе не всегда отражают фактические полномочия, поэтому проверяйте каждую критичную операцию.
Как выдать права
- Создать базовую роль для обычной работы.
- Отделить администрирование от повседневного аккаунта.
- Выдавать дополнительные возможности по согласованной заявке.
- Ограничивать срок временных разрешений.
- Пересматривать права при смене должности и завершении проекта.
Проверяйте не только видимые кнопки
Скрытая кнопка экспорта не гарантирует запрет операции. В приложении ограничения должны проверяться сервером для каждого запроса. Для приёмки разработчик может использовать тестовые аккаунты с разными ролями и подтвердить, что один клиент не получает документы другого. Проверки выполняют в согласованной среде без реальных чужих данных.
Отдельно учитывайте наследование прав через группы, общие ссылки и подключённые приложения. Пользователь может не иметь прямой роли администратора, но получить тот же доступ через другую группу.
Как избежать постоянных исключений
Если сотруднику ежедневно приходится просить администратора выполнить обычное действие, роль спроектирована неудобно. Исправьте модель, а не выдавайте полный доступ навсегда. Для аварийных полномочий нужен отдельный порядок с фиксацией причины и последующим отзывом.
Критерий результата
Проверка должна подтверждать и разрешённые, и запрещённые операции. Менеджер выполняет свою работу, но не меняет пользователей; подрядчик видит нужный проект, но не весь портфель клиентов. Такой контроль полезно повторять после обновлений и подключения интеграций, поскольку они могут менять фактические границы доступа.
Дополнительно: OWASP: проверка полномочий.
