Скачать документ «Технические требования к работе участников в системе межведомственного электронного взаимодействия «Түндүк»

П Р И К А З

Государственного предприятия «Центр электронного взаимодействия» при Государственном комитете информационных технологий и связи Кыргызской Республики от 1 марта 2019 года № 2-а

«Об утверждении технических требований к работе участников в системе межведомственного электронного взаимодействия «Түндүк»

В целях реализации пунктов 5, 6 и 10 Требований к взаимодействию информационных систем в системе межведомственного электронного взаимодействия «Түндүк» (далее – СМЭВ «Түндүк»), утвержденных постановлением Правительства Кыргызской Республики от 11 апреля 2018 года № 200, приказываю:

1. Утвердить:

• Требования к серверному оборудованию организаций, подключающихся к СМЭВ «Түндүк»;
• Требования к регистрации в Каталоге решений межведомственного взаимодействия;
• Требования к разработке и работе адаптеров информационных систем для осуществления запросов в системе межведомственного электронного взаимодействия «Түндүк».

2. Специалистам государственного предприятия «Центр электронного взаимодействия» при Государственном комитете информационных технологий и связи Кыргызской Республики принять необходимые меры по исполнению утверждаемых настоящим приказом Требований.
3. Контроль за исполнением настоящего приказа возложить на заместителя директора государственного предприятия «Центр электронного взаимодействия» при Государственном комитете информационных технологий и связи Кыргызской Республики А.Ч. Буржуева.

 

Директор                                                                                     Н.А. Кутнаева

 

Утверждены приказом
Государственного предприятия «Центр электронного взаимодействия»
при Государственном комитете информационных технологий и связи
Кыргызской Республики от 1 марта 2019 года № 2-а

 

Требования к серверному оборудованию организаций, подключающихся к системе межведомственного электронного взаимодействия «Түндүк»

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

 

1. Настоящие Требования к серверному оборудованию организаций, подключающихся к системе межведомственного электронного взаимодействия «Түндүк» (далее – Требования) разработаны в соответствии с постановлением Правительства Кыргызской Республики «Об утверждении Требований к взаимодействию информационных систем в системе межведомственного электронного взаимодействия «Түндүк» от 11 апреля 2018 года № 200.
2. Настоящие Требования определяют технические требования к серверному оборудованию, установке сервера безопасности, каналам связи, а также к серверному помещению организаций, подключающимся к системе межведомственного электронного взаимодействия «Түндүк».

 

2. Требования для установки сервера безопасности

 

3. Сервер безопасности устанавливается на специализированном серверном оборудовании организации. Серверное оборудование должно находится в серверном помещении или в помещении, отвечающем требованиям безопасности.
4. Для установки сервера безопасности необходимо оборудование, имеющее следующие минимальные характеристики: 64 битный Intel dual-core, AMD или иной эквивалентный вычислительный процессор с поддержкой аппаратных инструкций AES, с 4096 Мб оперативной памятью и 3Гб свободного места на жестком диске для чистой установки и дополнительным дисковым пространством для хранения лога транзакций, с USB 2.0 порт, с наличием двух сетевых интерфейсов либо одного, в случае наличия аппаратного сетевого фильтра промышленного класса, поддерживающего DNAT.

---

 

3. Требования к каналам связи

 

5. Каналы связи обеспечиваются минимально 1 Мбит или более на внешнюю зону, которая необходима для установки обновлений операционной системы, 20 Мбит или более по зоне Кыргызской Республики, а также публичный (глобальный) IP-адрес.
6. Требования к серверному помещению

 

6. Серверное оборудование аппаратно-программного комплекса и системы хранения данных размещаются в серверном помещении.

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

Для поверхности стен, потолков и пола применяются материалы, не выделяющие и не накапливающие пыль. Для напольного покрытия применяются материалы с антистатическими свойствами. Серверное помещение защищается от проникновения загрязняющих веществ.

Стены, двери, потолок, пол и перегородки серверного помещения обеспечивают герметичность помещения. Двери серверного помещения составляют не менее 1,2 метра в ширину и 2,2 метра в высоту, открываются наружу или раздвигаются. Конструкция рамы двери не предусматривает порога и центральной стойки.

7. Серверное помещение оборудуется фальшполом и (или) фальшпотолком для размещения кабельных систем и инженерных коммуникаций.
8. Через серверное помещение исключается прохождение любых транзитных коммуникаций. Трассы обычного и пожарного водоснабжения, отопления и канализации выносятся за пределы серверного помещения и не размещаются над серверным помещением на верхних этажах.
9. Монтаж коммуникационных каналов для прокладки силовых и слаботочных кабельных сетей здания выполняется в отдельных или разделенных перегородками кабельных лотках, коробах или трубах, разнесенных между собой. Слаботочные и силовые шкафы устанавливаются раздельно и закрываются на замок.

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

10. Серверное помещение надежно защищается от внешнего электромагнитного излучения.
11. При размещении оборудования в серверном помещении:

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

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

- обеспечивается наличие свободных служебных проходов для обслуживания оборудования;

- учитывается организация воздушных потоков системы обеспечения микроклимата;

- учитывается организация системы фальшполов и фальшпотолков.

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

- обслуживание оборудования;

- устранение проблем, возникающих при работе аппаратно-программного обеспечения;

- факты сбоев и отказов, а также результаты восстановительных работ;

- послегарантийное обслуживание критически важного оборудования по истечении гарантийного срока обслуживания.

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

13. Вмешательство в работу находящегося в эксплуатации оборудования возможно только с разрешения уполномоченного лица.
14. Основные и резервные серверные помещения располагаются на безопасном расстоянии в удаленных друг от друга зданиях. Требования к резервным серверным помещениям идентичны требованиям к основным серверным помещениям.
15. Для обеспечения кибербезопасности, отказоустойчивости и надежности функционирования:

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

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

3) серверное помещение оборудуется системами:

- контроля и управления доступом;

- обеспечения микроклимата;

- охранной сигнализации;

- видеонаблюдения;

- пожарной сигнализации;

- пожаротушения;

- гарантированного электропитания;

- заземления;

4) отказоустойчивость инфраструктуры серверного помещения должна составлять не менее 99,7 процента.

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

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

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

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

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

Температура в серверном помещении поддерживается в диапазоне от 20 ºС до 25 ºС при относительной влажности от 45 до 55 процентов.

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

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

Система мониторинга микроклимата контролирует климатические параметры в серверных шкафах и телекоммуникационных стойках:

- температуру воздуха;

- влажность воздуха;

- запыленность воздуха;

- скорость потока воздуха;

- задымленность воздуха;

- открытие (закрытие) дверей шкафов.

18. Система охранной сигнализации серверного помещения выполняется отдельно от систем безопасности здания. Сигналы оповещения выводятся в помещение круглосуточной охраны в виде отдельного пульта. Контролю и охране подлежат все входы и выходы серверного помещения, а также внутренний объем серверного помещения. Система охранной сигнализации имеет собственный источник резервированного питания.
19. Расположение камер системы видеонаблюдения выбирается с учетом обеспечения контроля всех входов и выходов в серверное помещение, пространства и проходов возле оборудования. Угол обзора и разрешение камер должны обеспечить распознавание лиц. Изображение с камер выводится на отдельный пульт в помещение круглосуточной охраны.
20. Система пожарной сигнализации серверного помещения выполняется отдельно от пожарной сигнализации здания. В серверном помещении устанавливаются два типа датчиков: температурные и дымовые.

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

21. Система пожаротушения серверного помещения оборудуется автоматической установкой пожаротушения, независимой от системы пожаротушения здания.

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

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

22. Система гарантированного электропитания предусматривает наличие двух вводов электропитания от разных источников внешнего электропитания на напряжение ~400/230 В, частотой 50 Гц и автономного генератора. Все источники электроэнергии подаются на автомат ввода резерва, осуществляющий автоматическое переключение на резервный ввод электропитания при прекращении, перерыве подачи электропитания на основном вводе. Параметры линий электропитания и сечение жил определяются исходя из планируемой суммарной потребляемой мощности оборудования и подсистем серверного помещения. Линии электропитания выполняются по пятипроводной схеме.

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

23. Система заземления серверного помещения выполняется отдельно от защитного заземления здания. Все металлические части и конструкции серверного помещения заземляются с общей шиной заземления. Каждый шкаф (стойка) с оборудованием заземляется отдельным проводником, соединяемым с общей шиной заземления. Открытые токопроводящие части оборудования обработки информации должны быть соединены с главным заземляющим зажимом электроустановки. Заземляющие проводники, соединяющие устройства защиты от перенапряжения с главной заземляющей шиной, должны быть самыми короткими и прямыми (без углов).
24. Размещение сервера безопасности в кабинетах, архивных, подсобных и иных помещениях запрещается.
25. Все участники СМЭВ «Түндүк», должны ограничить физический и логический доступ к серверу безопасности третьим лицам, не являющимися уполномоченными сотрудниками организации. Предоставление доступа к серверному оборудованию посторонним лицам в случае необходимости возможно только из локальной сети организации и под присмотром уполномоченного лица, с занесением события в реестр предоставления доступа.
26. Оператор СМЭВ «Түндүк» имеет право при необходимости осуществлять проверки на соответствие информационных систем Участника СМЭВ «Түндүк» законодательству Кыргызской Республики, техническим требованиям, установленным оператором СМЭВ «Түндүк».
27. Серверное оборудование Участника СМЭВ «Түндүк» размещается только в серверном помещении государственного органа, органа местного самоуправления и организации в соответствии с требованиями к серверным помещениям, установленными в настоящих Требованиях.

---

Утверждены приказом
Государственного предприятия
«Центр электронного взаимодействия»
при Государственном комитете
информационных технологий и связи
Кыргызской Республики от 1 марта 2019 года № 2-а

 

         Требования к регистрации сервисов в Каталоге решений межведомственного взаимодействия участниками системы межведомственного электронного взаимодействия «Түндүк» 

1. Общие положения
2. Настоящие Требования к регистрации сервисов в Каталоге решений межведомственного взаимодействия (далее – Каталог) участниками системы межведомственного электронного взаимодействия «Түндүк» (далее – Требования) разработаны в соответствии с постановлением Правительства Кыргызской Республики «Об утверждении Требований к взаимодействию информационных систем в системе межведомственного электронного взаимодействия «Түндүк» от 11 апреля 2018 года № 200.
3. Настоящие Требования определяют технические условия к регистрации информационных систем министерств и ведомств в Каталоге, внесению информации, а также управлению данными.
4. Каталог ведется и заполняется на государственном и официальном языках.
5. Термин, используемый в настоящих Требованиях:

Пользователь – ответственное лицо, назначенное Участником СМЭВ «Түндүк» в заявке на подключение к СМЭВ «Түндүк» для редактирования информации в Каталоге об Участнике СМЭВ «Түндүк».

2. Пользование Каталогом
3. На главной странице Каталога Пользователю представлена возможность просматривать информацию по другим Участникам СМЭВ «Түндүк», подключенным к системе межведомственного электронного взаимодействия «Түндүк» (далее – СМЭВ «Түндүк»). Для перехода на главную страницу Каталога необходимо перейти по ссылке https://catalog.ordo.gov.kg/. Также для перехода на главную страницу Каталога, необходимо нажать на знак «Түндүк» на панели навигации.

 

5. Главная страница Каталога состоит из панели навигации, где имеются следующие вкладки с информацией:

• участники – список участников системы межведомственного электронного взаимодействия «Түндүк»;
• информационные системы – список информационных систем участников СМЭВ «Түндүк» (название, участник, идентификатор);
• сервисы – список государственных и муниципальных услуг (название, информационная система, государственный орган, идентификатор, версия).
• сервера безопасности – список серверов, установленных Участникам СМЭВ «Түндүк».

Далее следует «Список участников, подключенных к системе «Түндүк», где показан список организаций, подключенных к СМЭВ «Түндүк» и их сервисы.

3. Регистрация пользователя в Каталоге
4. Регистрация Пользователя в Каталоге осуществляется после положительного рассмотрения заявки на подключение к СМЭВ «Түндүк»:

1) Администратор Государственного предприятия «Центр электронного взаимодействия» (далее – ГП «ЦЭВ») регистрирует Пользователя в Каталоге, согласно заполненной заявке на подключение к СМЭВ «Түндүк». После этого на электронную почту Пользователя, указанную в заявке на подключение, направляется ссылка для входа в личный кабинет в Каталоге.

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

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

4. Регистрация электронного сервиса в Каталоге
5. Написание наименований и описания должны быть на кириллице и не иметь сокращений для комфортного пользования Каталогом, как для Администратора, так и для Пользователей.
6. Для регистрации электронного сервиса и внесения изменений в Каталоге, необходимо:

• Ввести ссылку ordo.gov.kg в интернет-браузер.
• На панели навигации страницы Каталога нажать на кнопку «ВХОД».
• Ввести электронную почту (указанную в заявке) и созданный пароль. Нажать на кнопку «ВОЙТИ».
• На панели навигации нажать на кнопку «Личный кабинет».
• В появившемся окне появится общая информация о Пользователе и Участнике СМЭВ «Түндүк» (какому государственному, муниципальному органу, их подведомственным учреждениям или юридическим лицам относится зарегистрированная информационная система).

Для редактирования информации Участника СМЭВ «Түндүк» Пользователю необходимо нажать на название организации.

• Для внесения информации Участника СМЭВ «Түндүк» необходимо нажать на кнопку «РЕДАКТИРОВАТЬ».
• Далее необходимо заполнить поля актуальной информацией:
• имя участника – официальное наименование Участника СМЭВ «Түндүк»;
• сайт – официальный сайт участника;
• адрес – фактический адрес местонахождения;
• описание – полномочия и сфера деятельности;
• тип участника – категория участника (государственные органы, органы местного самоуправления, государственные и муниципальные учреждения и предприятии, юридические и физические лица);
• статус участника – необходимо выбрать один из вариантов, указывающий текущее состояние Участника СМЭВ «Түндүк» в Каталоге (участник, ликвидирован);
• роли участника – поставщик услуг, пользователь услуг или разработчик решений.
• Нажать на кнопку «СОХРАНИТЬ».
• На панели навигации нажать на кнопку «Личный кабинет».
• Для редактирования информации информационных систем Участника СМЭВ «Түндүк» нажать на название информационной системы.
• Нажать на кнопку «РЕДАКТИРОВАТЬ» для внесения сведений об информационной системе участника СМЭВ «Түндүк».
• Заполнить поля актуальной информацией:

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

• название – официальное наименование информационной системы;
• описание – задачи информационной системы.
• Нажать на кнопку «СОХРАНИТЬ».
• На странице «Информационная система» в нижней части указаны сервисы.

Нажать на наименование сервиса для редактирования информации.

• Нажать на кнопку «РЕДАКТИРОВАТЬ».
• Заполнить поля актуальной информацией:
• название – официальное наименование сервиса;
• описание – задачи сервиса;
• прикрепить файл документации сервиса – необходимая документация для подключения сервиса Участника СМЭВ «Түндүк» (на усмотрение).
• После окончания ввода информации необходимо нажать на кнопку «СОХРАНИТЬ».

9. Для выхода из личного кабинета Пользователя необходимо нажать на кнопку «Личный кабинет» и в нижней части страницы нажать на кнопку «ВЫХОД».

---

 

Утверждены приказом
Государственного предприятия
«Центр электронного взаимодействия»
при Государственном комитете
информационных технологий и связи
Кыргызской Республики от 1 марта 2019 года № 2-а

 

 Требования к разработке и работе адаптеров информационных систем
для осуществления запросов в системе межведомственного электронного взаимодействия «Түндүк»

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

1. Настоящие Требования к разработке и работе адаптеров информационных систем для осуществления запросов в системе межведомственного электронного взаимодействия «Түндүк» (далее – СМЭВ «Түндүк») разработаны в соответствии с постановлением Правительства Кыргызской Республики «Об утверждении Требований к взаимодействию информационных систем в системе межведомственного электронного взаимодействия «Түндүк» от 11 апреля 2018 года № 200.
2. В настоящих требованиях используются следующие понятия:

Подсистема – представляет собой часть информационной системы, принадлежащей Участнику системы межведомственного электронного взаимодействия «Түндүк» (далее – СМЭВ «Түндүк»).

Центральный сервис – централизованно определяемое короткое наименование к конкретной услуге, предоставляемой подсистемой участника СМЭВ «Түндүк». Сервис СМЭВ «Түндүк» – веб-сервис на основе SOAP (Simple Object Access Protocol), который предоставляется участником СМЭВ «Түндүк» или подсистемой и который может использоваться другими участниками или подсистемами СМЭВ «Түндүк».

3. В настоящих Требованиях используются следующие термины для определения требований к реализации протокола, в соответствии с международным стандартом RFC 1123:

Необходимо, должен – применяются для указания, что требование спецификации обязательно нужно обеспечить;

Рекомендуется, следует – используется для указания, что требование спецификации должно быть обеспечено, если этому не препятствуют уважительные причины;

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

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

2. Идентификация объектов

5. В СМЭВ «Түндүк» используются уникальные идентификаторы. Идентификаторы состоят из типа объекта и последовательности иерархических кодов.

Все идентификаторы начинаются с кода, идентифицирующего экземпляр СМЭВ «Түндүк». В коде системы используется экземпляр СМЭВ «Түндүк», который для промышленного экземпляра СМЭВ «Түндүк», который обозначается как «central-server».

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

При представлении сущностей в виде строк используется формат T:C1/C2/..., где T тип объекта и C1, C2 являются кодами компонентов.          Примечание: этот формат используется только в этом документе. В сообщениях и файлах конфигурации идентификаторы представлены в XML формате.

Участник СМЭВ «Түндүк» – УЧАСТНИК: [ЭКЗЕМПЛЯР]/ [класс участника]/ [код участника], где идентификатор состоит из следующих компонентов:

-  код соответствующий экземпляру СМЭВ «Түндүк»;

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

-  код участника который однозначно идентифицирует принадлежность участника СМЭВ «Түндүк» к классу.

Пример 1:

Идентификатор участника: central-server/GOV/7432234/ представляет собой  организацию, зарегистрированную в СМЭВ (central-server) с классом  государственного органа (GOV) и кодом 7432234.

Подсистема – ПОДСИСТЕМА: [владелец подсистемы] / [код подсистемы]. Идентификатор для подсистемы состоит из идентификатора участника СМЭВ «Түндүк», который владеет подсистемой и её кодом. Код подсистемы выбирается участником СМЭВ «Түндүк», и он должен быть уникальным в рамках подсистем этого участника.

Пример 2:

Идентификатор подсистемы: central-server/GOV/7432234/highsecurity с кодом highsecurity, принадлежащим участнику СМЭВ Түндүк, из предыдущего примера (УЧАСТНИК:central-server/GOV/7432234/).

Сервис – СЕРВИС: [поставщик услуг]/ [код услуги]/[версия]. Идентификатор сервиса состоит из идентификатора поставщика услуг (либо участника СМЭВ Түндүк, либо подсистемы), кода сервиса и его версии.  Код сервиса выбирается поставщиком услуг. Версия является необязательным параметром и может использоваться для различения технически несовместимых версий одного и того же сервиса.

Пример 3:

идентификатор сервиса: central-server/GOV/7432234/highsecurity/getSecureData/v1 идентифицирует версию v1 службы getSecureData

центральный сервис – CENTRALSERVICE: /[central-server]/[код услуги]. Список центральных сервисов управляется оператором СМЭВ «Түндүк», который также назначает уникальные коды сервисов.

Пример 4:

идентификатор центрального сервиса: central-server/populationRegisterpersonData идентифицирует центральный сервис, который возвращает данные человека из единого государственного регистра населения.

3. Формат сообщений
4. Форматы данных на основе XML для выражения идентификаторов составляются следующим образом.

Структуры данных и элементы, определенные в настоящем разделе, расположены пространстве имён http://x-road.eu/xsd/identifiers.  Полная XML-схема показана в Приложении.

Пример 5: (заголовок определения схемы)

<? xml version="1.0" encoding="UTF-8"?>

elementFormDefault="qualified" targetNamespace="http://cyber.ee/xsd/identifiers"

xmlns="http://x-road.eu/xsd/identifiers">

Комплексный тип XRoadIdentifierType служит базой для всех других типов идентификаторов (полученных путем ограничения), что содержит объединение всех полей, которые могут присутствовать в разных идентификаторах. Атрибут objectType содержит тип идентификатора и может использоваться для различения между участниками СМЭВ «Түндүк» и подсистемами, не прибегая к условиям, которые проверяют наличие отдельных полей.

 

Пример 6:

В перечислении XRoadObjectType перечислены все значения атрибута objectType.

Пример 7:

Затем необходимо определить элементы и атрибуты, используемые в XRoadIdentifierType.

Пример 8:

8. Определение сложных типов для представления конкретных типов идентификаторов осуществляются следующим образом.

 XRoadClientIdentifierType используется для представления идентификаторов, которые могут использоваться клиентами службы, а именно Участниками СМЭВ «Түндүк» и подсистемами.

Пример 9:

XRoadServiceIdentifierType может использоваться для представления идентификаторов сервисов.

Пример 10:

 XRoadCentralServiceIdentifierType может использоваться для представления идентификаторов инстанций.

Пример 11:

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

Описание дополнительных заголовков SOAP, которые используются в СМЭВ «Түндүк», осуществляется согласно настоящему разделу.

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

 

Таблица 1. Описание параметров заголовков сообщений

Поле	Тип	Обязательное или опциональное	Описание	Требования к заполнению
client	XRoadClientIdentifierType	Обязательное	Идентифицирует Клиента — сущность, которая инициирует вызов услуги.	Заполняется согласно протоколу СМЭВ «Түндүк»
service	XRoadServiceIdentifierType	Опциональное	Идентифицирует сервис, вызываемый запросом.	Заполняется согласно протоколу СМЭВ «Түндүк»
centralService	XRoadCentralService-IdentifierType	Опциональное	Идентифицирует центральную службу, вызываемую запросом.	Заполняется согласно протоколу СМЭВ «Түндүк»
id	string	Обязательное	Уникальный идентификатор для сообщения.	Необходимо использовать следующий метод генерации ID — 30 байт случайных данных, в кодировке Base64.
userId	string	Обязательное	Пользователь, действие которого инициировало запрос. Идентификатор пользователя должен быть с двухбуквенным ISO код страны (например, KG12345678901).	userId — Пользователь, действие которого инициировало запрос. Идентификатор пользователя следует формировать:   1. Двухбуквенным ISO кодом страны с добавлением персонального идентификационного номера пользователя (например, KG20102199900011). 2. Иным уникальным идентификатором пользователя (например, идентификатор пользователя используемый в АИС) такой метод передачи идентификаторов рекомендуется применять в тех случаях, когда невозможно идентифицировать пользователя по определенным причинам (запросы от правоохранительных органов), однако необходимо, чтобы АИС, запрашивающая информацию, могла идентифицировать конкретного пользователя. Информацию, определяющую пользователя по идентификатору, необходимо хранить на постоянной основе даже в случае увольнения сотрудников или вывода АИС из эксплуатации. 3. Иным уникальным идентификатором процесса (например, фоновой синхронизации между регистрами), который инициировал запрос данных.
requestHash	string	Опциональное	Для ответов. Это поле содержит хэш запроса SOAP сообщения.	Это поле автоматически заполняется
requestHash/ @algorithmId	string	Обязательное	Идентифицирует хэш-алгоритм, который был использован для вычисления значения запроса поля Hash. алгоритмы обозначаются как URI перечисленные в XML-DSIG спецификации [DSI13].	Это поле автоматически заполняется поставщиком сервисов сервера безопасности.
issue	string	Опциональное	Идентифицирует заявление, основание или документ, который послужил основанием обращения к сервису. Это поле используется для подключения службы запросов (и ответов) к рабочим процедурам.	1. Возможно не передавать данную информацию 2. Рекомендуется передавать на каком основании были запрошены данные (например, автозаполнение формы, проверка задолженности, прием на работу, а также иные причины)
authentication Method	string	Обязательное	Метод аутентификации	1. authenticationMethod должно быть одним из следующих: EID - с удостоверением личности (ID-CARD, DIGI-ID); MID - с мобильным удостоверением личности (MOBILE-ID); CERT - с другим сертификатом; EXTERNAL - через стороннюю услугу (BANK-LINK); PASSWORD - с идентификатором пользователя и паролем; SYSTEM - когда запрос был отправлен заданием cron или другим автоматическим процессом.   2. Возможно не передавать данное поле, если причиной вызова запроса не является конкретный пользователь АИС (например, задача cron или иные внутренние алгоритмы)
profileVersion	string	Обязательное	Версия протокола СМЭВ «Түндүк».	Для СМЭВ «Түндүк» 6 версия протокола 4.0

При ответе служба должна скопировать все поля заголовка из запроса в ответ.     

10. Содержание сообщения должно использовать соглашение о кодировании SOAP с документами/литералами. Согласно этому соглашению, содержание запроса должно быть обернуто в элемент с именем foo, а содержание ответа должно быть обернуто в элемент с именем fooResponse, где foo – это имя сервиса. Имя сервиса, используемое в элементе обертки, должно соответствовать элементу serviceCode поля заголовка сервиса.

4. Описание сервисов

 

11. Сервисы описываются с использованием языка описания веб-служб WSDL.
12. СМЭВ «Түндүк» поддерживает различные версии сервисов. Различные версии сервиса представляют незначительные технические изменения в описании услуги.

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

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

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

14. Описание сервисов с помощью WSDL осуществляются следующим образом.

Описания сервисов должны быть написаны на языке WSDL [WSD01] с учетом следующих ограничений и расширений.

Комбинация стиля/использования привязки WSDL должна быть документом/литералом (binding style="document"; use="literal").

Параметры ввода и вывода служб описываются с использованием XML-схемы [XSD04a, XSD04b].

Примечание: Чтобы избежать путаницы со стороны клиента, является ли пустой ответ тихой ошибкой или просто не содержит выходных записей, при разработке сервиса возврата данных, рекомендуется чтобы для любых вызовов сервиса ответ содержал по меньшей мере непустой скалярный параметр. Этот параметр может быть нетехническим сообщением об ошибке (технические сообщения об ошибках должны быть возвращены с сообщениями о сбоях SOAP).

В таблице 2 перечислены элементы, которые можно добавить в WSDL для передачи информации, относящейся к СМЭВ. Идентификатор предварительного пространства имен привязан к пространству имен «http://x-road.eu/xsd/identifiers».

Таблица 2. Элементы WSDL для служб СМЭВ «Түндүк»

 

Поле	Описание
/definitions/binding/operation/@name	Код сервиса
/definitions/binding/operation/ id:version	Версия сервиса
/definitions/portType/operation/ documentation/xrd:title	Название сервиса (human readable— Для предоставления пользователю)
/definitions/portType/operation/ documentation/xrd:notes	Описание сервиса (human readable— Для предоставления пользователю)
documentation/xrd:notes Description of the service (for displaying to users) /definitions/portType/operation/ documentation/xrd:techNotes	Описание сервиса (для разработчиков пользователю)

5. Заключительные положения
6. Участники СМЭВ «Түндүк» при разработке адаптеров и работе с ними обязаны соблюдать настоящие Требования.

Приложение к Требованиям

к разработке и работе адаптеров информационных систем для осуществления запросов в системе межведомственного электронного взаимодействия «Түндүк»

 XML Schema for Identifiers

Globally unique identifier in the XRoad system. Identifier consists of object type specifier and list of hierarchical codes (starting with code that identifiers the XRoad instance).

Enumeration for XRoad identifier types.

Identifies the XRoad instance. This field is applicable to all identifier types.

Type of the member (company, government institution, private person, etc.)

 Code that uniquely identifies a member of given member type.

 Code that uniquely identifies a subsystem of given XRoad member.

 Code that uniquely identifies a service offered by given XRoad member or subsystem.

 Version of the service.