Руководство по установке и администрированию ПО Мэйлбокс (стр. 1 )

Система ЭДО РТС

Руководство по установке
и администрированию
ПО Мэйлбокс

Реквизиты документа

Автор:

Версия: 1.10

Дата: 7/10/13

Организация/Подразделение: НП «Фондовая биржа РТС»

Pоссия, Москва

Ул. Долгоруковская, 38, корп. 1

Содержание

1. Используемые термины и сокращения 4

2. Лист изменений 4

3. Описание программного продукта 5

3.1. Назначение 5

3.2. Принципы функционирования 5

3.3. Описание таблиц базы данных Мэйлбокса 6

3.4. Схема гарантированной доставки сообщений 8

3.4.1. Схема доставки между Клиентом CoreMail и Мэйлбоксом 8

3.4.2. Схема доставки между двумя Мэйлбоксами 8

3.4.3. Особенности взаимодействия Клиента RTSMail с Мэйлбоксом 10

3.5. Шифрование сообщений 10

3.6. Общие требования 11

3.6.1. Требования к аппаратному обеспечению 11

3.6.2. Программное окружение 11

3.6.3. Другие материалы 11

3.7. Авторские права 11

3.8. Безопасность и конфиденциальность 11

3.9. Поддержка и информирование о проблемах 11

4. Работа с ПО "Мэйлбокс" 12

4.1. Настройки ini-файлов 12

4.1.1. Общие настройки rtsmail. ini 12

4.1.2. Настройки rtsmail. ini для базы данных на C-Tree 14

4.1.3. Настройки rtsmail. ini для ODBC 14

4.1.4. Настройки rtsqcomm. ini 15

4.2. Установка ПО "Мэйлбокс" 15

4.2.1. Данные, которыми необходимо располагать перед запуском: 15

4.2.2. Процедура установки 15

4.3. Запуск СКЗИ 16

4.4. Запуск ПО "Мэйлбокс" 16

4.5. Завершение работы ПО "Мэйлбокс" 16

4.6. Удаление ПО "Мэйлбокс" 16

4.7. Администрирование пользователей 16

4.7.1. Просмотр списка пользователей Мэйлбокса 16

4.7.2. Включение нового пользователя в список пользователей Мэйлбокса 17

4.7.3. Удаление пользователя из списка пользователей Мэйлбокса 17

4.8. База данных Мэйлбокса 17

5. Резервное копирование данных 17

6. Восстановление при ошибках, сбоях и нештатных ситуациях 18

7. Дополнительная информация 18

8. ПРИЛОЖЕНИЕ А "Работа с сертификатами" 19

8.1. Процедура создания базы сертификатов 19

8.1.1. Настроить конфигурационный файл 19

8.1.2. Создать "пустую" базу данных 20

8.1.3. Добавить сертификаты в базу данных 20

8.1.4. Подписать базу данных 20

8.1.5. Проверить правильность выполнения процедуры 20

8.2. Процедура замены базы сертификатов 20

8.3. Программа для администрирования сертификатов компании-абонента ЭДО 21

9. ПРИЛОЖЕНИЕ Б "Работа с БД сообщений" 22

10. ПРИЛОЖЕНИЕ В "Основные сообщения log-файлов" 24

11. ПРИЛОЖЕНИЕ Г "Замечания и предложения" 27

2.  Используемые термины и сокращения

БД	База данных.
Мэйлбокс	Сервер сообщений абонента ЭДО РТС.
Основная база сертификатов	БД, содержащая "базовые" сертификаты открытых ключей (ЦС, ХС и самого абонента ЭДО).
ПК	Персональный компьютер.
ПО	Программное обеспечение.
Приложение	Прикладная программа или система, использующая ЭДО РТС в качестве траспортной среды для обмена сообщениями с другими программами или системами.
РТС	Российская Торговая Система.
Сертификат	Электронный документ, подписанный ЭЦП Технического центра РТС и содержащий открытый ключ абонента ЭДО, а также информацию об электронном адресе этого абонента, сроке действия и других параметрах открытого ключа.
СКЗИ	Система криптографической защиты "Верба-О".
Файловый шлюз	Файловый шлюз предназначен для передачи (приема) файлов от отправителя получателю посредством транспорта ЭДО.
ХС	Хранилище сертификатов ЭДО.
ЦС	Центр сертификации – АРМ для изготовления сертификатов открытых ключей пользователей ЭДО РТС.
ЭДО	Система электронного документооборота РТС.
RTSGAdmin	Программа для администрирования сертификатов компании-абонента ЭДО.
Анкорный уровень	Уровень, указывающий последнюю важную для данного узла подпись.

3.  Лист изменений

Дата внесения изменений	Описание внесенных изменений
01.02.2002 г.	Добавлены гл. 3.3, 3.4, 3.4.1, 3.4.2, 3.4.3, 3.5, 3.6, 4.1, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 8.2, 8.3, 10. Изменена гл. 3.2.

4.  Описание программного продукта

4.1.  Назначение

Программное обеспечение "Мэйлбокс" (далее "Мэйлбокс") ‑ сервер сообщений абонента системы электронного документооборота РТС (ЭДО), обеспечивающий доступ к ней клиентским приложениям участников ЭДО.

4.2.  Принципы функционирования

Программное обеспечение Мэйлбокс устанавливается на рабочей станции или сервере участника системы электронного документооборота и обеспечивает передачу и прием сообщений. Схема функционирования Мэйлбокса, установленного в компании-участнике системы ЭДО представлена на Рис. 1

Рис. 1 Схема функционирования Мэйлбокса

Для всех прикладных программ устанавливается один Мэйлбокс на компьютере (Рабочая станция 1), подключенном к локальной сети компании, имеющей выход в сеть РТС или Internet.

Мэйлбокс регистрируется на сервере доступа Торговой системы РТС (Мэйлбоксы имеют только право логина, а никаких торговых прав не имеют). Прикладные программы подключаются к Мэйлбоксу в качестве локальных сервисов (пользователей).

Программа-пользователь Мэйлбокса может быть установлена на той же рабочей станции (Пользоваили на другой (ПользоваМэйлбокс получает сообщение программы-пользователя, подписанное электронно-цифровой подписью (ЭЦП), проверяет ЭЦП, шифрует, подписывает и передает его Мэйлбоксу получателя через сервер системы ЭДО (Центр ЭДО). Сервер системы ЭДО, установленный в Техническом центре РТС, производит проверку действительности сертификатов ЭЦП, использованных при формировании сообщений. Если сертификат заблокирован, скомпрометирован или истек срок его действия, то сообщение не передается Мэйлбоксу получателя, а Мэйлбоксу отправителя формируется соответствующее уведомление.

До получения подтверждения о доставке сообщение хранится в базе данных Мэйлбокса. Мэйлбокс-отправитель проверяет получено ли подтверждение на отправленное сообщение, если нет, то через время resend_interval (см. описание секции [mailbox] п.4.1.1.), производится перепосыл сообщения (активный режим работы). Если Мэйлбокс-получатель недоступен, то Мэйлбокс-отправитель посылает запрос в Overseer (пассивный режим работы). Параметр passive_resend_interval (см. описание секции [mailbox] п.4.1.1.) - интервал времени в секундах для пассивного режима работы.

Модуль Overseer предназначен для мониторинга Мэйлбоксов, подключенных к ЭДО РТС. Overseer принимает нотификации (оповещения) от всех Мэйлбоксов, которые подключаются к ЭДО РТС либо отключаются от него. Мэйлбокс-отправитель повторяет попытку доставки сообщения, только в том случае, если модуль Overseer подтверждает, что Мэйлбокс-получатель подключен к ЭДО РТС. Подробное описание модуля Overseer см. документ “RTS Overseer. doc”.

Подробная схема взаимодействия Мэйлбокса с ЭДО РТС см. на Рис. 2.

Рис. 2 Схема взаимодействия Мэйлбокса с ЭДО РТС

Обработанные (доставленные) сообщения удаляются из базы данных Мэйлбокса и помещаются в архив сообщений. Подробнее структура архива описана в п. 4.8.

Функции Мэйлбокса:

·  Прием, расшифрование и проверка ЭЦП входящих сообщений от Мэйлбокса отправителя и передача их пользователям;

·  Прием, проверка ЭЦП и шифрование исходящих сообщений от пользователей и передача их на Мэйлбокс получателя;

·  Работа с локальными базами данных сообщений (см. ПРИЛОЖЕНИЕ Б "Работа с БД сообщений").

4.3.  Описание таблиц базы данных Мэйлбокса

База Мэйлбокса – это база промежуточных необработанных сообщений. Необработанные сообщения – это сообщения обработка которых не завершена, либо сообщения на которые еще не получены подтверждения.

База Мэйлбокса состоит из следующих таблиц: MailVersion, MailDupes, MailMillEx, MailBodies. Структура таблиц построена таким образом чтобы упростить и ускорить операции по извлечению сообщений. Реально вся работа происходит в памяти, вся служебная информация по всем необработанным сообщениям хранится в памяти. Информация из таблиц загружается при старте Мэйлбокса, поэтому Мэйлбокс может работать достаточно долго, не читая сообщения из базы данных. Число индексов минимизировано, т. к. вся работа и поиск производятся в памяти. Также для удобства поиска сообщения разделены на заголовки (таблица MailMillEx) и тела (таблица MailBodies).

Уникальным ключом идентифицирующим каждое сообщение является комбинация из уникального идентификатора (uid) анкорного уровня и имени пользователя (user_name) (в таблице MailDupes вместо user_name используется параметр box_name).

Таблица MailVersion – в таблице хранится версия базы.

Название поля	Описание
version	Номер версии базы
version_faircomm	Дополнительное поле (в C-Tree ограничение на длину записи, не меньше 5 байт).

Если номер версии БД не совпадает с номером версии Мэйлбокса, пользователь получает соответствующее уведомление. В этом случае необходимо пересоздать базу данных (экспортировать все сообщения из старой БД в новую).

Таблица MailMillEx – таблица заголовков сообщений.

Название поля	Описание
original_to	Адрес получателя (анкорный уровень)
original_from	Адрес отправителя (анкорный уровень)
user_name	Имя пользователя (имя владельца письма)
uid	Уникальный идентификатор анкорного уровня
status	Статус сообщения: UNSENT – не отправленное, не зашифрованное сообщение. NOT_ACK – например, для User1: сообщение отправлено User1 на MailBox1 и ответ от MailBox1 еще не получен. Происходит перепосылка по тайм-аут. NOT_ACK_FROM_OTHER_MBOX – например, для User1: сообщение отправлено с MailBox1(Мэйлбокс отправителя) на другой MailBox2 (Мэйлбокс-получателя), но ответ от MailBox2 еще не получен (для сообщений самого Мэйлбокса этого статуса нет). SENT – например, для User1: получено подтверждение от MailBox2 на MailBox1. RECV – сообщение получено. FAILED – сообщение с ошибкой. REPLY – сообщение-подтверждение. Специальный вид сообщений которыми обмениваются Мэйлбоксы.
user_status	Статусы пользователя: UNDEFINED, INBOX, OUTBOX, SENT, FAILED, DELETED, REPLY (соответствуют статусам RTSMail, см. описание RTSMail).
body_size	Размер сообщения.
here_time	Время прохождения сообщения через Мэйлбокс.
is_orphan	Оrphan – Признак сообщения. Если orphan не стоит, то за время жизни сообщения отвечает клиентское приложение, сообщение будет удалено через вызов функции удаления из клиентского приложения. Если стоит признак orphan, то сообщение будет помещено в архив и удалено после получения подтверждения о гарантированной доставке от следующего узла связи. Например, ЦЭД не выставляет orphan при посылке оферты, для того, чтобы отслеживать статус при ее доставке.

Таблица MailBodies – таблица тел сообщений, сообщения хранятся фрагментами по 4 Кбайта.

Название поля	Описание
user_name	Имя пользователя
uid	Уникальный идентификатор
slice	Общее количество частей тела сообщения
slice_num	Номер части (1 из 5-ти, 2-ой из 5-ти и т. д.)

Два индекса uid_user_slice_idx и uid_user_body_idx необходимы для быстрой сборки сообщения.

Таблица MailDupes – таблица для хранения uid и user_name.

Название поля	Описание
uid	Уникальный идентификатор пользователя
box_name	Имя пользователя (user_name)
h_time	Время получения сообщения

Таблица дупов – таблица всех uid и user_name отправленных и полученных сообщений которые проходили через данный Мэйлбокс. Она необходима для того, чтобы избежать повторной обработки сообщений при перепосыле.

4.4.  Схема гарантированной доставки сообщений

Одной из самых важных задач Мэйлбокса является гарантированная доставка сообщений. Существует три схемы гарантированной доставки сообщений.

Для того чтобы гарантировать доставку сообщений, используется алгоритм многократного перепосыла сообщений. В существующей версии Мэйлбокса (1.3.6) время доставки не ограничено и сообщение считается доставленным только в случае получения подтверждения, о том, что отправленное сообщение принято.

4.4.1.  Схема доставки между Клиентом CoreMail и Мэйлбоксом

Схема Мэйлбокс-Клиент: Клиент (User) и Мэйлбокс (МailBox). См. рис. 3.

Рис. 3 Схема взаимодействия User-MailBox

User	MailBox
1) Помещает сообщение в БД Сoremail со статусом NOT_ACK.
2) Посылает сообщение на МailBox.
	3) Принимает сообщение. Проверяет в таблице MailDupes uid и user_name, если не находит, заносит их в таблицу MailDupes и разбивает сообщение по другим таблицам БД. Если uid и user_name пришедшего сообщения уже есть в таблице MailDupes (при перепосыле сообщения), в БД сообщение не помещается.
	4) Отправляет Reply-подтверждение о получении сообщения на User. Параметр ruid в Reply – идентификатор полученного сообщения. Cм. пример заголовка ниже п.3.4.2.
5) User получает Reply. Проверяет в таблице MailDupes не был ли Reply получен ранее, если нет помещает в MailDupes и в архив, если да, не помещает. Извлекает из заголовка Reply уникальный идентификатор оригинального сообщения – параметр ruid, если в таблице заголовков MailMillEx есть запись с таким uid, то сообщение считается доставленным и ему присваивается статус NOT_ACK_FROM_OTHER_MBOX. Если в таблице MailMillEx нет такого идентификатора, Reply игнорируется.
6) Если Reply не получен в течение времени resend_interval письмо перепосылается, перейти на 2).

Для схемы гарантированной доставки User-MailBox достаточно получения подтверждения с uid отправленного сообщения. Это простой Reply.

4.4.2.  Схема доставки между двумя Мэйлбоксами

Схема доставки между двумя Мэйлбоксами, принадлежащими разным компаниям происходит по более сложной схеме, потому что необходима не только гарантированная доставка сообщения, но и юридические доказательства того, что сообщение получено. Поэтому в теле ответного сообщения содержится не только uid отправленного сообщения, в нем хранится заголовок отправленного сообщения. Заголовок – это набор криптоуровней. Криптоуровень определяется полями uid, type, time, to, cid, from, sign и т. д.

Пример заголовка сообщения:

UID~2UvMOvwBAgDRT3vQPNpSB-rpiZVxV8dJ~ - уникальный идентификатор
TYPE~PSIGNED~ - тип криптоуровня
TIME~2001/04/05 14:41:29~ - время подписи (для данного узла)
[email protected]~ - адрес получателя
PTYPE~35089~ - пользовательский тип сообщения
RUID~10vMOmcCAAAdAU3Qbr-+2jeEmT1e3otU~ - уникальный идентификатор полученного сообщения
ORPHAN~ - признак сообщения
CID~001120~ - идентификатор сертификата
[email protected]~ - адрес отправителя
SIGN~MDAwMDAwMK0wUK0ZITI4GSirKKVqoH1HbArANJuvMit1uMIRbOZU7XTTXvC2bPdnXgkCeQMWgfV5D8PUORIrWN2bMHK3PlowMDA4OTAwMzk1MDEudYUqnZaPTUVNAboHAAA=~ - подпись отправителя

При прохождении сообщения через все узлы к нему добавляются криптоуровни всех пройденных узлов: подпись Клиента1, подпись Мэйлбокса1, шифрование Мэйлбокса1, подпись Заголовка Мэйлбокса1, подпись Заголовка Мэйлбокса1 на ХС, расшифрование на Мэйлбоксе2, подпись принимающего Мэйлбокса2.

Рассмотрим схему посыла сообщения с MailBox1 на МailBox2. . См. схему взаимодействия Мэйлбоксов рис. 4.

Рис. 4 Схема взаимодействия MailBox1-MailBox2

MailBox1	MailBox2
1) Помещает сообщение в БД со статусом NOT_ACK.
2) Отправляет сообщение на МailBox2.
	3) Принимает сообщение. Проверяет в таблице MailDupes uid и user_name, если не находит, заносит их в таблицу MailDupes и разбивает сообщение по другим таблицам БД. Если uid и user_name пришедшего сообщения уже есть в таблице MailDupes (при перепосыле сообщения), в БД сообщение не помещается.
	4) Формирует Reply1, помещает его в БД и отправляет на MailBox1. Reply1 – это криптопакет который содержит в теле сообщения заголовок полученного сообщения с МailBox1.
5) MailBox1 получает Reply1 от MailBox2. Проверяет в таблице MailDupes не был ли Reply1 получен ранее, если нет помещает в MailDupes и в архив, если да, не помещает. Извлекает из тела Reply1 заголовок оригинального сообщения, если в таблице заголовков MailMillEx есть запись с таким заголовком, то сообщение считается доставленным. Статус изменяется на SENT.
6) МailBox1 отправляет на МailBox2 подтверждение Reply2 о получении ответного сообщения. Это подтверждение обычный простой ответ с пустым телом сообщения. (см. п.3.4.1)
7) Если Reply1 не получен в течение времени resend_interval письмо перепосылается, перейти на 2).
	8) Принимает Reply2 c MailBox1. Схема проверки аналогична схеме приема простого Reply и описана в п.3.4.1.
	9) Если Reply2 не получен в течение времени resend_interval Reply1перепосылается, перейти на 4).

В схеме доставки между двумя Мэйлбоксами ответ (Reply1) должен содержать заголовок сообщения для того, чтобы получатель сообщения MailBox2 не мог опровергнуть получение сообщения с МailBox1. Сообщения с MailBox1 на MailBox2 и Reply1 идут не напрямую, а через ХС. Reply2 - подтверждение идет напрямую на Мэйлбокс, минуя ХС.

См. схему взаимодейситвия Мэйлбоксов через ХС Рис. 5.

Рис. 5 Схема взаимодействия MailBox1-MailBox2 через ХС.

4.4.3.  Особенности взаимодействия Клиента RTSMail с Мэйлбоксом

RTSMail – библиотека у которой нет своей базы сообщений, поэтому она работает в режиме вопрос-ответ. Если сообщение не получено на Мэйлбоксе, RTSMail своими средствами должен делать перепосыл сообщений, их сохранение и т. д.