Я проектирую доступы вокруг операций, а не должностей

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

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

Сначала — действие и последствия

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

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

Роль — это удобная упаковка, а не источник истины

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

Полезная проверка звучит так: можно ли объяснить право одной фразой без имени сотрудника? Например, «специалист смены подтверждает фактический выпуск на своём участке, но не меняет нормативы». Если ответ приходится искать в старой переписке, правило уже слишком мутное.

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

Временный доступ должен уметь заканчиваться

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

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

Нужен след, а не тотальный контроль

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

Хороший журнал связывает изменение с объектом и причиной. «Изменено поле» — слабая запись. «Изменён лимит по клиенту после согласования» уже даёт контекст. Заодно такой журнал помогает улучшать сам процесс: если одна и та же корректировка повторяется, возможно, система неверно отражает правило работы.

Как собрать матрицу без бесконечной таблицы

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

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

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

Три ошибки, которые дорого обходятся

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

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

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

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

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

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

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

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