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

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

Info

Publication number
RU2703150C1
RU2703150C1 RU2018132771A RU2018132771A RU2703150C1 RU 2703150 C1 RU2703150 C1 RU 2703150C1 RU 2018132771 A RU2018132771 A RU 2018132771A RU 2018132771 A RU2018132771 A RU 2018132771A RU 2703150 C1 RU2703150 C1 RU 2703150C1
Authority
RU
Russia
Prior art keywords
smev
interaction
information
request
electronic
Prior art date
Application number
RU2018132771A
Other languages
English (en)
Inventor
Артур Гагикович Хримян
Original Assignee
Общество с ограниченной ответственностью "А3"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Общество с ограниченной ответственностью "А3" filed Critical Общество с ограниченной ответственностью "А3"
Priority to RU2018132771A priority Critical patent/RU2703150C1/ru
Application granted granted Critical
Publication of RU2703150C1 publication Critical patent/RU2703150C1/ru

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84Mapping; Conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

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

Description

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

Claims (6)

1. Автоматизированная система для электронного документооборота, выполненная в виде серверного аппаратного комплекса, характеризующаяся тем, что серверный аппаратный комплекс содержит
облачный виртуальный центр обработки данных (ЦОД), в котором размещена информационная система - сервисная платформа доступа (СПД), выполненная с возможностью присвоения уникального внутреннего идентификационного номера запросу и электронного взаимодействия по защищенному каналу связи с использованием средств криптографической защиты информации по единому протоколу API, унифицирующему процесс взаимодействия с системой межведомственного электронного взаимодействия (СМЭВ) посредством использования единого формата взаимодействия, заложенного в API, представляющий собой адаптер взаимодействия СПД с внешними системами, и работающего через асинхронный SOAP-сервис, с по меньшей мере одним устройством пользователя и по меньшей мере одним сервером организации, оснащенным сервисом для взаимодействия со СМЭВ,
при этом информационная система СПД выполнена с возможностью поддержки в актуальном формате XSLT шаблонов для преобразования через заранее созданный для каждого конкретного вида запросов XSLT шаблон форматов XML-документов из форматов, получаемых от устройства пользователя в запросе, в актуальный на момент осуществления запроса формат XML-документов, заданных в документации по СМЭВ и документации на электронные сервисы/виды сведений СМЭВ.
2. Автоматизированная система для электронного документооборота по п. 1, характеризующаяся тем, что шаблоны XSLT поддерживаются администратором информационной системы - сервисной платформы доступа - в актуальном формате в ручном режиме.
3. Автоматизированная система для электронного документооборота по п. 1, характеризующаяся тем, что облачный виртуальный ЦОД представляет собой удаленный сервер.
4. Автоматизированная система для электронного документооборота по п. 1, характеризующаяся тем, что устройство пользователя представляет собой персональный компьютер, выполненный с возможностью взаимодействия с информационной системой СПД через WEB-интерфейс посредством WSS протокола из личного кабинета и/или через единый протокол API.
RU2018132771A 2018-09-14 2018-09-14 Сервисная платформа доступа RU2703150C1 (ru)

Priority Applications (1)

Application Number Priority Date Filing Date Title
RU2018132771A RU2703150C1 (ru) 2018-09-14 2018-09-14 Сервисная платформа доступа

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
RU2018132771A RU2703150C1 (ru) 2018-09-14 2018-09-14 Сервисная платформа доступа

Publications (1)

Publication Number Publication Date
RU2703150C1 true RU2703150C1 (ru) 2019-10-15

Family

ID=68280042

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2018132771A RU2703150C1 (ru) 2018-09-14 2018-09-14 Сервисная платформа доступа

Country Status (1)

Country Link
RU (1) RU2703150C1 (ru)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060277248A1 (en) * 2005-05-12 2006-12-07 Baxter Eugene E Configuration-based application architecture using XML/XSLT
WO2014049470A1 (en) * 2012-09-25 2014-04-03 Koninklijke Philips N.V. System and method for processing variant call data
US20140189500A1 (en) * 2000-04-24 2014-07-03 Tvworks, Llc Method and System for Transforming Content for Execution on Multiple Platforms
US20170103113A1 (en) * 2015-10-09 2017-04-13 Bank Of America Corporation System for inline message detail extraction and transformation
RU2635269C1 (ru) * 2016-02-02 2017-11-09 Алексей Геннадьевич Радайкин Комплекс аппаратно-программных средств, создающий защищенную облачную среду с автономной полнофункциональной инфраструктурой логического управления с биометрико-нейросетевой идентификацией пользователей и с аудитом подключаемых технических средств

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140189500A1 (en) * 2000-04-24 2014-07-03 Tvworks, Llc Method and System for Transforming Content for Execution on Multiple Platforms
US20060277248A1 (en) * 2005-05-12 2006-12-07 Baxter Eugene E Configuration-based application architecture using XML/XSLT
WO2014049470A1 (en) * 2012-09-25 2014-04-03 Koninklijke Philips N.V. System and method for processing variant call data
US20170103113A1 (en) * 2015-10-09 2017-04-13 Bank Of America Corporation System for inline message detail extraction and transformation
RU2635269C1 (ru) * 2016-02-02 2017-11-09 Алексей Геннадьевич Радайкин Комплекс аппаратно-программных средств, создающий защищенную облачную среду с автономной полнофункциональной инфраструктурой логического управления с биометрико-нейросетевой идентификацией пользователей и с аудитом подключаемых технических средств

Similar Documents

Publication Publication Date Title
US11546167B2 (en) System and method for using a distributed ledger gateway
US20150381580A1 (en) System and method to use a cloud-based platform supported by an api to authenticate remote users and to provide pki- and pmi- based distributed locking of content and distributed unlocking of protected content
CN113228011A (zh) 数据共享
CN103842958A (zh) 支持系统中的安全通信的实施
EP2354996B1 (en) Apparatus and method for remote processing while securing classified data
US8291214B2 (en) Apparatus and method for secure remote processing
CN105516157A (zh) 基于独立加密的网络信息安全输入系统和方法
CN110648241B (zh) 一种基于微服务架构的理赔处理方法及装置
Lo et al. An attribute-role based access control mechanism for multi-tenancy cloud environment
KR101418373B1 (ko) 클라우드 환경 기반 가상 휴대 단말 제공 장치
US8640185B2 (en) Personal-information managing apparatus and personal-information handling apparatus
Adkinson-Orellana et al. Privacy for google docs: Implementing a transparent encryption layer
CN112491955B (zh) 一种基于代理服务器实现iframe系统数据交换的方法和系统
RU2703150C1 (ru) Сервисная платформа доступа
CN113706299B (zh) 数据处理的方法、装置、电子设备及介质
CN105208044A (zh) 一种适用于云计算的密钥管理方法
CN110691060A (zh) 一种基于csp接口实现远端设备密码服务的方法和系统
CN111698192B (zh) 监控交易系统的方法、交易设备、监管设备及系统
CN113343273A (zh) 一种用户登陆方法、第一服务器及计算机可读存储介质
Inshi et al. LCA-ABE: Lightweight context-aware encryption for android applications
CN112948860B (zh) 数据处理方法、相关节点及介质
EP4322470A1 (en) Data encryption system and method
CN112738008B (zh) 信息同步变更方法、装置、计算机以及可读存储介质
CN113472785B (zh) 数据处理方法、装置、电子设备及可读存储介质
US20240103939A1 (en) System And Method for Implementing Micro-Application Environments

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20200915