В соответствии с подпунктами 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 |
Правила
интеграции объектов информатизации "электронного правительства"
Сноска. Правила в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 29.04.2020 № 165/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
Глава 1. Общие положения
1. Настоящие Правила интеграции объектов информатизации "электронного правительства" (далее – Правила) разработаны в соответствии с подпунктом 13) статьи 7 Закона Республики Казахстан "Об информатизации" (далее – Закон) и определяют порядок интеграции объектов информатизации "электронного правительства.
Сноска. Пункт 1 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 02.09.2022 № 307/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).2. В настоящих Правилах используются следующие основные понятия:
1) информационная система (далее – ИС) – организационно-упорядоченная совокупность информационно-коммуникационных технологий, обслуживающего персонала и технической документации, реализующих определенные технологические действия посредством информационного взаимодействия и предназначенных для решения конкретных функциональных задач;
2) объекты информатизации – электронные информационные ресурсы, программное обеспечение, интернет-ресурс и информационно-коммуникационная инфраструктура;
3) интеграция объектов информатизации – мероприятия по организации и обеспечению информационного взаимодействия между объектами информатизации на основании используемых в Республике Казахстан стандартных протоколов передачи данных;
4) уполномоченный орган в сфере информатизации (далее – уполномоченный орган) – центральный исполнительный орган, осуществляющий руководство и межотраслевую координацию в сфере информатизации и "электронного правительства";
5) сервис по предоставлению открытых данных – способ передачи данных в одностороннем порядке между объектами информатизации;
6) безопасность веб-сервисов (WebServiceSecurity) (далее – WSSecurity) – стандарт применения функций безопасности при обмене сообщениями между веб-сервисами SOAP. При применении стиля архитектуры программного обеспечения для распределенных систем (REST) безопасность сервиса обеспечивается через меры безопасности HTTPs, и применением аутентификации пользователей;
7) государственный сервис контроля доступа к персональным данным (далее – государственный сервис) – услуга, обеспечивающая информационное взаимодействие собственников и (или) операторов, третьих лиц с субъектом персональных данных и уполномоченным органом при доступе к персональным данным, содержащимся в объектах информатизации государственных органов и (или) государственных юридических лиц, включая получение от субъекта персональных данных согласия на сбор, обработку персональных данных или их передачу третьим лицам;
8) протокол Деффи-Хеллмана – криптографический протокол, позволяющий двум и более сторонам обменяться заранее согласованным общим секретным ключом, используя пару публичных и частных ключей в незащищенном от прослушивания канале связи;
9) публичный Peer IP-адрес – уникальный IP-адрес устройства, терминирующего VPN-туннель и используемого в сети Интернет, на стороне инициатора и/или владельца объекта информатизации;
10) интеграционный сервис – способ информационного взаимодействия объектов информатизации;
11) инициатор интеграционного сервиса – владелец объекта информатизации, инициирующий запрос на предоставление интеграционного сервиса;
12) владелец интеграционного сервиса (далее – владелец сервиса) – собственник или владелец объекта информатизации, предоставляющий интеграционный сервис;
13) расширяемый язык разметки (eXtensible Markup Language) (далее – XML) – расширяемый язык разметки, используемый для хранения и передачи данных в структурированном и машиночитаемом формате;
14) клиент-коннектор – программное обеспечение, предоставляющее инициатору объекта информатизации возможность генерации точки подключения к интеграционному сервису, размещенному на ШЭП, ВШЭП с поддержкой форматов ШЭП, ВШЭП;
15) транспортная подпись – электронная цифровая подпись, используемая для обеспечения целостности и авторства передаваемых сообщений при информационном взаимодействии ИС с применением спецификации WSSecurity;
16) удостоверяющий центр – юридическое лицо, удостоверяющее соответствие открытого ключа электронной цифровой подписи закрытому ключу электронной цифровой подписи, а также подтверждающее достоверность регистрационного свидетельства;
17) API с открытым правом доступа (OpenAPI) – API, выставленный в свободном доступе в сети Интернет, не требующий согласования или разрешения Владельца электронного информационного ресурса для осуществления информационного взаимодействия;
18) журнал логирования – файлы, содержащие информацию о работе системы, используемую для мониторинга ее работы и выявления причин, в случае возникновения сбоя;
19) единая транспортная среда государственных органов (далее – ЕТС ГО) – сеть телекоммуникаций, входящая в информационно-коммуникационную инфраструктуру "электронного правительства" и предназначенная для обеспечения взаимодействия локальных (за исключением локальных сетей, имеющих доступ к Интернету), ведомственных и корпоративных сетей телекоммуникаций государственных органов, их подведомственных организаций и органов местного самоуправления, а также иных субъектов информатизации, определенных уполномоченным органом, с соблюдением требуемого уровня информационной безопасности;
20) простой протокол доступа к объектам (SimpleObjectAccessProtocol) (далее – SOAP) – протокол, основанный на XML для передачи сообщений при интеграции ИС;
21) сервис-коннектор – программное обеспечение, позволяющее владельцу объекта информатизации создавать и размещать интеграционные сервисы на ШЭП;
22) реестр сервисов – перечень зарегистрированных в шлюзе "электронного правительства" и внешнем шлюзе "электронного правительства" сервисов, с описанием сервиса;
23) объекты информатизации "электронного правительства" – государственные электронные информационные ресурсы, программное обеспечение государственных органов, интернет - ресурс государственного органа, объекты инфраструктуры "электронного правительства", в том числе сервисный программный продукт, программное обеспечение и информационные системы иных лиц, предназначенные для формирования государственных электронных информационных ресурсов в рамках осуществления государственных функций и оказания государственных услуг;
24) оператор информационно-коммуникационной инфраструктуры "электронного правительства" (далее – оператор) – юридическое лицо, определяемое Правительством Республики Казахстан, на которое возложено обеспечение функционирования закрепленной за ним информационно-коммуникационной инфраструктуры "электронного правительства";
25) сервисный интегратор "электронного правительства" (далее – сервисный интегратор) – юридическое лицо, определяемое Правительством Республики Казахстан, на которое возложены функции по методологическому обеспечению развития архитектуры "электронного правительства" и типовой архитектуры "электронного акимата", а также иные функции, предусмотренные Законом;
26) внешний шлюз "электронного правительства" (далее – ВШЭП) – подсистема шлюза "электронного правительства", предназначенная для обеспечения взаимодействия информационных систем, находящихся в единой транспортной среде государственных органов, с информационными системами, находящимися вне единой транспортной среды государственных органов;
27) платежный шлюз "электронного правительства" (далее – ПШЭП) – ИС, автоматизирующая процессы передачи информации о проведении платежей в рамках оказания возмездных услуг, оказываемых в электронной форме;
28) шлюз "электронного правительства" (далее – ШЭП) – ИС, предназначенная для интеграции объектов информатизации "электронного правительства" с иными объектами информатизации "электронного правительства";
29) электронное сообщение (далее - сообщение) – электронный документ в формате XML, JSON, предназначенный для обмена информацией между объектами информатизации;
30) электронная цифровая подпись (далее – ЭЦП) – набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания;
31) Application programming interface (далее – API) – интерфейс программирования приложений, набор готовых программ, предоставляемых сервисом для информационного взаимодействия между объектами информатизации;
32) инкапсуляция AH (AuthenticationHeader) – инкапсуляция аутентифицирующего заголовка, которая позволяет аутентифицировать соседнего узла в туннеле VPN и обеспечить целостность передаваемых данных без шифрования. Значение в поле протокола заголовка IP – равное UDP порту 51;
33) Hyper Text Transfer Protocol (далее – HTTP) — протокол прикладного уровня передачи данных изначально — в виде гипертекстовых документов в формате HTML, используемый для передачи произвольных данных;
34) IP (Internet Protocol) – сетевая модель передачи данных, представленных в цифровом виде;
35) Java Script Object Notation (далее – JSON) – текстовый формат обмена данными, основанный на JavaScript;
36) Representational State Transfer (далее – REST) — стиль архитектуры программного обеспечения для взаимодействия компонентов распределенного приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределенных систем или взаимодействия сервисов, использующий стандарты, такие как HTTP, URL, JSON и XML;
37) SSL-сертификат (Secure Sockets Layer) – регистрационное свидетельство, предназначенное для использования интернет-ресурсом или ИС для обеспечения процедуры аутентификации;
38) TCP (Transmission Control Protocol) – один из основных протоколов передачи данных Интернета, предназначенный для управления передачей данных;
39) UDP (User Datagram Protocol) – протокол пользовательских датаграмм, один из ключевых элементов TCP/IP, набора сетевых протоколов для Интернета;
40) URL (Uniform Resource Locator) – единообразный локатор (определитель местонахождения) ресурса, указывает адрес сервиса объекта информатизации;
41) Virtual Private Network (далее – VPN) – виртуальная частная сеть для обмена информацией двух узлов.
Сноска. Пункт 2 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 02.09.2022 № 307/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).3. Интеграции посредством ШЭП, ВШЭП не подлежат:
1) сервисы, предоставляемые удостоверяющими центрами;
2) объекты информатизации, которые содержат сведения, составляющие государственные секреты Республики Казахстан и служебную информацию с пометкой "Для служебного пользования";
3) объекты информатизации, размещенные на информационно-коммуникационной платформе "электронного правительства" и предназначенные для формирования единого пространства данных для целей предоставлений аналитической информации по деятельности Правительства Республики Казахстан;
3-1) объекты информатизации, размещенные на информационно-коммуникационной платформе "электронного правительства" и предназначенные для осуществления налогового и таможенного администрирования в соответствии с законодательством Республики Казахстан;
4) сервисы по предоставлению открытых данных посредством OpenAPI, API, с использованием форматов XML, JSON и протоколов HTTP и HTTPS, посредством архитектурного стиля REST, включая интернет-порталы открытых данных, открытых бюджетов и открытых нормативных правовых актов.
Сноска. Пункт 3 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 02.09.2022 № 307/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).4. Негосударственная ИС интегрируется с ИС государственного органа только через ВШЭП, введенный в промышленную эксплуатацию.
При интеграции также учитывается наличие договора совместных работ по информационной безопасности государственных и негосударственных ИС.
Подключение негосударственных ИС к интеграционному сервису осуществляется в соответствии с параграфом 3 главы 2 настоящих Правил.
Подключение ИС государственного органа к интеграционному сервису государственного органа осуществляется в соответствии с параграфом 4 главы 2 настоящих Правил.
Сноска. Пункт 4 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).5. Мероприятия по интеграции объектов информатизации осуществляются посредством веб портала "электронного правительства" с учетом форматов данных, указанных в приложении 1 к настоящим Правилам.
6. Интеграция объектов информатизации осуществляется при условии наличия интеграционного сервиса в реестре сервисов на веб-портале "электронного правительства".
7. Оператор вносит изменения в сервис или исключает его из реестра сервисов по запросу Владельца сервиса или уполномоченного органа с уведомлением уполномоченного органа и сервисного интегратора.
Оператор в случае неиспользования государственного сервиса инициатором интеграционного сервиса отключает его от сервиса, содержащего персональные данные и конфиденциальную информацию, по запросу уполномоченного органа и (или) владельца сервиса, и (или) сервисного интегратора с уведомлением уполномоченного органа.
Сноска. Пункт 7 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).8. При оказании услуг в электронном виде объект информатизации направляет сведения об использовании платежей в ПШЭП.
Все заявки и документы удостоверяются ЭЦП уполномоченных лиц участников интеграционного взаимодействия.
Если информационная система инициатора интеграционного сервиса относится к объектам информатизации, указанным в пункте 2 статьи 49 Закона, то к заявке на подключение к сервису или на публикацию сервиса инициатор интеграционного сервиса прилагает протоколы испытаний с положительным результатом испытаний на соответствие требованиям информационной безопасности.
Сноска. Пункт 8 - в редакции приказа и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).9. Для разработки и размещения интеграционного сервиса на ШЭП, ВШЭП владелец интеграционного сервиса и инициатор интеграционного сервиса используют сервис-коннектор и клиент-коннектор для подключения к интеграционному сервису, при отсутствии иного интеграционного сервиса.
Глава 2. Порядок интеграции объектов информатизации "электронного правительства"
Параграф 1. Порядок публикации сервиса по инициативе инициатора интеграционного сервиса
10. При отсутствии сервиса в реестре сервисов инициатор интеграционного сервиса направляет посредством веб-портала "электронного правительства" запрос сервисному интегратору для предоставления рекомендаций по определению владельца объекта информатизации, в котором содержатся необходимые сведения.
11. При получении уведомления о поступлении заявки сервисный интегратор рассматривает запрос в течение 2 (двух) рабочих дней и предоставляет инициатору интеграционного сервиса рекомендации.
12. Инициатор интеграционного сервиса на основе рекомендаций сервисного интегратора авторизуется на веб-портале "электронного правительства" и направляет запрос в форме заявки на создание сервиса владельцу объекта информатизации.
13. Владелец объекта информатизации, получив уведомление о поступлении заявки на создание сервиса, в течение 2 (двух) рабочих дней рассматривает заявку. По результатам рассмотрения, согласовывает заявку либо возвращает ее на доработку инициатору, либо отказывает в создании сервиса с указанием причин.
14. В случае согласования заявки на создание сервиса, владелец объекта информатизации заполняет требования к взаимодействию с сервисом согласно приложению 2 к настоящим Правилам (далее – требования к взаимодействию с сервисом) и заявку на публикацию сервиса согласно приложению 3 к настоящим Правилам (далее – заявка на публикацию сервиса), прилагает к заявке файлы XSD сервиса, а также XML примеров запроса и ответа с тестовыми данными и направляет заявку инициатору интеграционного сервиса с уведомлением уполномоченного органа.
Сноска. Пункт 14 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).15. В случае возврата владельцем объекта информатизации заявки на создание сервиса на доработку инициатор интеграционного сервиса в течение 2 (двух) рабочих дней осуществляет доработку заявки и повторно направляет ее на рассмотрение владельцу объекта информатизации.
16. В случае отказа владельцем объекта информатизации в создании сервиса мероприятия по публикации сервиса прекращаются.
17. При поступлении заявки на публикацию сервиса оператором осуществляется проверка заявки на полноту и правильность заполнения в течение 3 (трех) рабочих дней. При отрицательном результате проверки заявки, оператор направляет заявку на доработку с указанием причин.
18. Владелец объекта информатизации в течение 2 (двух) рабочих дней дорабатывает заявку на публикацию сервиса и направляет заявку оператору на повторное рассмотрение.
19. При положительном результате проверки заявки оператор в течение 10 (десяти) рабочих дней предоставляет инициатору интеграционного сервиса доступ к тестовой среде ШЭП, ВШЭП и подключает инициатора интеграционного сервиса к сервису на тестовой среде ШЭП, ВШЭП для проведения тестирования интеграции.
20. Разработчики интеграционного сервиса со стороны владельца объекта информатизации, инициатора интеграционного сервиса вносят изменения в объекты информатизации для проведения тестирования по интеграции с объектами информатизации.
21. Совместно с разработчиками интеграционного сервиса со стороны владельца объекта информатизации, инициатора интеграционного сервиса и оператором проводится тестирование интеграционного сервиса в срок не более 3 (трех) месяцев до получения положительного результата.
Сноска. Пункт 21 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).22. Со стороны ШЭП, ВШЭП подтверждением реализации интеграционного сервиса является передача сообщений (для асинхронного сервиса – получение отправителем уникального идентификатора сообщения, для синхронного – получение ответного сообщения) между участниками взаимодействия, которая фиксируется в журнале логирования ШЭП, ВШЭП.
23. Со стороны участников взаимодействия (владельца сервиса и инициатора интеграционного сервиса) подтверждением реализации интеграционного сервиса является выполнение условий взаимодействия и обработка данных самими участниками взаимодействия.
24. В случае положительного результата тестирования интеграционного сервиса владелец сервиса формирует акт тестирования и ввода в эксплуатацию согласно приложению 4 к настоящим Правилам (далее – акт тестирования и ввода в эксплуатацию), удостоверяет его своей ЭЦП и направляет ее на согласование инициатору интеграционного сервиса.
При отрицательном результате тестирование интеграции продолжается до получения положительного результата.
25. Инициатор интеграционного сервиса при получении заявки и акта тестирования в течение 3 (трех) рабочих дней согласовывает акт тестирования, удостоверив его своей ЭЦП, и направляет акт тестирования на согласование оператору.
26. Оператор рассматривает акт тестирования в течение 3 (трех) рабочих дней с момента получения заявки и акта тестирования.
27. При отрицательном результате проверки оператор возвращает акт тестирования на доработку владельцу сервиса. Владелец сервиса в срок не более 3 (трех) рабочих дней осуществляет доработку акта тестирования и повторно направляет его на рассмотрение инициатору интеграционного сервиса.
При положительном результате проверки акта тестирования оператор согласовывает акт тестирования, в течение 10 (десяти) рабочих дней публикует паспорт сервиса в реестре сервисов и предоставляет инициатору интеграционного сервиса доступ к сервису на промышленной среде ШЭП, ВШЭП. Уполномоченный орган и сервисный интегратор уведомляются о публикации интеграционного сервиса посредством веб-портала "электронного правительства".
Сноска. Пункт 27 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).Параграф 2. Порядок публикации сервиса по инициативе владельца объекта информатизации
28. Владелец сервиса авторизуется на веб-портале "электронного правительства" и запускает процесс по публикации сервиса, предварительно проверив отсутствие сервиса в опубликованном реестре сервисов. При формировании заявки владелец сервиса заполняет требования к взаимодействию с сервисом и заявку на публикацию сервиса, принимает условия интеграции, с приложением файлов XSD сервиса, а также XML примеров запроса и ответа с тестовыми данными.
29. Оператор, получив уведомление о поступлении заявки на публикацию сервиса, осуществляет проверку заявки на публикацию сервиса, заявки на организацию сетевого доступа на полноту и правильность заполнения в течение 3 (трех) рабочих дней. При отрицательном результате проверки заявки, оператор направляет заявки на доработку с указанием причин.
30. При положительном результате проверки заявки оператор в течение 10 (десяти) рабочих дней осуществляет публикацию сервиса и предоставляет владельцу сервиса доступ к тестовой и промышленной среде ШЭП, ВШЭП. Уполномоченный орган и сервисный интегратор уведомляются о публикации интеграционного сервиса посредством веб-портала "электронного правительства".
31. При указании владельцем сервиса подключающегося к сервису владельца объекта информатизации публикация сервиса проводится в порядке, установленном пунктами 14-27 настоящих Правил.
Параграф 3. Порядок подключения к интеграционному сервису
32. Инициатор интеграционного сервиса авторизуется на веб-портале "электронного правительства" и производит поиск необходимого сервиса в реестре сервисов.
33. Инициатор интеграционного сервиса инициирует заявку на подключение к сервису, заполняет поля согласно приложению 5 к настоящим Правилам и принимает условия интеграции. Подключение к интеграционному сервису осуществляется с учетом требований к взаимодействию с сервисом.
Соглашение об использовании интеграционных сервисов владельцами негосударственных ИС для оказания государственных услуг заключается по типовой форме согласно приложению 7 к настоящим Правилам.
Сноска. Пункт 33 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).34. Владелец сервиса, получив уведомление о необходимости просмотра заявки посредством веб-портала "электронного правительства", в течение 2 (двух) рабочих дней направляет ответ по заявке на подключение к сервису. При отказе в интеграции указывает мотивированный ответ.
35. В случае согласования заявки владельцем сервиса оператор, получив уведомление о необходимости просмотра заявки посредством вебпортала "электронного правительства", в течение 3 (трех) рабочих дней осуществляет согласование и проверку заявки на подключение к сервису (интеграцию) на полноту и правильность заполнения. При отрицательном результате проверки заявки, оператор направляет заявку на доработку с указанием причин.
36. Инициатор интеграционного сервиса в течение 3 (трех) рабочих дней осуществляет доработку заявки и повторно направляет ее на рассмотрение Владельцу сервиса.
37. В случае согласования заявки оператор в течение 10 (десяти) рабочих дней предоставляет инициатору интеграционного сервиса доступ к тестовой среде ШЭП, ВШЭП для проведения тестирования интеграции.
38. Инициатор интеграционного сервиса, владелец сервиса, оператор в срок не более 3 (трех) месяцев проводят тестирование интеграции до получения положительного результата.
39. Совместно с разработчиками интеграционного сервиса со стороны владельца сервиса, инициатора интеграционного сервиса и оператором проводится тестирование интеграционного сервиса в согласованные сроки.
40. Со стороны ШЭП, ВШЭП подтверждением реализации интеграционного сервиса является передача сообщений (для асинхронного сервиса – получение отправителем уникального идентификатора сообщения, для синхронного – получение ответного сообщения) между участниками взаимодействия, которая фиксируется в журнале логирования ШЭП, ВШЭП.
41. Со стороны участников взаимодействия (владельца сервиса и инициатора интеграционного сервиса) подтверждением реализации интеграционного сервиса является выполнение условий взаимодействия и обработка данных самими участниками взаимодействия.
42. В случае положительного результата тестирования интеграционного сервиса инициатор интеграционного сервиса формирует акт тестирования и ввода в эксплуатацию, удостоверяет его своей ЭЦП и направляет ее на согласование владельцу сервиса.
При отрицательном результате тестирование интеграции продолжается до получения положительного результата.
43. Владелец сервиса при получении заявки и акта тестирования в течение 3 (трех) рабочих дней согласовывает акт тестирования, удостоверив его своей ЭЦП, и направляет акт тестирования на согласование оператору.
44. Оператор рассматривает акт тестирования в течение 3 (трех) рабочих дней с момента его получения.
45. При отрицательном результате проверки оператор возвращает акт тестирования на доработку инициатору интеграционного сервиса. Инициатор интеграционного сервиса в срок не более 3 (трех) рабочих дней осуществляет доработку акта тестирования и повторно направляет его на рассмотрение владельцу сервиса.
При положительном результате проверки акта тестирования оператор согласовывает акт тестирования и в течение 10 (десяти) рабочих дней предоставляет инициатору интеграционного сервиса доступ к сервису на промышленной среде ШЭП, ВШЭП. Уполномоченный орган и сервисный интегратор уведомляются о подключении инициатора интеграционного сервиса к интеграционному сервису посредством веб-портала "электронного правительства".
Сноска. Пункт 45 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).Параграф 4. Порядок подключения к интеграционному сервису государственного органа для ИС государственных органов
Сноска. Глава 2 дополнена параграфом 4 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 02.09.2022 № 307/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
45-1. Инициатор интеграционного сервиса авторизуется на веб-портале "электронного правительства" и производит поиск необходимого сервиса в реестре сервисов.
45-2. Инициатор интеграционного сервиса инициирует заявку на подключение/интеграцию к сервису, заполняет поля согласно приложению 5 к настоящим Правилам, принимает условия интеграции. Подключение к интеграционному сервису осуществляется с учетом требований к взаимодействию с сервисом.
45-3. При подаче заявки инициатором интеграционного сервиса на подключение к интеграционному сервису государственного органа:
владелец сервиса в личный кабинет веб-портала "электронного правительства" и на электронную почту получает уведомление о поступлении заявки на ознакомление;
оператор получает уведомление о необходимости просмотра заявки посредством веб-портала "электронного правительства", в течение 3 (трех) рабочих дней осуществляет согласование и проверку заявки на подключение к сервису (интеграцию) на полноту и правильность заполнения.
При отрицательном результате проверки заявки, оператор направляет заявку на доработку с указанием причин.
45-4. Инициатор интеграционного сервиса в течение 3 (трех) рабочих дней осуществляет доработку заявки и повторно направляет ее на рассмотрение оператору, владельцу сервиса - поступает на ознакомление.
45-5. При положительном результате проверки заявки на подключение к сервису (интеграцию) на полноту и правильность заполнения, оператор в течение 10 (десяти) рабочих дней предоставляет инициатору интеграционного сервиса доступ к тестовой среде ШЭП, ВШЭП для проведения тестирования интеграции.
45-6. Совместно с разработчиками интеграционного сервиса со стороны владельца сервиса, инициатора интеграционного сервиса и оператором проводится тестирование интеграционного сервиса не более 3 (трех) месяцев, а также согласно требованиям, предусмотренным пунктами 38-45 настоящих Правил.
45-7. При наличии в сервисе персональных данных и конфиденциальной информации интеграция производится с использованием государственного сервиса контроля доступа к персональным данным в соответствии с Правилами интеграции с государственным сервисом контроля доступа к персональным данным, утвержденными приказом исполняющим обязанности Министра цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан от 8 июля 2022 года № 236/НҚ (зарегистрирован в Реестре государственной регистрации нормативных правовых актов за № 28786).
Параграф 5. Порядок актуализации интеграционного сервиса
Сноска. Правила дополнены параграфом 5 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
45-8. Владелец сервиса инициирует актуализацию интеграционного сервиса в случае изменения условий функционирования интеграционного сервиса или по запросу инициатора интеграционного сервиса.
45-9. Актуализация интеграционного сервиса осуществляется владельцем сервиса после его авторизации на веб-портале "электронного правительства" путем подачи оператору заявки на актуализацию интеграционного сервиса по форме согласно приложению 8 к настоящим Правилам.
45-10. Оператор, получив уведомление о поступлении заявки на актуализацию интеграционного сервиса, осуществляет ее проверку на полноту и правильность заполнения в течение 3 (трех) рабочих дней. При отрицательном результате проверки заявки, оператор направляет заявку на доработку с указанием причин.
45-11. При положительном результате проверки заявки оператор в течение 10 (десяти) рабочих дней осуществляет актуализацию интеграционного сервиса.
Параграф 6. Порядок актуализации подключения к интеграционному сервису
Сноска. Правила дополнены параграфом 6 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
45-12. Инициатор интеграционного сервиса инициирует актуализацию подключения к интеграционному сервису в случае изменения условий функционирования подключения к интеграционному сервису.
45-13. Актуализация подключения к интеграционному сервису осуществляется инициатором интеграционного сервиса после его авторизации на веб-портале "электронного правительства" путем подачи оператору заявки на актуализацию подключения к интеграционному сервису по форме согласно приложению 9 к настоящим Правилам.
45-14. Оператор, получив уведомление о поступлении заявки на актуализацию подключения к интеграционному сервису, осуществляет ее проверку на полноту и правильность заполнения в течение 3 (трех) рабочих дней. При отрицательном результате проверки заявки, оператор направляет заявку на доработку с указанием причин.
45-15. При положительном результате проверки заявки оператор в течение 10 (десяти) рабочих дней осуществляет актуализацию подключения к интеграционному сервису.
Глава 3. Обеспечение эксплуатации и защиты интеграционного сервиса
46. ШЭП, ВШЭП работают на промышленной среде в круглосуточном режиме и принимают сообщения от объектов информатизации на постоянной основе за исключением технологических перерывов.
47. Время принятия сообщения ШЭП, ВШЭП не должно превышать одной минуты с момента его получения по универсальному синхронному каналу и асинхронному каналу. Время предоставления ответа по запросу на асинхронном канале, зависит от реализации каждого интеграционного сервиса.
48. Технологические перерывы в работе объекта информатизации заранее оговариваются и согласовываются владельцем сервиса, инициатором интеграционного сервиса и оператором за 3 (три) рабочих дня до начала их проведения (по умолчанию технологические перерывы приходятся на ночное время с 21:00 до 6.00 часов, а также в выходные и праздничные дни).
49. С целью проведения тестирования участниками взаимодействия обеспечивается работоспособность тестовой среды объектов информатизации.
50. В случае технической необходимости, оператор и/или владелец сервиса, инициатор интеграционного сервиса производит перезагрузку объекта информатизации, о чем уведомляют администраторов других объектов информатизации, в виде телефонограммы или по электронной почте, с указанием времени технических работ.
51. В случае если владелец сервиса, инициатор интеграционного сервиса не принимают соответствующие меры по исправлению технических ошибок по информационному взаимодействию в кратчайшие сроки, оператор отключает соответствующий интеграционный сервис владельца сервиса или приостанавливает подключение инициатора интеграционного сервиса, сообщив участникам реализации интеграционного сервиса.
52. В случае неисправности каналов связи, проведения провайдерами услуг связи плановых профилактических работ на линиях связи, срок устранения сбоя определяется регламентом провайдера.
53. Защита информации при реализации интеграционного сервиса обеспечивается:
1) использованием механизмов контроля целостности и достоверности информации, в том числе подтверждением авторства, подписанных ЭЦП XML сообщений;
2) авторизация субъектов информатизации на ШЭП, ВШЭП проходит по логину и паролю, которые выдаются оператором, и по транспортной подписи, за исключением сервисов с применением стиля архитектуры программного обеспечения для распределенных систем (REST);
3) журналированием всех событий на ШЭП, ВШЭП;
4) мероприятиями технического и организационного характера по защите информации в соответствии с Законом.
54. Подтверждением авторства сообщений является положительный результат проверки соответствия транспортной подписи регистрационным свидетельством ЭЦП участника интеграционного взаимодействия, направившего сообщение.
55. Транспортная подпись не содержит метку времени.
56. Проверка транспортной подписи в ЕТС ГО выполняется на ШЭП.
57. При вызове сервиса на ШЭП использование транспортной подписи осуществляется по сценарию использования транспортной подписи согласно приложению 6 к настоящим Правилам.
58. Проверка транспортной подписи в ЕТС ГО на ШЭП состоит из следующих процедур:
1) проверка принадлежности ЭЦП отправителю сообщения;
2) проверка действительности ЭЦП.
59. При информационном взаимодействии все электронные сообщения должны быть подписаны ЭЦП участников интеграционного взаимодействия.
60. При применении ЭЦП при информационном взаимодействии объектов информатизации необходимо руководствоваться Законом Республики Казахстан "Об электронном документе и электронной цифровой подписи".
Сноска. Пункт 60 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 02.09.2022 № 307/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).61. Защиту информации от несанкционированного доступа на уровне прикладного программного обеспечения, своевременную передачу и неизменность передаваемых сведений обеспечивает ШЭП, ВШЭП.
62. В случае временного отключения интеграционного сервиса (модификации сервиса, модификации объекта информатизации, предоставляющей доступ к сервису) владелец сервиса уведомляет уполномоченный орган и всех пользователей интеграционного сервиса посредством веб портала "электронного правительства" за 3 (три) рабочих дня, в случае отключения сервиса или прекращения работы не позднее 1 (одного) месяца.
63. Владелец сервиса и инициатор интеграционного сервиса определяют ответственных лиц, которые обеспечивают информационную безопасность и постоянную готовность программных и технических средств.
64. В случае изменения состава ответственных лиц (перевода или прекращения трудового договора) в недельный срок владелец сервиса и инициатор интеграционного сервиса производят взаимное информирование об имеющихся изменениях, и сообщаются новые сведения об ответственных лицах по своевременному исполнению положений настоящих Правил.
65. При отзыве протоколов испытаний на соответствие требованиям информационной безопасности на объект информатизации "электронного правительства", Оператор приостанавливает все интеграционные взаимодействия у данного объекта информатизации "электронного правительства" в течение 1 рабочего дня с уведомлением субъектов информатизации.
Сноска. Правила дополнены пунктом 65 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); в редакции приказа и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).| Приложение 1 к Правилам интеграции объектов информатизации "электронного правительства" |
Форматы данных веб-сервисов SOAP
1. Описание сообщений асинхронного канала
1.1. Интерфейс сервиса на ШЭП, ВШЭП:
Метод для отправки сообщений на асинхронный канал ШЭП, ВШЭП (SendMessage):
Запрос на предоставление сервиса (SendMessageRequest) содержит следующие поля: Формат данных SendMessageRequest
Тип | Обязательность | Описание | |
AsyncSendMessagerequest | Да | Запрос | |
AsyncMessageInfo | Дa | Метаданные сообщения | |
xsd: string | Да | Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение) | |
xsd: string | Нет | Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы (отправителя) система отрабатывающая сообщение) | |
xsd: string | Да | Идентификатор сервиса | |
xsd: string | Да |
Тип сообщения: | |
xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) | |
xsd: dateTime | Да | Дата создания сообщения | |
guid | Да | Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо. | |
SenderInfo | Да | Объект информация об отправителе (заполняется отправителем) | |
xsd: string | Да | Идентификатор отправителя (системы отправителя) | |
xsd: string | Да | Пароль отправителя | |
property | Нет | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя) | |
xsd: int | Ключ свойства | ||
xsd: int | Нет | Значение свойства | |
messagedata | Да | Объект передачи данных | |
xsd: Anytype | Нет | Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ ШЭП, ВШЭП на сообщение (sendMessageResponse) представляет собой массив элементов со следующими полями: Формат данных SendMessageResponse
Тип | Обязанность | Описание | |
AsyncSendMessagerequest | Да | Ответ | |
xsd: string | Да | Идентификатор сообщения | |
xsd: string | Да | Идентификатор цепочки сообщения | |
xsd: dateTime | Да | Дата ответа | |
Guid | Нет | Идентификатор сессии ШЭП |
Ответ об ошибке (SendMessagefault) представляет собой массив элементов со следующими полями: Формат данных SendMessagefault
Тип | Обязанность | Описание | |
ErrorInfo | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод отправки уведомления на ШЭП, ВШЭП о доставке или не доставке сообщения (SendDeliveryNotification):
Запрос на уведомление представляет собой массив элементов со следующими полями (sendDeliveryNotificationRequest): Формат данных SendDeliveryNotificationRequest
Ответ на уведомление (sendDeliveryNotificationResponse) представляет собой массив со следующими полями: Формат данных SendDeliveryNotificationResponse
Тип | Обязанность | Описание | |
Async SendDeliveryNotificationResponse | Ответ | ||
xsd: string | Да | Идентификатор сообщения | |
xsd: dateTime | Да | Дата ответа | |
guid | Нет | Идентификатор сессии ШЭП |
Ответ об ошибке (SendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Тип | Обязанность | Описание | |
ErrorInfo | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод получения статуса сообщения с ШЭП, ВШЭП (GetMessageStatus)
Запрос на статус сообщения (GetMessageStatusRequest) представляет собой массив элементов со следующими полями: Формат данных GetMessageStatusRequest
Тип | Обязанность | Описание | |
AsyncGetmessagestatus | Да | Запрос | |
xsd: string | Да | Идентификатор сообщения | |
xsd: dateTime | Да | Дата запроса | |
senderinfo | Да | Объект информация об отправителе (заполняется отправителем) | |
xsd: string | Да | Идентификатор отправителя (системы отправителя) | |
xsd: string | Нет | Пароль отправителя | |
property | Нет | Массив свойств запроса | |
xsd: int | Ключ свойства | ||
xsd: int | Нет | Значение свойства |
В ответе на запрос на статус (getMessageStatusResponse) должна быть возвращена структура следующего вида: Формат данных GetMessageStatusResponse
Тип | Обязанность | Описание | |
Async GetmessagestatusResponse | Ответ | ||
messageState | Да | Состояние сообщения | |
xsd: dateTime | Да | Дата ответа | |
xsd: string | Нет | Идентификатор сессии на ШЭП | |
MessagestatusInfo | Объект "Информация о статусе" | ||
xsd: int | Да | Код статуса сообщения | |
xsd: string | Да | Сообщение статуса | |
xsd: dateTime | Да | Дата изменения статуса |
В случае возникновении ошибки в системе, передается сообщение об ошибке (SendMessageFault), которая представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Тип | Обязанность | Описание | |
ErrorInfo | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод выборки сообщений с ШЭП (GetMessages) осуществляется по параметрам:
идентификатору сообщения + получателю (только для запросившего)+идентификатору сервиса;
идентификатору цепочки сообщений + получателю (только для запросившего) + идентификатору сервиса;
получателю (только для запросившего) + идентификатору сервиса.
Параметр GetMessagesRequest
Запрос содержит следующие поля: Формат данных GetMessageRequest
Тип | Обязанность | Описание | |
Async GetmessagesRequest | Да | Метаданные запроса | |
xsd: string | Да | Идентификатор сообщения | |
xsd: string | Нет | Идентификатор цепочки сообщения | |
xsd: dateTime | Нет | Дата запроса | |
xsd: string | Да | Идентификатор сервиса | |
Senderinfo | Нет | Объект информация об отправителе (заполняется отправителем) | |
xsd: string | Идентификатор отправителя (системы отправителя) | ||
xsd: string | Пароль отправителя | ||
xsd: int | Нет |
Максимальное кол-во сообщений в выборке. | |
Property | Да | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя | |
xsd: string | Да | Ключ свойства | |
xsd: string | Да | Значение свойства |
Ответ getMessagesResponse со следующими полями: Формат данных GetMessageResponse
Тип | Обязанность | Описание | |
Async GetmessageResponse | Да | Ответ | |
xsd: dateTime | Да | Дата ответа | |
xsd: string | Да | Идентификатор сессии на ШЭП | |
Asynmessage | Нет | ||
Asynmessageinfo | Да | Метаданные сообщения | |
xsd: string | Нет | Идентификатор сообщения | |
xsd: string | Да | Идентификатор цепочки | |
xsd: string | Да | Идентификатор сервиса | |
xsd: string | Да |
Тип сообщения: | |
xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) | |
xsd: dateTime | Да | Дата создания сообщения | |
guid | Нет | Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо. | |
SenderIndo | Да | Объект информация об отправителе (заполняется отправителем) | |
xsd: string | Да | Идентификатор отправителя (системы отправителя) | |
xsd: string | Нет | Пароль отправителя | |
property | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя | ||
xsd: string | Да | Ключ свойства | |
xsd: string | Да | Значение свойства | |
messageData | Да | Объект передачи данных | |
xsd: Anytype | Да | Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ об ошибке (SendMessagefault) представляет собой массив элементов со следующими полями: Формат данных SendMessagefault
Тип | Обязанность | Описание | |
ErrorInfo | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии, в которой произошла ошибка |
1.2. Интерфейс для реализации сервиса на стороне пользователей ШЭП, ВШЭП для работы с асинхронным каналом.
Сервис реализуется как на стороне провайдера сервиса, так и на стороне использующей сервис. Сервис реализуют в случае необходимости доставки ШЭП сообщений методом вызова сервиса получателя сообщения (PUSH).
Метод приема сообщений: (SendMessage)
Запрос на предоставление cообщения (SendMessageRequest) содержит следующие поля: Формат данных SendMessageRequest
Тип | Обязанность | Описание | |
Async SendMessageRequest | Да | ||
Async SendMessageInfo | Да | Мета данные сообщения | |
xsd: string | Да |
Идентификатор сообщения. | |
xsd: string | Нет | Идентификатор цепочки сообщений. Генерируется ШЭП. В случае отправки сообщения типа REQUEST на ШЭП данное поле должно быть пустым. При отправке сообщений других типов на ШЭП, данное поле ДОЛЖНО БЫТЬ ЗАПОЛНЕНО. В случае передачи сообщения получателю номер будет проставлен ШЭП. | |
xsd: string | Да | Идентификатор взаимодействия. По реестру сервисов ШЭП. | |
xsd: string | Да |
Тип сообщения: | |
xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) | |
xsd: dateTime | Да | Дата создания сообщения | |
guid | Нет | Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо. | |
SenderInfo | Да | Объект информация об отправителе (заполняется отправителем) | |
xsd: string | Да | Идентификатор отправителя (системы отправителя) | |
xsd: string | Нет | Пароль отправителя | |
Property | Нет | Массив дополнительных свойств сообщения | |
xsd: int | Да | Ключ свойства | |
xsd: int | Да | Значение свойства | |
messageData | Да | Объект передачи данных | |
xsd: Anytype | Да | Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ ШЭП на сообщение (sendMessageResponse) представляет собой массив элементов со следующими полями: Формат данных SendMessageResponse
Тип | Обязанность | Описание | |
Async SendMessageResponse | Да | Ответ | |
xsd: string | Да | Идентификатор сообщения | |
xsd: string | Да | Идентификатор цепочки сообщения | |
xsd: dateTime | Да | Дата ответа | |
guid | Нет | Идентификатор сессии ШЭП |
Ответ об ошибке (SendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Тип | Обязанность | Описание | |
ErrorInfo | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии в которой произошла ошибка |
Метод приема уведомлений об изменении статуса сообщения в ШЭП (ChangeMessageStatusNotification)
Запрос уведомления об изменении статуса сообщения (ChangeMessageStatusNotificationRequest) представляет собой массив элементов со следующими полями: Формат данных ChangeMessageStatusNotificationRequest
Тип | Обязанность | Описание | |
Async ChangeMessageStatus NotificationRequest | Да | ||
ChangeStatus Notification | Да | Уведомления о статусе доставки сообщения | |
xsd: string | Да | Идентификатор уведомления | |
xsd: string | Да | Идентификатор сообщения | |
xsd: dateTime | Да | Дата создания уведомления | |
messageState | Да | Состояние сообщения | |
messageStatusinfo | Да | Статус доставки (приема сообщения) | |
xsd: string | Да | Код статуса | |
xsd: string | Да | Сообщения статуса | |
xsd: dateTime | Да | Идентификатор маршурута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя) | |
Нет | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Сообщение ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
xsd: string | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии в которой произошла ошибка | |
xsd: dateTime | Да | Дата запроса | |
guid | Нет | Идентификатор сессии |
Ответ о принятии уведомления (changeMassageStatusNotificationResponse) представляет собой массив элементов со следующими полями: Формат данных ChangeMessageStatusNotificationResponse
Тип | Обязанность | Описание | |
Async ChangeMessageStatus NotificationResponse | Да | Ответ | |
xsd: dateTime | Да | Дата ответа | |
guid | Да | Идентификатор сессии (указанное в запросе) |
Ответ об ошибке (sendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault
Тип | Обязанность | Описание | |
ErrorInfo | Информация об ошибке | ||
xsd: string | Да | Код ошибки | |
xsd: string | Да | Дополнительное описание ошибки | |
xsd: dateTime | Да | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
guid | Нет | Идентификатор сессии в которой произошла ошибка |
2. Описание сообщений синхронного канала
2.1. Интерфейс сервиса на ШЭП:
Метод отправки сообщений по синхронному каналу (SendMessage)
Запрос на предоставление Сервиса (SendMessageRequest) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageRequest
Тип | Обязанность | Описание | |
SyncsendMessagerequest | Да | Запрос | |
SyncMessageInfo | Да | Информация о сообщении запроса | |
xsd: string | Да | Идентификатор сообщения в системе получателя (генерирует ШЭП) | |
xsd: string | Нет | Идентификатор цепочки сообщения в системе получателя запроса (Генерирует ШЭП) | |
xsd: string | Да | Идентификатор взаимодействия (ведется в реестре сервисов ШЭП) | |
xsd: dateTime | Да | Дата создания сообщения в Системе Отправителя (Инициатора взаимодействия). Заполняется Отправителем (инициатором взаимодействия). | |
xsd: string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой Отправителя, т.е. Инициатора взаимодействия) | |
guid | Нет | Идентификатор сессии на ШЭП. Устанавливается на ШЭП. | |
senderinfo | Да | Объект информация об отправителе (заполняется отправителем) | |
xsd: string | Да | Идентификатор отправителя (системы отправителя) | |
xsd: string | Да | Пароль отправителя | |
property | Нет | Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя | |
xsd: int | Ключ свойства | ||
xsd: int | Значение свойства | ||
requestData | Да | Объект передачи данных запроса | |
xsd: Anytype | Нет | Данные сообщения (формат определяется системой получателя сообщения) |
Ответное сообщение на запрос (SendMessageResponse) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageResponse
Тип | Обязанность | Описание | |
SyncsendMessageresponse | Да | Ответ | |
SyncMessageInfoResponse | Да | Информация об ответе | |
xsd: string | Да | Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение) | |
xsd: string | Нет | Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы отправителя (система отрабатывающая сообщение) | |
xsd: dateTime | Да | Дата ответа в системе получателя запроса (заполняется системой получателя запроса) | |
guid | Нет | Идентификатор сессии на ШЭП. Устанавливается на ШЭП. При отправки ответа системой получателя запроса заполнять не нужно. | |
StatusInfo | Да | Объект "Информация о статусе" | |
xsd: int | Да | Код статуса (проставляется системой получателя запроса) | |
xsd: string | Да | Сообщение о статусе | |
responsedata | Да | Объект "данные ответа" | |
xsd: Anytype | Нет | Объект данные сообщения (формат определяется системой получателя сообщения) |
Сообщение об ошибке (SendMessageFault1_SendMessageFault) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageFault
Тип | Обязанность | Описание | |
xsd: string | Да | Код ошибки | |
xsd: string | Да | Сообщение ошибки | |
xsd: string | Нет | Дополнительное описание ошибки | |
xsd: dateTime | Нет | Дата ошибки | |
ErrorInfo | Нет | Дочерняя ошибка | |
Guid | Нет | Идентификатор сессии в которой произошла ошибка |
Форматы данных сервисов REST
Описание сообщений.
Запрос на предоставление сервиса представляет собой массив элементов со следующими полями:
Тип | Обязанность | Описание | |
SyncsendMessagerequest | Да | Запрос | |
SyncMessageInfo | Да | Информация о сообщении запроса | |
string | Да | Идентификатор сообщения в системе получателя (генерирует ШЭП) | |
string | Да | Идентификатор взаимодействия (ведется в реестре сервисов ШЭП) | |
dateTime | Да |
Дата создания сообщения в Системе Отправителя (Инициатора взаимодействия) | |
string | Нет | Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой Отправителя, т.е. Инициатора взаимодействия) | |
senderinfo | Да | Объект информация об отправителе (заполняется отправителем) | |
string | Да | Идентификатор отправителя (системы отправителя) | |
string | Да | Пароль отправителя | |
requestData | Да | Объект передачи данных запроса | |
Anytype | Нет | Данные сообщения (формат определяется системой получателя сообщения) |
Ответное сообщение на запрос представляет собой массив элементов со следующими полями:
Тип | Обязанность | Описание | |
SyncsendMessageresponse | Да | Ответ | |
SyncMessageInfoResponse | Да | Информация об ответе | |
string | Да | Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение) | |
dateTime | Да | Дата ответа в системе получателя запроса (заполняется системой получателя запроса) | |
string | Да | Сообщение о статусе | |
responsedata | Да | Объект "данные ответа" | |
Anytype | Нет | Объект данные сообщения (формат определяется системой получателя сообщения) |
| Приложение 2 к Правилам интеграции объектов информатизации "электронного правительства" |
|
| Форма |
Требования к взаимодействию с сервисом
В таблице 1 приведены требования по производительности и надежности синхронного сервиса.
Таблица 1 – Требования по производительности и надежности синхронного сервиса
Контролируемый показатель | Ограничение | |
Максимальное время обработки запроса при синхронном взаимодействии | до 30 секунд | |
Среднее время обработки запроса | 10 секунд | |
Пиковая нагрузка | 2000 запросов в час | |
Номинальная нагрузка | 360 запросов в час | |
Среднее время работы без сбоев | 365/7/24 | |
Время на восстановление работоспособности | 3 часа |
Таблица 2 – Требования по производительности и надежности асинхронного сервиса
Контролируемый показатель | Ограничение | |
Максимальное время обработки запроса при асинхронном взаимодействии | Время предоставления результата по запросу на асинхронном сервисе, зависит от реализации каждого интеграционного сервиса | |
Пиковая нагрузка | 2000 запросов в час | |
Номинальная нагрузка | 360 запросов в час | |
Среднее время работы без сбоев | 365/7/24 | |
Время на восстановление работоспособности | 3 часа |
| Приложение 3 к Правилам интеграции объектов информатизации "электронного правительства" |
|
| Форма |
Заявка на публикацию сервиса
Сноска. Приложение 3 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
1. Владелец сервиса | |
2. | Наименование организации |
3. | ИИН/БИН |
4. | Должностное лицо, ответственное за эксплуатацию |
5. | Контактные данные разработчика сервиса (на казахском языке) |
6. | Контактные данные разработчика сервиса (на русском языке) |
7. Информационная система Владельца сервиса | |
8. | Корневая категория сервиса |
9. | Ресурс разработчика сервиса |
10. | Наименование системы |
11. | Логин системы |
12. | Пароль (тестовая среда) |
13. | Пароль (промышленная среда) |
14. | IP-адрес системы (тестовая среда) |
15. | Порт системы (тестовая среда) |
16. | Протокол (тестовая среда) |
17. | IP-адрес системы (промышленная среда) |
18. | Порт системы (промышленная среда) |
19. | Протокол (промышленная среда) |
20. | Сертификат открытого ключа транспортной ЭЦП системы (выданный Национальным удостоверяющим центром Республики Казахстан) |
21. | Протоколы испытаний на соответствие требованиям информационной безопасности |
22. | Имеется ли доступ до ШЭП (да/нет) |
23. | Имеется VPN-туннель для данной системы (да/нет) |
24. | Хостинг АО НИТ (да/нет) |
25. Электронный сервис | |
26. | Наименование сервиса |
27. | Описание сервиса |
28. | Ключ сервиса |
29. | Режим взаимодействия сервиса |
30. | Опубликовать сервис на ВШЭП (да/нет) |
31. | Опубликовать сервис на ШЭП (да/нет) |
32. | Сервис предоставляет персональные данные (да/нет) |
33. | Признак наличия маршрутизации сообщений (да/нет) |
34. | Ключ маршрута |
35. | Наименование URL сервиса, принимающего запросы (тестовая среда) |
36. | URL сервиса, принимающего запросы (тестовая среда) |
37. | Наименование URL сервиса, принимающего запросы (промышленная среда) |
38. | URL сервиса, принимающего запросы (промышленная среда) |
39. | Наличие авторизации на стороне сервиса (да/нет) |
40. | Метод авторизации |
41. | Логин |
42. | Пароль |
43. | Тип безопасности |
44. | SSL сертификат (выданный Национальным удостоверяющим центром Республики Казахстан) |
45. | XSD |
46. | Пример запроса |
47. | Пример ответа |
48. Клиент сервиса | |
49. | Наименование организации, ИИН/БИН |
50. | Наименование информационной системы |
51. Данные VPN-туннеля | |
52. | Информация о шлюзе VPN |
53. | Режим туннеля |
54. | Публичный Peer IP-адрес |
55. | Свойства туннеля Фаза 1 |
56. | Метод аутентификации |
57. | Частный общий ключ |
58. | Тип криптографии |
59. | Протокол Деффи-Хеллмана |
60. | Криптографический алгоритм |
61. | Алгоритм хеширования |
62. | Срок действия (для пересмотра построения туннеля) |
63. | Свойства туннеля Фаза 2 |
64. | Инкапсуляция |
65. | Криптографический алгоритм |
66. | Метод алгоритма |
67. | Группа совершенной прямой секретности |
68. | Срок действия (для пересмотра построения туннеля) |
69. | Величина в Kб (для пересмотра построения туннеля) |
| Приложение 4 к Правилам интеграции объектов информатизации "электронного правительства" |
Акт тестирования и ввода в эксплуатацию
Сноска. Приложение 4 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
1. | Участники информационного взаимодействия: |
2. | Наименование владельца сервиса |
3. | Наименование клиента сервиса |
4. | Информационные системы: |
5. | Информационная система владельца сервиса |
6. | Информационная система инициатора интеграционного сервиса |
7. | Сервисы тестирования: |
8. | Наименование сервиса |
9. | Ключ сервиса |
10. | Заключение |
11. | Сценарий тестирования |
12. | Решение по результатам тестирования |
13. | Протоколы испытаний на соответствие требованиям информационной безопасности |
14. | Дата перевода в промышленную среду |
| Приложение 5 к Правилам интеграции объектов информатизации "электронного правительства" |
Заявка на подключение/интеграцию к сервису
Сноска. Приложение 5 - в редакции приказа Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
1. Владелец сервиса | |
2. | Наименование организации |
3. | ИИН/БИН |
4. Инициатор интеграционного сервиса | |
5. | Наименование организации |
6. | ИИН/БИН |
7. | Основание для подключения |
8. | Файл основания для подключения |
9. | Приказ о пилотном проекте (да/нет) |
10. | Срок действия приказа о пилотном проекте |
11. | ФИО ответственного лица |
12. | Контактный телефон ответственного лица |
13. | Электронная почта ответственного лица |
14. Информационная система инициатора интеграционного сервиса | |
15. | Наименование системы |
16. | Логин системы |
17. | Пароль (тестовая среда) |
18. | Пароль (промышленная среда) |
19. | IP-адрес системы (тестовая среда) |
20. | Порт системы (тестовая среда) |
21. | Протокол (тестовая среда) |
22. | IP-адрес системы (промышленная среда) |
23. | Порт системы (промышленная среда) |
24. | Протокол (промышленная среда) |
25. | Контур взаимодействия |
26. | Имеется ли доступ до ШЭП (да/нет) |
27. | Имеется ли VPN-туннель для данной системы |
28. | Хостинг АО НИТ (да/нет) |
29. | Прикрепите сертификат открытого ключа транспортной ЭЦП системы (выданный Национальным удостоверяющим центром Республики Казахстан) |
30. | 30. Прикрепите протоколы испытаний на соответствие требованиям информационной безопасности (.doc, .docx, .pdf) |
31. Электронный сервис | |
32. | Ключ сервиса |
33. | Режим взаимодействия сервиса |
34. | Режим отправки сообщений |
35. | Признак наличия маршрутизации сообщений (да/нет) |
36. | Ключ маршрута |
37. | Наименование URL сервиса, принимающего запросы (тестовая среда) |
38. | URL сервиса, принимающего запросы (тестовая среда) |
39. | Наименование URL сервиса, принимающего запросы (промышленная среда) |
40. | URL сервиса, принимающего запросы (промышленная среда) |
41. | Наличие авторизации на стороне сервиса (да/нет) |
42. | Метод авторизации |
43. | Логин |
44. | Пароль |
45. | Тип безопасности |
46. | SSL сертификат (выданный Национальным удостоверяющим центром Республики Казахстан) |
47. | Сервис предоставляет персональные данные |
48. Данные VPN-туннеля | |
49. | Информация о шлюзе VPN |
50. | Режим туннеля |
51. | Публичный Peer IP-адрес |
52. | Свойства туннеля Фаза 1: |
53. | Метод аутентификации |
54. | Частный общий ключ |
55. | Тип криптографии |
56. | Протокол Деффи-Хеллмана |
57. | Криптографический алгоритм |
58. | Алгоритм хеширования |
59. | Срок действия (для пересмотра построения туннеля) |
60. | Свойства туннеля Фаза 2: |
61. | Инкапсуляция |
62. | Криптографический алгоритм |
63. | Метод алгоритма |
64. | Группа совершенной прямой секретности |
65. | Срок действия (для пересмотра построения туннеля) |
66. | Величина в Kб (для пересмотра построения туннеля) |
| Приложение 6 к Правилам интеграции объектов информатизации "электронного правительства" |
Сценарий использования транспортной подписи
1. Сценарий приема сообщения с использованием транспортной подписи ШЭП:
1) ШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения, транспортную подпись объектов информатизации);
2) ШЭП подписывает сообщение транспортной подписью;
3) ШЭП передает подписанное сообщение ВШЭП (при взаимодействии с ИС вне ЕТС ГО);
4) ВШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения, транспортную подпись объектов информатизации).
Данный сценарий используется при взаимодействии объектов информатизации.
2. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны:
1) отправитель подписывает сообщение транспортной подписью и отправляет на ШЭП;
2) ШЭП проверяет транспортную подпись сообщения:
проверяет соответствие ИИН/БИН указанного в ЭЦП ИИН/БИН-а, внесенного в систему при регистрации объекта информатизации;
проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).
3. Сценарий приема сообщения с использованием транспортных подписей ШЭП, кроме сервисов, реализованных с использованием REST технологии, и вызывающей стороны, с использованием метода шифрования сообщений:
1) отправитель сообщения шифрует сообщение;
2) отправитель сообщения подписывает сообщения транспортной подписью и отправляет ШЭП;
3) ШЭП расшифровывает сообщение;
4) ШЭП проверяет транспортную подпись сообщения:
проверяет соответствие ИИН/БИН указанного в ЭЦП на ИИН/БИН-а, внесенного в систему при регистрации объекта информатизации;
проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).
| Приложение 7 к Правилам интеграции объектов информатизации "электронного правительства" |
Соглашение об использовании интеграционных сервисов владельцами негосударственных информационных систем для оказания государственных услуг
Сноска. Правила дополнены приложением 7 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
___________ (наименование государственного органа) (_____________ / _____________) (наименование и ключ сервиса), далее именуемое "Сторона 1", с одной стороны, и _____________ (наименование организации), далее именуемое "Сторона 2", вместе именуемые "Стороны", заключили настоящее Соглашение об использовании интеграционных сервисов (далее по тексту – Соглашение) о нижеследующем.
Глава 1. Область применения
1. Настоящее Соглашение определяет уровень обслуживания при использовании сервиса интеграции Стороны 1 в целях обеспечения доступности государственных услуг, предоставляемых в электронном виде, осуществления деятельности государственных органов и принятия обязательств Стороной 2 по бесперебойному предоставлению государственных услуг через внешние платформы. При этом, устанавливаются индексы доступности сервиса интеграции, а также Сторона 1 обеспечивает на этапе промышленной эксплуатации доступность сервиса интеграции в соответствии с установленным индексом доступности.
Глава 2. Определения и сокращения
2. В соглашении используются следующие основные понятия:
1) интеграционный сервис – способ информационного взаимодействия объектов информатизации;
2) информационная безопасность – состояние защищенности электронных информационных ресурсов, информационных систем и информационно-коммуникационной инфраструктуры от внешних и внутренних угроз;
3) информационная система (далее – ИС) – организационно упорядоченная совокупность информационно-коммуникационных технологий, обслуживающего персонала и технической документации, реализующих определенные технологические действия посредством информационного взаимодействия и предназначенных для решения конкретных функциональных задач;
4) владелец интеграционного сервиса (далее – Владелец сервиса) – собственник или владелец объекта информатизации, предоставляющий интеграционный сервис;
5) шлюз "электронного правительства" (далее – ШЭП) – ИС, предназначенная для интеграции объектов информатизации "электронного правительства" с иными объектами информатизации "электронного правительства";
6) внешний шлюз "электронного правительства" (далее – ВШЭП) – подсистема шлюза "электронного правительства", предназначенная для обеспечения взаимодействия информационных систем, находящихся в единой транспортной среде государственных органов, с информационными системами, находящимися вне единой транспортной среды государственных органов;
7) инцидент информационной безопасности (далее – Инцидент) – отдельно или серийно возникающие сбои в работе информационно-коммуникационной инфраструктуры или отдельных ее объектов, создающие угрозу их надлежащему функционированию и (или) условия для незаконного получения, копирования, распространения, модификации, уничтожения или блокирования электронных информационных ресурсов;
8) владелец объектов информатизации – субъект, которому собственник объектов информатизации предоставил права владения и пользования объектами информатизации в определенных законом или соглашением пределах и порядке;
9) оператор информационно-коммуникационной инфраструктуры "электронного правительства" (далее – Оператор) – юридическое лицо, определяемое Правительством Республики Казахстан, на которое возложено обеспечение функционирования закрепленной за ним информационно-коммуникационной инфраструктуры "электронного правительства";
10) AC SD – Автоматизированная система "Service Desk", предназначенная для публикации инцидентов и отображение процесса хода исполнения;
11) ЕСМ – Единая система мониторинга;
12) ресурс – мобильное приложение или портал, используемый для оказания государственной услуги;
13) пользователь – лицо, которое использует ресурс для получения государственной услуги.
14) услугодатель – центральные государственные органы, загранучреждения Республики Казахстан, местные исполнительные органы областей, городов республиканского значения, столицы, районов, городов областного значения, акимы районов в городе, городов районного значения, поселков, сел, сельских округов, а также физические и юридические лица, оказывающие государственные услуги в соответствии с законодательством Республики Казахстан;
15) уполномоченный орган в сфере информатизации (далее – уполномоченный орган) – центральный исполнительный орган, осуществляющий руководство и межотраслевую координацию в сфере информатизации и "электронного правительства".
Сноска. Пункт 2 с изменениями, внесенными приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).Глава 3. Содержание соглашения
3. Сторона 1 осуществляет меры, предусмотренные законодательством Республики Казахстан о персональных данных и их защите.
4. Сторона 2:
1) соблюдает конфиденциальность и осуществляет защиту, не разглашает и не передает третьим лицам, не опубликовывает персональные данные и конфиденциальную информацию, переданную в рамках упомянутого сервиса Стороной 1, за исключением случаев, предусмотренных законами Республики Казахстан;
2) обеспечивает техническую поддержку;
3) для использования интеграционного(-ых) сервиса(-ов) подтверждает популярность своего ресурса наличием мобильного приложения в маркетплейсах;
4) обеспечивает на своем ресурсе бесперебойность оказываемой государственной услуги, при условии доступности всех сервисов других участников интеграционного взаимодействия;
5) предоставляет пользователям при использовании мобильного приложения удобные средства биометрической идентификации либо использует сервис биометрической идентификации личности Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан для авторизации и подписания документов.
6) до запуска государственной услуги в промышленную эксплуатацию на внешнюю платформу обеспечивает демонстрацию государственной услуги уполномоченному органу, владельцу интеграционного сервиса и услугодателю.
Сноска. Пункт 4 с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).5. Стороны:
1) обеспечивают бесперебойную работоспособность и доступность сервисов интеграции и принимают сообщения от объектов информатизации в режиме 24/7/365 (кроме плановых, внеплановых работ по обновлению, технических сбоев аппаратных средств, каналов связи и неработоспособности услуг по причине проблем на стороне ИС государственных органов);
2) ШЭП, ВШЭП работают на промышленной среде в круглосуточном режиме и принимают сообщения от объектов информатизации на постоянной основе за исключением технологических перерывов;
3) время принятия сообщения ШЭП, ВШЭП не должно превышать одной минуты с момента его получения по универсальному синхронному каналу и асинхронному каналу. Время предоставления ответа по запросу на асинхронном канале, зависит от реализации каждого интеграционного сервиса;
4) технологические перерывы в работе сервиса интеграции заранее оговариваются и согласовываются Сторонами за 3 (три) рабочих дня до начала их проведения (по умолчанию технологические перерывы приходятся на ночное время с 21:00 до 6.00 часов, а также в выходные и праздничные дни);
5) с целью проведения тестирования участниками взаимодействия обеспечивается работоспособность тестовой среды объектов информатизации;
6) в случае технической необходимости, производят перезагрузку объекта информатизации, о чем уведомляют администраторов других объектов информатизации, в виде телефонограммы или по электронной почте, с указанием времени технических работ;
7) в случае если Стороны не принимают соответствующие меры по исправлению технических ошибок по информационному взаимодействию, Оператор отключает соответствующий интеграционный сервис Владельца сервиса или приостанавливает подключение Стороны 2, сообщив участникам реализации интеграционного сервиса;
8) в случае неисправности каналов связи, проведения провайдерами услуг связи плановых профилактических работ на линиях связи, срок устранения сбоя определяется регламентом провайдера;
9) осуществляют меры по защите объектов информатизации;
10) соблюдают законодательство Республики Казахстан в сфере информатизации, персональных данных и их защите, информационной безопасности и пункты настоящего Соглашения.
6. Взаимодействия сторон.
Основанием для исполнения любых, оговоренных Соглашением услуг, являются:
1) запрос на устранение Инцидента;
2) задача на исполнение плановых работ;
3) регистрация запросов (заявок) происходит при приеме обращения Стороны 1 и/или Стороны 2 при регистрации сообщений в ЕСМ и управления службами в AC SD;
4) графики и состав плановых работ оговариваются в соответствующих политиках процесса управления инцидентами/изменениями/запросами в работе сервисов Стороны 1;
5) при запросе персональных данных субъект или его законный представитель дает (отзывает) согласие на сбор, обработку персональных данных посредством государственного сервиса контроля доступа к персональным данным.
7. Индекс доступности.
Расчет: индекс доступности рассчитывается по формуле, указанной ниже.
Формула состоит из:
И – индекс доступности сервиса, %;
Т – период возможной доступности сервиса, часы;
Р – период недоступности сервиса, часы.
При этом под недоступностью сервиса понимается время простоя, в которое авторизованные пользователи не имеют возможности получить доступ к ресурсам, информации, сервисам, предоставляемым ИС. Состоит из сбоев ИС, плановых и внеплановых работ, проводимых с отключением ИС.
Формула по расчету доступности ИС выглядит следующим образом:
(Т-Р)/Т*100= ХХ %
1) индекс доступности каждого сервиса высчитывается самостоятельно Владельцем сервиса для дальнейшей публикации на своих ресурсах.
Глава 4. Уведомление
8. Любое уведомление, которое одна сторона направляет другой стороне в соответствии с настоящим Соглашением, направляется нарочно, с дополнительным направлением посредством электронной почты или факса.
9. Уведомление вступает в силу после доставки или в указанный день вступления в силу (если указано в уведомлении) в зависимости от того, какая из этих дат наступит позднее.
Глава 5. Решение спорных вопросов
10. Сторона 1 и Сторона 2 должны прилагать все усилия к тому, чтобы разрешать в процессе прямых переговоров все разногласия или споры, возникающие между ними по настоящему Соглашению или в связи с ним.
11. Если после таких переговоров Сторона 1 и Сторона 2 не могут разрешить спор по настоящему Соглашению, любая из Сторон может потребовать решения этого вопроса в соответствии с законодательством Республики Казахстан.
Глава 6. Прочие условия
12. Срок действия данного Соглашения вступает в силу с момента подписания Сторонами и действует до его расторжения.
13. Любые изменения и дополнения к настоящему Соглашению совершаются в той же форме, что и заключение настоящего Соглашения, посредством подписания Сторонами дополнительного/ых соглашения/ий к настоящему Соглашению.
14. Настоящее Соглашение составлено на казахском и русском языках в двух экземплярах. Все экземпляры идентичны и имеют одинаковую юридическую силу. У каждой из Сторон находится по одному экземпляру настоящего Соглашения на казахском и русском языках. Все приложения к настоящему Соглашению являются его неотъемлемой частью.
15. В части, неурегулированной настоящим Соглашением, Стороны руководствуются законодательством Республики Казахстан.
16. Настоящее Соглашение может быть расторгнуто по соглашению Сторон либо по инициативе одной из Сторон, в случае, если другая Сторона не выполняет условия соблюдения пунктов настоящего Соглашения.
| Приложение 8 к Правилам интеграции объектов информатизации "электронного правительства" |
|
| Форма |
Заявка на актуализацию интеграционного сервиса
Сноска. Правила дополнены приложением 8 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
1. Владелец сервиса | |
2. | Наименование организации |
3. | ИИН/БИН |
4. | Должностное лицо, ответственное за эксплуатацию |
5. | Контактные данные разработчика сервиса (на казахском языке) |
6. | Контактные данные разработчика сервиса (на русском языке) |
7. Информационная система Владельца сервиса | |
8. | Корневая категория сервиса |
9. | Ресурс разработчика сервиса |
10. | Наименование системы |
11. | Логин системы |
12. | Пароль (тестовая среда) |
13. | Пароль (промышленная среда) |
14. | IP-адрес системы (тестовая среда) |
15. | Порт системы (тестовая среда) |
16. | Протокол (тестовая среда) |
17. | IP-адрес системы (промышленная среда) |
18. | Порт системы (промышленная среда) |
19. | Протокол (промышленная среда) |
20. | Комментарий к изменениям по сети |
21. | Сертификат открытого ключа транспортной ЭЦП системы (выданный Национальным удостоверяющим центром Республики Казахстан) |
22. | Протоколы испытаний на соответствие требованиям информационной безопасности |
23. | Контур взаимодействия |
24. | Имеется ли доступ до ШЭП (да/нет) |
25. | Имеется VPN-туннель для данной системы (да/нет) |
26. | Предоставляется ли хостинг АО НИТ (да/нет) |
27. Данные VPN-туннеля | |
28. | Информация о шлюзе VPN |
29. | Режим туннеля |
30. | Публичный Peer IP-адрес |
31. | Свойства туннеля Фаза 1 |
32. | Метод аутентификации |
33. | Частный общий ключ |
34. | Тип криптографии |
35. | Протокол Деффи-Хеллмана |
36. | Криптографический алгоритм |
37. | Алгоритм хеширования |
38. | Срок действия (для пересмотра построения туннеля) |
39. | Свойства туннеля Фаза 2 |
40. | Инкапсуляция |
41. | Криптографический алгоритм |
42. | Метод алгоритма |
43. | Группа совершенной прямой секретности |
44. | Срок действия (для пересмотра построения туннеля) |
45. | Величина в Kб (для пересмотра построения туннеля) |
46. Электронный сервис | |
47. | Наименование сервиса (на казахском языке) |
48. | Наименование сервиса (на русском языке) |
49. | Назначение сервиса (на казахском языке) |
50. | Назначение сервиса (на русском языке) |
51. | Ключ сервиса |
52. | Режим взаимодействия сервиса |
53. | Признак наличия маршрутизации сообщений (да/нет) |
54. | Ключ маршрута |
55. | Наименование URL сервиса, принимающего запросы (тестовая среда) |
56. | URL сервиса, принимающего запросы (тестовая среда) |
57. | Наименование URL сервиса, принимающего запросы (промышленная среда) |
58. | URL сервиса, принимающего запросы (промышленная среда) |
59. | Наличие авторизации на стороне сервиса (да/нет) |
60. | Метод авторизации |
61. | Логин |
62. | Пароль |
63. | Сервис предоставляет персональные данные (да/нет) |
64. | Тип безопасности |
65. | SSL сертификат (выданный Национальным удостоверяющим центром Республики Казахстан) |
66. | XSD |
67. | Пример запроса |
68. | Пример ответа |
| Приложение 9 к Правилам интеграции объектов информатизации "электронного правительства" |
|
| Форма |
Заявка на актуализацию подключения к интеграционному к сервису
Сноска. Правила дополнены приложением 9 в соответствии с приказом Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 05.12.2023 № 603/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования); с изменением, внесенным приказом и.о. Министра цифрового развития, инноваций и аэрокосмической промышленности РК от 26.07.2024 № 444/НҚ (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
1. Владелец сервиса | |
2. | Наименование организации |
3. | ИИН/БИН |
4. Инициатор интеграционного сервиса | |
5. | Наименование организации |
6. | ИИН/БИН |
7. | Основание для подключения |
8. | Файл основания для подключения |
9. | Приказ о пилотном проекте (да/нет) |
10. | Срок действия приказа о пилотном проекте |
11. | ФИО ответственного лица |
12. | Контактный телефон ответственного лица |
13. | Электронная почта ответственного лица |
14. Информационная система инициатора интеграционного сервиса | |
15. | Наименование системы |
16. | Логин системы |
17. | Пароль (тестовая среда) |
18. | Пароль (промышленная среда) |
19. | IP-адрес системы (тестовая среда) |
20. | Порт системы (тестовая среда) |
21. | Протокол (тестовая среда) |
22. | IP-адрес системы (промышленная среда) |
23. | Порт системы (промышленная среда) |
24. | Протокол (промышленная среда) |
25. | Комментарий к изменениям по сети |
26. | Контур взаимодействия |
27. | Имеется ли доступ до ШЭП (да/нет) |
28. | Имеется ли VPN-туннель для данной системы |
29. | Предоставляется ли хостинг АО НИТ (да/нет) |
30. | Сертификат открытого ключа транспортной ЭЦП системы (выданный Национальным удостоверяющим центром Республики Казахстан) |
31. | Протоколы испытаний на соответствие требованиям информационной безопасности |
32. Данные VPN-туннеля | |
33. | Информация о шлюзе VPN |
34. | Режим туннеля |
35. | Публичный Peer IP-адрес |
36. | Свойства туннеля Фаза 1: |
37. | Метод аутентификации |
38. | Частный общий ключ |
39. | Тип криптографии |
40. | Протокол Деффи-Хеллмана |
41. | Криптографический алгоритм |
42. | Алгоритм хеширования |
43. | Срок действия (для пересмотра построения туннеля) |
44. | Свойства туннеля Фаза 2: |
45. | Инкапсуляция |
46. | Криптографический алгоритм |
47. | Метод алгоритма |
48. | Группа совершенной прямой секретности |
49. | Срок действия (для пересмотра построения туннеля) |
50. | Величина в Kб (для пересмотра построения туннеля) |
51. Электронный сервис | |
52. | Ключ сервиса |
53. | Режим взаимодействия сервиса |
54. | Режим отправки сообщений |
55. | Признак наличия маршрутизации сообщений (да/нет) |
56. | Ключ маршрута |
57. | Наименование URL сервиса, принимающего запросы (тестовая среда) |
58. | URL сервиса, принимающего запросы (тестовая среда) |
59. | Наименование URL сервиса, принимающего запросы (промышленная среда) |
60. | URL сервиса, принимающего запросы (промышленная среда) |
61. | Наличие авторизации на стороне сервиса (да/нет) |
62. | Метод авторизации |
63. | Логин |
64. | Пароль |
65. | Тип безопасности |
66. | SSL сертификат (выданный Национальным удостоверяющим центром Республики Казахстан) |
67. | Сервис предоставляет персональные данные |