Руководитель филиала может согласовывать закупки. Но только своего филиала, в пределах установленной суммы и не те, которые создал сам. Роль «руководитель» описывает одну часть правила. Остальное зависит от конкретной заявки и обстоятельств решения.
На таких примерах полезно сравнивать RBAC и ABAC. Не выбирать, какая аббревиатура современнее, а выяснить, где хранить правило, откуда брать нужные сведения и как объяснить отказ человеку, который считает, что у него есть все необходимые полномочия.
Роль отвечает за обязанность, но может иметь ограничения
В RBAC разрешения объединяют в роли и назначают пользователям. Например, специалист создаёт заявку, согласующий утверждает её, аудитор читает завершённые решения. Роль не обязана совпадать с должностью из кадровой системы: человеку могут быть поручены несколько разных обязанностей.
Было бы неверно описывать RBAC как примитивную проверку одного названия. Модель допускает иерархии, ограничения и разделение обязанностей. NIST отдельно рассматривает эти возможности. Поэтому запрет согласовывать собственную заявку сам по себе ещё не требует полной замены системы ролей.
Проблема начинается, когда каждое сочетание филиала, категории закупки и временного исключения превращается в новую роль. Названия растут, а руководителю всё труднее подтвердить, кому действительно нужен каждый набор прав. Обратный выход — дать всем слишком широкую роль — упрощает администрирование за счёт защиты.
Атрибуты позволяют выразить правило ближе к заявке
ABAC принимает решение по признакам участника, ресурса, действия и, при необходимости, окружающих условий. Такое определение даёт NIST SP 800-162. В закупках пригодятся назначенный филиал, сумма, автор заявки и предел полномочий согласующего.
Правило можно сформулировать обычным предложением: действующий согласующий утверждает заявку своего филиала в пределах лимита, если он не её автор. Роль остаётся полезной, а атрибуты уточняют область действия. Нет необходимости переносить все простые права в отдельный сложный механизм.
Если существенна связь «назначен ответственным за эту конкретную заявку», её тоже надо представить явно. Такие отношения удобно рассматривать отдельно, иногда через relationship-based access control. Ни роль, ни набор общих признаков не должны случайно подменять отсутствующее назначение.
Кто имеет право менять признаки, от которых зависит доступ
Пусть правило написано верно, но филиал берётся из поля, которое пользователь может свободно прислать в запросе. Тогда проверка опирается на его утверждение о себе. Нужен доверенный источник: подтверждённое назначение, запись в системе или проверенные сведения от службы идентификации.
У каждого значимого атрибута должны быть владелец, способ изменения и срок актуальности. Если сотрудник перешёл в другой филиал, а приложение ещё видит вчерашнюю принадлежность, формально правильная политика даст неправильный результат. Важно измерять путь обновления, включая кэши и сведения внутри уже выданных токенов.
Объект тоже меняется. После согласования кто-то исправил сумму закупки. Старое разрешение нельзя автоматически переносить на новый вариант заявки. Нужна связь решения с проверенной версией данных и повторная проверка существенных условий перед выполнением. Это конкретное бизнес-ограничение, а не свойство, которое возникает после установки движка политик.
Нельзя ограничить только видимые кнопки
Скрытая кнопка согласования улучшает интерфейс, но не защищает сервер от прямого запроса. Те же права должны проверяться в API, выгрузках, поиске и фоновых операциях. Для заранее поставленного задания нужно определить, от чьего имени оно выполняется и должны ли полномочия оставаться действующими к моменту исполнения.
Важны и права на конкретный объект. Разрешение читать заявки не означает разрешение читать заявки любой организации. Эти требования, проверки каждого обращения и отказ по умолчанию разобраны в руководстве OWASP по авторизации.
Отказ службы проверки не должен превращаться в разрешение «на время аварии». Но его полезно отличать от обычного запрета: поддержке нужно знать, отсутствует ли назначение или недоступен источник данных. Пользователю можно объяснить невозможность операции без раскрытия чужой заявки или внутренних секретов.
Почему система сказала «да» вчера и «нет» сегодня
Для расследования нужны правило, его версия, результат и необходимые сведения о контексте решения. Сегодняшнее состояние кадрового справочника не всегда объясняет вчерашнее разрешение. При этом нельзя ради аудита бесконтрольно копировать в журналы документы и персональные данные.
Пример такого механизма — журналы решений Open Policy Agent, где предусмотрены сведения о проверке и фильтрация чувствительного содержимого. Конкретный инструмент вторичен: поддержка должна восстановить основание решения, имея необходимые права на такую диагностику.
Если правил несколько, заранее определяют порядок их совместного применения. Одно даёт руководителю общее разрешение, другое запрещает согласовывать своё. Какой результат получится при пересечении? И что будет, когда атрибут отсутствует? Эти случаи стоит закрепить в проверках до изменения политики.
Менять модель через спорные решения, а не число ролей
Возьмите несколько реальных случаев, для которых регулярно создают исключения. Запишите ожидаемый результат: заявка своего филиала, соседнего, собственная, с изменённой суммой, с истёкшим назначением. Проверки должны подтверждать разрешённую работу и запрещать лишнее. Успешный вход одного администратора почти ничего не доказывает.
Новое правило можно сначала сравнить с действующим на разрешённых тестовых данных или в режиме наблюдения, где оно ещё не выдаёт права. Расхождения разбирают с владельцем процесса. Возврат к старой политике также оценивают по результату: он не должен восстановить доступ, отозванный намеренно.
Для закупок разумным итогом может остаться несколько устойчивых ролей с ограничениями по заявке. У другой системы понадобится более развитая модель атрибутов и отношений. Выбирать стоит по возможности выразить правила, поддерживать их источники и объяснять решения, а не по обещанию однажды избавиться от всех исключений.