# Роли в приложении: как описать доступ к данным и действиям

Источник: https://quicklanding.ru/knowledge/app-user-roles/

Как составить матрицу доступа для приложения: действия, область данных, смена сотрудников и серверная проверка прав.

Фраза «администратор видит всё, сотрудник видит своё» кажется достаточной, пока в системе не появляется второй филиал или новый руководитель. Что считать своим: созданную заявку, назначенную задачу или все заказы компании? Роли нужно описывать через данные и действия, иначе каждая новая функция будет заново решать вопрос доступа.

## Сначала перечислите действия

![Рабочие места в офисе компании](/assets/images/knowledge/app-user-roles.webp)

Просмотр, создание, изменение, удаление, выгрузка и назначение ответственного имеют разный смысл. Право открыть карточку не должно автоматически давать возможность скачать все вложения или изменить статус. Для каждого действия укажите, зачем оно нужно конкретной группе пользователей.

Например, менеджер может видеть назначенные обращения и менять рабочий комментарий. Руководитель просматривает обращения своего филиала и перераспределяет их. Сотрудник, выдающий доступы, не обязательно должен читать документы всех клиентов. Это условная схема, которую уточняют по реальному процессу.

## Добавьте область данных

Одна роль может работать в пределах проекта, филиала или организации. Запишите, по какому признаку определяется принадлежность записи. Проверка должна опираться на серверные сведения, а не на идентификатор организации, присланный самим пользователем.

| Действие | Область | Условие |
| --- | --- | --- |
| Просмотр заказа | Заказы своей компании | Подтверждённая связь аккаунта |
| Изменение заявки | Назначенные обращения | Разрешённое рабочее состояние |
| Выдача доступа | Согласованная группа | Отдельное право управления |
| Выгрузка | Разрешённый набор записей | Проверка права и состава полей |

Такая матрица помогает заметить противоречия до разработки. Если руководитель видит карточку, но не имеет права открыть документ, интерфейс должен объяснять это состояние. Случайные ошибки «файл не найден» скрывают проблему прав и мешают поддержке.

## Проверяйте каждый серверный маршрут

Скрытие кнопки делает интерфейс понятнее, но запрос можно отправить напрямую. Проверяйте доступ при чтении, изменении, загрузке файлов и выгрузке. Отдельно учитывайте фоновые действия и интеграции, которые выполняются без обычной пользовательской страницы.

По умолчанию неизвестная комбинация прав должна получать отказ. При добавлении новой функции её доступ согласуют явно. Не наследуйте автоматически максимальные возможности только потому, что пользователь уже вошёл в приложение.

## Опишите смену ответственности

Сотрудник может перейти в другой филиал, уволиться или временно замещать коллегу. Определите, как меняются права и судьба назначенных записей. Отзыв доступа должен применяться к действующим сеансам и серверным операциям в соответствии с выбранной моделью.

Если клиентская компания приглашает своих сотрудников, ограничьте круг полномочий приглашающего. Он не должен выдавать доступ к другим организациям. Полезно фиксировать, кто создал приглашение, кому оно адресовано и какие права согласованы.

## Не превращайте удобство в общий аккаунт

Общий вход отдела мешает понять, кто изменил данные, и усложняет отзыв доступа. Отдельные аккаунты позволяют связать действие с сотрудником. Служебные ключи интеграций должны храниться отдельно от пользовательских паролей и иметь ограниченную область применения.

В журнале отмечайте значимые изменения прав и действий. Состав журнала выбирайте по задаче расследования, избегая записи паролей, токенов и лишнего содержимого документов. Права доступа к самому журналу тоже относятся к модели приложения.

## Принимайте права по отрицательным сценариям

Проверьте не только успешный вход. Пользователь одной организации пробует открыть чужой заказ, сотрудник без права изменения отправляет запрос вручную, отозванный аккаунт использует старую сессию. Прямой адрес файла должен соблюдать те же ограничения, что и карточка.

В QuickLanding можем подготовить матрицу по вашим должностям и действиям, затем включить её в задание и приёмку. Такая работа помогает развивать приложение без постоянных исключений, которые известны одному разработчику и не отражены в правилах компании.

## Документация и проверка сведений

Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.

- [OWASP: проверка прав доступа](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [OWASP: безопасная загрузка файлов](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)

## Материалы по соседним задачам

- [Личный кабинет клиента: какие функции нужны в первой версии](/knowledge/client-portal-scope/)
- [Техническое задание на сайт: как описать результат без лишней документации](/knowledge/website-specification/)
- [Приложения и интеграции](/services/development/)

## Частые вопросы

### Можно начать с двух ролей?

Да, если их действия и область данных определены. Количество ролей само по себе не показывает качество модели. Две ясные роли лучше десяти названий с неявными исключениями.

### Почему нельзя защищать страницу только скрытой кнопкой?

Пользователь способен отправить запрос без интерфейса. Сервер должен самостоятельно проверить право на запись и действие. Это относится и к файлам, и к выгрузкам, и к отдельным API.

### Нужен ли доступ разработчику ко всем данным?

Не автоматически. Определите задачу, необходимый объём и срок доступа. Для диагностики можно использовать тестовые данные или ограниченный маршрут. Техническая поддержка не должна безусловно наследовать полномочия владельца.

Автор: Владимир Николаев