Администрирование

• 1: Основные настройки
• 1.1: Настройки конфигурации Аналитического портала
• 1.2: База данных Аналитического портала
• 1.3: База данных Аналитического портала
• 1.4: Сетевые настройки Аналитического портала
• 1.5: Как настроить https
• 1.6: Технические сведения о используемых стандартах для HTTPS
• 1.7: Как настроить https с прокси-сервером
• 2: Установка и запуск
• 3: Обновление Modus BI
• 4: Лицензирование портала
• 5: Кэширование аналитического портала
• 6: Права доступа и роли аналитического портала
• 7: Провайдеры аутентификации
• 8: Профиль наборов данных
• 9: Настройка прав доступа на уровне записей (RLS)
• 10: Настройка RLS запросами с пользовательскими переменными
• 11: Настройка пользовательских переменных
• 12: Размещение через iframe портала Modus на стороннем ресурсе
• 13: Использование безопасного режима для отладки отчётов

1 - Основные настройки

Modus: Аналитический портал является веб-приложением и состоит условно из трёх частей:

• «Клиента» (Frontend) — средство отображения интерфейсов приложения в браузере;
• «Сервера» (Backend) — основное приложение, выполняющее роль веб-сервера, взаимодействующего с источниками данных и выполняющего пользовательские команды;
• «Данные и метаданные» — служебные данные необходимые для работы (настройки, команды, списки сущностей и т.д.). Распологаются в базе данных Аналитического портала. Для размещения базы данных Аналитического портала используется СУБД PostgreSQL.

1.1 - Настройки конфигурации Аналитического портала

Изменение базовых настроек портала выполняются из WEB-клиента аналитического портала и в файле настроек «modusbi.json», расположенного в каталоге исполняемого файла аналитического портала.
Настройки Аналитического портала, редактируемые из WEB-клиента сохраняются и считываются в базе метаданных.
Настройки в файле редактируются вручную, изменения в WEB-клиенте не изменяют файл настроек.
Часть настроек доступных из WEB-клиента дублируется настройками из файла. Настройки из файла имеют более высокий приоритет. Список смежных настроек приведён ниже.
Если есть необходимость настраивать смежные настройки из WEB-клиента, настройку из файла необходимо убрать (как значение, так и само свойство).

Настройки из WEB-клиента

Используя WEB-клиент, перейдите в меню «Администрирование» и выберите раздел «Настройки портала»:

Откроется окно с настройками:

Доступные из WEB-клиента настройки:

Файл настроек «modusbi.json»

Файл настроек «modusbi.json» находится в каталоге размещения исполняемого файла аналитического портала.

{
	"metadata": {
		"driver": "postgres",
		"datasource": "postgres://pg_user:pg_passw@pg_server:5432/BASE_NAME?application_name=modusbi&sslmode=disable",
		"maxopenconns": 100,
		"maxidleconns" : 20,
		"maxlifetime": 3600
	},
	"server": {
		"host": "192.168.0.1",
		"port": 3000,
		"debug": "enabled"
	},
	"backend": {
		"protocol": "http",
		"host": "192.168.0.1",
		"port": 3000,
		"base_url": "/v1/api/"
	},
	"frontend": {
		"base_url": "/"
	},
	"form": {
		"base_url": "/fvd"
	},
	"update": {
		"path": "update"
	},
	"backup": {
		"path": "backup"
	},
	"Databases": {
		"Vertica" : {
			"InMemoryResultRowLimit": 1000			
		}
	},
	"CollLogger": "enabled",
	"auth": {
		"log": {
			"to_file": true,
			"to_metadata": false
		}
	}
}	

, где

Соответствие настроек WEB-клиента и ифайла настроек

Некоторые настройки можно редактировать как в интерфейсе WEB-клиента так и в файле настроек «modusbi.json»:

Примечание: Настройки в файле имеют приоритет перед аналогичными настройками в WEB-клиенте. Если необходимо иметь возможность выполнять некоторые настройки из WEB-клиента, аналогичную настройку из файла необходимо убрать (как значение, так и само свойство).

1.2 - База данных Аналитического портала

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

В качестве СУБД, для размещения базы данных Аналитическому порталу требуется PostgreSQL (версии не ниже 10).
Всё дальнейшее описание будет вестись из расчета использования именно этой СУБД.
СУБД PostgreSQL предварительно необходимо установить и настроить.

Примечание: за дистрибутивами СУБД PostgreSQL и инструкциями по установке и настройке перейдите на официальный сайт разработчика:

• https://www.postgresql.org/download/
• https://www.postgresql.org/docs/10/runtime-config.html

Если СУБД PostgreSQL устанавливается впервые и будет использоваться без дополнительного ПО – пуллеров соединений (PgBouncer, Pgpool-II и т.д.), то для корректной работы с Аналитическим порталом в файле конфигурации PostgreSQL необходимо правильно сконфигурировать следующий параметр:

• max\_connections — пиковое количество одновременно работающих пользователей (значение рассчитывается в зависимости от мощности сервера, по-умолчанию 100).

Примечание: до версии Аналитического портала 3.0 использовалась встраиваемая СУБД — SQLite.

Инициализация базы данных портала

Для инициализации базы данных Аналитического портала необходимо:

1. создать пустую базу данных;
2. указать параметры подключения к базе данных в файле настроек;
3. выполнить первоначальное заполнение при помощи специальной команды.

Шаг 1. Создание базы данных СУБД

В СУБД необходимо создать базу данных с любой основной схемой (в PostgreSQL по умолчанию — это «public»).
Никаких элементов внутри созданной базы данных дополнительно создавать не требуется.

Примечание: О том, как создать базу данных в СУБД PostgreSQL можно прочесть в официальном руководстве:

• https://www.postgresql.org/docs/current/manage-ag-createdb.html

Шаг 2. Указание параметров подключения к базе в файле настроек

Для подключения Аналитического портала к базе данных, необходимо в файле настроек Аналитического портала «modusbi.json», в разделе metadata указать параметры подключения к базе данных:

{
  ...
  "metadata": {
    "driver": "postgres",
    "datasource": "postgres://<ПОЛЬЗОВАТЕЛЬ_БД>:<ПАРОЛЬ_БД>@<IP-АДРЕС_PG>:<ПОРТ_PG>/<ИМЯ_БД>?application_name=modusbi&sslmode=disable",
    "maxopenconns": <максимальное количество одновременно открытых соединений>,
    "maxidleconns" : <максимальное количество открытых соединений в пуле>,
    "maxlifetime": <максимальное время жизни соединения в пуле>
  }
  ...
}

• driver — Строка — Имя драйвера для подключения к серверу СУБД, всегда «postgres»;
• datasource — Строка — Строка, в которой закодированы параметры подключения к базе данных:
  • <ПОЛЬЗОВАТЕЛЬ_БД> — Строка — Логин пользователя СУБД;
  • <ПАРОЛЬ_БД> — Строка — Пароль пользователя СУБД;
  • <IP-АДРЕС_PG> — Строка — IP-адрес сервера СУБД;
  • <ПОРТ_PG> — Число — Порт используемый сервером СУБД;
  • <ИМЯ_БД> — Строка — Имя базы данных на сервере СУБД, созданной на предыдущем шаге;
• maxopenconns — Число — Максимальное количество одновременно открытых соединений. Не должно быть больше значения max_connections в настройках СУБД PostgreSQL;
• maxidleconns — Число — Максимальное количество открытых (ожидающих) соединений в пуле;
• maxlifetime — Число — Максимальное время жизни соединения в пуле. Указывается в секундах.

Пример: Аналитический портал и СУБД PostgreSQL установлены на одном сервере. Сервер СУБД PostgreSQL «слушает» стандартный порт «5432». Для подключения используется учетная запись пользователя СУБД с логином «admin» и паролем «pass». Имя базы данных для портала — «modusbi». Для описываемого случая, раздел «metadata» файла настроек будет следующим:

{
  ...
  "metadata": {
    "driver": "postgres",
    "datasource": "postgres://admin:pass@localhost:5432/modusbi?application_name=modusbi&sslmode=disable",
    "maxopenconns": 100,
    "maxidleconns" : 20,
    "maxlifetime": 3600
    }
  ...
}

Примечание: Пользователь СУБД, чей логин и пароль указывается в файле настроек портала, должен иметь в подключаемой базе данных права следующих типов: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE.

Шаг 3. Первоначальное заполнение базы данных

Для первоначального заполнения базы данных необходимо запустить выполнение файла портала в режиме инициализации. Для запуска портала в режиме инициализации используется ключ -init.
Для Windows:

C:\portal>modusbi.exe -init

Для Linux:

/opt/modusbi# ./modusbi -init

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

Если всё настроено верно, в файле лога «modusbi.log» появится соответствующее сообщение:

«Cозданы метаданные в <БД PostgreSQL>, необходимо перезапустить сервер.»

где

• <БД PostgreSQL> — Имя созданной вами базы данных;
• сервер — (который необходимо перезапустить) — это сам Аналитический портал, исполняющий роль сервера в клиент-серверной архитектуре.

Запуск с ключом -init выполняется только при первоначальной настройке. Последующие запуски производятся без использования данного ключа.

1.3 - База данных Аналитического портала

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

В качестве СУБД, для размещения базы данных Аналитическому порталу требуется PostgreSQL (версии не ниже 10).
Всё дальнейшее описание будет вестись из расчета использования именно этой СУБД.
СУБД PostgreSQL предварительно необходимо установить и настроить.

Примечание: За дистрибутивами СУБД PostgreSQL и инструкциями по установке и настройке перейдите на официальный сайт разработчика:

• https://www.postgresql.org/download/
• https://www.postgresql.org/docs/10/runtime-config.html

Если СУБД PostgreSQL устанавливается впервые и будет использоваться без дополнительного ПО – пуллеров соединений (PgBouncer, Pgpool-II и т.д.), то для корректной работы с Аналитическим порталом в файле конфигурации PostgreSQL необходимо правильно сконфигурировать следующий параметр:

• max\_connections - пиковое количество одновременно работающих пользователей (значение рассчитывается в зависимости от мощности сервера, по-умолчанию 100).

Примечание: До версии Аналитического портала 3.0 использовалась встраиваемая СУБД – SQLite

Инициализация базы данных портала

Для инициализации базы данных Аналитического портала необходимо:

1. Создать пустую базу данных
2. Указать параметры подключения к базе данных в файле настроек
3. Выполнить первоначальное заполнение при помощи специальной команды

Шаг 1. Создание базы данных СУБД

В СУБД необходимо создать базу данных с любой основной схемой (в PostgreSQL по умолчанию – это public).
Никаких элементов внутри созданной базы данных дополнительно создавать не требуется.

Примечание: О том, как создать базу данных в СУБД PostgreSQL можно прочесть в официальном руководстве:

• https://www.postgresql.org/docs/current/manage-ag-createdb.html

Шаг 2. Указание параметров подключения к базе в файле настроек

Для подключения Аналитического портала к базе данных, необходимо в файле настроек Аналитического портала modusbi.json, в разделе "metadata" указать параметры подключения к база данных:

{
  ...
  "metadata": {
    "driver": "postgres",
    "datasource": "postgres://<ПОЛЬЗОВАТЕЛЬ_БД>:<ПАРОЛЬ_БД>@<IP-АДРЕС_PG>:<ПОРТ_PG>/<ИМЯ_БД>?application_name=modusbi&sslmode=disable",
    "maxopenconns": <максимальное количество одновременно открытых соединений>,
    "maxidleconns" : <максимальное количество открытых соединений в пуле>,
    "maxlifetime": <максимальное время жизни соединения в пуле>
  }
  ...
}

• driver - Строка - Имя драйвера для подключения к серверу СУБД, всегда “postgres”.
• datasource - Строка - Строка, в которой закодированы параметры подключения к базе данных.
  • <ПОЛЬЗОВАТЕЛЬ_БД> - Строка - Логин пользователя СУБД.
  • <ПАРОЛЬ_БД> - Строка - Пароль пользователя СУБД.
  • <IP-АДРЕС_PG> - Строка - IP адрес сервера СУБД.
  • <ПОРТ_PG> - Число - Порт используемый сервером СУБД.
  • <ИМЯ_БД> - Строка - Имя базы данных на сервере СУБД, созданной на предыдущем шаге.
• maxopenconns - Число - Максимальное количество одновременно открытых соединений. Не должно быть больше значения max_connections в настройках СУБД PostgreSQL.
• maxidleconns - Число - Максимальное количество открытых (ожидающих) соединений в пуле.
• maxlifetime - Число - Максимальное время жизни соединения в пуле. Указывается в секундах.

Пример: Аналитический портал и СУБД PostgreSQL установлены на одном сервере. Сервер СУБД PostgreSQL слушает стандартный порт 5432. Для подключения используется учетная запись пользователя СУБД с логином admin и паролем pass.Имя базы данных для портала – modusbi. Для описываемого случая, раздел «metadata» файла настроек будет следующим:

{
  ...
  "metadata": {
    "driver": "postgres",
    "datasource": "postgres://admin:pass@localhost:5432/modusbi?application_name=modusbi&sslmode=disable",
    "maxopenconns": 100,
    "maxidleconns" : 20,
    "maxlifetime": 3600
    }
  ...
}

Примечание: Пользователь СУБД, чей логин и пароль указывается в файле настроек портала, должен иметь в подключаемой базе данных права следующих типов: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE.

Шаг 3. Первоначальное заполнение базы данных

Для первоначального заполнения базы данных необходимо запустить выполнение файла портала в режиме инициализации. Для запуска портала в режиме инициализации используется ключ "-init".
Для Windows:

C:\portal>modusbi.exe -init

Для Linux:

/opt/modusbi# ./modusbi -init

Примечание: Пользователь OS, под чьей учетной записи производится запуск приложения портала, должен иметь право на создание, изменение, удаление файлов в каталоге размещения исполняемого файла портала и на запуск исполняемого файла портала.

Если всё настроено верно, в файле лога modusbi.log появится соответствующее сообщение:

Созданы метаданные в '<БД PostgreSQL>', необходимо перезапустить сервер.

где,

• <БД PostgreSQL> - Имя созданной вами базы данных.
• сервер - (который необходимо перезапустить) это сам Аналитический портал, исполняющий роль сервера в клиент-серверной архитектуре.

Запуск с ключом “-init” выполняется только при первоначальной настройке. Последующие запуски производятся без использования данного ключа.

1.4 - Сетевые настройки Аналитического портала

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

Сетевые настройки портала устанавливаются в WEB-клиенте аналитического портала или в файле настроек «modusbi.json», находящегося в каталоге исполняемого файла аналитического портала. Настройки в файле редактируются вручную. Изменения сделанные в WEB-клиенте не изменяют файл настроек.
Часть настроек доступных из WEB-клиента дублируется настройками из файла. Настройки из файла имеют более высокий приоритет, список смежных настроек приведён ниже.
Если есть необходимость настраивать смежные настройки из WEB-клиента, настройку из файла необходимо убрать (как значение, так и само свойство).

Структура URL

После загрузки клиентской части Аналитического портала в память браузера по первоначальной ссылке, клиент отправляет запросы на сервер, генерируя URL на основании настроек:

• «Протокол»:
  • «Протокол сервера данных»;
• «Доменная часть»:
  • «Адрес сервера данных»;
  • «Порт сервера данных»;
• «Путь на сервере»:
  • «Корневой каталог приложения на сервере» — имя службы, если доменное имя маскирует несколько служб или «/» если доменное имя представляет только Аналитический портал;
  • «Путь к API данных» — путь относительно корневого каталога, где опубликован API сервера портала, по умолчанию «/v1/api/»;
    • «Корневой каталог приложения Форм Ввода Данных» — путь к подразделу форм ввода данных относительно пути к API. По умолчанию «/fvd».

Настройки из WEB-клиента

Файл настроек modusbi.json

Файл настроек «modusbi.json» находится в каталоге размещения исполняемого файла аналитического портала.

{
	"metadata": {
    ...
	"server": {
		"host": "192.168.0.1",
		"port": 3000,
		"debug": "enabled"
	},
	"backend": {
		"protocol": "http",
		"host": "192.168.0.1",
		"port": 3000,
		"base_url": "/v1/api/"
	},
	"frontend": {
		"base_url": "/"
	},
	"form": {
		"base_url": "/fvd"
	},
	...
}	

, где

Соответствие сетевых настроек WEB-клиента и файла настроек

Некоторые настройки можно редактировать как в интерфейсе WEB-клиента так и в файле настроек modusbi.json:

Примечание: Настройки в файле имеют приоритет перед аналогичными настройками в WEB-клиенте. Если необходимо иметь возможность выполнять некоторые настройки из WEB-клиента, аналогичную настройку из файла необходимо убрать (как значение, так и само свойство).

1.5 - Как настроить https

Использование протокола https для связи клиента и сервера можно организовать как сторонними средствами (например, при помощи прокси сервер), так и средствами Аналитического портала.
В данной статье описывается как включить использование https протокола средствами Аналитического портала.

Для включения HTTPS протокола вам понадобится файл сертификата и файл закрытого ключа, оба в формате PEM. Данные файлы необходимо загрузить в настройки Аналитического портала.

Примечание: Более подробная информация о используемых форматах и стандартах находится в разделе “TLS: стандарты, ключи, шифры”

Далее описан процесс настройкй по шагам.

Шаг 1: Загрузка файлов

Используя WEB-клиент, перейдите в меню «Администрирование» и выберите раздел «Настройки портала»:

В этом разделе вам нужно поочерёдно загрузить файлы сертификата и закрытого ключа:

• «Ключ SSL» — настройка для загрузки закрытого ключа
• «Сертификат SSL» — настройка для загрузки сертификата

Для загрузки файла нажмите на кнопку с надписью «Выберите файл».
Файл будет загружен, а вместо кнопки выбора появится кнопка очистки:

Если вы хотите заменить ранее загруженный файл, нужно нажать на кнопку с надписью «Очистить». Кнопка очистки исчезнет, а на её месте вновь появится кнопка выбора.

Примечание: Загрузка и очистка производят изменения локально, в памяти WEB-Клиента. То есть, файл сначала загружается в память WEB-клиента, а после сохранения настроек (кнопка «Сохранить настройки») файл из памяти клиента попадает в базу данных Аналитического портала. При очистке, клиент запоминает факт очистки, и при записи файл удаляется из базы данных Аналитического портала.

Шаг 2: Выбор протокола

В том же разделе «Настройки портала», выберете протокол HTTPS в качестве значения для настройки «Протокол сервера данных».

Аналогично, выбор протокола можно произвести, указав его в файле настроек modusbi.json:

{
  ...
  "backend": {
    "protocol": "https",
  ...
  },
  ...
}

Примечание:

1. Настройка «Протокол сервера данных», находящаяся в файле, имеет приоритет перед аналогичной настройкой в WEB-клиенте. Если есть необходимость иметь возможность настраивать протокол из WEB-клиента, настройку из файла необходимо убрать (как значение, так и само свойство protocol).

2. Параметры «Ключ SSL» и «Сертификат SSL» настраиваются только из WEB-клиента.

Шаг 3: Сохранить настройки

После того как файлы загружены и выбран протокол, необходимо сохранить сделанные изменения в настройках.
Для сохранения изменений, сделанных в WEB-клиенте, в том же разделе «Настройки портала» нажмите на кнопку «Сохранить настройки».

Шаг 4: Перезагрузить сервер Аналитического портала

Для применения сохраненных изменений настроек сервер Аналитического портала нужно перезагрузить.
Для перезагрузки сервера с новыми настройками можно воспользоваться кнопкой «Перезагрузка», в том же разделе «Настройки портала».

После перезагрузки, если всё было настроено верно, сервер портала будет использовать https-протокол для связи с WEB-клиентом.

Примечание:

1. В текущей реализации сервера, валидация загруженных файлов сертификата и ключа на предмет их соответствия техническим требованиям происходит только при запуске сервера Аналитического портала. Если при запуске файлы не пройдут проверку, то сервер запустится с поддержкой http-протокола, о чём в файле лога будет сделана отметка. Там же, в файле лога будет указана причина несоответствия файлов нужным требованиям.

2. В текущей реализации сервера, проверка файлов на предмет соответствия параметрам производится при условии правильного определения mime типа файлов сертификата и ключа со стороны браузера WEB-клиента. Если сервер не переходит в режим использования https-протокола, а в файле лога присутствует сообщение о ошибке декодирования файла сертификата или ключа, обратитесь в техническую поддержку.

1.6 - Технические сведения о используемых стандартах для HTTPS

Транспорт

В качестве транспортного механизма для HTTPS Аналитический портал использует TLS.
Поддерживаемые версии TLS: 1.0, 1.1, 1.2 (RFC 5246), 1.3 (RFC 8446).

Файлы

• Файл сертификата:

  • Должен быть в формате Privacy Enhanced Mail (PEM);
  • PEM должен быть контейнером для ASN.1 DER.

• Файл закрытого ключа:

  • Должен быть в формате Privacy Enhanced Mail (PEM);
  • PEM должен быть контейнером для ASN.1 DER;
  • Поддерживаются PKCS#1 и PKCS#8.

Допустимые комбинации стандартов для файла закрытого ключа:

• PEM » ASN.1 DER » PKCS#1 » RSA;
• PEM » ASN.1 DER » PKCS#8 » RSA;
• PEM » ASN.1 DER » PKCS#8 » ECDSA;
• PEM » ASN.1 DER » PKCS#8 » ED25519;
• PEM » ASN.1 DER » ED25519.

Сертификат

Формат сертификата определён стандартом X.509. Данный тип сертификата в обиходе имеет второе, не техническое наименование — сертификат SSL. Поддерживаются версии до X.509v3 включительно. Актуальной на момент написания инструкции является версия X.509v3.

Ключевая пара

Поддерживаются следующие типы ключей:

• RSA – PKCS#1v2, RFC8017 — без ограничения на размер ключа. Максимальное значение открытой экспоненты (2^31)-1;
• ECDSA – FIPS186-4, SEC1v2 — поддерживаются именованные кривые: secp224r1, secp256r1, prime256v1, secp384r1, secp521r1;
• ED25519 – RFC8032 — только для TLS 1.3.

Защита передаваемых данных

Поддерживаемые типовые шифронаборы для TLS 1.0–1.2:

• TLS_ECDHE_RSA_WITH_RC4_128_SHA;
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA;
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA;
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA;
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305;
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA;
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA;
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA;
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305;
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
• TLS_RSA_WITH_AES_256_CBC_SHA;
• TLS_RSA_WITH_AES_256_GCM_SHA384;
• TLS_RSA_WITH_AES_128_CBC_SHA;
• TLS_RSA_WITH_RC4_128_SHA;
• TLS_RSA_WITH_3DES_EDE_CBC_SHA;
• TLS_RSA_WITH_AES_128_CBC_SHA256;
• TLS_RSA_WITH_AES_128_GCM_SHA256.

Поддерживаемые типовые шифронаборы для TLS только 1.2:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305;
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305;
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
• TLS_RSA_WITH_AES_128_GCM_SHA256;
• TLS_RSA_WITH_AES_128_CBC_SHA256;
• TLS_RSA_WITH_AES_256_GCM_SHA384.

Общий шаблон имени набора для TLS 1.0–1.2:

TLS_<**Алгоритм аутентификации**>_WITH_<**Шифр данных**>_<**Хеш-функция**>

, где

• «Алгоритм аутентификации» — криптосистема, используемая для аутентификации (аутентифицируются сервер и сеансовый секрет);
• «Шифр данных» — симметричный алгоритм, который послужит для защиты передаваемых данных;
• «Хеш-функция» — хеш-функция, являющаяся основой для HMAC.

Поддерживаемые типовые шифронаборы для TLS только 1.3:

• TLS_AES_128_GCM_SHA256;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_256_GCM_SHA384.

Общий шаблон имени набора для TLS 1.3:

TLS_<**Шифр данных**>_<**Хеш-функция**>

, где

• «Шифр данных» — симметричный алгоритм, который послужит для защиты передаваемых данных;
• «Хеш-функция» — хеш-функция, являющаяся основой для HMAC.

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

1.7 - Как настроить https с прокси-сервером

Альтернативным вариантом настройки протокола HTTPS для связи клиента и сервера является использование прокси- сервера, как промежуточного звена между клиентом и сервером Аналитического портала. При этом сервер аналитического портала должен иметь соответствующие настройки.

Настройки сервера Аналитического портала

Сервер Аналитического портала сообщает клиенту аналитического портала информацию нужную для построения URL к API сервера, с указанием типа используемого протокола. При использовании HTTPS протокола, настроенного на прокси-сервере, связь прокси-сервера с Аналитическим порталом имеет смысл вести с использованием протокола HTTP, для снижения нагрузки. Нагрузка при этом ложится на прокси-сервер.

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

Примечания:

1. Настройка «Протокол сервера данных» находящаяся в файле имеет приоритет перед аналогичной настройкой в WEB-клиенте. Если есть необходимость иметь возможность настраивать протокол из WEB-клиента, настройку из файла необходимо убрать (как значение, так и само свойство protocol).
2. Параметры «Ключ SSL» и «Сертификат SSL» настраиваются только из WEB-клиента.

Настройки прокси-сервера

Настройка прокси-сервера будет показана на примере Ngnix.

Nginx

Операционная система: Debian GNU/Linux 12 (bookworm).

Способ установки: из репозитория дистрибутива.

Шаг 1. Обновление информации и установка Ngnix

Обновляем информацию о репозитории и устанавливаем пакет Ngnix:

apt-get update  
apt-get install nginx

Шаг 2. Перенос файлов в каталоги

Помещаем сертификат и ключ в каталоги:

cp ./ssl-cert.pem /etc/ssl/certs/
cp ./ssl-cert.key /etc/ssl/private/

Шаг 3. Создание файла конфигурации

Создаем файл конфигурации SSL nginx:

nano /etc/nginx/snippets/ssl.conf

Добавляем строки о сертификате и ключе в созданный файл:

ssl_certificate /etc/ssl/certs/ssl-cert.pem;
ssl_certificate_key /etc/ssl/private/ssl-cert.key;

Сохраняем изменения.

Шаг 4. Настройка файла nginx

Настраиваем Ngnix. Удаляем link дефолтного файла конфигурации:

rm /etc/nginx/sites-enabled/*

Создаём новый файл конфигурации:

nano /etc/nginx/sites-available/new_site

Добавляем в файл строки:

server {
 	listen 443 ssl;
	server_name  new_site;
	include snippets/ssl.conf;

	location / {
		proxy_pass http://127.0.0.1:3000;
		proxy_set_header Host $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

		client_max_body_size 200M;
		proxy_max_temp_file_size 0;
		proxy_buffering off;
	}
}

, где

• http://127.0.0.1:3000 — адрес сервера и порта на котором запущена служба Аналитического портала.
• new_site — адрес сайта.

Сохраняем и выходим.

Создаем link на созданный нами файл конфигурации:

ln -s /etc/nginx/sites-available/new_site /etc/nginx/sites-enabled/new_site

Шаг 5. Настройка внешнего адреса в файле «modusbi.json»

Необходимо настроить параметры подключения к серверу Backend в файле «modusbi.json». К указанному адресу будут обращаться клиентские соединения из браузера при работе с аналитическим порталом. В общем случае обращение должно выполняться к устройству, на котором запущен аналитический портал.

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

Добавляем в файл «modusbi.json» строки:

{
...
  "backend": {
    "protocol": "https",
    "host": "new_site",
    "port": 443,
    "base_url": "/v1/api/"
  }
...
}

, где

• new_site — адрес сайта.

Шаг 6. Перезагрузка

Перезапускаем службу Nginx:

systemctl reload nginx.service

Настройка завершена.

2 - Установка и запуск

Состав и содержание дистрибутива

Дистрибутив содержит:

• «modusbi» — исполняемый файл, являющийся сервером для Аналитического портала. Расширение файла зависит от платформы (операционной системы):
  • «Windows» — исполняемый файл «modusbi.exe»;
  • «Linux» — исполняемый файл «modusbi»;
• «modusbi.json» — файл настройки, который можно использовать для быстрой первичной настройки. Позволяет не изменяя метаданные запустить портал с любыми предварительными настройками;
• «modusbi-init.mbm» — файл инициализации базы данных Аналитического портала;
• «modusbi.mbv» — триальный ключ, позволяющий работать с Аналитическим порталом 30 дней.
• «update/modusbi.mbu» — файл обновления базы данных Аналитического портала до последней версии.

Дополнительно, в дистрибутиве для «Windows» содержатся:

• «modusbi.bat» — файл для запуска Аналитического портала как приложения;
• «service-create.bat» — файл создания сервиса Аналитического портала;
• «service-delete.bat» — файл удаления сервиса Аналитического портала.

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

Подготовка перед установкой АП

1. Перед установкой аналитического портала необходимо развернуть базу данных под управлением СУБД PostgrеSQL для хранения настроек АП.

Для установки СУБД Postger SQL обратитесь к официальному руководству:

https://www.postgresql.org/download/

https://www.postgresql.org/docs/10/runtime-config.html_

2. После установки СУБД, создайте новую базу данных, например «modusbi»:

CREATE DATABASE "modusbi"

Установка АП для Windows

Необходимо запустить файл дистрибутива «ModusBI-xx.xx.xx.exe», где «хх.хх.хх» - номер устанавливаемого релиза. В появившемся окне нажать кнопку «Далее» и указать путь к каталогу, куда будет установлен аналитический портала, затем подождать пока файлы распакуются и завершить установку.

Запуск портала в режиме службы

Для запуска портала в режиме службы необходимо запустить файл «service-create.bat», для удаления «service-delete.bat». Оба файла находятся в каталоге, куда была выполнена установка.

Установка АП из .deb пакета

Необходимо скопировать на диск файл установки с расширением «.deb» и выполнить команду:

sudo dpkg -i ИмяФайла.deb

По умолчанию программа будет установлена в каталог «/opt/modusbi».

Запуск и остановка службы выполняется командами:

systemctl start/stop modusbi

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

Установка АП из .rpm пакета

Необходимо скопировать на диск файл установки с расширением «.rpm» и выполнить команду:

sudo rpm -i ИмяФайла.rpm

По умолчанию программа будет установлена в каталог «/opt/modusbi».

Запуск и остановка службы выполняется командами:

systemctl start/stop modusbi

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

Первоначальная настройка аналитического портала

Настройка «modusbi.json»

После установки необходимо перейти в каталог, куда были распакованы файлы и в первую очередь необходимо отредактировать файл «modusbi.json». Далее требуется несколько действий, описанных ниже.

1. Настроить параметры подключения к СУБД PostgreSQL в блоке «metadata».

{
  "metadata": { 
    "driver": "postgres", 
    "datasource": "postgres://<ПОЛЬЗОВАТЕЛЬ_БД>:<ПАРОЛЬ_БД>@<IP-АДРЕС_PG>:<ПОРТ_PG>/<ИМЯ_БД>?application_name=modusbi&sslmode=disable", 
    "maxopenconns": <максимальное количество одновременно открытых соединений, не больше значения max_connections в PostgreSQL>, 
    "maxidleconns": <максимальное количество открытых (ожидающих) соединений в пуле>, 
    "maxlifetime": <максимальное время жизни соединения в пуле, секунды> 
    }
}

Например, СУБД установлена на том же сервере, что и аналитический портал, и подключение к ней выполняется стандартный порт 5432. Была создана база данных «modusbi» и был создан пользователь «postgres», ему задан пароль «my_pass». Тогда строка подключения будет выглядеть по умолчанию следующим образом:

{
  "metadata": { 
    "driver": "postgres", 
    "datasource": "postgres://postgres:my_pass@127.0.0.1:5432/modus?application_name=modusbi&sslmode=disable", 
    "maxopenconns": 100, 
    "maxidleconns" : 20, 
    "maxlifetime": 3600 
    }
}

2. Настроить хост сервера в блоке «server». По умолчанию сервер прослушивает порт 3000 только на локальном хосте 127.0.0.1, если предполагается переход в аналитический портал с других устройств, необходимо установить в качестве значение "host": "0.0.0.0"

Например, предполагается вход на аналитический портал с других устройств на порт 3000. Тогда блок «server» будет иметь следующие настройки:

{
...
  "server": {
    "host": "0.0.0.0",
    "port": 3000
  }
...
}

3. Настроить параметры подключения к серверу Бэкэнда. К этому адресу будут обращаться клиентские соединения из браузера при работе с аналитическим порталом. В общем случае обращение должно выполняться к устройству, на котором запущен аналитический портал. По умолчанию сервер обращается к локальному хосту 127.0.0.1 на порт 3000. Для работы с других устройств необходимо указать значения и параметры подключения к внутреннему или внешнему адресу сервера, с указанием протокола, по которому будет проходить соединение.

Например, предполагается вход на аналитический портал для пользователей с других устройств, находящихся в локальной сети. Аналитический портал развернут по адресу 192.168.0.3, сервер слушает порт 3000. Тогда блок «backend» будет иметь следующие настройки:

{
...
  "backend": {
    "protocol": "http",
    "host": "192.168.0.3",
    "port": 3000,
    "base_url": "/v1/api/"
  }
...
}

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

Запуск инициализации Базы данных

После настройки портала необходимо выполнить его первичную инициализацию. Для этого необходимо в командной строке в режиме администратор или в среде bash перейти в каталог портала и запустить исполняемый файл «modusbi.exe» (в Linux системах «modusbi») с параметром -init.

Например, Аналитический портал установлен в каталог «C:\Program Files\ModusBI». Тогда команда инициализации будет иметь вид:

cd "Program Files\ModusBI"
"modusbi.exe" -init

После выполнения команды начнется создание структуры метаданных в указанной в настройках информационной базе. Результатом выполнения команды должно стать информационное сообщение «созданы метаданные в ‘<БД PostgreSQL>’, необходимо перезапустить сервер». Детальная информация о процессе инициализации будет записана в файл журнала «modusbi.log».

Важно! Инициализация базы данных портала выполняется только один раз при первом запуске.

Получение временной лицензии. Если аналитический портал устанавливается на устройство впервые, автоматически будет получена временная лицензия на срок 30 дней, информация об этом будет отражена в информационном сообщении и в командной строке. Подробней о лицензировании см. здесь.

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

Проверьте работоспособность портала

Для проверки перейдите по адресу аналитического портала в своем браузере. На новом портале доступна учетная запись:

• имя: «admin»;
• пароль: «admin».

Поле первого входа, рекомендуется поменять стандартные параметры подключения.

Портал готов к работе.

3 - Обновление Modus BI

Обновление выполняется с помощью файлов «.mbu». В имени файла указывается:

• операционная система, для которой предназначено обновление (Linux / Windows);
• версия АП(X.Y.Z), с которой это обновление можно применить;
• версия АП(X.Y.Z), которая будет результатом обновления.

Например, файл обновления «modusbi-windows-3.0.0-3.1.9.mbu» предназначен для обновления Аналитического портала, развернутого на Windows, для любой версии Аналитического портала, начиная с 3.0.0 (подойдут порталы версии 3.0.0, 3.0.1, … ,3.0.9, 3.1.3 и т.д.). После успешного обновления версия АП будет установлена в 3.1.9.

Перед обновлением портала необходимо сделать копию базы метаданных средствами Postrge SQL.

Важно! До версии 3.0.0 обновление было не кумулятивным и требовалось строгое совпадение номеров версий обновляемого портала, и версии применяемого обновления. Например, обновление «modusbi-linux-2.4.0-2.4.4.mbu» можно установить только если версия портала 2.4.0. Применить такое обновление для портала версии 2.4.1 нельзя.

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

Поиск файлов обновления выполняется в каталоге «update» по месту установки портала. Путь до каталога задается в параметре update.path файла настроек «modusbi.json».

После обработки у файла обновления добавляется расширение в имени:

• «invalid» — если обновление не удалось применить;
• «apply» — если обновление успешно применено.

Файл обновления можно скопировать в эту папку через файловую систему. Либо через веб-интерфейс портала — «Настройки портала» / «Импортировать обновление»:

Если при старте портала было найдено подходящее обновление, то портал выполняет бэкап основных файлов портала:

• исполняемый файл портала;
• файл настроек;
• файл базы метаданных для базы формата SQLite.

Резервная копия сохраняется в папке заданной в настройках backup.path. По умолчанию папка «backup». Формат «.mbb» — по сути zip-архив с дополнительной метаинформацией в файле.

Процедура обновления портала состоит из следующих этапов.

1. Оповещение пользователей.

2. Остановка портала и создание бэкапа базы метаданных из СУБД PostgreSQL с помощью средств самой субд. Для SQLIte достаточно скопировать файл с метаданными. Остановка портала:

   • для Linux можно использовать команду systemctl stop modusbi;
   • для Windows службу можно остановить через оснастку службы;
   • если портал запущен не как служба, необходимо завершить процесс связанный с исполняемым файлом («modusbi»).

3. Копирование нужного файла обновления в папку для обновлений («update»).

4. Запуск портала. В процессе запуска портал попробует применить обновление. Процесс обновления логирует свои действия в основной лог, поэтому контролировать его можно по этому логу.

5. После применения обновления портал попробует выполнить перезапуск. Текущая реализация работы в режиме службы не всегда позволяет автоматический перезапуск портала, поэтому иногда может требоваться ручная остановка портала и запуск, уже новой версии портала.

Версию портала и его частей можно проверить в разделе Аналитического портала «Лицензия».

Важно! Остановка и запуск портала могут потребовать административных («root») прав. До обновления нужно проверить их наличие.

4 - Лицензирование портала

Для использования Аналитического портала необходимо, чтобы на портале была активирована действующая лицензия. Ознакомиться с параметрами лицензии можно пользователю с правами администратора в разделе «Настройки», «Лицензия»:

Лицензия регламентирует:

• срок её действия;
• количество пользователей;
• количество дашбордов;
• доступность функционала ограничения на уровне записей («РЛС»);
• доступность функционала Форм ввода данных;
• доступность функционала Отчетных форм;
• доступность опции «white label».

С версии 2.4.0 дистрибутив программного продукта «Модус: Аналитический портал» поставляется с 30-дневной лицензией для ознакомления. Аналитический портал в ознакомительной версии имеет ограничения:

• по сроку использования — 30 дней с момента первого запуска;
• количеству пользователей — 5;
• количеству дашбордов — 5.

Для работы с коммерческой версией портала необходимо активировать коммерческую лицензию. После покупки программного продукта пользователь получает PIN-код для активации лицензии. Лицензия портала привязывается к оборудованию сервера, на котором он установлен.

При использовании ОС Linux для запуска приложения «Аналитического портала», для работы алгоритмов проверки лицензии требуется наличие домашнего каталога у пользователя, от учетной записи которого выполняется запуск. В данном каталоге будет создан каталог “.hasplm”, для размещения ключей.

Параметры, с которыми связывается лицензия:

• MAC-адреса устройств;
• характеристики процессора;
• UUID виртуальной машины.

При изменении параметров сервера лицензия на аналитический портал перестает действовать. Для получения новой лицензии необходимо обратиться на линию технической поддержки 112@modusbi.ru.

Восстановление лицензии

В рамках действующей технической поддержки для пользователей доступно одно льготное восстановление лицензии за период обслуживания. Стоимость восстановления лицензии можно уточнить, обратившись к сопровождающему партнёру, или направив запрос по адресу post@modusbi.ru.

Активация лицензии аналитического портала

1. Войдите в Аналитический портал с правами администратора.
2. В разделе «Настройки» / «Лицензии» нажмите на кнопку «Создать файл запроса для создания нового ключа». Введите присланный ранее PIN-код и ИНН организации.
3. Сохраните файл запроса «license_request.mbc».
4. Направьте сформированный файл запроса по электронной почте на адрес технической поддержки 112@modusbi.ru. При запросе необходимо указать ИНН компании, для которой был приобретен Аналитический портал. В ответ будет направлен файл ответа.
5. После получения файла-ответа перейдите в раздел «Администрирование» / «Лицензии» и нажмите на кнопку «Установить ключ».
6. Выберите полученный файл-ответ формата «.mbv».
7. Перезагрузите Аналитический портал. Для этого на вкладке «Настройки портала» следует нажать кнопку «Перезагрузка»:

8. После перезагрузки будет доступен функционал портала в рамках, заданных лицензией. Параметры лицензии будут отображены в таблице «Лицензии», а активный ключ будет выделен желтым цветом в «Списке ключей»:

Обновление лицензии

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

Последовательность действий при окончании срока лицензии и изменении инфраструктуры:

1. Связаться с сопровождающим партнёром Modus BI.
2. В Modus BI будет создана и согласована заявка на выпуск нового ключа лицензии, после чего сопровождающий партнёр Modus BI предоставит новый PIN-код доступа.
3. На вкладке «Лицензия» Аналитического портала необходимо нажать кнопку «Создать файл запроса для создания нового ключа». В появившемся диалоговом окне следует указать новый PIN-код и ИНН организации, после чего скачать файл-запрос («license_request.mbc»).
4. Файл-запроса следует отправить сопровождающему партнёру Modus BI.
5. Сопровождающий партнёр Modus BI предоставит новый файл ключа лицензии, сгенерированный на основании полученного файла-запроса.
6. На вкладке «Лицензия» Аналитического портала следует нажать кнопку «Установить ключ» и предоставить для окна запроса новый ключ лицензии.
7. На вкладке «Настройки портала» следует нажать кнопку «Перезагрузка» для перезагрузки Аналитического портала.

Кроме сопровождающего партнёра Modus BI, взаимодействие по лицензии можно выстроить с помощью линии технической поддержки (если она предусмотрена договором).

В случае покупки дополнительного пакета, также необходимо обновить лицензию:

1. На вкладке «Лицензия» Аналитического портала следует нажать кнопку «Создать файл запроса для обновления ключа». Скачается файл запроса («license_request.mbc»).
2. Файл-запроса следует отправить сопровождающему партнёру Modus BI.
3. Менеджер Modus BI предоставит новый файл ключа лицензии, сгенерированный на основании полученного файла-запроса.
4. На вкладке «Лицензия» Аналитического портала следует нажать кнопку «Установить ключ» и предоставить для окна запроса новый ключ лицензии.
5. На вкладке «Настройки портала» следует нажать кнопку «Перезагрузка» для перезагрузки Аналитического портала.

5 - Кэширование аналитического портала

Для ускорения работы с отчетами аналитический портал может сохранять результаты запросов к данным, и на высокой скорости возвращать их при повторном запросе аналогичных данных пользователями. Это происходит благодаря хранению кэша Аналитического портала. Для его настройки необходимо открыть раздел «Настройки Кэширования» на панели «Администрирование».

Для использования функционала необходимо активировать переключатель «Использование КЭШ» и перезапустить портал.

Настройки КЭШ:

• «Время жизни КЭШ» — время которое данные после их получения будут считаться актуальными.
• Оптимальное время жизни КЭШ 10-30 минут.
• «Периодичность сброса» — время в минутах проверки и сброса устаревших данных.
• Оптимальная периодичность сброса КЭШ — 2 минуты.
• «Вариант настройки исключений» — позволяет настроить исключения наборов данных, к которым кэширование не будет применяться. Данные таких наборов будут каждый раз получаться из хранилища. При помощи кнопки «Выбор набора данных» можно настроить исключения.

Рекомендуем отключать кэширование наборов на этапе разработки и настройки аналитических панелей.

Статистика КЭШ

Функционал ведет статистику использования КЭШ:

1. «Текущее состояние»: «Используется» / «Отключен».
2. «Количество кэшированных наборов данных».
3. «Всего записей кэш» — итоговое количество записей кэша.
4. «Занимаемая память» — измеряется в байт.

Сброс КЭШ

Если необходимо очистить КЭШ память портала можно использовать команду «Очистить весь КЭШ». Очистить КЭШ набора данных можно в форме настройки набора данных, при помощи кнопки «Сбросить КЭШ».

6 - Права доступа и роли аналитического портала

Ролевая модель Программного продукта представляет собой двухуровневую структуру:

«1 уровень» — определяется ролью пользователя – роль определяет основные функциональные возможности этого пользователя;

«2 уровень» — предоставление доступа для пользователя к перечню разделов (пользователь сможет просматривать все отчеты этого раздела) и / или на определенные отчеты раздела (будет виден раздел, но доступны только часть отчетов раздела).

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

На портале созданы три роли:

• «Администратор» — имеет полные права, может создавать пользователей и предоставлять им права, подключать источники данных, настраивать наборы данных, настраивать расположение отчетов меню, а также настраивать отчеты в режиме конструктора;

• «Аналитик» — может добавлять и редактировать наборы данных, самостоятельно создавать и настраивать отчеты в режиме «Конструктор» и просматривать отчеты, настроенные другими аналитиками;

• «Пользователь» — может только просматривать предварительно настроенные отчеты, на которые у него есть доступ.

Создание нового пользователя и предоставление прав доступа

Для создания нового пользователя необходимо перейти в список пользователей в режиме «Администрирование» (см. рисунок «Настройка пользователей») и нажать кнопку «Добавить пользователя».

Заполните «фамилию», «имя», «отчество» пользователя, «логин» и «пароль». Также можно указать дополнительную информацию по пользователю: «организация», «подразделение», «должность», «e-mail», «телефон». Обязательные поля для заполнения: «логин», «пароль», «фамилия», «имя». Выберите роль пользователя из вариантов («Администратор», «Аналитик», «Пользователь»), по умолчанию устанавливается роль «Пользователь». В системе предусмотрена возможность настройки доступа через профили. «Общий профиль» создается, если предполагается использовать один и тот же набор прав у нескольких пользователей. «Личный профиль» — если настройки на права у пользователя индивидуальные. Если пользователю присвоены общие профили и настроен личный профиль — происходит «конкатенация» прав. Для создания общего профиля необходимо перейти в раздел «Профили доступа к отчетам» в режиме «Администрирование» и нажать кнопку «Добавить профиль»:

В появившемся окне формы ввода нового профиля (рисунок выше) заполните «наименование» и «описание». Здесь обязательное поле — «наименование». Нажмите кнопку «Настроить разрешения». Откроется окно для установки доступа к отчетам:

Для предоставления доступа ко всем отчетам раздела установите флаг около названия раздела (см. п.1 рисунка выше). Для предоставления доступа к конкретному отчету необходимо установить флаг около названия отчета (см. п.2 рисунка выше).

После установки прав нажмите кнопку «Сохранить» в окне настройки доступа к отчетам (см. п.3 рисунка выше), затем «Создать» в форме ввода профиля. Для настройки профилей необходимо зайти в карточку пользователя (первые два рисунка).

Для присваивания общего профиля нажать кнопку «Профили» (см. п.2 рисунка «Настройка пользователей»).

В появившемся окне назначения профилей доступа поставить флаг напротив профилей, которые необходимо присвоить пользователю, нажать «Сохранить» в окне назначения профилей доступа, нажать «Сохранить» в окне настройки пользователя:

Для присваивания личного профиля нажать кнопку «Личный профиль» (см. п.1 рисунка «Форма ввода нового пользователя»).

В появившемся окне настройки личного профиля для предоставления доступа ко всем отчетам раздела установите флаг около названия раздела. Для предоставления доступа к конкретному отчету необходимо установить флаг около названия отчета, нажать «Сохранить» в окне настройки личного профиля, нажать «Сохранить» в окне настройки пользователя:

Для просмотра прав у пользователя нажать кнопку «Отчет» (см. п.3 рисунка «Форма ввода нового пользователя»). В появившейся форме будет отображена информация о текущих правах доступа:

Управление пользователями и изменение настроек пользователя

Операции «управления пользователями» и «настройками» расположены в списке пользователей:

Для изменения настроек пользователя воспользуйтесь кнопкой в виде ручки в строке пользователя в списке. При нажатии кнопки откроется форма для изменения настроек. Внесите необходимые изменения и нажмите кнопку «Сохранить».

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

7 - Провайдеры аутентификации

1. Общее описание

Для обеспечения возможности входа пользователя на аналитический портал (АП) посредством разных методов идентификации и аутентификации, спроектированы и разработаны провайдеры аутентификации.

1.1. Провайдер аутентификации

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

Пока период действия маркера доступа не истёк, пользователь автоматически входит на АП.

На основе текущей реализации вариантов входа на АП созданы следующие провайдеры аутентификации :

1. «Password» — провайдер использующий имя пользователя для идентификации и пароль для аутентификации;

2. «LDAP for Active Directory» — провайдер передающий имя пользователя и пароль в службу каталогов «Active Directory» посредством протокола «LDAP»;

3. «SAML» — провайдер выполняющий создание подписанного «XML–документа» по стандарту «SAML», который используется для идентификации системы и передающий созданный документ внешней системе для выполнения аутентификации пользователя;

4. «OAuth2.0 Client Credentials» — провайдер аутентификации выполняющий авторизацию посредством стандарта авторизации «OAuth 2.0», с использованием типа предоставления учётных данных «ClientCredentials», который используется для конфиденциальных клиентов, которые запрашивают доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации;

5. «OAuth2.0 Authorization Code» — провайдер аутентификации выполняющий авторизацию посредством стандарта авторизации «OAuth 2.0», с использованием типа предоставления учётных данных «Authorizationcode», который в основном используется для «Web-сервисов», которые выполняют перенаправление запроса на сервер авторизации и обрабатывают ответ.

1.2. Конфигурация провайдера аутентификации

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

Таким образом получается, что администратор АП может управлять методом идентификации и аутентификации на АП посредством создания/изменения конфигураций провайдера аутентификации.

1.3. Параметры конфигурации провайдера аутентификации

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

Постоянные параметры конфигурации описаны ниже.

1. «Провайдер» аутентификации/авторизации — выбирается при добавлении конфигурации и не может быть изменён.

2. «Тип хеширования» — алгоритм который используется для обработки пароля пользователя, выбирается при добавлении конфигурации и не может быть изменён.

3. «Имя конфигурации» — уникальное внутреннее название для конфигурации.

4. «Отображаемое наименование» — уникальное название конфигурации, которое отображается пользователю.

5. «Администратор доступа» — пользователь, от имени которого выполняются автоматические операции после успешной обработки ответа от службы/сервиса идентификации/аутентификации.

6. «Иконка» — графическое изображение которое выводится на форме Входа/Выхода пользователя.

7. «Встроенный» — признак, который устанавливается разработчиками и не может быть изменён, характеризует конфигурацию провайдера аутентификации, встроенную в АП, которая используется всегда при отсутствии других конфигураций.

8. «По умолчанию» — признак, указывающий на конфигурацию, которая используется для идентификации/аутентификации пользователя, если пользователь не существует в списке пользователей АП или создан без указания конфигурации провайдера.

9. «Показывать форму» — признак указывает на необходимость отображения формы Входа.

Для каждого провайдера аутентификации набор динамических полей определяют разработчики на основе схемы.

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

1. «Password»:

   • необходимо ввести имя пользователя — требует ввода имени пользователя на форме Входа;

   • необходимо ввести пароль — требует ввода пароля на форме Входа;

2. «LDAP for Active Directory»:

   • необходимо ввести имя пользователя — требует ввода имени пользователя на форме Входа;

   • следует ввести пароль — требует ввода пароля на форме Входа;

   • адрес («host») — обязательное поле, содержит IP-адрес или DNS-имя сервера LDAP;

   • порт («port») — не обязательное поле, содержит порт, который прослушивается службой LDAP на «адрес».

   По умолчанию 0.

   Если равен 0, то используется стандартный порт «389» для не защищённого соединения или порт «636» для защищённого соединения (параметры указываются ниже);

   • база поиска («base_dn») — обязательное поле, содержит уникальное имя базы поиска («DN»), состоящее из одного или нескольких относительных уникальных имён («RDN»).

   Пример: «dc=example,dc=com»;

   • база поиска с пользователем («bind_dn») — не обязательное поле, содержащее уникальное имя базы поиска, содержащее клиента/пользователя.

   Пример: «cn=username,dc=example,dc=com»;

   • пароль пользователя ( «bind_pass») — не обязательный если не указан «база поиска с пользователем», содержит пароль клиента/пользователя, указанного в «база поиска с пользователем»;

   • не использовать шифрование TLS («skip_tls») — не обязательное поле, по умолчанию значение «Да», не использовать шифрование TLS при выполнении запросов;

   • использовать шифрование SSL («use_ssl») — не обязательное поле, по умолчанию значение «Нет», использовать шифрование SSL при выполнении запросов (параметры указываются ниже);

   • SSL-сертификат («ssl_cert») — не обязательное поле, путь и наименование файла, содержащего SSL-сертификат, используется если «использовать шифрование SSL» установлено в «Да»;

   • SSL-ключ («ssl_key») — не обязательное поле, путь и наименование файла, содержащего SSL-ключ, используется если «использовать шифрование SSL» установлено в «Да»;

   • название сервера из SSL-сертификата («server_name») — не обязательное поле, содержащее название сервера, указанное в SSL сертификате (Server Name Indication), используется если «использовать шифрование SSL» установлено в «Да»;

   • NetBIOS имя домена («server_netbios») — необязательное поле, содержит NetBIOS имя домена по умолчанию. Используется для формирования логина пользователя sAMAccountName стандарта. Если данная настройка указана, и не включена настройка «использовать в качестве имени пользователя UPN», то имя домена будет добавляться к логину пользователя автоматически, если логин не содержит имени домена. Например имя домена “HOUSE”, а логин введенный пользователем “v.ivanov”, то логин используемый для аутентификации будет “HOUSE\v.ivanov”, однако если пользователь введет логин вместе с именем домена “HOUSE\v.ivanov”, то ничего к логину прибавляться не будет;

   • пропускать проверку безопасность при использовании SSL («insecure_skip_verify») — не обязательное поле, по умолчанию установлено в «Да», пропускать проверку безопасность при использовании SSL;

   • использовать в качестве имени пользователя UPN («user_principal_name») — не обязательное поле. Указывает порталу, что в качестве логина пользователи будет использовать userPrincipalName (UPN) — имя участника-пользователя. Это новый формат указания имени пользователя для входа в систему, основанный на интернет-стандарте RFC 822. UPN образуется сочетанием имени пользователя с доменным суффиксом, например “ivanov_ii@home.local”. По умолчанию настройка установлена в значение «Да» - использовать UPN. Если настройка указана «Нет», то в качестве логина будет использоваться sAMAccountName свойство учетной записи пользователя.

   Пример: username@example.com.

3. «SAML»:

   • поставщик учётных записей: «Файла метаданных» — обязательное поле, содержит наименование и полный путь к файлу, содержащему метаданных поставщика идентификации/аутентификации.

   Пример: «metadata.xml»;

   • поставщик сервиса: «Адрес сервера портала» — обязательное поле, содержит адрес сервера портала.

   Пример: «https://dev.modusbi.ru/v1/api»;

   • поставщик сервиса: «Использовать самозаверенный сертификат» — не обязательное поле, если значение установлено в «Да», то автоматически создаётся сертификат и ключ для доменного имени используемого в адресе сервера портала;

   • поставщик сервиса: «Файла сертификата» — обязательное поле, если сервер портала использует протокол «HTTPS» и значение «Поставщик сервиса: Использовать самозаверенный сертификат» установлено в «Нет», содержит наименование и полный путь к файлу, содержащему сертификат, созданный для доменного имени, используемого в адресе АП.

   Пример: «domain.cert»;

   • поставщик сервиса: «Файла ключа для сертификата» — обязательное поле, если сервер портала использует протокол «HTTPS» и значение «Поставщик сервиса: Использовать самозаверенный сертификат» установлено в «Нет», содержит наименование и полный путь к файлу, содержащему ключ для сертификата созданный для доменного имени, используемого в адресе АП.

   Пример: «domain.key»;

   • поставщик сервиса: «Создавать пользователя» — не обязательное поле, если установлено в «Да», то после получения ответа от «Поставщик учётных записей» об успешной идентификации/аутентификации, создаётся новый пользователь в АП с данными полученными из ответа;

   • поставщик сервиса: «Устанавливать Профили» — не обязательное поле, если установлено в «Да», то после получения ответа от «Поставщик учётных записей» об успешной идентификации/аутентификации, пользователю устанавливаются «Профили» с использованием «Групп для конфигурации провайдера аутентификации»;

   • поставщик учётных записей: «способ передачи для Входа» (SingleSignOnService) – определяет значение атрибута «Binding» «XML-тэга» «SingleSignOnService», который необходимо использовать в файле настроек, указанного в пункте «1».

   Если значение настройки не указано, то используется первая запись «XML-тэга» «SingleSignOnService» из файла настроек, указанного в пункте «1». Допустимые поддерживаемые значения:

   • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST» — значение по умолчанию;

   • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect»;

   • поставщик учётных записей: «способ передачи для Выхода» (SingleLogoutService) – определяет значение атрибута «Binding» «XML-тэга» «SingleLogoutService», который необходимо использовать в файле настроек, указанного в пункте «1».

   Если значение настройки не указано, то используется первая завись «XML-тэга» «SingleLogoutService» из файла настроек, указанного в пункте «1».

   Допустимые поддерживаемые значения:

   • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST» - значение по умолчанию;

   • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect»;

   • поставщик сервиса: «Формат идентификатора пользователя» (NameIDFormat) – задаёт значение «XML-тэга» из которого необходимо получать формат представления идентификатора пользователя.

   В соответствии с документацией (http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, §4.2), поддерживаются следующие значения:

   - «urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified» — используется как значение по умолчанию;
   - «urn:oasis:names:tc:SAML:2.0:nameid-format:persistent»;
   - «urn:oasis:names:tc:SAML:2.0:nameid-format:transient»;
   - «urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress»;
   - «urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName»;
   

   • поставщик сервиса: «Подписать запрос аутентификации» — определяет необходимость использования шифрования отправляемых данных;

   • пставщик сервиса: «Проверять действительность сертификата шифрования» — перед тем как подписывается запрос аутентификации выполняется проверка срока годности сертификата, используемого для шифрования;

   • поставщик сервиса: «Не проверять подпись» — при обработке ответа от поставщика учётных записей не выполняется проверка подписи перед расшифровкой;

   • поставщик сервиса: «Разрешить отсутствие атрибутов» — если в результате обработки ответа от поставщика учётных записей не будут найдены некоторые атрибуты в «XML-тэгах», то не возвращать ошибку обработки;

   • поставщик сервиса: «Проверять данные подтверждения субъекта» — при обработки ответа от поставщика учётных записей проверяются атрибуты «XML-тэга» «urn:oasis:names:tc:SAML:2.0:assertion Subject».

4. «OAuth2.0 Client Credentials»:

   • «Необходимо ввести имя пользователя» — требует ввода имени пользователя на форме Входа;

   • «Необходимо ввести пароль» — требует ввода пароля на форме Входа;

   • «Идентификатор приложения» — строковое значение, полученное при регистрации на сервере авторизации («client id»);

   • «Код приложения» — строковое значение, полученное при регистрации на сервере авторизации («client secret»);

   • «Адрес сервера авторизации» — интернет адрес сервера авторизации;

   • «Адрес получения маркера доступа» — интернет адрес куда необходимо отправлять запросы на получение маркера доступа;

   • «Адрес получения данных пользователя» — интернет адрес куда необходимо отправлять запросы с полученным маркером доступа, чтобы получить данные пользователя;

   • «Получать области пользователя» (разделённые пробелом) — строка, содержащая значения, описывающие данные пользователя на стороне сервера авторизации и использующиеся при создании и обновлении пользователя после успешной аутентификации в АП, по умолчанию равно «openid name email groups roles»;

   • «Области для установки профилей» (разделённые пробелом) — строка, содержащая значения, описывающие данные пользователя на стороне сервера авторизации и использующиеся для установки профилей после успешной аутентификации в АП, посредством «Групп конфигурации провайдера аутентификации», по умолчанию равно «groups roles»;

   • «Создавать пользователя» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, создаётся новый пользователь в АП с данными полученными из ответа;

   • «Устанавливать Профили» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, пользователю устанавливаются «Профили» с использованием «Групп для конфигурации провайдера аутентификации».

5. «OAuth2.0 Authorization Code»:

   • «Необходимо ввести имя пользователя» — требует ввода имени пользователя на форме Входа;

   • «Необходимо ввести пароль» — требует ввода пароля на форме Входа;

   • «Идентификатор приложения» — строковое значение, полученное при регистрации на сервере авторизации («client id»);

   • «Код приложения» — строковое значение, полученное при регистрации на сервере авторизации («client secret»);

   • «Адрес сервера портала» (https://demo.modusbi.ru/v1/api) – интернет адрес публикации API Аналитического портала. На этот адрес будет выполнено перенаправление с сервера авторизации. Обычно интернет адрес публикации API состоит из интернет адреса Аналитического портала «https://demo.modusbi.ru» и относительного пути к точке публикации API «/v1/api».

   • «Адрес сервера авторизации» — интернет адрес сервера авторизации;

   • «Адрес получения маркера доступа» — интернет адрес куда необходимо отправлять запросы на получение маркера доступа;

   • «Адрес получения данных пользователя» — интернет адрес куда необходимо отправлять запросы для получения данных о пользователе (атрибутов учетной записи);

   • «Имя атрибута из которого получать ’login’ пользователя» - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве логина пользователя. Если не заполнено, используется атрибут “email”;

   • «Имя атрибута из которого получать ‘Имя’ пользователя» - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве имени пользователя. Если не заполнено, используется атрибут “given_name”;

   • «Имя атрибута из которого получать ‘Фамилию’ пользователя» - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве фамилии пользователя. Если не заполнено, используется атрибут “family_name”;

   • «Имя атрибута из которого получать ‘Отчество’ пользователя» - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве отчества пользователя. Если не заполнено, используется атрибут “middle_name”;

   • «Имя атрибута из которого получать ‘E-mail’ пользователя» - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве адреса электронной почты пользователя. Если не заполнено, используется атрибут “email”;

   • «Получать области пользователя» — строка, в которой перечислены имена областей (scope) к которым нужно запрашивать доступ для получения информации о пользователе (атрибутов учетной записи). Имена областей следует отделять пробелами. Значение по умолчанию «openid name email groups roles»;

   • «Атрибуты для установки профилей» — строка, в которой перечислены имена атрибутов учетной записи пользователя (получаемых от сервера аутентификации) содержащих информацию о членстве пользователя в группах. Имена атрибутов следует отделять пробелами. По умолчанию используются атрибуты «groups» и «roles». Значения атрибутов, перечисленных в этой настройке, должны быть массивами из строк - имен групп. Имена групп, получаемые из перечисленных атрибутов, должны совпадать с именами групп указанным в «Настройка групп» конфигурации провайдера аутентификации.

   Примечание: 
   В Keycloak для получения нужного типа данных значения атрибутов, при создании атрибута необходимо выбрать следующие параметры:  
   - "Claim JSON Type": String  
   - "Aggregate attribute": On  
   

   • «Создавать пользователя» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, создаётся новый пользователь в АП с данными полученными из ответа;

   • «Устанавливать Профили» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, пользователю устанавливаются «Профили» с использованием «Групп для конфигурации провайдера аутентификации» и значений из свойств перечисленных в настройке «Свойства для установки профилей».

1.4. Создание/изменение пользователя

Так как в результате идентификации и аутентификации пользователя может возникнуть необходимость создания/изменения учётных данных для пользователя в АП, а также назначение доступа пользователя к разным частям АП посредством назначения «Профилей», то для каждой конфигурации провайдера аутентификации возможно:

1. указание необходимости создании пользователя после успешной идентификации и аутентификации;

2. назначение пользователю «Профилей» (любых типов) на основании полученного «Списка доступа» в результате идентификации и аутентификации в провайдере аутентификации.

1.5. Группы для конфигурации провайдера аутентификации

Для корректного назначения «Профилей» пользователю необходимо, что бы с каждым возможным элементом «Списка доступа» были установлены связи с одним или несколькими существующими «Профилями».

Таким образом для каждой конфигурации провайдера аутентификации можно создать свой уникальный «Список доступа», который называется «Группы конфигурации».

Каждый элемент «Группы конфигурации» может быть связан с одним или несколькими существующими «Профилями».

1.6. Установка «Профилей» пользователю

Для обеспечения корректного текущего доступа пользователя к частям АП, установка «Профилей» на основании связи с «Группами конфигурации» выполняется каждый раз после успешной идентификации и аутентификации пользователя в провайдере аутентификации, посредством удаления установленных «Профилей» кроме профиля с типом «Личный» и назначения новых «Профилей» на основании «Группами конфигурации».

2. Инструкции и пример настройки

2.1. Добавление конфигурации провайдеров доступа

1. Зайти на портал с правами администратора. Перейти в меню «Администрирование» (см. рисунок ниже, 1), «Настройки провайдеров» (2) и нажать «Добавить конфигурацию» (3):

2. Заполнить поля «Имя» (см. рисунок ниже, 1), «Отображаемое наименование» (2), «Выбрать провайдера авторизации» (3), тип хэширования (4) и нажать «Создать»:

3. Перейти в редактирование конфигурации по кнопке «Настройки» (см. самый первый рисунок, 1).

4. При необходимости — изменить «Имя» (см. рисунок ниже, 1) и «Отображаемое наименование» (2), установить опции и (3), выбрать иконку (4), выбрать администратора доступа (5); заполнить поля (6) — поля меняются в зависимости от выбранного провайдера авторизации:

2.2. Пример настройки для Active Directory

1. Добавляем конфигурацию с параметрами:

2. Заполняем настройки конфигурации — поля «Адрес», «База поиска» и выбираем иконку для конфигурации:

3. Создаем пользователя. Имя пользователя (UPN) по умолчанию в интернет-стиле, также указываем конфигурацию:

4. Проверяем доступ на портал указывая логин, пароль и нажимая на иконку созданной конфигурации:

8 - Профиль наборов данных

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

Для настройки профилей наборов данных необходимо перейти в «Настройки» / «Профили наборов данных». Для добавления нового профиля необходимо нажать на «Добавить профиль».

В открытой форме присутствуют следующие поля:

• «Наименование»;
• «Описание»;
• «Тип профиля».

Для создания доступны следующие типы наборов данных:

1. «Все наборы данных» — предназначен для администраторов, которым нужен доступ ко всем наборам данных;
2. «Только свои наборы данных» — предназначен для аналитиков, которые создают свои отчеты. Имеют доступ только к своим данные, которые загрузили;
3. «Выбранные наборы данных» — предназначен для аналитиков, которые хотят получить доступ к определенным наборам данных.

При нажатии на кнопку «Настроить разрешения» будет открыто окно выбора наборов данных для типа профиля «Выбранные наборы данных».

Также наборы данных можно сочетать между собой:

• «Все наборы данных» + «Только свои наборы данны» = «Все наборы данных»;
• «Только свои наборы данных» + «Выбранные наборы данных» = свои созданные наборы данных и выбранные наборы данных, созданные другими пользователями.

Для применения к определенному пользователю наборов данных, необходимо перейти в карточку пользователя, перейти в раздел «Профили» и во вкладку «Профиль наборов данных». В открытой форме выбрать нужные наборы данных.

Примененные профили будут отображаться в карточке профиля.

9 - Настройка прав доступа на уровне записей (RLS)

Разграничение прав доступа на уровне записей (Record Level Security — сокр. RLS) — это настройка прав пользователей, которая позволяет разделить права в разрезе динамически меняющихся данных. Основное преимущество этого разграничения, что пользователи, просматривая одни и те же отчеты, не увидят недоступные им данные и могут даже не догадываться об их существовании.

Чаще всего RLS используют для ограничения видимости в разрезе организаций или клиентов (пользователь видит лишь «свои» данные), но применение может быть любым — территориальным, категориальным и т.п.

Механизм RLS реализован через настраиваемое автоматическое дополнение запроса к источнику данных специальным фильтром, связанным с ограничением части набора данных или ограничением на весь набор для конкретного пользователя. Таким образом, пользователь не увидит в отчете данные, на которые ему не был предоставлен доступ.

Для возможности использования одних и тех же настроек RLS для разных наборов данных была реализована следующая архитектура: RLS это надстройка над целевым набором данных, правила настраиваются с помощью профиля и объектов RLS. Связь с пользователем объектов RLS может быть напрямую или через специальные роли. Один профиль и его объекты могут применяться к разным целевым наборам:

Для настройки нужно выполнить следующие шаги:

• сформулировать принципы разграничения доступа;
• подготовить справочные данные;
• включить механизм;
• настроить роли RLS;
• настроить профили RLS;
• объединить профили и роли в объекты RLS;
• установить ограничения в целевом наборе данных;
• присвоить пользователям соответствующие роли RLS;
• включить использование RLS.

Принципы разграничения прав и подготовка справочных наборов данных

Для использования RLS необходимо подготовить справочники значений (наборы данных для профиля RLS), содержащие записи, по которым будет осуществляться предоставление или ограничение доступа к данным основного набора.

Набор данных для профиля RLS может содержать «Поле RLS» (идентификатор), «Представление поля RLS» (значение), «Поле родителя RLS» (идентификатор атрибута), «Представление поля родителя RLS» (значение атрибута).

Предоставление или ограничение доступа может осуществляться как по «Полю RLS», так и по «Родителю поля RLS» (группе полей с одинаковым атрибутом). Значения в полях представления служат для удобства восприятия информации и будут отображаться в настройках вместо значений идентификаторов.

Примеры использования RLS и соответствие данных справочного набора:

Установка механизма RLS для источника

Поскольку механизм RLS является надстройкой над основным функционалом, возможность его использования необходимо установить в нужном источнике данных. Установка механизма RLS производится под ролью «Администратор». Дальнейшая настройка и управление возможны под ролью «Аналитик».

Для включения RLS нужно перейти в раздел «Источники» в режиме «Администрирование», выбрать источник данных, для которого необходимо включить RLS. В разделе «Дополнительные опции» нажать «Установить» напротив поля «Поддержка RLS»:

При успешной установке появится информационное сообщение:

После установки RLS для выбранного источника, в режиме «Администрирование» в меню станут доступны следующие разделы: «Настройки RLS», «Роли RLS». В параметрах наборов данных раздела «Наборы данных» появится пункт «Настройки RLS»:

Важно! При отмене установки RLS все настройки («Роли», «Профили», «Объекты») удаляются. Для восстановления настроек придеться проделать всю работу заново. Если необходимо сохранить настройки, но не использовать RLS в работе, пользуйтесь возможностью включения/выключения RLS.

Настройка ролей RLS

Роли RLS — один из типов ролей, используемых на портале. Этот тип ролей нужен для привязки пользователей к объектам RLS. Если пользователю присвоили роль, то он имеет права, указанные в объекте RLS, привязанного к этой роли. При включенном RLS для набора данных, пользователь, у которого нет соответствующей роли RLS, не увидит данные из набора.

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

В открывшемся окне указать наименование роли, пользователей, которым присваивается эта роль RLS и нажать «Создать»:

Добавленные роли RLS можно изменять или удалять с помощью кнопок «Редактировать» и «Удалить». В этом же интерфейсе можно присваивать роль новым пользователям или убрать ее использование у пользователя.

Настройка Профилей RLS

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

Для создания профиля необходимо перейти в режиме «Администрирование» в раздел «Настройки RLS», выбрать источник данных и нажать кнопку «Новый профиль»:

В открывшемся окне указать наименование профиля, выбрать набор справочных данных, из выбранного набора справочных данных выбрать поле RLS — идентификатор и поле представления — значение, опционально поле родителя RLS и поле представление родителя, и нажать «Создать».

Добавленные Профили RLS можно изменять или удалять с помощью кнопок «Редактировать» и «Удалить».

Настройка Объектов RLS

Объект RLS — это описание варианта ограничения для выбранного профиля и привязка к этому ограничению ролей RLS и/или пользователей. Для каждого профиля может быть создано неограниченное количество объектов (вариантов ограничений). Рекомендуется создать один из вариантов, разрешающих доступ ко всем объектам профиля.

Настройка объекта RLS вызывается из того же интерфейса, где настраиваются профили.

Для этого надо перейти в раздел «Настройки RLS», выбирать источник данных, выбирать профиль RLS (нажать на него мышью) и нажать кнопку «Новый объект»:

В открывшемся окне Профиль RLS заполнится автоматически, указать наименование объекта, выбрать Роль RLS (по кнопке «Роли RLS Выбрать») и/или Пользователей (по кнопке «Пользователи Выбрать»), выбирать Тип условия. При выборе Типа условия «включение»/«исключение» необходимо будет выбрать Тип поиска («по элементу» / «по родителю») и указать значения (по кнопке «Значения Выбрать», откроется список элементов или список родителей в зависимости от выбранного типа поиска). После заполнения нажать «Создать»:

Добавленные Объекты RLS можно изменять или удалять с помощью кнопок «Редактировать» и «Удалить».

Возможны следующие типы условий:

• «Включение» — требует указания значений, которые будут доступны;
• «Включение всех» — не требует указания значений, все значения будут доступны;
• «Исключение» — требует указания значений, которые будут недоступны;
• «Исключение всех» — не требует указания значений, все значения будут недоступны.

Включение и настройка RLS для нужного набора данных.

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

Для включения использования RLS на определенном наборе данных необходимо перейти в раздел «Наборы данных», выбрать нужный набор и открыть «Настройки RLS»:

Указать с каким профилем и по какому полю связать набор данных и нажать «Применить RLS» — в результате сформируется SQL-запрос RLS. Далее, необходимо включить RLS с помощью переключателя и нажать «Сохранить», чтобы изменения вступили в силу:

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

Включение RLS для источника.

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

Когда все настройки для работы механизма RLS завершены, можно начать его использовать. Для этого надо включить механизм RLS для источника. Эта операция доступна для Администратора системы.

Включить/отключить механизм RLS (без потери произведенных настроек) можно в режиме «Администрирование» в разделе «Настройки RLS» или в разделе «Источники»:

После включения RLS для всех Пользователей, кому присвоены Роли с RLS или указаны в настройках напрямую, будут действовать настроенные правила в Объектах RLS. Для всех остальных доступ к данным будет закрыт.

Особенности применения ограничений:

1. Cозданные настройки RLS суммируются.

• Если создано 2 RLS-объекта с включением и исключением одного и того же элемента, то в итоге будет применено исключение;

• Если пользователю предоставлены права «включение всех» элементов и дополнительно «включение» конкретного элемента, то права «включение всех» будут перекрыты логикой «включение».

1. Настройки RLS применяются при сохранении. Поэтому если для пользователя (или группы пользователей) необходимо реализовать ограничение доступа, например, ко всем организациям «Восточного округа» кроме «Управа района Богородское города Москвы» и «Управа района Вешняки города Москвы», то потенциально может возникнуть ситуация, когда пользователю будут доступны данные еще непримененного ограничения. Т.е. исключение одной из управ применяется, а другая ещё не исключена.

Варианты корректной настройки такого рода ограничений:

• создать объект RLS с исключением целевых элементов (т.е. исключения двух управ настроены в одном объекте);
• если же ограничение необходимо применить несколькими простыми объектами, то сначала необходимо добавить пользователя в роль «исключение всех», с этого момента ему не будут доступны все организации, настроить конкретные исключения, а после удалить пользователя из роли «исключение всех».

Важно! Ограничения RLS действуют также и на пользователей с правами администратора. Если у администратора нет прав на просмотр данных, он их не увидит.

10 - Настройка RLS запросами с пользовательскими переменными

Пользовательские переменные представляют атрибуты пользователя Аналитического портала. Они подразделяются на встроенные (системные, определяемые структурой метаданных Аналитического портала) и дополнительные (на усмотрение администратора портала в зависимости от решаемых задач).

Настройка пользовательских переменных осуществляется администратором в блоке меню «Переменные» и в окне «Редактирование пользователя» (блок меню «Пользователи»).

см. Список встроенных пользовательских переменных

Настройка RLS с использованием пользовательских переменных

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

Предварительная подготовка данных

Для использования разделения доступа с использованием переменных, набор данных должен содержать ключевое поле, по которому осуществляется фильтрация RSL (например, table.rslkey).

Пример 1:

В источнике данных должна быть создана таблица соответствия атрибута пользователя, по которому предполагается вводить ограничения, и значений rslkey, к которым данному пользователю разрешен (запрещен) доступ. Например, таблица «rlstable», содержащая поля rlstable.userid и rlstable.rslkey.

Пример 2:

Такую таблицу можно создавать и редактировать при помощи ФВД.

Подготовка запроса для набора данных

К базовому запросу для получения данных из таблицы «table» необходимо добавить условие WHERE, фильтрующее строки, отвечающие условию выборки из таблицы «rlstable» по значению пользовательской переменной.

Базовый запрос (пример):

SELECT table.data, table.anotherdata FROM table

Модифицированный запрос (пример):

SELECT table.data, table.anotherdata FROM table 
WHERE table.rslkey IN (SELECT rlstable.rslkey from rlstable WHERE rlstable.userid = $user.ID$)

Для каждого пользователя, авторизованного на Аналитическом портале и просматривающего отчет, значение $user.ID$ будет равно идентификатору этого конкретного пользователя, таким образом он увидит только те строки, которые ему предназначены. В нашем примере пользователю «id 101» будут показаны только строки с rlskey = 'Иванов' (№ 1 и 2 в таблице «table»), пользователю «id 102» — данные по Петрову, а «id 100» увидит все строки таблицы «table».

Используя диалект SQL источника данных, можно проектировать более сложные запросы для набора данных, накладывая как включающие (разрешающие), так и исключающие (запрещающие) фильтры, в том числе по нескольким пользовательским переменным (встроенным и дополнительным)

11 - Настройка пользовательских переменных

Пользовательские переменные представляют атрибуты пользователя Аналитического портала. Они подразделяются на встроенные (системные, определямые структурой метаданных Аналитического портала) и дополнительные (на усмотрение администратора Портала в зависимости от решаемых задач).

Список встроенных пользовательских переменных

Создание дополнительных переменных

Для создания дополнительных переменных необходимо перейти в раздел «Переменные» бокового меню настроек. Для этого требуются права администратора портала.

1. Нажмите кнопку «Добавить переменную» в верхнем правом углу экрана.
2. В окне создания переменной введите имя переменной (краткое), её описание и тип (Строка, Число или Дата). Имя должно быть уникальным (недопустимо дублирование имен как встроенных, так и других дополнительных переменных).
3. Нажмите кнопку «Создать».
4. После того, как переменная появится в списке, станут доступны операции редактирования (кнопка «карандаш» в правой части списка) и удаления (кнопка «корзина»).

Присвоение значений пользовательским переменным вручную

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

1. Перейдите в раздел бокового меню настроек «Пользователи».
2. Выберите пользователя, для которого необходимо отредактировать значения, и нажмите кнопку «карандаш» в правой части списка.
3. В окне редактирования пользователя измените значения ФИО, Организации, Логина и др., значения системных (встроенных) переменных будут изменены соответственно.
4. Для редактирования дополнительных переменных нажмите кнопку Переменные в окне редактирования пользователя.
5. Перейдите на вкладку «Пользовательские». В ней отображается список переменных, ранее созданных Администратором портала.
6. Выберите переменную для редактирования, нажмите на содержащую её строку. Раскроется меню редактирования переменной.
7. Нажмите кнопку «Добавить значение».
8. В появившейся строке введите значение, При несоблюдении формата (типа переменной) будет выведено предупреждение, сохранить изменения будет невозможно, потребуется внести исправления.
9. Существующие значения переменной можно удалять, нажав на кнопку “корзина”, либо изменять.
10. После добавления новых или редактирования существующих значений переменных нажмите кнопку «Сохранить».

Получение значений пользовательских переменных от провайдера авторизации

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

1. В окне редактирования провайдера включите опцию «Загружать автоматически значения серверных переменных по данным провайдера».
2. Нажмите кнопку «Серверные переменные».
3. В списке переменных укажите внешние имена (алиасы) тех переменных, которые должен передавать провайдер. При наличии соответствующего параметра авторизации значение переменной будет обновляться для пользователя при каждой авторизации.
4. Нажмите кнопку сохранить.

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

12 - Размещение через iframe портала Modus на стороннем ресурсе

1. Размещение через iframe портала Modus на стороннем ресурсе.

Для размещения дашбордов BI портала Модус на стороннем веб ресурсе, предварительно необходимо «разрешить» на стороне настроек окружения серверного оборудования публикацию домена через iframe. Непосредственно на стороне платформы Модус каких-то дополнительных настроек не требуется.

Для публикации Модуса на стороннем веб портале, необходимо вставить код iframe на странице стороннего ресурса следующего вида:

<iframe src="(URL_дашборда)" frameborder="0" scrolling="yes" height="1000" width="100%">
</iframe>

где:

• frameborder — ширина рамки iframe;
• scrolling — включена отключена прокрутка iframe;
• height — высота iframe (в нашем случае высота на 100% экрана, так как мы отображаем весь сайт);
• width — ширина iframe (в нашем случае ширина на 100% экрана для отображения по всей ширине экрана.

2. Публикация дашборда без авторизации

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

• создать пользователя и назначить права на выбранные дашборды;
• перейти в настройки портала;
• выбрать пользователя для автоматической аутентификации;
• сохранить настройки и перезагрузить портал.

Для вызова дашборда без авторизации (при условии, что данный дашборд доступен выбранному пользователю «по умолчанию») необходимо добавить к URL дашборда следующую запись: «?login=default»

Пример:
https://covid.modusbi.ru/report/553?login=default.

3. Размещение дашборда через iframe без авторизации

По результату настройки пользователя без авторизации по умолчанию, достаточно к коду iframe добавить в URL запись «?login=default»

Пример кода iframe без авторизации для встраивания в сторонний ресурс:

<iframe src="https://covid.modusbi.ru/report/553?login=default" frameborder="0" scrolling="yes" height="1000" width="100%">
</iframe>

Работу iframe можно проверить на стороннем ресурсе:
https://codepen.io/SnapToPixels/pen/BjgvRM.

4. Настройка сквозной авторизации на BI Портале Modus.

Инструкция по настройке провайдера аутентификации размещено в инструкции в разделе Провайдеры аутентификации.

5. Настройка сквозной авторизации в Modus ETL

Настройка осуществляется типовыми средствами платформы 1С:Предприятие, подробнее по ссылке:
https://v8.1c.ru/platforma/openid-autentifikatsiya/;
https://v8.1c.ru/platforma/mehanizmy-autentifikacii/.

13 - Использование безопасного режима для отладки отчётов

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

Последовательность действий следующая.

1. При необходимости, можно проводить восстановление на копии отчета. В этом случае, сначала сделайте копию.
2. Скопируйте ссылку на отчет в адресной строке браузера.
3. Добавить к адресу текст ?safemode и выполнить переход по адресу.

Например, если в адресной строке браузера отчёта указано «https://free.modusbi.ru/report/847», то после добавления нужного текста, адрес должен принять вид «https://free.modusbi.ru/report/847?safemode»:

4. Откроется окно «Меню безопасного режима»:

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

5. Повторите переход в безопасный режим. В списке «Удалить» необходимо выбрать элемент, который вызывает ошибку и нажать кнопку «Удалить» — элемент будет удален из дашборда.

Например, после включения в список «Показать» элемента с номером «3» отчёт не отобразился корректно. Выставляем в списке «Удалить» номер «3», и под списком «Удалить» появится кнопка «Удалить 3»:

Кнопка «Удалить 3» позволит удалить элемент, ведущий к ошибке.

Аналогичным способом можно удалить и другие элементы визуализации по их номерам, а потом следует нажать кнопку «Закрыть» в диалоговом окне.

6. После закрытия окна «Меню безопасного режима», отчёт отобразиться в режиме со всеми визуализациями, кроме удалённых на предыдущем шаге. Удаление в безопасном режиме в действительности не изменяет дашборд, однако теперь можно отредактировать отчёт без проблемных элементов (кнопка с изображением шестерёнки в врехнем правом углу экрана — вход в режим конструктора).

7. Исправьте отчет в режиме конструктора сохраните его.