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

На этой странице:

• Введение
• Пользователи
• Роли
• Права доступа
  • Ресурсно-ограниченные права
  • Ограничение доступа к данным по сервисам, хостам и группам сервисов
    • Три измерения области видимости
    • Как комбинируются измерения: объединение (ИЛИ)
    • Разворачивание групп сервисов
    • Как фильтр применяется к источникам данных
    • Объединение прав из нескольких ролей
  • Доступ к данным через группу хостов
    • Право управления группами resource_group
    • Регистр имён хостов
    • Пустая группа и сбой чтения группы
    • Роли без сервисов
• Внешние группы
  • Привязка групп LDAP/OIDC
• Журнал аудита

Введение

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

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

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

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

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

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

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

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

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

Роли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступ к данным через группу хостов

Помимо списка хостов, роли можно выдать доступ к группе хостов. В админке ролей при выборе типа области в роли появляется Группы хостов: мультивыбор с поиском «Поиск групп хостов…», в списке — имя группы и число хостов; удалённая группа отмечена как «удалённая группа». Переключатель Предоставить доступ ко всем группам хостов выдаёт доступ ко всем группам.

Группа хостов — четвёртое измерение области видимости, наравне с service, host и service_group. Все правила выше действуют для неё так же: измерения объединяются по ИЛИ, а открытое измерение (*) снимает фильтр целиком.

• Роль с группой A, в которую входят хосты h1 и h2, видит данные только h1 и h2.
• Роль с группой A и прямым грантом на хост h9 видит h1, h2 и h9.
• Доступ выдаётся на группу по её идентификатору, поэтому переименование группы доступ не затрагивает.
• Состав группы читается из РСМ, а не хранится в роли. Хост, добавленный в группу, становится доступен роли не позже чем через 30 секунд, без сброса кэша прав; изменение самих грантов вступает в силу как обычно.
• В фильтре «Группа хостов» на дашбордах, в колонке «Группы» и в форме окна обслуживания роль видит не только группы со своим грантом, но и любую группу, в которой есть хотя бы один видимый ей хост. Например, роли с грантами на группы «Gitlab» и «Документация» видна и группа «Стенд», если в неё входят хосты этих групп; счётчик у «Стенда» считает только видимые роли хосты, а выбор «Стенда» сужает выдачу до них же — доступа к остальным хостам «Стенда» роль не получает.

Фильтр по группе применяется на всех путях, перечисленных в таблице выше: PromQL и LogsQL (в запрос подставляются хосты группы), REST-запросы (события, трейсы и другие хостовые данные), инциденты, кубы OLAP и инструменты ассистента (в обращении ассистента вместо списка хостов передаётся сводка «N хостов из групп …»). Для кубов в токен передаются идентификаторы групп, а не списки хостов, поэтому размер токена от размера группы не зависит.

Право управления группами resource_group

Право resource_group управляет разделом Группы хостов (в админке — «Управление группами хостов»): view — просмотр списка и карточек, edit — создание, переименование, удаление групп и изменение состава.

• Право выдаётся только на все группы — в пикере предлагается один вариант «все» (ключ *). Попытка выдать его на конкретный идентификатор отвергается с ошибкой 422.
• Роли с правом {edit, *, *} получают resource_group автоматически.
• Право resource_group отделено от host_group: первое управляет самими группами, второе открывает данные хостов. Роли с доступом к данным через группу не нужно право на управление ею.
• Ресурсно-сервисная модель правами на группы в версии 204 не ограничивается: роль с правом просмотра ресурсов РСМ (resource:view) видит все группы и их состав. Права на отдельную группу и ограничение РСМ по типам ресурсов в версии 204 нет.

Выдача прав через группу записывается в журнал аудита как идентификаторы групп и число хостов, без полного списка хостов.

Регистр имён хостов

• Хосты из группы сравниваются без учёта регистра во всех источниках данных: WEB01 в группе совпадёт с метрикой, у которой метка host="web01".
• Прямые гранты host сравниваются с учётом регистра, как и раньше: грант на WEB01 не открывает хост web01.

Пустая группа и сбой чтения группы

Платформа не допускает, чтобы неудачное раскрытие группы открывало больше данных, чем задумано:

• Пустая группа (или удалённая) — доступ, выданный на неё, ничего не открывает: выдача пустая, а не «всё». Это же касается групп сервисов.
• Сбой чтения состава группы — запрос завершается ошибкой, а не возвращает все данные; результат сбоя не кэшируется. Это же касается групп сервисов.

Раскрытие очень больших групп (порядка 2000 хостов и больше) работает, но платформа пишет предупреждение в журнал.

Роли без сервисов

Роль, в которой нет ни одной записи service (только хосты, только группа хостов или то и другое), называется ролью без сервисов. Начиная с версии 204 для неё действуют такие правила:

Раньше такая роль видела все инциденты, а доступ к трейсам и ключевым бизнес-транзакциям зависел от пути запроса. В админке ролей у роли с хостами или группами без сервисов показывается пояснение: «Роль без сервисов: трейсы и ключевые бизнес-транзакции будут пусты, инциденты — только по её хостам».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фильтры

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

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

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

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

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

Экспорт

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

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

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

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

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

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

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