Администрирование RBAC

Обновлено 07.09.2026

Руководство по разделу Администрирование RBAC: управление пользователями, ролями, правами доступа, внешними группами и просмотр журнала аудита.

Введение

Администрирование RBAC — раздел платформы Proto Observability для расширенного управления доступом на основе ролей (Role-Based Access Control). Раздел предоставляет единый интерфейс для:

Управления пользователями — приглашение, активация/деактивация, назначение ролей, сброс пароля
Управления ролями — создание пользовательских ролей, редактирование существующих
Настройки прав доступа — матрица разрешений по типам ресурсов и действиям
Привязки внешних групп — сопоставление групп из внешних провайдеров (LDAP/OIDC) с ролями платформы
Аудита — просмотр журнала всех действий, связанных с управлением доступом

Версия

Данный функционал доступен начиная с версии 200.

Доступ

Раздел «Администрирование RBAC» доступен только пользователям с правами администратора. Если раздел не отображается в меню, обратитесь к администратору платформы.

Как открыть: перейдите в раздел Администрирование RBAC в основном меню навигации платформы.

Пользователи

Вкладка «Пользователи» отображает таблицу всех зарегистрированных пользователей платформы.

Столбцы таблицы:

Столбец	Описание
Имя	Имя пользователя
Email	Адрес электронной почты
Роли	Назначенные роли (отображаются в виде тегов)
Последний вход	Дата и время последней авторизации

Возможности:

Поиск — фильтрация списка по имени или email
Фильтр по роли — отображение только пользователей с выбранной ролью
Пригласить пользователя — кнопка для отправки приглашения новому пользователю

Операции с пользователем (доступны через столбец действий):

Операция	Описание
Управление ролями	Назначение или отзыв ролей пользователя
Редактирование	Изменение данных пользователя
Сброс пароля	Установка нового временного пароля
Включить / Отключить	Активация или деактивация учетной записи

Роли

Вкладка «Роли» содержит список всех ролей, доступных в платформе.

Роли делятся на два типа:

Системные роли — предустановленные роли платформы (например, «Администратор», «Пользователь»). Системные роли отмечены специальным индикатором и не могут быть удалены.
Пользовательские роли — созданные администратором роли для специфических сценариев доступа.

Доступные операции:

Создание роли — укажите имя и описание для новой роли
Редактирование роли — изменение имени и описания существующей роли
Просмотр деталей — подробная информация о роли и связанных разрешениях

Права доступа

Вкладка «Права доступа» отображает матрицу разрешений — какие действия разрешены каждой роли для каждого типа ресурсов.

Структура матрицы:

Строки — типы ресурсов платформы (дашборды, алерты, сервисы, настройки и другие)
Столбцы — роли
Ячейки — действия, разрешенные для данной комбинации роли и типа ресурса (просмотр, создание, редактирование, удаление, администрирование)

Администратор может настроить разрешения для пользовательских ролей, изменяя значения в ячейках матрицы.

Системные роли

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

Ресурсно-ограниченные права

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

Поддерживаемые типы ресурсов для ограничения по экземпляру:

Тип ресурса	Пример ограничения
`service`	Доступ только к сервису `payment_bank`
`host`	Доступ только к хосту `db-01.internal`
`service_group`	Доступ только к группе сервисов (бизнес-приложению) `credit_conveyor`
`bt` (бизнес-транзакция)	Просмотр только конкретных ключевых бизнес-транзакций
`slo`	Редактирование только SLO определённой команды
`dashboard`	Редактирование только выделенных дашбордов

Версия

Ограничение по host и service_group доступно начиная с версии 201. Ограничение по service — с версии 200. Три измерения (service, host, service_group) образуют единую область видимости данных — см. раздел Ограничение доступа к данным.

Как настроить:

Откройте редактирование роли на вкладке Роли.
В секции прав доступа выберите тип ресурса и действия (просмотр, редактирование и т.д.).
Вместо подстановочного значения * (все ресурсы) укажите идентификаторы или имена конкретных ресурсов.
Сохраните изменения.

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

Администраторы

Пользователям с ролью администратора ({admin, *, *}) по-прежнему доступны все ресурсы платформы. Ресурсно-ограниченные права — инструмент тонкой настройки для обычных ролей.

Ограничение доступа к данным по сервисам, хостам и группам сервисов

Права на типы ресурсов service, host и service_group автоматически применяются ко всем запросам данных, которые выполняет пользователь в интерфейсе платформы. Платформа прозрачно добавляет фильтр по разрешённой области видимости, поэтому любой виджет на дашборде, Traces Explorer, Logs Explorer, Браузер метрик, разделы Инфраструктура → Хосты, Бизнес-приложения и SLO показывают пользователю только разрешённые данные — даже если сам запрос написан без явного фильтра.

Три измерения области видимости

Область видимости складывается из трёх независимых измерений. Каждое измерение можно оставить открытым (доступ ко всем), задать явным списком или не настраивать вовсе:

Измерение	Тип ресурса	Метка данных
Сервисы	`service`	`service`
Хосты	`host`	`host` (в метриках и трассах), `hostname` (в логах)
Группы сервисов	`service_group`	`service_group`

Для каждого измерения возможны три состояния:

Доступ ко всем (в интерфейсе — переключатель «Предоставить доступ ко всем …», в правах — ключ *). Снимает ограничение по данным полностью — см. оговорку об объединении ниже.
Список конкретных значений — доступ только к выбранным сервисам / хостам / группам.
Не настроено (для роли нет ни одной записи данного типа) — измерение не участвует в фильтрации.

Сопоставление строгое: запись данных без соответствующей метки (например, метрика без метки host) не попадает в выборку по этому измерению.

Как комбинируются измерения: объединение (ИЛИ)

Если у роли настроено несколько измерений, они объединяются по правилу ИЛИ (объединение): пользователь видит данные, которые попадают хотя бы под одно настроенное измерение.

Пример. Роль даёт доступ к сервисам cart, catalogue и к хосту backend-04. Пользователь увидит:

данные сервисов cart и catalogue — на любом хосте, где эти сервисы работают;
плюс любые данные хоста backend-04.

Это важно учитывать на страницах, сгруппированных по одному измерению. Например, в Logs Explorer при такой роли будут видны и логи хоста backend-04, и логи сервисов cart/catalogue — даже если эти сервисы работают на другом хосте. Это не сбой фильтрации, а следствие объединения: логи разрешённых сервисов видны везде, где эти сервисы запущены.

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

Чтобы, например, показать пользователю логи или метрики только одного хоста, оставьте в роли ограничение только по host и не добавляйте гранты по сервисам и группам сервисов. Комбинация «список сервисов + список хостов» из-за объединения (ИЛИ) расширяет, а не сужает выборку.

Доступ ко всем = снятие фильтра

Если любое из трёх измерений выставлено в «Доступ ко всем» (*), фильтр по данным снимается целиком, а не только по этому измерению. Например, роль с host = * и списком сервисов покажет данные всех сервисов и всех хостов. Открытое измерение всегда «перевешивает» списки в других измерениях.

Разворачивание групп сервисов

Грант на конкретную группу сервисов (service_group) при загрузке прав разворачивается в набор её сервисов-участников (по данным за последние 30 дней). Благодаря этому группа корректно отображается везде, где данные разделяются по сервисам, а не по группе, — в списке сервисов Traces Explorer, в фильтрах и в проверках доступа к трассам. Открытый грант (service_group = *) не разворачивается — он и так снимает ограничение.

Как фильтр применяется к источникам данных

Источник данных	Способ применения
PromQL (метрики)	На каждое настроенное ограниченное измерение добавляется отдельный `extra_filters[]`: `{service=~"…"}`, `{host=~"…"}`, `{service_group=~"…"}`. VictoriaMetrics объединяет эти значения по ИЛИ.
LogsQL (логи)	Добавляется `extra_filters` вида `(service:in("…") or hostname:in("…"))`. Хосты сопоставляются с полем логов `hostname`. Отдельного поля `service_group` в логах нет — доступ к группе доходит до логов через разворачивание группы в сервисы.
CubeJS (OLAP)	В JWT-токен CubeJS добавляются claim’ы `allowed_services`, `allowed_hosts`, `allowed_service_groups`, которые преобразуются в условия фильтрации через `queryRewrite`.

Поведение для разных категорий пользователей:

Администраторы (правило {admin, *, *}) и роли с открытым измерением (*) — видят все данные, фильтр не добавляется.
Пользователи с ограниченной областью видимости — видят объединение (ИЛИ) настроенных измерений.
Пользователи без прав на область видимости (нет ни одной записи service/host/service_group) — фильтр по данным не добавляется; доступ по-прежнему ограничивается правами на сам раздел (например, право view на logs).

Отказ в доступе

Если у пользователя нет прав на ресурс целиком (например, нет ни одного разрешённого SLO), вместо пустого результата отображается локализованная панель «Доступ запрещён» с пояснением. Это работает для виджетов APDEX, таблиц KBT, правил обнаружения, SLO, сегментов, правил извлечения бизнес-контекста и других.

Объединение прав из нескольких ролей

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

Практическое следствие: если пользователю, помимо роли с ограниченной областью видимости, назначена роль с доступом на чтение ко всем ресурсам (например, системная роль «Пользователь» / Viewer с правилом {view, *, *}), то открытое измерение этой роли снимает ограничение — пользователь увидит все данные.

Проверьте членство во внешних группах

Роль может назначаться не только напрямую, но и автоматически — через членство во внешней группе (LDAP/OIDC или встроенное сопоставление, см. Внешние группы). Если пользователь с ограниченной ролью всё равно видит все данные, проверьте, не состоит ли он в группе, сопоставленной с ролью «Пользователь» (Viewer) или «Администратор». Членство в группах задаётся в провайдере учётных записей (например, в Keycloak), а не в разделе «Администрирование RBAC».

Внешние группы

Вкладка «Внешние группы» позволяет настроить автоматическое назначение ролей платформы на основе групп из внешних провайдеров учетных записей (LDAP, OpenID Connect).

Принцип работы:

При входе пользователя через SSO (LDAP или OIDC) платформа определяет его группы во внешнем провайдере. Если для этих групп настроено сопоставление, пользователю автоматически назначаются соответствующие роли платформы.

Доступные операции:

Просмотр сопоставлений — таблица существующих привязок «внешняя группа — роль платформы»
Добавить сопоставление — диалоговое окно для создания новой привязки: укажите имя внешней группы и выберите роль платформы

Настройка SSO

Для использования внешних групп необходимо предварительно настроить подключение SSO (LDAP или OIDC). Подробнее см. Настройка RBAC.

Привязка групп LDAP/OIDC

В таблице сопоставлений каждая запись имеет источник (source_type), который определяет, откуда ожидается имя группы:

Источник	Когда использовать
LDAP	Для пользователей, аутентифицируемых через LDAP-каталог (Active Directory и т.п.)
OIDC	Для пользователей, входящих через внешнего OIDC-провайдера
Встроенный (built-in)	Предустановленные сопоставления для исторических имён групп — их нельзя удалить, только отключить

Настраиваемое имя claim для OIDC

По умолчанию платформа ожидает, что OIDC-провайдер передаёт список групп пользователя в claim groups. Если ваш провайдер использует другое имя (например, roles, ldap_groups, cognito:groups), его можно указать в настройках Keycloak — платформа корректно извлечёт группы из произвольного claim.

Унаследованные сопоставления

При обновлении с предыдущих версий платформы исторические имена LDAP-групп автоматически сохраняются как встроенные (built-in) сопоставления. Это гарантирует, что существующие пользователи не потеряют доступ после миграции на v200.

Журнал аудита

Вкладка «Журнал аудита» — хронологический журнал действий пользователей в платформе. Он отвечает на вопросы службы информационной безопасности и аудиторской проверки: кто, когда, с какого адреса, над каким объектом выполнил действие и чем оно закончилось.

Версия

Начиная с версии 202 журнал переработан: добавлены отдельные потоки событий, состояние объекта «до» и «после», быстрые фильтры и экспорт. До версии 202 журнал охватывал только операции управления доступом.

Потоки событий

Журнал разделён на потоки, переключаемые в верхней части экрана:

Поток	Что попадает
Изменения	Создание, изменение и удаление объектов: роли и права, правила алертинга, окна обслуживания, отчёты, дашборды, ресурсы РСМ и другие
Доступ	Обращения на чтение данных: просмотр, выгрузка, запуск операций
Все	Оба потока вместе

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

Фильтры

Фильтр	Назначение
Период времени	Интервал, за который показываются события
Пользователь	Кто выполнил действие
Действие	Создал, изменил, удалил, просмотрел, выгрузил, обновил, запустил, отменил, запустил расследование
Тип ресурса	Класс объекта: сервисы, хосты, дашборды, инциденты, SLO, окна обслуживания, отчёты, администрирование RBAC и другие
Результат	Разрешено, Отказано, Ошибка
Объект	Поиск по объекту: точное совпадение по идентификатору или начало имени
IP-адрес	Адрес, с которого выполнено действие

Отдельно доступны быстрые срезы — «Только отказы» и «Изменения прав доступа»: первый показывает попытки выполнить действие без прав, второй — изменения в модели доступа. Это два самых частых запроса службы безопасности.

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

Состояние «до» и «после»

Для изменений прав доступа и окон обслуживания в подробностях события показывается таблица изменённых полей: Поле, Было, Стало. Не нужно сравнивать две версии объекта вручную — видно, что именно поменялось.

Дополнительно в подробностях доступны технические данные: ID запроса, User-Agent, HTTP-метод, код ответа, параметры запроса (только имена — значения не сохраняются) и исходный JSON события с копированием в буфер обмена.

Ограничения размера

Тело запроса сохраняется, если оно в формате JSON и не превышает 64 КБ; иначе событие содержит пометку об этом. Крупные подробности могут быть сохранены частично — такие записи помечаются явно, «молчаливого» усечения нет.

Экспорт

Журнал выгружается в CSV и JSON. Выгружается вся выборка по текущим фильтрам, а не только текущая страница. Если выборка не поместилась в файл целиком, выводится предупреждение с числом событий — период следует сузить и повторить выгрузку.

Для непрерывной передачи событий во внешние системы используйте экспорт в SIEM.

Сроки хранения

События потока Изменения хранятся 365 дней, потока Доступ — 90 дней.

Обновление платформы до версии 202 выполняется без перезаписи данных: записи, накопленные в предыдущих версиях, сохраняются и хранятся 365 дней, но не содержат новых полей (состояние «до/после», категория события).

Права доступа

Просмотр журнала требует права администратора. Если схема журнала на стенде ещё не обновлена, интерфейс сообщает об этом отдельно — часть возможностей в таком режиме недоступна.