2.7. Настройки безопасности¶
Администрирование функций безопасности включает в себя следующее:
- управление ролями доступа;
- управление пользователями;
- управление токенами приложений;
- настройка прав доступа к данным;
- настройка режима аутентификации.
Также важная тема, относящаяся к безопасности, – режимы функционирования TDG.
2.7.1. Ролевая модель доступа¶
В TDG реализована ролевая модель доступа к функциям системы и данным, хранящимся в системе. По умолчанию, определены три роли, которые могут быть назначены различным пользователям и внешним приложениям для авторизованного доступа и действий в системе:
- «admin»
- «supervisor»
- «user»
Данные роли можно рассматривать как своего рода шаблоны — они являются нередактируемыми и имеют предзаданный набор прав.
Роль | Доступ к функциям | Доступ к данным |
---|---|---|
admin | Полный доступ ко всем функциям. | read/write для всех агрегатов |
supervisor | Полный доступ в режиме «только для чтения» — имеет доступ ко всем разделам системы, но не может менять ее настройки. | read для всех агрегатов |
user | Ограниченный доступ. Запрещен доступ к разделам, связанным с администрированием системы (скрыты вкладки Cluster, Configuration files, Model, Audit Log, Settings). | Отсутствует |
На основе этих ролей администратором могут быть созданы пользовательские роли с произвольным набором прав как для доступа к функциям системы, так и для доступа к данным.
Текущий список ролей пользователей можно увидеть на вкладке Settings > Roles:

Для работы ролевой модели доступа необходимо назначить одному из наборов реплик
в кластере роль account_manager
. Это делается на этапе настройки кластера.
2.7.1.1. Создание роли пользователя¶
Администратор имеет возможность создания новых ролей доступа, в том числе на базе уже существующих (ролей по умолчанию или ранее созданных пользовательских ролей). Для новой роли может быть задан произвольный набор прав, и также к ней может быть привязан профиль доступа к данным.
Для создания новой роли пользователя:
На вкладке Settings > Roles нажмите Add new role. Откроется диалог создания роли.
В диалоге создания задайте следующие параметры:
Name
— название роли;Description (optional)
— (опционально) произвольное описание роли;Inherit from role
— (опционально) выбор существующей роли, на базе которой будет создаваться новая.
В таблице отметьте флаг Allowed для тех действий, которые будут доступны для пользователя данной роли (перечислены в списке в колонке Action). Профили доступа к данным, если они уже созданы в системе, отображаются в этом же списке. Назначить профиль доступа к данным можно и позднее, отредактировав набор действий для этой роли.
Сохраните новую роль, нажав Save.
2.7.2. Управление пользователями¶
Текущий список пользователей TDG и инструменты для управления ими находятся на вкладке Settings > Users:

Управление пользователями включает в себя следующие операции:
- управление профилем пользователя (создание, редактирование, удаление);
- изменение статуса пользователя;
- сброс пароля пользователя;
- экспорт/импорт пользовательских профилей;
- управление политикой паролей.
2.7.2.1. Создание профиля пользователя¶
Для создания профиля пользователя TDG:
В web-интерфейсе перейдите на вкладку Settings > Users и нажмите Create user. Откроется диалог создания пользователя.
В диалоге укажите следующие параметры:
Name
— имя пользователя;Email
— электронная почта пользователя;Password
— пароль для авторизации в системе (должен соответствовать политике паролей). Также пароль можно сгенерировать автоматически:- либо кнопкой Generate;
- либо оставить поле пустым — в этом случае система автоматически
сгенерирует пароль и отправит пользователю на указанный
Email
(для этого необходимо иметь настроенный SMTP-сервер).
Expires in
— (опционально) срок действия пароля;Role
— роль пользователя согласно ролевой модели доступа.
Нажмите Submit.
При создании профиля автоматически генерируется уникальный идентификатор пользователя, который отображается в колонке LOGIN в таблице User list и используется в дальнейшем для авторизации в web-интерфейсе.
Профили пользователей, включая их пароли, хранятся в файле конфигурации системы
config.yml
, который синхронизируется между всеми
инстансами, входящими в кластер.
В целях безопасности пароли пользователей хранятся в виде хэша с добавлением
криптографической соли.
При задании пароля можно посмотреть текущую политику паролей в режиме подсказки:
Примечание
Помимо создания профилей пользователей в web-интерфейсе, их можно импортировать в систему посредством JSON-файла.
2.7.2.2. Редактирование и удаление профиля пользователя¶
Для редактирования профиля пользователя:
- В web-интерфейсе перейдите на вкладку Settings > Users.
- В таблице User list в колонке ACTIONS для нужного пользователя нажмите Edit.
- В диалоге редактирования профиля пользователя измените необходимые параметры и нажмите Submit.
Для удаления профиля пользователя из системы в колонке ACTIONS нажмите More для нужного пользователя и выберите в выпадающем меню Delete. В диалоговом окне подтвердите удаление, нажав OK.
2.7.2.3. Изменение статуса пользователя¶
При создании профиля пользователя он автоматически активируется в системе, на что указывает статус «active» в колонке STATUS таблицы User list. Администратор может изменить статус пользователя вручную — заблокировать пользователя в системе:
В колонке ACTIONS нажмите More для нужного пользователя и выберите в выпадающем меню Block user:
В диалоговом окне укажите, если необходимо, причину изменения статуса (параметр Reason) и нажмите Block. Если ранее статус пользователя уже менялся, причина последнего изменения статуса будет указана в параметре Previous Reason.
Статус пользователя будет изменен на «blocked» и отображен в колонке STATUS.
В дальнейшем администратор может заново активировать профиль пользователя по аналогичной процедуре (More > Unblock user).
2.7.2.4. Сброс пароля пользователя¶
Администратор может сбросить пароль любого из пользователей: в колонке ACTIONS нажмите More для нужного пользователя и выберите в выпадающем меню Reset password. В диалоговом окне подтвердите сброс пароля, нажав OK. После этого на электронный адрес пользователя, указанный в его профиле, будет выслан временный пароль для авторизации в системе.
Для корректной работы отправки нового пароля на электронный адрес должен быть настроен SMPT-сервер. Для этого необходимо:
Развернуть и запустить SMTP-сервер.
В файле конфигурации TDG
config.yml
прописать следующие настройки и загрузить измененную конфигурацию в систему:connector: output: - name: to_smtp type: smtp url: <URI SMPT-сервера> from: <адрес отправителя> timeout: <значение тайм-аута, секунды> account_manager: only_one_time_passwords: true output: name: to_smtp
2.7.2.5. Экспорт/импорт профилей пользователей¶
Профили пользователей можно экспортировать из системы в формате JSON. Для этого на вкладке Settings > Users нажмите Export:

В результате система сформирует и экспортирует файл с именем users-<N>.json
(где <N> — порядковый номер), который содержит массив с профилями всех текущих
пользователей. Профиль каждого пользователя имеет следующий формат (пример):
[
{
"expires_in":2592000,
"login":"pc9199",
"email":"petrov@mailserver.com",
"created_at":1586236779870364400,
"state_reason":"petrov@mailserver.com state is changed to active: recover from disabled",
"failed_login_attempts":1,
"uid":"23563aa8-facc-4970-89f3-cfc267609c3b",
"role":"admin",
"state":"active",
"username":"Петров",
"last_login":1586236825716746000,
"last_password_update_time":null
},
{
...
}
]
Также возможна обратная операция — импорт профилей пользователей в систему.
Для импорта вначале необходимо подготовить файл с профилями пользователей в формате JSON. Это может быть ранее экспортированный файл с профилями (см. выше), или же администратор может подготовить файл с этими данными самостоятельно. В описанном представлении данных пользователя в формате JSON обязательными являются все поля кроме:
state_reason
;last_login
;last_password_update_time
;password
.
Отдельно нужно сказать про поле password
и логику генерации пароля
пользователя при импорте профиля. Существует 2 варианта создания пароля:
- Указать пароль в явном виде в поле
password
— в этом случае флаг Generate passwords в диалоге импорта отмечать не нужно (см. ниже процедуру импорта), и пароль для пользователя будет взять из поляpassword
как есть. При этом пароль должен соответствовать текущей политике паролей, определенной в системе. - Сгенерировать пароль автоматически — в этом случае в поле
password
необходимо передать пустое значение (null
) или просто не указывать это поле в JSON, а в диалоге импорта нужно отметить флаг Generate passwords. Пароль будет сгенерирован автоматически в соответствии с текущей политикой паролей.
Важно
Для всех импортируемых пользователей в JSON должен быть выбран один и тот же вариант генерации пароля - либо вариант 1, либо вариант 2.
После успешного импорта профиля данные пользователя, включая пароль, будут отображены в web-интерфейсе. Также можно настроить отправку данных на электронную почту пользователя. Для этого необходимо иметь настроенный SMTP-сервер и в диалоге импорта отметить флаг Send passwords via user’s email.
Пример профиля пользователя в формате JSON для импорта в систему:
[
{
"expires_in":2592000,
"login":"rk7222",
"email":"ivanov@mailserver.com",
"created_at":1586236779870364400,
"state_reason":null,
"failed_login_attempts":0,
"uid":"a0067457-faf2-4441-b213-7c823422bab6",
"role":"admin",
"state":"active",
"username":"Иванов",
"last_login":null,
"last_password_update_time":null,
"password":null
}
]
Для импорта профилей пользователей:
На вкладке Settings > Users нажмите Import. Откроется диалоговое окно.
В диалоговом окне выберите JSON-файл с профилями пользователей (Choose File), отметьте, если необходимо, опции, связанные с генерацией паролей (Generate passwords и Send passwords via user’s email), и нажмите Apply.
В случае успешного импорта новые профили пользователей будут добавлены в таблицу User list. Данные профилей, включая пароли, будут показаны в web-интерфейсе в сообщении о результатах операции импорта.

Важно
Сохраните сгенерированный пароль надежном месте. В целях безопасности пароль в явном виде показывается только сразу после импорта. Сообщение с паролем исчезнет, как только вы покинете данную страницу или запустите следующую операцию импорта.
Также данные импортированного пользователя, включая пароль, можно сохранить в
формате .csv
— кнопка Download passwords в сообщении с результатами импорта.
2.7.2.6. Управление политикой паролей¶
Политика создания паролей для авторизации пользователей в системе регулируется на вкладке Settings > Password Policy. Данная политика применима в равной степени как к паролям, которые пользователи задают вручную, так и к автоматически сгенерированным паролям. Изменять политику паролей может только администратор.
Политика определяет минимальную допустимую длину пароля (Password length
) и
то, какие категории символов должны быть обязательно включены в пароль:
- латинские буквы в нижнем регистре (
Include Lowercase Characters
); - латинские буквы в верхнем регистре (
Include Uppercase Characters
); - цифры от 0 до 9 включительно (
Include Digits
); - дополнительные символы
!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
(Include Symbols
).
Значения по умолчанию: длина пароля — 8 символов; в пароле должны обязательно присутствовать символы из первых трех категорий (дополнительные символы — опционально).
Для изменения политики паролей необходимо поменять значения нужных параметров и нажать ОК.
2.7.3. Токен приложений¶
Приложениям внешних систем для доступа к данным и функциям TDG необходим авторизованный доступ, который организуется через токены приложений.
Общий процесс выглядит следующим образом: в web-интерфейсе администратор генерирует токен, назначает для него права доступа к объектам TDG и передает токен разработчикам внешней системы.
Сгенерировать токен можно в web-интерфейсе: вкладка Settings > Tokens, кнопка Create token. В диалоге создания необходимо указать следующие параметры и нажать Submit:
Name
— имя (ключ) токена, которое будет в дальнейшем идентифицировать его в системе;Expires in
— (опционально) срок действия токена;Role
— роль токена. Аналогична роли пользователя согласно ролевой модели доступа.
После генерации токен в явном виде будет доступен только в сообщении в web-интерфейсе:

Важно
Сохраните сгенерированный токен в надежном месте. В целях безопасности токен в явном виде показывается только один раз, при генерации. Сообщение с токеном исчезнет, как только вы покинете данную страницу или сгенерируете новый токен.
В дальнейшем сам сгенерированный токен и его имя являются нередактируемыми. Отредактировать можно только срок действия токена и его роль.
Другие возможные операции по управлению токенами — изменение статуса, удаление, экспорт, импорт — аналогичны таким же операциям для пользовательских профилей.
2.7.4. Права доступа к данным¶
TDG дает возможность установить для каждой роли права на действия с данными (объекты с логическим типом «Aggregate», далее — агрегат), которые обрабатываются и хранятся в системе:
Read
— чтение (получение) информации о хранящихся в системе агрегатах;Write
— вставка и удаление агрегатов.
Устанавливать права нужно после того, как в систему загружена модель данных, в которой описаны агрегаты и связанные с ними объекты. Модель данных загружается при первоначальной конфигурации системы.
Права доступа к данным задаются в web-интерфейсе через создание профиля доступа (data action), который потом назначается для каких-либо из пользовательских ролей.
Для создания профиля доступа:
Перейдите на вкладку Settings > Data actions.
Нажмите Add new Data Action. Откроется диалог создания профиля.
В поле Name введите имя профиля доступа.
Для каждого из агрегатов отметьте галочками нужные права,
Read
и/илиWrite
.Сохраните профиль, нажав Save.
Созданный профиль доступа отображается на вкладке Settings > Data actions.
Профиль является редактируемым, т.е. в дальнейшем можно изменять права
Read
/Write
для нужных агрегатов.
После создания профиль становится доступен для назначения какой-либо роли.
Примечание
Назначить профиль доступа можно только для роли, созданной в системе администратором. Для ролей по умолчанию («admin», «supervisor», «user») эта операция недоступна, т.к. эти роли нередактируемые и являются своего рода шаблонами с предзаданным набором прав.
Чтобы назначить профиль доступа для существующей роли:
Перейдите на вкладку Settings > Roles и в колонке Action для нужной роли нажмите Edit.
В диалоге редактирования отметьте флаг Allowed для нужного профиля доступа.
Сохраните настройки роли, нажав Save.
Аналогично профиль доступа можно назначить и при создании новой роли.
2.7.5. Режим обязательной аутентификации¶
Сразу после развертывания системы у пользователей и внешних приложений есть возможность неавторизованного анонимного доступа ко всем функциям и данным, что некорректно с точки зрения безопасности. Поэтому одним из первых действий администратора должно быть отключение возможности анонимного доступа и настройка обязательной аутентификации.
Для этого необходимо:
- Создать профиль пользователя с ролью «admin».
- Авторизоваться в системе под этим пользователем.
- Включить режим обязательной аутентификации (отключить анонимный доступ).
Режим обязательной аутентификации включается/отключается на вкладке Cluster переключателем Auth.

2.7.6. Режимы функционирования TDG¶
TDG может функционировать в двух режимах:
- режиме эксплуатации (production mode);
- режиме разработки (dev mode).
Режим эксплуатации является основным для штатной эксплуатации TDG.
Режим разработки предоставляет дополнительный функционал (см. список ниже), который используется при разработке пользовательского кода и отладке работы системы. Однако при штатной эксплуатации этот функционал может снижать производительность системы и создавать ситуации, потенциально небезопасные с точки зрения сохранности данных и уязвимости системы. Поэтому в версии TDG, сертифицированной по требованиям доверия ФСТЭК России, использование режима разработки запрещено.
Дистрибутивы установки для этих двух режимов разные. По умолчанию выдается дистрибутив для работы в режиме эксплуатации.
В режиме разработки доступны следующие дополнительные функции (по сравнению с режимом эксплуатации):
- GraphQL запрос на удаление данных (mutation) во всех спейсах инстансов с ролью «storage»;
- GraphQL запросы на чтение (query) и изменение (mutation) конфигурации кластера и настроек системы;
- GraphQL запросы (mutation)
evaluate
для выполнения любого кода, включая код для чтения и изменения данных; - включен «строгий режим» (модуль strict), который позволяет отслеживать использование необъявленных глобальных переменных;
- более полная проверка (с помощью модуля checks) типов аргументов, передаваемых в функции Lua. В режиме разработки проверка выполняется для большинства функций, принимающих на вход данные от пользователя. В режиме эксплуатации – только для функций репозитория.
- доступна вкладка Console;
- доступна вкладка Code.
Дистрибутив установки содержит
скрипты enable_dev_mode.sh
и enable_prod_mode.sh
для включения
соответствующего режима функционирования. Скрипты находятся в корневой
директории дистрибутива.
Развернутый инстанс можно переключить в другой режим работы. Для этого необходимо:
На сервере, где развернут инстанс, перейти в директорию, где хранятся исполняемые файлы для этого инстанса
/usr/share/tarantool/<instance_name>
Запустить нужный скрипт (
enable_dev_mode.sh
илиenable_prod_mode.sh
).Перезапустить инстанс:
systemctl restart <instance_name>