Я не называю доступ ролью, пока сотрудник не может объяснить своё действие в системе

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

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

Начинаю не с должностей, а с действий

Я бы не спрашивал: «Какие роли нужны?» Сначала полезнее разложить один реальный сценарий. Допустим, компания принимает заказ: сотрудник создаёт его, другой проверяет условия, третий подтверждает отгрузку, руководитель видит отклонения. Для каждого шага можно назвать действие, объект и границу.

Не «менеджер работает с заказами», а «создаёт черновик своего заказа», «видит заказы своей группы», «не меняет отгруженный документ». В этой формулировке уже есть материал для нормального права. Сотруднику понятно, что он может сделать. Команде понятно, какое исключение надо обсуждать, а не обходить общей учётной записью.

Одна роль не должна быть универсальным ключом

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

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

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

Роль должна помогать в обычный понедельник

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

Если ответ — «пусть кто-нибудь зайдёт под учётной записью администратора», система уже зависит не от процесса, а от личной договорённости. Гораздо лучше, когда замещение, просмотр и согласование предусмотрены отдельно. Такой принцип работает и в других правилах: замена человека не должна открывать весь сейф. В статье о замещении согласующего этот момент виден особенно хорошо.

Как не превратить управление доступами в бесконечный проект

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

1. Кто создаёт операцию и какие данные может исправить до отправки?
2. Кто принимает решение и на основании чего?
3. Кто может отменить или скорректировать результат?
4. Кто видит историю и замечает нетипичное действие?
5. Как доступ выдаётся, пересматривается и снимается при смене роли?

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

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

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

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

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