ВНУТРЕННИЕ СИСТЕМЫ · ДОСТУП · 13 МИНУТ
Как определить роли и доступы
Отталкиваемся от действий людей: что можно увидеть, изменить, подтвердить и передать.
Короткий ответ: проектируйте доступ вокруг действий, а не названий должностей
Для каждой группы пользователей определите, что она должна видеть, создавать, изменять, подтверждать, выгружать и удалять. Затем отдельно отметьте действия, которые требуют повышенного контроля: изменение прав, финансовых условий, персональных данных, массовые операции и внешние отправки.
Пользователь получает только те данные и действия, которые нужны его текущей работе. Расширение права должно быть осознанным и проверяемым.
РАБОЧИЙ ОБРАЗЕЦ / ДЕМОНСТРАЦИОННЫЕ ДАННЫЕ
Три роли и четыре действия
На небольшом экране таблицу можно прокрутить в сторону →
| Роль | Смотреть | Менять | Подтверждать | Передавать |
|---|---|---|---|---|
| Клиент | Свою запись | Свой черновик | Нет | Ответственному |
| Специалист | Назначенные | Рабочие поля | Результат своей работы | На проверку |
| Руководитель | Согласованный контур | Назначения | Приёмку | Между ролями |
Это пример, не готовая политика. При смене роли проверяют и новые разрешения, и отзыв прежних. Нужный минимум доступа не равен абсолютной безопасности.
Как согласовать права участников
- Перечислите действия над конкретными объектами, а не только должности.
- Для каждой роли отметьте просмотр, изменение, подтверждение и передачу.
- Проверьте запреты, временный доступ и смену роли на тестовых аккаунтах.
Что учесть
Матрица — исходное правило, а не доказательство безопасности. Ограничения нужно реализовать и проверить на стороне системы, включая прямые запросы.
Подробный разбор, подготовка и вопросы
Начните с инвентаризации рабочих действий
Должность «менеджер» сама по себе мало говорит системе. Один менеджер создаёт записи, другой согласует условия, третий только просматривает отчёты. Составьте список объектов и действий: клиенты, заявки, документы, задачи, платежи, настройки, пользователи и отчёты.
- Какие данные пользователь должен находить и просматривать?
- Что он создаёт самостоятельно?
- Какие поля может изменять после создания?
- Какие действия требуют подтверждения другого человека?
- Может ли пользователь выгружать или массово изменять записи?
- Что происходит при смене роли или уходе сотрудника?
Редкие действия не обязательно превращать в постоянную роль. Для них можно предусмотреть временное разрешение или отдельный маршрут запроса.
Соберите матрицу ролей и прав
| Действие | Исполнитель | Руководитель | Администратор |
|---|---|---|---|
| Просматривать свои записи | Да | Да | По необходимости |
| Просматривать записи команды | Нет | Да | По необходимости |
| Изменять рабочий статус | В пределах процесса | Да | Нет |
| Менять чувствительные условия | Запрос | Подтверждение | Нет |
| Управлять пользователями | Нет | Нет | Да |
| Выгружать данные | Ограниченно | По разрешению | По политике |
Это пример логики, а не универсальная модель. Реальная матрица зависит от процесса, данных и правил компании.
Выделите чувствительные данные и необратимые действия
Не все поля и кнопки одинаково рискованны. Обычное изменение комментария отличается от удаления документа, смены банковских реквизитов или массовой отправки клиентам. Для чувствительных операций полезны подтверждение, ограничение по роли, журнал и возможность восстановления.
Персональные данные
Ограничить просмотр, выгрузку и использование только рабочей необходимостью.
Финансовые условия
Фиксировать автора, старое и новое значение, основание изменения.
Права пользователей
Отделить администрирование от обычной операционной работы.
Массовые действия
Показывать объём, последствия и запрашивать явное подтверждение.
Внешние отправки
Проверять получателя, содержание и допустимость автоматического действия.
Удаление
Использовать архив или период восстановления там, где это возможно.
Продумайте временные права и исключения
Жёсткая модель без исключений заставляет сотрудников обмениваться паролями или просить администратора выполнить обычную работу. Но постоянный полный доступ ради редкого случая создаёт другой риск. Зафиксируйте безопасный промежуточный путь.
- Пользователь отправляет запрос с причиной и сроком.
- Ответственный подтверждает конкретное право или действие.
- Система фиксирует выдачу и использование разрешения.
- Доступ автоматически прекращается или пересматривается.
- Спорный случай остаётся в журнале для разбора.
Для небольшого первого релиза часть механики может быть организационной, если она понятна и не скрыта от команды.
Проверьте модель доступа до подключения реальных пользователей
Создайте тестовую учётную запись для каждой роли. Пройдите не только разрешённые сценарии, но и попытки открыть чужую запись, изменить запрещённое поле, вызвать прямой URL, выполнить массовое действие или повторить запрос после смены роли.
| Проверка | Ожидаемый результат |
|---|---|
| Обычный рабочий сценарий | Доступ без лишних запросов и обходных путей |
| Запрещённое действие | Понятный отказ без раскрытия данных |
| Смена роли | Старые права прекращаются во всех интерфейсах |
| Прямой адрес или API | Ограничение работает не только на уровне кнопки |
| Журнал действий | Видны автор, время и содержание важного изменения |
| Уход сотрудника | Доступ закрыт, рабочие записи переданы |
Частые вопросы
Сколько ролей должно быть в первом релизе?
Столько, сколько существует устойчиво различающихся наборов задач и ограничений. Обычно полезно начать с нескольких рабочих ролей, а редкие исключения обрабатывать отдельно.
Можно ли дать всем полный доступ и ограничить позже?
Это создаёт лишний риск и усложняет последующую проверку. Безопаснее сразу выделить чувствительные данные и действия, а остальные права расширять по подтверждённой потребности.
Роль должна совпадать с должностью?
Не обязательно. Роль описывает задачи и права внутри системы. Один сотрудник может совмещать несколько ролей, а одинаковые должности — работать с разными участками процесса.
Какие действия нужно журналировать?
В первую очередь изменение чувствительных данных, прав доступа, финансовых условий, статусов, массовые операции, выгрузки и действия автоматизации.
Как проверить права перед запуском?
Создать тестовые учётные записи каждой роли и пройти типовые и запрещённые сценарии: просмотр, создание, изменение, удаление, экспорт и подтверждение чувствительных действий.
СЛЕДУЮЩИЙ ШАГ
Зафиксировать роли и основной сценарий первого релиза.
Определим рабочие действия, чувствительные зоны и проверяемую модель доступа.