Роли, права и согласования
Инструкция для администратора Zentro: как устроены права, как завести роль, выдать её, задать квоты по ролям и как работают согласования «двух пар глаз».
Роли сервиса проще завести мастером вместе с сервисом (Подключение сервиса), выдать людям — в карточке пользователя (Пользователи).
Как устроены права
Заголовок раздела «Как устроены права»Право — строка СЕРВИС:РЕСУРС:ДЕЙСТВИЕ заглавными: RHM:ENV:WRITE, IDENTITY:USER:BLOCK.
Любой сегмент может быть * — «любой»: RHM:*:VIEW — просмотр всего в RHM, RHM:*:* — всё в RHM.
- Первый сегмент — пространство прав (ключ сервиса). Приложения и API сервиса получают только
права своего пространства: права
RHM:…не попадут в токен дляDELIVERY. - Роль — именованный набор прав. Человеку выдают роли, не права.
- Права человека — объединение всех его активных ролей.
- Каталога прав нет: какие права понимает сервис, знает его команда. Формат проверяет сервер.
Права самого Identity — пространство IDENTITY. Встроенная роль IDENTITY_ADMIN = IDENTITY:*:*.
Для частичного доступа к панели соберите свою роль из прав IDENTITY:… — например, служба
поддержки: IDENTITY:USER:VIEW, IDENTITY:USER:BLOCK, IDENTITY:CREDENTIAL:RESET,
IDENTITY:SESSION:REVOKE (полный список по действиям — Пользователи).
Завести роль
Заголовок раздела «Завести роль»Роли → Создать роль.
| Поле | Что вписать |
|---|---|
| Имя | Заглавными, с префиксом сервиса: RHM_OPERATOR. Потом не меняется |
| Описание | Кому и зачем: «Дежурные инженеры — выкатка и откат» |
| Права | По одному в строке: RHM:*:VIEW, RHM:ENV:WRITE |
Список ролей — таблицей (по умолчанию) или карточками, переключатель справа над списком;
выбор запоминается в браузере. Поиск — по имени, описанию и правам (USER:VIEW найдёт все роли с
этим правом), фильтр — по сервису или «Вне сервиса». В таблице кнопка «Открыть» в строке
разворачивает роль: правка, удаление, носители — там.
- Системные роли (метка «системная») встроены и не меняются. Кастомные — ваши: «Изменить» (описание и права) и «Удалить».
- Изменение прав действует для всех носителей сразу; сервисы, проверяющие токены у себя, увидят его не позже чем через 15 минут.
- Удалённая роль перестаёт давать права всем, кто её носил.
- «Кто носит роль» в строке — носители и срок, если роль выдана на время.
Роль, созданная здесь, не входит ни в какой сервис. Чтобы она отключалась вместе с сервисом — Сервисы → сервис → Роли → включить существующую (права роли должны быть в пространстве сервиса).
Выдать роль
Заголовок раздела «Выдать роль»Пользователи → человек → Роли → Назначить роль — навсегда или на N минут (JIT). Подробно — Пользователи, «Выдать и снять роли».
Выдавайте минимально нужное: оператору — …_OPERATOR, а не …_ADMIN. Временный доступ на
дежурство или разбор инцидента — через JIT: снимется сам.
Последний администратор защищён: снять с него
IDENTITY_ADMIN, заблокировать или удалить Identity не даст. Считаются только администраторы с бессрочной ролью — выданная «на время» не спасёт, когда истечёт.
Квоты по ролям
Заголовок раздела «Квоты по ролям»Identity ограничивает, сколько запросов в минуту может сделать один вошедший пользователь или
сервисный клиент (security.user_rate_limit_per_min, по умолчанию 600). Некоторым нужно больше —
например, сервисным учёткам интеграций.
Настройки → Безопасность → security.user_rate_limit_by_role — строки «роль → число»:
- число — своя квота для носителей роли (может быть и ниже общей);
- «без лимита» — галкой (для сервисных учёток), не нулём;
- при нескольких ролях у человека действует самая щедрая;
- роли без строки живут по общей квоте.
Согласования («две пары глаз»)
Заголовок раздела «Согласования («две пары глаз»)»Необратимые операции — безвозвратное удаление пользователя и привязка аккаунта без подтверждения владельцем — выполняются только по одобренной заявке: подаёт один администратор, одобряет другой. Себе одобрить нельзя.
Как проходит:
- Инициатор подаёт заявку с причиной — в карточке пользователя (блок удаления или привязки; на удаление — ещё и Согласования → Подать заявку по ID пользователя).
- Другой администратор открывает Согласования — заявки, которые ждут решения, — и нажимает «Согласовать» или «Отклонить». На Обзоре такие заявки тоже видны.
- Когда набрано нужное число голосов, заявку исполняют в карточке пользователя. Заявка одноразовая и живёт ограниченное время.
Кто и сколько одобряет — Настройки → Безопасность:
| Настройка | По умолчанию | Смысл |
|---|---|---|
security.user_hard_delete.required_approvals |
1 | Сколько независимых одобрений нужно на безвозвратное удаление. 0 — согласования выключены, удаляет один администратор |
security.user_hard_delete.approver_roles |
IDENTITY_ADMIN |
Носители каких ролей могут одобрять |
security.user_hard_delete.approver_user_ids |
пусто | Конкретные сотрудники (их ID) — дополнительно к ролям |
Привязка без подтверждения владельцем всегда требует двух одобрений — это не настраивается. Последнего администратора удалить нельзя при любой политике.
Частые ошибки
Заголовок раздела «Частые ошибки»| Что видно | Причина | Что сделать |
|---|---|---|
| «Не удалось создать роль. Проверьте имя и права.» | Имя занято или право в неверном формате | Формат СЕРВИС:РЕСУРС:ДЕЙСТВИЕ, заглавными; другое имя |
| Нет кнопок «Изменить» / «Удалить» у роли | Роль системная | Создать свою с нужными правами |
| Сервис не видит новое право | Права другого пространства или токен ещё старый | Право — в пространстве сервиса; подождать до 15 минут |
| Кнопок «Согласовать» / «Отклонить» нет у заявки | Заявка ваша | Одобряет другой администратор |
| «Согласования отключены» на странице | required_approvals = 0 |
Так задумано: удаляет один администратор. Включить — число больше нуля |
| Голос не принимается | Вы не в списке одобряющих | Роль из approver_roles или ваш ID в approver_user_ids |
| У квоты роли: «Не меньше …; безлимит — галкой «без лимита», а не нулём» | Ноль — не «без лимита» | Галка «без лимита» |