Управление правами доступа пользователей Kintsugi#

Platform V Kintsugi (DBM) предоставляет широкий спектр возможностей по настройке прав доступа благодаря двум моделям управления доступом: Role-Based Access Control (RBAC) и Attribute-Based Access Control (ABAC).

Распределение привилегий моделью RBAC#

Модель RBAC распределяет привилегии на основе заранее установленных ролей.

Каждая роль включает конкретные права, доступные ее обладателям.

RBAC позволяет централизованно назначить привилегии через предварительно созданные роли.

Распределение привилегий моделью ABAC#

Модель ABAC основывается на правилах, учитывающих атрибуты пользователя, ресурса и окружения.

Атрибуты ABAC#

Активы#

Основой для вычисления привилегий в механизме ABAC являются атрибуты объектов. В данном разделе рассмотрим атрибуты активов.

В качестве атрибутов активов выступают пользовательские свойства.

Набор пользовательских свойств определяется клиентом после развертывания Kintsugi (DBCM) и может изменяться по мере необходимости.

Группы активов (фильтры активов)#

В Kintsugi (DBCM) группы активов формируются путем задания некоторого набора признаков (фильтра): активы, обладающие подходящим набором признаков, считаются членами группы.

Фильтр активов представляет собой набор условий (предикатов), при этом:

каждый предикат проверяет одно из пользовательских свойств на равенство заданному значению;
все предикаты фильтра объединяются через операцию логического «И».

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

Примеры фильтров#

Фильтр будем представлять в форме JSON-документа, содержащего один объект, где каждая пара key-value описывает один предикат, где:

key – имя пользовательского свойства;
value – искомое значение пользовательского свойства.

Пусть в системе присутствует набор активов с пользовательскими свойствами согласно следующей таблице.

Название актива	Свойство `custom_as`	Свойство `custom_stand`	Свойство `custom_cluster`
`host-cyan-dev-jazz-primary`	`cyan`	`dev`	`jazz`
`host-cyan-dev-jazz-secondary`	`cyan`	`dev`	`jazz`
`host-cyan-dev-blues-primary`	`cyan`	`dev`	`blues`
`host-cyan-dev-blues-secondary`	`cyan`	`dev`	`blues`
`host-cyan-ops-jazz-primary`	`cyan`	`ops`	`jazz`
`host-cyan-ops-jazz-secondary`	`cyan`	`ops`	`jazz`
`host-cyan-ops-blues-primary`	`cyan`	`ops`	`blues`
`host-cyan-ops-blues-secondary`	`cyan`	`ops`	`blues`
`host-magenta-dev-jazz-primary`	`magenta`	`dev`	`jazz`
`host-magenta-dev-jazz-secondary`	`magenta`	`dev`	`jazz`
`host-magenta-dev-blues-primary`	`magenta`	`dev`	`blues`
`host-magenta-dev-blues-secondary`	`magenta`	`dev`	`blues`
`host-magenta-ops-jazz-primary`	`magenta`	`ops`	`jazz`
`host-magenta-ops-jazz-secondary`	`magenta`	`ops`	`jazz`
`host-magenta-ops-blues-primary`	`magenta`	`ops`	`blues`
`host-magenta-ops-blues-secondary`	`magenta`	`ops`	`blues`

Рассмотрим несколько примеров фильтрации активов:

Выдача привилегий на все активы для конкретной автоматизированной системы#

Требуется выдать привилегии на все активы, находящиеся в стендах ops автоматизированной системы magenta.

Задайте фильтр активов следующим образом:

{
   "custom_as": "magenta",
   "custom_stand": "ops"
}

Данный фильтр выбирает активы, у которых свойство:

custom_as имеет значение magenta;
custom_stand имеет значение ops.

Группа активов, образованная данным фильтром, будет включать следующие элементы:

host-magenta-ops-jazz-primary;
host-magenta-ops-jazz-secondary;
host-magenta-ops-blues-primary;
host-magenta-ops-blues-secondary.

Выдача привилегий на все активы всех автоматизированных систем#

Требуется выдать привилегии на все активы, находящиеся в стендах ops всех автоматизированных систем.

Задайте фильтр активов следующим образом:

{
   "custom_stand": "ops"
}

Данный фильтр выбирает активы, у которых свойство custom_stand имеет значение ops.

Группа активов, образованная данным фильтром, будет включать следующие элементы:

host-cyan-ops-jazz-primary;
host-cyan-ops-jazz-secondary;
host-cyan-ops-blues-primary;
host-cyan-ops-blues-secondary;
host-magenta-ops-jazz-primary;
host-magenta-ops-jazz-secondary;
host-magenta-ops-blues-primary;
host-magenta-ops-blues-secondary.

Выдача привилегий на все активы, существующие в настоящий момент, и создаваемые в будущем#

Для выдачи привилегий на все активы, существующие в настоящий момент, и создаваемые в будущем, задайте фильтр активов следующим образом — в виде пустого JSON-документа.

Данный фильтр не содержит условий на пользовательские свойства, то есть он выбирает все активы.

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

Пользователи и их группы#

Как правило, привилегии требуется выдавать не отдельным пользователям, а их группам.

Группа пользователей в Kintsugi (DBCM):

имеет идентификатор (user_group_key);
включает множество пользователей, определенное одним из двух способов:
- непосредственным перечислением (если имя пользователя содержится в массиве usernames, то пользователь считается членом группы);
- по признаку наличия у них определенной роли RBAC (если у пользователя имеется роль, заданная в поле role_name, то пользователь считается членом группы).

Таким образом, пользователь с точки зрения механизма ABAC обладает следующими характеристиками:

членство в группах с определенными значениями user_group_key (прямо);
обладание ролями RBAC с определенными значениями role_name (косвенно, через членство в группах с заданным значением поля role_name).

Внимание

Вычисление привилегий не имеет прямой связи с механизмом RBAC, однако, благодаря возможности создавать группы пользователей, ассоциированные с RBAC-ролями, при выдаче привилегий в механизме ABAC становится возможным учесть принадлежность пользователя к определенной RBAC-роли.

Набор привилегий#

Привилегии представляют собой конкретные права, которые определены в Kintsugi (DBCM):

Привилегия Backend	Примечания
`asset_pg_edit`	Изменение характеристик активов PostgreSQL
`asset_pg_delete`	Удаление активов PostgreSQL
`asset_pg_view`	Получение списка событий Открытие дашборда Обзор Открытие дашбордов метрик мониторинга Открытие информации о производительности Открытие помощника по блокировкам Создание отчета PWR Создание и редактирование пользовательских дашбордов
`alerting_view_subscribers`	Просмотр списка подписчиков на оповещения
`pg_metrics_toggle_global`	Переключение флага сбора всех метрик
`pg_metrics_regular_toggle`	Переключение флага сбора метрик с типами `pg` и `host` и изменение порогов метрик с типами `pg` и `host`
`pg_metrics_embedded_toggle`	Переключение флага сбора и параметров встроенных метрик
`asset_pg_log_view`	Просмотр логов актива
`asset_pg_config_edit`	Изменение конфигурации активов

Конфигурация политики ABAC#

Политика ABAC конфигурируется путем загрузки снепшотов через публичный REST API (/privileges/snapshots/upload).

Подробнее с публичным API-вызовом можно ознакомиться в документе «Руководство прикладного разработчика на Kintsugi (DBCM)» раздел «Загрузка правил выдачи привилегий для групп пользователей».

Важно

Загруженные снепшоты не приводят к изменению политики ABAC немедленно. Для того чтобы изменить политику, соответствующий снепшот должен быть применен администратором через интерфейс Kintsugi.