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

1. УТВЕРЖДЕНО
приказом Министерства связи
и массовых коммуникаций
Российской Федерации
от №
Технические требования
к взаимодействию информационных систем в единой системе
межведомственного электронного взаимодействия
1. Общие положения
1.1. Настоящие Технические требования (далее – Требования) к
взаимодействию информационных систем в единой системе
межведомственного электронного взаимодействия определяют правила
интеграции информационных систем федеральных органов исполнительной
власти, государственных внебюджетных фондов, исполнительных органов
государственной власти субъектов Российской Федерации, органов местного
самоуправления, государственных и муниципальных учреждений,
многофункциональных центров, иных органов и организаций (далее – органы
и организации), используемых при предоставлении государственных и
муниципальных услуг и исполнении государственных и муниципальных
функций в электронной форме (далее – информационные системы), с единой
системой межведомственного электронного взаимодействия (далее – система
взаимодействия), а также требования к техническому обеспечению
информационного обмена, осуществляемого с применением единой системы
межведомственного электронного взаимодействия между информационными
системами в целях предоставления государственных и муниципальных услуг
и исполнения государственных и муниципальных функций в электронной
форме (далее – Требования).
1.2. В настоящих Требованиях использованы нормы, требования и
рекомендации, приведенные в следующих законодательных, нормативно-
правовых и иных актах:
Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации,
информационных технологиях и о защите информации»;
Федеральный закон от 10 января 2002 г. № 1-ФЗ «Об электронной
цифровой подписи»;
Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации
предоставления государственных и муниципальных услуг»;
постановление Правительства РФ от 10 сентября 2009 г. № 723 «О
порядке ввода в эксплуатацию отдельных государственных информационных
систем»;
постановление Правительства РФ от 15 июня 2009 г. № 478 «О единой
системе информационно-справочной поддержки граждан и организаций по

2. вопросам взаимодействия с органами исполнительной власти и органами
местного самоуправления с использованием информационно-
телекоммуникационной сети Интернет»;
постановление Правительства Российской Федерации
от 11 ноября 2003 г. № 677 «Об общероссийских классификаторах технико-
экономической и социальной информации в социально-экономической
области»;
постановление Правительства РФ от 28 января 2002 г. № 65 «О
федеральной целевой программе "Электронная Россия (2002 - 2010 годы)»
ГОСТ 19.001-77 «Общие положения»;
ГОСТ 19781-90 «Термины и определения»;
ГОСТ 19.101-77 «Виды программ и программных документов»;
ГОСТ 19.102-77 «Стадии разработки»;
ГОСТ 19.103-77 «Обозначения программ и программных документов»;
ГОСТ 19.104-78 «Основные надписи»;
ГОСТ 19.105-78 «Общие требования к программным документам»;
ГОСТ 19.106-78 «Требования к программным документам,
выполненным печатным способом»;
ГОСТ 19.201-78 «Техническое задание, требования к содержанию и
оформлению»;
ГОСТ 19.202-78 «Спецификация. Требования к содержанию и
оформлению»;
ГОСТ 19.301-79 «Программа и методика испытаний. Требования к
содержанию и оформлению»;
ГОСТ 19.401-78 «Текст программы. Требования к содержанию и
оформлению»;
ГОСТ 19.402-78 «Описание программы»;
ГОСТ 19.403-79 «Ведомость держателей подлинников»;
ГОСТ 19.404-79 «Пояснительная записка. Требования к содержанию и
оформлению»;
ГОСТ 19.501-78 «Формуляр. Требования к содержанию и
оформлению»;
ГОСТ 19.502-78 «Описание применения. Требования к содержанию и
оформлению»;
ГОСТ 19.503-79 «Руководство системного программиста. Требования к
содержанию и оформлению»;
ГОСТ 19.504-79 «Руководство программиста. Требования к
содержанию и оформлению»;
ГОСТ 19.505-79 «Руководство оператора. Требования к содержанию и
оформлению»;
ГОСТ 19.506-79 «Описание языка. Требования к содержанию и
оформлению»;
ГОСТ 19.507-79 «Ведомость эксплуатационных документов»;
ГОСТ 19.508-79 «Руководство по техническом обслуживанию.
Требования к содержанию и оформлению»;

3. ГОСТ 19.601-78 «Общие правила дублирования, учета и хранения»;
ГОСТ 19.602-78 «Правила дублирования, учета и хранения
программных документов, выполненных печатным способом»;
ГОСТ 19.603-78 «Общие правила внесения изменений»;
ГОСТ 19.604-78 «Правила внесения изменений в программные
документы, выполненных печатным способом»;
ГОСТ 34.201-89 «Виды, комплектность и обозначения документов при
создании автоматизированных систем»;
ГОСТ 34.320-96 «Концепции и терминология для концептуальной
схемы и информационной базы»;
ГОСТ 34.321-96 «Информационные технологии. Система стандартов
по базам данных. Эталонная модель управления»;
ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
ГОСТ 34.602-89 «Техническое задание на создание
автоматизированной системы»;
ГОСТ 34.603-92 «Информационная технология. Виды испытаний
автоматизированных систем»;
РД 50-34.698-90 «Автоматизированные системы. Требования к
содержанию документов»;
ГОСТ Р ИСО/МЭК 8824-3-2002 «Информационная технология.
Абстрактная синтаксическая нотация версии один»;
ГОСТ Р ИСО/МЭК 10746-3-2001 «Управление данными и открытая
распределенная обработка»;
ГОСТ Р ИСО/МЭК 15271-02 «Процессы жизненного цикла
программных средств»;
ГОСТ Р ИСО/МЭК 15910-2002 «Процесс создания документации
пользователя программного средства»;
ГОСТ 7.79-2000 (ИСО 9-95) «Правила транслитерации кирилловского
письма латинским алфавитом»;
ГОСТ Р ИСО 9001-2008 «Системы менеджмента качества.
Требования», утвержден приказом Ростехрегулирования от 18 декабря 2008
г. № 471-ст;
Руководящий документ. Средства вычислительной техники.
Межсетевые экраны. Защита от несанкционированного доступа к
информации. Показатели защищенности от несанкционированного доступа к
информации, утвержденный решением председателя Государственной
технической комиссии при Президенте Российской Федерации от 25 июля
1997 г.
Методические рекомендации по обеспечению с помощью
криптосредств безопасности персональных данных при их обработке в
информационных системах персональных данных с использованием средств
автоматизации, утвержденным руководством 8 Центра Федеральной службы
безопасности Российской Федерации 21 февраля 2008 года № 149/54-144;
Методика определения актуальных угроз безопасности персональных
данных при их обработке в информационных системах персональных

4. данных, утвержденная Заместителем директора Федеральной службы по
техническому и экспортному контролю 14 февраля 2008 года;
Базовая модель угроз безопасности персональных данных при их
обработке в информационных системах персональных данных, утвержденная
Заместителем директора Федеральной службы по техническому и
экспортному контролю 15 февраля 2008 года.
1.3. В настоящих Требованиях и Приложениях к настоящим
Требованиям используются следующие сокращения:
ЗСПД - защищенная сеть передачи данных;
ИКТ - информационно-коммуникационные технологии;
ИОГВ - исполнительные органы государственной власти;
ИС - информационные системы;
ЛК - централизованная система «Личный кабинет»;
МФЦ - многофункциональный центр предоставления
государственных и муниципальных услуг;
ОГВ - органы государственной власти;
ОМСУ - органы местного самоуправления;
ПГУ - Единый портал государственных и муниципальных услуг
(функций);
РОИВ - региональные органы исполнительной власти;
СИА - Система идентификации и аутентификации;
СКЗ - средства криптографической защиты информации;
СУБД - система управления базами данных;
УЦ - удостоверяющий центр;
ФОИВ - федеральные органы исполнительной власти;
ФСБ - Федеральная служба безопасности Российской Федерации;
ФСТЭК - Федеральная служба по техническому и экспортному
контролю;
ЭЦП - электронная цифровая подпись;
HTML - Hypertext Markup Language – язык гипертекстовой
разметки;
HTTP - Hypertext Тransfer Рrotocol – протокол передачи
гипертекста;
IETF - Internet Engineering Task Force – инженерная группа
проектировщиков информационно-телекоммуникационной
сети Интернет;
IP - Internet Protocol – интернет-протокол;
LDAP - Lightweight Directory Access Protocol – облегченный
протокол доступа к каталогам;
OASIS - Organization for the Advancement of Structured Information
Standards – организация по развитию стандартов
структурированной информации;
OGC - Open GIS Consortium – открытый консорциум
геоинформационных систем;
RDF - Resource Description Framework – среда описания ресурсов;

5. RFC - Request for Comments – запрос на комментарии;
SOAP - Simple Object Access Protocol – простой протокол обмена
структурированными сообщениями;
SSL - Secure Socket Layer – протокол защищенных соединений;
TCP - Transmission Control Protocol – протокол управления
передачей;
TLS - Transport Layer Security – безопасность транспортного
уровня;
UDDI - Universal Description Discovery and Integration –
универсальное описание, обнаружение и интеграция;
UML - Unified Modelling Language – унифицированный язык
моделирования;
URI - Uniform Resource Identifier – унифицированный
идентификатор ресурса;
URL - Uniform Resource Locator – унифицированный локатор
ресурса;
URN - Uniform Resource Name – унифицированное имя ресурса;
W3C - World Wide Web Consortium – Консорциум Всемирной
паутины;
WSDL - Web Services Description Language – язык описания
электронных сервисов;
WS-I - Web Services Interoperability Organisation – организация по
интероперабельности электронных сервисов;
XML - Extensible Markup Language – расширяемый язык разметки;
XSL - Extensible Stylesheet Language – расширяемый язык таблиц
стилей.
1.4. В настоящих Требованиях используются следующие термины с
соответствующими определениями:
интероперабельность – способность программных, информационных
или аппаратных ресурсов допускать совместное их использование с другими
заранее неизвестными при их создании ресурсами.
интерфейс - документированный способ доступа к информационной
системе;
информационно-коммуникационная инфраструктура – совокупность
информационных систем общего назначения, сетей, каналов связи, средств
коммутации и управления информационными потоками, средств доступа, а
также организационных структур, обеспечивающих их функционирование;
метаданные – информация о данных – их составе и структуре,
содержании, формате представления, методах доступа и требуемых для этого
полномочиях пользователей, о месте хранения, источнике, владельце и т.п;
метаобъект – структурированное описание свойств некоторого типа
объектов, используемого в информационной системе;
метаобъект системы взаимодействия – структурированное описание
свойств типа объектов, используемого в информационной системе для
обмена информацией между различными информационными системами;

6. репозиторий метаданных системы взаимодействия – компонент системы
взаимодействия, предназначенный для ведения и предоставления
метаобъектов системы взаимодействия в интересах участников
информационного взаимодействия, поддерживаемого системой
взаимодействия;
электронная служба – средство предоставления регламентированного
доступа к информационной системе, подключенной к системе
взаимодействия, с различными целями (получение информации, передача
информации, совершение различных действий и пр.).
электронное сообщение системы взаимодействия – имеющее
определенную структуру и формат электронное сообщение, с помощью
которого организуется функционирование системы взаимодействия (далее -
электронное сообщение).
Иные термины, используемые в настоящих Требованиях, применяются в
тех же значениях, в каких они определены в иных нормативных правовых
актах Российской Федерации.
1.5. Участниками информационного взаимодействия,
поддерживаемого системой взаимодействия, (далее – участники
взаимодействия) являются:
поставщик – оператор информационной системы, предоставляющий
электронные службы для обеспечения функционирования электронных
сервисов в соответствии с настоящими Требованиями;
потребитель – оператор информационной системы, получивший право
использования электронного сервиса в соответствии с настоящими
Требованиями;
оператор системы взаимодействия – Министерство связи и массовых
коммуникаций Российской Федерации.
При наличии необходимости и в получении, и в предоставлении
сведений с использованием системы взаимодействия органы и организации
при подключении к системе взаимодействия могут исполнять одновременно
функции поставщика и потребителя.
Оператор системы взаимодействия вправе в установленном порядке
привлекать организации в целях осуществления деятельности по
обеспечению работоспособности системы взаимодействия в ходе ее
эксплуатации, в том числе в части обеспечения соблюдения настоящих
Требований.
2. Требования к информационным системам,
подключаемым к системе взаимодействия
Требования к разработке и использованию интерфейсов
2.1. Интерфейс информационной системы, подключаемой к системе
взаимодействия, должен быть реализован в виде электронного сервиса.

7. 2.2. Программно-аппаратные средства обеспечения защищённой
интеграции информационных систем с системой взаимодействия должны
обеспечивать выполнение требований настоящих Требований.
Применяемые при разработке и использовании интерфейсов
технологии, стандарты и спецификации должны соответствовать
государственным стандартам Российской Федерации, иным нормативно
установленным и общепризнанным стандартам и требованиям в области
информационных технологий и программного обеспечения.
Требования к протоколам сетевого взаимодействия
2.3. При использовании сетевых протоколов передачи данных
необходимо придерживаться следующих спецификаций:
протокол передачи гипертекста HTTP v. 1.1 – стандарт RFC 2616
инженерной группы проектировщиков информационно-
телекоммуникационной сети Интернет (Internet Engineering Task Force,
IETF);
модернизированный протокол http v. 1.1 с обеспечением безопасности
транспортного уровня (TLS) для существующего протокола управления
передачей (TCP);
протокол защищённых соединений SSL v. 3 / TLS – стандарт RFC 5246
инженерной группы проектировщиков информационно-
телекоммуникационной сети Интернет (Internet Engineering Task Force,
IETF);
Набор протоколов IP Security для обеспечения защиты данных –
стандарты RFC 4301, 4302, 4835, 2403, 2404, 2405, 4303, 4835, 5996, 2410,
2411, 2412 инженерной группы проектировщиков информационно-
телекоммуникационной сети Интернет (Internet Engineering Task Force,
IETF);
сервисы поддержки пространства имен DNS (Domain Name Services) –
стандарт RFC 1035 инженерной группы проектировщиков информационно-
телекоммуникационной сети Интернет (Internet Engineering Task Force, IETF).
Требования к протоколам электронных сервисов
2.4. При разработке электронных сервисов необходимо
придерживаться следующих спецификаций:
базовый профиль интероперабельности v. 1.1 – стандарт Организации
по интероперабельности электронных сервисов (Web Services Interoperability
Organization Basic Profile 1.1, http://www.ws-i.org/Profiles/BasicProfile-1.1-
2006-04-10.html) – спецификация носит обязательный характер;
профиль передачи электронными сервисами бинарных приложений
(WS-I Attachments Profile 1.0) – стандарт Организации по
интероперабельности электронных сервисов WS-I (http://www.ws-
i.org/Profiles/SimpleSoapBindingProfile-1.0.html http://www.ws-

8. i.org/Profiles/AttachmentsProfile-1.0.html) – спецификация носит
рекомендательный характер;
профиль передачи электронными сервисами бинарных приложений
(SOAP Message Transmission Optimization Mechanism) – стандарт
консорциума W3C (http://www.w3.org/TR/soap12-mtom/) – спецификация
носит рекомендательный характер;
профиль связывания электронных сервисов (WS-I Simple SOAP Binding
Profile 1.0) – стандарт организации по интероперабельности электронных
сервисов WS-I (http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html,
http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html) –
спецификация носит рекомендательный характер;
протокол SOAP 1.1 – стандарт консорциума W3C
(http://www.w3.org/TR/soap/) – спецификация носит обязательный характер;
язык описания электронных сервисов (Web Services Description
Language, WSDL 1.1) – стандарт консорциума W3C (http://www.ws-
i.org/Profiles/SimpleSoapBindingProfile-1.0.html, http://www.w3.org/TR/wsdl) –
спецификация носит обязательный характер;
политика использования электронных сервисов (Web Services Policy
1.2) – проект рекомендации консорциума W3C (http://www.ws-
i.org/Profiles/SimpleSoapBindingProfile-
1.0.htmlhttp://www.w3.org/Submission/WS-Policy/) – спецификация носит
рекомендательный характер;
спецификация универсального описания, обнаружения и интеграции
электронных сервисов UDDI v. 3.0 (Universal Description Discovery and
Integration) – стандарт Организации по развитию стандартов
структурированной информации (Organization for the Advancement of
Structured Information Standards, OASIS, http://www.uddi.org/specification.htm)
– спецификация носит рекомендательный характер;
спецификация универсального описания, обнаружения и интеграции
электронных сервисов UDDI v. 2.0 (Universal Description Discovery and
Integration) – стандарт Организации по развитию стандартов
структурированной информации (Organization for the Advancement of
Structured Information Standards, OASIS, http://www.uddi.org/specification.htm)
– спецификация носит рекомендательный характер.
2.5. При описании данных, метаданных и используемых наборов
символов, применяемых в процессе информационного обмена, необходимо
придерживаться следующих спецификаций:
расширяемый язык разметки XML (Extensible Markup Language) – в
соответствии с набором стандартов консорциума W3C
(http://www.w3.org/XML);
XML-схема (XML Schema 1.1, также допускается использование XML
Schema 1.0) – стандарты консорциума W3C, специфицированные в
документах:
XML-схемы Часть 1: Структуры (http://www.w3.org/TR/xmlschema-
1/structures),

9. XML-схемы Часть 2: Типы данных (http://www.w3.org/TR/xmlschema-
2/datatypes);
расширяемый язык таблиц стилей XSL v. 1.1 (Extensible Stylesheet
Language) – стандарт консорциума W3C (http://www.w3.org/TR/xsl)
определяющий XSL-преобразование (XSL Transformation) спецификацией
(http://www.w3.org/TR/xslt).
Особые условия и ограничения при разработке электронных сервисов
2.6. При разработке электронных сервисов должны быть соблюдены
следующие особые условия и ограничения:
согласно спецификации WS-I Basic Profile 1.1 все WSDL и XSD файлы
должны быть кодированы в кодировке UTF-8 или UTF-16 (с указанием этой
кодировки в заголовке XML);
в WSDL описании электронного сервиса запрещены двунаправленные
циклические ссылки из файла WSDL(1) на файл WSDL(2), если
одновременно при этом файл WSDL(2) содержит ссылку на файл WSDL(1),
несмотря на то, что спецификация WSDL 1.1 это допускает.
Однонаправленные ссылки между файлами WSDL и XSD допустимы в
любом количестве и сочетании;
электронный сервис считается доступным только при одновременной
доступности и точки доступа (endpoint) электронного сервиса и WSDL-
писания электронного сервиса. Если не доступна точка доступа (endpoint)
электронного сервиса, не должно быть доступно и WSDL-описание
электронного сервиса, и, наоборот, если недоступно WSDL-описание
электронного сервиса, то не должна быть доступна точка доступа (endpoint)
электронного сервиса. Доступность электронного сервиса обеспечивает
Поставщик электронного сервиса.
Требования к обработке сообщений интерфейсом
информационной системы, подключенной к системе взаимодействия
2.7. Входящие электронные сообщения, полученные по каналам связи
системы взаимодействия, проходят контроль в следующем порядке:
проверка ЭЦП электронного сообщения;
формально-логическая проверка электронного сообщения.
2.8. Проверка ЭЦП электронного сообщения осуществляется
информационной системой, подключенной к системе взаимодействия, через
подсистему проверки ЭЦП с использованием соответствующего
удостоверяющего центра.
2.9. Электронные сообщения, ЭЦП для которых подтверждена,
подвергаются формально-логической проверке значений реквизитов
электронного сообщения.
2.10. В случае непрохождения формально-логической проверки,
электронное сообщение исключается из дальнейшей обработки, данный

10. факт фиксируется и по каналам связи системы взаимодействия отправителю
направляется служебное электронное сообщение, извещающее об отказе в
приеме электронного сообщения.
2.11. В случае прохождения формально-логической проверки
электронного сообщения, по каналам связи системы взаимодействия
отправителю направляется служебное электронное сообщение, извещающее
об успешном приеме электронного сообщения информационной системы,
подключенной к системе взаимодействия.
2.12. Если принятое и успешно прошедшее процедуры контроля
электронное сообщение является сообщением запроса на предоставление
электронной услуги, то ИС Поставщика разрешает использование данного
электронного сервиса.
2.13. Если принятое и успешно прошедшее процедуры контроля
электронное сообщение является извещением о готовности данных, то ИС
Получателя при необходимости инициирует сервис запроса этих данных.
Требования к структуре электронных сообщений
2.14. Требования к общей структуре SOAP-сообщения:
soap:header (заголовок электронного сообщения системы
взаимодействия);
soap:body (тело электронного сообщения системы взаимодействия);
soap:Fault (сообщение об ошибке).
2.15. Заголовок электронного сообщения системы взаимодействия
включает в том числе:
передачу сведений об аутентификации и авторизации (WS-security),
передачу параметров при асинхронном взаимодействии (WS-
Addressing).
2.16. Тело электронного сообщения системы взаимодействия в общем
случае состоит из следующих элементов:
блок данных;
блок присоединенных документов;
блока ЭЦП.
2.17. Блок данных электронного сообщения должен содержать дату и
время отправки электронного сообщения в систему взаимодействия.
2.18. Блок присоединенных документов может содержать информацию
(текстовую, графическую и пр.), прилагаемую к электронному сообщению
системы взаимодействия.
2.19. Блок ЭЦП должен содержать набор ЭЦП ИС Поставщиков, для
входящих по отношению к системе взаимодействия электронных сообщений,
или набор ЭЦП ИС Поставщиков и самой системы взаимодействия, для
исходящих по отношению к системе взаимодействия электронных
сообщений.
2.20. Сообщение об ошибке содержит текстовое описание возникшей
ошибки и ее код в рамках ИС, в рамках которой она возникла.

11. 2.21. Ответственность за содержание реквизитов электронного
сообщения несет участник взаимодействия, отправивший данное
электронное сообщение, если иное не предусмотрено настоящими
Требованиями, иными правовыми актами Российской Федерации.
2.22. Отвественность за легитимность использования ЭЦП несет
участник взаимодействия, отправивший электронное сообщение
Требования к документированию элементов метаданных
2.23. Все элементы метаданных в XML-схеме должны быть
документированы на русском языке.
2.24. Документирование элементов метаданных рекомендуется
выполнять с использованием конструкции XML Schema:
<xsd:annotation>
<xsd:documentation>Текст описания</xsd:documentation>
</xsd:annotation>
Синтаксическую конструкцию XML Schema <!-- текст комментария -->
рекомендуется применять только в качестве вспомогательных комментариев
к XML схеме, если это необходимо, и не использовать для документирования
элементов метаданных.
Требования к наименованию элементов метаданных
2.25. При формировании наименования элементов метаданных
рекомендуется осуществлять подбор слова или словосочетания из
английского языка, соответствующего тому или иному используемому
понятию.
2.26. Наименования, обозначающие общепринятые аббревиатуры,
подлежат транслитерации на латиницу.
В исключительных случаях, если в английском языке отсутствует
слово или словосочетание, достаточно однозначно определяющее
описываемое понятие или допускающее большое количество вариантов
обратного перевода, допустимо использовать транслитерацию на латинский
алфавит, производимую согласно ГОСТ 7.79-2000 (ИСО 9-95) «Правила
транслитерации кирилловского письма латинским алфавитом».
2.27. Все слова в наименовании элемента метаданных рекомендуется
использовать полностью, без сокращений.
Порядок записи слов в наименовании, в которых используется два или
более слова, должен соответствовать правилам английского языка. Слова
должны записываться подряд, без пробела и других знаков между ними.
2.28. Наименования метаданных должны записываться строчными
буквами, кроме аббревиатур, записываемых полностью прописными
(заглавными) буквами. Если используется два или более слова, то каждое
последующее слово кроме первого должно начинаться с прописной
(заглавной) буквы.

12. По согласованию с Оператором системы взаимодействия допускается
использование в качестве первого (а также единственного) слова с прописной
(заглавной) буквы.
2.29. В наименования простых и составных типов (simpleType,
complexType) для обозначения их отличия от элементов (element),
рекомендуется добавлять суффикс «Type».
2.30. По согласованию с Оператором системы взаимодействия при
наименовании элементов метаданных допускается использование
кириллицы.
2.31 Согласование, указанное в пунктах 2.28 и 2.30 настоящих
Требований, осуществляется путем включения соответствующих положений
в Регламенты предоставления и использования электронных сервисов,
подписываемые участниками взаимодействия в порядке, установленном
разделом 5 настоящих Требований.
Требования к контрольному примеру обращения к электронного сервису
2.31. Под контрольным примером обращения к электронному сервису
понимается пример обращения к электронному сервису и ответа
электронного сервиса на указанное обращение. Контрольный пример
обращения и ответа должен быть предоставлен поставщиком в формате
SOAP.
2.32. Назначением контрольного примера является подтверждение
работоспособности электронного сервиса при проведении процедуры
регистрации, в рамках которой осуществляется отправка электронному
сервису запроса, приведенного в контрольном примере, и сравнение
полученного ответа электронного сервиса с ответом, приведенном в
контрольном примере.
2.33. Контрольный пример не должен вызывать выполнение каких-
либо операций в информационной системе поставщика, которые могут
привести к возникновению событий, позволяющих информационной системе
участника взаимодействия или работникам участника взаимодействия
интерпретировать полученные при выполнении контрольного примера
данные как реальные, а не тестовые.
2.34. Регистрация электронного сервиса информационной системы
поставщика и/или потребителя может считаться завершенной только при
условии успешного выполнения контрольного примера, которое
предполагает совпадение ответа электронного сервиса с ответом,
приведенным в контрольном примере, либо, при объективной
невозможности возврата электронным сервисом повторяемых данных, – его
соответствие описанию логики формирования ответа, которое в подобных
случаях должно сопровождать предоставляемый контрольный пример (к
примеру, электронный сервис возвращает номер зарегистрированного
обращения, который не может повторяться, - в этом случае контрольный
пример сопровождается указанием этого факта).

13. 2.35. В дальнейшем контрольный пример может быть использован для
настройки модуля системы взаимодействия, обеспечивающего проверку
доступности и работоспособности электронного сервиса, а так же для
отладки программного кода разработчиками Потребителя электронного
сервиса.
Требования к системе гарантированной доставки сообщений на стороне всех
участников взаимодействия
2.36. Интерфейс информационной системы участника взаимодействия
должен обеспечивать гарантированную доставку неискаженных сообщений в
рамках информационного обмена между информационной системой данного
участника взаимодействия и системой взаимодействия в установленные
(регламентированные) сроки.
2.37. Интерфейс системы взаимодействия должен обеспечивать
гарантированную доставку неискажённых сообщений с унифицированным
интервалом времени ожидания ответа на запрос всеми участниками
взаимодействия.
2.38. Каждый из участников взаимодействия должен иметь систему
гарантированной доставки.
Требования к условиям хранения данных, передаваемых через систему
взаимодействия
2.39. Система взаимодействия обеспечивает фиксацию и хранение
сведений об истории движения в системе взаимодействия электронных
сообщений при предоставлении государственных и муниципальных услуг,
исполнении государственных и муниципальных функций в электронной
форме (далее – сведения об истории движения электронных сообщений), а
также ведение журнала обращений Потребителей к электронным сервисам
системы взаимодействия и электронным сервисам Поставщиков.
2.40. Хранение сведений об истории движения электронных сообщений
осуществляется в специально созданной для данного хранения подсистеме
системы взаимодействия.
Требования к использованию нормативно-справочной информации
2.41. Информационная система, подключаемая к системе
взаимодействия, должна использовать общероссийские классификаторы
технико-экономической и социальной информации.
2.42. При использовании в информационных системах ведомственных
справочников и классификаторов, ведомство (организация), ответственная за
информационную систему должна обеспечить ведение справочников,

14. классификаторов и доступ к ним посредством электронного сервиса,
подключаемого к системе взаимодействия.
3. Требования к подключению к системе взаимодействия
региональных систем взаимодействия
3.43. В целях обеспечения возможности подключения к системе
взаимодействия региональная система взаимодействия должна быть
построена на основе открытой сервис – ориентированной архитектуры,
включать средства поддержки аппаратной и территориальной
масштабируемости, а также соответствовать иным критериям, изложенным в
настоящем разделе.
3.44. Для организации межведомственного электронного
взаимодействия в субъекте Российской Федерации должна быть обеспечена
возможность подключения к региональной системе взаимодействия
информационных систем территориальных органов федеральных органов
исполнительной власти, исполнительных органов государственной власти
субъектов Российской Федерации, органов местного самоуправления,
государственных и муниципальных учреждений, многофункциональных
центров, иных органов и организаций, используемых при предоставлении
государственных и муниципальных услуг и исполнении государственных и
муниципальных функций в электронной форме, с использованием
защищенных каналов связи.
3.45. Соответствующие электронные сервисы подключенных к
региональной системе взаимодействия информационных систем должны
быть зарегистрированы в реестре электронных сервисов информационных
систем органов и организаций, подключенных к региональной системе
взаимодействия.
3.46. Доступ к электронным сервисам информационных систем,
подключенным к региональной системе взаимодействия, должен
предоставляться в соответствии с правами доступа, определенными
Поставщиками данных электронных сервисов.
3.47. При создании региональной системы взаимодействия должна
быть обеспечена отказоустойчивость, в том числе за счет распределения
нагрузки и резервирования мощностей.
3.48. Региональная система взаимодействия должна обеспечивать
гарантированную доставку неискаженных сообщений от отправителя к
получателю в установленные (регламентированные) сроки.
3.49. Региональная система взаимодействия должна удовлетворять
требованиям по защите информации при передаче персональных данных,
предусмотренных законодательством Российской Федерации и доступности
3.50. Работоспособность региональной системы взаимодействия
должна автоматически восстанавливаться при перезапуске программно-
аппаратных средств. Должно быть обеспечено восстановление программного

15. обеспечения серверов в случае сбоя работы оборудования в установленные
интервалы времени.
3.51. При организации обеспечения сохранности информации в
региональной системе взаимодействия необходимо руководствоваться
положениями Постановления Правительства РФ от 18.05.2009 г. № 424 «Об
особенностях подключения федеральных государственных информационных
систем к информационно-телекоммуникационным сетям», Приказа
Министерства связи и массовых коммуникаций РФ от 25.07.2009 г. № 104
«Об утверждении Требований по обеспечению целостности, устойчивости
функционирования и безопасности информационных систем общего
пользования».
При этом должны поддерживаться следующие функции:
резервное копирование баз данных, программных файлов;
восстановление данных в непротиворечивое состояние при
программно-аппаратных сбоях (отключение электрического питания, сбоях
операционной системы и т.д.) вычислительно-операционной среды
функционирования;
восстановление данных в непротиворечивое состояние при сбоях в
работе сетевого программного и аппаратного обеспечения.
3.52. Региональная система взаимодействия должна быть устойчива по
отношению к программно-аппаратным ошибкам, отказам технических и
программных средств, с возможностью восстановления ее
работоспособности и целостности информационного содержимого при
возникновении ошибок и отказов.
3.53. Надежность региональной системы взаимодействия должна
обеспечиваться следующими показателями:
надежностью системы электропитания;
организацией дисковых массивов серверов технологии RAID;
использования кластеризации и резервирования аппаратных
компонентов системы взаимодействия;
наличием и использованием узлов с возможностью «горячей» замены
на критичных серверах (вентиляторы, блоки питания, накопители на жестких
дисках).
3.54. Региональная система взаимодействия и ее компоненты должны
работать под управлением многопользовательской и многозадачной
операционной системы.
3.55. Для обеспечения требуемого уровня надежности системы
взаимодействия оборудование должно соответствовать следующим
требованиям:
удовлетворять минимальным требованиям используемой
операционной системы;
обеспечивать требуемые СУБД характеристики к аппаратной
платформе с учетом объема обрабатываемых данных;
удовлетворять требованиям, предъявляемым к защите и целостности
информации.

16. 3.56. Срок гарантийного обслуживания региональной системы
взаимодействия должен составлять не менее одного года с момента ввода ее
в промышленную эксплуатацию.
3.57. Сохранность информации в региональной системе
взаимодействия должна обеспечиваться:
при пожарах, затоплениях, землетрясениях и других стихийных
бедствиях - организационными и защитными мерами, опирающимися на
подготовленность помещений и персонала, обеспечивающими сохранность
хранимых копий информации на магнитных носителях;
при разрушениях данных при механических и электронных сбоях и
отказах в работе компьютеров - на основе программных процедур
восстановления информации с использованием хранимых копий баз данных,
программных файлов, а также загружаемых файлов;
при сбое в электропитании - организационными и защитными мерами,
опирающимися на подготовленность резервного питания для поддержания
нормального функционирования системы в течение времени, необходимого
для устранения сбоя в электропитании или для нормального ручного
завершения работы системы;
при сбое из-за ошибок в работе персонала - организационными и
защитными мерами, опирающимися на подготовленность персонала.
3.58. Оператор региональной системы взаимодействия должен в
установленном порядке разработать и согласовать модель угроз и модель
нарушителя региональной системы взаимодействия. На основе указанных
моделей должна быть разработана политика безопасности, определяющая
меры и средства, используемые при защите от несанкционированного
доступа.
3.59. Региональная система взаимодействия должна обеспечивать
защиту от несанкционированного доступа на основе положений принятой
политики безопасности, включая следующие меры:
доступ в администраторский интерфейс должен происходить только по
индивидуальному логину и паролю;
должен вестись журнал всех действий администратора в
администраторском интерфейсе;
система должна иметь возможность блокировки доступа
администратора в администраторский интерфейс;
система должна вести журнал всех аутентификаций.
3.60. В случае реализации интерфейса администратора региональной
системы взаимодействия как – интерфейса с доступом из информационно-
коммуникационной сети Интернет защита от несанкционированного доступа
со стороны пользователей сети информационно-телекоммуникационной сети
Интернет к данному интерфейсу должна обеспечиваться следующим
комплексом мер:
ограничение доступа к администраторскому интерфейсу только с
определенных IP адресов;

17. доступ к администраторскому интерфейсу должен производиться по
протоколу HTTPS.
3.62. Региональная система взаимодействия должна иметь возможность
функционировать в следующих режимах:
штатный режим;
режим системного администрирования.
Штатный режим должен являться основным режимом
функционирования, обеспечивающим выполнение задач региональной
системы взаимодействия.
Режим системного администрирования должен являться
технологическим режимом и использоваться для сопровождения
региональной системы взаимодействия, в том числе изменения
конфигурации, параметров работы, настроек, выполнения регламентного
обслуживания программно-технических средств.
В режиме системного администрирования должны выполняться
функции, связанные с реконфигурацией, конвертированием и
архивированием баз данных. После возникновения отказа в каком-либо из
компонентов системы, режим должен обеспечивать перевод отказавших
компонентов в штатный режим функционирования после идентификации
возникшего отказа и устранения его причин.
3.63. Региональная система взаимодействия должна обеспечивать
хранение информации о доступных электронных сервисах и интерфейсах
подключенных к ней информационных систем.
3.64. Для реализации возможности осуществления повторных вызовов
электронных сервисов при сбоях необходимо обеспечить возможность:
настройки количества повторных вызовов до формирования сообщения
о сбое;
настройки временного интервала, в течение которого осуществляются
повторные вызовы.
3.65. Должна быть реализована возможность оповещения оператора
системы взаимодействия о сбоях системы по электронной почте,
позволяющая:
задавать адреса электронной почты администраторов с учетом
распределенной архитектуры системы взаимодействия с привязкой к местам
размещения компонентов региональной системы взаимодействия и
системных администраторов;
задавать интервал времени, за который собираются сообщения от
компонента повторных вызовов –электронных сервисов о возникших сбоях
или их устранении;
формировать пакет уникальных сообщений за заданный интервал
времени для каждого администратора, исключающий повторные сообщения
об одном и том же сбое или устранении сбоя, и его отправку адресату. Пакет
уникальных сообщений должен включать сообщения о сбоях/устранении во
всех компонентах региональной системы взаимодействия, за которые
отвечает данный администратор.

18. 3.66. Региональная система взаимодействия должна обеспечивать
фиксацию и возможность предоставления в систему взаимодействия
сведений об истории движения электронных сообщений, включая:
наименование запрошенного сервиса;
дату и время обращения;
дату и время ответа;
данные по запросам ИС, включая наименование ИС; дату и время
получения ответа от ИС; тип ответа; информацию о возникновении ошибок.
3.68. Для обеспечения поддержки функциональности по мониторингу
хода предоставления государственной или муниципальной услуги, а также
для обеспечения расширения функциональности по взаимодействию
информационных систем участников взаимодействия в системе
взаимодействия должен быть реализован универсальный механизм
регистрации и управления событиями.
3.69. Региональная система взаимодействия должна реализовывать
универсальный механизм, позволяющий обрабатывать события в
информационных системах, подключенных к системе взаимодействия и
внутренние события системы взаимодействия и обеспечивать передачу
информации о событии всем заинтересованным участникам взаимодействия.
3.70. Региональная система взаимодействия должна реализовывать
универсальный (не зависящий от вида события) электронный сервис,
обеспечивающий размещение экземпляра события в очереди событий,
поддерживаемой региональной системой взаимодействия.
3.71. Региональная система взаимодействия должна обеспечивать
универсальный (не зависящий от вида события) электронный сервис,
обеспечивающий формирование подписки на событие, зарегистрированное в
списке событий.
3.72. Региональная система взаимодействия должна осуществлять
протоколирование (журналирование) всех уведомлений о возникновении
событий и всех фактов рассылки.
4. Порядок подключения информационных систем
к системе взаимодействия
4.1. Для подключения информационной системы к системе
взаимодействия ее владелец или оператор:
заключают соглашение в соответствии с пунктом 14 Положения (далее
– Соглашение);
обеспечивают защищенный канал связи между своей информационной
системой и системой взаимодействия;
разрабатывают интерфейсы взаимодействия с системой
взаимодействия в соответствии с настоящими Требованиями;
регистрируют электронный сервис информационной системы в реестре
электронных сервисов информационных систем органов и организаций,
подключенных к системе взаимодействия (далее - реестр электронных

19. сервисов)в соответствии с правилам, изложенными в Регламенте разработки
и использования электронных сервисов системы взаимодействия
(Приложение 1 к настоящим Требованиям).
4.2. Оператор системы взаимодействия осуществляет приемку
электронного сервиса, в процессе которой осуществляется:
проверка представленной документации;
проверка соответствия разработанного электронного сервиса
настоящим Требованиям,
тестирование электронного сервиса на контрольном примере в
соответствии с представленной методикой испытаний.
В случае если электронный сервис не проходит проверку, он
возвращается на доработку Поставщику.
В случае соответствия электронного сервиса условиям, указанным в
настоящих Требованиях, Оператор системы взаимодействия регистрирует
его в реестре электронных сервисов.
4.3. Кроме процедуры регистрации электронного сервиса
информационной системы поставщикам и потребителям доступны
следующие процедуры в соответствии с правилами, установленными
Регламентом разработки и использования электронных сервисов системы
взаимодействия согласно Приложение № 1:
процедура изменения электронного сервиса системы взаимодействия;
процедура исключения электронного сервиса из системы
взаимодействия;
поиск и обнаружение необходимого электронного сервиса в системе
взаимодействия;
автоматическая процедура межсистемного электронного
взаимодействия. В процедуре участвуют информационные системы
Поставщика, Потребителя и системы взаимодействия;
процедура мониторинга состояния и использования электронных
сервисов системы взаимодействия.
5. Порядок информационного обмена в системе взаимодействия
5.1. Информационное взаимодействие осуществляется между
Поставщиками и Потребителями через систему взаимодействия с
использованием механизмов взаимной двухфакторной криптографической
аутентификации с использованием сертифицированных средств.
5.2. Мониторинг информационного взаимодействия информационных
систем осуществляется средствами системы взаимодействия.
5.3. Электронные сервисы, используемые для взаимодействия
информационных систем, подлежат регистрации в системе взаимодействия.
5.4. В системе взаимодействия подлежат регистрации электронные
сервисы, обеспечивающие:
межведомственное взаимодействие;

20. взаимодействие между системой взаимодействия (федеральный
уровень) и региональной системой взаимодействия (региональный уровень).
5.5.Порядок эксплуатации системы взаимодействия определяется
Регламентом разработки и использования электронных сервисов системы
взаимодействия, являющимся Приложением №1 к настоящим Требованиям.
5.6. Контроль исполнения технических регламентов системы
взаимодействия осуществляет Оператор системы взаимодействия.
5.7. Конкретный перечень электронных сервисов, которые Поставщик
предоставляет в систему взаимодействия, и порядок их предоставления
может определяться Регламентом предоставления электронных сервисов,
подписываемого Поставщиком и Оператором системы взаимодействия в
рамках заключения Соглашения.
5.8. В Регламенте предоставления электронных сервисов указываются:
а) перечень предоставляемых Поставщиком электронных сервисов;
б) условия предоставления электронных сервисов, включающие:
технические параметры функционирования данных электронных
сервисов;
способы контроля технических параметров электронных сервисов для
каждого из таких параметров;
требования к обеспечению информационной безопасности при
использовании электронных сервисов: способы аутентификации, сетевые
настройки, шифрование и др.
в) требования к объектам информационного взаимодействия,
включающие:
перечень информационных систем, на базе которых функционируют
электронные сервисы – полное и краткое наименование, назначение;
перечень предоставляемой информации в разрезе каждой
информационной системы и краткое описание данной информации;
форматы передаваемых данных (pdf, xml, doc, xls, jpg и др.). При
передаче структурированных данных описывается их структура.
г) требования к субъектам информационного взаимодействия,
включающие специфические технические требования, которые должны быть
выполнены:
Оператором системы взаимодействия для осуществления
взаимодействия (наличие аппаратного, программного обеспечения и др.);
Поставщиком, для осуществления взаимодействия;
Потребителем;
д) правила предоставления доступа органов и организаций к
электронным сервисам. Правила доступа могут быть сформулированы
несколькими способами, например:
указан фиксированный перечень Потребителей;
указана ссылка на документ, в котором приведен список возможных
Потребителей;
сформулированы критерии, при выполнении которых Потребитель
имеет право доступа к электронному сервису;

21. указано, что электронный сервис является общедоступным;
иные способы.
В период действия Соглашения регламентов предоставления
электронных сервисов может быть несколько и они могут изменяться при
модернизации электронных сервисов в соответствии с правилами системы
взаимодействия (Приложение №1 к настоящим Требованиям).
5.9. Потребитель автоматически получает доступ к электронным
сервисам информационных систем поставщиков, для которых не
установлены ограничения по доступу в момент подписания Соглашения.
5.10. При необходимости использования электронных сервисов,
имеющих ограничения по доступу, а также композитных электронных
сервисов, между Потребителем и Оператором системы взаимодействия
подписывается Регламент использования электронных сервисов.
В Регламенте использования электронных сервисов указывается
перечень используемых электронных сервисов, сведения, перечисленные в
подпунктах «б»-«г», а также в случае композитного электронного сервиса,
алгоритм сбора и преобразования данных.
5.11. При подписании Регламента использования электронных
сервисов Оператор системы взаимодействия в обязательном порядке
проверяет основания Потребителя для получения доступа к интересующим
электронным сервисам Поставщиков, сверяя их с условиями соглашений с
соответствующими Поставщиками.
5.12. Во всех случаях Потребитель получает оговоренную информацию
на условиях Соглашения и Регламентов, Поставщик предоставляет
информацию на условиях Соглашения и Регламентов, а Оператор системы
взаимодействия обеспечивает техническую возможность передачи
информации и прочие услуги системы взаимодействия, связанные с поиском
электронных сервисов, протоколированием запросов Потребителей и ответов
Поставщиков, обеспечением доступа и преобразованием информации.
5.13. При использовании комплексного электронного сервиса,
преобразующего или компонующего информацию, Регламент использования
электронного сервиса должны содержать раздел, описывающий алгоритм
преобразования данных, который осуществляется внутри системы
взаимодействия.
5.14. Оператор системы взаимодействия ежеквартально анализирует:
статистические данные об использовании электронных сервисов;
перечень зарегистрированных информационных систем и электронные
сервисы за отчетный период;
перечень внесенных изменений в реестр электронных сервисов за
отчетный период;
перечень заключенных Соглашений с Поставщиками и Потребителями;
отчет о работоспособности системы взаимодействия: перечень сбоев с
указанием причины и продолжительности.

22. 6. Требования к использованию электронной цифровой подписи и
взаимодействию с удостоверяющим центром
6.1. Программно-технические средства системы взаимодействия и
региональнойй системы взаимодействия, а также программно-технические
средства, реализующие сервисы, предполагающие использование ЭЦП на
стороне участников взаимодействия, должны обеспечивать выработку и
проверку ЭЦП в соответствующем удостоверяющем центре.
6.2. Для выполнения операций, указанных в пункте 6.1. настоящих
Требований, должны использоваться сертифицированные СКЗИ,
реализующие следующие алгоритмы, установленные государственными
стандартами Российской Федерации:
алгоритм формирования и проверки ЭЦП в соответствии с
требованиями ГОСТ Р 34.10-2001 «Информационная технология.
Криптографическая защита информации. Процессы формирования и
проверки электронной цифровой подписи»;
алгоритм выработки значения хэш-функции в соответствии с
требованиями ГОСТ Р 34.11-94 «Информационная технология.
Криптографическая защита информации. Функция хэширования»;
алгоритм зашифрования/расшифрования данных и вычисления
имитовставки в соответствии с требованиями ГОСТ 28147-89 «Системы
обработки информации. Защита криптографическая. Алгоритм
криптографического преобразования».
6.3. Применяемые для подписания сообщений сертификаты открытых
ключей ЭЦП должны соответствовать международному стандарту X.509 –
версия 3.
6.4. Программно-техническими средствами системы взаимодействия и
региональной системы взаимодействия должна обеспечиваться возможность
проверки ЭЦП в электронных сообщениях системы взаимодействия.
6.5. Проверка ЭЦП электронного сообщения должна проводиться для
всех входящих сообщений, подписанных ЭЦП.
При отрицательном результате проверки отправителю сообщения
должно отправляться уведомление, а результат операции должен
записываться в журнал регистрации событий.
6.6. Программно-техническими средствами системы взаимодействия и
региональной системы взаимодействия должна обеспечиваться возможность
выработки ЭЦП исходящих сообщений в доверенной вычислительной среде
с помощью закрытых ключей ЭЦП должностного лица оператора системы
взаимодействия и (или) региональной системы взаимодействия.
6.7. Все исходящие сообщения, отправляемые участникам
взаимодействия (поставщикам и потребителям) от имени системы
взаимодействия, должны подписываться ЭЦП должностного лица оператора
системы взаимодействия (региональной системы взаимодействия). в
соответствующем удостоверяющем центре.

23. 6.8. Программно-техническими средствами системы взаимодействия и
региональной системы взаимодействия должна обеспечиваться возможность
проверки действительности сертификатов открытых ключей ЭЦП с
использованием списков отозванных сертификатов (CRL – Certificate
Revocation List) и протокола получения статуса сертификата в реальном
времени (OCSP – Online Certificate Status Protocol).
При отрицательном результате проверки действительности
сертификата отправителю сообщения должно отправляться уведомление, а
результат операции должен записываться в журнал регистрации событий.
6.9. Для обеспечения юридической значимости электронных
сообщений в системе взаимодействия участники взаимодействия могут
использовать сертификаты открытых ключей ЭЦП, выпущенные
удостоверяющими центрами, соответствующих требованиям Федерального
закона «Об электронной цифровой подписи», иных правовых актов
Российской Федерации, настоящих Требований.
6.10. Выбор удостоверяющего центра осуществляется участником
взаимодействия.
6.11. Используемые удостоверяющие центры должны обеспечивать
публикацию списков отозванных сертификатов (CRL – Certificate Revocation
List) в информационно-телекоммуникационной сети Интернет Интернет и
обеспечивать их круглосуточную доступность по протоколу HTTP.
6.12. Списки отозванных сертификатов должны соответствовать
международному стандарту X.509 – версия 2.
6.13. Дополнительно к публикуемым спискам отозванных
сертификатов удостоверяющие центры могут использовать протокол
получения статуса сертификата в реальном времени (OCSP – Online
Certificate Status Protocol). В этом случае используемые удостоверяющие
центры должны обеспечить круглосуточную доступность соответствующего
сервиса.
6.14. Программно-техническими средствами системы взаимодействия и
региональной системы взаимодействия должна обеспечиваться возможность
регистрации в системе сертификатов открытых ключей удостоверяющих
центров, используемых участниками взаимодействия для выпуска
сертификатов должностных лиц, осуществляющих выработку ЭЦП для
электронных сообщений системы взаимодействия.
6.15. Программно-техническими средствами системы взаимодействия и
региональной системы взаимодействия должна обеспечиваться возможность
проверки подлинности ЭЦП в электронных сообщениях системы
взаимодействия и построения цепочек сертификатов до зарегистрированных
в системе сертификатов открытых ключей используемых удостоверяющих
центров.
При отрицательном результате проверки действительности
сертификата отправителю сообщения должно отправляться уведомление, а
результат операции должен записываться в журнал регистрации событий.