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