2.7. Настройки безопасности¶
Администрирование функций безопасности включает в себя следующее:
Также важная тема, относящаяся к безопасности, — режимы функционирования TDG.
2.7.1. Ролевая модель доступа¶
В TDG реализована ролевая модель доступа к функциям системы и данным, хранящимся в системе. По умолчанию, определены три роли, которые могут быть назначены различным пользователям и внешним приложениям для авторизованного доступа и действий в системе:
«admin»;
«supervisor»;
«user».
Данные роли можно рассматривать как своего рода шаблоны — они являются нередактируемыми и имеют предзаданный набор прав.
Роль |
Доступ к функциям |
Доступ к данным |
---|---|---|
admin |
Полный доступ ко всем функциям. |
|
supervisor |
Полный доступ в режиме «только для чтения» — имеет доступ ко всем разделам системы, но не может менять ее настройки. |
|
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
— (опционально) срок действия пароля;
Примечание
Проверка истечения срока действия паролей выполняется примерно раз в 30 минут. Учетные записи с истекшим сроком действия паролем блокируются.
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. После этого на электронный адрес пользователя, указанный в его профиле, будет выслан временный пароль для авторизации в системе.
Для корректной работы отправки нового пароля на электронный адрес должен быть настроен SMTP-сервер. Для этого необходимо:
Развернуть и запустить SMTP-сервер.
В файле конфигурации TDG
config.yml
прописать следующие настройки и загрузить измененную конфигурацию в систему:connector: output: - name: to_smtp type: smtp url: <URI SMTP-сервера> from: <адрес отправителя> timeout: <значение тайм-аута, секунды> account_manager: only_one_time_passwords: true output: name: to_smtp
2.7.2.5. Экспорт/импорт профилей пользователей¶
2.7.2.5.1. Экспорт¶
Профили пользователей можно экспортировать из системы в формате 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
},
{
...
}
]
2.7.2.5.2. Импорт¶
Также возможна обратная операция — импорт профилей пользователей в систему.
Для импорта вначале необходимо подготовить файл с профилями пользователей в формате 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. Данная политика применима в равной степени как к паролям, которые пользователи задают вручную, так и к автоматически сгенерированным паролям. Изменять политику паролей может только администратор.
В политике определяются:
Категории символов, которые должны быть обязательно включены в пароль:
Include Lowercase Characters
— латинские буквы в нижнем регистре. По умолчанию включено;Include Uppercase Characters
— латинские буквы в верхнем регистре. По умолчанию включено;Include Digits
— цифры от 0 до 9 включительно. По умолчанию включено;Include Symbols
— дополнительные символы (!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
);
Password length
— минимальная допустимая длина пароля. Значение по умолчанию: 8. Максимальная длина пароля: 1000 символов.
Для изменения политики паролей необходимо поменять значения нужных параметров и нажать ОК.
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.

Важно
При включении режима обязательной аутентификации любой запрос к TDG, а также доступ к веб-интерфейсу потребуют идентификации и аутентификации.
После идентификации и аутентификации пользователя в веб-интерфейсе будут скрыты недоступные для роли текущего пользователя вкладки.
Для выполнения идентификации и аутентификации можно использовать один из следующих способов:
Передача логина и пароля пользователя.
Передача параметра
lsid
из файла-cookie (в основном используется веб-интерфейсом после первого ввода логина и пароля для последующих аутентификаций).Передача токена приложения.
2.7.6. Авторизация внешних пользователей и систем через LDAP¶
Система TDG поддерживает технологию единого входа (Single Sign-On). Таким образом, авторизованный доступ к данным и функциям TDG возможен не только через токены и пользователей, но и через LDAP.
Чтобы настроить авторизацию внешних пользователей и систем через LDAP, пропишите необходимые параметры
в файле конфигурации config.yml
.
Добавить секцию LDAP в файл конфигурации можно на любом этапе работы с системой TDG.
В самом начале настройки LDAP стоит обратить внимание на параметры domain
и organizational_units
.
Они используются при аутентификации для поиска пользователя в соответсвующем домене и организационном юните(-ах).
Логином в систему является строка вида имя пользователя@domain
, где:
имя пользователя
это пользователь в LDAP, который состоит в описанном выше домене и организационном юнитеdomain
это домен LDAP также описанный выше
Например: johndoe@example.com
.
Однако, если опция use_active_directory
выставлена в True
, то логином в систему будет являться атрибут userPrincipalName
у пользователя LDAP.
Примечание
Для локального тестирования LDAP авторизации предлагается использовать сервер GLAuth. Гарантируется работа с версией GLAuth 2.0.0.
2.7.7. Режимы функционирования TDG¶
TDG может функционировать в двух режимах:
режиме эксплуатации (production mode);
режиме разработки (dev mode).
Режим эксплуатации является основным для штатной эксплуатации TDG.
Режим разработки предоставляет дополнительный функционал (см. список ниже), который используется при разработке пользовательского кода и отладке работы системы. Однако при штатной эксплуатации этот функционал может снижать производительность системы и создавать ситуации, потенциально небезопасные с точки зрения сохранности данных и уязвимости системы. Поэтому в версии TDG, сертифицированной по требованиям доверия ФСТЭК России, использование режима разработки запрещено.
Дистрибутивы установки для этих двух режимов разные. По умолчанию выдается дистрибутив для работы в режиме эксплуатации.
В режиме разработки доступны следующие дополнительные функции (по сравнению с режимом эксплуатации):
GraphQL-запрос на удаление данных (mutation) во всех спейсах экземпляров с ролью «storage»;
GraphQL-запросы на чтение (query) и изменение (mutation) конфигурации кластера и настроек системы;
GraphQL-запросы (mutation)
evaluate
для выполнения любого кода, включая код для чтения и изменения данных;включен «строгий режим» (встроенный модуль Tarantool
strict
), который позволяет отслеживать использование необъявленных глобальных переменных;более полная проверка (с помощью модуля Tarantool
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>