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