Без рубрики

Об утверждении Требований к подключению и взаимодействию информационных систем с использованием региональной системы межведомственного электронного взаимодействия города Москвы

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

Во исполнение постановления Правительства Москвы от 25 октября 2011 года N 498-ПП "О региональной системе межведомственного электронного взаимодействия города Москвы":
1. Утвердить:
1.1. Требования к подключению и взаимодействию информационных систем к региональной системе межведомственного электронного взаимодействия города Москвы согласно приложению 1 к настоящему распоряжению.
1.2. Правила разработки электронных сервисов и требования к взаимодействию информационных систем с использованием региональной системы межведомственного электронного взаимодействия города Москвы согласно приложению 2 к настоящему распоряжению.
2. Контроль за исполнением настоящего приказа возложить на заместителя руководителя департамента С.А. Лысенко.

Руководитель департамента А.В. Ермолаев

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

ТРЕБОВАНИЯ К ПОДКЛЮЧЕНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ К РЕГИОНАЛЬНОЙ СИСТЕМЕ МЕЖВЕДОМСТВЕННОГО ЭЛЕКТРОННОГО ВЗАИМОДЕЙСТВИЯ ГОРОДА МОСКВЫ

1. Общие положения

1.1. Настоящие Требования определяют последовательность действий и процедур:
— по подключению информационных систем (далее — ИС) органов исполнительной власти города Москвы и подведомственных организаций (далее — органы и организации) к региональной системе межведомственного электронного взаимодействия города Москвы (далее — РСМЭВ);
— по реализации прав доступа к сервисам РСМЭВ;
— по регистрации электронных сервисов в РСМЭВ;
— по взаимодействию в РСМЭВ.
1.2. В настоящих Требованиях используются следующие термины и определения:
реестр электронных сервисов информационных систем (далее — Реестр) — специализированное хранилище данных в составе РСМЭВ, содержащее формализованные описания электронных сервисов и ИС, подключенных в РСМЭВ, их возможностей и характеристик;
Оператор — Департамент информационных технологий города Москвы или организация, определенная в соответствии с Положением о региональной системе межведомственного электронного взаимодействия города Москвы, утвержденным постановлением Правительства Москвы от 25 октября 2011 года N 498-ПП;
Владелец ИС — орган или организация, являющиеся собственником или осуществляющие полномочия собственника ИС, которую необходимо подключить к РСМЭВ;
Поставщик — владелец ИС, подключенной в РСМЭВ и предоставляющей с использованием электронных сервисов информацию для ИС, подключенных к РСМЭВ;
Потребитель — владелец ИС, подключенной к РСМЭВ и запрашивающей доступ к информации, передаваемой с использованием электронных сервисов ИС, подключенных в РСМЭВ.

2. Участники процесса подключения информационных систем к РСМЭВ

2.1. Участниками процесса подключения ИС к РСМЭВ являются оператор, поставщики и потребители.

3. Порядок подключения информационной системы в РСМЭВ

3.1. ИС, в отношении которой принято решение о готовности подключения к РСМЭВ, подлежит регистрации в РСМЭВ.
3.2. Регистрация ИС в РСМЭВ осуществляется Оператором на основании заявки на подключение ИС к РСМЭВ по форме согласно приложению 1 к настоящим Требованиям.
3.3. Для регистрации ИС в РСМЭВ владелец ИС направляет Оператору следующий пакет документов:
— заявка на подключение ИС к РСМЭВ;
— сертификат ключа технологической электронной подписи (далее — электронная подпись, ЭП, технологическая ЭП), ИС в формате BASE 64 (*.cer);
— корневой сертификат удостоверяющего центра, выдавшего сертификат ключа электронной подписи ИС;
— контрольный пример, подписанный технологической электронной подписью ИС.
3.4. Регистрация ИС в РСМЭВ возможна только при наличии между РСМЭВ и ИС канала связи с использованием средств защиты информации.
Оператор обеспечивает организацию защиты физического канала связи между РСМЭВ и объектами, расположенными по адресам, указанным в заявке на подключение ИС к РСМЭВ.
Оператор обеспечивает доставку, монтаж и запуск средств защиты информации по адресам, указанным в заявке на подключение ИС к РСМЭВ, при наличии физического канала связи.
Владелец ИС обеспечивает доступ представителей Оператора к месту размещения ИС для установки средств защиты информации.
По факту передачи Оператором средств защиты информации Владельцу ИС обеими сторонами подписывается акт приема-передачи оборудования в безвозмездное временное пользование.
3.5. По результатам регистрации ИС в РСМЭВ Оператор направляет ответственным представителям Владельца ИС уведомление о подключении ИС к РСМЭВ по электронной почте с указанием мнемонического идентификатора ИС.
3.6. Владелец ИС осуществляет тестирование подключения ИС к РСМЭВ и уведомляет Оператора о результатах тестирования.
3.7. По результатам тестирования составляется протокол по форме согласно приложению 5 к настоящим Требованиям.
3.8. В случае неудовлетворительного результата тестирования Оператор совместно с Владельцем ИС проводят мероприятия, направленные на устранение выявленных недостатков.
3.9. В случае достижения положительных результатов тестирования регистрация ИС признается завершенной.

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

4.1. ИС Поставщика должна быть подключена к РСМЭВ в соответствии с пунктом 3 настоящих Требований.
4.2. Поставщик для регистрации каждого электронного сервиса предоставляет Оператору следующий пакет документов:
— паспорт и описание формата электронного сервиса (приложение 2 к настоящим Требованиям);
— сведения о сертификате ключа электронной подписи ИС Поставщика, используемом при подписании электронных сообщений, передаваемых с использованием электронного сервиса в ответ на поступающие запросы из ИС других участников информационного взаимодействия;
— руководство пользователя электронного сервиса (приложение 4 к настоящим Требованиям — не приводится);
— контрольный пример для проверки работоспособности электронного сервиса, содержащий технологическую электронную подпись ИС Поставщика.
4.3. Поставщиком для каждого электронного сервиса определяется и указывается в паспорте электронного сервиса порядок доступа Потребителей к электронному сервису. При отсутствии этой информации доступ к электронному сервису будет разрешен только Поставщику и Оператору в целях тестирования и мониторинга доступности соответствующего электронного сервиса.
4.4. Оператор регистрирует электронный сервис в Реестре.
4.5. По результатам регистрации электронного сервиса Поставщика Оператор направляет ответственным представителям Владельца ИС уведомление о регистрации электронного сервиса в Реестре по электронной почте, содержащее паспорт электронного сервиса с указанием следующих данных:
— идентификатор сервиса;
— дата регистрации;
— адрес сервиса в РСМЭВ.
4.6. Оператор совместно с Поставщиком осуществляет тестирование электронного сервиса. Тестирование осуществляется с использованием контрольных примеров, предоставленных Поставщиком. В случае невозможности регистрации электронного сервиса (например, из-за его некорректного функционирования) Оператор незамедлительно информирует Поставщика о необходимости устранения указанных причин.
4.7. По результатам тестирования составляется протокол по форме согласно приложению 5 к настоящим Требованиям.
4.8. В случае неудовлетворительного результата тестирования Поставщик проводит мероприятия, направленные на устранение выявленных недостатков, с привлечением при необходимости Оператора.
4.9. При достижении положительных результатов тестирования Оператор публикует информацию об электронном сервисе на технологическом портале РСМЭВ, а регистрация электронного сервиса признается завершенной.

5. Порядок реализации прав доступа к электронным сервисам

5.1. Потребитель направляет Оператору заявку на предоставление доступа к электронному сервису по форме согласно приложению 3 к настоящим Требованиям.
5.2. Оператор анализирует заявку на предмет возможности предоставления доступа к электронному сервису:
— Потребитель должен быть указан в списке разрешенных Потребителей в паспорте электронного сервиса Поставщика;
— ИС Потребителя должна быть зарегистрирована в РСМЭВ.
5.3. В случае если запрошенные права доступа отсутствуют или не соответствуют правам, указанным в реестре прав доступа, Оператор уведомляет об этом Потребителя.
5.4. Потребитель согласовывает предоставление доступа с Поставщиком.
5.5. В случае принятия Поставщиком положительного решения о доступе Потребителя к своему электронному сервису Поставщик вносит изменения в паспорт электронного сервиса и предоставляет новую версию паспорта Оператору.
5.6. После получения новой версии паспорта от Поставщика Оператор обеспечивает техническую реализацию доступа ИС Потребителя к электронному сервису Поставщика.
5.7. Оператор уведомляет по электронной почте ответственного представителя Потребителя о предоставлении доступа к электронному сервису.
5.8. Потребитель осуществляет тестирование корректности доступа к электронному сервису. Тестирование осуществляется с использованием контрольных примеров, предоставленных Поставщиком.
5.9. В случае неудовлетворительного результата тестирования Потребитель, Оператор и Поставщик проводят мероприятия, направленные на устранение выявленных недостатков.
5.10. При достижении положительных результатов тестирования реализация прав доступа к электронному сервису признается завершенной.
5.11. По результатам тестирования составляется протокол по форме согласно приложению 5 к настоящим Требованиям.

Приложение 1 к Требованиям к подключению информационных систем к региональной системе межведомственного электронного взаимодействия города Москвы

ОБРАЗЕЦ ЗАЯВКИ НА ПОДКЛЮЧЕНИЕ

Заявка на подключение информационной системы к региональной системе межведомственного электронного взаимодействия города Москвы

Данные о владельце
Полное наименование
Краткое наименование
Юридический адрес
(индекс, г. Москва, улица, д. __, корп. __)
ИНН
ОГРН
Данные об информационной системе
Полное наименование
Краткое наименование
Комментарии
(если имеются)
Мнемонический идентификатор
присваивается Оператором
Стадия создания
(Разработка/Опытная эксплуатация/Промышленная эксплуатация)
Адреса организации каналов связи
Адрес 1
(г. Москва, улица, д. __, корп. __)
Адрес 2
(г. Москва, улица, д. __, корп. __)
Адрес 3
(г. Москва, улица, д. __, корп. __)
Данные о сертификате технологической электронной подписи
Серийный номер СКП
Дата начала действия СКП
Дата окончания действия СКП
Удостоверяющий центр
Город
Представители владельца, ответственные за функционирование информационной системы (необходимо указать контактную информацию как минимум двух представителей)
Представитель 1
Фамилия
Имя
Отчество
Должность
Рабочий телефон
Мобильный телефон
Адрес электронной почты
Представитель 2
Фамилия
Имя
Отчество
Должность
Рабочий телефон
Мобильный телефон
Адрес электронной почты
Данные о сетевом окружении информационной системы
Адрес и маска сети внешнего интерфейса межсетевого экрана (может быть как из приватный, так и из публичный адрес пространства (IP внеш./маска)
Адрес шлюза по умолчанию в сети, в которую включается внешний интерфейс межсетевого экрана (IP gw внеш.)
В случае использования приватного адреса на внешнем интерфейсе межсетевого экрана — публичный адрес NAT трансляции, через который осуществляется доступ к внешнему интерфейсу межсетевого экрана (IP fw(NAT)
Адрес и маска сети внутреннего интерфейса межсетевого экрана (IP внут./маска)
Адрес шлюза для маршрутизации внутрь информационной системы владельца для сети, в которую включается внутренний интерфейс межсетевого экрана (если применимо) (IP gw внут.)
Адрес(а) сервера(ов) органов и организаций, которые будут взаимодействовать с сервером РСМЭВ (IP тун.)

Приложение 2 к Требованиям к подключению информационных систем к региональной системе межведомственного электронного взаимодействия города Москвы

ОБРАЗЕЦ ПАСПОРТА ЭЛЕКТРОННОГО СЕРВИСА

Паспорт электронного сервиса

Сведения об информационной системе, предоставляющей электронный сервис
Полное наименование
Краткое наименование
Данные о ведомстве
Полное наименование
Краткое наименование
Представители владельца, ответственные за функционирование электронного сервиса (необходимо указать контактную информацию как минимум двух представителей)
Представитель 1
Фамилия
Имя
Отчество
Должность
Рабочий телефон
Мобильный телефон
Адрес электронной почты
Представитель 2
Фамилия
Имя
Отчество
Должность
Рабочий телефон
Мобильный телефон
Адрес электронной почты
Представитель владельца, согласующий предоставление доступа потребителям
Фамилия
Имя
Отчество
Должность
Рабочий телефон
Сведения об электронном сервисе
Идентификатор сервиса
назначается Оператором
Полное наименование
Краткое наименование
Основное назначение
Область применения
Не заполняется
Версия
в формате X. XX
Стадия создания
(Разработка/Опытная эксплуатация/Промышленная эксплуатация)
Режим взаимодействия сервиса
Не заполняется
Дата регистрации
указывается Оператором
Адрес описания
Ссылка на WSDL документ, описывающий электронный сервис
Адрес Поставщика
Адрес электронного сервиса у Поставщика
Адрес РСМЭВ
назначается Оператором
Режим гарантированной доступности
Операции (методы) электронного сервиса
Код операции
Наименование операции
Назначение операции
Операция 1
Запрос
Выполнение запроса
Операция 2
Ответ
Возвращение данных

Права (матрица) доступа
Потребитель сервиса
Наименование информационной системы потребителя
Уровень доступа (полный/по операциям)
Список допустимых операций
Владелец 1
Информационная система 1
Полный
Владелец 2
Информационная система 2
По операциям
Операция 1
Операция 3

Приложение 3 к Требованиям к подключению информационных систем к региональной системе межведомственного электронного взаимодействия города Москвы

ОБРАЗЕЦ ЗАЯВКИ НА ПОЛУЧЕНИЕ ДОСТУПА К СЕРВИСУ

 Заявка на получение доступа к электронному сервису информационной системы, подключенной к РСМЭВ В Департамент информационных технологий города Москвы ЗАЯВКА___________________________________________________________________________ наименование участника межведомственного информационного взаимодействияна предоставление доступа к электронному сервису___________________________________________________________________________ наименование информационной системы, мнемонический идентификатор___________________________________________________________________________ наименование собственника информационной системы В целях реализации соглашения о взаимодействии при обеспеченииоказания государственных услуг и исполнении государственных функций вэлектронном виде _________________________________________________________,во исполнение следующих нормативных правовых актов:_________________________________________________________________________________________________________________________________________________________________________________________________________________________________ дата, номер и наименование нормативных правовых актов, устанавливающихвозможность получения информации для предоставления государственных услуг и исполнения государственных функций прошу: предоставить доступ к электронному сервису___________________________________________________________________________ наименование электронного сервиса, SID в составе следующих операций:

Наименование операций
Уровень доступа
Электронный сервис
Полный
Операция 1
По операциям
Операция 2
По операциям

 подпись, расшифровка подписи, дата М.П.

Приложение 5 к Требованиям к подключению информационных систем к региональной системе межведомственного электронного взаимодействия города Москвы

ШАБЛОН ПРОТОКОЛА ПРОВЕДЕНИЯ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ

— [Текст], написанный в квадратных скобках, является руководством по заполнению разделов шаблона и при формировании документа должен быть удален.
— Текст, выделенный жирным курсивом, является примером заполнения раздела и при формировании документа должен быть удален.
— Текст без специальных выделений является обязательным для использования в документе и не подлежит удалению.

1.1. Ссылки на документы

N
Наименование
Описание
Версия
Дата
1
[Наименование документа]
ПЛАН ТЕСТИРОВАНИЯ
0.01

1.2. Субъект тестирования

[Описание субъекта тестирования]

1.3. Объект тестирования

1.3.1. Идентификация версии

Номер Версии
1.0
Тип Версии
ПОСТАВОЧНАЯ

1.3.2. Список компонентов

Компонент
Вид тестирования
Система целиком
НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ
Тип входящего запроса process
НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ

1.4. Результат тестирования

Результат тестирования
[Результат тестирования]

[Описание результатов тестирования]

1.4.1. Динамическая нагрузка

Параметр
Значение
Критерий
Max1
[значение]
[Критерий окончания теста]
Max2
[значение]
[Критерий окончания теста]

1.4.2. Статическая нагрузка

Параметр
Значение
Критерий
Time1
[значение]
[Критерий окончания теста]
Time2
[значение]
[Критерий окончания теста]

1.5. Программа и методика испытаний

1.5.1. Динамическая нагрузка web-сервиса

Параметр
Значение
Длительность
[время испытания]
Минимальное значение, запросов/с
[минимальное количество запросов]
Максимальное значение, запросов/с
[максимальное количество запросов] (с одной машины)
Тестируемый тип запроса
Process
Проект
[название проекта SoapUI для тестирования]

Стратегия
Хост
min
max
avg
last
cnt
tps
bytes
bps
err
rat
Нарастающая нагрузка с [количество] до [количество] потоков
[IP хоста]

Расшифровка параметров:
— min — минимальное время отклика (миллисекунды);
— max — максимальное время отклика (миллисекунды);
— avg — среднее время отклика (миллисекунды);
— last — время отклика на последнее обращение (миллисекунды);
— cnt — число сообщений;
— tps — число завершенных транзакций в секунду;
— bytes — количество байт;
— bps — байт в секунду;
— err — отказы;
— rat — процент отказов.
[Описание ошибок]
[Графики и описание графиков тестирования]

1.5.2. Статическая нагрузка web-сервиса с одной клиентской машины

Параметр
Значение
Длительность
Минимальное значение, запросов/с
Максимальное значение, запросов/с
Тестируемый тип запроса
Проект

Стратегия
Хост
min
max
avg
last
cnt
tps
bytes
bps
err
rat
Статичная нагрузка [количество] потоков

Расшифровка параметров:
— min — минимальное время отклика (миллисекунды);
— max — максимальное время отклика (миллисекунды);
— avg — среднее время отклика (миллисекунды);
— last — время отклика на последнее обращение (миллисекунды);
— cnt — число сообщений;
— tps — число завершенных транзакций в секунду;
— bytes — количество байт;
— bps — байт в секунду;
— err — отказы;
— rat — процент отказов.
[Описание ошибок]
[Графики и описание графиков тестирования]

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

ПРАВИЛА РАЗРАБОТКИ ЭЛЕКТРОННЫХ СЕРВИСОВ И ТРЕБОВАНИЯ К ВЗАИМОДЕЙСТВИЮ ИНФОРМАЦИОННЫХ СИСТЕМ С РСМЭВ

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

Электронный сервис — программный модуль, идентифицируемый адресом URL, чьи публичные интерфейсы и привязки определены и описаны в стандарте XML. По указанным параметрам электронный сервис может быть распознан другими электронными сервисами, которые могут взаимодействовать с ним посредством электронных сообщений.
Электронные сообщения в региональной системе межведомственного электронного взаимодействия города Москвы передаются в формате XML посредством электронных сервисов (веб-сервисов).
Базовым протоколом взаимодействия определяется SOAP over HTTP. Требования к стандартам и протоколам приведены в разделе 2 настоящих Правил.
Общая структура электронного сообщения включает в себя:
— заголовок электронного сообщения РСМЭВ (soap:Header);
— тело электронного сообщения системы взаимодействия (soap:Body);
— сообщение об ошибке (soap:Fault).
Заголовок электронного сообщения включает в том числе:
— передачу сведений об аутентификации и авторизации, электронные подписи (технологические электронные подписи) тела сообщения (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. Допускается также использование оптимизированного механизма передачи бинарных данных в структурированных сообщениях MTOM (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-security-1.0.pdf) с профилем X.509 Certificate Token Profile (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf).
Формирование ЭП должно производиться средствами сертифицированных систем криптографической защиты информации.

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

Поддерживаются два формата передачи вложений:
— вложение в виде бинарных данных в пределах самого блока передачи вложений (пример сообщения приведен в приложении 1 — не приводится);
— вложения присоединяются к конверту электронного сообщения в соответствии со спецификацией MTOM (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. Требования к контрольному примеру:
Контрольный пример будет использоваться для проверки работоспособности электронного сервиса при регистрации в Реестре, а также для отладки взаимодействия со стороны внешних ИС, Пользователей данного электронного сервиса.

Добавить комментарий