Приложение 2. Правила разработки электронных сервисов и требования к взаимодействию информационных систем с РСМЭВ

Приложение 2
к распоряжению Департамента
информационных технологий г. Москвы
от 30 мая 2012 г. N 64-16-367/12

Правила
разработки электронных сервисов и требования к взаимодействию информационных систем с РСМЭВ

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

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

Электронные сообщения в региональной системе межведомственного электронного взаимодействия города Москвы передаются в формате XML посредством электронных сервисов (веб-сервисов).

Базовым протоколом взаимодействия определяется SOAP over HTTP. Требования к стандартам и протоколам приведены в разделе 2 настоящих Правил.

Общая структура электронного сообщения включает в себя:

- заголовок электронного сообщения РСМЭВ (soap:Header);

- тело электронного сообщения системы взаимодействия (soap:Body);

- сообщение об ошибке (soap:FauIt).

Заголовок электронного сообщения включает в том числе:

- передачу сведений об аутентификации и авторизации, электронные подписи (технологические электронные подписи) тела сообщения (WS-security);

- передачу параметров при асинхронном взаимодействии (WS-Addressing).

Заголовок электронного сообщения может содержать также дополнительные атрибуты, такие как дата и время отправки сообщения.

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

Тело электронного сообщения предназначено для передачи содержательной части сообщения (данных).

Сообщение об ошибке содержит текстовое описание возникшей ошибки и ее код (опционально) в рамках ИС, в которой она возникла.

Ответственным за содержание реквизитов электронного сообщения является участник межведомственного информационного взаимодействия, отправивший данное электронное сообщение, если иное не предусмотрено нормативными правовыми актами Российской Федерации и города Москвы, настоящими Правилами.

2. Требования к стандартам и протоколам

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

2.1.1. Протокол передачи гипертекста HTTP v. 1.1;

2.1.2. Набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов IPSec (IP Security);

2.1.3. Протоколы поддержки пространства имен DNS (Domain Name Services).

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

2.2.1. Протокол обмена структурированными сообщениями SOAP 1.1 - стандарт консорциума W3C http://www.w3.org/TR/soap/.

2.2.2. Язык описания веб-сервисов (Web Services Description Language, WSDL 1.1) - стандарт консорциума W3C http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html http://www.w3.org/TR/wsdl.

2.2.3. Базовый профиль интероперабельности v. 1.1 - стандарт Организации по интероперабельности веб-сервисов (Web Services Interoperability Organization Basic Profile 1.1) http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html;

2.2.4. Политика использования электронных сервисов WS-Policy 1.2 http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html; http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/);

2.2.5. Профиль интероперабельности по передаче бинарных данных (WS-I Attachments Profile 1.0) - опубликован по адресам в информационно-телекоммуникационной сети Интернет: http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html; http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html;

2.2.6. Допускается также использование оптимизированного механизма передачи бинарных данных в структурированных сообщениях МТОМ (SOAP Message Transmission Optimization Mechanism) - опубликован по адресу в информационно-телекоммуникационной сети Интернет: http://www.w3.org/TR/soap12-mtom/;

2.2.7. Профиль сопоставления данных WS-I Simple SOAP Binding Profile 1.0 - опубликован по адресам в информационно-телекоммуникационной сети Интернет: http://www.wsi.org/Profiles/SimpleSoapBindingProfile-1.0.html; http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html).

2.2.8. Спецификация универсального описания, поиска и интеграции электронных сервисов UDDI 3.0 - опубликована по адресу в информационно-телекоммуникационной сети Интернет: http://www.uddi.org/specification.htm.

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

2.3.1. Расширяемый язык разметки XML - опубликован по адресу в информационно-телекоммуникационной сети Интернет: http://www.w3.org/XML;

2.3.2. Расширяемый язык описания схем данных XML Schema (XML Schema 1.0, XML Schema 1.1) http://www.w3.org/TR/xmlschema-1/structures, http://www.w3.org/TR/xmlschema-2/datatypes;

2.3.3. Расширяемый язык описания таблиц стилей (Extensible Stylesheet Language v 1.1 и XSL Transformation) опубликованы по адресам в информационно-телекоммуникационной сети Интернет: http://www.w3.org/TR/xsl, http://www.w3.org/TR/xslt.

2.4. При разработке электронных сервисов должны быть соблюдены следующие особые условия и ограничения:

2.4.1. Все описания электронных сервисов и описания схем данных должны создаваться в кодировке UTF-8 или UTF-16 (с указанием этой кодировки в заголовке соответствующего описания);

2.4.2. В описаниях электронных сервисов запрещены циклические ссылки между описаниями двух и более электронных сервисов;

2.4.3. Однонаправленные ссылки между описаниями электронного сервиса и описаниями схем данных допустимы в любом количестве и сочетании;

2.4.4. Электронный сервис считается доступным только при одновременной доступности точки доступа электронного сервиса (endpoint) и описания электронного сервиса. Доступность электронного сервиса обеспечивает оператор ИС, в рамках которой функционирует электронный сервис.

2.4.5. Кодировка электронных сообщений в РСМЭВ должна быть UTF-8;

2.4.6. Для межведомственного информационного взаимодействия кодировка вложений должна быть UTF-8.

3. Требования к использованию технологической электронной подписи

Сертификаты ключей проверки электронной подписи (далее - сертификаты), ключей ЭП и ключей проверки ЭП (далее - ключи ЭП) (в соответствии с п. 3 ст. 14 Федерального закона от 6 апреля 2011 г. N 63-ФЗ "Об электронной подписи"), используемые для формирования электронных подписей органа исполнительной власти города Москвы, выдаются на имя органа исполнительной власти города Москвы и применяются в ИС при оказании государственных и муниципальных услуг/исполнении государственных и муниципальных функций с использованием РСМЭВ.

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

По согласованию допускается наличие нескольких сертификатов для одного ОИВ.

Количество формируемых на ОИВ сертификатов ЭП не может быть меньше количества информационных систем данного ОИВ, непосредственно подключенных к РСМЭВ.

Электронное сообщение может содержать более одной ЭП. Обязательной является технологическая ЭП с атрибутом actor, равным RSMEVAUTH. Также возможно произвольное (в том числе нулевое) количество иных ЭП.

Каждая ИС ОИВ должна иметь свой сертификат ЭП, содержащий OID (object identifier) 1.2.643.3.88.1.1.1.8 "Автоматическое заверение электронных сообщений, отправляемых одним органом исполнительной власти города Москвы в адрес другого участника информационного взаимодействия (как московского, так и федерального) посредством электронных сервисов (веб-сервисов), размещенных в региональной системе межведомственного электронного взаимодействия города Москвы (РСМЭВ)", и идентификатор ИС (присваивается Департаментом информационных технологий города Москвы при получении заявки на подключение).

На основе сертификата РСМЭВ проводит аутентификацию и авторизацию, если обращение к электронному сервису с использованием ЭП предусмотрено Поставщиком.

Заголовок сообщения должен содержать в соответствии со стандартом WSSecurity:

- информацию (ссылку) о сертификате,

- подпись тела сообщения,

- атрибут actor подписи - фиксирован и его значение задается в виде строковой константы (RSMEVAUTH);

3.1. Общие требования к ЭП, формируемой РСМЭВ.

Сертификаты и ключи ЭП, используемые для формирования ЭП в сообщениях РСМЭВ, выдаются на имя оператора РСМЭВ и применяются для формирования ЭП РСМЭВ.

ЭП РСМЭВ подтверждает:

- факт прохождения электронного сообщения через РСМЭВ;

- факт аутентификации и авторизации в соответствии с правилами, указанными в реестре прав доступа к электронным сервисам (матрице доступа);

- неизменность сведений, внесенных в электронное сообщение РСМЭВ.

3.2. Блок ЭП информационной системы:

3.2.1. Блок ЭП предназначен для передачи значений ЭП в установленном формате. Значение атрибута actor ЭП всегда указывается RSMEVAUTH.

3.2.2. Сведения этого блока, помимо хранения собственно самой ЭП отправителя, используются РСМЭВ для аутентификации и авторизации обращений к электронным сервисам.

3.3. Блок ЭП РСМЭВ:

3.3.1. Блок ЭП РСМЭВ предназначен для передачи значений ЭП, формируемой РСМЭВ в установленном формате.

3.3.2. ЭП, передаваемая в этом блоке, используется для подписания сведений в электронном сообщении, добавляемых при передаче РСМЭВ.

3.4. Унифицированный служебный заголовок РСМЭВ:

3.4.1. Унифицированный служебный заголовок РСМЭВ предназначен для размещения в сообщении сведений, добавляемых РСМЭВ.

3.4.2. ИС участников межведомственного взаимодействия не обязаны обрабатывать данный блок, но должны корректно осуществлять обработку входящих сообщений, содержащих унифицированный служебный заголовок РСМЭВ.

3.4.3. Состав элементов, входящих в служебный заголовок, не является жестко специфицированным. С развитием формата сообщений, передаваемых через РСМЭВ, возможно расширение состава элементов.

3.4.4. Минимальный набор элементов содержит сведения о метке времени прохождения сообщения через РСМЭВ.

3.4.5. Для обозначения унифицированного служебного заголовка РСМЭВ применяется элемент rsmev:Header в пространстве имен xmlns:rsmev.

3.5. Правила формирования ЭП:

Структура ЭП должна соответствовать стандарту OASIS Standard 200401 (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-sec urity-1.0.pdf) с профилем Х.509 Certificate Token Profile (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi le-1.0.pdf).

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

4. Требования к передаче вложений

Поддерживаются два формата передачи вложений:

- вложение в виде бинарных данных в пределах самого блока передачи вложений (пример сообщения приведен в Приложении 1);

- вложения присоединяются к конверту электронного сообщения в соответствии со спецификацией МТОМ (http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/) (пример сообщения приведен в Приложении 2).

4.1. Требования к описанию метаданных:

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

4.1.2. Документирование элементов метаданных следует выполнять с использованием конструкции:

- (xsd:annotation)

(xsd:documentation) Текст описания (/xsd:documentation)

- (/xsd:annotation).

4.1.3. Синтаксическую конструкцию (!- текст комментария -) рекомендуется применять только в качестве вспомогательных комментариев к описаниям данных, если это необходимо, и не использовать для документирования элементов метаданных.

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

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

4.1.6. Все слова в наименовании элемента метаданных рекомендуется использовать полностью, без сокращений.

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

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

4.1.9. В наименования простых и составных типов (simpleType, complexType) для обозначения их отличия от элементов (element) рекомендуется добавлять суффикс "Type".

4.2. Требования к контрольному примеру:

Контрольный пример будет использоваться для проверки работоспособности электронного сервиса при регистрации в Реестре, а также для отладки взаимодействия со стороны внешних ИС, Пользователей данного электронного сервиса.