По мотивам Социальный труд и открытое проектирование. Введение

предлагается организовать открытый проект «Электронное подписание внутренних документов компании». Интерес к электронной подписи большой (МЧД и т.п.), но простых решений нет.

В целом подписание внутренних документов компании несложно расширить на «внешнее»: для этого достаточно с контрагентами заключить регламент, который «узаконит» применение подписи. Внутренние документы компании – разнообразны, распорядительные (приказы, распоряжения, служебные записки), бухгалтерские и управленческие отчеты и другие документы.

В целом «Электронное подписание внутренних документов компании» можно распространить на очень широкую отраслевую специфику, например, банковскую – подписание первичных документов и бухгалтерских отчетов (балансы, книга открытых \ закрытых счетов и т.п.) по 2346-У. 

Недавно обновился Трудовой кодекс (Статьи 21.1 – 22.3 введенные ФЗ от 22.11.2021 N 377) в части электронной подписи, что резко повысило интерес к подписанию кадровых документов. Предлагается в рамках проекта научиться подписывать кадровые документы, т.к. если это получится, то остальное будет реализовать еще проще. Важно не столько услужение задачи – сколько то, что электронный документооборот хоть как-то начали регламентировать законодательно (криво, но хоть как-то).

Как вариант: у компании уже есть HR-система, но без кнопки «подписать». Проект КЭДО позволит добавить эту кнопку (включая маршруты согласования и подписания) и организовать долговременный архив с электронной подписью документов в рамках юридически значимого документооборота.

Сокращения: ЭП – электронная подпись, КЭДО – кадровый электронный документооборот, УКЭП (КЭП) \ УНЭП (НЭП) – усиленная (читай криптографическая, точнее «усиленная криптографией») квалицированная \ не квалицированная ЭП.

1. Общая постановка задачи

Проект «как проект»

Организовать как проект – это значит выполнить обычные для проекта требования (см. PMBOK или груды подобной проектной макул литер атуры) понять требования заказчика, организовать проектную команду, каждому участнику команды «нарезать задачи» и т.п. Хорошо, если найдутся заказчики, которые готовы будут внедрить предложенное решение, но и это не обязательно. В любом случае, будем считать, что есть «виртуальный заказчик» с некоей типовой задачей (требованиями).

Идеальной комбинацией было бы, если ИТ-ВУЗ открыл бы такой открытый (публичный) проект для своей кадровой службы и своими силами реализовал бы Open Source проект (а мы бы ему дружно в этом помогали).

Хорошо бы обозначить устав проекта (цели) и т.п., развернуть инфо-площадку проекта, где идет обсуждение и выбор проектных решений проектной командой и т.п. В этой части (it-pamphlet#1) поговорим лишь о направлениях (подходах) решения задачи.

Параметры проекта

Участники. Это те, у кого есть возможность совмещать основную работу (учебу, безделье) с краудсорсингом, а именно участвовать в подготовке открытого проекта \ готового решения по внедрению электронного кадрового документооборота (или не только кадрового «электронного документооборота с электронной подписью»).

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

Комплексность. В рамках проекта хотелось бы получить подробные ответы на все составные части проектного решения КЭДО. Пока вижу следующие фрагменты (артефакты):

• «бумажные» регламенты (включая, «согласие подписывать кадровые документы электронной подписью») на внедрение и использование КЭДО;   

• ПО КЭДО (софт + эксплуатационная документация);  

• инфраструктура ЭП, включая удостоверяющий центр, сервисы времени и проверки сертификатов и др. Например, если развертывается собственный неаккредитованный удостоверяющий центр (НЭП), то также потребуются к нему «бумажные» регламенты, которые в том числе, регламентируют обработку персональных данных.

Результат проекта глазами кадровика (заказчика). В простом варианте: кадровик загружает в КЭДО кадровый документ (pdf), далее документ проходит цикл согласований и подписаний и на выходе получится кадровый документ:

А) подписанный электронной подписью с визуализируемыми штампиками (оттисками ЭП);

Б) всё подписанное является документами долговременного хранения и удовлетворяет требованиям: Трудовой кодекс (Статьи 21.1 – 22.3 введенные ФЗ от 22.11.2021 N 377), Приказ Минтруда России от 20.09.2022 № 578н, 63-ФЗ и др.

В сложном варианте: кадровик выгружает из HR-системы в КЭДО документ и далее передает обратно в HR-систему его статус (например, «подписан»).

Результат проекта глазами айтишника (обслуги КЭДО). В ИТ-каталоге компании появляются как минимум два новых сервиса: поддержка КЭДО и выдача (передача) ключей ЭП.

Результат проекта глазами лицензирования. Идеально результат проекта (проектное решение) должно быть под лицензией класса copyleft, но для первого варианта (обычно же «комом») - это не обязательно. Отдельные составные части проектного решения (программы) могут быть коммерческими. Open Source \ Free проект может быть не обязательно на «все 100%» (50\50 тоже неплохо). 

2. С чего начать?

Давным-давно в каких-то ГОСТ 15.РВ ххх прочитал две умные мысли (точнее требования). Первая: прежде чем что-то делать – посмотри по сторонам, что в этом направлении сделано в мире (другими), проанализируй это.

Это будет первая задача. Целиком и «под ключ» - найти вряд ли удастся, но многие готовые компоненты - непременно. К сожалению, не нашел Open Source \ Free систем класса BPMS\DMS (ECM) с готовой кнопкой «подписать» для «Community Edition». Т.е. если бы в такой системе можно было бы гибко настраивать маршруты и была бы «заветная» кнопка «подписать», то решение бы было «почти готово».    

На примере «Отечественного производителя». Конфигурации «Community Edition» отечественных систем класса СЭД или всякие «Low code» с поддержкой конфигурации СЭД, в которых нет ЭП:

• Citeck ECOS Community

• ELMA Community Edition

«Не Отечественные производители» поступают хитрее (коварнее). Некоторые из них добавляют в «Community Edition» сильно старую и сильно урезанную реализацию электронной подписи: вроде как формально она есть, но настолько неудобная, что использовать практически невозможно.

В любом случае, перед тем «как с головой окунаться» в Open Source крипто-библиотеки, в задачу проекта войдет «посмотри по сторонам» и запиши анализ в блокнотик. Туда же хорошо бы записать и коммерческие приложения. К коммерческим предложениям будут два обязательных условия: наличие триальной версии по кнопке «сказать» на сайте и наличие явной цены на сайте хоть на какую-то конфигурацию, т.е. «за ценой обращайтесь индивидуально, т.к. одно и тоже мы продаем за очень разную цену» – не пройдет. 

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

В целом, для решения основных задач КЭДО (в рамках ТрудКодекса) требуется «легкий СЭД» - простая согласовалка \ подписалка, которая позволяет настраивать последовательно-параллельные маршруты (задачи согласования \ подписания) с заветной кнопочкой «подписать» и долго сохранять юридическую значимость (как минимум за пределами срока действия личного сертификата). Конечно, если документы не выгружаются далее в архив, то в этой СЭД должен быть поиск документов, хотя бы по атрибутам, указанных в карточке документа (как в любой DMS\ECM). Задачка выглядит вроде, как и не сложно. 

Постановку задачу нужно формализовать в виде бизнес-требований, но основное их содержание было приведено абзацем выше (плюс ссылки на ТрудКодекс, приказы МинТруда и 63-ФЗ). В приложении к Приказу Минтруда России от 20.09.2022 № 578н приведен перечень кадровых документов. Можно разбить на задачи минимум и максимум, например, подписывать только документы, для которых не требуется КЭП (минус пять документов из общего списка) и подписывать всё, что разрешено (максимум).

Утверждение, что у каждой компании будут свои уникальные бизнес-требования к КЭДО – мне не понятно. «Тараканы» у каждого будут – свои, но требования к подписанию \ хранению – «в целом» одинаковые. Вариации типа: мне такой –то «загогулистый» маршрут подписания и «зелененький штамп» задаются требованием: наличие современного конструктора маршрутов и дизайнера штампов.

Чтобы было понятно «куда идем» и какие задачи в проекте решаем, то «для затравки» приведем два «подводных камня» проекта (любого КЭДО).

3. Основной «подводный камень» КЭДО и иного ЭДО

Требование долгосрочной юридической значимости подписанного документа – это основная проблема, которую часто не понимают. Почти всё современное подписание – оно «кратковременного» срока хранения подписи. Типовой вопрос \ ответ («подводный камень») на форумах в ветках документооборота с ЭП (гуглится):

Вопрос: может ли подпись быть "недействительна в силу истечения времени"
Ответ: нет, если подписание произошло в пределах срока, когда подпись была действительна.
PS. Ну что вы, в самом деле, как дети малые..

Правильный ответ: если вы сможете однозначно доказать, что подписание произошло в пределах срока, когда подпись была действительна. К сожалению, почти сразу после подписания электронная подпись (усиленная КЭП/НЭП) на документе – «протухает» и становится проблематичным доказать, что подпись была сделана при действующем сертификате. Как это ни печально: подпись вроде как есть, но срок окончания действительности сертификата истек, и «карета» на глазах превратилась в «тыкву», т.е. проверить подпись с истекшим сроком сертификата – это большая проблема.

Если вы вели архив подписанных документов, то посмотрите, что стало с документами полуторагодичной давности: если ранее программа проверки подписи вам выводила: «все хорошо» с зелеными галками, то теперь стало иначе. «Классическое подписание» работает так: подписали и сразу отдали второй стороне, а вторая сторона тут же проверила подпись, убедилась, что подпись «хороша», но что срок годности подписи всего то – «ничего» и после его истечения подпись «протухает» – ей «невдомек» (и вам тоже). Представьте, что было бы в стране, если на всех бумажных документах рукописные подписи исчезали (высыхали чернила) бы спустя 15 месяцев.      

Срок действия сертификата проверки электронной подписи – обычно 15 месяцев: получили сертификат год назад, подписали сегодня и после трех месяцев вам уже практически не получится (однозначно) доказать, что подпись на документе действительна. Странно и страшно (суровая реальность). Чтобы устранить эту проблему – и затеян огромный айтишный «кавардак» (как ставить подпись, куча стандартов и дополнительные сервисы), который помноженный на юридическую «неразбериху» (как признавать подпись спустя время следуя «буквам в законе») пытается решить задачу что в кадровом документообороте, что в других документооборотах с ЭП.   

Для продления «срока годности» поставленной ранее подписи, в первую очередь, при отзыве сертификата, есть варианты:

1 «Долгий» (многолетний) сертификат и время подписания. Требуется: подтверждение времени, когда подписан документ, и знания по отзыву сертификата (статус сертификата) на момент проверки. При действительном сертификате проверки подписи (не путать со сроком действия закрытого ключа), даже если сертификат был отозван, мы можем утверждать, что подпись была поставлена, когда сертификат действовал. Для этого требуется достоверное доказательство «доверенного времени» (например, штамп времени, например, по стандарту CADES-T) и срок действительности сертификата проверки подписи, например, 10-15 лет. Ключевой момент: сертификат на момент проверки может быть отозван, но подписание происходило при действительном сертификате проверки подписи.        

Законодательно про сроки упомянуто только в приказе N 796-ФСБ:

36. Срок действия ключа проверки ЭП не должен превышать срок действия ключа ЭП более чем на 15 лет.

Даже если срок действия закрытого ключа 15 месяцев, то у нас еще в запасе аж 15 лет для проверки этой подписи. Почему не выдаются сертификаты со сроком действия ключа проверки на 15 лет? Фактически для увеличения срока от центра требуется лишь вести (отвечать на запрос) статус этого сертификата в течении заявленного времени, при этом единственная ценность, - это знание, что если сертификат был отозван, то в какое время: до подписания или после.

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

2 Усовершенствованная подпись (не путать с «усиленная»). Насколько я понял в международной трактовке любая CADES – подпись, включая CAdES-BES (Basic Electronic Signature) – уже по определению «Усовершенствованная»: advanced electronic signature (AdES)  https://en.wikipedia.org/wiki/Advanced_electronic_signature

Однако нам требуется «Усовершенствованная» не в международной, а «в русско-народной» интерпретации. В российском понимании: «Усовершенствованной» подпись становится при наличии сервисов времени TSP и онлайн проверки сертификатов OCSP (или аналогичных сервисов). https://www.cryptopro.ru/products/cades

Это стандарты начиная с CADES-XL (CAdES-X Long Type 1). Обзор форматов стандарта CAdES говорит, что лучше сразу использовать CADES-A version 3, как единственный современный вариант, который «улучшает» все существующие CADES. https://strozhevsky.com/free_docs/CAdES.pdf

Обычно срок «годности» подписи (сертификата) CADES-XL \ CADES-A составляет 15 лет (сертификат подписи штампа времени и онлайн проверки сертификатов).

Это конечно не 75 лет или «постоянного хранения» (вечно), но вполне достаточно: уже через пять лет скорее всего будет понятно, как правильно обеспечить эти самые 75 лет (пока лишь «вилами по воде», и нет надежды на скорое принятие чего-либо типа законопроекта № 1173189-7).

По стандартам CADES есть красивый обзор Как проверить подпись через 100 лет?

https://pki-forum.ru/files/files/archive_2014/17%20kiyko.pdf

3 Некая доверенная «третья сторона». Грубо: при возникновении спора в суде говорится, что есть договор с контрагентом и в нем указано, что есть третья сторона – арбитр (типа Диадок) и он хранит документы или их заверяет (своей ЭП) или «еще что-то» и именно ему - верить. Так и в кадровом документообороте может быть третья сторона (две: работодатель, сотрудник) – она и «гарантирует законность». Этот вариант не рассматриваем. Обычно это «облачные истории» (к тому же и не «ясные»).

4 Другие варианты. Возможна ситуация: типовой срок «годности» подписи работодателя и сотрудника – год.  Документ подписываем тремя подписью, третья - «серверная», например, выданная внутренним корпоративным неаккредитованным удостоверяющим центром (например, сертификат проверки 15 лет). Она ставится последней и заверяет как обе личные подписи (работодатель + сотрудник) и статус их сертификатов проверки подписи (что сертификаты действующие, т.е. аналог OCSP), так и время (аналог TSP).

Такой подход видимо возможен, т.к. законодательно не определены ни TSP, ни OCSP и вообще в законах нет никакой конкретики: слов CADES, требований по сертификации к сервисам TSP \ OCSP и т.п. Например, приказ «о времени» от МинЦифры – это «как вилами по воде», Приказ МинЦифры от 06.11.2020 № 580 "Об утверждении порядка создания и проверки метки доверенного времени". Это вариант оставим как «запасной», он схож «с арбитражем», но внутри компании.

Дисклеймер: не являюсь сертифицированным специалистом в области криптографии, поэтому «вышеуказанное не точно». 

4. «Потустороннее» размещение подписи

К вопросу: какую подпись использовать. Есть три типа подписей (пути куда «ее воткнуть»):

а) "Отсоединенная\отделённая" (открепляемая) - отдельный файл (sig,p7s) и для её проверки нужен исходный документ (pdf, docx, txt, xml и т.п.), примеры: PKCS#7/CMS/CADES. Итого два файла: документ + подпись.

б) "Встроено-совмещенная" (не открепляемая), всего один файл, содержащий и документ и подпись.

б1) "Встроенная" - документ и подпись в одном файле, причем в том же формате, что и исходный документ. Реализуется самим форматом, подпись записывается внутри файла документа в специальные поля метаданных, примеры: PDF – PADES, docx\xlsx (Microsoft Office), XML – XMLDSig,

т.е. это не отдельный файл с расширением sig\p7s, а всё тот же тип файла, но
уже содержащий внутри подписи\сертификаты. Это самый понятный и практичный
вариант.

б2) «Присоединенная\совмещенная», единый файл с подписью, файл в специфическом формате, в формате отличном от формата исходного документа. Примеры: файл sig\p7s\sgn (расширение зависит от информационной системы). В такой нестандартно закодированной структуре содержится и исходный файл и подпись (подписи) к нему. Прочитать его обычно может только тот софт, который и делал подпись.  

https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=19091

https://dss.cryptopro.ru/docs/articles/rest/signserver/structs/sigparams.html

Какую подпись брать? Закон это не регламентирует. Будем ориентироваться на логику и здравый смысл (к сожалению, рос-государственная «логика» обычно противоречит общечеловеческому здравому смыслу).

Потерянная подпись. Представите ситуацию: вы принесли в суд документ и сказали, что «подписи из документа «выпали» (по дороге) и мы не можем их найти, но они точно были». Или вы отдаете кому-то пятьсот файлов: двести документов и триста подписей к ним и говорите: всё лежит в одной папке – сами разберите к какими документам какие подписи относятся (название файлов без связки «документ-подпись»). И … если какой-то подписи не найдете, то скажите нам, мы ее вам донесем. Это к тому, что часто сложно сказать сколько подписей в реальности было у подписанного документа (если документ физически отделен от подписи).

Если я не вижу свою подпись на документе, то могу и позабыть, что ранее его подписывал и снова подписать, и так десять раз. В итоге в отдельном «мешке» подписей (итоговой папке с подписями) будет много разных подписей одного подписанта одного документа (какую подпись выбрать?). Если на бумажном документе вы сразу увидите, что один подписант подписал «по забывчивости» этот документ десять раз, то в случае с электронной открепляемой подписью – вы не узнаете «сколько всего подписей» было в действительности.

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

Это всё «страшилки» про отсоединенную подпись. Как может быть построен на ней логичный документооборот – мне не понятно, но гос-инфраструктура, включая гос-сервисы проверки ЭП на госуслугах, сервис ГосКлюч, - ориентированы на открепляемую подпись.

Документ что электронный, что бумажный должен быть не отделим от его подписи (подписей), неужели это не является логичным? При отсоединенной (открепленной) подписи можно складывать отдельные подписи в отдельные файлики и потом принести документ и отдельно «мешок» подписей к нему. Точнее два «мешка»: мешок документов и «мешок» файлов подписей, где одному документу соответствует много подписей (в том числе разных подписей одного подписанта). Это нормально? Даже говорят о «цифровизации» подхода: О, как круто, ранее такое было невозможно! мы научились отделять подпись от самого документа (документ отдельно, подпись отдельно), это большое достижение digital по сравнению «с устаревшим аналоговым бумажным» документооборотом!    

Самый понятный вариант – это встроенная в pdf подпись (PADES): все работали с Abode Reader и даже без всяких КЭДО обычный сотрудник может подписывать встроенным в обычный Abode Reader инструментом документы. Дешево и сердито. Предлагается PADES взять за основу в проектном решении КЭДО. В нем есть понятный механизм визуализации нескольких штампиков (не подписываемые метаданные документа).

В обычном Abode Reader предусмотрен (и давно) раздел - добавление цифровой подписи. Раздел "Дополнительные инструменты", - вкладка "Сертификаты". В этом разделе можно поставить цифровую подпись (при использовании плагина к Abode Reader по имени «КриптоПро PDF» – квалифицированную подпись УКЭП), поставить отметку о времени и проверить сертификаты.

https://www.cryptopro.ru/products/other/pdf

Сценарий:

1. Загружаем в Abode Reader документ и нажимаем кнопку "Поставить цифровую подпись" (чтобы появилась кнопка, следуйте Раздел "Дополнительные инструменты", - вкладка "Сертификаты");

2. Выделяем участок документа, где будет стоять подпись;

3. В появившемся окне выбираем сертификат из списка, которым будем подписывать

4. И … «чудо»: у вас на документе в выделенном месте появится название подписанта, которому принадлежит ЭЦП, дата и время подписания. Это конечно может быть еще «не заветная» подпись с длительным сроком годности (хранения), но уже результат.

5. Если у вас нет никакой подписи, то перед подписанием Abode Reader предложит создать самоподписной сертификат.

Вопрос: зачем нужен тогда КЭДО как «легкий СЭД»? Ответ: чтобы вы нажимали кнопку «подписать» не в Abode Reader, а в КЭДО, при этом КЭДО не только вела вас по маршруту далее (если нажато «отказать» – возвращало на стартовую позицию), но, и чтобы было видно «кто подписал» и «на чьей стороне сейчас мячик» (кто еще на нажал «подписать», какой срок подписания и т.п.), т.е. кроме карточки документа добавляется карточка задачи \ согласования (workflow). Если этого не требуется, то задача сильно облегчается, т.к. не требуется функция «управления задачами», т.е. достаточно лишь средство нанесения подписи на документ, например, Abode Reader и его кнопка «подписать».  

Заключение

Как видим, проблемы КЭДО завязаны на криптографию. Сегодняшний юридический «туман» вокруг ЭП как самого механизма подписания (форматы, стандарты, онлайн-проверки), так и «долговременного хранения» (на «далекое» будущее есть законопроект № 1173189-7) почти ничего «не запрещает» (повторюсь, - «сегодня») и дает большое поле вариативности (свободу выбора технических решений). Это приведет к тому, что в спорах в суде будет не состязание логики и прямые ссылки на закон, а состязание ухищрений юристов: да, напрямую закон это не регламентирует, но вот косвенно «так – то и так», и ровно также будет говорить юрист, с другой стороны.        

Однако для большинства заказчиков (тем более продавцов и crowdsourcing - проектировщиков) этот «густой туман» не является стоп-фактором внедрения и число проектов с ЭП быстро растет, особенно КЭДО и HR-систем с кнопкой «подписать», что спровоцировал недавний upgrade Трудового кодекса.

Множество других обсуждений проектных решений, типа УКЭП или УНЭП, ГОСТ (рф-криптография от 94/01/12) или не ГОСТ (международная, RSA), перештамповка («освежает» \ продлевает подпись еще на 15 лет), где хранить подпись (токен \ флешка, win-реестр клиента, доверенное хранилище на сервере), неаккредитованный удостоверяющий центр и другая инфраструктура КЭДО и т.п. – уже в рамках планируемого проекта.

В проекте не рассматриваем:

• «облака» (только on-premise), как коммерческие on-cloud, так и гос-SAAS (сервис «Работа в России»);

• простую ЭП («логин + пароль» - вне периметра \ ИТ-систем компании не подлежит объективному контролю / объективному доказательству).

Общая план-концепция проекта: подготовить проектное решение КЭДО (в идеале Open Source \ Free) или найти почти готовое, например, «легкий СЭД» с кнопкой «подписать» и «допилить» его «под кадры», например, добавив туда формирование xml описания, как это требует приказ МинТруда № 578н. Провести апробацию на реальном внедрении КЭДО, опубликовать отчет и  услышать заветные: Молодец! Возьми с полки пирожок!

Открываем проект? Есть заказчики и разработчики в команду такого проекта?