Приложение А (справочное). Требования к провайдеру 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-сервиса может преобразовывать данные в сообщениях. Обычно это пре