Ролевая модель в DataGrid#

Ролевая модель — это набор разрешений и прав, которые предоставляют пользователям доступ к управлению и настройке DataGrid. Обычно ролевая модель соответствует действиям и полномочиям определенной должности, что позволяет создать и настроить конкретную роль, а затем предоставить эту роль всем сотрудникам с такой должностью. В плагине безопасности все операции, связанные с предоставлением и изъятием прав пользователей, выполняются через роли. Можно создавать любые роли с любым набором разрешений, которые будут учитывать специфику рабочего процесса команды.

Функциональность продукта DataGrid позволяет гибко создавать роли и назначать им права с помощью утилиты Admin UI (подробнее см. в разделе «Управление ролями при помощи Admin UI» текущего документа). Если используется роль инсталляции из дистрибутива DataGrid, в процессе установки автоматически создаются четыре роли:

SECURITY_ADMIN — администратор безопасности. Пользователь с этой ролью может настраивать права и разрешения для других ролей, создавать новые ролевые модели и учетные записи других пользователей. Также роль SECURITY_ADMIN может быть использована для аудита системы.
MAINTENANCE_ADMIN — администратор кластера. Пользователь с этой ролью отвечает за «здоровье» кластера и работу с SQL-запросами: может опустить или поднять кластер, настроить узлы, снять снепшот.
SERVER_NODE — техническая учетная запись для запуска кластера и работы серверных узлов. Эта роль позволяет запустить кластер и следить за безопасностью узла.
CLIENT — учетная запись для работы толстого клиента.

Кроме того, можно создать собственные ролевые модели. Если ролевая модель была создана ролью инсталляции из дистрибутива DataGrid, воспользуйтесь ролью SECURITY_ADMIN для создания и настройки любых других ролевых моделей. Также разрешения для создания новых ролей можно определить самостоятельно (без обязательного участия роли SECURITY_ADMIN) — например, настроить возможность создания новых ролей и разрешений в учетной записи администратора.

Важно

Если используются предустановленные роли из поставки DataGrid, нельзя назначать одному и тому же пользователю более одной из четырех описанных выше ролей (SECURITY_ADMIN, MAINTENANCE_ADMIN, SERVER_NODE, CLIENT).

Списки разрешений для ролей#

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

Список разрешений на работу с кешами:

CACHE_CREATE — создание кеша;
CACHE_DESTROY — удаление кеша;
CACHE_READ — чтение значений из кеша;
CACHE_PUT — добавление/изменение значения в кеше;
CACHE_REMOVE — удаление значения из кеша.

Примечание

При добавлении разрешений на работу с кешами обязательно укажите имя каждого кеша с разрешениями для него. Чтобы разрешение распространялось на все кеши, укажите * вместо имени кеша.

Список разрешений на выполнение задач:

TASK_EXECUTE — запуск задачи на выполнение;
TASK_CANCEL — отмена выполнения задачи.

Примечание

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

Список разрешений на запуск сервисов:

SERVICE_DEPLOY — развертывание сервиса;
SERVICE_CANCEL — отмена развертывания сервиса;
SERVICE_INVOKE — вызов сервиса.

Примечание

При добавлении разрешений на запуск сервисов обязательно укажите имя каждого сервиса с разрешениями для него. Чтобы разрешение распространялось на все сервисы, укажите * вместо имени задачи.

Список системных разрешений:

ADMIN_CLUSTER_NODE_START — запуск новых узлов в кластере;
ADMIN_CLUSTER_NODE_STOP — остановка и перезапуск узлов в кластере;
ADMIN_KILL — завершение системных процессов;
ADMIN_OPS — выполнение команд для администрирования DataGrid (не включает в себя разрешения с префиксом ADMIN_, приведенные ниже);
ADMIN_READ_DISTRIBUTED_PROPERTY — просмотр property, доступных для изменения через control.sh и их текущее значение;
ADMIN_SNAPSHOT — работа со снепшотами (CREATE, CANCEL, CHECK). Должно быть у серверных узлов;
ADMIN_METADATA_OPS — выполнение операций с метаданными (REMOVE, UPDATE);
ADMIN_WRITE_DISTRIBUTED_PROPERTY — редактирование property, доступных для изменения через утилиту control;
ADMIN_USER_ACCESS — управление данными безопасности пользователей;
ADMIN_CLUSTER_STATE — управление состоянием кластера (INACTIVE, ACTIVE, ACTIVE_READ_ONLY);
CACHE_CREATE — создание кеша. Выбирается или это системное разрешение, или разрешение на работу с кешами. Выбор CACHE_CREATE в качестве системного разрешения позволяет создавать все кеши;
CACHE_DESTROY — удаление кеша. Выбирается или это системное разрешение, или разрешение на работу с кешами. Выбор CACHE_DESTROY в качестве системного разрешения позволяет удалять все кеши;
CHANGE_STATISTICS — разрешение на выполнение команды ANALYZE and DROP STATISTICS;
EVENTS_ENABLE — включение событий;
EVENTS_DISABLE — отключение событий;
JOIN_AS_SERVER — присоединение к кластеру в качестве серверного узла;
REFRESH_STATISTICS — разрешение на выполнение команды REFRESH STATISTICS.

Инструкции по настройке ролей приведены в разделе «Управление ролями» текущего документа.

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

список минимально необходимых разрешений, которые обязательно выдаются пользователю;
список конфликтных разрешений, которые запрещается выдавать пользователю с данной ролью.

Матрица несовместимости ролей#

В DataGrid право на доступ к операциям определяется на основе ролей, при этом все четыре роли из поставки DataGrid являются несовместимыми.

Роль	`SECURITY_ADMIN`	`MAINTENANCE_ADMIN`	`SERVER_NODE`	`CLIENT`
`SECURITY_ADMIN`	—	Несовместимы	Несовместимы	Несовместимы
`MAINTENANCE_ADMIN`	Несовместимы	—	Несовместимы	Несовместимы
`SERVER_NODE`	Несовместимы	Несовместимы	—	Несовместимы
`CLIENT`	Несовместимы	Несовместимы	Несовместимы	—

Типы сертификатов для ролей#

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

При администрировании DataGrid пользователь с ролью SECURITY_ADMIN выдает другим пользователям разрешения на конкретные действия в кластере, а затем присваивает каждому пользователю определенную роль. Невозможно одновременно предоставить одному пользователю сразу две из четырех ролей из поставки DataGrid (SECURITY_ADMIN, MAINTENANCE_ADMIN, SERVER_NODE, CLIENT), у которых существует определенный тип сертификата.

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

Сопоставление типов сертификатов с разрешениями

Тип сертификата	Соответствие базовой роли DataGrid	Обязательные разрешения	Запрещенные разрешения
`A`	`MAINTENANCE_ADMIN`	`ADMIN_OPS` `ADMIN_CLUSTER_STATE`	`JOIN_AS_SERVER` `ADMIN_USER_ACCESS`
`C`	`CLIENT`	Любые, кроме запрещенных	`JOIN_AS_SERVER`, `ADMIN_OPS`, `ADMIN_USER_ACCESS`
`G`	`SECURITY_ADMIN`	`ADMIN_USER_ACCESS`	`JOIN_AS_SERVER` `ADMIN_OPS`
`S`	`SERVER_NODE`	`JOIN_AS_SERVER` `ADMIN_OPS` `ADMIN_CLUSTER_STATE`	`ADMIN_USER_ACCESS`

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

Подробнее об использовании сертификатов — в разделе «Управление сертификатами пользователей» документа «Инструкция по установке».

Управление ролями#

В настоящий момент роли могут быть описаны:

динамически при помощи Admin UI (рекомендуется для persistence-кластеров);
с помощью утилиты ise-user-control;
вручную в json-файле default-security-data.json, который считывается в момент запуска кластера (рекомендуется только для in-memory-кластеров).

Для управления ролями рекомендуется использовать графическую утилиту Admin UI. Если с Admin UI возникнут проблемы, обратитесь к сетевому администратору или сообщите в техподдержку.

Управление ролями с помощью Admin UI#

AdminUI позволяет управлять ролями, назначаемыми пользователям. Чтобы настроить роли с помощью утилиты Admin UI, используйте учетную запись администратора безопасности SECURITY_ADMIN. Подробнее о создании, редактировании и удалении пользователей, ролевых моделей и разрешений смотрите в разделе «Управление ролями».

Управление ролями с помощью `ise-user-control`#

Использование утилиты ise-user-control при работе с persistence-кластерами рекомендуется только в случае отказа графической утилиты Admin UI.

Подробнее работа с утилитой ise-user-control описана в разделе «Утилита ise-user-control для управления пользователями» документа «Руководство по системному администрированию».

Управление ролями в json-файле#

В json-файле содержится информация о ролях (аналог групп безопасности в Linux) и пользователях. Название файла может меняться и прописывается в bean JsonSecurityDataSupplierImpl. По умолчанию файл имеет название default-security-data.json.

Внимание

Ручное создание и использование этого файла рекомендуется только для in-memory кластеров. Для persistence-кластеров рекомендуется использовать графическую утилиту управления Admin UI.

Описание роли#

Файл с описанием роли имеет следующую структуру:

{
  "name": "ROLE_NAME",
  "perms": {
    "dfltAllowAll": false,
    "cachePermissions": {},
    "taskPermissions": {},
    "servicePermissions": {},
    "systemPermissions": []
  },
  "conflictPerms": {
    "dfltAllowAll": false,
    "cachePermissions": {},
    "taskPermissions": {},
    "servicePermissions": {},
    "systemPermissions": []
  }
}

где:

name — имя роли;
perms — разрешения следующих видов:
- dfltAllowAll — если true, то разрешены все действия, если false, то по умолчанию запрещены все действия, кроме тех, на которые дано разрешение. По требованию безопасности всегда указано значение false;
- cachePermissions — разрешение на работу с кешами. Атрибут cachePermissions содержит имя кеша или префикc со знаком * на конце и необходимые разрешения.
Пример:
```
"TEST_CACHE1": ["CACHE_CREATE","CACHE_DESTROY","CACHE_READ","CACHE_PUT","CACHE_REMOVE"],
"TEST_CACHE2*": ["CACHE_READ","CACHE_PUT","CACHE_REMOVE"]
```
Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.
taskPermissions — разрешение на выполнение задач. taskPermissions содержит имя задачи или префикc со знаком * на конце и разрешение на ее запуск или отмену.

Пример:
```
"com.sbt.task.UserTask": ["TASK_EXECUTE", "TASK_CANCEL"]
```
Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.
servicePermissions — разрешение на запуск сервисов. servicePermissions содержит имя сервиса или префикc со знаком * на конце и разрешения на установку/запуск/отмену.

Пример:
```
"com.sbt.*": ["SERVICE_INVOKE"]
"com.sbt.test.*": ["SERVICE_DEPLOY","SERVICE_CANCEL","SERVICE_INVOKE"]
```
Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.
systemPermissions — системные разрешения.

Пример:
```
["JOIN_AS_SERVER","CACHE_CREATE","CACHE_DESTROY","ADMIN_OPS", "ADMIN_SNAPSHOT"]
```
Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.
conflictPerms — список разрешений, которые запрещается выдавать пользователю, обладающему определенной ролью. Значение полей для conflictPerms задается аналогично полям perms, описанным выше. Исключение составляет флаг dfltAllowAll:
- если его значением является false, то пользователю разрешается иметь совместно с текущей ролью любые другие, чьи предоставляемые разрешения не пересекаются с разрешениями, указанными посредством полей cachePermissions, taskPermissions, servicePermissions или systemPermissions текущей роли.
- если его значением является true, то пользователю запрещается иметь любые другие роли совместно с текущей. В этом случае разрешения, указанные посредством полей cachePermissions, taskPermissions, servicePermissions или systemPermissions текущей роли, игнорируются.

Описание пользователя#

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

{
  "creds": {
    "login": "testUser1",
    "password": "YOUR_PASSWORD_HASH",
    "salt": "YOUR PASSWORD SALT"
  },
  "roles": [
    "SHOULD_CHANGE_PASSWORD"
  ]
}