ПРИКАЗ ФЕДЕРАЦИИ - egov.astrobl.ru · МИНИСТЕРСТВО СВЯЗИ И...

МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙФЕДЕРАЦИИ

ПРИКАЗ

от 23 июня 2015 года N 210

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

(с изменениями на 22 февраля 2017 года)

____________________________________________________________________Документ с изменениями, внесенными: приказом Минкомсвязи России от 22 февраля 2017 года N 71

(Официальный интернет-портал правовой информации www.pravo.gov.ru,05.06.2017, N 0001201706050011) (вступил в силу с 1 августа 2017 года). ____________________________________________________________________

В соответствии с постановлением Правительства Российской Федерацииот 8 сентября 2010 года N 697 "О единой системе межведомственногоэлектронного взаимодействия" (Собрание законодательства РоссийскойФедерации, 2010, N 38, ст.4823; 2011, N 24, ст.3503; N 49, ст.7284; 2013, N 45,ст.5827; 2014, N 12, ст.1303, N 42, ст.5746, N 48, ст.6862, ст.6876, N 50, ст.7113)приказываю:

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

2. Признать утратившим силу приказ Министерства связи и массовыхкоммуникаций Российской Федерации от 27.12.2010 N 190 "Об утвержденииТехнических требований к взаимодействию информационных систем в единойсистеме межведомственного электронного взаимодействия" (зарегистрированМинистерством юстиции Российской Федерации 29.12.2010, регистрационныйN 19425).

3. Направить настоящий приказ на государственную регистрацию вМинистерство юстиции Российской Федерации.

http://docs.cntd.ru/document/456058890



МинистрН.А.Никифоров

Зарегистрированов Министерстве юстицииРоссийской Федерации25 августа 2015 года,регистрационный N 38668

Технические требования к взаимодействиюинформационных систем в единой системемежведомственного электронноговзаимодействияУТВЕРЖДЕНЫприказомМинистерства связии массовых коммуникаций

Российской Федерацииот 23 июня 2015 года N 210

(с изменениями на 22 февраля 2017 года)

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

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

II. Межведомственное электронное взаимодействие сиспользованием единого электронного сервиса

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

получение передаваемых электронных сообщений (далее - Единыйэлектронный сервис)._______________

Пункт 2 Положения о единой системе межведомственного электронноговзаимодействия, утвержденного постановлением Правительства РоссийскойФедерации от 8 сентября 2010 года N 697 (Собрание законодательстваРоссийской Федерации, 2010, N 38, ст.4823; 2011, N 24, ст.3503; N 49, ст.7284;2013, N 45, ст.5827; 2014, N 12, ст.1303, N 42, ст.5746, N 48, ст.6862, ст.6876, N50, ст.7113).

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



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

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

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

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

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

(Подпункт дополнительно включен с 1 августа 2017 года приказомМинкомсвязи России от 22 февраля 2017 года N 71)

7.2. Система взаимодействия обеспечивает присвоение кода транзакцииэлектронных сообщений, передаваемых в системе взаимодействия, инаправляет информационной системе потребителя сообщение, содержащееприсвоенный код транзакции.


7.3. Код транзакции формируется путем направления информационнойсистемой потребителя в систему взаимодействия запроса, в которыйобязательно включаются буквенно-цифровой код информационной системыоргана или организации информационного взаимодействия (далее - мнемоникаинформационной системы) и уникальный реестровый номер услуги (функции),в рамках предоставления (исполнения) которой запрошен код транзакции.





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

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

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

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

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

13. При смене форматов видов сведений оповещение потребителейсведений о смене форматов производится на портале "Технологическийпортал СМЭВ" в информационно-телекоммуникационной сети "Интернет"(http://smev.gosuslugi.ru) путем специального объявления, публикации новогоформата в каталоге видов сведений и пометки старого формата как недействующего с определенной даты.

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

(Пункт в редакции, введенной в действие с 1 августа 2017 года приказомМинкомсвязи России от 22 февраля 2017 года N 71.

14.1. К сообщениям типа "Запрос" (далее - запрос) относятся сообщения,исходящие от потребителя (кроме сообщений типа "Отмена").

Результатом сообщения типа "Запрос кода транзакции" являетсяприсвоение кода транзакции в рамках предоставления (исполнения) услуг(функций).

(Абзац дополнительно включен с 1 августа 2017 года приказомМинкомсвязи России от 22 февраля 2017 года N 71)



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

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

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

Для передачи сообщения типа "Запрос кода транзакции" отинформационной системы потребителя в систему взаимодействияиспользуется метод запроса кода транзакции (TransactionCode), который приусловии успешного прохождения запроса кода транзакции форматно-логического контроля (далее - ФЛК) автоматически присваивается системойвзаимодействия и направляется потребителю, инициировавшему такойзапрос.

(Абзац дополнительно включен с 1 августа 2017 года приказомМинкомсвязи России от 22 февраля 2017 года N 71)

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

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

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

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


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

(Подпункт в редакции, введенной в действие с 1 августа 2017 годаприказом Минкомсвязи России от 22 февраля 2017 года N 71.

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

19. ЭП-СП должностного лица органа власти, участвующего вмежведомственном взаимодействии также включается в состав сообщения вобязательном порядке в случае наличия соответствующего требованиянормативного правового акта Российской Федерации и соответствияуказанного лица такому требованию.

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

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

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

20.3. ЭП-ОВ.

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

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

21.2. ЭП-СП;(Подпункт в редакции, введенной в действие с 1 августа 2017 года

приказом Минкомсвязи России от 22 февраля 2017 года N 71.

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

21.4. блок атрибутов бизнес-процесса;21.5. код транзакции.(Подпункт дополнительно включен с 1 августа 2017 года приказом

Минкомсвязи России от 22 февраля 2017 года N 71)




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

с помощью механизма оптимизации передачи сообщений МТОМ ._______________

Справочно: Спецификация SOAP Message Transmission OptimizationMechanism опубликована по адресу в информационно-телекоммуникационнойсети "Интернет": http://www.w3.org/TR/soap12-mtom/.

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

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

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


24.3. ЭП-СМЭВ.

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

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

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

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

26.3. обратный адрес, необходимый для доставки ответа потребителю,включающий, в том числе, код транзакции (далее - адрес потребителя);


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


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

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

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


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

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

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


29.3. ЭП-ОВ.30. Блок данных ответа включает, в том числе:

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

30.2. ЭП-СП;

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

30.4. адрес потребителя.(Пункт 30 дополнительно включен с 1 августа 2017 года приказом


____________________________________________________________________Пункты 30-126 предыдущей редакции с 1 августа 2017 года считаются

соответственно пунктами 31-127 настоящей редакции - приказ МинкомсвязиРоссии от 22 февраля 2017 года N 71.____________________________________________________________________

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




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

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

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


33.3. ЭП-СМЭВ.

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

34.1. блок данных ответа, сформированный отправителем сообщения;34.2. код транзакции;(Подпункт дополнительно включен с 1 августа 2017 года приказом


____________________________________________________________________Подпункты 34.2-34.5 предыдущей редакции с 1 августа 2017 года

считаются соответственно подпунктами 34.3-34.6 настоящей редакции -приказ Минкомсвязи России от 22 февраля 2017 года N 71.____________________________________________________________________

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

34.4. подпункт исключен с 1 августа 2017 года - приказ МинкомсвязиРоссии от 22 февраля 2017 года N 71;

____________________________________________________________________Подпункты 34.5 и 34.6 предыдущей редакции с 1 августа 2017 года

считаются соответственно подпунктами 34.4 и 34.5 настоящей редакции -приказ Минкомсвязи России от 22 февраля 2017 года N 71.____________________________________________________________________

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

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

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





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

37. Изготовление, выдача ключей электронных подписей и сертификатовключей проверки электронных подписей участникам информационноговзаимодействия осуществляются в соответствии с положениямиФедерального закона от 6 апреля 2011 года N 63-ФЗ "Об электроннойподписи" (Собрание законодательства Российской Федерации, 2011, N 15,ст.2036, N 27, ст.3880; 2012, N 29, ст.3988, 2013, N 14, ст.1668, N 27, ст.3463,ст.3477, 2014, N 11, ст.1098, N 26, ст.3390).

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

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

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

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

39.3. Подтвердить получение (Аск), служит для подтверждения получениясообщения, вызывается после получения сообщения методами GetRequestили GetResponse;

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

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

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

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


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

(Пункт в редакции, введенной в действие с 1 августа 2017 года приказомМинкомсвязи России от 22 февраля 2017 года N 71.

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

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


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

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

41.4. проверка ЭП-СП;41.5. проверка по ЭП-СМЭВ кода транзакции;(Подпункт дополнительно включен с 1 августа 2017 года приказом


____________________________________________________________________Подпункт 41.5 предыдущей редакции с 1 августа 2017 года считается

подпунктом 41.6 настоящей редакции - приказ Минкомсвязи России от 22февраля 2017 года N 71.____________________________________________________________________

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

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





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

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

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

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

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

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

(Пункт дополнительно включен с 1 августа 2017 года приказомМинкомсвязи России от 22 февраля 2017 года N 71)

III. Межведомственное электронное взаимодействие сиспользованием электронных сервисов


____________________________________________________________________Пункты 46-127 предыдущей редакции с 1 августа 2017 года считаются

соответственно пунктами 47-128 настоящей редакции - приказ МинкомсвязиРоссии от 22 февраля 2017 года N 71.____________________________________________________________________

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

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

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

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

50.1. протокол передачи гипертекста версии 1.1 - комментарийинженерной группы проектировщиков информационно-телекоммуникационной

сети "Интернет" 2616;_______________

Справочно: Протокол передачи гипертекста - Hypertext Transfer Protocol(HTTP).

Справочно: Комментарий инженерной группы проектировщиковинформационно-телекоммуникационной сети "Интернет" обозначается RFC(Request for Comments).

50.2. расширенный протокол передачи гипертекста версии 1.1 с

обеспечением безопасности транспортного уровня ;_______________

Справочно: Безопасность транспортного уровня обозначается TLS(Transport Layer Security).


50.3. протокол защищенных соединений версии 3 - комментарийинженерной группы проектировщиков информационно-телекоммуникационнойсети "Интернет" 5246;_______________

Справочно: Протокол защищенных соединений обозначается SSL(Secure Socket Layer).

50.4. набор протоколов для обеспечения защиты данных, передаваемых по

межсетевому протоколу ;_______________

Справочно: Набор протоколов для обеспечения защиты данных,передаваемых по межсетевому протоколу, обозначается IPsec (IP Security).

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

50.6. протоколы использования системы поддержки пространства имен -комментарии инженерной группы проектировщиков информационно-телекоммуникационной сети "Интернет" 1035._______________

Справочно: Система поддержки пространства имен обозначается DNS(Domain Name System).

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

51.1. протокол обмена структурированными сообщениями версии 1.1 -

стандарт Консорциума Всемирной сети - спецификация носит обязательный

характер ;_______________

Справочно: Консорциум Всемирной сети - World Wide Web Consortium(http://www.w3.org/TR/soap/).

Справочно: Протокол обмена структурированными сообщениями(Simple Object Access Protocol, SOAP) опубликован по адресу винформационно-телекоммуникационной сети "Интернет":http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

51.2. язык описания электронных сервисов версии 1.1 - стандарт

Консорциума Всемирной сети - спецификация носит обязательный характер;_______________

Справочно: Язык описания электронных сервисов версии 1.1 (WebServices Description Language, WSDL 1.1) опубликован по адресу винформационно-телекоммуникационной сети "Интернет":http://www.w3.org/TR/wsdl.

51.3. базовый профиль интероперабельности версии 1.1 - стандарт

Организации по интероперабельности электронных сервисов -

спецификация носит обязательный характер ;_______________

Справочно: Организация по интероперабельности электронныхсервисов - Web Services Interoperability Organization.

Справочно: Базовый профиль интероперабельности версии 1.1 (WS-IBasic Profile 1.1) опубликован по адресу в информационно-телекоммуникационной сети "Интернет": http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html.

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

рекомендательный характер ;_______________

Справочно: Политика использования электронных сервисов версии 1.2(Web Services Policy 1.2) опубликована по адресу в информационно-телекоммуникационной сети "Интернет": http://www. w3.org/Submission/WS-Policy/).

51.5. оптимизированный механизм передачи бинарных данных вструктурированных сообщениях - стандарт Консорциума Всемирной сети -

спецификация носит рекомендательный характер ;_______________

Справочно: Оптимизированный механизм передачи бинарных данных вструктурированных сообщениях (SOAP Message Transmission OptimizationMechanism) опубликован по адресу в информационно-телекоммуникационнойсети "Интернет": http://www.w3.org/TR/soap12-mtom/.

51.6. профиль сопоставления данных версии 1.0 - стандарт Организации поинтероперабельности электронных сервисов - спецификация носит

обязательный характер ;_______________

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

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

рекомендательный характер ._______________

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

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

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

Всемирной сети ;_______________

Справочно: Расширяемый язык разметки (XML Extensible MarkupLanguage) опубликован по адресу в информационно-телекоммуникационнойсети "Интернет": http://www.w3.org/standards/techs/xml#w3c_all.

52.2. расширяемый язык описания схем данных версии 1.1 - стандарт

Консорциума Всемирной сети , специфицированный в документах: часть 1.

"Структуры" , часть 2. "Типы данных" - спецификация носит обязательныйхарактер;_______________

Справочно: Расширяемый язык описания схем данных версии 1.1 (XMLSchema 1.1).

Справочно: Опубликовано по адресу в информационно-телекоммуникационной сети "Интернет": http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/.

Справочно: Опубликовано по адресу в информационно-телекоммуникационной сети "Интернет": http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/.

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

53.1. согласно базовому профилю интероперабельности версии 1.1 все

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

Справочно: Язык описания схем данных (XML Schema Definition, XSD) -один из языков описания структуры электронных сообщений.

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

53.3. электронный сервис считается доступным только при одновременной

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

Справочно: Точку доступа электронного сервиса принято обозначатьendpoint.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

63.3. сообщение об ошибке (soap:Fault).

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

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

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

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

65.1. блок данных;

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

65.3. блок ЭП.

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

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

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

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

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

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

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

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

<xsd:annotation><xsd:documentation>Текст описания</xsd:documentation></xsd:annotation>.Синтаксическую конструкцию  рекомендуется

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

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

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

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

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

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

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

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

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

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

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

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

структурированными сообщениями данных ._______________

Справочно: SOAP-сообщение.

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

95.2. взаимодействие между системой взаимодействия (федеральныйуровень) и региональной системой взаимодействия (региональный уровень);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

98.12. дата начала функционирования электронного сервиса ;_______________

Справочно: Рекомендуется для кодировки значения даты использоватьопределение профиля ISO 8601 [W3CDTF], которое поддерживает форматГГГГ-ММ-ДД.

98.13. ссылка на WSDL-документ, описывающий электронный сервис;

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

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

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

100.1. неизменный уникальный идентификатор электронного сервиса в

рамках принятой системы идентификации сервиса ;_______________

Справочно: Уникальный идентификатор выбирается в соответствии состандартом ISO/IEC 9834-8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

116.3. IP-адрес пользователя;

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

116.5. содержимое запроса;

116.6. содержимое ответа;

116.7. объем передаваемых данных в запросе (в байтах);

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

116.9. при возникновении ошибки - ее описание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРИКАЗ ФЕДЕРАЦИИ - egov.astrobl.ru · МИНИСТЕРСТВО СВЯЗИ И...

Documents