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

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

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

1. SECURITY_ADMIN — администратор безопасности. Пользователь с этой ролью может настраивать права и разрешения для других ролей, создавать новые ролевые модели и учетные записи других пользователей. Также роль SECURITY_ADMIN может быть использована для аудита системы.

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

3. SERVER_NODE — техническая учетная запись для запуска кластера и работы серверных узлов. Эта роль позволяет запустить кластер и следить за безопасностью узла.

4. CLIENT — учетная запись для работы толстого клиента.

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

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

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

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

• 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 являются несовместимыми.

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

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

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

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

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

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

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

• динамически с помощью Platform V Grid Center;

• с помощью утилиты ise-user-control;

• вручную в json-файле default-security-data.json, который считывается в момент запуска кластера (рекомендуется только для in-memory-кластеров).

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

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

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

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

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

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

{
  "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 со знаком * на конце и необходимые разрешения.

  Пример

  JSON#

  "TEST_CACHE1": ["CACHE_CREATE","CACHE_DESTROY","CACHE_READ","CACHE_PUT","CACHE_REMOVE"],
  "TEST_CACHE2*": ["CACHE_READ","CACHE_PUT","CACHE_REMOVE"]
  

  Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.

• taskPermissions — разрешение на выполнение задач. taskPermissions содержит имя задачи или префикc со знаком * на конце и разрешение на ее запуск или отмену.

  Пример

  JSON#

  "com.sbt.task.UserTask": ["TASK_EXECUTE", "TASK_CANCEL"]
  

  Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.

• servicePermissions — разрешение на запуск сервисов. servicePermissions содержит имя сервиса или префикc со знаком * на конце и разрешения на установку/запуск/отмену.

  Пример

  JSON#

  "com.sbt.*": ["SERVICE_INVOKE"]
  "com.sbt.test.*": ["SERVICE_DEPLOY","SERVICE_CANCEL","SERVICE_INVOKE"]
  

  Возможные значения разрешений приведены в разделе «Списки разрешений для ролей» выше.

• systemPermissions — системные разрешения.

  Пример

  JSON#

  ["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"
  ]
}

где:

• login — логин пользователя;

• password — хеш salted-пароля;

• salt — salt, используемая для генерации хеша пароля.

  Salt и пароль можно получить через утилиту ise-user-control.sh, как в примере ниже:

  bash-3.2$ ./bin/ise-user-control.sh generate-hash
  User control utility.
  Time: YYYY-MM-DDT11:47:57.021
  Command [generate-hash] started.
  Enter value for --password (password):
  Enter value for --confirm-password (confirm password):
  Salt: YOUR_PASSWORD_SALT
  Salted hash: YOUR_PASSWORD_HASH
  Command [generate-hash] finished successfully.
  Control utility has completed execution at: YYYY-MM-DDT11:48:07.227
  Execution time: 10206 ms
  

• roles — список ролей пользователя.