Права доступа во внутренней системе: как составить матрицу ролей

Исполнитель вошёл во внутреннюю систему и видит форму проекта. Это ещё не означает, что он вправе менять любую задачу, скачивать вложения или выгружать список. Чтобы убрать такую неоднозначность, разложите каждое право на четыре части: субъект, объект, отдельное действие и проверяемая область.

Матрица прав нужна до разработки и приёмки. Она фиксирует рабочие решения, но сама по себе не доказывает безопасность системы: правила ещё предстоит реализовать и проверить.

Перечислите рабочие объекты и отдельные действия

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

Используйте заготовку «объект → операция → рабочая необходимость → владелец правила»:

Не объединяйте эти строки словом «редактирование». Изменение статуса, переназначение, удаление и согласование могут принадлежать разным ролям. Просмотр проекта также не даёт автоматически права выгрузить все его записи.

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

Заполните матрицу ролей и областей доступа

Рабочая строка должна отвечать не только на вопрос «можно ли», но и объяснять границу решения:

Слово «свои» замените проверяемой связью: assignee_id задачи совпадает с ID пользователя; проект указан в его действующих членствах; либо проект входит в перечень управляемых. Сравнение по отображаемому имени для этого не подходит.

Для списка, поиска и выгрузки действует та же граница: результат = записи в разрешённой области ∩ разрешённые поля. Если пользователь читает только один проект, поиск не должен раскрывать названия других проектов. Если экспорт ограничен несколькими полями, выгрузка не должна незаметно включать остальные.

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

Матрица описывает требования, а не навязывает конкретный RBAC-, ABAC- или иной движок. Одной метки роли может быть недостаточно: решение часто зависит от связи пользователя с конкретной записью.

Согласуйте совмещение ролей и исключения

Разберите по отдельности управление участниками, чтение рабочих данных, удаление, согласование и экспорт. Технический администратор может назначать утверждённую роль, но из этого не следует право читать или выгружать бизнес-данные.

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

Каждое исключение должно содержать:

1. объект, действие и область;
2. рабочее основание;
3. уполномоченного согласующего;
4. срок или событие окончания;
5. способ проверки отзыва.

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

Отделите скрытую кнопку от серверного запрета

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

В программу будущей приёмки включите:

• прямой переход к известной согласованной тестовой записи;
• замену идентификатора только между собственными тестовыми фикстурами;
• скачивание тестового вложения;
• поиск, список и экспорт;
• попытку запрещённого изменения.

При отказе сервер не возвращает закрытое содержимое и не выполняет изменение. Интерфейс показывает согласованное нейтральное сообщение. Отдельно фиксируйте HTTP-ответ, вид экрана, состояние данных и состав выдачи: ни один из этих признаков в одиночку не подтверждает корректное исполнение правила. Универсальный HTTP-код для всех архитектур назначать не нужно.

Не смешивайте отказ в праве с ошибкой обязательного поля. В первом случае действие запрещено этому субъекту или для этой области. Во втором пользователь может иметь право, но передал неполные данные.

Опишите смену роли и снятие доступа

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

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

Способ обновления сессий и кэша, а также допустимую задержку должен объяснить разработчик конкретной системы. Не обещайте мгновенный отзыв без проверки. Испытайте ранее открытую и новую сессию. Уже скачанная копия не исчезает автоматически после снятия права и требует отдельного правила обращения. Историю авторства записей удалять вместе с доступом не следует.

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

Разберите учебную матрицу проектного приложения

В демонстрационном примере проектов, задач и времени показана связь рабочих объектов. Он не подтверждает реализацию описанной ниже модели прав.

Учебный пример. Все роли, ID, правила и ожидаемые ответы придуманы для объяснения; это не права сотрудников, не клиентский кейс и не отчёт о тесте.

Есть проекты DEMO-P1 и DEMO-P2. Задача DEMO-T1 относится к DEMO-P1 и назначена DEMO-U1. DEMO-T2 относится к DEMO-P1, а DEMO-T3 — к DEMO-P2; обе назначены DEMO-U2. Сначала DEMO-U1 — Исполнитель и участник только DEMO-P1. Условный Руководитель проекта управляет только DEMO-P1.

Объекты закрыты. Неописанное действие не разрешено. Чтение проекта Исполнителем или Наблюдателем включает задачи этого проекта, но изменение ограничено назначенной задачей. Руководитель выгружает только ID проекта и ID, название и статус задачи; записи времени не входят в выгрузку. Это решения примера, а не готовая политика.

В рабочей версии к этим колонкам нужно добавить основание, согласующего и ID проверки. Пока они не согласованы, пример не следует переносить в систему.

T1. Чтение своего проекта. У DEMO-U1 есть членство в DEMO-P1, поэтому M1 разрешает чтение DEMO-P1 и его задач. DEMO-P2 в результат не входит.

T2. Изменение чужой задачи внутри своего проекта. DEMO-T2 находится в DEMO-P1, но назначена DEMO-U2. Условие M2 требует одновременно членство в проекте и назначение задачи субъекту. Второе условие не выполнено: отказ, запись не меняется.

T3. Прямая ссылка на чужой проект. DEMO-U1 открывает согласованную тестовую ссылку на DEMO-P2. Членства нет, поэтому M1 не применяется; закрытые данные не возвращаются.

T4. Изменение и экспорт — разные действия. DEMO-T1 назначена DEMO-U1 и находится в DEMO-P1, поэтому изменение разрешено по M2. Следующий запрос выгрузки DEMO-P1 отдельно запрещён по M4.

T5. Администратор без бизнес-роли. Администратор доступа может изменить утверждённое назначение по M8, но не может читать DEMO-P1 без отдельного бизнес-разрешения: отказ по M9.

T6. Смена Исполнителя на Наблюдателя. После подтверждённого применения у DEMO-U1 остаются роль Наблюдателя и членство в DEMO-P1. M11 разрешает чтение проекта. Строки, разрешающей Наблюдателю изменять DEMO-T1, нет, поэтому прежнее право не наследуется.

T7. Снятие всех назначений. После подтверждённого применения роли и членства DEMO-U1 пусты. Разрешающей строки нет, поэтому защищённый запрос DEMO-P1 должен быть отклонён. Фактический результат старой и новой сессии заполняют только при будущей проверке. История авторства сохраняется; прежние выгруженные копии рассматривают отдельно.

T8. Ограниченная выгрузка руководителя. По M7 Руководитель выгружает только данные DEMO-P1 и только ID проекта, ID, название и статус задачи. DEMO-P2 и записи времени отсутствуют.

T9. Неизвестное совмещение ролей. Для DEMO-U1 запрошены роли Исполнителя и Наблюдателя, но правило конфликта не определено. Вопрос возвращают владельцу. Нельзя автоматически разрешить редактирование, применить универсальный приоритет запрета или закрыть эту ветку приёмки.

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

Фактический результат не заполнен. Выше приведены только ожидаемые решения условной матрицы; приложение, сервер авторизации и права реальной организации не тестировались.

Превратите строки матрицы в сценарии приёмки

Для каждой применимой строки подготовьте положительную и отрицательную проверку. Используйте единый шаблон:

ID правила и версия → субъект и исходные назначения → объект и состояние → действие и канал → ожидаемое разрешение или отказ → фактический результат и подтверждение → ответственный.

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

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

Назначьте владельца матрицы и порядок изменений

Передайте команде один согласованный комплект:

• версию матрицы;
• принятые и неизвестные правила;
• основания и окончания исключений;
• сценарии с ожидаемыми результатами;
• ответственных за применение и проверку.

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

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

Матрицу стоит включить в техническое задание на автоматизацию процесса: она дополняет описание участников, данных и приёмки, но не заменяет общее ТЗ.

Switch On AI помогает согласовать роли, действия и критерии при разработке внутренней системы под рабочие роли. Для обсуждения подготовьте один процесс: роли, объекты, нужное действие и пример запрета. По обезличенной матрице можно проверить границы и согласовать следующий этап разработки — обсудить матрицу одного рабочего процесса.