В современном мире уже трудно представить многие сферы деятельности человека без использования вычислительной техники. Она способствует быстрому обмену информацией и ускорению многих других процессов. Одним из таких процессов является обмен документацией как внутри компании, так и за её пределами. На сегодняшний день многие компании стремятся перевести как минимум часть процесса внутреннего обмена документами в ведение информационных систем. Хотя многие ограничиваются лишь электронной регистрацией документов и их частичной загрузкой в виде сканированных изображений, некоторые компании прилагают немалые усилия для перевода всей работы с большинством документов в электронный вид. Зачастую процессы согласования и регистрации перенести не так сложно, но когда дело доходит до этапа подписания документа многие компании начинают испытывать некоторые трудности связанные, в большей степени, с юридическими вопросами, касающимися электронно-цифровой подписи (далее ЭЦП). Этих вопросов всегда возникает достаточное множество, начиная от простейшего вопроса, какой документ может быть подписан ЭЦП, а какой — нет, и заканчивая вопросом о том, кто вообще имеет право подписывать данный документ.
Хотя на большую часть вопросов могут ответить нормативно правовые акты «Закон Республики Казахстан от 7 января 2003 года № 370-II Об электронном документе и электронной цифровой подписи» и «Постановление Правительства Республики Казахстан от 17 апреля 2004 года N 430 Об утверждении Правил электронного документооборота», на вопрос о том, кто может поставить свою ЭЦП на том или ином документе они могут ответить только косвенно, например, что документ должен быть подписан лицом имеющим на это полномочия и что подписанный ЭЦП документ приравнивается к документу подписанному вручную [1]. Поскольку законы об электронной цифровой подписи никак не регламентируют кто конкретно может подписывать тот или иной документ и приравнивают его к документу на бумажном носителе, подписанном собственноручно, можно сделать вывод, что на эти документы распространяются те же самые правила, которые существуют для «бумажных» документов. Эти правила описываются во множестве нормативно-правовых актах, каждый из которых отвечает за свою область деятельности компании, например, финансовую, работа с кадрами, юридическую, работа с клиентами и др.
Целью данной статьи не является поиск ответа на вопрос кто же конкретно может регистрировать тот или иной документ поскольку этим должны заниматься профессиональные юристы. Далее речь пойдёт об исследовании того, как информационные системы, призванные обеспечить ведение электронного документооборота могут или должны обеспечить проверку права подписи того или иного документа на разных уровнях и этапах его жизни. Конечно, в большинстве случаев, такие проверки не могут дать абсолютной гарантии того, что электронный документ будет подписан именно тем уполномоченным лицом, которое должно это сделать, но они могут обеспечить максимальный контроль и ограничения в этой области, чтобы потом компании, использующие подсистемы, осуществляющие эти действия, могли с лёгкостью отвечать на вопрос «а какое право этот человек имел на подпись этого документа тогда-то?». Помимо ответов на сложные вопросы подобные подсистемы смогут существенно сократить сами факты их возникновения и сэкономить большую долю средств на финансировании юристов и/или юридических отделов.
Для начала рассмотрим основные типовые этапы жизненного цикла электронного документа (рисунок 1).
Рис. 1. Основные этапы жизненного цикла электронного документа
Данные этапы могут изменяться в зависимости от многих факторов, но в большинстве случаев этап, когда документ является черновиком и ему присваиваются различные атрибуты существует практически всегда. Именно на этом этапе в документ можно заложить множество необходимых атрибутов, которые в дальнейшем могут быть использованный для проверки права подписи уполномоченного лица. Помимо этого, создаётся карточка документа, которая тоже может нести в себе необходимые свойства.
Ключевыми свойствами, влияющими на право подписания документа, обычно являются: тип документа, номенклатура, к которой он относится, должность предполагаемого подписанта и дата регистрации/подписания документа. Не все эти свойства обязательны для использования совместно, возможно использовать их в отдельности.
Проверки права подписания можно осуществлять несколькими способами используя их как в отдельности, так и используя их одновременно для повышения точности. Ниже будут представлены основные из них.
Проверка является ли текущий пользователь предварительное указанным подписантом. Такой метод очень прост в своём применении и требует лишь проверки является ли текущий пользователь тем самым человеком, который вписан с атрибуты документа (или карточку документа) как единственно возможный подписант. Он весьма прост в своём применении и может выполняться автономно на стороне клиента с последующей проверкой на стороне сервера, но у такой простоты есть и свои недостатки.
Для выполнения этой проверки на стороне клиента достаточно сверить данные сертификата пользователя с данными внесёнными в атрибуты документа. Затем на стороне сервера требуется дополнительный контроль действительности сертификата, наличия для его открытого ключа регистрационного свидетельства и целостности подписи.
Одним из существенных недостатков является то, что кто-то должен указать подписанта для данного документа и не совершить при этом непреднамеренной (например, при незнании, что сейчас работает заместитель, а не сам сотрудник) или, что ещё хуже, намеренной ошибки. Данный выбор обычно не подкреплён никакими электронными доказательствами, а лишь регламентирован различными регламентами вне системе электронного документооборота (СЭД). Соответственно и проверка права подписи у указанного в атрибутах документа (или карточки документа) может быть выполнена только вручную и только уполномоченными сотрудниками.
Проверка на соответствие подписываемого документа объектным идентификаторам (OID) записанным всертификат пользователя. Данная проверка может производиться как на стороне клиента, так и на стороне сервера электронного документооборота в котором обрабатывается данный конкретный документ. Для её выполнения нужно произвести некоторые подготовительные работы с документом.
Для проверки права подписания с помощью проверки на соответствие OID достаточно вести в системе электронного документооборота объектные идентификаторы (OID) для каждой номенклатуры дел и присваивать номенклатуру документу до его подписания. Данная номенклатура должна быть вписана в атрибуты документа в виде её OID. Таким образом в момент подписания на стороне клиента можно выполнить проверку наличия конкретного OID присвоенного документу в сертификате пользователя выданном уполномоченным удостоверяющим центром (УЦ). Если такой идентификатор присутствует в сертификате пользователя и сертификат действителен на текущий момент (т. е. его срок действия не истёк, он не состоит в списках отзыва УЦ и выдан уполномоченным или доверенным УЦ), то программное обеспечение на стороне клиента должно разрешить проставление подписи для данного лица, в обратном случае пользователь должен получить уведомление с причинами отказа в подписании и предложение обратиться в службу поддержки пользователей.
Очень важно, чтобы все вписанные в сертификат пользователя данные (OID) присутствовали также в регистрационном свидетельстве, выпускаемом УЦ при выдачи пользователю сертификата ЭЦП и закрытого ключа. Только этот документ, согласно законам [2,3,4], имеет юридическую силу в суде и только на его основании может быть подтверждено само право владения конкретным закрытым ключом.
При сохранении новой версии документа в СЭД может выполняться проверка на стороне сервера — из документа считывается и проверяется электронная подпись, а также получается сертификат пользователя, который подписал данный документ (обычно его копия храниться вместе с документом и также подписана как УЦ, так и самим пользователем). После проверки подписи должна быть произведена повторная проверка наличия «номенклатурного» OID в сертификате пользователя для исключения подлога. Данная проверка должна сверять не только OID номенклатуры вписанный в атрибуты документа, но и OID номенклатуры указанной в карточке документа, при этом у подписанта не должно быть прав на редактирование этой карточки (или отдельных полей) на этапе подписания для исключения возможности смены значений в полях карточки.
Для последующих читателей данного документа должен быть предусмотрен функционал повторной проверки подписи в любой момент времени после подписания, включая момент нахождения документа в архиве СЭД.
К достоинствам такого метода проверки можно отнести скорость, возможность автономной работы клиента от сервера в момент подписания (не считая проверки наличия сертификата в списках отзыва УЦ), а также точность проверки, которая гарантирована тем, что при его выпуске сертификат с прописанными в нём OID подписывается корневым сертификатом УЦ и эту подпись достаточно легко проверить программными средствами на стороне клиента.
К недостаткам относится тот факт, что сертификат и регистрационное свидетельство для него выпускаются на определённый срок, и любое изменение в них приводит к тому, что нужно их перевыпустить. Перевыпуск влечёт за собой как временные затраты на перезапись носителей сертификатов и закрытых ключей (закрытые ключи не требуют обязательного перевыпуска), так и финансовые на оплату деятельности УЦ в рамках подобных запросов. Так как такие запросы могут возникать достаточно часто в виду того, что не только могут изменяться должности уполномоченных сотрудников, но и могут появляться временные заместители (например, на время отпуска основного сотрудника), которым необходимо выдать права на подписание, а потом их аннулировать. Таким образом, возникают множественные необходимости замены сертификатов: при смене должности одного лица нужно заменить сертификат как ему, так и лицу, которое займёт вакантную должность; при отпуске сотрудника нужно временно заменить его сертификат убрав из него права на подпись, а его заместителю выдать права, затем по окончанию срока замещения перевыпустить сертификаты опять. Данный недостаток достаточно существенен, поскольку каждый перевыпуск требует сбора достаточного количество документов и происходит обычно не моментально, а в сроки, установленные УЦ.
Проверка на наличие права подписания определённого типа документов учеловека занимающего конкретную должность вданный момент времени. В этом случае проверяется не наличие конкретных OID в сертификате подписанта, а принадлежность текущего пользователя к любой из определённых должностей, для которых разрешено подписание конкретной номенклатуры (в атрибутах документа по-прежнему требуется её наличие). Такая проверка не может работать автономно от сервера СЭД, но всё же может частично исполняться на стороне клиента. Для её выполнения на стороне клиента требуется выполнить запрос к серверу в целях установления факта вхождения в должность, которая закреплена как уполномоченная для подписания документов, попадающих в конкретную номенклатуру. Поскольку подобные сопоставления на стороне клиента выполнять не имеет смысла сервер должен предоставлять простой интерфейс для проверки права подписания возвращающий ДА либо НЕТ и принимающий на вход сертификат пользователя и номенклатуру документа (или идентификатор карточки документа). Подсистема, скрывающаяся за данным интерфейсом, должна также проверять наличие (и действительность) регистрационного свидетельства, дающего определённому в нём человеку право использования закрытого ключа, соответствующего открытому ключу, прописанному в полученном сертификате. Таким образом всю цепочку можно отразить на схеме взаимодействия клиентской стороны с серверной (рисунок 2).
Рис. 2. Схема проверки права подписи через связь сотрудника, должности и номенклатуры (на схеме отражены только положительные решения)
При сохранении изменений в документе на сервере, как и в предыдущем методе, требуется проверка права подписания на стороне сервера для исключения подлога. Функционал проверки права подписи в любое время также необходим.
Для обеспечения проверки права подписи в любое время в СЭД должна храниться вся история перемещения сотрудников внутри должностей с учётом временных интервалов в которые они их занимали. Так же требуется хранить информацию о том, когда и какая должность имела право подписывать определённую номенклатуру.
Метод проверки основанный на работе с должностью решает множество недостатков предыдущего метода, таких как временные и финансовые затраты при перевыпуске сертификатов и регистрационных свидетельств. Кроме того, нет необходимости перевыпускать сертификаты большей части сотрудников компании при изменении номенклатуры дел.
К сожалению, подобный метод имеет свои существенные недостатки. К ним относится тот факт, что связи должностей, сотрудников и номенклатур не удостоверены никакими цифровыми подписями и могут быть изменены в любой момент. Для решения этого недостатка в СЭД должна быть предусмотрена возможность подписания этих связей с помощью ЭЦП первых руководителей или других ответственных лиц. Также теряется возможность автономной работы с документом.
Кроме приведённых методов для проверки права подписи можно использовать их комбинации, а также и другие методы. Самое важное, чтобы все условия, связи и компоненты в используемой логике были подкреплены ЭЦП и/или отдельными подписанными документами. Нужно всегда помнить, что одно из слабейших мест любой крупной системы — это всеохватывающая власть над ней у администраторов данной системы, которые в любой момент могут манипулировать любыми неподписанными данными.
Такие проверки могут помочь не только при подписании документов ЭЦП, но и заблокировать регистрацию в СЭД документов, подписанных на бумажных носителях благодаря контролю за атрибутами (подписант) регистрационной карточки, создаваемой в СЭД для каждого документа.
Подводя итог можно сказать, что система электронного документооборота способна не только ответить на вопрос любого её участника «Тварь я дрожащая или право имею?», но и заблокировать подписание важных документов неуполномоченными сотрудниками. Это поможет существенно упростить работу юридических отделов впоследствии и чётко регламентировать деятельность сотрудников компании.
Литература:
- Статья 7. Пункт 1, Закон Республики Казахстан от 7 января 2003 года N 370 «Об электронном документе и электронной цифровой подписи», редакция от 01.01.2016, URL: http://adilet.zan.kz/rus/docs/Z030000370_ (дата обращения: 02.06.2016)
- Статья 10. Пункт 1, Закон Республики Казахстан от 7 января 2003 года N 370 «Об электронном документе и электронной цифровой подписи», редакция от 01.01.2016, URL: http://adilet.zan.kz/rus/docs/Z030000370_ (дата обращения: 02.06.2016)
- Статья 14. Закон Республики Казахстан от 7 января 2003 года N 370 «Об электронном документе и электронной цифровой подписи», редакция от 01.01.2016, URL: http://adilet.zan.kz/rus/docs/Z030000370_ (дата обращения: 02.06.2016)
- Статья 15. Закон Республики Казахстан от 7 января 2003 года N 370 «Об электронном документе и электронной цифровой подписи», редакция от 01.01.2016, URL: http://adilet.zan.kz/rus/docs/Z030000370_ (дата обращения: 02.06.2016)
