Ролевая модель доступа нужна, чтобы каждый пользователь видел и делал только то, что ему положено, а администратор видел, кто что делал и когда. Без этого в системе с несколькими людьми быстро теряется контроль и доверие.
Три слоя ролей: кто и на каком уровне
Роль назначается пользователю и определяет набор доступных действий. В простых системах выделяют три-четыре слоя.
- Администратор управляет пользователями, задаёт правила (кто может загружать документы, менять статусы) и смотрит полный журнал.
- Консультант работает с документами и клиентами в рамках своей зоны: видит назначенные ему дела, но не видит чужих.
- Клиент заполняет свой кабинет, видит статус своего дела и загружает документы по запросу.
Роли различаются по методам API и полям данных. Консультант вызывает метод GET /documents/mine, администратор вызывает GET /documents и видит чужие. На уровне базы или приложения это реализуется через проверку прав перед каждой операцией.
Разделение прав по методам: что описать в ТЗ
Каждый метод API или страница в приложении требует правила доступа: какие роли могут его вызвать и с какими ограничениями.
- Список методов и прав. Для каждого метода и каждой роли указываем: может или не может. Для среднего приложения это таблица на 30-50 строк. Например:
POST /documents, администратор и консультант могут, клиент не может. - Видимость данных. Консультант видит только свои документы, администратор видит все. Это описывается фильтрами в запросах или на уровне базы (row-level security).
- Запись и изменение. Клиент может обновить свой номер телефона, но не может изменить статус дела. Консультант может изменить статус, но только своего дела.
Эту таблицу проверяем при оценке, она выявляет много вопросов. Заказчик может думать, что консультант видит всех клиентов, а на деле имелись в виду только назначенные. Лучше сразу вписать граничные случаи: может ли консультант изменить дату встречи, если клиент уже загрузил согласие?
Версии значимых данных и откат
Когда клиент или консультант меняет документ или статус, система сохраняет версию. Старые версии не удаляются, а архивируются. Система хранит, кто и когда сделал изменение.
Это нужно, если система работает с юридически значимыми данными. Журнал версий показывает, кто подписал документ и когда, если подпись поддерживается. Откатить изменение можно, восстановив старую версию, но откат тоже записывается в журнал.
Журнал каждого действия: что логировать
Логируется каждый вызов значимого метода: создание документа, смена статуса, загрузка файла, одобрение консультантом. В записи фиксируем дату и время (UTC), пользователя, метод API, параметры запроса, результат (успех или ошибка). Если данные изменились, сохраняем старое и новое значение.
Уровень детали зависит от требований. Если система работает с финансовыми данными, логируем каждое изменение суммы. Если речь о статусе, логируем переходы между статусами.
Журнал хранится в базе отдельно от основных данных, чтобы не замедлять приложение. Доступ к нему имеет администратор и, если нужен аудит, внешний аудитор.
Загрузка документов с проверкой прав
Клиент загружает документ в свой кабинет. Система проверяет: может ли этот клиент загружать в это поле, соответствует ли тип файла ограничению (PDF, DOCX), укладывается ли размер в квоту.
Консультант может загружать документы от имени клиента или от себя, например ответ на письмо. Администратор может загружать исправления.
Каждая загрузка логируется с именем файла и размером.
Маршрут клиента: пошаговый процесс
Дело или заявка проходит несколько этапов: подача, рассмотрение, согласование, исполнение, закрытие. На каждом этапе клиент видит, что произойдёт дальше и какие документы нужны.
Консультант видит карточку дела со всей информацией и переводит его в следующий статус. Клиент видит только этап, статус и сроки.
При проектировании уточняем: может ли клиент вернуться на шаг назад? Может ли консультант пропустить этап? Кто утверждает переходы? Это описываем в ТЗ как граф состояний или таблицу переходов.
Отчёты с публикацией и PDF
Администратор формирует недельный отчёт: количество принятых дел, время обработки, нагрузка по консультантам, задержки. Отчёт публикуется в кабинете и экспортируется в PDF.
Консультант видит свой отчёт: обработанные дела, средний срок, комментарии клиентов. Клиент видит статус своего дела и ориентировочный срок готовности.
Для этого нужна отдельная логика агрегации на уровне приложения или базы.
Из чего складывается модель
| Компонент | Что делает | Где находится |
|---|---|---|
| Модель ролей | Три роли, права по методам API | ТЗ, таблица доступов |
| Фильтрация данных | Кто видит свои данные, а кто чужие | База (RLS) или слой приложения |
| Логирование | Каждое значимое действие | Отдельная таблица в базе |
| Версии данных | История изменений без удаления | История с датой и пользователем |
| Маршрут | Граф состояний дела | ТЗ, таблица переходов |
| Отчёты | Агрегация по ролям и датам | Вычисляется по запросу или кешируется |
Как разделить доступ за один вечер: шаги и шаблон
Разделение прав не обязательно начинать с программы. Таблица доступов уже даёт понимание, кто что может делать.
Шаг 1. Список ролей. Выпишите всех, кто пользуется системой, и запишите роль одним словом: администратор, консультант, клиент.
Шаг 2. Список объектов. Что хранится в системе: документы, заявки, клиенты, отчёты.
Шаг 3. Для каждой пары роль и объект отметьте действия. Просмотр, создание, изменение, удаление. Если действие не нужно, ставим «нет».
Шаг 4. Добавьте ограничения. Кто видит только свои записи, кто не видит чужие данные, кто может менять статус.
Шаг 5. Отметьте спорные случаи. Например, может ли консультант перенести встречу, если клиент уже загрузил документ. Такие вопросы решаем до разработки, а не в процессе.
| Роль | Объект | Просмотр | Создание | Изменение | Ограничение |
|---|---|---|---|---|---|
| Администратор | Все заявки | да | да | да | нет |
| Консультант | Свои заявки | да | да | да | только назначенные клиенты |
| Клиент | Свои документы | да | да | нет | только свой кабинет |
Сделайте завтра: заполните таблицу для одной системы, которой пользуетесь сейчас, например для таблицы заявок или общего файла. Если таблицы не хватает, значит, вопрос доступа уже требует внимания, и это хороший повод обсудить задачу.
Частые вопросы
Нужно ли логировать чтение данных? Редко. Обычно логируют изменения: создание, обновление, удаление. Чтение логируют, если документ критичный (финансовый отчёт, медицинская карта) и важно знать, кто его смотрел. В ТЗ это описываем явно.
Может ли консультант менять данные клиента? Зависит от процесса. Если консультант может исправить ошибку в адресе или телефоне, это решается в ТЗ. Если нет, то нет. Право фиксируем явно, чтобы не было спора в конце.
Как долго хранить журнал? Обычно не меньше одного-двух лет, но срок зависит от отрасли и требований закона. Если система работает с персональными данными, учитываем 152-ФЗ, для госзакупок смотрим требования ФЗ-44. В ТЗ описываем срок хранения и процесс архивирования.
Если хотите спланировать ролевую модель и границы доступа для своей системы, опишите её в форме на сайте. Мы предложим, с чего начать: обычно с таблицы доступов и графа состояний.