Смэв фмс

<!–

Александр Левашов

–>

Сервис ФМС «умирает» под давлением запросов через СМЭВ

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

В ходе заседания президиума Ассоциации российских банков (АРБ) ряд ее участников подняли вопрос о проблемах при взаимодействии с Федеральной миграционной службой (ФМС).

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

«На практике по этой причине банки часто вынуждены отказывать клиентам – физическим лицам в обслуживании, – говорится в заявлении АРБ. – Вместе с тем такие отказы, и особенно отказы в выдаче вкладов, неизбежно расцениваются клиентами как признак наличия у банка трудностей, чреватых отзывом лицензии, что в существенной мере вредит имиджу и деловой репутации кредитной организации, а также может легко спровоцировать панику вкладчиков».

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

В ФМС не смогли прокомментировать жалобы банков. По словам источника CNews, знакомого с деятельностью ФМС, у сервиса проверки паспортных данных есть две существенные проблемы. Во-первых, медленно работает его база данных, во-вторых, он периодически «падает».

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

«Для гражданина это не критично, он ждет проверку своих данных лишь один раз. Но для банка, который обращается к сервису регулярно, это неприемлемо», – считает собеседник CNews.

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

Такую услугу, в частности, предоставляет Национальное бюро кредитных историй (НБКИ). Как говорит его представитель Елена Григорьева, по договору между НБКИ и ФМС бюро и служба установили «b2b-соединение, с помощью которого бюро транслирует запросы банков на проверку статусов паспортов в ФМС. ФМС самостоятельно осуществляет проверку по своей базе и присылает ответ, в котором указан статус, по тому же каналу».

«Первая Портовая Компания» поделилась опытом внедрения российской ERP

Смэв фмс

Соединение НБКИ с ФМС, по словам Григорьевой, установлено не через СМЭВ. Сбоев в его работе НБКИ не испытывает, условия соглашения не раскрывает.

Некоторые бюро кредитных историй, по мнению собеседника CNews, могут осуществлять проверку паспортов через «дружественные» банки, подключенные к сервису ФМС через СМЭВ, а затем продавать эту услугу другим банкам, что является нарушением закона.

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

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

Руслан Косарим, Angara Security: В связи с нехваткой экспертизы на рынке вырос интерес к MSS-сервисам

Смэв фмс

«За последний год к СМЭВ подключились около 800 банков, соответственно, значительно возросла нагрузка и на сервис по проверке паспортных данных, – сообщил CNews замминистра связи Алексей Козырев. – Сервис ФМС является одним из самых востребованных в СМЭВ. Поэтому служба должна правильно управлять его мощностью».

Рост запросов через СМЭВ также стал причиной сбоев в работе ИТ-систем Росреестра, о чем ранее писал CNews. К этому ведомству обращаются региональные и федеральные органы власти, запрашивая выписки, необходимые им для предоставления госуслуг.

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

<!–

Ирина Пешкова

–>

Корневой ИТ-системе электронного правительства грозит реформа

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

Мишустин реформирует СМЭВ

Премьер-министр России Михаил Мишустин подписал постановление о реформе системы электронного межведомственного взаимодействия (СМЭВ). Цель реформы – повысить эффективность работы госорганов и качество электронных услуг. Постановление от 4 сентября 2020 г. №1347 опубликовано на сайте Правительства.

СМЭВ – это корневая система электронного правительства, созданная для взаимодействия чиновников федеральных, региональных и муниципальных органов при предоставлении госуслуг. Реализация взаимодействия информационных систем организаций и ведомств осуществляется в рамках государственной целевой программы «Информационное общество (2011-2020 гг.)».

Что должно измениться

Нынешняя реформа предполагает несколько изменений.

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

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

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

Это поможет уменьшить нагрузку на отдельные сегменты системы, снизить количество сбоев и существенно повысить её надёжность.

Система работает в соответствии с Федеральным законом от 27 июля 2010 г. №210-ФЗ «Об организации предоставления государственных и муниципальных услуг».

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

Напомним, что СМЭВ, призванная упростить гражданам процесс получения госуслуг, создавалась и модернизировалась много лет. Первое упоминание необходимости автоматизации соответствующих процессов можно найти еще в концепции формирования в России электронного правительства до 2010 г. Ее в 2007-2008 гг. подготовило Мининформсвязи под руководством Леонида Реймана. С 2008 г. по май 2012 г. за создание системы отвечало Минкомсвязи под руководством Игоря Щеголева, а затем проект курировала новая команда министерства во главе с Николаем Никифоровым.

На CNews Forum в ноябре 2018 г. Владислав Онищенко, руководитель Аналитического центра при Правительстве России, организации, который выполнял функцию проектного офиса программы «Цифровая экономика» сказал, что СМЭВ накопила технологическое отставание от растущих потребностей цифрового обмена информацией.

В конце августа 2018 г. на заседании подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг одобрен план развития Единой системы межведомственного электронного взаимодействия (СМЭВ) на 2018-2020 гг.

Некоторые ключевые подробности о СМЭВ

В целом, под инфраструктурой электронного правительства власти России подразумевают совокупность государственных информационных систем (ГИС), программно-аппаратных средств и сетей связи, обеспечивающих при оказании услуг и осуществлении функций в электронной форме взаимодействие госорганов, граждан и юридических лиц. В состав существующей инфраструктуры входят, помимо СМЭВ, портал госуслуг (ЕПГУ), единая система идентификации и аутентификации (ЕСИА), система досудебного обжалования решений, принятых при осуществлении госуслуг, единая система нормативной справочной информации и др.

Количество российских компаний, использующих облачную инфраструктуру, утроилось

Смэв фмс

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

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

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

По данным «Ростелекома», в 2017 г. общее количество запросов, переданных с помощью СМЭВ, превысило 19 млрд. СМЭВ также обеспечивает передачу информации о платежах, совершенных банковскими организациями, в Государственную информационную систему о государственных и муниципальных платежах (ГИС ГМП). В 2017 г. количество подключенных к СМЭВ удостоверяющих центров достигло 160 участников.

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

Смэв фмс

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

Больше проверок:  Технологический портал смэв

Взаимодействие между федеральными органами исполнительной власти и государственными внебюджетными фондами при предоставлении госуслуг стало осуществляться исключительно с использованием СМЭВ с 1 января 2015 г. Тогда же власти запретили самостоятельную разработку новых сервисов. Органам власти субъектов России было рекомендовано перейти на единый электронный сервис с 1 января 2017 г., согласно постановлению Правительства №1222 «О дальнейшем развитии единой системы межведомственного электронного взаимодействия».

Со 2 апреля 2018 г. столичные суды общей юрисдикции стали направлять все исполнительные документы в адрес всех территориальных органов ФССП России только в электронном виде посредством СМЭВ.

Система межведомственного электронного взаимодействия

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

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

Положительный эффектПравить

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

Функции СМЭВПравить

  • Ведение реестра электронных сервисов
  • Ведение политик безопасности, применяемых к зарегистрированным электронным сервисам
  • Маршрутизация сообщений к зарегистрированным электронным сервисам при синхронном и асинхронном взаимодействии
  • Протоколирование обращений (входящих и исходящий сообщений) к электронным сервисам
  • Гарантированная доставка сообщений, осуществляемая за счет механизма повторных вызовов электронных сервисов при сбоях
  • Обеспечение оповещения Оператора СМЭВ о сбоях в функционировании электронных сервисов
  • Передача информации о событиях на СМЭВ по подписке заинтересованным Пользователям (информационным системам)
  • Формирование динамически создаваемой статистики использования электронных сервисов
  • Подписание электронных сообщений электронной подписью
  • Форматно-логический контроль входящих сообщений
  • Контроль и мониторинг процессов межведомственного обмена с использованием СМЭВ

Техническое описание системыПравить

СМЭВ состоит из сети защищенных каналов связи между узлами, расположенными в центрах обработки данных Ростелекома. Каждый узел СМЭВ — это шина на базе Oracle Enterprise Service Bus. Участники СМЭВ являются поставщиками и потребителями сведений:

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

Технические подробности взаимодействияПравить

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

Для передачи электронных сообщений используется протокол SOAP поверх HTTP.

Для размещения электронной подписи в сообщениях применяются стандарты XMLDsig и PKCS#7.

Ограничение доступа реализовано на основании сведений, передаваемых в сообщении с использованием стандарта WS-Security.

СМЭВ обладает функциями протоколирования взаимодействия. Также СМЭВ позволяет установить кто, в каком объёме и на основании каких привилегий делал запрос информации.

Хронология реализации проектаПравить

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

В 2009 году обеспечена возможность взаимодействия между Единым порталом государственных услуг (ЕПГУ) и информационными системами федеральных органов исполнительной власти (ФОИВ) для заказа государственных услуг в электронном виде. Взаимодействие обеспечивалось с использованием синхронных электронных сервисов. На конец года было зарегистрировано порядка 30 электронных сервисов.

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

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

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

Кредитные организации (банки) получили доступ к СМЭВ под контролем ЦБ согласно постановлению Правительства Российской Федерации от 22.12.2012 № 1382. В Федеральном законе от 07.08.2001 № 115-ФЗ также определена возможность доступа к СМЭВ для упрощенной идентификации негосударственных пенсионных фондов, части страховых организаций, организаций федеральной почтовой связи и некоторых других организаций, осуществляющих операции с денежными средствами или иным имуществом.

Постановлением Правительства Российской Федерации от 19 ноября 2014 года № 1222 «О дальнейшем развитии единой системы межведомственного электронного взаимодействия» с 1 января 2015 года запрещена разработка электронных сервисов в СМЭВ согласно Методическим рекомендациям по работе в СМЭВ версии 2.X. Новые сведения следует предоставлять согласно Методическим рекомендациям по работе в СМЭВ версии 3.X. — таким образом третья версия СМЭВ официально введена в эксплуатацию с начала 2015 года.

ПримечанияПравить

  1. Федеральный закон от 27 июля 2010 г. N 210-ФЗ «Об организации предоставления государственных и муниципальных услуг». Дата обращения: 23 октября 2018. Архивировано 9 февраля 2022 года.
  2. CNEWS 2013 № 65. Дата обращения: 23 марта 2013. Архивировано 12 марта 2013 года.
  3. Постановление Правительства РФ от 28 ноября 2011 г. № 697 «О единой системе межведомственного электронного взаимодействия». Дата обращения: 23 октября 2018. Архивировано 23 октября 2018 года.
  4. Технологический портал СМЭВ
  5. Проект «Электронное правительство». Дата обращения: 10 января 2013. Архивировано 10 января 2013 года.
  6. Telekomza. Минкомсвязи определилось с форматом документов для СМЭВ — PDF/А + реквизиты в XML. Дата обращения: 1 октября 2014. Архивировано 6 октября 2014 года.
  7. Приказ Минкомсвязи РФ от 27.12.2010 года № 190 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия». URL: http://smev.gosuslugi.ru/portal/api/files/get/424 Архивная копия от 7 сентября 2014 на Wayback Machine
  8. Методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи. URL: http://smev.gosuslugi.ru/portal/api/files/get/6671 Архивная копия от 6 октября 2014 на Wayback Machine
  9. Николай Никифоров: «Электронные сервисы в СМЭВ должны функционировать круглосуточно». Минкомсвязь России. Дата обращения: 1 июня 2016. Архивировано 20 сентября 2016 года.
  10. Сервис ФМС «умирает» под давлением запросов через СМЭВ. Дата обращения: 23 октября 2018. Архивировано 23 октября 2018 года.
  11. Шквал запросов через СМЭВ физически ломает оборудование Росреестра. Дата обращения: 23 октября 2018. Архивировано 23 октября 2018 года.

СсылкиПравить



В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.

Общая схема взаимодействия через СМЭВ

Участники взаимодействия

Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.

Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).

image

Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.

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

Виды сведений

Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.

Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.

На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.

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

Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:

image

Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:

image

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

Обмен по универсальному виду сведений можно представить так:

image

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

  • номер заявления портала и сведения, позволяющие определить услугу;
  • целевое подразделение, к которому пользователь обращается за услугой.
Больше проверок:  Главная страница Проверки gov ru

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

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

Очереди сообщений и процесс взаимодействия

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

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

Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.

image

На каждый запрос может поступить как успешный, так и неуспешный ответ.

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

  • Произошло расхождение справочных данных на портале и у поставщика;
  • Нужного соответствия просто нет в настройках системы поставщика.

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

Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.

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

Постановка задачи

С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.


Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.

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

Смэв фмс

Система межведомственного электронного взаимодействия (СМЭВ) задумывалась как цифровая среда предоставления услуг и исполнения государственных и муниципальных функций в электронной форме.

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

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

В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 3.0, и о паре интересных нюансов, с которыми пришлось при этом столкнуться.

Здравствуйте!

Может возникнуть вопрос. Почему своими силами? Когда для СМЭВ 3 есть целый Технологический портал, где

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

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

По той простой причине, что уже есть собственная информационная система, работающая с форматами электронной подписи XMLDSig, XAdES, в которой применяются библиотеки проекта Apache Santuario, реализующие основные стандарты безопасности для XML. А также библиотеки, входящие в состав КриптоПро JCSP, помимо работы с XML, обеспечивающие API криптографических функций СКЗИ КриптоПро CSP.

Написание собственных методов для работы с электронными подписями СМЭВ 3 в данном случае выглядит более целесообразно, нежели разворачивание полного клиента поставляемого:
ФГБУ НИИ «Восход» (до 21 марта 2016 года ФГУП НИИ «Восход») или интеграция, его отдельных классов и пакетов.

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

Анализ исходных данных

Загружаем с портала СМЭВ 3:

Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.

Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1">
   <S:Body>
      <ns2:SendRequestRequest xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">
         <ns:SenderProvidedRequestData Id="SIGNED_BY_CONSUMER" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">	<ns:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns:MessageID><ns2:MessagePrimaryContent><ns1:BreachRequest xmlns:ns1="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0"  xmlns:ns2="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"  xmlns:ns3="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1" Id="PERSONAL_SIGNATURE"> <ns1:RequestedInformation> <ns2:RegPointNum>Т785ЕС57</ns2:RegPointNum> </ns1:RequestedInformation> <ns1:Governance> <ns2:Name>ГИБДД РФ</ns2:Name> <ns2:Code>GIBDD</ns2:Code> <ns2:OfficialPerson> <ns3:FamilyName>Загурский</ns3:FamilyName> <ns3:FirstName>Андрей</ns3:FirstName> <ns3:Patronymic>Петрович</ns3:Patronymic> </ns2:OfficialPerson></ns1:Governance> </ns1:BreachRequest> </ns2:MessagePrimaryContent>	<ns:TestMessage/></ns:SenderProvidedRequestData>
         <ns2:CallerInformationSystemSignature><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/><ds:Reference URI="#SIGNED_BY_CONSUMER"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>J3746ks34pOcPGQpKzc0sz3n9+gjPtzZbSEEs4c3sTwbtfdaY7N/hxXzEIvXc+3ad9bc35Y8yBhZ/BYbloGt+Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIBcDCCAR2gAwIBAgIEHVmVKDAKBgYqhQMCAgMFADAtMRAwDgYDVQQLEwdTWVNURU0xMQwwCgYDVQQKEwNJUzIxCzAJBgNVBAYTAlJVMB4XDTE1MDUwNzEyMTUzMFoXDTE4MDUwNjEyMTUzMFowLTEQMA4GA1UECxMHU1lTVEVNMTEMMAoGA1UEChMDSVMyMQswCQYDVQQGEwJSVTBjMBwGBiqFAwICEzASBgcqhQMCAiMBBgcqhQMCAh4BA0MABEDoWGZlTUWD43G1N7TEm14+QyXrJWProrzoDoCJRem169q4bezFOUODcNooQJNg3PtAizkWeFcX4b93u8fpVy7RoyEwHzAdBgNVHQ4EFgQUaRG++MAcPZvK/E2vR1BBl5G7s5EwCgYGKoUDAgIDBQADQQCg25vA3RJL3kgcJhVOHA86vnkMAtZYr6HBPa7LpEo0HJrbBF0ygKk50app1lzPdZ5TtK2itfmNgTYiuQHX3+nE</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns2:CallerInformationSystemSignature>
      </ns2:SendRequestRequest>
   </S:Body>
</S:Envelope>

Дедуктивным методом выясняется что:

  • больше не используется прием с выносом из содержимого тега Signature в Security заголовок элемента BinarySecurityToken с сертификатом открытого ключа проверки электронной подписи и ссылкой на него через SecurityTokenReference в теле самого Signature, как, например, в СМЭВ 2.4.6. Теперь сертификат должен находиться внутри Signature.
  • второе и, по сути, самое существенное и важное изменение, оказывающее большое влияние на процесс подписи — это добавление новой проприетарной трансформации:
    <ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/>

Через эту трансформацию распространяются собственные правила каноникализации СМЭВ 3.

Каноникализация — процесс приведения данных, имеющих несколько возможных форм представления, к одному нормализованному стандартному виду.

Перед тем как посчитать хэш подписываемого атрибута в XML-конверте и подписать, необходимо выполнить его конвертацию в заданный правилами СМЭВ 3 вид.

В поисках описания трансформации urn://smev-gov-ru/xmldsig/transform открываем Методические рекомендации 3.4.0.3

Знакомимся с пунктом 4.4.2.1 Правила формирования электронной подписи сообщений

Формат подписи XMLDSig detached (https://www.w3.org/TR/xmldsig-core/)

Трансформация, дополнительно к канонизации urn://smev-gov-ru/xmldsig/transform

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

Пункт Методических указаний 12.4. ПРИЛОЖЕНИЕ 4: ОБРАЗЦОВАЯ РЕАЛИЗАЦИЯ ТРАНСФОРМАЦИИ URN://SMEV-GOV-RU/XMLDSIG/TRANSFORM
содержит Java класс SmevTransformSpi.java, реализующий алгоритм трансформации «urn://smev-gov-ru/xmldsig/transform», наследник org.apache.xml.security.transforms.TransformSpi из библиотеки Apache Santuario.

Таким образом, чтобы обеспечить каноникализацию подписываемого конверта СМЭВ 3, можно использовать в своем коде этот класс трансформации.

Единственным условием и ограничением в этом случае будет, что для обработки XML-документа при формировании подписи или ее проверки нужно использовать именно org.apache.xml.security.signature.XMLSignature из проекта Apache Santuario.

Задействовать инструменты из пакетов javax.xml.crypto.dsig или ru.CryptoPro.JCPxml.xmldsig просто так уже не получится.

Подготовка к подписи по правилам СМЭВ 3

Apache Santuario изначально ничего не знает про ГОСТ криптографические алгоритмы и СКЗИ КриптоПро.

В библиотеке xmlsec-1.5.0.jar в файле \org\apache\xml\security\resource\config.xml содержатся настройки только для работы с зарубежными криптографическими алгоритмами.

Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.

По старинке это делалось так:

//APACHE-SANTUARIO INIT WITH CryptoPro JCP
        System.setProperty("org.apache.xml.security.resource.config", "resource/jcp.xml");
        org.apache.xml.security.Init.init();
        String cfile1 = System.getProperty("org.apache.xml.security.resource.config");
        LOGGER.log(Level.INFO, "Init class URL: " + org.apache.xml.security.Init.class.getProtectionDomain().getCodeSource().getLocation());
        LOGGER.log(Level.INFO, cfile1);

В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:

ru.CryptoPro.JCPxml.xmldsig.JCPXMLDSigInit.init();

Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:

  try {
                Transform.register(SmevTransformSpi.ALGORITHM_URN, SmevTransformSpi.class.getName());
                santuarioIgnoreLineBreaks(true);
                LOGGER.log(Level.INFO, "SmevTransformSpi has been initialized");
            } catch (AlgorithmAlreadyRegisteredException e) {
                LOGGER.log(Level.INFO, "SmevTransformSpi Algorithm already registered: " + e.getMessage());
            } 

Заодно сразу выполняем требование из Методических указаний:

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

santuarioIgnoreLineBreaks(true);

    private static final String IGNORE_LINE_BREAKS_FIELD = "ignoreLineBreaks";

/**
     * Apache Santuario privileged switch IgnoreLineBreaks property
     * 
     * @param mode
     */
    private void santuarioIgnoreLineBreaks(Boolean mode) {
        try {
            Boolean currMode = mode;
            AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
                
                public Boolean run() throws Exception {
                    Field f = XMLUtils.class.getDeclaredField(IGNORE_LINE_BREAKS_FIELD);
                    f.setAccessible(true);
                    f.set(null, currMode);
                    return false;
                }
            });
            
        } catch (Exception e) {
            LOGGER.warning("santuarioIgnoreLineBreaks " + ExceptionUtils.getFullStackTrace(e));
        }
    }

Делается это в привилегированном блоке AccessController.doPrivileged
и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.

Просто через настройку системного свойства:

System.setProperty("org.apache.xml.security.ignoreLineBreaks", "true");

Через настройку опции JVM:

-Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true

Если взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».

private static boolean ignoreLineBreaks =
        AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
            public Boolean run() {
                return Boolean.valueOf(Boolean.getBoolean
                    ("org.apache.xml.security.ignoreLineBreaks"));
            }
        }).booleanValue();
public static boolean ignoreLineBreaks() {
        return ignoreLineBreaks;
    }

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

Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.

С этим свойством, конечно, возникает вопрос к Apache Santuario:

Смэв фмс

Подпись сообщений СМЭВ 3

Для подписи документов СМЭВ 3 все готово.

Код подписания выглядит следующим образом:

private static final String XMLDSIG_MORE_GOSTR34102001_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411";
    private static final String XMLDSIG_MORE_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr3411";
    private static final String CANONICALIZATION_METHOD = "http://www.w3.org/2001/10/xml-exc-c14n#";
    private static final String DS_SIGNATURE = "//ds:Signature";
    private static final String SIG_ID = "sigID";
    private static final String COULD_NOT_FIND_XML_ELEMENT_NAME = "ERROR! Could not find xmlElementName = ";
    private static final String GRID = "#";
    private static final String XML_SIGNATURE_ERROR = "xmlDSignature ERROR: ";

try {
            // инициализация объекта чтения XML-документа
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
            
            // установка флага, определяющего игнорирование пробелов в
            // содержимом элементов при обработке XML-документа
            dbf.setIgnoringElementContentWhitespace(true);
            
            // установка флага, определяющего преобразование узлов CDATA в
            // текстовые узлы при обработке XML-документа
            dbf.setCoalescing(true);
            
            // установка флага, определяющего поддержку пространств имен при
            // обработке XML-документа
            dbf.setNamespaceAware(true);
            
// загрузка содержимого подписываемого документа на основе
            // установленных флагами правил из массива байтов data            DocumentBuilder documentBuilder = dbf.newDocumentBuilder();
         
           Document doc = documentBuilder.parse(new ByteArrayInputStream(data));
            
            /*
             * Добавление узла подписи <ds:Signature> в загруженный XML-документ
             */
            
            // алгоритм подписи (ГОСТ Р 34.10-2001)
            final String signMethod = XMLDSIG_MORE_GOSTR34102001_GOSTR3411;
            
            // алгоритм хеширования, используемый при подписи (ГОСТ Р 34.11-94)
            final String digestMethod = XMLDSIG_MORE_GOSTR3411;
            
            final String canonicalizationMethod = CANONICALIZATION_METHOD;
            
         
            String[][] filters = {{XPath2FilterContainer.SUBTRACT, DS_SIGNATURE}};
            String sigId = SIG_ID;
                
                // инициализация объекта формирования ЭЦП в соответствии с
                // алгоритмом ГОСТ Р 34.10-2001
                XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod);
                
                // определение идентификатора первого узла подписи
               
                sig.setId(sigId);
                
                // получение корневого узла XML-документа
                Element anElement = null;
                if (xmlElementName == null) {
                    anElement = doc.getDocumentElement();
                } else {
                    NodeList nodeList = doc.getElementsByTagName(xmlElementName);
                    anElement = (Element) nodeList.item(0);
                }
                // = doc.getElementById("#AppData");
                // добавление в корневой узел XML-документа узла подписи
                if (anElement != null) {
                    anElement.appendChild(sig.getElement());
                } else {
                    throw new SignatureProcessorException(COULD_NOT_FIND_XML_ELEMENT_NAME + xmlElementName);
                }
                
                /*
                 * Определение правил работы с XML-документом и добавление в узел подписи этих
                 * правил
                 */
                
                // создание узла преобразований <ds:Transforms> обрабатываемого
                // XML-документа
                Transforms transforms = new Transforms(doc);
                
                // добавление в узел преобразований правил работы с документом
                // transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE);
                transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
                transforms.addTransform(SmevTransformSpi.ALGORITHM_URN);
                
                // добавление в узел подписи ссылок (узла <ds:Reference>),
                // определяющих правила работы с
                // XML-документом (обрабатывается текущий документ с заданными в
                // узле <ds:Transforms> правилами
                // и заданным алгоритмом хеширования)
                sig.addDocument(xmlElementID == null ? "" : GRID + xmlElementID, transforms, digestMethod);
                
                /*
                 * Создание подписи всего содержимого XML-документа на основе закрытого ключа,
                 * заданных правил и алгоритмов
                 */
                
                // создание внутри узла подписи узла <ds:KeyInfo> информации об
                // открытом ключе на основе
                // сертификата
                sig.addKeyInfo(x509Cert);
                
                // создание подписи XML-документа
                sig.sign(privateKey);
            
            // определение потока, в который осуществляется запись подписанного
            // XML-документа
            bais = new ByteArrayOutputStream();
            
            // инициализация объекта копирования содержимого XML-документа в
            // поток
            TransformerFactory tf = TransformerFactory.newInstance();
            
            // создание объекта копирования содержимого XML-документа в поток
            Transformer trans = tf.newTransformer();
            
            // копирование содержимого XML-документа в поток
            trans.transform(new DOMSource(doc), new StreamResult(bais));
            bais.close();
        } catch (TransformationException e) {
            throw new SignatureProcessorException("TransformationException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (XMLSignatureException e) {
            throw new SignatureProcessorException("XMLSignatureException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (TransformerException e) {
            throw new SignatureProcessorException("TransformerException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (IOException e) {
            throw new SignatureProcessorException("IOException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (XMLSecurityException e) {
            throw new SignatureProcessorException("XMLSecurityException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (SAXException e) {
            throw new SignatureProcessorException("SAXException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (ParserConfigurationException e) {
            throw new SignatureProcessorException(
                    "ParserConfigurationException " + XML_SIGNATURE_ERROR + e.getMessage());
        }
        return bais.toByteArray();

Основными параметрами здесь являются:

byte[] data, // XML сообщение в виде массива байтов

String xmlElementName, // имя элемента в XML вместе с префиксом, в который следует добавить подпись, для СМЭВ-3 в общем случае "ns2:CallerInformationSystemSignature"

String xmlElementID // ID элемента в XML (если присутствует) вместе с префиксом, на который следует поставить подпись, для СМЭВ-3 в общем случае "SIGNED_BY_CONSUMER"

X509Certificate certificate // сертификат открытого ключа проверки подписи

PrivateKey privateKey // закрытый ключ подписи

Проверка подписи сообщения СМЭВ 3

Код проверки подписи выглядит следующим образом:

private static final QName QNAME_SIGNATURE = new QName("http://www.w3.org/2000/09/xmldsig#", "Signature", "ds");
    private static final String SIGNATURE_NOT_FOUND = "Signature not found!";
    private static final String SIGNATURE_NOT_VALID = "Signature not valid";
    private static final String SMEV_SIGNATURE_PASSED_CORE_VALIDATION = "SmevSignature passed core validation";
    private static final String VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION = "Verify signature on XML IOException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION = "Verify signature on XML ParserConfigurationException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION = "Verify signature on XML SAXException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION = "Verify signature on XML XMLSignatureException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION = "Verify signature on XML XMLSecurityException: ";
    private static final String ID = "Id";

   boolean coreValidity = true;
        try {
            DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance();
            bf.setNamespaceAware(true);
            DocumentBuilder b = bf.newDocumentBuilder();
            Document doc = b.parse(new InputSource(new ByteArrayInputStream(signedXmlData)));
            
            NodeList sigs = doc.getElementsByTagNameNS(QNAME_SIGNATURE.getNamespaceURI(), QNAME_SIGNATURE.getLocalPart());
            org.apache.xml.security.signature.XMLSignature sig = null;
            sigSearch: {
                for (int i = 0; i < sigs.getLength(); i++) {
                    Element sigElement = (Element) sigs.item(i);
                    String sigId = sigElement.getAttribute(ID);
                    if (sigId != null) {
                        sig = new org.apache.xml.security.signature.XMLSignature(sigElement, "");
                        break sigSearch;
                    }
                }
                throw new XMLSignatureVerificationException(SIGNATURE_NOT_FOUND);
            }
            org.apache.xml.security.keys.KeyInfo ki = (org.apache.xml.security.keys.KeyInfo) sig.getKeyInfo();
            
            X509Certificate certificate = ki.getX509Certificate();
            
            if (!sig.checkSignatureValue(certificate.getPublicKey())) {
                coreValidity = false;
                LOGGER.log(Level.INFO, SIGNATURE_NOT_VALID);
            } else {
                LOGGER.log(Level.INFO, String.format(SMEV_SIGNATURE_PASSED_CORE_VALIDATION));
            }
            
        } catch (IOException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (ParserConfigurationException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (SAXException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (org.apache.xml.security.signature.XMLSignatureException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (XMLSecurityException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION + ExceptionUtils.getStackTrace(e));
        }
        
        return coreValidity;

Проблемы. Хэш не совпадает

Смэв фмс

Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Из него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.

Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как

ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП

<ds:DigestValue>e76oVeYGapFDE+PV6glsj0XDjLHydLMd0cSkFPY8fWk=</ds:DigestValue>

не совпадал с оригинальным примером:

<ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo==</ds:DigestValue>

Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLEventWriter bdst =
outputFactory.get().createXMLEventWriter(baos, ENCODING_UTF_8); 

для параллельного анализа всех этапов трансформации.

Нормализованный элемент XML, на который требуется поставить подпись, выглядел следующим образом:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns4:Name>ГИБДД РФ</ns4:Name><ns4:Code>GIBDD</ns4:Code><ns4:OfficialPerson><ns5:FamilyName xmlns:ns5="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns5:FamilyName><ns5:FirstName>Андрей</ns5:FirstName><ns5:Patronymic>Петрович</ns5:Patronymic></ns4:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

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

Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.

Старая версия класса трансформации выдала следующий нормализованный документ:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns5:Name xmlns:ns5="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">ГИБДД РФ</ns5:Name><ns6:Code xmlns:ns6="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">GIBDD</ns6:Code><ns7:OfficialPerson xmlns:ns7="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"><ns8:FamilyName xmlns:ns8="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns8:FamilyName><ns9:FirstName xmlns:ns9="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Андрей</ns9:FirstName><ns10:Patronymic xmlns:ns10="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Петрович</ns10:Patronymic></ns7:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

С ним хэш стал совпадать, а подпись успешно проходить валидацию.

Сравнение версий класса SmevTransformSpi показала, что помимо добавленных в новой реализации дополнительных функций логирования и диагностики в debug режиме:

if (logger.isDebugEnabled()) {
                debugStream = new DebugOutputStream(argDst);
                dst = outputFactory.get().createXMLEventWriter(debugStream, ENCODING_UTF_8);
            } else {
                dst = outputFactory.get().createXMLEventWriter(argDst, ENCODING_UTF_8);
            }

Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:

Смэв фмс

prefixMappingStack.pop();

, которая удаляет первый объект из стека с префиксами

  Stack<List<Namespace>> prefixMappingStack = new Stack<List<Namespace>>();

, что приводило к неверной работе SmevTransformSpi.

Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.

Работающий класс трансформации и конверт с подписью можно посмотреть в github.com/VBurmistrov/Smev3

Результаты

Подписание конвертов СМЭВ 3 выполняется успешно.

Сообщения проходят проверку на портале Электронного правительства Госуслуги

Смэв фмс

И в собственном приложении:

Смэв фмс

<!–

Кристина Холупова

–>

ГИС ФМС будет делиться данными о невыездных россиянах с МВД Белоруссии

МВД заказало доработку системы миграционного учета почти за миллиард рублей. После доработки в систему будут поступать данные о постановке граждан на воинский учет. Также через нее будут отправляться данные о запрете на выезд российских граждан за пределы нашей страны в МВД Белоруссии. Система с новыми опциями должна заработать с конца ноября 2023 г.

Доработка ГИС
миграции

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

Для этих и иных целей МВД объявило тендер на доработку государственной
информационной системы миграционного учета (ГИСМУ). На это из бюджета
выделено 914,6 млн руб. После доработки системы сведения о прохождении военной службы ФМС будет получать от Минобороны.

Система дорабатывается в «соответствии с изменениями законодательства в сфере
миграции», отмечается на портале госзакупок. CNews ожидает ответа от МВД — какие нормативно-правовые акты регулируют предоставления сведений в ФМС о прохождении военной службы.

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

fms.png

Система миграционного учета будет основательно доработана

Тендер на доработку системы был опубликован 21 октября 2022 г. в формате открытого конкурса. Заявки на него принимаются до 7 ноября. Итоги конкурса будут подведены 10 ноября. Заказчиком выступило Научно-производственное объединение «Специальная техника и связь» МВД. Система должна быть доработана до 30 ноября 2023 г.

Данные для МВД
Белоруссии

В ходе проекта также планируется обеспечить взаимодействие ГИСМУ с паспортно-визовым сервисом
МВД, возможность получения и отправки ответов с использованием системы межведомственного
электронного взаимодействия (СМЭВ), получения сведений из единой
госинформсистемы социального обеспечения и т. д.

Артем Пермяков, Directum: HR-специалист становится агентом цифровизации

Смэв фмс

Предусмотрена новая возможность выгрузки из системы данных о российских гражданах,
в отношении которых действуют ограничения на выезд с территории России, для
последующей передачи этих сведений в МВД Белоруссии.

В описании объекта закупки указываются нормативно-правовые
акты, согласно которым вносятся изменения в ГИСМУ. Например, вышеупомянутую
доработку системы регулирует соглашение
между правительствами России и Белоруссии о взаимном признании
виз и по иным вопросам, связанным с въездом иностранных граждан и лиц без
гражданства на территории государств-участников Договора о создании Союзного
государства
от 19 июня 2020 г.

В тендерных документах десятки страниц, посвященных основаниям для изменений в ГИСМУ. Самые свежие нормативно-правовые акты датированы 1 марта 2022 г. Исходя из этого можно предположить, что изменения в миграционном законодательстве не связаны со специальной военной операцией России на Украине.

Взаимодействие с
Минцифры

Помимо прочего, в ГИСМУ после доработки должны
выгружаться/загружаться данные в/из пограничной службы ФСБ посредством
системы «Мир» (ГИС миграционного учета, а также изготовления, оформления и
контроля обращения документов, удостоверяющих личность).

От отдельных инструментов до суперприложений: как развивался российский рынок коммуникационных сервисов

Смэв фмс

Виды выгружаемых сведений определены неким соглашением между МВД,
ФСБ и Минцифры, отмечается в документе. CNews ждет пояснений от МВД и Минцифры по этому вопросу.

Смэв фмс

Skip to content


Информационные технологии для финансового рынка Logo