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