АВТОМАТИЗИРОВАННАЯ СИСТЕМА ЭЛЕКТРОННОЙ ПОДПИСИ ДОКУМЕНТОВ

Полезная модель относится к устройствам обработки данных для специального применения и может быть использована в структуре электронного документооборота заказчик-исполнитель, в частности при реализации документооборота в области рекламы.
Используемые в описании термины и сокращения:
1) Электронный документ (ЭД) - документ, в котором информация представлена в электронно-цифровой форме.
2) Электронный документооборот (ЭДО) - это способ организации работы с документами, при котором основная масса документов используется в электронном виде и хранится централизованно.
3) Система электронного документооборота (СЭД) - система с программным обеспечением, которая позволяет организовать работу с электронными документами (создание, изменение, поиск), а также взаимодействие между сотрудниками (передачу документов, выдачу заданий, отправку уведомлений и т.п.).
4) Электронная цифровая подпись или электронная подпись (ЭП) - реквизит электронного документа, защищенный от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи, позволяющий установить отсутствие утраты, искажения или подделки содержащейся в электронном документе информации, а также обладателя электронной цифровой подписи.
5) Обладатель электронной цифровой подписи - лицо, на имя которого зарегистрирована электронная цифровая подпись и которое обладает соответствующим закрытым ключом электронной цифровой подписи, позволяющим с помощью средств электронной цифровой подписи создавать свою электронную цифровую подпись в электронных документах (подписывать электронные документы).
6) Закрытый ключ электронной цифровой подписи - уникальная последовательность символов, известная обладателю электронной цифровой подписи и предназначенная для создания им в электронных документах электронной цифровой подписи с использованием средств электронной цифровой подписи.
7) Открытый ключ электронной цифровой подписи - уникальная последовательность символов, доступная любому пользователю информационной системы, предназначенная для подтверждения с использованием средств электронной цифровой подписи подлинности электронной цифровой подписи в электронном документе.
8) Сертификат ключа подписи - документ на бумажном носителе или электронный документ с электронной цифровой подписью уполномоченного лица удостоверяющего центра, идентифицирующий обладателя электронной цифровой подписи, включающий открытый ключ электронной цифровой подписи и выдаваемый удостоверяющим центром пользователю информационной системы для обеспечения возможности подтверждения подлинности электронной цифровой подписи.
9) Удостоверяющий центр (УЦ) (сервер, который осуществляет управление сертификатами) - подразделение, обеспечивающее взаимное доверие между участниками обмена электронными сообщениями, подписанными электронной цифровой подписью. УЦ гарантирует подлинность документов при обмене между участниками ЭДО и хранит у себя электронные подписи документов, ставит на документ штамп времени.
10) Визирование - процесс согласования документа внутри компании.
11) HTTP (англ. HyperText Transfer Protocol - «протокол передачи гипертекста»)
- протокол прикладного уровня передачи данных в первую очередь в виде текстовых сообщений. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщики (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.
12) Метод HTTP (англ. HTTP Method) - последовательность из любых символов кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово записанное заглавными буквами. Название метода чувствительно к регистру. Каждый сервер обязан поддерживать как минимум методы GET и HEAD.
13) Подписант - пользователь, обладающий правом и возможностью подписывать документы.
14) ЮЛ - название юридического лица контрагента.
15) КриптоПро - криптопровайдер используется во многих программах российских разработчиков для генерации электронной подписи (ЭП), работы с сертификатами, создания структуры PKI.
16) Криптопровайдер (Cryptography Service Provider, CSP) - это независимый модуль, позволяющий осуществлять криптографические операции в операционных системах Microsoft, управление которым происходит с помощью функций CryptoAPI.
17) PKI - Public Key Infrastructure, набор технических средств, распределенных служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей.
18) PH - рекламоноситель (например, телеканал, радиостанция, интернет сайт).
19) Толстый клиент или Rich-клиент в архитектуре клиент-сервер - это приложение, обеспечивающее (в противовес «тонкому клиенту») расширенную функциональность независимо от центрального сервера. Часто сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента. Толстый клиент обладает широким функционалом.
Уровень техники.
Известны алгоритмы электронной цифровой подписи (ЭЦП), позволяющие подписывать электронные документы электронной цифровой подписью с помощью секретных ключей пользователей и проверять подлинность электронных цифровых подписей по открытым ключам. Принадлежность открытого ключа конкретному пользователю удостоверяется с помощью цифровой подписи доверительного центра в виде цифрового сертификата. Для каждого пользователя генерируется пара уникальных ключей - секретный и открытый ключи электронной цифровой подписи. Свой секретный ключ пользователь должен хранить в тайне и использовать его при подписании электронного документа.
Общим недостатком электронной цифровой подписи является необходимость надежного хранения своего секретного ключа на носителе (запомнить ключ практически невозможно вследствие его большого размера) и самого носителя, и необходимость запоминать к нему пароль. Кроме того, существует проблема совместимости различных алгоритмов, программных продуктов и аппаратных средств для электронной цифровой подписи, что является серьезным ограничением для широкого применения ЭЦП. Не менее серьезной проблемой является психологический барьер для перехода к технологиям безбумажного документооборота с применением ЭЦП.
Из патентной литературы известен способ подписания документов электронной аналого-цифровой подписью и устройство для его реализации по патенту РФ 2287223 (МПК H04L 9/32, опубл. 10.11.2006). Данное решение позволяет создавать подписываемые пользователями электронные документы без предварительного генерирования личных электронных цифровых подписей пользователей. Идентификация пользователя, подписавшего такой электронный документ, осуществляется по биометрическим данным пользователя, которые становятся неотъемлемой частью только данного электронного документа и которые невозможно вставить в другой электронный документ. Это дает возможность любой организации, постоянно работающей с населением, имея хотя бы одно такое устройство переводить первичные документы (такие как квитанции, чеки, ордера, счета и пр.) в электронный вид и хранить данные документы в электронной базе данных. При этом пользователь может получить копию документа, как в бумажном, так и в электронном виде. Достоверность полученного электронного документа, подписанного электронной аналого-цифровой подписью, проверяют в два этапа. Сначала проверяют электронную цифровую подпись при помощи открытого ключа, являющегося парой секретному ключу, хранящемуся в памяти устройства для подписи. Затем проверяют принадлежность биометрических данных, содержащихся в электронном документе, конкретному пользователю, подписавшему данный документ.
Это техническое решение не исключает того, что данная процедура должна осуществляться в доверительном центре, где предварительно должна быть проверена целостность защитного корпуса. Доверительный центр сертифицирует полученный открытый ключ своей электронной цифровой подписью, подтверждающей принадлежность открытого ключа данному устройству для подписи документов.
Недостатком данного технического решения является недостаточная надежность датчиков вскрытия защитного корпуса в зоне устройства ввода биометрических данных пользователей, что потенциально позволяет злоумышленнику получить доступ к шине данных, соединяющей устройство ввода биометрических данных с микропроцессором. Это позволило бы злоумышленнику подать в устройство для подписи аналого-цифровую информацию о пользователе без его ведома напрямую через шину данных. Кроме того, в данной системе, при использовании в качестве аналоговой составляющей автографической подписи пользователя, предполагается применение дополнительного биометрического устройства для ввода рукописной информации, что приводит к удорожанию и увеличению размера устройства для подписи.
В связи с этими недостатками указанное техническое решение пока не нашло практического применения.
Тем не менее, из уровня техники известны практически реализованные системы обмена электронными юридическими значимыми документами между контрагентами, например система «Такском Файлер»: http://filer.taxcom.ru/about/info/. Данная система разработана одним из крупнейшим в России УЦ - компанией TAXCOM, http://www.taxcom.ru/. Данная система позволяет загружать различные электронные документы через веб интерфейс (личный кабинет участника процесса) и передавать их в УЦ Такском для регистрации подписи. Обработанные документы УЦ видны в личном кабинете «Такском Файлер» участникам процесса ЭДО.
Схема работы с системой «Такском Файлер» представлена на фиг. 2
1. Пользователь в «Такском Файлер» выбирает ЮЛ и осуществляет вход в систему (вводит логин и пароль), под соответствующим ЮЛ.
2. Осуществляет вручную загрузку документов в систему
3. Вручную выбирает необходимые документы и подписывает их (нажимает кнопку «Подписать»)
4. Система Криптопро к каждому документу генерирует электронную подпись, на основе заданного в настройках сертификата подписи.
5. Подписанный документ и подпись к нему автоматически формируется в контейнер и отправляется в УЦ
6. УЦ обрабатывает (формирует квитанции, проставляет штамп времени) документ и отправляет сведения обратно в систему
7. В системе находится подписанный документ.
Недостатками данной системы являются:
- Нет возможности работать с другими УЦ. Работа может осуществляться только с УЦ Такском.
- Система не обладает функционалом визирования документов, таким образом, процесс согласования (визирование) документов осуществляется вне системы. На фиг. 2 представлено в блоке «Процесс согласования документов». Отсутствие данного функционала не позволяет контролировать корректность данных в документах. В организациях, в которых учет документов осуществляется по утвержденному жизненному циклу (к примеру, счета, поступающие на оплату обязательно должны быть проверены с фиксацией соответствующего статуса менеджером и бухгалтером и только после оплачены) для выполнения подобной задачи необходимо параллельно с данной системой вести каталог документов, отражать в них статусы прохождения проверки документа. При значительном потоке документов данная задача становится затратной и подверженной большому количеству ошибок.
- Отсутствие системы прав. Нет возможности для каждого пользователя настроить определенный набор документов по заранее заданным критериям. Например, пользователь 1 подписывает только счета, пользователь 2 подписывает только гарантийные письма и акты, а пользователь 3 все типы документов. Более сложные настройки прав, например, пользователь 1 подписывает счета контрагентов 1, 2, 3, 4, 5, а пользователь 2, счета контаргентов 6, 7, 8, 9, 10, также отсутствуют.
- Конфиденциальность и безопасность. Из-за отсутствия системы прав, которая позволяет гибко настраивать видимость и подпись документов пользователи видят и имеют возможность подписывать документы, не относящиеся к их деятельности.
- Отсутствует возможность в одном информационном окне подписывать документы от нескольких ЮЛ. Для этого пользователю необходимо использовать столько информационных окон Такском Файлера, от скольких ЮЛ он собирается подписывать документы. На фиг. 2 представлено блоком «Выбор ЮЛ, вход под соответствующим логином».
- Затратоемкость процессов. Каждый документ в систему загружается индивидуально, нет массовой загрузки. На фиг. 2 представлено блоком «Загрузка документа в систему».
- Ограниченное кол-во фильтров: тип документа, ЮЛ, дата, от, не позволяющих осуществлять гибкую сортировку массива документов, что при больших объемах документов может вызвать увеличение временных ресурсов на обработку и подпись документов.
- Отсутствие почтовых оповещение и напоминаний о необходимости обработки документов. Таким образом, пользователю, осуществляющему подпись, в системе необходимо осуществлять постоянный мониторинг документов, назначенных ему на подпись.
Другим аналогом является система «Контур Диадок» (http://www.diadoc.ru/possibilities), разработанная УЦ СКБ Контур.
Схема работы с системой «Контур Диадок» представлена на фиг. 3
1. Пользователь в «Контур Диадок» выбирает ЮЛ и осуществляет ход в систему (вводит логин и пароль), под соответствующим ЮЛ.
2. Осуществляет вручную загрузку документов в систему.
3. Вручную выбирает необходимые документы и при необходимости отправляет на согласование (визирование).
4. После визирования документ подписывается (нажимает кнопку «Подписать»).
5. Система Криптопро к каждому документу генерирует электронную подпись, на основе заданного в настройках сертификата подписи.
6. Подписанный документ и подпись к нему автоматически формируется в контейнер и отправляется в УЦ
7. УЦ обрабатывает (формирует квитанции, проставляет штамп времени) документ и отправляет сведения обратно в систему.
8. В системе находится подписанный документ.
Недостатками данной системы являются:
- Нет возможности работать с другими УЦ. Работа может осуществляться только с УЦ СКБ Контур.
- Простая модель визирования. На фиг. 3 представлено в блоке «Процесс согласования документов». Система не обладает функционалом, позволяющим настраивать процесс визирования документов по индивидуальному графу каждого контрагента и каждого типа документа, что наиболее характерно для процесса обработки и подготовки рекламных материалов для отправки на РН. Нет возможности настроить последовательность визирования. Нет возможности визировать документы стороной получателя (например, Контрагентом 2) после подписи Контрагентом 1. Нет возможности визировать документы одновременно несколькими пользователями.
- Упрощенная система прав. Нет возможности для каждого пользователя настроить определенный набор документов по заранее заданным критериям. Например, пользователь 1 подписывает только счета, пользователь 2 подписывает гарантийные письма и акты, а пользователь 3 все типы документов. Более сложные настройки прав, например пользователь 1 подписывает счета контрагентов 1, 2, 3, 4, 5, а пользователь 2, счета контрагентов 6, 7, 8, 9, 10 также отсутствуют.
- Конфиденциальность и безопасность. Из-за отсутствия системы прав, которая позволяет гибко настраивать видимость и подпись документов пользователи видят и имеют возможность подписывать документы, не относящиеся к их деятельности.
- Отсутствует возможность в одном информационном окне подписывать документы от нескольких ЮЛ, в частности, нескольких рекламодателей. Для этого пользователю необходимо использовать столько информационных окон «Контур Диадок», от скольких ЮЛ он собирается подписывать документы. На фиг. 3 представлено блоком ”Выбор ЮЛ, вход под соответствующим логином”.
- Ограниченное кол-во фильтров: тип документа, ЮЛ, статус, дата от, не позволяющих осуществлять гибкую сортировку массива документов, что при больших объемах документов может вызвать увеличение временных ресурсов на обработку и подпись документов.
- Отсутствие почтовых оповещение и напоминаний о необходимости обработки документов. Таким образом, подписанту в системе, необходимо осуществлять постоянный мониторинг документов, назначенных ему на подпись.
Общей слабостью упомянутых выше технических решений является недостаток функциональных возможностей системы электронной подписи документов в случае их обработки многими субъектами и необходимости взаимного согласования процесса движения документа до выдачи окончательного варианта документа, что не позволяет использовать эти системы для обработки рекламных материалов перед отправкой в РН. Предлагаемая модель является полностью автоматизированной системой, предназначенной для контроля за согласованием и подписью электронных документов, в частности, рекламных материалов. Уникальной особенностью предлагаемой автоматизированной системы является возможность работать с любым УЦ, предоставляющим API для взаимодействия с ним.
Преимущества предлагаемой автоматизированной системы по сравнению с аналогами: «Такском Файлер», а также «Контур Диадок», которая принимается в качестве прототипа, заключаются в следующем:
- Возможность работать с любым УЦ предоставляющим API для внешней интеграции, благодаря конструктору запросов, который позволяет, используя интерфейс системы настраивать интеграцию с любым УЦ.
- Возможность интегрировать систему с любой системой электронного документооборота через обмен файлами в xml формате. Таким образом, процесс получения документов в предлагаемую систему может быть полностью автоматизированным, а в случаем необходимости может быть настроен обратный поток контейнеров электронных документов в систему электронного документооборота.
- Массовая загрузка документов (электронных файлов) в систему без интеграции с внешними системами документооборота, что дает системе полностью автономную работу по процессу электронного обмена и электронной подписи документов между контрагентами.
- Возможность визировать документы по заданным критериям для каждого типа документа, пользователя и контрагента. Таким образом, возникает процесс контроля документов по заранее заданному жизненному циклу, сокращаются потенциальные ошибки и злоупотребления. Пока документ не прошел проверку и подтверждения, на подпись не поступает.
- Система прав, позволяющая настраивать для каждого пользователя видимость и возможность подписи\визирования документы по большому кол-ву критериев.
- Почтовые оповещения пользователей о необходимости визировать и подписывать документы
- Возможность подписывать документы в одном информационном пространстве (в одной форме системы) нескольких ЮЛ одновременно
- Используется двухфакторная модель аутентификации в систему: как через «толстого клиента» фиг. 4 - фиг. 11, так и через Веб интерфейс фиг. 12. Настройки, система прав и конструктор запросов доступны только через «толстого клиента». Подпись и визирование может осуществляться, как через «толстого клиента» и через web интерфейс. Техническим результатом предложенной модели является расширение функциональных возможностей системы, ее быстродействия и минимизация ручных действий оператора, за счет обеспечения возможности интегрирования с любыми удостоверяющим центром и системой электронного оборота, автономной работы по процессу электронного обмена при согласовании и электронной подписи документов, двухфакторной модели аутентификации с выбором рабочего сервера, а также автоматизации контроля цикла движения документа и настройки на конкретного пользователя для исключения потенциальных ошибок и злоупотреблений.
Указанный технический результат достигается тем, что в. автоматизированной системе электронной подписи документов, содержащей выделенный сервер с входным интерфейсом, включающим в себя блок подготовки электронных версий документов, а также подсистемой формирования электронно-цифровой подписи (ЭЦП), включающей в себя блок отображения и трекинга документов в соответствии правами пользователя, блок отображения статуса документа и блок криптографических операций средствами КриптоПро, подсистемой удостоверяющего центра (УЦ), включающей в себя блок выдачи юридически значимого документа, подписанного ЭЦП, на выделенном сервере дополнительно сформирована подсистема согласования электронных версий документов и выбора удостоверяющего центра, включающая в себя первый элемент ИЛИ, блок отправки электронной версии документа на визирование, блок отправки электронной версии документа на подпись и блок автоматического формирования запроса в удостоверяющий центр (УЦ), включающий в себя конструктор запросов, причем во входной интерфейс дополнительно введены блок входа в систему и блок автоматизированной загрузки электронных версий документов в систему, в подсистему формирования ЭЦП дополнительно введены второй элемент ИЛИ, блок почтового извещения о необходимости подписи и блок почтового извещения о необходимости визирования, а в подсистему УЦ дополнительно введен блок обработки документа в выбранном удостоверяющем центре (УЦ), при этом выход блока подготовки электронных версий документов через последовательно включенные блок входа в систему и блок автоматизированной загрузки электронных версий документов в систему связан со вторым элементом ИЛИ, первый выход которого подключен к первому входу блока почтового извещения о необходимости подписи, а второй - через блок почтового извещения о необходимости визирования - к входу первого элемента ИЛИ, один выход которого через блок отправки электронной версии документа на визирование подключен ко второму входу блока почтового извещения о необходимости подписи, а второй выход - через последовательно включенные блок отправки электронной версии документа на подпись, блок автоматического формирования запроса в УЦ, включающий в себя конструктор запросов, и блок обработки документа в выбранном УЦ - к входу блока выдачи юридически значимого документа, подписанного ЭЦП, являющегося выходом системы, выход блока почтового извещения о необходимости подписи подключен ко второму входу блока отправки электронной версии документа на подпись.
Кроме того, входы в блоки входного интерфейса и конструктор запросов выполнены в виде интерактивных форм на экране дисплея, содержащих интерактивные разделы функционалов «Документы», «Взаимодействия с УЦ» и «Система прав».
Кроме того, интерактивные формы конструктора запросов дополнительно содержат интерактивные подразделы «Основные действия», «Методы», «Глобальные переменные», «Список структур» и «Список нестандартных данных».
Кроме того, вход во входной интерфейс выполнен в виде интерактивной формы на экране дисплея, содержащей интерактивный раздел «Входящие».
Полезная модель поясняется чертежами.
На фиг. 1 представлена общая схема автоматизированной системы электронной подписи документов предлагаемой полезной модели.
На фиг. 2. представлена схема работы с системой «Такском Файлер» (показаны позиции блоков, совпадающих с предлагаемой полезной моделью).
На фиг. 2. представлена схема работы с системой «Контур Диадок» (показаны позиции блоков, совпадающих с предлагаемой полезной моделью).
На фиг. 4. показана форма входного интерфейса для задания настроек типов документов предлагаемой полезной модели.
На фиг. 5. показана форма входного интерфейса с разделом реестра документов (настройка графа визирования).
На фиг. 6. показана форма конструктора со списком основных действий.
На фиг. 7. показана форма конструктора со списком методов.
На фиг. 8. показана форма конструктора со списком глобальных переменных.
На фиг. 9. показана форма конструктора со списком структур.
На фиг. 10. показана форма конструктора со списком нестандартных типов данных.
На фиг. 11 показана форма конструктора для задания наборов прав пользователей.
На фиг. 12. показана форма входного интерфейса для аутентификации в систему минуя «толстого клиента».
Автоматизированная система электронной подписи документов содержит выделенный сервер 1 с входным интерфейсом 2, включающим в себя блок подготовки электронных версий документов 3. На сервере сформированы подсистема формирования электронно-цифровой подписи (ЭЦП) 4, включающая в себя блок отображения и трекинга документов в соответствии правами пользователя 5, блок отображения статуса документа 6 и блок криптографических операций средствами КриптоПро 7, подсистема удостоверяющего центра (УЦ) 8, включающая в себя блок выдачи юридически значимого документа, подписанного ЭЦП 9, На выделенном сервере дополнительно сформирована подсистема согласования электронных версий документов и выбора удостоверяющего центра 10, включающая в себя первый элемент ИЛИ 11, блок отправки электронной версии документа на визирование 12, блок отправки электронной версии документа на подпись 13 и блок автоматического формирования запроса в удостоверяющий центр (УЦ) 14, включающий в себя конструктор запросов 15, причем во входной интерфейс 2 дополнительно введены блок входа в систему 16 и блок автоматизированной загрузки электронных версий документов в систему 17, в подсистему формирования ЭЦП 4 дополнительно введены второй элемент ИЛИ 18, блок почтового извещения о необходимости подписи 19 и блок почтового извещения о необходимости визирования 20, а в подсистему УЦ 8 дополнительно введен блок обработки документа в выбранном удостоверяющем центре (УЦ) 21, при этом выход блока подготовки электронных версий документов 3 через последовательно включенные блок входа в систему 16 и блок автоматизированной загрузки электронных версий документов в систему 17 связан со вторым элементом ИЛИ 18, первый выход которого подключен к первому входу блока почтового извещения о необходимости подписи 19, а второй - через блок почтового извещения о необходимости визирования 20 - к входу первого элемента ИЛИ 11, один выход которого через блок отправки электронной версии документа на визирование 12 подключен ко второму входу блока почтового извещения о необходимости подписи 19, а второй выход - через последовательно включенные блок отправки электронной версии документа на подпись 13, блок автоматического формирования запроса в УЦ 14, включающий в себя конструктор запросов 15, и блок обработки документа в выбранном УЦ 21 - к входу блока выдачи юридически значимого документа, подписанного ЭЦП 9, являющегося выходом системы, выход блока почтового извещения о необходимости подписи 19 подключен ко второму входу блока отправки электронной версии документа на подпись 13.
Входы в блоки входного интерфейса 2 и конструктор запросов 15 выполнены в виде интерактивных форм на экране дисплея, содержащих интерактивные разделы функционалов «Документы», «Взаимодействия с УЦ» и «Система прав».
Интерактивные формы конструктора запросов 15 дополнительно содержат интерактивные подразделы «Основные действия», «Методы», «Глобальные переменные», «Список структур» и «Список нестандартных данных».
Вход во входной интерфейс может быть выполнен в виде интерактивной формы на экране дисплея, содержащей интерактивный раздел «Входящие».
Конкретная реализация и функционирование автоматизированная системы электронной подписи документов представлены ниже.
Функционирование системы в общем виде представляет собой взаимодействие между собой функционалов:
- Документы.
- Взаимодействия с УЦ.
- Система прав.
Процесс подписи документов в предлагаемой модели для пользователя заключается в следующей последовательности:
1. Пользователь входит в систему под логином и паролем. В системе отображаются все ЮЛ, доступные пользователю по правам.
2. В систему автоматизировано или вручную загружаются файлы документов.
3. Система автоматически (по заданным настройкам) формирует оповещение на визирование и подпись документа и отправляет на e-mail пользователей.
4. Пользователь в системе визирует и/или подписывает документ (в зависимости от наличия прав).
5. Система Криптопро к каждому документу генерирует электронную подпись, на основе заданного в настройках сертификата подписи.
6. Подписанный документ и подпись к нему автоматически формируется в контейнер и отправляется в УЦ.
7. УЦ обрабатывает (формирует квитанции, проставляет штамп времени) документ и отправляет сведения обратно в систему.
8. В системе находится подписанный документ.
В разделе «Документы» задаются настройки для типов документов: указываются типы документов, порядок подписи, двусторонний или односторонний, что представлено на фиг. 4. Количество типов документов может быть неограниченным. В данном разделе также содержится реестр документов, что представлено на фиг. 5. Реестр документов
формируется путем закачки (автоматически или вручную) документов для последующего визирования и подписания их. В реестре также есть кнопки «подписать» и «визировать». Также есть возможность выделить список необходимых документов и подписать их массово.
Ручная загрузка документов осуществляется по следующему алгоритму:
1) Нажать кнопку «добавить».
2) Указать тип документа.
3) Выбрать ЮЛ продавца, ЮЛ покупателя.
4) Выбрать файл или список файлов.
5) Нажать кнопку «добавить».
Автоматическая загрузка документов осуществляется через интеграцию данной системы с любой системой документооборота посредствам XML форматов. Интеграция осуществляется через файловую систему. Для этого создаются папки inbox и outbox, и прописывается к ним путь в настройках данной системы. Система будет автоматически отслеживать эти папки с интервалом раз в минуту (в системе может быть настроен другой интервал времени), и обрабатывать контейнеры.
Контейнер - zip архив следующей структуры:
- Папка с произвольным именем
- Файл документ
- Document.xml
- Info.xml
Файл документ - документ для подписи в произвольном формате. Исключения составляют только те документы, которые строго регламентированы государством, в соответствии с законодательными актами.
Info.xml - xml файл содержащий информацию о типе документа и путь к нему внутри архива.
Document.xml - информация об отправителе и получателе документа, информация о документе, также в этом файле указывается информация необходимая для подписи документа: сертификат, отпечаток сертификата, идентификаторы личных кабинетов УЦ.
В разделе «Взаимодействие с УЦ» задаются настройки, каким УЦ будут обслуживаться документы, что представлено на фиг. 6 и фиг. 7. Система обладает гибкими возможностями и позволяет производить данные настройки вплоть до каждого документа. Настройки осуществляются по следующим аналитикам: ЮЛ-поставщика, ЮЛ-заказчика, клиенту, РД, тип документ, период, ГО документа. Таким образом, каждый документ обладает признаком, в каком УЦ он обслуживается. Для генерации ЭП в данной системе необходимо наличие на компьютере пользователя программы КриптоПро CSP.
Для настройки взаимодействия с УЦ используется конструктор запросов 15. Конструктор состоит из:
- Списка основных действий фиг. 6.
- Списка методов фиг. 7.
- Списка глобальных переменных фиг. 8.
- Списка структур фиг. 9.
- Список нестандартных типов данных фиг. 10.
Для каждого метода описываются два события:
- Событие до вызова метода.
- Событие после вызова метода.
Для каждого параметры описываются события:
- Событие после получение параметра.
В конструкторе описаны следующие стандартные методы:
- Decode - декодировать закрытой частью ключа.
- Encode - закодировать закрытой частью ключа.
- ConvertTo32str - преобразовать в base32 строку.
- ConvertTo64dtr - преобразовать в base64 строку.
В конструкторе описаны следующие стандартные переменные:
@cert - Двоичное DER-представление X.509-сертификата текущего пользователя.
В конструкторе изначально заведены основные действия, которые необходимо детализировать под каждый УЦ:
Аутентификации в УЦ.
1. Подпись.
2. Переподпись.
3. Проверка статуса.
4. Получения файла контейнера.
5. Получение файла извещения.
При необходимости через пользовательский интерфейс можно завести дополнительные действия. Все созданный вручную действия должны быть в обязательном порядке привязаны к основным, и задан порядок их выполнения.
Список структур. В конструкторе необходимо описать все структуры, которые будут использовать при составлении запроса.
Список нестандартных типов данных. Если в структурах используются нестандартные типы данных они должны быть описаны в каталоге типов данных.
Список глобальный переменных. Здесь описываются переменные, в которых будут храниться результаты выполнения методов
Для каждого действия в конструкторе запросов описываются:
1) Тип метода, post или get.
2) Параметры метода.
3) Структуры, которые могут являться значением параметра.
4) Параметры, которые могут являться ответом сервера на запрос.
В разделе «Система прав» для пользователей задаются наборы прав, которые позволяют пользователю видеть, визировать и подписывать документы, представлено на фиг. 11. Система прав обладает возможностью гибкой настройки прав для конкретного пользователя и состоит из следующих пространств прав, для каждого из действий:
Просмотр
- Типы документов (задается список типов).
- Состояние документов (задается список состояний).
- Местонахождение документа (задается список местонахождений).
- ЮЛ-поставщики (задается список ЮЛ-поставщиков).
- ЮЛ-заказчики (задается список ЮЛ-заказчиков).
- Подразделения Контрагента (задается список подразделений).
Визирование
- Типы документов (задается список типов).
- Состояние документов (задается список состояний).
- Местонахождение документа (задается список местонахождений).
- ЮЛ-поставщики (задается список ЮЛ-поставщиков).
- ЮЛ-заказчики (задается список ЮЛ-заказчиков).
- Подразделения Контрагента (задается список подразделений).
Подпись
- Типы документов (задается список типов).
- Состояние документов (задается список состояний).
- Местонахождение документа (задается список местонахождений).
- ЮЛ-поставщики (задается список ЮЛ-поставщиков).
- ЮЛ-заказчики (задается список ЮЛ-заказчиков).
- Подразделения Контрагента (задается список подразделений).
Для настройки процесса визирования в системе реализован граф визирования. На фиг. 5 представлена форма настройки графа визирования.
В данной форме задается Клиент (ЮЛ), класс (тип) документа, сам граф и тип графа. В системе прав для каждого пользователя задается настройка для рассылки информационных сообщения о результатах документооборота. Это позволяет оперативно визировать\подписывать документы, при этом пользователям нет необходимости проверять систему на наличие новых документов, требующих обработки. Это с одной стороны позволяет оперативно реагировать на появление новых документов, а с другой уменьшает время, необходимое для работы в системе.
Раздел «Система прав» доступна администратору системы.
Существует следующие информационные рассылки:
- Документы, подлежащие визированию
- Документы, подлежащие подписанию
Также существует возможность настроить периодичность информационных рассылок.
Таким образом, предложенной полезной моделью обеспечивается достижение технического результата, которым является расширение функциональных возможностей системы, ее быстродействия и минимизация ручных действий оператора, за счет обеспечения возможности интегрирования с любыми удостоверяющим центром и системой электронного оборота, автономной работы по процессу электронного обмена при согласовании и электронной подписи документов, двухфакторной модели аутентификации с выбором рабочего сервера, а также автоматизации контроля цикла движения документа и настройки на конкретного пользователя для исключения потенциальных ошибок и злоупотреблений.