2.7. Настройки безопасности¶

2.7.1. Ролевая модель доступа¶

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

• «admin»;

• «supervisor»;

• «user».

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

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

Текущий список ролей пользователей можно увидеть на вкладке Settings > Roles:

Для работы ролевой модели доступа необходимо назначить одному из наборов реплик в кластере роль account_manager. Это делается на этапе настройки кластера.

2.7.2. Управление пользователями¶

Текущий список пользователей TDG и инструменты для управления ими находятся на вкладке Settings > Users:

Управление пользователями включает в себя следующие операции:

• управление профилем пользователя (создание, редактирование, удаление);

• изменение статуса пользователя;

• сброс пароля пользователя;

• экспорт/импорт пользовательских профилей;

• управление политикой паролей.

2.7.2.1. Создание профиля пользователя¶

Для создания профиля пользователя TDG:

1. В web-интерфейсе перейдите на вкладку Settings > Users и нажмите Create user. Откроется диалог создания пользователя.

   

2. В диалоге укажите следующие параметры:

   • Name — имя пользователя;

   • Email — электронная почта пользователя;

   • Password — пароль для авторизации в системе (должен соответствовать политике паролей). Также пароль можно сгенерировать автоматически:

     • либо кнопкой Generate;

     • либо оставить поле пустым — в этом случае система автоматически сгенерирует пароль и отправит пользователю на указанный Email (для этого необходимо иметь настроенный SMTP-сервер).

   • Expires in — (опционально) срок действия пароля;

   Примечание

   Проверка истечения срока действия паролей выполняется примерно раз в 30 минут. Учетные записи с истекшим сроком действия паролем блокируются.

   • Role — роль пользователя согласно ролевой модели доступа.

3. Нажмите Submit.

При создании профиля автоматически генерируется уникальный идентификатор пользователя, который отображается в колонке LOGIN в таблице User list и используется в дальнейшем для авторизации в web-интерфейсе.

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

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

Примечание

Помимо создания профилей пользователей в web-интерфейсе, их можно импортировать в систему посредством JSON-файла.

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 варианта создания пароля:

1. Указать пароль в явном виде в поле password — в этом случае флаг Generate passwords в диалоге импорта отмечать не нужно (см. ниже процедуру импорта), и пароль для пользователя будет взять из поля password как есть. При этом пароль должен соответствовать текущей политике паролей, определенной в системе.

2. Сгенерировать пароль автоматически — в этом случае в поле 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
   }
]

Для импорта профилей пользователей:

1. На вкладке Settings > Users нажмите Import. Откроется диалоговое окно.

   

2. В диалоговом окне выберите 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), который потом назначается для каких-либо из пользовательских ролей.

Для создания профиля доступа:

1. Перейдите на вкладку Settings > Data actions.

2. Нажмите Add new Data Action. Откроется диалог создания профиля.

   

3. В поле Name введите имя профиля доступа.

4. Для каждого из агрегатов отметьте галочками нужные права, Read и/или Write.

5. Сохраните профиль, нажав Save.

Созданный профиль доступа отображается на вкладке Settings > Data actions. Профиль является редактируемым, т.е. в дальнейшем можно изменять права Read/Write для нужных агрегатов.

После создания профиль становится доступен для назначения какой-либо роли.

Чтобы назначить профиль доступа для существующей роли:

1. Перейдите на вкладку Settings > Roles и в колонке Action для нужной роли нажмите Edit.

2. В диалоге редактирования отметьте флаг Allowed для нужного профиля доступа.

   

3. Сохраните настройки роли, нажав Save.

Аналогично профиль доступа можно назначить и при создании новой роли.

2.7.5. Режим обязательной аутентификации¶

Для этого необходимо:

1. Создать профиль пользователя с ролью «admin».

2. Авторизоваться в системе под этим пользователем.

3. Включить режим обязательной аутентификации (отключить анонимный доступ).

Режим обязательной аутентификации включается/отключается на вкладке Cluster переключателем Auth.

После идентификации и аутентификации пользователя в веб-интерфейсе будут скрыты недоступные для роли текущего пользователя вкладки.

Для выполнения идентификации и аутентификации можно использовать один из следующих способов:

1. Передача логина и пароля пользователя.

2. Передача параметра lsid из файла-cookie (в основном используется веб-интерфейсом после первого ввода логина и пароля для последующих аутентификаций).

3. Передача токена приложения.

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.

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 для включения соответствующего режима функционирования. Скрипты находятся в корневой директории дистрибутива.

Развернутый экземпляр можно переключить в другой режим работы. Для этого необходимо:

1. На сервере, где развернут экземпляр, перейти в директорию, где хранятся исполняемые файлы для этого экземпляра /usr/share/tarantool/<instance_name>

2. Запустить нужный скрипт (enable_dev_mode.sh или enable_prod_mode.sh).

3. Перезапустить экземпляр:

   systemctl restart <instance_name>