Перейти к основному содержимому
Версия: 2.5

Ролевая политика

В системе Памир роли используются как один из основных атрибутов пользователя для назначения доступа к функциям платформы, ресурсам и внешним сервисам.

Роль хранится в пользовательском атрибуте role и может использоваться:

  • в правилах доступа к функциям системы;
  • в правилах доступа к дашбордам, TQL, индикаторам здоровья и объектам CMDB;
  • при интеграции со сторонними сервисами, поддерживающими авторизацию по роли.

Общие принципы​

Роль — это атрибут пользователя​

В Памир роль не является отдельной сущностью со встроенным фиксированным поведением. Она хранится как значение атрибута профиля пользователя:

  • имя атрибута: role
  • тип значения: строка
  • допустимые значения определяются схемой атрибута

Именно поэтому роль:

  • отображается в карточке пользователя;
  • может использоваться в пользовательских фильтрах правил доступа;
  • может быть изменена через редактирование атрибута пользователя или схемы атрибута.

Допустимые значения ролей ограничены схемой​

Набор ролей задаётся JSON Schema атрибута role. Обычно используется перечисление значений через oneOf, где для каждого значения задаются:

  • техническое имя роли (const);
  • отображаемое наименование (title).

Пример схемы:

{
  "type": "string",
  "oneOf": [
    {
      "const": "pamir_analytic",
      "title": "Аналитик"
    },
    {
      "const": "pamir_system",
      "title": "Системный пользователь"
    },
    {
      "const": "pamir_external_system",
      "title": "Внешняя система"
    },
    {
      "const": "pamir_admin",
      "title": "Администратор"
    },
    {
      "const": "pamir_admin_ib",
      "title": "Администратор ИБ"
    },
    {
      "const": "pamir_root",
      "title": "Суперадминистратор"
    },
    {
      "const": "pamir_developer",
      "title": "Разработчик"
    }
  ]
}

Это означает, что пользователь может получить только одну из ролей, разрешённых текущей схемой атрибута.

Где настраиваются роли​

Схема атрибута role​

Список доступных ролей определяется в настройках пользовательского атрибута role.

В атрибуте задаются:

  • системное имя атрибута — role;
  • отображаемое имя, например Роль;
  • схема JSON, которая ограничивает допустимые значения;
  • дополнительные модификаторы, например:
    • обязательность заполнения;
    • запрет самостоятельного редактирования пользователем.

На практике это позволяет централизованно управлять тем, какие роли доступны для выбора при создании и редактировании пользователей.

Выбор роли при создании локального пользователя​

При создании локального пользователя поле Роль отображается как список значений, сформированный на основе схемы атрибута role.

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

Предустановленные роли​

В типовой поставке могут использоваться следующие роли:

  • Аналитик (pamir_analytic)
  • Системный пользователь (pamir_system)
  • Внешняя система (pamir_external_system)
  • Администратор (pamir_admin)
  • Администратор ИБ (pamir_admin_ib)
  • Суперадминистратор (pamir_root)
  • Разработчик (pamir_developer)

Назначение этих ролей определяется не только их названием, но и тем, как они используются:

  • в правилах доступа внутри Памир;
  • в интеграции со сторонними сервисами.

Как роли используются внутри Памир​

Роль сама по себе не даёт права автоматически. Фактические права пользователя определяются тем, какие правила доступа настроены для соответствующего значения атрибута role.

Например:

  • правило доступа к функциям может разрешать роль Администратор;
  • правило доступа к дашбордам может разрешать роль Аналитик;
  • правило доступа к CMDB может использовать роль как один из атрибутов ABAC-фильтра.

Таким образом, роль в Памир выполняет функцию признака пользователя, который используется в политике доступа.

Подробнее см. Настройка доступа.

Изменение ролевой политики​

Изменение списка ролей​

Чтобы изменить список ролей, необходимо отредактировать схему атрибута role:

  • добавить новое значение const и title;
  • изменить отображаемое имя существующей роли;
  • удалить ненужные значения.

Важно учитывать последствия изменений​

При изменении схемы атрибута role необходимо учитывать:

  • Правила доступа используют значения ролей в фильтрах пользователей.
    Если изменить техническое значение роли (const), существующие правила, ссылающиеся на старое значение, перестанут применяться корректно.

  • Интеграции со сторонними сервисами также могут зависеть от значения роли.
    Особенно это важно для сервисов, где роль пользователя пробрасывается наружу, например в OpenSearch.

  • Изменение только отображаемого имени (title) безопаснее, чем изменение const.
    Отображаемое имя влияет на интерфейс, а техническое значение — на логику работы правил и интеграций.

Рекомендуемый порядок изменения ролей​

  1. Определить, требуется ли новая роль или достаточно скорректировать существующие правила доступа.
  2. Добавить новое значение в схему атрибута role.
  3. Обновить правила доступа, использующие роли в пользовательских фильтрах.
  4. При необходимости обновить интеграции со сторонними сервисами.
  5. Проверить назначение роли пользователям и итоговые права доступа.

Роли и сторонние сервисы​

В Памир часть сторонних сервисов публикуется через API Gateway и защищается через механизм auth_request.

При обращении пользователя к такому сервису:

  1. API Gateway отправляет запрос в auth-сервис Памир.
  2. Auth-сервис определяет пользователя и его роль.
  3. В зависимости от конфигурации сервиса в запрос могут быть переданы заголовки с данными пользователя.

Для сервисов, которым требуется знать роль пользователя, могут пробрасываться заголовки:

  • X-User-Login
  • X-User-Opensearch-Role

Общий механизм описан в разделе Настройка API Gateway.

Интеграция ролей с OpenSearch​

Для OpenSearch в Памир реализовано проксирование ролевой модели PAMIR в ролевую модель OpenSearch.

Как это работает​

  1. Пользователь обращается к OpenSearch Dashboards через API Gateway.
  2. API Gateway выполняет аутентификацию через auth-service.
  3. Auth-service возвращает логин пользователя и роль для OpenSearch.
  4. API Gateway передаёт в OpenSearch заголовки:
    • X-User-Login
    • X-User-Opensearch-Role
  5. Плагин безопасности OpenSearch воспринимает значение X-User-Opensearch-Role как backend_role.
  6. Далее backend-роль сопоставляется с ролью OpenSearch через roles_mapping.yml.

Таким образом, роль пользователя в Памир может участвовать в определении прав доступа уже внутри OpenSearch.

Что важно при изменении ролей​

Если в системе изменяются технические значения ролей, необходимо проверить:

  • что auth-service продолжает возвращать корректное значение роли;
  • что в roles_mapping.yml существует соответствующее сопоставление;
  • что роль OpenSearch, указанная в маппинге, действительно существует в roles.yml.

Подробности см. в разделе Ролевая модель OpenSearch.

Рекомендации по использованию ролей​

  • Используйте роли как устойчивые категории пользователей, а не как временные признаки.
  • Не меняйте без необходимости технические идентификаторы ролей (const).
  • Для изменения бизнес-наименования роли меняйте только title.
  • Основную логику прав реализуйте через правила доступа, а не через попытку закладывать права в само название роли.
  • Перед добавлением новой роли убедитесь, что для неё будут настроены:
    • правила доступа внутри Памир;
    • при необходимости — маппинг во внешние сервисы.

Связанные разделы​