Сервисная платформа доступа

Изобретение относится к области информационных технологий. Технический результат заключается в создании автоматизированной системы для электронного документооборота. Система выполнена в виде серверного аппаратного комплекса, содержащего облачный виртуальный центр обработки данных (ЦОД), в котором размещена информационная система - сервисная платформа доступа (ИС СПД), выполненная с возможностью электронного взаимодействия по защищенному каналу посредством API, работающего через асинхронный SOAP-сервис, с по меньшей мере одним устройством пользователя и по меньшей мере одним сервером организации, оснащенным сервисом для взаимодействия с системой межведомственного электронного взаимодействия (СМЭВ), при этом ИС СПД выполнена с возможностью поддержки в актуальном формате XSLT шаблонов для преобразования форматов XML-документов из форматов, получаемых от устройства пользователя в запросе, в актуальный на момент осуществления запроса формат XML-документов, заданных в документации по СМЭВ и документации на электронные сервисы/виды сведений СМЭВ. 3 з.п. ф-лы, 4 ил.

 

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

Из уровня техники известная компьютерная система, представляющая собой масштабируемую универсальную архитектуру программного обеспечения для платформы бизнес-компьютеров, которая легко адаптируется к широкому спектру отраслей и бизнес-приложений, особенно для сред, требующих большого объема взаимодействия в режиме реального времени с клиентами и других пользователей по различным каналам связи. Используя интерфейсы на основе расширяемого языка разметки (XML) для обмена данными, общую платформу можно использовать для создания бизнес-приложений для различных вертикальных рынков и различных устройств просмотра информации (компьютерные мониторы, веб-браузеры, плоские файлы данных, электронные таблицы, ручные устройства и тому подобное). Масштабируемая архитектура сосредоточена вокруг новой «платформы обмена сообщениями» для обмена сообщениями между различными компонентами. Другим аспектом изобретения является механизм бизнес-документооборота. В предпочтительном варианте осуществления встроенная система безопасности реализуется внутри адаптеров / соединителей платформы через динамическое открытие / закрытие соединения, таким образом, при котором не каждый компонент может просматривать все сообщения, плавающие в платформе (US 2003097457, 22.05.2003).

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

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

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

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

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

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

Поддержка XSLT шаблонов в актуальном формате осуществляют в ручном режиме.

Облачный виртуальный ЦОД представляет собой удаленный сервер.

Устройство пользователя представляет собой персональный компьютер.

Используемые сокращения:

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

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

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

API - асинхронный SOAP-сервис (Application programming interface), который позволяет унифицировать процесс взаимодействия Потребителей со СМЭВ посредством использования единого формата взаимодействия (далее – формат), заложенного в API. По своей сути является адаптером взаимодействия СПД с внешними системами.

ЭП – электронная подпись.

ИС – информационная система.

СПД - ИС «Сервисная платформа доступа».

Облачный ЦОД – облачный центр обработки данных (облачное хранилище).

XSLT-шаблон - eXtensible Stylesheet Language Transformations— язык преобразования XML-документов по предварительно настроенному алгоритму.

VPN Клиент - программный клиент, посредством которого организовывается защищённый по ГОСТ VPN канал. Данный клиент может быть, например, ViPNet Client от ОАО «ИнфоТеКС», С-Терра Клиент от ООО «С-Терра СиЭсПи» или аналогичные им программные ГОСТ решения.

Криптошлюз – аппаратное решение, посредством которого организовывается защищенный по ГОСТ канал. Данное решение может быть таким, например, как программно-аппаратный шлюз безопасности ViPNet Coordinator от ОАО «ИнфоТеКС», либо С-Терра Шлюз, представляющий собой программный комплекс на аппаратной платформе (программно-аппаратный комплекс, ПАК), предназначенный для обеспечения безопасности сети связи любой топологии от ООО «С-Терра СиЭсПи» или аналогичные им ПАК решения, соответствующие ГОСТ по информационной безопасности.

WEB-интерфейс – Веб-страница или совокупность веб-страниц предоставляющая пользовательский интерфейс для взаимодействия с СПД посредством WSS протокола.

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

Уникальными особенностями взаимодействия Потребителей со СМЭВ через СПД является:

1. Использование универсального протокола передачи данных, работающего через асинхронный SOAP-сервис (Application programming interface, далее - API), который позволяет унифицировать процесс взаимодействия Потребителей со СМЭВ посредством использования единого формата взаимодействия (далее – формат), заложенного в API, вместо использования большого количества форматов, определенных разработчиками электронных сервисов /видов сведений (в СМЭВ зарегистрировано более 900 различных форматов) так как в API реализованы и поддерживаются в актуальном виде XSLT шаблоны (в ручном режиме), с использованием которых происходит преобразование форматов XML-документов из унифицированного формата, передаваемого в API, в разнообразные форматы, определенные разработчиками электронных сервисов /видов сведений СМЭВ.

2. Взаимодействие различных Потребителей со СМЭВ (более 15 000 участников подключено к СМЭВ) через одну систему - СПД, размещенную в облачном виртуальном ЦОД.

Использование вышеуказанных уникальных преимуществ СПД позволит:

1. В части использования уникального протокола взаимодействия СПД API (единого формата взаимодействия) со СМЭВ:

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

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

c. Значительно сократить объем трудозатрат Потребителя на постоянную модернизацию своей информационной системы для взаимодействия со СМЭВ, так как уникальный протокол API СПД покрывает все текущие и будущие форматы взаимодействия с информационными сервисами (электронными сервисами/видами сведений СМЭВ).

2. В части взаимодействия Потребителей с СПД, размещенной в облачном виртуальном ЦОД:

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

b. Увеличить скорость реакции и действий на устранение технических проблем, возникновение которых возможно при работе с СПД, так как при таком взаимодействии реализованы инструменты мониторинга состояния работы вычислительного оборудования (службой эксплуатации облачного виртуального ЦОД) и состоянии работы СПД (администраторами СПД), и разработаны SLA (согласованный уровень качества предоставления услуги) по устранению таких инцидентов в кратчайшие сроки.

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

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

Сущность заявленного изобретения подтверждается чертежами, где на фиг. 1 проиллюстрирована схема взаимодействия Потребителей через API с СПД, размещенной в облачном виртуальным ЦОД, и различными электронными сервисами / видами сведений разработанными Поставщиками и зарегистрированными в СМЭВ, и, в том числе, с различными Поставщиками без использования СМЭВ; на фиг. 2 – проиллюстрирован процесс взаимодействия Потребителей cо СМЭВ через СПД размещенную в облачном виртуальном ЦОД, посредством использования WEB-интерфейса; на фиг. 3 – проиллюстрирован процесс взаимодействия Потребителей cо СМЭВ через СПД размещенную на локальных мощностях Потребителя (во внутреннем периметре), посредством использования универсального сервиса для передачи данных (API); на фиг. 4 – проиллюстрирован процесс взаимодействия Потребителей cо СМЭВ через СПД размещенную на локальных мощностях Потребителя (во внутреннем периметре), посредством использования WEB-интерфейса.

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

В облачном виртуальный ЦОД 10 размещена информационная система СПД 3, которая связана посредством API 2, работающего через асинхронный SOAP-сервис, с устройствами пользователя (персональным компьютером) 1 Потребителя сведений, по защищенному каналу 4 с Поставщиком 7 (персональными компьютерами, серверами Поставщиков) напрямую 8 или по защищенному каналу 4 через сервис СМЭВ 5 с электронными сервисами/видами сведений СМЭВ 7 (нумерация соответствует Фиг.1).

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

Таким образом запрос поступивший через API в СПД, размещенную в облачном ЦОД, преобразовывается из формата XML-документа Потребителя сведений в формат XML-документа, заданный Поставщиками (разработчиками электронных сервисов/видов сведений) СМЭВ, посредством использования предварительно настроенного XSLT-шаблона (алгоритма преобразования документов, который настраивается и поддерживается в актуальном состоянии администратором СПД, вручную, в соответствии с форматами XML-документов, указанных в руководстве пользователя на любой конкретный электронный сервиса/вид сведений СМЭВ, а также соответствует требованиям актуальной версии Методических рекомендаций по работе со СМЭВ).

API является адаптером взаимодействия СПД с внешними системами (серверами, персональными компьютерами), и входит в состав компонентов СПД, размещенной в облачном ЦОД. Соответственно API принимает запросы Потребителей сведений по унифицированном формату XML-документов и передает их на обработку в СПД, либо передает ответ из СПД в информационные системы Потребителей сведений.

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

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

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

Ниже приведены варианты возможных сценариев взаимодействия Потребителя сведений с СПД и СМЭВ.

На фиг. 1 проиллюстрирована схема взаимодействия Потребителей сведений через API с СПД, размещенной в облачном виртуальным ЦОД, и различными электронными сервисами/видами сведений, разработанными Поставщиками и зарегистрированными в СМЭВ, которая состоит из следующих этапов:

1. Потребитель сведений через свою ИС формирует запрос в формате XML, заданном в API.

2. Сформированный Потребителем запрос направляется в виде XML-документа по SOAP-протоколу через защищенный по ГОСТ VPN канал (посредством использования VPN Клиента или Критошлюза) на Криптошлюз, размещенный на принимающей сообщение стороне в облачном виртуальном ЦОД.

3. Запрос, поступает по защищенному каналу от Потребителя в облачный виртуальный ЦОД на Криптошлюз, на нем расшифровывается и маршрутизируется через API в СПД. При этом API, принимая запрос, идентифицирует Потребителя СПД по определенному признаку, затем запрос проходит первичную обработку и ему присваивается уникальный внутренний идентификационный номер в СПД, далее событие аудита СПД через брокер сообщений Rabbit MQ передается в подсистему аудита, в которой обрабатывается, и параллельно передается в базу данных PostgreSQL, а также через брокер сообщений Rabbit MQ направляется в подсистему преобразования сообщений, где сообщение конвертируется в актуальный XML формат взаимодействия в СМЭВ и через брокер сообщений Rabbit MQ передается в подсистему взаимодействия со СМЭВ, затем через подсистему работы с ЭП подписывается ЭП и передается на Криптошлюз, установленный в облачном виртуальном ЦОД, который шифрует запрос по ГОСТ.

4. Зашифрованный по ГОСТ запрос передается на Криптошлюз, установленный в СМЭВ.

5. СМЭВ через Криптошлюз расшифровывает полученный запрос от СПД и принимает его в обработку. Затем СМЭВ проверяет запрос, полученный от СПД, на его соответствие действующим требованиям и форматам взаимодействия, указанным в документации по работе со СМЭВ и руководстве пользователя на определенный электронный сервис/вид сведений. После завершения всех необходимых проверок в СМЭВ запрос маршрутизируется на Криптошлюз, который зашифровывает трафик по ГОСТ.

6. Зашифрованный по ГОСТ запрос передается на Криптошлюз Поставщика (для его последующей передачи на определенный электронный сервис или в определенную очередь сообщений по конкретному виду сведений СМЭВ).

7. ИС Поставщика принимает со своего Криптошлюза расшифрованный трафик из СМЭВ от СПД с запросом сведений и производит необходимую обработку запроса, затем ИС Поставщика формирует ответ в XML формате, подписывает его своей ЭП и передает его на свой Криптошлюз для его шифрования по ГОСТ, с последующей передачей на Криптошлюз СМЭВ, для его последующей расшифровки и обработки на принимающей стороне. Далее ответ в обратном порядке проходит шаги с 6 по 1 и попадает в ИС Потребителя.

8. Так как СПД позволяет взаимодействовать с Поставщиками не только через СМЭВ, но и напрямую, то сформированный в XML-формате запрос может быть также передан напрямую определенному Поставщику.

9. Поставщик обрабатывает запрос, готовит ответ и подписывает его своей ЭП. Далее ответ проходит шаги 8, 3, 2, 1 и попадает в ИС Потребителя.

На фиг. 2 проиллюстрирована схема взаимодействия Потребителей сведений через WEB-интерфейс с СПД, размещенной в облачном виртуальным ЦОД, и различными электронными сервисами/видами сведений, разработанными Поставщиками и зарегистрированными в СМЭВ, которая состоит из следующих этапов:

1. Потребитель сведений через защищенный по ГОСТ VPN канал (посредством использования VPN Клиента или Криптошлюза) по WSS-протоколу заходит в личный кабинет WEB-интерфейса СПД и формирует запрос.

2. Сформированный Потребителем запрос направляется в виде XML-документа в СПД.

3. Сформированному через WEB-интерфейс запросу присваивается внутренний номер запроса, далее через брокер сообщений Rabbit MQ событие аудита СПД передается в подсистему аудита, в которой обрабатывается, и параллельно передается в базу данных PostgreSQL, а также запрос, через брокер сообщений Rabbit MQ, направляется в подсистему преобразования сообщений, где сообщение конвертируется в актуальный формат взаимодействия в СМЭВ и через брокер сообщений Rabbit MQ передается в подсистему взаимодействия со СМЭВ, затем через подсистему работы с ЭП подписывается ЭП и передается на Криптошлюз, установленный в облачном виртуальном ЦОД, который шифрует трафик по ГОСТ.

4. Зашифрованный по ГОСТ запрос передается на Криптошлюз, установленный в СМЭВ.

5. СМЭВ через Криптошлюз расшифровывает полученный запрос от СПД и принимает его в обработку. Затем СМЭВ проверяет запрос, полученный от СПД, на его соответствие действующим требованиям и форматам взаимодействия, указанным в документации по работе со СМЭВ и руководстве пользователя на определенный электронный сервис/вид сведений. После завершения всех необходимых проверок в СМЭВ запрос маршрутизируется на Криптошлюз, который зашифровывает трафик по ГОСТ.

6. Зашифрованный по ГОСТ запрос передается на Криптошлюз Поставщика (для его последующей передачи на определенный электронный сервис или в определенную очередь сообщений по конкретному виду сведений СМЭВ).

7. ИС Поставщика принимает со своего Криптошлюза расшифрованный трафик из СМЭВ от СПД с запросом сведений и производит необходимую обработку запроса, затем ИС Поставщика формирует ответ в XML формате, подписывает его своей ЭП и передает его на свой Криптошлюз для его шифрования по ГОСТ, с последующей передачей на Криптошлюз СМЭВ, для его последующей расшифровки и обработки на принимающей стороне. Далее ответ в обратном порядке проходит шаги с 6 по 1 и попадает в WEB-интерфейс Потребителя.

8. Так как СПД позволяет взаимодействовать с Поставщиками не только через СМЭВ, но и напрямую, то сформированный в XML-формате запрос может быть также передан напрямую определенному Поставщику.

9. Поставщик обрабатывает запрос, готовит ответ и подписывает его своей ЭП. Далее ответ проходит шаги 8, 3, 2, 1 и попадает в личный кабинет в WEB-интерфейсе Потребителя.

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

1. Потребитель сведений через свою ИС формирует запрос в формате XML, заданном в API.

2. Сформированный Потребителем запрос направляется в виде XML-документа по SOAP-протоколу через API в СПД.

3. Запрос поступает через API в СПД. При этом API, принимая запрос, идентифицирует Потребителя СПД по определенному признаку, затем запрос проходит первичную обработку и ему присваивается уникальный внутренний идентификационный номер в СПД, далее событие аудита СПД через брокер сообщений Rabbit MQ передается в подсистему аудита, в которой обрабатывается, и параллельно передается в базу данных PostgreSQL, а также через брокер сообщений Rabbit MQ направляется в подсистему преобразования сообщений, где сообщение конвертируется в актуальный XML формат взаимодействия в СМЭВ и через брокер сообщений Rabbit MQ передается в подсистему взаимодействия со СМЭВ, затем через подсистему работы с ЭП подписывается ЭП и передается на Критошлюз, установленный во внутреннем периметре Потребителя, который шифрует запрос по ГОСТ.

4. Зашифрованный по ГОСТ запрос передается на Криптошлюз, установленный в СМЭВ.

5. СМЭВ через Криптошлюз расшифровывает полученный запрос от СПД и принимает его в обработку. Затем СМЭВ проверяет запрос, полученный от СПД, на его соответствие действующим требованиям и форматам взаимодействия, указанным в документации по работе со СМЭВ и руководстве пользователя на определенный электронный сервис/вид сведений. После завершения всех необходимых проверок в СМЭВ запрос маршрутизируется на Криптошлюз, который зашифровывает трафик по ГОСТ.

6. Зашифрованный по ГОСТ запрос передается на Криптошлюз Поставщика (для его последующей передачи на определенный электронный сервис или в определенную очередь сообщений по конкретному виду сведений СМЭВ).

7. ИС Поставщика принимает со своего Криптошлюза расшифрованный трафик из СМЭВ от СПД с запросом сведений и производит необходимую обработку запроса, затем ИС Поставщика формирует ответ в XML формате, подписывает его своей ЭП и передает его на свой Криптошлюз для его шифрования по ГОСТ, с последующей передачей на Криптошлюз СМЭВ, для его последующей расшифровки и обработки на принимающей стороне. Далее ответ в обратном порядке проходит шаги с 6 по 1 и попадает в ИС Потребителя.

8. Так как СПД позволяет взаимодействовать с Поставщиками не только через СМЭВ, но и напрямую, то сформированный в XML-формате запрос может быть также передан напрямую определенному Поставщику.

9. Поставщик обрабатывает запрос, готовит ответ и подписывает его своей ЭП. Далее ответ проходит шаги 8, 3, 2, 1 и попадает в ИС Потребителя.

На фиг. 4 проиллюстрирована схема взаимодействия Потребителей сведений через WEB-интерфейс с СПД, размещенной на локальных мощностях Потребителя (во внутреннем периметре), и различными электронными сервисами/видами сведений, разработанными Поставщиками и зарегистрированными в СМЭВ, которая состоит из следующих этапов:

1. Потребитель сведений по WSS-протоколу заходит в личный кабинет WEB-интерфейса СПД и формирует запрос.

2. Сформированный Потребителем запрос направляется в виде XML-документа в СПД.

3. Сформированному через WEB-интерфейс запросу присваивается внутренний номер запроса, далее через брокер сообщений Rabbit MQ событие аудита СПД передается в подсистему аудита, в которой обрабатывается, и параллельно передается в базу данных PostgreSQL, а также запрос, через брокер сообщений Rabbit MQ, направляется в подсистему преобразования сообщений, где сообщение конвертируется в актуальный формат взаимодействия в СМЭВ и через брокер сообщений Rabbit MQ передается в подсистему взаимодействия со СМЭВ, затем через подсистему работы с ЭП подписывается ЭП и передается на Криптошлюз, установленный во внутреннем периметре Потребителя, который шифрует трафик по ГОСТ.

4. Зашифрованный по ГОСТ запрос передается на Криптошлюз, установленный в СМЭВ.

5. СМЭВ через Криптошлюз расшифровывает полученный запрос от СПД и принимает его в обработку. Затем СМЭВ проверяет запрос, полученный от СПД, на его соответствие действующим требованиям и форматам взаимодействия, указанным в документации по работе со СМЭВ и руководстве пользователя на определенный электронный сервис/вид сведений. После завершения всех необходимых проверок в СМЭВ запрос маршрутизируется на Криптошлюз, который зашифровывает трафик по ГОСТ.

6. Зашифрованный по ГОСТ запрос передается на Криптошлюз Поставщика (для его последующей передачи на определенный электронный сервис или в определенную очередь сообщений по конкретному виду сведений СМЭВ).

7. ИС Поставщика принимает со своего Криптошлюза расшифрованный трафик из СМЭВ от СПД с запросом сведений и производит необходимую обработку запроса, затем ИС Поставщика формирует ответ в XML формате, подписывает его своей ЭП и передает его на свой Криптошлюз для его шифрования по ГОСТ, с последующей передачей на Криптошлюз СМЭВ, для его последующей расшифровки и обработки на принимающей стороне. Далее ответ в обратном порядке проходит шаги с 6 по 1 и попадает в WEB-интерфейс Потребителя.

8. Так как СПД позволяет взаимодействовать с Поставщиками не только через СМЭВ, но и напрямую, то сформированный в XML-формате запрос может быть также передан напрямую определенному Поставщику.

9. Поставщик обрабатывает запрос, готовит ответ и подписывает его своей ЭП. Далее ответ проходит шаги 8, 3, 2, 1 и попадает в личный кабинет в WEB-интерфейсе Потребителя.

Преимуществами заявленного изобретения является:

1. Использование универсального протокола передачи данных, работающего через асинхронный SOAP-сервис (Application programming interface, далее - API), который позволяет унифицировать процесс взаимодействия Потребителей со СМЭВ посредством использования единого формата взаимодействия (далее – формат), заложенного в API, вместо использования большого количества форматов, определенных разработчиками электронных сервисов /видов сведений (в СМЭВ зарегистрировано более 900 различных форматов) так как в API реализованы и поддерживаются в актуальном виде XSLT шаблоны (в ручном режиме), с использованием которых происходит преобразование форматов XML-документов из унифицированного формата в API в разнообразные форматы, определенные разработчиками электронных сервисов /видов сведений СМЭВ.

2. Взаимодействие различных Потребителей со СМЭВ (более 15 000 участников подключено к СМЭВ) через одну систему - СПД, размещенную в облачном виртуальном ЦОД.

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

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

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

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

3. Автоматизированная система для электронного документооборота по п. 1, характеризующаяся тем, что облачный виртуальный ЦОД представляет собой удаленный сервер.

4. Автоматизированная система для электронного документооборота по п. 1, характеризующаяся тем, что устройство пользователя представляет собой персональный компьютер, выполненный с возможностью взаимодействия с информационной системой СПД через WEB-интерфейс посредством WSS протокола из личного кабинета и/или через единый протокол API.