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

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

1. Настоящие Технические требования к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия (далее — Требования) определяют правила интеграции информационных систем федеральных органов исполнительной власти, государственных внебюджетных фондов, исполнительных органов государственной власти субъектов Российской Федерации, органов местного самоуправления, государственных и муниципальных учреждений, многофункциональных центров, иных органов и организаций (далее — органы и организации), используемых при предоставлении государственных и муниципальных услуг и исполнении государственных и муниципальных функций в электронной форме (далее — информационные системы), с единой системой межведомственного электронного взаимодействия (далее — система взаимодействия), а также требования к техническому обеспечению информационного обмена, осуществляемого с применением системы взаимодействия, между информационными системами в целях предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме.#❝

2. Единый электронный сервис представляет собой программные и технические средства, обеспечивающие единый документированный способ взаимодействия информационных систем органов и организаций при обмене сведениями, необходимыми для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме посредством технологии очередей электронных сообщений, обеспечивающей взаимодействие программ в асинхронном режиме, не требующей установки между ними прямой связи и гарантирующей получение передаваемых электронных сообщений! (далее — Единый электронный сервис).#❝

3. Информационный обмен сведениями осуществляется органами и организациями с использованием Единого электронного сервиса системы взаимодействия.#❝

4. Требования к форматам сведений, представляющим собой структуру передаваемых сведений, устанавливаются органами и организациями, предоставляющими сведения, необходимые в целях предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций (далее — поставщики), в соответствии с настоящими#❝

5. Органы и организации, получающие сведения с использованием Единого электронного сервиса системы взаимодействия (далее — потребитель), инициируют запрос сведений путем обращения к Единому электронному сервису системы взаимодействия.#❝

6. Оператор системы взаимодействия ведет реестр сведений, необходимых для предоставления государственных и муниципальных услуг и выполнения государственных и муниципальных функций в системе взаимодействия (далее - реестр сведений).#❝

7. В рамках информационного взаимодействия информационные системы поставщика и потребителя обмениваются сообщениями. Информационная система, отправляющая сообщение через систему взаимодействия, является отправителем сообщения, а информационная система, получающая сообщение из системы взаимодействия, — получателем.#❝

8. Информационное взаимодействие в системе взаимодействия осуществляется в асинхронном режиме. Передача сообщений через систему взаимодействия осуществляется посредством технологии очередей.#❝

9. Форматы сведений разрабатываются поставщиком с использованием языка описания схем данных XML Schema Definition (XSD).#❝

10. ХМГ-схема или Schematron-cxema, созданные Ha основе Х5О-описания формата сведений, доступны для проверки поставщиком входящего запроса потребителя только в случае, если эти схемы содержатся в реестре сведений.#❝

11. В системе взаимодействия реестр сведений включает одну или несколько версий формата сведений. Каждая версия формата сведений состоит из одной или нескольких ХМГ-схем: одна описывает сведения, передаваемые в сообщении, а остальные, при необходимости, импортируются в неё посредством выполнения директивы «xs:import».#❝

12. При необходимости внесения изменений в формат сведений, в системе взаимодействия необходимо зарегистрировать новую версию ХМГ-схемы. Чтобы обеспечить корректную маршрутизацию сообщений, соответствующих устаревшим версиям форматов сведений, в системе взаимодействия сохраняется полная история всех изменений, включая все предыдущие версии ХМГ-схем. Для каждой новой версии формата сведений ХМГ-схема должна иметь отличающееся от предыдущих версий форматов целевое пространство имен (target namespace).#❝

13. При смене форматов видов сведений оповещение потребителей сведений о смене форматов производится на портале «Технологический портал СМЭВ» в информационно-телекоммуникационной сети#❝

14. В системе взаимодействия используются сообщения следующих типов: запрос, ответ, отмена (запроса). Все сообщения обрабатываются одинаковым образом.#❝

14.1. К сообщениям типа «Запрос» (далее — запрос) относятся сообщения, исходящие от потребителя (кроме сообщений типа «Отмена»).#❝

14.2. Сообщения типа «Ответ» (далее — ответ) могут содержать или запрошенные данные, или мотивированный отказ в приеме запроса к исполнению.#❝

14.3. Результатом сообщения типа «Отмена» (далее — отмена) является удаление сообщения из очереди системы взаимодействия, если запрос не был получен поставщиком. Сообщения типа «Отмена» применимы только к сообщениям типа «Запрос».#❝

15. Сообщения в системе взаимодействия передаются в формате XML в кодировке ОТЕ-8 с указанием кодировки в заголовке сообщения. Сообщения, содержащие WSDL и XSD файлы, должны также использовать кодировку UTF-8 с указанием кодировки в заголовке сообщения.#❝

16. Информационные системы участников взаимодействия в теле сообщений должны поддерживать применение блоков, элементов данных и электронных подписей. Использование отличных от описанных в настоящих требованиях блоков и элементов данных не допускается.#❝

17. В сообщениях, передаваемых через систему взаимодействия, применяются следующие усиленные квалифицированные электронные подписи:#❝

17.1. электронная подпись, формируемая должностным лицом органа власти, участвующего в межведомственном взаимодействии (далее — ЭП-СП);#❝

17.2. электронная подпись, формируемая от имени органа власти, участвующего в межведомственном взаимодействии (далее — ЭП-ОВ);#❝

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

18. ЭП-ОВ и ЭП-СМЭВ включаются в состав сообщения в обязательном порядке. |#❝

20. Структура запроса, который информационная система потребителя передает в систему взаимодействия, включает в себя:#❝

20.1. блок данных запроса;#❝

20.2. блок содержимого вложений;#❝

20.3. ЭП-ОВ.#❝

21. Блок данных запроса включает, в том числе:#❝

21.1. блок структурированных сведений;#❝

21.2. электронную подпись должностного лица;#❝

21.3. блок заголовков вложений и ЭП-СП для вложений;#❝

21.4. блок атрибутов бизнес-процесса.#❝

22. Блок содержимого вложений добавляется, если потребителю необходимо передать в информационную систему поставщика информацию, в том числе неструктурированную, которая не входит в блок структурированных сведений в соответствии с требованиями поставщика. Вложенные файлы и идентификаторы вложений располагаются вне подписанного с помощью ЭП-ОВ блока данных запроса для корректной реализации кодирования вложений с помощью механизма оптимизации передачи сообщений MTOM’.#❝

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

24. Структура запроса, который информационная система поставщика получает из системы взаимодействия, включает в себя:#❝

24.1. блок данных СМЭВ-конверта;#❝

24.2. блок содержимого вложений;#❝

24.3. ЭП-СМЭВ.#❝

25. СМЭВ-конверт представляет собой структурированный набор данных для передачи сообщений в систему взаимодействия, включающих блоки и элементы служебных данных, бизнес данных и электронные подписи.#❝

26. Блок данных СМЭВ-конверта включает в том числе:#❝

26.1. блок данных запроса, сформированный отправителем сообщения;#❝

26.2. ЭП-ОВ, которой подписан блок данных запроса;#❝

26.3. обратный адрес, необходимый для доставки ответа потребителю;#❝

26.4. блок маршрутной информации.#❝

27. Блок содержимого вложений не изменяется при прохождении через систему взаимодействия и соответствует блоку содержимого вложений запроса, который информационная система потребителя передала в систему взаимодействия.#❝

28. С помощью ЭП-СМЭВ:#❝

28.1. подписываются блок данных запроса вместе с ЭП-ОВ и добавленные в систему взаимодействия блок маршрутной информации и обратный адрес;#❝

28.2. обеспечивается целостность запроса на всем пути от отправителя до получателя.#❝

29. Структура ответа, который информационная система поставщика передает в систему взаимодействия, включает в себя:#❝

29.1. блок данных ответа;#❝

29.2. блок содержимого вложений;#❝

29.3. ЭП-ОВ.#❝

30. Блок содержимого вложений может быть добавлен, если поставщику необходимо передать информацию, в том числе неструктурированную, которая не входит в ответ.#❝

31. Ответ подписывается ЭП-ОВ, формируемой от имени органа власти, участвующего в межведомственном взаимодействии и выступающего в роли поставщика сведений. С помощью ЭП-ОВ обеспечивается целостность ответа и идентификация информационной системы отправителя.#❝

32. Структура ответа, который информационная система потребителя получает из системы взаимодействия, включает в себя:#❝

32.1. блок данных СМЭВ-конверта;#❝

32.2. блок содержимого вложений:#❝

32.3. ЭП-СМЭВ.#❝

33. Блок данных СМЭВ-конверта включает в том числе:#❝

33.1. блок данных ответа, сформированный отправителем сообщения;#❝

33.2. ЭП-ОВ, которой подписан блок данных ответа;#❝

33.3. обратный адрес, необходимый для доставки ответа потребителю;#❝

33.4. идентификатор, присвоенный запросу в системе взаимодействия, на который передается ответ; -#❝

33.5. блок маршрутной информации.#❝

34. Блок содержимого вложений в процессе доставки системой взаимодействия не изменяется.#❝

35. С помощью ЭП-СМЭВ обеспечивается целостность ответа на всем пути от отправителя до получателя, подтверждение поступления ответа из системы взаимодействия во время, указанное в метке времени и право на обращение информационной системы потребителя за ответом.#❝

36. Изготовление, выдача ключей электронных подписей и сертификатов ключей проверки электронных подписей участникам информационного взаимодействия осуществляются в соответствии с положениями Федерального закона от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи» (Собрание законодательства Российской Федерации, 2011, № 15, ст. 2036, № 27, ст. 3880;#❝

37. Обмен сообщениями между информационной системой потребителя и информационной системой поставщика осуществляется путем вызова одного или нескольких методов Единого электронного сервиса, предоставляемых системой взаимодействия и представляющих собой операции обмена структурированными сообщениями (далее — метод).#❝

38. Для передачи запроса от информационной системы потребителя к информационной системе поставщика и ответа от информационной системы поставщика к информационной системе потребителя используются следующие методы:#❝

38.1. Послать запрос (SendRequest), служит для передачи запроса от информационной системы потребителя в систему взаимодействия;#❝

38.2. Получить запрос (GetRequest), служит для получения запроса информационной системой поставщика из системы взаимодействия: ‘-#❝

38.3. Подтвердить получение (Ack), служит для подтверждения получения сообщения, вызывается после получения сообщения методами GetRequest или GetResponse; |#❝

38.4. Послать ответ (SendResponse), служит для передачи ответа на запрос от информационной системы поставщика в систему взаимодействия; |#❝

38.5. Получить ответ (GetResponse), служит для получения из системы взаимодействия ответа на запрос от информационной системы потребителя;#❝

38.6. Отмена запроса (CancelRequest), служит для отмены запроса информационной системы поставщика в систему взаимодействия;#❝

38.7. Получение статистики (GetIncomingQueueStatistics), служит для получения статистики по доставке сообщений в систему взаимодействия.#❝

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

40. Запрос передается в систему взаимодействия с помощью метода SendRequest, после чего в системе взаимодействия последовательно выполняются следующие операции:#❝

40.1. форматно-логический контроль (далее - ФЛК) СМЭВ-конверта по схеме XSD. ФЛК представляет собой проверку формата сведений, контроль логики заполнения сведений, осуществляемые путем проверки соответствия этих данных документам на языке XSD и, при необходимости, Schematron;#❝

40.2. проверка ЭП-ОВ на предмет корректности и Ha предмет действительности соответствующих сертификатов ключей подписи. ЭП-ОВ также используется для идентификации потребителя сервиса, приславшего запрос;#❝

40.3. проверка бизнес-данных по схемам XSD и, при наличии, Schematron, разработанным поставщиком сведений (проверяется полное имя корневого структурного элемента формата сведений для идентификации информационной системы поставщика - получателя запроса);#❝

40.4. проверка ЭП-СП;#❝

40.5. помещение запроса в очередь запросов и присвоение сообщению СМЭВ-идентификатора, подтверждающего факт помещения запроса в очередь запросов (автоматически присваивается сиситемой взаимодействия и направляется потребителю).#❝

41. Запрос находится в очереди запросов до момента его получения информационной системой поставщика посредством обращения к системе взаимодействия.#❝

41.1. Для получения запроса информационная система поставщика подготавливает и подписывает ЭП-ОВ сообщение на получение запроса, после чего путем вызова метода GetRequest, передает это сообщение в систему взаимодействия.#❝

41.2. Система взаимодействия по ЭП-ОВ идентифицирует информационную систему поставщика и, при наличии недоставленных запросов, возвращает в информационную систему поставщика очередной запрос, предварительно подписав его ЭП-СМЭВ.#❝

42. Получив из системы взаимодействия запрос, информационная система поставщика проверяет ЭП-СМЭВ и, в случае успешной проверки, сохраняет у себя этот запрос и подтверждает получение запроса путем вызова метода Ack.#❝

43. Информационная система поставщика готовит ответ на полученный запрос и, подписав его ЭП-ОВ, отправляет в систему взаимодействия путем вызова метода SendResponse. Система взаимодействия, получив ответ от информационной системы поставщика, выделяет из него адрес потребителя, определяет по нему очередь сообщений для потребителя и помещает в нее полученный ответ.#❝

44. Информационная система потребителя путем вызова метода GetResponse передает в систему взаимодействия подготовленное и подписанное ЭП-ОВ сообщение для чтения ответов на отправленные запросы. Система взаимодействия по ЭП-ОВ идентифицирует информационную систему потребителя и определяет, к каким очередям этот потребитель имеет доступ. Из соответствующей очереди система взаимодействия выбирает ответ, подписывает его ЭП-СМЭВ и передает в информационную систему потребителя. Информационная система, потребителя при получении ответа проверяет ЭП-СМЭВ, сохраняет этот ответ и подтверждает получение ответа путем вызова метода Ack.#❝

45. Документированный способ доступа к информационной системе (далее - интерфейс), подключаемой к системе взаимодействия, должен быть реализован в виде электронного сервиса.#❝

46. Программно-аппаратные средства обеспечения защищенной интеграции информационных систем с системой взаимодействия должны обеспечивать выполнение настоящих Требований.#❝

47. Применяемые при разработке и использовании интерфейсов технологии, стандарты и спецификации должны соответствовать нормативно установленным и общепринятым стандартам и требованиям в области информационных технологий и программного обеспечения.#❝

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

48.1. протокол передачи гипертекста’ версии 1.1 - комментарий инженерной группы § проектировщиков = информационно-телекоммуникационной — сети#❝

48.3. протокол защищенных соединений” версии 3 - комментарий инженерной группы проектировщиков информационно-телекоммуникационной сети «Интернет» 5246;#❝

48.4. набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу”#❝

48.5. комментарии инженерной группы проектировщиков информационнотелекоммуникационной сети «Интернет» 4301, 4302, 4835, 2403, 2404, 2405, 4303, 4835, 5996, 2410, 2411, 2412;#❝

48.6. протоколы использования системы поддержки пространства имен* -#❝

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

49.1. протокол обмена структурированными сообщениями версии 1.1 - [7 9 > стандарт Консорциума Всемирной сети’ - спецификация носит обязательный#❝

49.2. язык описания электронных сервисов версии 1.1 - стандарт Консорциума Всемирной сети - спецификация носит обязательный характер";#❝

49.4. политика использования электронных сервисов версии 1.2 - проект рекомендации Консорциума Всемирной сети - спецификация носит рекомендательный характер ;#❝

49.5. оптимизированный механизм передачи бинарных данных в структурированных сообщениях - стандарт Консорциума Всемирной сети - спецификация носит рекомендательный характер °;#❝

49.6. профиль сопоставления данных версии 1.0 - стандарт Организации по интероперабельности электронных сервиов - спецификация носит обязательный характер‘;#❝

49.7. спецификация универсального описания, поиска и интеграции электронных сервисов версии 3.0 - стандарт Организации по развитию стандартов структурированной информации - спецификация носит рекомендательный характер”.#❝

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

50.1. расширяемый язык разметки - набор стандартов Консорциума#❝

50.2. расширяемый язык описания схем данных версии 1.1 - стандарт Консорциума Всемирной сети”, специфицированный в документах: часть 1.#❝

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

51.1. согласно базовому профилю интероперабельности версии 1.1 все описания электронных сервисов и описания схем данных? должны создаваться в кодировке UTF-8 (с указанием этой кодировки в заголовке соответствующего описания);#❝

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

51.3. электронный сервис считается доступным только при одновременной доступности и точки доступа электронного сервиса”, и описания электронного сервиса. Доступность электронного сервиса обеспечивает оператор информационной системы, в рамках которой функционирует электронный сервис (далее - поставщик).#❝

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

52.1. проверка электронной подписи (далее - ЭП) электронного сообщения (при необходимости);#❝

52.2. формально-логическая проверка электронного сообщения.#❝

53. Проверка ЭП электронного сообщения осуществляется операторами информационных систем, подключенных к системе взаимодействия, и оператором системы взаимодействия (далее — участники взаимодействия).#❝

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

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

57. В случае непрохождения формально-логической проверки электронное сообщение исключается из дальнейшей обработки, данный факт фиксируется, и по каналам связи системы взаимодействия отправителю направляется служебное электронное сообщение, извещающее 06 отказе в приеме электронного сообщения.#❝

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

59. Если принятое и успешно прошедшее процедуры контроля электронное сообщение является сообщением запроса на предоставление электронной услуги, то информационная система поставщика разрешает использование данного электронного сервиса.#❝

60. Если принятое и успешно прошедшее процедуры контроля электронное сообщение является извещением о готовности данных, то информационная система оператора, имеющего право использования электронного сервиса в соответствии с настоящими Требованиями (далее - потребитель), при необходимости инициирует сервис запроса этих данных.#❝

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

61.1. заголовок электронного сообщения системы взаимодействия (soap:header); |#❝

61.2. тело электронного сообщения системы взаимодействия (soap:body);#❝

61.3. сообщение об ошибке (soap:Fault).#❝

62. Заголовок электронного сообщения системы взаимодействия включает в том числе:#❝

62.1. передачу сведений об аутентификации и авторизации (WS-security);#❝

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

63. Тело электронного сообщения системы взаимодействия в общем случае состоит из следующих элементов:#❝

63.1. блок данных;#❝

63.2. блок присоединенных документов;#❝

63.3. блок ЭП.#❝

64. Блок данных электронного сообщения должен содержать дату и время отправки электронного сообщения в систему взаимодействия.#❝

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

66. Блок ЭП должен содержать одну или несколько ЭП, фиксирующих целостность и авторство каждого из блоков данных и каждого из блоков присоединенных документов.#❝

67. Сообщение об ошибке содержит текстовое описание возникшей ошибки и ее код в рамках информационной системы, в которой она возникла.#❝

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

69. Ответственным за правомерность использования ЭП является участник взаимодействия, отправивший электронное сообщение.#❝

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

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

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

73. Наименования, обозначающие общепринятые аббревиатуры, подлежат транслитерации на латиницу.#❝

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

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

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

77. Наименования метаданных должны записываться строчными буквами, кроме аббревиатур, записываемых полностью прописными (заглавными) буквами.#❝

78. По согласованию с оператором системы взаимодействия допускается использование в качестве первого (а также единственного) слова с прописной (заглавной) буквы.#❝

79. В наименования простых и составных типов (simpleType, complexType) для обозначения их отличия от элементов (element) рекомендуется добавлять суффикс «Туре».#❝

80. По согласованию с оператором системы взаимодействия при наименовании элементов метаданных допускается использование кириллицы.#❝

81. Согласование, указанное в пунктах 78 и 80 ‘настоящих Требований, осуществляется путем дополнения соглашений, подписываемых в соответствии с пунктом 14 Положения о системе взаимодействия, утвержденного постановлением Правительства Российской Федерации от 8 сентября 2010 г. № 697 «О единой системе межведомственного электронного взаимодействия» (Собрание законодательства Российской Федерации, 2010, № 38, ст. 4823; 2011, № 24, ст. 3503; № 49, ст. 7284; 2013, № 45, ст. 5827; 2014, № 12, ст. 1303, № 42, ст. 5746, № 48, ст. 6862, ст. 6876, № 50, ст. 7113).#❝

82. Под контрольным примером обращения к электронному сервису понимается пример обращения к электронному сервису и ответа электронного сервиса на указанное обращение. Контрольный пример обращения и ответа должен быть предоставлен поставщиком в формате протокола обмена структурированными сообщениями данных“.#❝

83. Назначением контрольного примера является подтверждение работоспособности электронного сервиса при проведении процедуры регистрации, в рамках#❝

84. Контрольный пример не должен вызывать выполнение каких-либо операций в информационной системе поставщика, которые могут привести к возникновению событий, позволяющих информационной системе участника взаимодействия или работникам участника взаимодействия интерпретировать полученные при выполнении контрольного примера данные как реальные, а не тестовые. Регистрация электронного сервиса информационной системы поставщика и (или) потребителя может считаться завершенной только при условии успешного выполнения контрольного примера, которое предполагает совпадение ответа электронного сервиса с ответом, приведенным в контрольном примере, либо, при объективной невозможности возврата электронным сервисом повторяемых данных, его соответствие описанию логики формирования ответа, которое в подобных случаях должно сопровождать предоставляемый контрольный пример (например, электронный сервис возвращает номер зарегистрированного обращения, который не может повторяться, в этом случае контрольный пример сопровождается указанием этого факта).#❝

85. В дальнейшем контрольный пример может быть использован для настройки модуля системы взаимодействия, обеспечивающего проверку доступности и работоспособности электронного сервиса, а также для отладки программного кода разработчиками потребителя электронного сервиса.#❝

87. Система взаимодействия обеспечивает гарантированную доставку неискаженных сообщений с определенным интервалом времени ожидания ответа на запрос путем определенного количества повторных вызовов электронных сервисов информационных систем участников взаимодействия за заданный интервал времени.#❝

88. Система взаимодействия обеспечивает фиксацию факта доставки неискаженного сообщения либо факта ошибки при передаче сообщения в рамках информационного обмена между информационной системой участника взаимодействия и системой взаимодействия.#❝

89. Электронные сервисы информационных систем участников взаимодействия могут разделяться по режиму работы в части обработки сообщений на синхронные и асинхронные электронные сервисы.#❝

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

91. Хранение сведений об истории движения электронных сообщений осуществляется в соответствии с требованиями законодательства Российской Федерации в специально созданной для данного хранения подсистеме системы взаимодействия.#❝

92. Для подключения информационной системы к системе взаимодействия ее оператор (поставщик или потребитель):#❝

92.1. обеспечивает защищенный канал связи между своей информационной системой и системой взаимодействия;#❝

92.2. разрабатывает интерфейсы взаимодействия с системой взаимодействия в соответствии с настоящими Требованиями;#❝

92.3. регистрирует электронный сервис информационной системы в реестре электронных сервисов информационных систем органов и организаций, подключенных к системе взаимодействия (далее - реестр электронных сервисов).#❝

93. В системе взаимодействия подлежат регистрации электронные сервисы, обеспечивающие:#❝

93.1. взаимодействие информационных систем, подключенных к системе взаимодействия;#❝

93.3. предоставление государственных и муниципальных услуг в электронной форме с использованием федеральной государственной информационной системы «Единый портал государственных и муниципальных услуг (функций)» (далее - единый портал).#❝

94. Электронные сервисы, обеспечивающие предоставление государственных услуг и муниципальных услуг в электронной форме с использованием единого портала, должны реализовывать следующие функции:#❝

94.1. направление сведений из заполненных форм заявлений и иных документов в едином портале в информационную систему поставщика;#❝

94.2. обновление в едином портале информации о ходе предоставления государственной услуги или исполнения государственной функции поставщиком;#❝

94.3. передачу из информационной системы поставщика в единый портал результата оказания государственной услуги и (или) ее отдельных административных процедур (действий).#❝

95. Для подключения информационной системы к системе взаимодействия поставщик осуществляет действия, предусмотренные пунктом 92 настоящих Требований, а также предоставляет оператору системы взаимодействия следующие документы:#❝

95.1. паспорт электронного сервиса, регистрируемого в системе взаимодействия;#❝

95.2. методику испытаний электронного сервиса, регистрируемого в системе взаимодействия, включая контрольный пример обращения к электронному сервису;#❝

95.3. руководство пользователя электронного сервиса, регистрируемого в системе взаимодействия.#❝

96. В предоставляемом поставщиком паспорте электронного сервиса, регистрируемого в системе взаимодействия, указываются:#❝

96.1. полное и краткое наименования электронного сервиса;#❝

96.2. развернутое описание назначения электронного сервиса;#❝

96.3. информационная система, предоставляющая электронный сервис;#❝

96.4. стадия создания и использования электронного сервиса (разработка, тестовая эксплуатация, опытная эксплуатация или промышленная эксплуатация);#❝

96.5. режим гарантированной доступности электронного сервиса, который выражается в формате «a/b», где а - количество часов доступности сервиса в сутки; b - количество дней доступности сервиса в году, с дополнительным указанием рабочего времени;#❝

96.6. полное и сокращенное наименование организации - собственника технических средств, используемых для обработки информации, содержащейся в базах данных, составляющих информационную систему, предоставляющую электронный сервис;#❝

96.7. полное и сокращенное наименование организации - оператора информационной системы, предоставляющей электронный сервис;#❝

96.8. наименование структурного подразделения организации - оператора информационной системы, предоставляющей электронный сервис, ответственного за эксплуатацию электронного сервиса;#❝

96.9. фамилия, имя, отчество (при наличии), должность, контактный телефон, адрес электронной почты должностного лица, ответственного за эксплуатацию электронного сервиса;#❝

96.10. текущая версия электронного сервиса в формате Х.ХХ;#❝

96.11. тип режима работы сервиса: А - асинхронный или С - синхронный;#❝

96.12. дата начала функционирования электронного сервиса”;#❝

96.13. ссылка на \У/5ОГ-документ, описывающий электронный сервис;#❝

96.14. адрес электронного сервиса у поставщика.#❝

97. При заполнении паспорта электронного сервиса описание отдельных его элементов может повторяться.#❝

98. Оператором системы взаимодействия при регистрации электронного сервиса в реестре электронных сервисов в паспорте электронного сервиса дополнительно указываются:#❝

98.1. неизменный уникальный идентификатор электронного сервиса в рамках принятой системы идентификации сервиса”;#❝

98.2. узел системы взаимодействия, через который осуществляется доступ к электронному сервису;#❝

98.3. адрес электронного сервиса в системе взаимодействия.#❝

99. Поставщик обеспечивает доступность электронного сервиса, регистрируемого в системе взаимодействия, для проведения приемки электронного сервиса.#❝

100. Оператор системы взаимодействия осуществляет регистрацию электронного сервиса, в процессе которой осуществляются:#❝

100.1. проверка представленной документации;#❝

100.2. проверка соответствия разработанного электронного сервиса настоящим Требованиям;#❝

100.3. тестирование электронного сервиса на контрольном примере в соответствии с представленной методикой испытаний.#❝

101. В случае если электронный сервис не проходит проверку, он возвращается на доработку поставщику.#❝

102. В случае соответствия электронного сервиса условиям, указанным в настоящих Требованиях, оператор системы взаимодействия регистрирует его в реестре электронных сервисов.#❝

103. В целях изменения электронного сервиса, зарегистрированного в системе взаимодействия, поставщик электронного сервиса обеспечивает доступность новой версии электронного сервиса для проведения приемки и предоставляет оператору системы взаимодействия следующие документы:#❝

103.1. паспорт новой версии электронного сервиса, составленный в соответствии с пунктом 96 настоящих Требований;#❝

103.2. методику испытаний новой версии электронного сервиса, включая контрольный пример обращения к электронному сервису;#❝

103.3. руководство пользователя новой версии электронного сервиса.#❝

104. Оператор системы взаимодействия осуществляет приемку новой версии электронного сервиса, разработанного поставщиком, в следующем порядке:#❝

104.1. проверяет комплектность и качество представленной документации;#❝

104.2. проверяет соответствие новой версии электронного сервиса настоящим 'Требованиям;#❝

104.3. тестирует новую версию электронного сервиса на контрольном примере в соответствии с представленной методикой испытаний.#❝

105. При положительных результатах проверки новой версии электронного сервиса, разработанного поставщиком, оператор системы взаимодействия осуществляет регистрацию электронного сервиса в системе взаимодействия и рассылает уведомление всем потребителям данного электронного сервиса о выходе его новой версии и сроках работоспособности старой версии электронного сервиса.#❝

106. В случае если новая версия электронного сервиса, разработанного поставщиком, не прошла проверку, оператор системы взаимодействия возвращает электронный сервис поставщику на доработку.#❝

107. В целях удаления из системы взаимодействия ранее зарегистрированного в ней электронного сервиса (далее - исключение электронного сервиса) поставщик направляет уведомление оператору системы взаимодействия об исключении электронного сервиса с указанием причины.#❝

108. Оператор системы взаимодействия проверяет обоснованность заявки на исключение электронного сервиса из системы взаимодействия и определяет оставшийся срок эксплуатации электронного сервиса.#❝

109. Оператор системы взаимодействия уведомляет потребителей электронного сервиса о сроках его отключения.#❝

110. Поставщик выводит исключаемый электронный сервис из эксплуатации в определенный оператором системы взаимодействия срок.#❝

111. Оператор системы взаимодействия удаляет запись об электронном сервисе из системы взаимодействия.#❝

112. Для осуществления поиска и обнаружения необходимого электронного сервиса в системе взаимодействия потребитель обращается на технологический портал системы взаимодействия и просматривает список всех зарегистрированных электронных сервисов либо осуществляет поиск нужного электронного сервиса с использованием поисковых процедур. По запросу потребитель получает полное описание электронного сервиса.#❝

113. В целях осуществления мониторинга состояния и использования электронного сервиса при получении информационными системами потребителя электронных сообщений из информационных систем поставщика в системе взаимодействия фиксируются факты взаимодействия двух информационных систем.#❝

114. В рамках процедуры мониторинга состояния и использования электронных сервисов, зарегистрированных в системе взаимодействия, для каждого взаимодействия автоматически регистрируются следующие данные:#❝

114.1. запрашиваемый электронный сервис;#❝

114.2. пользователь (для авторизованных запросов);#❝

114.3. ТР-адрес пользователя;#❝

114.4. время отклика электронного сервиса;#❝

114.5. содержимое запроса;#❝

114.6. содержимое ответа;#❝

114.8. объем передаваемых данных в ответе (в байтах);#❝

114.9. при возникновении ошибки - ее описание.#❝

115. В рамках процедуры мониторинга состояния и использования электронных сервисов, зарегистрированных в системе взаимодействия, также:#❝

115.1. в автоматическом режиме осуществляется регулярный опрос зарегистрированных электронных сервисов, анализируется их состояние и формируется автоматическая рассылка уведомлений оператору системы взаимодействия и поставщику электронного сервиса при диагностировании ошибок;#❝

115.2. в автоматизированном режиме выполняются задачи предоставления аналитических отчетов по результатам работы системы взаимодействия с возможностью группировки, сортировки и фильтрации данных.#❝

116. Условия и порядок использования ЭП при осуществлении информационного взаимодействия определяются законодательством Российской Федерации в области применения ЭП.#❝

117. Подсистема информационной безопасности каждой информационной системы, подключаемой к системе взаимодействия, должна обеспечивать установленные законодательством Российской Федерации уровни защищенности информации, обрабатываемой в этой системе.#❝

118. Все каналы связи системы взаимодействия, выходящие за пределы контролируемых зон участников взаимодействия, должны быть защищены с помощью сертифицированных средств криптографической защиты информации, удовлетворяющих установленным требованиям к средствам криптографической защиты информации класса не ниже КСЗ и находящихся в пределах контролируемых зон участников взаимодействия.#❝

119. Доступ к электронным сервисам информационных систем участников взаимодействия должен осуществляться с использованием сертифицированных средств межсетевого экранирования.#❝

120. Администрирование и сопровождение оборудования, обеспечивающего криптографическую защиту каналов связи, должно производиться только участником взаимодействия либо уполномоченными им лицами.#❝

121. Доступ посторонних лиц ко всем техническим средствам системы взаимодействия, каналам связи и поддерживающим системам (электропитания, вентиляции, кондиционирования) в контролируемой зоне участника взаимодействия должен быть исключен.#❝

122. В целях обеспечения защиты информации, содержащейся в информационных . системах, подключенных к системе взаимодействия, участники взаимодействия:#❝

122.1. обеспечивают при обслуживании информационных систем, подключенных. к системе взаимодействия, исполнение установленных требований по информационной, производственной, технологической и противопожарной безопасности;#❝

122.2. осуществляют контроль доступа посторонних лиц к техническим средствам и каналам связи в контролируемой зоне участника взаимодействия, включая время проведения ремонтных работ и уборки помещений;#❝

122.3. обеспечивают обслуживание информационных систем, подключенных к системе взаимодействия, только лицами, имеющими право доступа к информации, содержащейся в указанных информационных системах;#❝

122.4. принимают необходимые и достаточные меры, исключающие доступ посторонних лиц к защищаемой, в том числе парольной и ключевой информации, хранящейся на используемых и отчуждаемых носителях информации;#❝

122.5. осуществляют учет лиц, имеющих доступ к оконечному оборудованию, обеспечивающему криптографическую защиту каналов связи системы взаимодействия, расположенному в контролируемой зоне участника взаимодействия, а также лиц, имеющих возможность изменения конфигурации информационных систем данного участника взаимодействия, подключенных к системе взаимодействия.#❝

123. В целях обеспечения полноценного функционирования системы взаимодействия и подключенных к ней информационных систем каждый участник взаимодействия: |#❝

123.1. обеспечивает возможность оперативного переключения на резервный канал с сохранением функций обеспечения безопасности информации для всех каналов связи, выход из строя которых может существенно повлиять на доступность информационных систем, подключенных к системе взаимодействия:#❝

123.2. обеспечивает возможность оперативной замены оборудования, обеспечивающего криптографическую защиту каналов связи, используемых участником взаимодействия для осуществления информационного обмена в рамках системы взаимодействия, в случае выхода такого оборудования из строя.#❝

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

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

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