Приложение А (справочное). Требования к провайдеру MSM-сервиса

Приложение А
(справочное)

Требования
к провайдеру MSM-сервиса

А.1 Требования к провайдеру сервиса

Нижеследующие разделы определяют сервисы ESB типа (сервисной шины предприятия). Данные сервисы обеспечиваются провайдерами MSM-сервисов. Указанные сервисы не входят в MSM-спецификацию. Они формируют области, в которых продавцы и другие заинтересованные стороны обеспечивают работу дифференцированных сервисов.

А.2 Уведомление

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

А.3 Требования безопасности

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

a) Провайдер MSM-сервиса может хранить сообщения как данные постоянного хранения. Если это имеет место, и безопасность канала обеспечена, то сохраняемые сообщения могут быть зашифрованы, чтобы предотвратить несанкционированный доступ к ним.

b) Запросы на доступ с недопустимыми маркерами безопасности регистрируются в журнале. Наличие записей в журнале указывает либо на проблемы с конфигурацией, либо на возможные атаки на систему.

c) Запросы на доступ к недопустимым URI канала также регистрируются в журнале. Наличие записей в журнале указывает либо на проблемы с конфигурацией, либо на возможные атаки на систему.

d) Внутренние сообщения конкретного MSM-сервиса могут шифроваться. Они могут передаваться по специальному безопасному каналу. Используемый метод коммуникации может зависеть от используемых сервисов транспортировки. Он может не определяться в интерфейсе MSM-сервиса.

е) Идентификатор сеанса связи MSM должен быть уникальным в глобальном масштабе. Его использование ограничивается конкретным провайдером (потребителем). Доступ к каналу производится только через маркер безопасности.

А.4 Требования к практической реализации MSM-приложения

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

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

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

c) MSM-сервисы не обеспечивают проверку сообщений. Приложения-получатели должны проверять все полученные сообщения на соответствие установленным требованиям (например, требованиям B2MML).

А.5 Требования безопасности к MSM-каналам

Некоторые практические реализации могут потребовать дополнительных уровней безопасности, отличных от уровней, определенных в 5.2.6. Например, рассматриваемые практические реализации могут потребовать особой безопасности для сообщений типа GET/SHOW (получить/показать), для сообщений типа PROCESS (обработать), CHANGE (изменить), CANCEL (снять). Одни каналы могут специализироваться по запросам (типа GET/SHOW), другие - по обработке сообщений (типа PROCESS, CHANGE, CANCEL).

А.6 Требования к идентификаторам сеансов связи MSM

Идентификаторы сеансов связи MSM должны содержать длинные числа, включать несколько строк, быть неочевидными и неугадываемыми. Данные идентификаторы должны быть уникальными для каждого приложения и каждого канала. Это делается для того, чтобы предотвратить доступ к сеансу связи без маркера безопасности. Некоторые сервисы обеспечивают безопасность, полагаясь на идентификатор сеанса связи MSM. Так как идентификатор сеанса связи MSM не изменяется (он хранится приложением), то механизм хранения должен принимать специальные меры безопасности. Только приложение-хранилище имеет право предоставлять идентификатор сеанса связи MSM и использовать его для коммуникаций.

А.7 Валидация формата данных

Провайдер MSM-сервиса обеспечивает проверку формата данных в сообщениях. Если формат данных в сообщении соответствует установленным требованиям (например, требованиям B2MML, BatchML и т.п.), то провайдер сервиса проверяет корректность синтаксиса выложенных сообщений.

Сообщения подлежат контрольной проверке.

В данном случае провайдер MSM-сервиса должен задействовать карту перекрестных связей перечня тем и файлов XML-схемы. Данная карта используется провайдером для проверки корректности подписки, запросов и ответов.

А.8 Допустимые проверки приложений

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

А.9 Регистрация обмена данных в журнале

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

А.10 Обработка типовых ошибок

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

А.11 Сервис преобразования данных

Провайдер MSM-сервиса может преобразовывать данные в сообщениях. Обычно это преобразование специального формата данных приложения провайдера (приложения потребителя) в какой-либо стандартный формат (например, формат B2MML, формат BatchML и т.п.). И наоборот, это может быть преобразование из стандартного формата в специальный формат конкретного приложения.

Специального требования к провайдерам MSM-сервисов по выполнению вышеуказанных преобразований не предъявляется.

Обычно преобразование интерфейсов производится с учетом перечня тем. Формат темы должен соответствовать формату рассматриваемого приложения. Провайдер MSM-сервисов ассоциирует тему сообщения с необходимым преобразованием. Если получено сообщение с темой преобразования, то провайдер MSM-сервиса преобразует специальный формат данного сообщения в стандартный. Если получен запрос с темой преобразования, то провайдер MSM-сервиса, наоборот, преобразует стандартный формате специальный формат Приложения, соответствующий формату темы.

Провайдер MSM-сервиса обеспечивает корректное соотношение между:

1) Темой приложения;

2) правилами преобразования специального формата в стандартный;

3) определением "стандартной" Темы.

Рисунок А.1 - Сервисы MSM-преобразований

А.12 Корпоративный мост

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

Требований к порядку обеспечения корпоративного сервиса MSM провайдером не предъявляется.

Сценарий построения цепи обеспечения сохранности опубликованных сообщений показан на рисунке А.2. По данному сценарию, представитель приложения (или часть MSM-сервиса) из окружения компании А следит за публикациями MSM-сервиса. Представитель выкладывает публикацию с помощью аутентифицированного (безопасного) метода для представителя приложения из окружения компании В. Получающий сообщение представитель публикует свое сообщение в MSM-среде компании В. Рассматриваемый мост может также преобразовать канал и темы из пространства имен компании А в пространство имен компании В.

Примечание - Спецификации безопасных (аутентифицированных) каналов связи в настоящем стандарте не рассматриваются.

Рисунок А.2 - Корпоративный мост между несколькими MSM-сервисами

А.13 Техническое обслуживание сообщений

Провайдер MSM-сервиса управляет сообщениями в канале. При этом сервис обладает следующими возможностями:

- стирание "висячих" сообщений, не стертых ранее вследствие отказа транзакции запроса (отклика);

- отслеживание длины очереди сообщений, уведомление ответственных лиц об образовании недопустимо длинной очереди;

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