Единый контакт-центр

1414

8-800-080-7777

Категория

Условие поиска

Государственный орган *

Публичное обсуждение до

С По

Тип

Статус

Дата создания

С По

 


О внесении изменении в приказ исполняющего обязанности Министра информации и коммуникаций Республики Казахстан от 29 марта 2018 года № 123 «Об утверждении Правил интеграции объектов информатизации «электронного правительства»

Краткое содержание:
Статус: На рассмотрении
Версия проекта:   Версия 1   
Тип НПА: Приказ
Дата создания: 03/02/2020
Публичное обсуждение до: 17/02/2020
Дата запуска онлайн-обсуждения:
Дата окончания онлайн-обсуждения:
Приложенные документы:

В соответствии с подпунктом 13) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года «Об информатизации» ПРИКАЗЫВАЮ:

 

 

         Утверждены
приказом Министра
цифрового развития, инноваций и

аэрокосмической промышленности

 Республики Казахстан
от ____ 20_ года № ____

 

 

Правила
 интеграции объектов информатизации «электронного правительства»

 

Глава 1. Общие положения

                                                                                     

1. Настоящие Правила интеграции объектов информатизации «электронного правительства» (далее – Правила) разработаны в соответствии с подпунктом 13) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года «Об информатизации» (далее – Закон) и определяют порядок интеграции объектов информатизации «электронного правительства».

  1. В настоящих Правилах используются следующие основные понятия:
  1. владелец объектов информатизации (далее - Владелец) – субъект, которому собственник объектов информатизации предоставил права владения и пользования объектами информатизации в определенных законом или соглашением пределах и порядке;
  2. техническая реализация интеграции объектов информатизации – комплекс технических работ, в том числе тестирование и работы по вводу в промышленную эксплуатацию интеграционного сервиса, проводимых для обеспечения интеграции участников информационного взаимодействия;
  3. уполномоченный орган в сфере информатизации (далее – уполномоченный орган) – центральный исполнительный орган, осуществляющий руководство и межотраслевую координацию в сфере информатизации и «электронного правительства»;
  4. информационная система (далее – ИС) – организационно-упорядоченная совокупность информационно-коммуникационных технологий, обслуживающего персонала и технической документации, реализующих определенные технологические действия посредством информационного взаимодействия и предназначенных для решения конкретных функциональных задач;
  5. опытная эксплуатация объекта информатизации – эксплуатация объекта информатизации в пилотной зоне, проводимая с целью выявления и устранения недостатков его функционирования и определения соответствия требованиям технической документации;
  6. промышленная эксплуатация объекта информатизации – этап жизненного цикла объекта информатизации, на протяжении которого осуществляется использование объекта информатизации в штатном режиме в соответствии с целями, задачами и требованиями, изложенными в технической и нормативно-технической документации;
  7. бизнес-данные объекта информатизации – данные взаимодействия владельца объекта информатизации и инициатора интеграционного сервиса, входящие в состав сообщений формата ШЭП как блок, не проверяемый на стороне ШЭП;
  8. интеграция объектов информатизации – мероприятия по организации и обеспечению информационного взаимодействия между объектами информатизации на основании используемых в Республике Казахстан стандартных протоколов передачи данных;
  9. данные обмена объекта информатизации – данные взаимодействия владельца объекта информатизации и инициатора интеграционного объекта информатизации;
  10. безопасность веб-сервисов (WebServiceSecurity) (далее – WSSecurity) – стандарт применения функций безопасности при обмене сообщениями между веб-сервисами SOAP. При применении стиля архитектуры программного обеспечения для распределенных систем (REST) безопасность сервиса обеспечивается через меры безопасности HTTPs, и применением аутентификации пользователей;
  11. протокол Деффи-Хеллмана – криптографический протокол, позволяющий двум и более сторонам обменяться заранее согласованным общим секретным ключом, используя пару публичных и частных ключей в незащищенном от прослушивания канале связи;
  12. частный IP-адрес – внутренний уникальный сетевой адрес узла в локальной компьютерной сети;
  13. публичный IP-адрес – уникальный сетевой адрес, маршрутизируемый в сети Интернет;
  14. интеграционный сервис – способ информационного взаимодействия объектов информатизации;
  15. инициатор интеграционного сервиса – владелец объекта информатизации, инициирующий запрос на предоставление интеграционного сервиса;
  16. расширяемый язык разметки (eXtensible Markup Language) (далее – XML) – расширяемый язык разметки, используемый для хранения и передачи данных в структурированном и машиночитаемом формате;
  17. транспортная подпись – электронная цифровая подпись, используемая для обеспечения целостности и авторства передаваемых сообщений при информационном взаимодействии ИС с применением спецификации WSSecurity;
  18. удостоверяющий центр – юридическое лицо, удостоверяющее соответствие открытого ключа электронной цифровой подписи закрытому ключу электронной цифровой подписи, а также подтверждающее достоверность регистрационного свидетельства;
  19. журнал логирования – файлы, содержащие информацию о работе системы, используемую для мониторинга ее работы и выявления причин, в случае возникновения сбоя;
  20. единая транспортная среда государственных органов (далее – ЕТС ГО) – сеть телекоммуникаций, входящая в информационно-коммуникационную инфраструктуру «электронного правительства» и предназначенная для обеспечения взаимодействия локальных (за исключением локальных сетей, имеющих доступ к Интернету), ведомственных и корпоративных сетей телекоммуникаций государственных органов, их подведомственных организаций и органов местного самоуправления, а также иных субъектов информатизации, определенных уполномоченным органом, с соблюдением требуемого уровня информационной безопасности;
  21. простой протокол доступа к объектам (SimpleObjectAccessProtocol) (далее – SOAP) – протокол, основанный на XML для передачи сообщений при интеграции ИС;
  22. реестр сервисов – перечень зарегистрированных в шлюзе «электронного правительства» и внешнем шлюзе «электронного правительства» сервисов, с описанием сервиса;
  23. оператор информационно-коммуникационной инфраструктуры «электронного правительства» (далее – оператор) – юридическое лицо, определяемое Постановлением Правительства Республики Казахстан от 29 января 2016 года № 40, на которое возложено обеспечение функционирования закрепленной за ним информационно-коммуникационной инфраструктуры «электронного правительства»;
  24. сервисный интегратор «электронного правительства» (далее – сервисный интегратор) – юридическое лицо, определяемое Правительством Республики Казахстан, на которое возложены функции по методологическому обеспечению развития архитектуры «электронного правительства» и типовой архитектуры "электронного акимата", а также иные функции, предусмотренные Законом;
  25. шлюз «электронного правительства» (далее – ШЭП) – ИС, предназначенная для интеграции объектов информатизации «электронного правительства» с иными объектами информатизации;
  26. объекты информатизации «электронного правительства» (далее – объекты информатизации) – государственные электронные информационные ресурсы, программное обеспечение государственных органов, интернет - ресурс государственного органа, объекты инфраструктуры «электронного правительства», в том числе сервисный программный продукт, программное обеспечение и информационные системы  иных лиц, предназначенные для формирования государственных электронных информационных ресурсов в рамках осуществления государственных функций и оказания государственных услуг;
  27. внешний шлюз «электронного правительства» (далее – ВШЭП) – подсистема шлюза «электронного правительства», предназначенная для обеспечения взаимодействия ИС, находящихся в ЕТС ГО, с ИС, находящимися вне ЕТС ГО;
  28. платежный шлюз «электронного правительства» (далее – ПШЭП) – ИС, автоматизирующая процессы передачи информации о проведении платежей в рамках оказания возмездных услуг, оказываемых в электронной форме;
  29. электронное сообщение – электронный документ в формате XML, JSON, предназначенный для передачи посредством интеграционного сервиса или API сервиса между объектами информатизации;
  30. электронная цифровая подпись (далее – ЭЦП) – набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания;
  31. инкапсуляция AH (AuthenticationHeader) – инкапсуляция аутентифицирующего заголовка, которая позволяет аутентифицировать соседнего узла в туннеле VPN и обеспечить целостность передаваемых данных без шифрования. Значение в поле протокола заголовка IP – равное UDP порту 51;
  32. ESP (Encapsulation Security Pay load) – инкапсуляция защищенных данных, который позволяет зашифровать весь кадр, передаваемый через VPN-канал, включая полезную нагрузку и IP-заголовки источника и назначения.
  33. IP (Internet Protocol) – сетевая модель передачи данных, представленных в цифровом виде;
  34. SSL-сертификат (Secure Sockets Layer) – регистрационное свидетельство, предназначенное для использования интернет-ресурсом или ИС для обеспечения процедуры аутентификации;
  35. TCP (Transmission Control Protocol) – один из основных протоколов передачи данных Интернета, предназначенный для управления передачей данных;
  36. UDP (User Datagram Protocol) – протокол пользовательских датаграмм, один из ключевых элементов TCP/IP, набора сетевых протоколов для Интернета;
  37. URL (Uniform Resource Locator) – единообразный локатор (определитель местонахождения) ресурса, указывает адрес сервиса объекта информатизации;
  38. Virtual Private Network (далее – VPN) – виртуальная частная сеть для обмена информацией двух узлов.
  39. API сервис – способ информационного взаимодействия между объектами информатизации;
  40. Application programming interface (далее – API) – интерфейс программирования приложений, набор готовых программ, предоставляемых сервисом для информационного взаимодействия между объектами информатизации;
  41. владелец API - субъект информатизации, осуществляющий информационное взаимодействие через API;
  42. API с открытым правом доступа (OpenAPI) – API, выставленный в свободном доступе в сети Интернет, не требующий согласования или разрешения владельца/собственника электронного информационного ресурса для осуществления информационного взаимодействия;
  43. Hyper Text Transfer Protocol (далее – HTTP) — протокол прикладного уровня передачи данных изначально — в виде гипертекстовых документов в формате «HTML», используемый для передачи произвольных данных;
  44. Representational State Transfer (далее – REST) — стиль архитектуры программного обеспечения для взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённых систем или взаимодействия сервисов, использующий стандарты, такие как HTTP, URL, JSON и XML;
  45. java script object notation (далее – JSON) – текстовый формат обмена данными, основанный на JavaScript;
  46. мониторинг интеграционных объектов информатизации (далее – система мониторинга) – компонент ШЭП, предназначенный для чтения и хранения определенных настроек интеграционного процесса и предоставляющий визуальный интерфейс для использования оператором;
  47. клиент-коннектор – программное обеспечение, предоставляющее инициатору интеграционного объекта информатизации возможность генерации точки подключения к интеграционному сервису, размещенному на ШЭП, ВШЭП с поддержкой форматов ШЭП, ВШЭП;
  48. сервис-коннектор – программное обеспечение, позволяющее владельцу объекта информатизации создавать и размещать интеграционные сервисы на ШЭП.

         3. Интеграции посредством ШЭП, ВШЭП не подлежат:

  1. сервисы, предоставляемые удостоверяющими центрами;
  2. объекты информатизации, которые содержат сведения, составляющие государственные секреты Республики Казахстан и служебную информацию ограниченного распространения;
  3. объекты информатизации, размещенные на информационно-коммуникационной платформе «электронного правительства» и предназначенные для формирования единого пространства данных для целей предоставлений аналитической информации по деятельности Правительства Республики Казахстан;
  4. сервисы по предоставлению открытых данных посредством OpenAPI, API, с использованием форматов XML, JSON и протоколов HTTP и HTTPS, посредством архитектурного стиля REST, включая интернет-порталы открытых данных, открытых бюджетов и открытых нормативных правовых актов.

         4. Мероприятия по интеграции объектов информатизации, в том числе направление на согласование заявок на публикацию, интеграцию, согласование документов тестирования, соглашений, а также заявок на организацию сетевого взаимодействия осуществляются посредством веб-портала «электронного правительства».

         5. Интеграция объектов информатизации осуществляется при условии наличия интеграционного объекта информатизации в реестре сервисов на веб-портале «электронного правительства».

         6. Для непосредственного осуществления платежей в рамках оказания возмездных услуг, оказываемых в электронной форме, к интеграции с ПШЭП допускаются объекты информатизации банков второго уровня, организаций, осуществляющих отдельные виды банковских операций, а также платежных организаций, прошедших учетную регистрацию в Национальном Банке Республики Казахстан.

         7. При оказании услуг в электронном виде информационная система услугодателя должна направлять информацию об использовании чека об оплате в ПШЭП.

         8. Обмен заявками, документами между участниками интеграционного взаимодействия осуществляется на веб-портале «электронного правительства». Все заявки, документы и соглашения удостоверяются ЭЦП уполномоченных лиц участников  интеграционного взаимодействия.

         Если информационная система инициатора интеграционного сервиса относится к объектам информатизации, указанным в пункте 2 статьи 49 закона Республики Казахстан от  24 ноября 2015 года «Об информатизации», то к заявке на подключение к сервису или на публикацию сервиса инициатор интеграционного сервиса прилагает акт испытаний с положительным результатом испытаний на соответствие требованиям информационной безопасности.

         9. Владелец и инициатор интеграционного сервиса могут использовать сервис-коннектор для разработки и размещения интеграционного сервиса на ШЭП, ВШЭП и клиент-коннектор для подключения к интеграционному сервису.

Сервис-коннектор и клиент-коннектор поддерживают системы управления базами данных MySQL, PostgreSQL, SQLServer, Oracle.

 

 

Глава 2. Порядок интеграции объектов информатизации «электронного правительства»

Параграф 1. Порядок публикации интеграционного сервиса по инициативе инициатора интеграционного сервиса

 

         10. Инициатор интеграционного сервиса авторизуется на веб-портале «электронного правительства» и направляет запрос в форме заявки на публикацию сервиса Владельцем, предварительно проверив отсутствие необходимого сервиса в опубликованном реестре сервисов. При формировании заявки инициатор интеграционного сервиса заполняет требуемые поля согласно Приложениям 1, 2 настоящих Правил, принимает условия интеграции, с приложением файлов WSDL и XSD сервиса, а также XML примеров запроса и ответа с тестовыми данными.

         11. Заявка в автоматическом режиме направляется сервисному интегратору для проведения анализа интеграций объектов информатизации «электронного правительства» и предоставления рекомендации.

         При получении уведомления о поступлении заявки сервисный интегратор рассматривает запрос в рамках собственной компетенции в течение 2 (двух) рабочих дней и готовит рекомендации.

         12. Рекомендация сервисного интегратора в автоматическом режиме поступает инициатору интеграционного сервиса.

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

         13. Владелец, получив уведомление о поступлении заявки, в течение 2 (двух) рабочих дней рассматривает заявку.

         По результатам рассмотрения заявки Владелец согласовывает заявку либо возвращает ее на доработку инициатору либо отказывает  в публикации сервиса с указанием причин.

         14. В случае согласования заявки Владелец заполняет требуемые поля заявки согласно Приложениям 1, 2 к настоящим Правилам, принимает условия интеграции, прилагает к заявке файлы WSDL и XSD сервиса, а также XML примеров запроса и ответа с тестовыми данными и направляет заявку  оператору с уведомлением инициатора интеграционного сервиса и уполномоченного органа.

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

16. В случае отказа Владельца в публикации сервиса мероприятия по публикации сервиса прекращаются.

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

         18. При необходимости доработки заявки и соглашения по результатам их рассмотрения оператором Владелец в течение 2 (двух) рабочих дней дорабатывает заявку на публикацию сервиса и направляет заявку и соглашение оператору на повторное рассмотрение.

19. При положительном результате проверки заявки оператор в течение 10 (десяти) рабочих дней предоставляет инициатору интеграционного сервиса доступ к тестовой среде ШЭП и подключает инициатора интеграционного сервиса к сервису на тестовой среде ШЭП для проведения тестирования интеграции.

20. Оператором совместно с разработчиками интеграционного сервиса со стороны Владельца и инициатора интеграционного сервиса проводится тестирование интеграционного сервиса в согласованные сроки.

21. Со стороны ШЭП подтверждением успешной реализации интеграционного сервиса является успешная передача сообщений (для асинхронного сервиса – получение отправителем уникального идентификатора сообщения, для синхронного – получение ответного сообщения) между участниками взаимодействия, которая фиксируется в журнале логирования.

         22. Со стороны участников взаимодействия (владельца объекта информатизации и инициатора интеграционного сервиса) подтверждением успешной реализации интеграционного сервиса является успешное выполнение условий взаимодействия и обработка данных самими участниками взаимодействия.

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

При отрицательном результате тестирование интеграции продолжается до получения успешного результата, но не более 3  (трех) месяцев.

24. Владелец при получении заявки и акта тестирования согласовывает акт тестирования, удостоверив его своей ЭЦП, и направляет акт тестирования на согласование оператору.

25. Оператор рассматривает акт тестирования в течение 3 (трех) рабочих дней с момента получения материалов, проверяет их на полноту и правильность заполнения.

26. При отрицательном результате проверки оператор возвращает акт тестирования на доработку инициатору интеграционного сервиса. Инициатор интеграционного сервиса в срок не более 3 (трех) рабочих дней осуществляет доработку акта тестирования и повторно направляет его на рассмотрение оператору.

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

27.     Интеграционный сервис вводится в промышленную эксплуатацию на основании подписанного акта после проведения оператором необходимых технических работ на ШЭП, ВШЭП, ПШЭП (перевод интеграционного сервиса в промышленную среду).

        

 

Параграф 2. Порядок публикации объектов информатизации по инициативе владельца объекта информатизации

 

         28. Владелец авторизуется на веб-портале «электронного правительства»  и запускает процесс по публикации сервиса, предварительно проверив отсутствие сервиса в опубликованном реестре сервисов. При формировании заявки Владелец заполняет требуемые поля согласно Приложениям 1, 2 настоящих Правил, принимает условия интеграции, с приложением файлов WSDL и XSD сервиса, а также XML примеров запроса и ответа с тестовыми данными.

         29. Оператор,  получив  уведомление о поступлении заявки на публикацию сервиса,  осуществляет проверку заявки на публикацию сервиса, заявки на организацию сетевого доступа на полноту и правильность заполнения в течение 3 (трех) рабочих дней. При отрицательном результате проверки заявок, оператор направляет заявки на доработку с указанием причин отказа.   

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

31. В случае успешного тестирования интеграционного сервиса Владелец формирует акт тестирования согласно Приложению 3 настоящих Правил, удостоверяет его своей ЭЦП и направляет ее на согласование оператору.

При отрицательном результате тестирование интеграции продолжается до получения успешного результата, но не более 3  (трех) месяцев.

32. Оператор  рассматривает акт тестирования в течение 3 (трех) рабочих дней с момента получения материалов, проверяет их на полноту и правильность заполнения.

33. При отрицательном результате проверки оператор возвращает акт тестирования на доработку Владельцу. Владелец интеграционного сервиса в срок не более 3 (трех) рабочих дней осуществляет доработку акта тестирования и повторно направляет его на рассмотрение оператору.

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

 

Параграф 3. Порядок интеграции объектов информатизации

 

         34. Инициатор интеграционного сервиса авторизуется на портале «электронного правительства» и производит поиск необходимого сервиса в опубликованном реестре сервисов. Поиск осуществляется согласно паспортам сервисов, где указано полное описание объектов информатизации.

         35. Инициатор интеграционного сервиса инициирует заявку на подключение к сервису, заполняет требуемые поля согласно Приложению 4 настоящих Правил, принимает условия интеграции.

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

         37. Инициатор интеграционного сервиса, получив уведомление о необходимости просмотра заявки посредством веб-портала «электронного правительства», в течение 2 (двух) рабочих дней дорабатывает заявку на подключение к сервису, принимает условия интеграции.

         38. В случае согласования заявки Владельцем оператор, получив уведомление о необходимости просмотра заявки посредством веб-портала «электронного правительства», в течение 3 (трех) рабочих дней осуществляет согласование соглашения, проверку заявки на подключение к сервису (интеграцию) на полноту и правильность заполнения. При отрицательном результате проверки заявки, оператор направляет заявку на доработку с указанием причин.

         39. Инициатор интеграционного сервиса в течение 3 (трех) рабочих дней осуществляет доработку заявки и повторно направляет ее на рассмотрение оператору.

         40. В случае согласования заявки оператор в течение 10 (десяти) рабочих дней предоставляет инициатору интеграционного сервиса технический доступ к тестовой среде ШЭП, ВШЭП и подключает инициатора интеграционного сервиса к интеграционному сервису на тестовой среде для проведения тестирования интеграции.

         41. Инициатор интеграционного сервиса, Владелец, оператор в срок не более 3 (трех) месяцев проводят тестирование интеграции до получения успешного результата. Тестирование проводится в порядке, установленном пунктами 20-27 настоящих Правил.

 

 

Глава 3. Обеспечение эксплуатации и защиты интеграционного сервиса

        

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

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

         44. Технологические перерывы в работе объекта информатизации заранее оговариваются и согласовываются владельцем объекта информатизации, инициатором интеграционного сервиса и оператором за 3 (три) рабочих дня до начала их проведения (по умолчанию технологические перерывы приходятся на ночное время с 21:00 до 6.00 часов, а также в выходные и праздничные дни).

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

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

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

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

         49. Защита информации при реализации интеграционного сервиса обеспечивается:

  1. использованием механизмов контроля целостности и достоверности информации, в том числе подтверждением авторства, подписанных XML сообщений;
  2. авторизацией объектов информатизации на ШЭП, ВШЭП по логину и паролю, которые выдаются оператором, и по транспортной подписи, за исключением сервисов с применением стиля архитектуры программного обеспечения для распределенных систем (REST);
  3. журналированием всех событий на ШЭП, ВШЭП;
  4. мероприятиями технического и организационного характера по защите информации в соответствии с Законом.

         50. Подтверждением авторства сообщений является положительный результат проверки соответствия транспортной подписи регистрационным свидетельством ЭЦП владельца объекта информатизации, направившего сообщение.

         51. Транспортная подпись не содержит метку времени. Наличие метки времени в бизнес-данных объекта информатизации регулируется в соответствии с согласованным техническим документом на интеграцию. ШЭП не проводит проверку на наличие метки времени в данных объекта информатизации.

  1. Проверка транспортной подписи в ЕТС ГО выполняется на ШЭП. Транспортная подпись ШЭП не содержит метку времени.
  2. При вызове сервиса на ШЭП использование транспортной подписи осуществляется по сценарию использования транспортной подписи согласно приложению 5 к настоящим Правилам.
  3. Проверка транспортной подписи в ЕТС ГО на ШЭП состоит из процедур:
    1. проверка принадлежности ЭЦП отправителю сообщения;
    2. проверка действительности ЭЦП.
  4. При информационном взаимодействии все электронные сообщения должны быть подписаны ЭЦП владельцев объектов информатизации.
  5. При применении ЭЦП при информационном взаимодействии объектов информатизации необходимо руководствоваться Законом Республики Казахстан от 7 января 2003 года "Об электронном документе и электронной цифровой подписи".
  6. Защиту информации от несанкционированного доступа на уровне прикладного программного обеспечения, своевременную передачу и неизменность передаваемых сведений обеспечивает ШЭП.
  7. Владелец уведомляет уполномоченный орган и всех пользователей интеграционного сервиса посредством веб-портала «электронного правительства» за 3 (три) рабочих дня, в случае временного отключения интеграционного сервиса (модификации сервиса, модификации объекта информатизации, предоставляющей доступ к сервису) или не позднее 1 (одного) месяца, в случае отключения сервиса, в связи с прекращением работы.
  8. Владелец и инициатор интеграционного сервиса определяют ответственных лиц, которые обеспечивают информационную безопасность и постоянную готовность программных и технических средств.    
  9. В случае изменения состава ответственных лиц (перевода или прекращения трудового договора) в недельный срок Владелец и инициатор интеграционного сервиса производят взаимное информирование об имеющихся изменениях, и сообщаются новые сведения об ответственных лицах по своевременному исполнению положений настоящих Правил.

 

 

 

 

Приложение 1
к Правилам интеграции
объектов информатизации
«электронного правительства»

 

 

 

 

 

Форма

       

Требования к взаимодействию с сервисом

Сведения о публикуемом сервисе

1

Владелец сервиса

Заполняется наименование организации с  idp

2

Наименование информационной системы 

Заполняется из справочника ЕПИР

3

Контур взаимодействия

Переключатель «В ЕТС ГО» / «Вне ЕТС ГО»

4

Ключ сервиса

 

Вручную текстовое поле обязательное

ФЛК для поля:

Подсказка: Условное обозначение сервиса, должно содержать краткое наименование ИС и название сервиса

5

Режим взаимодействия сервиса

Переключатель Синхронный/асинхронный

6

Наименование сервиса на русском

Вручную текстовое поле обязательное

ФЛК для поля: формат поля string(96), т.е. макс кол-во символов 96

7

Наименование сервиса на казахском

Вручную текстовое поле обязательное

ФЛК для поля: формат поля string(96), т.е. макс кол-во символов 96

8

Назначение сервиса на русском

Вручную текстовое поле обязательное

9

Назначение сервиса на казахском

Вручную текстовое поле обязательное

10

Бизнес описание работы сервиса на русском

Вручную текстовое поле необязательное

Вложение файла(-ов) необязательное

Подсказка: Приложите схему информационного взаимодействия. Форматы данных. Пояснения к схеме.

11

Бизнес описание работы сервиса на казахском

Вручную текстовое поле необязательное

Вложение файла(-ов) необязательное

Подсказка: Приложите схему информационного взаимодействия. Форматы данных. Пояснения к схеме.

 

Рекомендуемые требования по производительности и надежности:

 

Контролируемый показатель

Ограничение

12

Максимальное время обработки запроса при синхронном взаимодействии

Вручную текстовое поле необязательное

(заполняется только для синхронных)

13

Среднее время обработки запроса

Вручную текстовое поле обязательное

14

Пиковая нагрузка

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

15

Номинальная нагрузка

 

Вручную текстовое поле обязательное Подсказка: оптимальное количество запросов в час

16

Среднее время работы без сбоев

 

Вручную текстовое поле обязательное

17

Время на восстановление работоспособности

Вручную текстовое поле обязательное

18

Требования по использованию ЭЦП

Требования по информационной безопасности

Требования к формату Журнала логирования

Требования со стороны ШЭП/ВШЭП

Стандартный текст, обязательное поле.

Согласен с требованиями Проставляет галочку - V

 

 

 

 

В таблице 1 приведены требования по производительности и надежности сервиса.

Таблица 1 – Требования по производительности и надежности

Контролируемыйпоказатель

Ограничение

1

Максимальное время обработки запроса при синхронном взаимодействии

до 60 секунд

2

Среднеевремяобработкизапроса

10 секунд

3

Пиковаянагрузка

2000 запросов в час

4

Номинальнаянагрузка

360 запросов в час

5

Среднее время работы без сбоев

365/7/24

6

Времянавосстановлениеработоспособности

3 часа

 

 

 

 

Приложение 2
к Правилам интеграции
объектов информатизации
«электронного правительства»

 

 

 

Форма

     

Заявка на публикацию сервиса

1. Владелец сервиса

 

 

 

1

Наименование организации

Заполняется автоматически

name/description (SystemOwner)

Автоматически

 

2

Идентификатор организации

Не нужно в заявке отображать

 

 

 

3

БИН/ИИН организации

Заполнятеся автоматически согласно п.1

Identity (SystemOwner)

 

 

4

Должностное лицо, ответственное за эксплуатацию

Текстовое поле, обязательное, ручной ввод

 

 

 

2. Информационная система владельца сервиса

 

 

 

5

Контактные данные разработчика сервиса

Текстовое поле, обязательное, ручной ввод

Email (System)

 

 

6

Наименование системы

Текстовое поле, обязательное, заполнятеся автоматически С требований пункт 2.

name/description (System)

 

 

7

Идентификатор системы

Не нужно в заявке отображать

 

 

 

8

Адрес системы в тестовой среде

Текстовое поле, обязательное, ручной ввод

 

 

 

9

Порт системы в тестовой среде

Текстовое поле, обязательное, ручной ввод

 

 

 

10

Адрес системы в промышленной среде

Текстовое поле, обязательное, ручной ввод

 

 

 

11

Порт системы в промышленной среде

Текстовое поле, обязательное, ручной ввод

 

 

 

12

Наличие авторизации на стороне сервиса

Да/нет

isAuth (Destination)

 

 

13.1

Метод авторизации

Basic (по умолчанию)/Digest

Появляется, если заполнено поле 12

authMethod (Destination)

 

 

 

13.2

Логин

Появляется, если заполнено поле 12

Отображается только для администратора

authLogin (Destination)

 

 

13.3

Пароль

Появляется, если заполнено поле 12

Отображается только для администратора

authPassword (Destination)

 

 

3. Электронный сервис

 

 

14

Наименование сервиса

Заполняется автоматически С требований пункт 5

Name (Service)

 

 

15

Описание сервиса

Заполняется автоматически С требований пункт 6

Description (Service)

 

 

16

Ключ сервиса

Заполняется автоматически С требований пункт 4

serviceKey (Service)

 

 

17

Режим взаимодействия сервиса

Синхронный/асинхронный

Type (Service)

 

 

18

Тип безопасности

"LOGIN_PASSWORD": "По логину и паролю",

"SIG_CERT_OFFLINE": "Транспортная подпись",

    "SIG_CERT_ONLINE": "Транспортная подпись с проверкой сертификата в НУЦ РК",

    "SIG_CERT_ENC_OFFLINE": "Транспортная подпись с шифрованием",

    "SIG_CERT_ENC_ONLINE": "Транспортная подпись с шифрованием и проверкой сертификата в НУЦ РК",

    "SIG_GOST_OFFLINE": "Транспортная подпись ГОСТ",

"SIG_GOST_ONLINE": "Транспортная подпись ГОСТ с проверкой сертификата в НУЦ РК"

securityType (Service)

 

 

19

Адрес точки доставки

ULR точки доставки

url(Destination)

 

 

20

Наименование точки доставки

Условное обозначение точки доставки. Латинские буквы верхнего регистра, символы -,_. 

name(Destination) 

 

 

21

Признак наличия маршрутизации сообщений

Да/нет

route (Service)

 

 

21.1

Ключ маршрута

Появляется если в поле 19 «да»

В поле подсказка: введите наименование маршрута

routeKey (Route)

 

 

22

Необходимость получния уведомления ИС - отправителей сообщений об изменении статусов сообщений от ШЭП

Переключатель (0-не требуется, 1- требуется)

Только для асинхронных сервисов

Notify (ServiceClient)

 

 

23

Необходимость получения дополнительного уведомления о доставке от ШЭП

Переключатель (0-не требуется, 1- требуется)

Только для асинхронных сервисов

acceptNotification (Destination)

 

 

24

Режим отправки сообщений

0 - точка доставки синхронного канала,

1 - точка доставки асинхронного канала тип PULL,

2 - точка доставки асинхронного канала тип PUSH

type (Destination)

 

 

25

Формат сообщений

Soap 

rest (Service)

 

 

4. Инициатор интеграционного сервиса (необязательные поля)

 

26

Наименование организации

Текстовое поле, обязательное, ручной ввод

name/description (SystemOwner)

 

 

26.1

Идентификатор организации

Не нужно в заявке отображать

 

 

 

27

БИН организации

Текстовое поле, необязательное, заполняется со справочника ЕПИР

Identity (SystemOwner)

 

 

5. Вложения

 

 

28

Прикрепите SSL сертификат

Прикрепить файл, обязательное, вручную

Для сохранения сертификата нужно указывать alias, по которому сохраняем сертификат в хранилище ключей.

 

 

 

29

Прикрепите сертификат открытого ключа транспортной ЭЦП системы

Прикрепитьфайл, обязательное, вручную

Для сохранения сертификата нужно указывать alias, по которому сохраняем сертификат в хранилище ключей.

 

 

30

Прикрепите WSDL

Прикрепитьфайл, обязательное, вручную

 

 

 

31

Прикрепите XSD

С возможностью добавлять несколько полей +

 

 

 

32

Прикрепите пример запроса

Прикрепить файл, обязательное, вручную

 

 

 

33

Прикрепите пример ответа

Прикрепить файл, обязательное, вручную

 

 

 

6. Контур взаимодействия

 

 

 

34

Контур взаимодействия

 

 

 

 

35

Имеется доступ до ШЭП / VPN-туннель для данной системы?

Если в ЕТС / вне ЕТС

 

 

 

36

Поля из ВПН формы если нет VPN-туннеля

 

 

 

 

Информация о шлюзе VPN

Редактируемое поле, обязательное

Текстовый

 

 

 

Режимтуннеля

Редактируемое поле, обязательное

Справочник

 

 

3

Публичный Peer IP-адрес

Редактируемое поле, обязательное

Текстовый

 

 

3

Свойства туннеля Фаза 1:

 

 

 

 

Методаутентификации

Редактируемое поле, обязательное

Текстовый

 

 

 

Частный общий ключ

Редактируемое поле, обязательное

Текстовый

 

 

 

Тип криптографии

Редактируемое поле, обязательное

Текстовый

 

 

 

Протокол Деффи-Хеллмана

Редактируемое поле, обязательное

Текстовый

 

 

 

Криптографический алгоритм

Редактируемое поле, обязательное

Текстовый

 

 

3

Алгоритм хеширования

Редактируемое поле, обязательное

Текстовый

 

 

3

Срок действия (для пересмотра построения туннеля)

Редактируемое поле, обязательное

Текстовый

 

 

 

Свойства туннеля Фаза 2:

 

 

 

 

Инкапсуляция (ESP или AH)

Редактируемое поле, обязательное

Текстовый

 

 

 

Криптографический алгоритм

Редактируемое поле, обязательное

Текстовый

 

 

 

Метод алгоритма

Редактируемое поле, обязательное

Текстовый

 

 

4

Группа совершенной прямой секретности

Редактируемое поле, обязательное

Текстовый

 

 

4

Срок действия (для пересмотра построения туннеля)

Редактируемое поле, обязательное

Текстовый

 

 

4

Величина в Kб (для пересмотра построения туннеля)

Редактируемое поле, обязательное

Текстовый

 

 

                     

 

Данные об инициаторе интеграционного сервиса

1

ФИО, контактный телефон, email, ответственного лица

 

Email (System)

Вручную

1. Информационная система инициатора интеграционного сервиса сервиса

 

2

Наименование системы

 

name/description (System)

Справочник

2.1

Идентификатор системы

 

 

Не нужно в заявке отображать

3

Адрес системы в тестовой среде

 

 

Вручную

4

Порт системы в тестовой среде

 

Вручную

5

Адрес системы в промышленной среде

 

Вручную

6

Порт системы в промышленной среде

 

Вручную

7

Наличие авторизации

 

isAuth (Destination)

Да/нет

Только для асинхронных

7.1

Метод авторизации

 

authMethod (Destination)

 

Basic (по умолчанию)/Digest

Появляется если заполнено поле 7

Толькодляасинхронных

7.2

Логин

 

authLogin (Destination)

Появляется если заполнено поле 7

Только для асинхронных

7.3

Пароль

 

authPassword (Destination)

Появляется если заполнено поле 7

Только для асинхронных

8

Адрес точки доставки

 

url(Destination)

Введите url точки доставки

Только для асинхронных

9

Наименование точки доставки

 

name(Destination) 

Условное обозначение точки доставки. Латинские буквы верхнего регистра, символы -,_.

Только для асинхронных

10

Тип безопасности

 

securityType (Service)

"LOGIN_PASSWORD": "По логину и паролю",

"SIG_CERT_OFFLINE": "Транспортная подпись",

    "SIG_CERT_ONLINE": "Транспортная подпись с проверкой сертификата в НУЦ РК",

    "SIG_CERT_ENC_OFFLINE": "Транспортная подпись с шифрованием",

    "SIG_CERT_ENC_ONLINE": "Транспортная подпись с шифрованием и проверкой сертификата в НУЦ РК",

    "SIG_GOST_OFFLINE": "Транспортная подпись ГОСТ",

"SIG_GOST_ONLINE": "Транспортная подпись ГОСТ с проверкой сертификата в НУЦ РК

11

Признак наличия маршрутизации сообщений

 

 

Да/нет

Только для асинхронных

11.1

Ключ маршрута инициатор интеграционного сервиса

 

addlClientKey (ServiceClient)

Появляется если заполнено поле 11

Только для асинхронных

12

Необходимость получения уведомления ИС - отправителей сообщений об изменении статусов сообщений от ШЭП

 

Notify (ServiceClient)

Переключатель (0-не требуется, 1- требуется)

Только для асинхронных

13

Необходимость получения дополнительного уведомления о доставке от ШЭП

 

acceptNotification (Destination)

Переключатель (0-не требуется, 1- требуется)

Только для асинхронных

14

Режим отправки сообщений

 

type (Destination)

Переключатель PUSH, PULL

(Подсказка: PUSH – адресат самостоятельно извлекает адресованные ему сообщения, PULL – ШЭП отправляет ответы на запросы адресату)

Толькодляасинхронных

2. Контур взаимодействия

 

15

Контур взаимодействия

 

 

 

16

Имеется доступ до ШЭП / VPN-туннель для данной системы?

Если в ЕТС / вне ЕТС

 

 

17

Поля из ВПН формы если нет VPN-туннеля

 

 

3. Вложения

 

18

Прикрепите сертификат открытого ключа транспортной ЭЦП системы

 

 

 

19

Прикрепите SSL сертификат

Только для асинхронных

 

 

           

 

 


 

 

 

 

Приложение 3

к Правилам интеграции
объектов информатизации
«электронного правительства»

 

 

Акт об успешном тестировании и вводе в эксплуатацию

Участники информационного взаимодействия:

Наименование владельца сервиса

Заполняется автоматически с Заявки

Наименование инициатора интеграционного сервиса

Заполняется автоматически с Заявки

Информационные системы:

Информационная система владельца сервиса

Заполняется автоматически с Заявки

Информационная система инициатора интеграционного сервиса

Заполняется автоматически с Заявки

Сервисы тестирования:

Наименование сервиса

Заполняется автоматически с Заявки

Ключ сервиса

Заполняется автоматически с Заявки

Сценарий тестирования

Прикрепить файл, обязательное, ручной ввод

Решение по результатам тестирования

Нередактируемое поле. Стандартный текст:

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

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

Дата ввода в промышленную эксплуатацию

Календарь, обязательное, ручной ввод

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Приложение 4
к Правилам интеграции
объектов информатизации
«электронного правительства»

 

Заявка на подключение/интеграцию к сервису

1. Владелец сервиса

1

Наименование организации

Заполняется автоматически

 

 

2

Идентификатор организации

Не нужно в заявке отображать

 

 

3

БИН/ИИН организации

Заполнятеся автоматически согласно п.1

Identity (SystemOwner)

 

2. Инициатор интеграционного сервиса

4

Наименование организации

Заполняется наименование организации с  idp

 

 

5

Идентификатор организации

Не нужно в заявке отображать

 

 

6

БИН/ИИН организации

Заполнятеся автоматически согласно п.4

Identity (SystemOwner)

 

7

Основание для подключения

Текстовое поле, обязательное, ручной ввод

 

 

8

ФИО, контактный телефон, email, ответственного лица

Текстовое поле, обязательное, ручной ввод

Email (System)

 

3. Информационная система инициатора интеграционного сервиса

 

9

Наименование системы

Заполняется со справочника ЕПИР

name/description (System)

 

9.1

Идентификатор системы

Не нужно в заявке отображать

 

 

10

Логин системы

Текстовое поле, обязательное, ручной ввод

Подсказка: Логин для авторизации ИС на ШЭП/ВШЭП

Отображается только для администратора

 

 

11

Пароль (тест)

Текстовое поле, обязательное, ручной ввод

Подсказка: Пароль для авторизации ИС в тестовой среде ШЭП/ВШЭП

Отображается только для администратора

 

 

12

Пароль (прод)

Текстовое поле, обязательное, ручной ввод

Подсказка: Пароль для авторизации ИС в боевой среде ШЭП/ВШЭП

Отображается только для администратора

 

 

13

IP-адрес системы (тест)

Текстовое поле, обязательное, ручной ввод

 

 

14

Порт системы (тест)

Текстовое поле, обязательное, ручной ввод

 

15

IP-адрес системы (продуктив)

Текстовое поле, обязательное, ручной ввод

 

16

Порт системы (продуктив)

Текстовое поле, обязательное, ручной ввод

 

4. Электронный сервис

17

Ключ сервиса

Заполняется автоматически

 

 

18

Режим взаимодействия сервиса

Заполняется автоматически

 

 

19

Режим отправки сообщений

Переключатель PUSH, PULL

(Подсказка: PUSH – адресат самостоятельно извлекает адресованные ему сообщения, PULL – ШЭП отправляет ответы на запросы адресату)

Толькодля асинхронных

type (Destination)

 

20

Признак наличия маршрутизации сообщений

Да/нет

route (Service)

 

20.1

Ключ маршрута

Появляется если в поле 20 «да»

В поле подсказка: используется если по одному сервису несколько адресов доставки

routeKey (Route)

 

21

Наименование URL сервиса, принимающего ответные запросы (тест)

Заполняется автоматически

 

 

22

URL сервиса, принимающего ответные запросы (тест)

Текстовое поле, обязательное, ручной ввод

Подсказка: URL системы, принимающей запросы

 

 

23

Наименование URL сервиса, принимающего ответные запросы (прод)

Заполняется автоматически

 

 

24

URL сервиса, принимающего ответные запросы (прод)

Текстовое поле, обязательное, ручной ввод

Подсказка: URL системы, принимающей запросы

 

 

25

Наличие авторизации

Да/нет

Только для асинхронных

isAuth (Destination)

 

25.1

Метод авторизации

Basic (по умолчанию)/Digest

Появляется если в поле 25 «Да»

Только для асинхронных

authMethod (Destination)

 

 

25.2

Логин

Появляется если в поле 25 «Да»

Только для асинхронных

authLogin (Destination)

 

25.3

Пароль

Появляется если в поле 25 «Да»

Только для асинхронных

authPassword (Destination)

 

26

Тип безопасности

"LOGIN_PASSWORD": "По логину и паролю",

    "SIG_GOST_OFFLINE": "Транспортная подпись ГОСТ",

securityType (Service)

 

27

Необходимость получения уведомления ИС - отправителей сообщений об изменении статусов сообщений от ШЭП

Переключатель (0-не требуется, 1- требуется)

Только для асинхронных

Notify (ServiceClient)

 

28

Необходимость получения дополнительного уведомления о доставке от ШЭП

Переключатель (0-не требуется, 1- требуется)

Только для асинхронных

acceptNotification (Destination)

 

29

Сервис предоставляет персональные данные

Заполняется автоматически

 

 

29,1

XPath-путь к элементу, содержащему ИИН

Заполняется автоматически

 

 

29,2

Предусмотрена отправка SMS гражданам для получения разрешения на предоставление их персональных данных

Заполняется автоматически

 

 

5. Контур взаимодействия

 

30

Контур взаимодействия

Заполняется автоматически

 

 

31

Имеется доступ до ШЭП / VPN-туннель для данной системы?

Если в ЕТС / вне ЕТС

 

 

 

6 Поля из ВПН формы

32

Информация о шлюзе VPN

Редактируемое поле, обязательное

Текстовый

33

Режим туннеля

Редактируемое поле, обязательное

Справочник

34

Публичный Peer IP-адрес

Редактируемое поле, обязательное

Текстовый

 

Свойства туннеля Фаза 1:

 

 

35

Методаутентификации

Редактируемое поле, обязательное

Текстовый

36

Частный общий ключ

Редактируемое поле, обязательное

Текстовый

37

Тип криптографии

Редактируемое поле, обязательное

Текстовый

38

Протокол Деффи-Хеллмана

Редактируемое поле, обязательное

Текстовый

39

Криптографический алгоритм

Редактируемое поле, обязательное

Текстовый

40

Алгоритм хеширования

Редактируемое поле, обязательное

Текстовый

41

Срок действия (для пересмотра построения туннеля)

Редактируемое поле, обязательное

Текстовый

 

Свойства туннеля Фаза 2:

 

 

42

Инкапсуляция (ESP или AH)

Редактируемое поле, обязательное

Текстовый

43

Криптографический алгоритм

Редактируемое поле, обязательное

Текстовый

44

Метод алгоритма

Редактируемое поле, обязательное

Текстовый

45

Группа совершенной прямой секретности

Редактируемое поле, обязательное

Текстовый

46

Срок действия (для пересмотра построения туннеля)

Редактируемое поле, обязательное

Текстовый

47

Величина в Kб (для пересмотра построения туннеля)

Редактируемое поле, обязательное

Текстовый

7. Вложения

 

48

Прикрепите основание для подключения

Прикрепить файл. Не обязательное, вручную

 

 

49

Прикрепите сертификат открытого ключа транспортной ЭЦП системы

Прикрепить файл, обязательное, вручную

 

 

50

Прикрепите акт по результатам испытаний на соответствие требованиям информационной безопасности

Прикрепить файл, Только для государственных органов, вручную

 

 

51

Прикрепите SSL сертификат

Прикрепить файл, обязательное, вручную

Только для асинхронных

 

 

           

 

 

 

Приложение 5
к Правилам интеграции
объектов информатизации
«электронного правительства»

 

 

Сценарий использования транспортной подписи

 

1. Сценарий приема сообщения с использованием транспортной подписи ШЭП:

         1) ШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения, транспортную подпись объектов информатизации);

2) ШЭП подписывает сообщение транспортной подписью;

3) ШЭП передает подписанное сообщение ВШЭП (при взаимодействии с ИС вне ЕТС ГО);

4) ВШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения, транспортную подпись объектов информатизации).

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

2. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны:

1) отправитель подписывает сообщение транспортной подписью и отправляет на ШЭП;

2) ШЭП проверяет транспортную подпись сообщения:

проверяет соответствие ИИН/БИН указанного в ЭЦП на ИИН/БИН ИП/юридического лица, внесенного в систему при регистрации объекта информатизации;

проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).

3. Сценарий приема сообщения с использованием транспортных подписей ШЭП, кроме сервисов, реализованных с использование REST технологии, и вызывающей стороны, с использованием метода шифрования сообщений:

1) отправитель сообщения шифрует сообщение;

2) отправитель сообщения подписывает сообщения транспортной подписью и отправляет ШЭП;

3) ШЭП расшифровывает сообщение;

4) ШЭП проверяет транспортную подпись сообщения:

проверяет соответствие ИИН/БИН указанного в ЭЦП на ИИН/БИН ИП/юридического лица, внесенного в систему при регистрации объекта информатизации;

проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов

1. Внести в приказ исполняющего обязанности Министра информации и коммуникаций Республики Казахстан от 29 марта 2018 года № 123 «Об утверждении Правил интеграции объектов информатизации «электронного правительства» (зарегистрирован в Реестре государственной регистрации нормативных правовых актов за № 16777) следующее изменение:

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

2. Комитету государственных услуг Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан в установленном законодательном порядке обеспечить: 

1) государственную регистрацию настоящего приказа в Министерстве юстиции Республики Казахстан;

2) размещение настоящего приказа на интернет-ресурсе Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан;

3) в течение десяти рабочих дней после государственной регистрации настоящего приказа представление в Юридический департамент Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан сведений об исполнении мероприятий, предусмотренных подпунктами 1) и 2) настоящего пункта.

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

5. Настоящий приказ вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования.

 

 

Министр цифрового развития, инноваций и аэрокосмической промышленности

Республики Казахстан

 

 

                          

                           А. Жумагалиев

  • 23
  • Министерство цифрового развития, инноваций и аэрокосмической промышленности РК
  • 1 0
  • 354

Комментарий

КАКИМБЕКОВ КАЗБЕК

java script object notation (далее – JSON) – текст... посмотреть текст 0 0 04/02 - 15:23 / Подписаться

Рекомендуется использовать общепринятый формат написания - JavaScript Object Notation (далее - JSON)

КАКИМБЕКОВ КАЗБЕК

владелец API - субъект информатизации, осуществляю... посмотреть текст 0 0 04/02 - 15:38 / Подписаться

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

АФОНИН ЮРИЙ

3. Интеграции посредством ШЭП, ВШЭП не подлежат:... посмотреть текст 0 0 04/02 - 15:39 / Подписаться

2 раздел пропущен.

АФОНИН ЮРИЙ

объекты информатизации «электронного правительства... посмотреть текст 0 0 04/02 - 15:43 / Подписаться

Не создается ли коллизия в сокращения "объекта информатизации" с определением данным в п.п.4 ст.1 Закона Республики Казахстан от 24 ноября 2015 года № 418-V ЗРК "Об информатизации".

АФОНИН ЮРИЙ

объекты информатизации, размещенные на информацион... посмотреть текст 0 0 04/02 - 15:55 / Подписаться

Согласно строки 26 и п.п. 64 ст.1 Закона об информатизации, сервисный программный продукт, размещаемый на ИКП ЭП (п.1 ст.26 Закона Об информатизации), входит в определение объекта информатизации ЭП, а следовательно не логично его исключение из правил, т.к. необходимо вести учет и контроль использования бизнес-данных и персональных данных в том числе.

АФОНИН ЮРИЙ

данные обмена объекта информатизации – данные взаи... посмотреть текст 0 0 04/02 - 15:58 / Подписаться

Данные собственника объекта информатизации не являются бизнес-данными?

АФОНИН ЮРИЙ

владелец объектов информатизации (далее - Владелец... посмотреть текст 0 0 04/02 - 15:59 / Подписаться

Может ли собственник объекта информатизации участвовать в процессе интеграционного взаимодействия или только владелец?

КАКИМБЕКОВ КАЗБЕК

сервисы по предоставлению открытых данных посредст... посмотреть текст 0 0 04/02 - 15:59 / Подписаться

ограничение в виде "с использованием форматов XML, JSON и протоколов HTTP и HTTPS, посредством архитектурного стиля REST" создает необходимость интеграции геоинформационных систем через ШЭП\ВШЭП (т.к. там не всегда REST). Но в тоже время, объемы растровых карт в мб выше органичений ШЭП\ВШЭП, следовательно, технически невозможна интеграция через ШЭП\ВШЭП.

АФОНИН ЮРИЙ

5. Интеграция объектов информатизации осуществляет... посмотреть текст 0 0 04/02 - 16:01 / Подписаться

При интеграции не предполагается использовать витрину сервисов проекта Smart Bridge?

АФОНИН ЮРИЙ

11. Заявка в автоматическом режиме направляется се... посмотреть текст 0 0 04/02 - 16:07 / Подписаться

Согласно поправкам к Закону Об информатизации от 25.11.19 года п.п.20 ст.12 Компетенция сервисного интегратора исключена.

АФОНИН ЮРИЙ

13. Владелец, получив уведомление о поступлении за... посмотреть текст 0 0 04/02 - 16:14 / Подписаться

Не логично ли права доступа к тем или иным сервисам определять на законодательном уровне, сократив "футбол завки"?

АФОНИН ЮРИЙ

По результатам рассмотрения заявки Владелец соглас... посмотреть текст 0 0 04/02 - 16:18 / Подписаться

Где определены причины отказа в осуществлении интеграционного взаимодействия?

АФОНИН ЮРИЙ

15. В случае возврата Владельцем заявки на публика... посмотреть текст 0 0 04/02 - 16:23 / Подписаться

Для чего установлено ограничение в 10 дней, инициатор по результатам рекомендаций/комментариев владельца может пересмотреть заявку (в плоть до внесения изменения в свою ИС) или вообще от нее отказаться (например, воспользоваться сервисами Open API)?

АФОНИН ЮРИЙ

16. В случае отказа Владельца в публикации сервиса... посмотреть текст 0 0 04/02 - 16:27 / Подписаться

Каковы права инициатора в случае не правомерного отказа в интеграции?

АФОНИН ЮРИЙ

19. При положительном результате проверки заявки о... посмотреть текст 0 0 04/02 - 16:31 / Подписаться

Предполагается ли, что в тестовой среде ШЭП имеются тестовые базы (ИС, сервисы), а в случае применения коннекторов, то тестовые коннекторы?

АФОНИН ЮРИЙ

23. В случае успешного тестирования интеграционног... посмотреть текст 0 0 04/02 - 16:34 / Подписаться

Не предполагается ли применение автоматического (сценарного) тестирования и генерации актов тестирования для упрощения последующих процедур проверки/перепроверки актов?

АФОНИН ЮРИЙ

27.     Интеграционный сервис вводится в промышлен... посмотреть текст 0 0 04/02 - 16:38 / Подписаться

Вопросы информационной безопасности не рассматриваются при вводе в промышленную эксплуатацию, ведь по сути интеграционный сервис это маленькая ИС, а значит п.1 ст.40 Закона Об информатизации?

АФОНИН ЮРИЙ

38. В случае согласования заявки Владельцем операт... посмотреть текст 0 0 04/02 - 16:47 / Подписаться

Необходимо четко обозначить возможные причины отказа, во избежание не правомерности или превышения полномочий со стороны Оператора.

КАКИМБЕКОВ КАЗБЕК

Сервис-коннектор и клиент-коннектор поддерживают с... посмотреть текст 0 0 04/02 - 16:47 / Подписаться

поддержка с первой версии каждых СУБД? SQL Server - Microsoft SQL Server? Oracle - это производитель ПО, не СУБД

АФОНИН ЮРИЙ

Параграф 3. Порядок интеграции объектов информатиз... посмотреть текст 0 0 04/02 - 16:55 / Подписаться

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

АФОНИН ЮРИЙ

опытная эксплуатация объекта информатизации – эксп... посмотреть текст 0 0 04/02 - 16:59 / Подписаться

По тексту документа не применяется, для чего указано определение?

КАКИМБЕКОВ КАЗБЕК

При положительном результате проверки акта тестиро... посмотреть текст 0 0 04/02 - 18:30 / Подписаться

Какой процесс для исключения сервиса из реестра сервисов?

КАКИМБЕКОВ КАЗБЕК

Сведения о публикуемом сервисе 1... посмотреть текст 0 0 05/02 - 09:03 / Подписаться

Наименование информационной системы - необходимо брать с архитектурного портала "ЭП" с привязкой к владельцу