RBAC для trading/operations console: least privilege и break-glass

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

Сначала выписать действия, затем собирать роли

Полезный черновик выглядит приземлённо: read, simulate, propose, approve, apply, rollback, manage-credentials. После этого каждому действию задают scope — environment, competition, provider, market или иной предметный контур. Роль появляется только как удобная упаковка этих разрешений. Такой порядок снижает риск «универсальных операторов», которым исторически выдали всё сразу.

Название отдела само по себе не является security boundary. Два человека из одной команды могут выполнять разные функции: один готовит изменение, второй подтверждает, третий имеет только read-only доступ для диагностики. Если роль описывается фразой «доступ инженера», она почти наверняка слишком широкая.

Критичное изменение должно иметь второго участника

Separation of duties полезна там, где одиночная ошибка способна повлиять на публикуемое состояние или усложнить последующее расследование. Не каждое действие требует двух человек: чтение метрик и временное открытие диагностической панели обычно дешевле оставить простыми. Но изменение trading rule, policy, credential или production-конфигурации стоит рассматривать отдельно и явно фиксировать, нужен ли независимый approval.

В журнале важен не только факт «разрешено». Нужны actor, выбранный scope, причина, версия до и после, идентификатор request/approval и результат применения. Тогда review отвечает на конкретный вопрос: кто инициировал изменение и что именно было изменено, а не просто показывает строку «admin action».

Break-glass — режим инцидента, а не постоянная роль

Аварийное расширение прав должно отличаться от обычной работы. У него есть причина, короткий срок жизни, повышенная наблюдаемость и обязательный разбор после использования. Если «суперправа» выдаются заранее и никогда не отзываются, break-glass превращается в обход всей модели least privilege.

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

Интерфейс обязан показывать границу действия

Авторизация на backend не спасает от ошибки, если оператор не видит, к чему относится кнопка. Перед подтверждением стоит явно показывать environment и предметный scope, а для опасных операций — также ожидаемое изменение состояния. Особенно полезно это при одинаково названных турнирах, рынках или provider routes.

Отдельная защита нужна от «тихих» массовых действий. Bulk change должен показывать количество затронутых сущностей и не маскировать частичный failure. Если применились 98 изменений из 100, оператор должен получить именно такой результат, а не зелёный статус всей операции.

Access review проверяет необходимость, а не красивую таблицу

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

Для RIF хороший критерий качества RBAC — возможность ответить на четыре вопроса без ручной реконструкции: кто выполнил действие, в каком scope, на каком основании и какое состояние получилось. Всё остальное — детали конкретной IAM-платформы.

Machine identities не должны прятаться за ролью оператора

Часть действий в консоли со временем автоматизируется: scheduled change, reconciler или deployment job вызывает тот же backend. Не стоит выдавать автоматике «человеческую» роль общего назначения. Отдельная machine identity с узким scope делает журнал понятнее и позволяет отозвать только конкретный automation path. Если человек вручную запускает автоматическую процедуру, audit trail должен связывать initiator и исполнителя, а не выбирать одного из них.

Удаление роли тоже требует проверки зависимостей. Если automation или дежурная процедура всё ещё рассчитывает на старое permission, внезапный revoke может проявиться только во время аварии. Перед снятием доступа полезно видеть фактическое использование и владельца каждой интеграции.

Break-glass доступ имеет смысл только как наблюдаемое исключение

Аварийная роль не должна быть скрытым способом обойти обычные правила. Для неё заранее определяют основание, срок, расширенный audit и последующий review. После завершения инцидента доступ снимается автоматически или по проверяемой процедуре, а факт использования входит в evidence package критичного изменения. Тогда emergency path остаётся рабочим инструментом, но не превращается в постоянную привилегию, о которой вспоминают только во время аудита.