Акция

Миграция с других систем

Скидка на систему «ДЕЛО» при миграции с других решений.

Получите демоверсию и консультацию

+7(495) 221-24-31
или

Узнайте стоимость


Вернуться к списку

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

Приказом Минкомсвязи России от 27 декабря 2010 года № 190 утверждены «Технические требования к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия».

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

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

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

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

Документ достаточно объёмный и многообразный (75 пунктов), но, к сожалению, плохо структурированный, и работать с ним сложно.

Всем учить английский!

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

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

  • Спецификация универсального описания, поиска и интеграции электронных сервисов версии 2.0 – стандарт Организации по развитию стандартов структурированной информации (Universal Description Discovery and Integration, UDDI 2.0)
  • Протокол обмена структурированными сообщениями (Simple Object Access Protocol, SOAP)
  • Язык описания электронных сервисов версии 1.1 (Web Services Description Language, WSDL 1.1)
  • Базовый профиль интероперабельности версии 1.1 (WS-I Basic Profile 1.1)

В «Требованиях» даны прямые ссылки на тексты данных спецификаций в сети Интернет, но переход по ним может у неподготовленного человека вызвать легкий шок – все эти документы (как и другие пять спецификаций, использование которых рекомендуется, но не обязательно) не переведены на русский язык, т.е. всем участникам информационного обмена нужно теперь в обязательном порядке осваивать английский язык!

Я, конечно, могу понять, почему Минкомсвязи так поступило – на русский язык очень многие необходимые стандарты и спецификации не переводились, и в ближайшее время вряд ли эти переводы появятся. Тем не менее, мне интересно было бы узнать мнение юристов о том, как всё это стыкуется со ст. 66 Конституции Российской Федерации и ст.3 Федерального закона от 01.06.2005 № 53-ФЗ «О государственном языке Российской Федерации».

Конституция Российской Федерации, статья 6

1. Государственным языком Российской Федерации на всей ее территории является русский язык.

Федеральный закон от 01.06.2005 №53-ФЗ «О государственном языке Российской Федерации»

Статья 3. Сферы использования государственного языка Российской Федерации

1. Государственный язык Российской Федерации подлежит обязательному использованию:

1) в деятельности федеральных органов государственной власти, органов государственной власти субъектов Российской Федерации, иных государственных органов, органов местного самоуправления, организаций всех форм собственности, в том числе в деятельности по ведению делопроизводства;

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

Внесенные в декабре 2009 года изменения в Федеральный закон от 27.12.2002 № 184-ФЗ «О техническом регулировании» позволяют использовать международные, стандарты (ст.13), однако для этого они должны быть зарегистрированы в Федеральном информационном фонде технических регламентов и стандартов. Одним из условий регистрации является наличие «его надлежащим образом заверенного перевода на русский язык» (ст.44).

Метаданные в СМЭВ

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

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

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

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

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

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

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

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

Обработка электронных сообщений в СМЭВ

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

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

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

Кто, интересно, будет определять необходимость проверки ЭЦП? Вообще-то в приличных местах принято, что уж если сообщение подписано/заверено ЭЦП, то ЭЦП должна быть проверена получателем, и факт успешности проверки задокументирован. Также любопытно отсутствие проверки на наличие вирусов – видимо, предполагается, что в СМЭВ они не выживают?

Очень неудачно сформулирован п.14: «Если принятое и успешно прошедшее процедуры контроля электронное сообщение является сообщением запроса на предоставление электронной услуги, то информационная система поставщика разрешает использование данного электронного сервиса». Я считаю, что прохождение форматно-логического контроля – это лишь основание взять документ в работу, в то время, как решение о разрешении использования электронного сервиса может приниматься органом-получателем сообщения с учетом целого ряда обстоятельств, и в каких-то случаях возможен и отказ. Думаю, в данном случае Минкомсвязи не нужно без нужды вмешиваться в дела поставщика услуг.

Кто за что отвечает

По поводу ответственности «Требования» содержат следующие пункты:

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

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

Любят же у нас писать пусть путано, но красиво! В «Требованиях» об ответственности за реквизиты больше нигде ничего не говорится (поэтому воду можно было бы и не лить). А если уж поминать (IMHO не к месту) «иные нормативные акты» (какие? ведомств у нас много, и об электронном документообороте нормативных актов только ленивый не пишет), то уж тогда и о законах можно было бы вспомнить :)

Что понимается под «легитимностью использования ЭЦП»? И что делать, если ЭЦП успешно проверилась у получателя, а кто-то (кто?) счёл, что отправитель использовал её «нелегитимно»?

Хранение информации об информационном взаимодействии

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

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

Очень жаль, что о соответствующем законодательстве РФ не сказано хотя бы двух-трёх слов – просто любопытно, кто и когда у нас занимался (и занимался ли?) регламентацией хранения истории обмена сообщениями.

Подключение к системе взаимодействия

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

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

Любопытно, что понимается под «защищённым каналом связи»? Одни могут понять это как защищённое соединение, которое может быть реализовано и через интернет, а другие – как физически обособленную защищённую линию. Если Минкомсвязи имеет в виду второй вариант, то я бы советовала министерству как следует подумать ещё раз.

Чтобы зарегистрировать сервис, необходимо представить комплект документов (п.48):

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

Мой комментарий: У меня сложилось (возможно, и ошибочное) впечатление, что документ делали «на скорую руку» – уж больно нескладным он получился как в целом по своей структуре, так и в плане формулировок отдельных пунктов.

И, конечно, порадовала гуманность Минкомсвязи – оно ведь могло потребовать составлять идентификаторы не на английском, а, скажем, на немецкои языке :)

Источник: Кодекс
http://docs.kodeks.ru/document/902255281

Автор: Наталья Храмцовская
Источник: http://rusrim.blogspot.com/2011/01/blog-post_22.html

Возврат к списку


Ольга Савко

Начальник группы телемаркетинга

Получите качественную бесплатную консультацию

Акция

Переход на отечественную АИС МФЦ

Скидка на право использования АИС МФЦ «ДЕЛО» при миграции с других решений по автоматизации МФЦ

Акция

«Амнистия» по техподдержке

Акция для клиентов, у которых есть просроченная техподдержка до 01.01.2015

Календарь мероприятий

26октября

Важнейшее IT-событием октября - конференция «Осенний документооборот»

Узнать больше

19сентября

Конференция CNews «ИКТ в госсекторе 2018: цифровое будущее»

Узнать больше

19сентября

Конференция TAdviser «СЭД и ECM Day 2018»

Узнать больше
Все мероприятия

Наши клиенты

7 000 компаний

Наши партнеры

250

во всех городах России
и странах СНГ