В соответствии с подпунктами 13) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года "Об информатизации" ПРИКАЗЫВАЮ:
1. Утвердить прилагаемые Правила интеграции объектов информатизации "электронного правительства".
2. Признать утратившим силу приказ исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 28 января 2016 года № 104 "Об утверждении Правил интеграции шлюза "электронного правительства", платежного шлюза "электронного правительства" с информационными системами" (зарегистрирован в Реестре государственной регистрации нормативных правовых актов под № 13244, опубликован 14 марта 2016 года в информационно-правовой системе нормативных правовых актов Республики Казахстан "Әділет").
3. Департаменту развития "электронного правительства" и государственных услуг Министерства информации и коммуникаций Республики Казахстан обеспечить:
1) государственную регистрацию настоящего приказа в Министерстве юстиции Республики Казахстан;
2) в течение десяти календарных дней со дня государственной регистрации настоящего приказа направление его в Республиканское государственное предприятие на праве хозяйственного ведения "Республиканский центр правовой информации" для официального опубликования и включения в Эталонный контрольный банк нормативных правовых актов Республики Казахстан;
3) размещение настоящего приказа на интернет-ресурсе Министерства информации и коммуникаций Республики Казахстан;
4) в течение десяти рабочих дней после государственной регистрации настоящего приказа представление в Юридический департамент Министерства информации и коммуникаций Республики Казахстан сведений об исполнении мероприятий, предусмотренных подпунктами 1), 2) и 3) настоящего пункта.
4. Контроль за исполнением настоящего приказа возложить на курирующего вице-министра информации и коммуникаций Республики Казахстан.
5. Настоящий приказ вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования.
|
Исполняющий обязанности министра информации и коммуникаций Республики Казахстан |
А. Ажибаев |
| Утверждены приказом исполняющего обязанности Министра информации и коммуникаций Республики Казахстан от 29 марта 2018 года № 123 |
Правила
интеграции объектов информатизации "электронного правительства"
Глава 1. Общие положения
1. Настоящие Правила интеграции объектов информатизации "электронного правительства" (далее – Правила) разработаны в соответствии с подпунктом 13) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года "Об информатизации" (далее – Закон) и определяют порядок интеграции объектов информатизации "электронного правительства".
2. В настоящих Правилах используются следующие основные понятия:
1) владелец объектов информатизации – субъект, которому собственник объектов информатизации предоставил права владения и пользования объектами информатизации в определенных законом или соглашением пределах и порядке;
2) техническая реализация интеграции объектов информатизации – комплекс технических работ, в том числе тестирование и работы по вводу в промышленную эксплуатацию интеграционного сервиса, проводимых для обеспечения интеграции участников информационного взаимодействия;
3) уполномоченный орган в сфере информатизации (далее – уполномоченный орган) – центральный исполнительный орган, осуществляющий руководство и межотраслевую координацию в сфере информатизации и "электронного правительства";
4) информационная система (далее – ИС) – организационно-упорядоченная совокупность информационно-коммуникационных технологий, обслуживающего персонала и технической документации, реализующих определенные технологические действия посредством информационного взаимодействия и предназначенных для решения конкретных функциональных задач;
4-1) промышленная эксплуатация информационной системы – эксплуатация информационной системы в штатном режиме в соответствии с целями, задачами и требованиями, изложенными в технической документации и нормативно-технической документации;
5) бизнес-данные объекта информатизации – данные взаимодействия владельца объекта информатизации и инициатора реализации интеграционного сервиса, входящие в состав сообщений формата ШЭП как блок, не проверяемый на стороне ШЭП;
6) интеграция объектов информатизации – мероприятия по организации и обеспечению информационного взаимодействия между объектами информатизации на основании используемых в Республике Казахстан стандартных протоколов передачи данных;
7) безопасность веб-сервисов (Web Service Security) (далее – WS Security) – стандарт применения функций безопасности при обмене сообщениями между веб-сервисами SOAP;
8) протокол Деффи-Хеллмана – криптографический протокол, позволяющий двум и более сторонам обменяться заранее согласованным общим секретным ключом, используя пару публичных и частных ключей в незащищенном от прослушивания канале связи;
9) частный IP-адрес – внутренний уникальный сетевой адрес узла в локальной компьютерной сети;
10) публичный IP-адрес – уникальный сетевой адрес, маршрутизируемый в сети Интернет;
11) инициатор реализации интеграционного сервиса (далее - инициатор интеграционного сервиса) – владелец объекта информатизации, инициирующий запрос на предоставление интеграционного сервиса;
12) интеграционный сервис – сервис, реализованный в рамках информационного взаимодействия объектов информатизации;
13) расширяемый язык разметки (eXtensible Markup Language) (далее – XML) – расширяемый язык разметки, используемый для хранения и передачи данных в структурированном и машиночитаемом формате;
14) транспортная подпись – электронная цифровая подпись, используемая для обеспечения целостности и авторства передаваемых сообщений при информационном взаимодействии ИС с применением спецификации WS Security;
15) удостоверяющий центр – юридическое лицо, удостоверяющее соответствие открытого ключа электронной цифровой подписи закрытому ключу электронной цифровой подписи, а также подтверждающее достоверность регистрационного свидетельства;
16) журнал логирования – файлы, содержащие информацию о работе системы, используемую для мониторинга ее работы и выявления причин, в случае возникновения сбоя;
17) единая транспортная среда государственных органов (далее – ЕТС ГО) – сеть телекоммуникаций, входящая в информационно-коммуникационную инфраструктуру "электронного правительства" и предназначенная для обеспечения взаимодействия локальных (за исключением локальных сетей, имеющих доступ к Интернету), ведомственных и корпоративных сетей телекоммуникаций государственных органов, их подведомственных организаций и органов местного самоуправления, а также иных субъектов информатизации, определенных уполномоченным органом, с соблюдением требуемого уровня информационной безопасности;
18) простой протокол доступа к объектам (Simple Object Access Protocol) (далее – SOAP) – протокол, основанный на XML для передачи сообщений при интеграции ИС;
19) реестр сервисов – перечень зарегистрированных в шлюзе "электронного правительства" и внешнем шлюзе "электронного правительства" сервисов, с описанием сервиса;
20) оператор информационно-коммуникационной инфраструктуры "электронного правительства" (далее – оператор) – юридическое лицо, определяемое Постановлением Правительства Республики Казахстан от 29 января 2016 года № 40, на которое возложено обеспечение функционирования закрепленной за ним информационно-коммуникационной инфраструктуры "электронного правительства";
21) сервисный интегратор "электронного правительства" (далее – сервисный интегратор) – юридическое лицо, определяемое Правительством Республики Казахстан, на которое возложены функции по методологическому обеспечению развития архитектуры "электронного правительства" и типовой архитектуры "электронного акимата", а также иные функции, предусмотренные Законом;
22) шлюз "электронного правительства" (далее – ШЭП) – ИС, предназначенная для интеграции государственных и негосударственных ИС в рамках "электронного правительства";
23) объекты информатизации "электронного правительства" (далее – объекты информатизации) – государственные электронные информационные ресурсы, программное обеспечение государственных органов и информационно-коммуникационная инфраструктура "электронного правительства", в том числе негосударственные ИС, интегрируемые с ИС государственных органов или предназначенные для формирования государственных электронных информационных ресурсов;
24) внешний шлюз "электронного правительства" (далее – ВШЭП) – подсистема шлюза "электронного правительства", предназначенная для обеспечения взаимодействия ИС, находящихся в ЕТС ГО, с ИС, находящимися вне ЕТС ГО;
25) платежный шлюз "электронного правительства" (далее – ПШЭП) – ИС, автоматизирующая процессы передачи информации о проведении платежей в рамках оказания возмездных услуг, оказываемых в электронной форме;
26) электронное сообщение – электронный документ в формате XML, предназначенный для обмена информацией между объектами информатизации;
27) электронная цифровая подпись (далее – ЭЦП) – набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания;
28) инкапсуляция AH (Authentication Header) – инкапсуляция аутентифицирующего заголовка, которая позволяет аутентифицировать соседнего узла в туннеле VPN и обеспечить целостность передаваемых данных без шифрования. Значение в поле протокола заголовка IP – равное UDP порту 51;
29) ESP (Encapsulation Security Payload) – инкапсуляция защищенных данных, который позволяет зашифровать весь кадр, передаваемый через VPN-канал, включая полезную нагрузку и IP-заголовки источника и назначения. Значение в поле протокола заголовка IP, равное UDP порту 50;
30)IP (Internet Protocol) – сетевая модель передачи данных, представленных в цифровом виде;
31) SSL-сертификат (Secure Sockets Layer) – регистрационное свидетельство, предназначенное для использования интернет-ресурсом или ИС для обеспечения процедуры аутентификации;
32) TCP (Transmission Control Protocol) – один из основных протоколов передачи данных Интернета, предназначенный для управления передачей данных;
33) UDP (User Datagram Protocol) – протокол пользовательских датаграмм, один из ключевых элементов TCP/IP, набора сетевых протоколов для Интернета;
34) URL (Uniform Resource Locator) – единообразный локатор (определитель местонахождения) ресурса, указывает адрес сервиса объекта информатизации;
35) Virtual Private Network (далее – VPN) – виртуальная частная сеть для обмена информацией двух узлов.
Сноска. Пункт 2 с изменением, внесенным приказом Министра цифрового развития, оборонной и аэрокосмической промышленности РК от 22.04.2019 № 48/НҚ (вводится в действие по истечении десяти календарных дней дня после дня его первого официального опубликования).3. Интеграции с ШЭП, ВШЭП и ПШЭП не подлежат сервисы, предоставляемые удостоверяющими центрами, объекты информатизации, которые содержат сведения, составляющие государственные секреты Республики Казахстан и служебную информацию ограниченного распространения, а также объекты информатизации, размещенные на информационно-коммуникационной платформе "электронного правительства" и предназначенные для формирования единого пространства данных для целей предоставлений аналитической информации по деятельности Правительства Республики Казахстан.
Сноска. Пункт 3 в редакции приказа Министра цифрового развития, оборонной и аэрокосмической промышленности РК от 22.04.2019 № 48/НҚ (вводится в действие по истечении десяти календарных дней дня после дня его первого официального опубликования).4. Интеграция объектов информатизации посредством ШЭП, ВШЭП, ПШЭП осуществляется при согласии владельца объекта информатизации на проведение интеграции.
Глава 2. Порядок интеграции объектов информатизации
"электронного правительства"
5. Участниками реализации интеграционного сервиса являются:
1) сервисный интегратор;
2) уполномоченный орган;
3) оператор;
4) разработчики интеграционного сервиса со стороны владельца объекта информатизации;
5) разработчики интеграционного сервиса со стороны инициатора интеграционного сервиса.
6. Мероприятия по интеграции объектов информатизации с ШЭП осуществляются в следующем порядке:
1) инициатор интеграционного сервиса направляет Сервисному интегратору запрос для рассмотрения возможности интеграции объектов информатизации (далее – запрос);
2) сервисный интегратор в течение 7 (семь) рабочих дней с момента получения запроса проводит анализ реализации интеграции объектов информатизации с учетом анализа утвержденных архитектур государственных органов, соответствия единым требованиям в области информационно-коммуникационных технологий, утвержденных постановлением Правительства Республики Казахстан от 20 декабря 2016 года № 832, требованиям по развитию архитектуры "электронного правительства", утвержденным приказом Министра информации и коммуникаций Республики Казахстан от 31 мая 2018 года № 239 (зарегистрирован в Реестре государственной регистрации нормативных правовых актов за № 17046), а также анализа на наличие аналогичных сервисов в реестре сервисов и предоставляет рекомендации инициатору интеграционного сервиса к интеграции с ШЭП, ВШЭП и ПШЭП;
3) при получении от сервисного интегратора положительных рекомендаций инициатор интеграционного сервиса направляет в адрес владельца объекта информатизации соглашение по реализации интеграции объектов информатизации (далее - соглашение) для подписания с приложением рекомендации сервисного интегратора.
В соглашении указывается о реализации интеграции с учетом форматов данных, указанных в приложении 1 к настоящим Правилам, а также указываются требования производительности и надежности передаваемых сообщений объектов информатизации посредством ШЭП, ВШЭП, которые запрашиваются у оператора и информация по интеграционному сервису (основания, условия интеграции);
4) владелец объекта информатизации в течение 10 (десять) рабочих дней со дня получения соглашения от инициатора интеграционного сервиса подписывает соглашение либо отказывает в его подписании.
Негосударственная ИС интегрируется с ИС государственного органа при условии наличия акта о приемке в промышленную эксплуатацию ИС, акта с положительным результатом испытаний на соответствие требованиям информационной безопасности, экспертизы технической документации и аттестата соответствия требованиям информационной безопасности.
Данные требования не распространяются на ИС финансовых организаций при их интеграции через ВШЭП, введенный в промышленную эксплуатацию.
При подписании соглашения также учитывается наличие договора совместных работ по информационной безопасности государственных и негосударственных ИС;
5) в случае подписания соглашения владелец объекта информатизации направляет в адрес уполномоченного органа заявку на публикацию сервиса на ШЭП (указывается тестовая и промышленная среда) по форме согласно приложению 2 к настоящим Правилам, с приложением:
SSL сертификата, открытого ключа ИС, выданных Национальным удостоверяющим центром Республики Казахстан (актом передачи);
при взаимодействии в контуре ЕТС ГО дополнительно предоставляется заявку на организацию доступа к информационным ресурсам в ЕТС ГО согласно приложению 3 к настоящим правилам (указывается тестовая или промышленная среда);
при взаимодействии в контуре Интернет (для ИС вне ЕТС ГО интегрируемых посредством ВШЭП) дополнительно предоставляется VPN-форма для создания VPN-туннеля по форме согласно приложению 4 к настоящим Правилам (указывается тестовая или промышленная среда).
В случае если сервис уже опубликован на ШЭП, то реализация интеграции объектов информатизации осуществляется согласно подпунктам 1), 2), 3), 4), 6), 7), 8), 9), 10), 11) и 12) настоящего пункта;
6) инициатор интеграционного сервиса направляет в адрес уполномоченного органа заявку на интеграцию объекта информатизации с ШЭП для использования, опубликованного на ШЭП сервиса (указывается тестовая и промышленная среда) по форме согласно приложению 5 к настоящим Правилам с приложением:
соглашения на интеграцию с владельцем объекта информатизации;
рекомендации сервисного интегратора по интеграции объектов информатизации;
SSL сертификата, открытого ключа ИС, выданных Национальным удостоверяющим центром Республики Казахстан (актом передачи);
при взаимодействии в контуре ЕТС ГО дополнительно предоставляется заявка на организацию доступа к информационным ресурсам в ЕТС ГО по форме согласно приложению 3 к настоящим правилам (указывается тестовая или промышленная среда);
при взаимодействии в контуре Интернет (для ИС вне ЕТС ГО интегрируемых посредством ВШЭП) дополнительно предоставляется VPN-форма для создания VPN-туннеля по форме согласно приложению 4 к настоящим Правилам (указывается тестовая или промышленная среда);
акта о приемке в промышленную эксплуатацию ИС (предоставляется владельцем негосударственной ИС для работы в промышленной среде) ;
акта с положительным результатом испытаний на соответствие требованиям информационной безопасности (предоставляется владельцем негосударственной ИС для работы в промышленной среде);
экспертизы технической документации и аттестата соответствия требованиям информационной безопасности (предоставляется владельцем негосударственной ИС для работы в промышленной среде);
договора совместных работ по информационной безопасности государственных и негосударственных ИС;
7) уполномоченный орган направляет вышеуказанные материалы владельца объекта информатизации и инициатора интеграционного сервиса оператору для проведения необходимых мероприятий по технической реализации интеграционного сервиса.
Оператор исполняет указанные заявки в течение 10 (десять) рабочих дней с момента получения материалов от уполномоченного органа до момента ввода в промышленную эксплуатацию интеграционного сервиса (в зависимости от готовности инициатора интеграционного сервиса и владельца объекта информатизации);
8) для начала тестирования работы интеграционного сервиса оператор регистрирует в реестре сервисов данные об объектах информатизации и их пользователях.
Сервисному интегратору предоставляется доступ к реестру сервисов;
9) разработчики интеграционного сервиса со стороны владельца объекта информатизации, инициатора интеграционного сервиса вносят изменения в объекты информатизации для проведения тестирования по интеграции с объектами информатизации;
10) совместно с разработчиками интеграционного сервиса со стороны владельца объекта информатизации, инициатора интеграционного сервиса и оператором проводится тестирование интеграционного сервиса в согласованные сроки;
11) в случае успешного тестирования интеграционного сервиса между оператором, уполномоченным органом, инициатором интеграционного сервиса и владельцем объекта информатизации составляется документ (акт) об успешном тестирования и вводе в промышленную эксплуатацию интеграционного сервиса, с указанием сроков ввода в промышленную эксплуатацию интеграционного сервиса;
12) интеграционный сервис вводится в промышленную эксплуатацию на основании подписанного акта после проведения оператором необходимых технических работ на ШЭП, ВШЭП, ПШЭП (перевод интеграционного сервиса в "рабочую" среду).
Сноска. Пункт 6 с изменением, внесенным приказом Министра цифрового развития, оборонной и аэрокосмической промышленности РК от 22.04.2019 № 48/НҚ (вводится в действие по истечении десяти календарных дней дня после дня его первого официального опубликования).7. Со стороны ШЭП подтверждением успешной реализации интеграционного сервиса является успешная передача сообщений (для асинхронного сервиса – получение отправителем уникального идентификатора сообщения, для синхронного – получение ответного сообщения) между участниками взаимодействия, которая фиксируется в журнале логирования.
8. Со стороны участников взаимодействия (владельца объекта информатизации и инициатора интеграционного сервиса) подтверждением успешной реализации интеграционного сервиса является успешное выполнение условий взаимодействия и обработка данных самими участниками взаимодействия.
9. В случае если осуществляется обмен информации о деталях платежей и иной информации в части платежей, объект информатизации интегрируются с ПШЭП, посредством ШЭП.
10. ШЭП, ПШЭП работают в круглосуточном режиме, принимают сообщения от объекта информатизации на постоянной основе за исключением технологических перерывов.
11. Время принятия сообщения ШЭП не должно превышать одной минуты с момента его получения по универсальному синхронному каналу и асинхронному каналу. Время предоставления результата по запросу на асинхронном канале, зависит от реализации каждого интеграционного сервиса.
12. Технологические перерывы в работе объекта информатизации заранее оговариваются и согласовываются владельцем объекта информатизации, инициатором реализации интеграционного сервиса и оператором за три рабочих дня до начала их проведения (по умолчанию технологические перерывы приходятся на ночное время с 21:00 до 6.00 часов, а также в выходные и праздничные дни).
13. В случае технической необходимости оператор и/или владелец объекта информатизации, инициатор реализации интеграционного сервиса производит перезагрузку системы, о чем уведомляют администраторов других объектов информатизации в виде телефонограммы или по электронной почте с указанием времени отсутствия доступа.
14. В случае если владелец объекта информатизации, инициатор реализации интеграционного сервиса не принимают соответствующие меры по исправлению технических ошибок по информационному взаимодействию, оператор по истечению одного месяца с момента возникновения технических ошибок отключает соответствующий сервис владельца объекта информатизации или приостанавливает подключение инициатора реализации интеграционного сервиса, заблаговременно сообщив участникам реализации интеграционного сервиса, до момента устранения технических ошибок.
15. В случае неисправности каналов связи, проведения провайдерами услуг связи плановых профилактических работ на линиях связи срок устранения сбоя определяется регламентом провайдера.
16. Организационные мероприятия включают доступ персонала к серверам, активному сетевому оборудованию, системе электропитания серверов.
17. Защита информации при реализации интеграционного сервиса обеспечивается:
1) использованием механизмов контроля целостности и достоверности информации, в том числе подтверждением авторства, подписанных XML сообщений;
2) авторизацией объектов информатизации на ШЭП, ВШЭП по логину и паролю, которые выдаются оператором, и по транспортной подписи;
3) журналированием всех событий на ШЭП;
4) мероприятиями технического и организационного характера по защите информации в соответствии с Законом.
18. Подтверждением авторства сообщений является положительный результат проверки соответствия транспортной подписи регистрационным свидетельством ЭЦП владельца объекта информатизации, направившего сообщение.
19. Транспортная подпись не содержит метку времени. Наличие метки времени в бизнес-данных объекта информатизации регулируется в соответствии с согласованным техническим документом на интеграцию. ШЭП не проводит проверку на наличие метки времени в бизнес-данных объекта информатизации.
20. Проверка транспортной подписи в ЕТС ГО выполняется на ШЭП. Транспортная подпись ШЭП не содержит метку времени.
21. При вызове сервиса на ШЭП использование транспортной подписи осуществляется по сценарию использования транспортной подписи согласно приложению 6 к настоящим Правилам.
22. Проверка транспортной подписи в ЕТС ГО на ШЭП состоит из процедур:
1) проверка принадлежности ЭЦП отправителю сообщения;
2) проверка действительности ЭЦП.
23. При информационном взаимодействии все электронные сообщения должны быть подписаны ЭЦП владельцев объектов информатизации, за исключением информационных взаимодействий объектов информатизации, реализованных до вступления в силу настоящих Правил.
24. При применении ЭЦП при информационном взаимодействии объектов информатизации необходимо руководствоваться Законом Республики Казахстан от 7 января 2003 года "Об электронном документе и электронной цифровой подписи".
25. Защиту информации от несанкционированного доступа на уровне прикладного программного обеспечения, своевременную передачу и неизменность передаваемых сведений обеспечивает ШЭП.
26. Владелец объекта информатизации уведомляет уполномоченный орган и всех пользователей интеграционного сервиса за три календарных дня в случае временного отключения сервиса (модификации сервиса, модификации объекта информатизации, предоставляющей доступ к сервису) или не позднее месяца в случае отключения сервиса в связи с прекращением работы.
27. Владельцы объекта информатизации определяют ответственных лиц, которые обеспечивают информационную безопасность и постоянную готовность программных и технических средств.
28. В случае изменения состава ответственных лиц (перевода или прекращения трудового договора) в недельный срок производится взаимное информирование об имеющихся изменениях, и сообщаются новые сведения об ответственных лицах по своевременному исполнению положений настоящих Правил.
| Приложение 1 к Правилам интеграции объектов информатизации "электронного правительства" |
Форматы данных
1. Описание сообщений асинхронного канала
1.1. Интерфейс сервиса на ШЭП:
Метод для отправки сообщений на асинхронный канал ШЭП (SendMessage):
Запрос на предоставление Сервиса (SendMessageRequest) содержит следующие поля: Формат данных SendMessageRequest
Поле | Тип | Обязательность | Описание |
request | AsyncSendMessagerequest | Да | Запрос |
messageInfo | AsyncMessageInfo | Дa | Мета данные сообщения |
messageId | xsd: string | Нет | Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение) |
correlationId | xsd: string | Нет | Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы (отправителя) система отрабатывающая сообщение) |
serviceId | xsd: string | Да | Идентификатор сервиса |
messageType | xsd: string | Да |
Тип сообщения: |
routeId | xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) |
messageDate | xsd: dateTime | Да | Дата создания сообщения |
sessionId | guid | Да | Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо. |
sender | SenderInfo | Да | Объект информация об отправителе (заполняется отправителем) |
senderId | xsd: string | Да | Идентификатор отправителя (системы отправителя) |
password | xsd: string | Нет | Пароль отправителя |
properties | property | Нет | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя |
key | xsd: int | Ключ свойства | |
value | xsd: int | Нет | Значение свойства |
messageData | messagedata | Да | Объект передачи данных |
data | xsd: Anytype | Нет | Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ ШЭП на сообщение (sendMessageResponse) представляет собой массив элементов со следующими полями: Формат данных SendMessageResponse
Поле | Тип | Обязанность | Описание |
response | AsyncSendMessagerequest | Да | Ответ |
messageId | xsd: string | Да | Идентификатор сообщения |
correlationId | xsd: string | Да | Идентификатор цепочки сообщения |
responseDate | xsd: dateTime | Да | Дата ответа |
sessionId | Guidа | Нет | Идентификатор сессии ШЭП. |
Ответ об ошибке (SendMessagefault) представляет собой массив элементов со следующими полями: Формат данных SendMessagefault
Поле | Тип | Обязанность | Описание |
ErrorInfo | ErrorInfo | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод отправки уведомления на ШЭП о доставке или не доставке сообщения (SendDeliveryNotification):
Запрос на уведомление представляет собой массив элементов со следующими полями (sendDeliveryNotificationRequest): Формат данных SendDeliveryNotificationRequest
Поле | Тип | Обязанность | Описание |
request | Async SendDeliveryNotificationRequest | Да | Запрос |
notification | DeliveryNotification | Да | Уведомления о статусе доставки сообщения |
messageId | xsd: string | Да | Идентификатор сообщения |
serviceid | xsd: string | Да | Идентификатор сервиса |
notificationDate | xsd: dateTime | Да | Дата создания уведомления |
deliveryStatus | deliveryStatusInfo | Да | Статус доставки (приема сообщения) |
receiveStatus | xsd: string | Да |
Статус доставки сообщения: |
statusDate | xsd: dateTime | Да | Дата изменения статуса |
resendMessage | xsd: string | Да | Повторное сообщение |
error | ErrorInfo | Нет | Информация об ошибке |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Нет | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
requestDate | xsd: dateTime | Да | Дата запроса |
sender | SenderInfo | Нет | Отправитель |
senderId | xsd: string | Да | Идентификатор отправителя |
password | xsd: string | Нет | Пароль отправителя |
Ответ на уведомление (sendDeliveryNotificationResponse) представляет собой массив со следующими полями: Формат данных SendDeliveryNotificationResponse
Поле | Тип | Обязанность | Описание |
Response | Async SendDeliveryNotificationResponse | Ответ | |
notificationId | xsd: string | Да | Идентификатор сообщения |
responseDate | xsd: dateTime | Да | Дата ответа |
sessionId | guid | Нет | Идентификатор сессии ШЭП |
Ответ об ошибке (SendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Поле | Тип | Обязанность | Описание |
ErrorInfo | ErrorInfo | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод получения статуса сообщения с ШЭП (GetMessageStatus)
Запрос на статус сообщения (GetMessageStatusRequest) представляет собой массив элементов со следующими полями: Формат данных GetMessageStatusRequest
Поле | Тип | Обязанность | Описание |
request | AsyncGetmessagestatus | Да | Запрос |
messageId | xsd: string | Да | Идентификатор сообщения |
requestDate | xsd: dateTime | Да | Дата запроса |
sender | senderinfo | Да | Объект информация об отправителе (заполняется отправителем) |
senderId | xsd: string | Да | Идентификатор отправителя (системы отправителя) |
password | xsd: string | Нет | Пароль отправителя |
properties | property | Нет | Массив свойств запроса |
key | xsd: int | Ключ свойства | |
value | xsd: int | Нет | Значение свойства |
В ответе на запрос на статус (getMessageStatusResponse) должна быть возвращена структура следующего вида: Формат данных GetMessageStatusResponse
Поле | Тип | Обязанность | Описание |
response | Async GetmessagestatusResponse | Ответ | |
messageState | messageState | Да | Состояние сообщения |
responseDate | xsd: dateTime | Да | Дата ответа |
sessionId | xsd: string | Нет | Идентификатор сессии на ШЭП |
status | MessagestatusInfo | Объект "Информация о статусе" | |
statusсode | xsd: int | Да | Код статуса сообщения |
statusmessage | xsd: string | Да | Сообщение статуса |
statusDate | xsd: dateTime | Да | Дата изменения статуса |
В случае возникновении ошибки в системе, передается сообщение об ошибке (SendMessageFault), которая представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Поле | Тип | Обязанность | Описание |
ErrorInfo | ErrorInfo | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод выборки сообщений с ШЭП (GetMessages) осуществляется по параметрам:
идентификатору сообщения + получателю (только для запросившего)+идентификатору сервиса;
идентификатору цепочки сообщений + получателю (только для запросившего) + идентификатору сервиса;
получателю (только для запросившего) + идентификатору сервиса.
Параметр GetMessagesRequest.
Запрос содержит следующие поля: Формат данных GetMessageRequest.
Поле | Тип | Обязанность | Описание |
request | Async GetmessagesRequest | Да | Метаданные запроса |
messageId | xsd: string | Нет | Идентификатор сообщения |
correlationId | xsd: string | Нет | Идентификатор цепочки сообщения |
requestdate | xsd: dateTime | Нет | Дата запроса |
serviceId | xsd: string | Да | Идентификатор сервиса |
sender | Senderinfo | Нет | Объект информация об отправителе (заполняется отправителем) |
senderId | xsd: string | Идентификатор отправителя (системы отправителя) | |
password | xsd: string | Пароль отправителя | |
amount | xsd: int | Нет |
Максимальное кол-во сообщений в выборке. |
properties | Property | Да | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя |
key | xsd: string | Да | Ключ свойства |
value | xsd: string | Да | Значение свойства |
Ответ getMessagesResponse со следующими полями: Формат данных GetMessageResponse
Поле | Тип | Обязанность | Описание |
response | Async GetmessageResponse | Да | Ответ |
responseDate | xsd: dateTime | Да | Дата ответа |
sessionId | xsd: string | Да | Идентификатор сессии на ШЭП |
messages | Asynmessage | Нет | |
messageInfo | Asynmessageinfo | Да | Метаданные сообщения |
messageId | xsd: string | Нет | Идентификатор сообщения |
correlationId | xsd: string | Да | Идентификатор цепочки |
serviceId | xsd: string | Да | Идентификатор сервиса |
messageType | xsd: string | Да |
Тип сообщения: |
routeId | xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) |
messageDate | xsd: dateTime | Да | Дата создания сообщения |
sessionId | guid | Нет | Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо. |
Sender | SenderIndo | Да | Объект информация об отправителе (заполняется отправителем) |
senderId | xsd: string | Да | Идентификатор отправителя (системы отправителя) |
password | xsd: string | Нет | Пароль отправителя |
properties | property | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя | |
Key | xsd: string | Да | Ключ свойства |
Value | xsd: string | Да | Значение свойства |
messageData | messageData | Да | Объект передачи данных |
Data | xsd: Anytype | Да | Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ об ошибке (SendMessagefault) представляет собой массив элементов со следующими полями: Формат данных SendMessagefault
Поле | Тип | Обязанность | Описание |
ErrorInfo | ErrorInfo | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии, в которой произошла ошибка |
1.2. Интерфейс для реализации сервиса на стороне пользователей ШЭП для работы с асинхронным каналом.
Сервис реализуется как на стороне провайдера сервиса, так и на стороне использующей сервис. Сервис реализуют в случае необходимости доставки ШЭП сообщений методом вызова сервиса получателя сообщения (PUSH).
Метод приема сообщений: (SendMessage)
Запрос на предоставление cообщения (SendMessageRequest) содержит следующие поля: Формат данных SendMessageRequest
Поле | Тип | Обязанность | Описание |
request | Async SendMessageRequest | Да | |
messageInfo | Async SendMessageInfo | Да | Мета данные сообщения |
messageId | xsd: string | Нет |
Идентификатор сообщения. |
correlationId | xsd: string | Нет | Идентификатор цепочки сообщений. Генерируется ШЭП. В случае отправки сообщения типа REQUEST на ШЭП данное поле должно быть пустым. При отправке сообщений других типов на ШЭП, данное поле ДОЛЖНО БЫТЬ ЗАПОЛНЕНО. В случае передачи сообщения получателю номер будет проставлен ШЭП. |
serviceId | xsd: string | Да | Идентификатор взаимодействия. По реестру сервисов ШЭП. |
messageType | xsd: string | Да |
Тип сообщения: |
routeId | xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) |
messageDate | xsd: dateTime | Да | Дата создания сообщения |
sessionId | guid | Нет | Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо. |
sender | SenderInfo | Да | Объект информация об отправителе (заполняется отправителем) |
senderId | xsd: string | Да | Идентификатор отправителя (системы отправителя) |
password | xsd: string | Нет | Пароль отправителя |
properties | Property | Нет | Массив дополнительных свойств сообщения |
key | xsd: int | Да | Ключ свойства |
value | xsd: int | Да | Значение свойства |
messageData | messageData | Да | Объект передачи данных |
data | xsd: Anytype | Да | Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ ШЭП на сообщение (sendMessageResponse) представляет собой массив элементов со следующими полями: Формат данных SendMessageResponse
Поле | Тип | Обязанность | Описание |
response | Async SendMessageResponse | Да | Ответ |
messageId | xsd: string | Да | Идентификатор сообщения |
correlationId | xsd: string | Да | Идентификатор цепочки сообщения |
responseDate | xsd: dateTime | Да | Дата ответа |
sessionId | guid | Нет | Идентификатор сессии ШЭП. |
Ответ об ошибке (SendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Поле | Тип | Обязанность | Описание |
ErrorInfo | ErrorInfo | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод приема уведомлений об изменении статуса сообщения в ШЭП (ChangeMessageStatusNotification)
Запрос уведомления об изменении статуса сообщения (ChangeMessageStatusNotificationRequest) представляет собой массив элементов со следующими полями: Формат данных ChangeMessageStatusNotificationRequest
Поле | Тип | Обязанность | Описание |
request | Async ChangeMessageStatus NotificationRequest | Да | |
notification | ChangeStatus Notification | Да | Уведомления о статусе доставки сообщения |
notificationid | xsd: string | Да | Идентификатор уведомления |
messageId | xsd: string | Да | Идентификатор сообщения |
notificationDate | xsd: dateTime | Да | Дата создания уведомления |
messageState | messageState | Да | Состояние сообщения |
Status | messageStatusinfo | Да | Статус доставки (приема сообщения) |
statusCode | xsd: string | Да | Код статуса |
statusMessage | xsd: string | Да | Сообщения статуса |
statusDate | xsd: dateTime | Да | Идентификатор маршурута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) |
error | Нет | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorMessage | xsd: string | Да | Сообщение ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | xsd: string | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
requestdate | xsd: dateTime | Да | Дата запроса |
sessionid | guid | Нет | Идентификатор сессии |
Ответ о принятии уведомления (changeMassageStatusNotificationResponse) представляет собой массив элементов со следующими полями: Формат данных ChangeMessageStatusNotificationResponse
Поле | Тип | Обязанность | Описание |
response | Async ChangeMessageStatus NotificationResponse | Да | Ответ |
responseDate | xsd: dateTime | Да | Дата ответа |
sessionid | guid | Да | Идентификатор сессии (указанное в запросе) |
Ответ об ошибке (sendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Поле | Тип | Обязанность | Описание |
ErrorInfo | ErrorInfo | Информация об ошибке | |
errorCode | xsd: string | Да | Код ошибки |
errorData | xsd: string | Да | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Да | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | guid | Нет | Идентификатор сессии в которой произошла ошибка |
2. Описание сообщений синхронного канала
2.1. Интерфейс сервиса на ШЭП:
Метод отправки сообщений по синхронному каналу (SendMessage)
Запрос на предоставление Сервиса (SendMessageRequest) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageRequest
Поле | Тип | Обязанность | Описание |
request | SyncsendMessagerequest | Да | Запрос |
requestInfo | SyncMessageInfo | Да | Информация о сообщении запроса |
messageId | xsd: string | Да | Идентификатор сообщения в системе получателя (генерирует ШЭП) |
correlationId | xsd: string | Нет | Идентификатор цепочки сообщения в системе получателя запроса (Генерирует ШЭП) |
serviceid | xsd: string | Да | Идентификатор взаимодействия (ведется в реестре сервисов ШЭП) |
messegeDate | xsd: dateTime | Да | Дата создания сообщения в Системе Отправителя (Инициатора взаимодействия). Заполняется Отправителем (инициатором взаимодействия). |
routeId | xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой Отправителя, т.е. Инициатора взаимодействия) |
sessionId | guid | Нет | Идентификатор сессии на ШЭП. Устанавливается на ШЭП. |
sender | senderinfo | Да | Объект информация об отправителе (заполняется отправителем) |
senderId | xsd: string | Да | Идентификатор отправителя (системы отправителя) |
password | xsd: string | Да | Пароль отправителя |
properties | property | Нет | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя |
key | xsd: int | Ключ свойства | |
value | xsd: int | Значение свойства | |
requestData | requestData | Да | Объект передачи данных запроса |
data | xsd: Anytype | Нет | Данные сообщения (формат определяется системой получателя сообщения) |
Ответное сообщение на запрос (SendMessageResponse) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageResponse.
Поле | Тип | Обязанность | Описание |
response | SyncsendMessageresponse | Да | Ответ |
responseInfo | SyncMessageInfoResponse | Да | Информация об ответе |
messageId | xsd: string | Да | Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение) |
correlationId | xsd: string | Нет | Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы отправителя (система отрабатывающая сообщение) |
responseDate | xsd: dateTime | Да | Дата ответа в системе получателя запроса (заполняется системой получателя запроса) |
sessionId | guid | Нет | Идентификатор сессии на ШЭП. Устанавливается на ШЭП. При отправки ответа системой получателя запроса заполнять не нужно. |
status | StatusInfo | Да | Объект "Информация о статусе" |
code | xsd: int | Да | Код статуса (проставляется системой получателя запроса) |
message | xsd: string | Да | Сообщение о статусе |
responseData | responsedata | Да | Объект "данные ответа" |
data | xsd: Anytype | Нет | Объект данные сообщения (формат определяется системой получателя сообщения) |
Сообщение об ошибке (SendMessageFault1_SendMessageFault) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageFault
Поле | Тип | Обязанность | Описание |
errorCode | xsd: string | Да | Код ошибки |
errorMessage | xsd: string | Да | Сообщение ошибки |
errorData | xsd: string | Нет | Дополнительное описание ошибки |
errorDate | xsd: dateTime | Нет | Дата ошибки |
subError | ErrorInfo | Нет | Дочерняя ошибка |
sessionId | Guid | Нет | Идентификатор сессии в которой произошла ошибка |
| Приложение 2 к Правилам интеграции объектов информатизации "электронного правительства" |
|
| Форма |
Заявка на публикацию сервиса на ШЭП 1. Описание сервисов
Элемент | Описание | Пояснение по заполнению | Информация | |
1. Сведения об организации-владельце объекта информатизации | ||||
1 | Наименование | Организация, осуществляющая права собственности на объект информатизации, реализующий электронный сервис | Не допускаются сокращения в названии, а также использование аббревиатур. | |
2 | Краткое наименование | Краткое наименование организации | Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура. | |
3 |
Идентификатор в сертификатах Национальный удостоверяющий центр Республики Казахстан (индивидуальный идентификационный номер (далее – ИИН) для индивидуальных предпринимателей (далее - ИП), | ИИН для ИП/БИН | ||
2.Контактные данные разработчиков интеграционного сервиса со стороны владельца объекта информатизации | ||||
4 | Наименование | Объект информатизации, предоставляющий данный электронный сервис. | Не допускаются сокращения в названии, а также использование аббревиатур. | |
5 | Краткое наименование | Краткое наименование объекта информатизации | Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура. | |
6 | Эксплуатационное подразделение | Подразделение, ответственное за эксплуатацию электронного сервиса | Не допускаются сокращения в названии, а также использование аббревиатур. | |
7 | Руководитель эксплуатационного подразделения | ФИО, должность, контактный телефон, электронная почта | Необходимо указывать контактное лицо, с кем контактировать для организации взаимодействия с администраторами и разработчиками сервиса | |
8 | Должностное лицо, ответственное за эксплуатацию | ФИО, должность, контактный телефон, электронная почта | Необходимо указывать контактное лицо, напрямую отвечающее за администрирование сервиса - с кем контактировать для уточнения технических деталей функционирования сервиса или устранения инцидентов при его неработоспособности (технический специалист). | |
9 |
Контактные данные разработчиков интеграционного сервиса | ФИО физического лица\наименование юридического лица, контактное лицо, контактный телефон, электронная почта | Необходимо указывать контактное лицо, напрямую отвечающее за разработку (техническую поддержку) сервиса - с кем контактировать для уточнения технических деталей функционирования сервиса или устранения инцидентов при его неработоспособности (технический специалист). | |
3.Сведения об объекте информатизации, предоставляющем сервис | ||||
10 | Краткое наименование объекта информатизации | Краткое наименование объекта информатизации | Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура | |
11 | Наименование | Наименование объекта информатизации | ||
12 | Среда использования | Среда использования сервиса |
Выбрать из нижеперечисленного: | |
4.Сведения о документах | ||||
13 | Основание на публикацию сервиса на ШЭП | Ссылка на документ | ||
5.Сведения о сервисе | ||||
14 | Наименование | Полное наименование электронного сервиса | Не допускаются сокращения в названии, а также использование аббревиатур | |
15 | Описание | Развернутое описание назначения электронного сервиса | Необходимо указывать исчерпывающее описание назначения электронного сервиса. | |
16 | Ключ сервиса | Условное наименование сервиса |
1) Заполнять латинскими буквами. | |
17 | Режим взаимодействия сервиса | Выбрать из списка, руководствуясь примечанием |
Необходимо выбрать "Синхронный", "Асинхронный" режим. | |
18 | Адрес системы | URL системы, предоставляющий сервис |
Для ИС в ЕТС ГО: необходимо указать IP адрес в ЕТС ГО. | |
19 | Признак наличия маршрутизации сообщений | Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса) |
Признак наличия маршрутизации сообщений | |
20 | Режим отправки сообщений | Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. |
PUSH или PULL | |
21 | Необходимость получения уведомления ИС - отправителей сообщений об изменении статусов сообщений от ШЭП | Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. |
0 - не требуется, | |
22 | Необходимость получения дополнительного уведомления о доставке от ШЭП | Выбрать из списка, руководствуясь примечанием (только для асинхронных сервисов) |
0 - не требуется, | |
6. Тестовые данные | ||||
23 | Адреса тестового сервиса | Адреса тестового сервиса (в интернете, ЕТС) | ||
2. Пользователи сервиса
1 | Наименование владельца объекта информатизации (пользователя) | |||
2 | Наименование объекта информатизации | |||
3 | Адрес объекта информатизации |
Для синхронных сервисов – IP адрес |
| Приложение 3 к Правилам интеграции объектов информатизации "электронного правительства" и |
|
| Форма |
Заявка на организацию доступа к информационным ресурсам в ЕТС ГО
№ | Наименование поля | Информация | |||
1 | Организация | ||||
2 | Управление, отдел, должность | ||||
3 | ФИО, контактный телефон, email | ||||
4 | К какому ресурсу (ам) необходим доступ | ||||
5 | Перечень работ проводимых на серверах | ||||
6 | Откуда (IP адреса) |
Куда | Порт | ФИО, должность | Адрес, кабинет, контактный телефон, email |
IP ШЭП | IP объекта информатизации | Порт объекта информатизации | |||
IP объекта информатизации | IP ШЭП | Порт ШЭП | |||
7 | Протокол (а), порт (ы) к которым необходим доступ | ||||
| Приложение 4 к Правилам интеграции объектов информатизации "электронного правительства |
|
| Форма |
VPN - форма
| Заполняет инициатор интеграционного сервиса (сетевые администраторы) | Заполняет оператор |
Контактная информация | ||
Наименование объекта информатизации | ||
ФИО | ||
Адрес электронной почты | ||
Номер телефона (рабочий, сотовый) | ||
Дополнительная информация | ||
ФИО | ||
Адрес электронной почты | ||
Номер телефона (рабочий, сотовый) | ||
Техническая информация | ||
Информация о шлюзе VPN | ||
Режим туннеля (транспорт/туннель) | ||
Публичный Peer IP-адрес | ||
IP-адреса для взаимодействия | ||
Свойства Туннеля | Фаза 1 | |
Метод аутентификации | ||
Частный общий ключ | ||
Тип криптографии | ||
Протокол Деффи-Хеллмана | ||
Криптографический алгоритм | ||
Алгоритм хеширования | ||
Срок действия (для пересмотра построения туннеля) | ||
Свойства Туннеля | Фаза 2 | |
Инкапсуляция (ESP или AH) | ||
Криптографический алгоритм | ||
Метод алгоритма | ||
Группа совершенной прямой секретности | ||
Срок действия (для пересмотра построения туннеля) | ||
Величина в Kб (для пересмотра построения туннеля) | ||
| Приложение 5 к Правилам интеграции объектов информатизации "электронного правительства" |
|
| Форма |
Заявка на интеграцию объекта информатизации с ШЭП для использования опубликованного на ШЭП сервиса
№ | Элемент | Описание | Информация |
1. Сведения об организации-владельце сервиса | |||
1 | Наименование | Организация, осуществляющая права собственности на объект информатизации, реализующую электронный сервис. | Не допускаются сокращения в названии, а также использование аббревиатур. |
2. Сведения об объекте информатизации, предоставляющем сервис | |||
2 |
| ServiceID опубликованного сервиса |
|
3 | Наименование | Наименование объекта информатизации | Не допускаются сокращения в названии, а также использование аббревиатур. |
4 | Основание на интеграцию | Ссылка на документ | |
3. Сведения о пользователе сервиса | |||
5 | Сведения об организации-владельце | ||
6 | Наименование объекта информатизации, предоставляющего электронный сервис | Не допускаются сокращения в названии, а также использование аббревиатур. | |
7 | Краткое наименование объекта информатизации | Краткое наименование объекта информатизации | Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура |
8 | Адрес системы | URL системы, предоставляющий сервис |
Для синхронных сервисов – IP адрес |
9 | Описание | Развернутое описание назначения электронного сервиса | Необходимо указывать исчерпывающее описание назначения электронного сервиса. |
| Приложение 6 к Правилам интеграции объектов информатизации "электронного правительства" |
Сценарий использования транспортной подписи
1. Сценарий приема сообщения с использованием транспортной подписи ШЭП:
1) ШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения, транспортную подпись объектов информатизации);
2) ШЭП подписывает сообщение транспортной подписью;
3) ШЭП передает подписанное сообщение ВШЭП (при взаимодействии с ИС вне ЕТС ГО);
4) ВШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения, транспортную подпись объектов информатизации).
Данный сценарий используется при взаимодействии объектов информатизации.
2. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны:
1) отправитель подписывает сообщение транспортной подписью и отправляет на ШЭП;
2) ШЭП проверяет транспортную подпись сообщения:
проверяет соответствие ИИН/БИН указанного в ЭЦП на ИИН/БИН ИП/юридического лица, внесенного в систему при регистрации объекта информатизации;
проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).
3. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны, с использованием метода шифрования сообщений:
1) отправитель сообщения шифрует сообщение;
2) отправитель сообщения подписывает сообщения транспортной подписью и отправляет ШЭП;
3) ШЭП расшифровывает сообщение;
4) ШЭП проверяет транспортную подпись сообщения:
проверяет соответствие ИИН/БИН указанного в ЭЦП на ИИН/БИН ИП/юридического лица, внесенного в систему при регистрации объекта информатизации;
проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).