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