Журнал подписания помогает восстановить путь документа от загрузки до завершения маршрута. Он показывает, какая версия была отправлена, кто и когда совершал действия, почему процесс остановился и прошла ли проверка подписи. Однако журнал не заменяет сам подписанный файл: доказательную ценность имеет полный комплект данных.
Идентификатор и версия документа
Каждому документу нужен уникальный идентификатор, который не меняется при переименовании файла или перемещении карточки. Для каждой новой редакции создают отдельную версию и фиксируют ее связь с предыдущей.
В журнале сохраняют:
· внутренний идентификатор документа;
· название файла;
· номер версии;
· дату загрузки или формирования;
· автора либо инициатора;
· тип документа;
· размер и формат файла;
· контрольную сумму;
· ссылку на предыдущую редакцию;
· статус актуальности.
Контрольная сумма особенно важна: она позволяет сопоставить событие с конкретным содержимым. Два файла могут называться одинаково, но отличаться одной цифрой. Журнал должен показывать, к какой версии относится подпись.
Если документ формируется системой автоматически, фиксируют шаблон, исходные данные и момент создания итогового файла. После первой подписи содержимое не должно незаметно пересобираться.
Сведения об участниках и полномочиях
Для каждого действия нужно понимать не только имя пользователя, но и его роль. Один человек загружает проект, другой согласует условия, третий имеет право подписать документ от имени организации.
Полезно сохранять:
· идентификатор учетной записи;
· фамилию, имя и отчество либо наименование организации;
· роль в маршруте;
· основание полномочий;
· способ входа и подтверждения личности;
· сведения о представителе;
· реквизиты доверенности или машиночитаемой доверенности;
· данные сертификата электронной подписи;
· результат проверки полномочий на момент подписания.
Персональные данные собирают не по принципу «чем больше, тем лучше», а в объеме, необходимом для процедуры и последующего подтверждения действий. Доступ к ним ограничивают по ролям, а срок хранения связывают с назначением документа и требованиями организации.
Какие события необходимо фиксировать
История подписания документа должна отражать весь маршрут, включая неудачные и отмененные действия. Если хранится только финальная отметка «подписано», невозможно понять, почему процесс занял неделю или какая версия была отклонена.
В журнал включают события:
1. Создание карточки.
2. Загрузку или формирование файла.
3. Изменение реквизитов и маршрута.
4. Отправку приглашений.
5. Доставку и открытие уведомлений.
6. Просмотр документа участником.
7. Согласование или отказ.
8. Наложение электронной подписи.
9. Проверку подписи и сертификата.
10. Отмену, отзыв или истечение маршрута.
11. Замену версии.
12. Завершение процесса.
13. Выгрузку или передачу документа во внешнюю систему.
14. Архивирование и удаление в соответствии с установленными правилами.
Время, подпись и результат проверки
Каждое событие сопровождают датой, временем и указанием часового пояса. Иначе отметки из разных систем сложно выстроить в правильной последовательности. Отдельно различают время сервера, момент действия пользователя и доверенную метку времени, если она применяется.
Для события подписания фиксируют:
· точное время операции;
· идентификатор подписанной версии;
· вид электронной подписи;
· владельца сертификата;
· издателя и серийный номер сертификата;
· срок его действия;
· результат проверки цепочки доверия;
· статус сертификата;
· наличие метки времени;
· результат проверки целостности файла;
· технический идентификатор операции.
Журнал электронного подписания не должен просто сообщать, что кнопка была нажата. Он должен связывать подпись с конкретным файлом и сохранять результат криптографической проверки.
Что фиксировать в маршруте согласования
Когда документ проходит через нескольких участников, журнал должен показывать порядок и условия перехода между этапами. В платформе для подписания https://skb-techno.ru/sup особенно важна связь между маршрутом, версиями и действиями каждой стороны.
Стоит сохранять:
· список участников;
· последовательный или параллельный порядок;
· обязательность каждого шага;
· дату отправки приглашения;
· срок ожидания;
· повторную отправку уведомления;
· делегирование;
· пропуск этапа и его основание;
· изменение состава подписантов;
· итоговый статус маршрута.
Если участника заменили после начала процесса, журнал должен показать, кто внес изменение и почему. Нельзя просто перезаписать фамилию в карточке: иначе история станет недостоверной.
При параллельном подписании фиксируют, что все участники получили одну версию. При последовательном — что после подписи первого лица содержание не изменилось перед передачей следующему.
Требования к целостности журнала
Сам журнал может стать объектом спора, поэтому обычной редактируемой таблицы недостаточно. Записи должны быть защищены от незаметного удаления и исправления.
Для этого применяют:
· разграничение прав доступа;
· неизменяемые или добавочные записи;
· контроль целостности;
· резервное копирование;
· синхронизацию времени;
· регистрацию действий администраторов;
· версионирование настроек;
· периодическую проверку восстановления архива.
Если корректировка технической записи необходима, старое значение не удаляют. Создают новое событие с причиной исправления, автором и временем. Так сохраняется прослеживаемость.
Что выгружать вместе с документом
Для долгосрочного хранения сохраняют исходный файл, подписи, протокол проверки, маршрут, ключевые события, доверенности и метки времени. Архив должен оставаться понятным без доступа к интерфейсу сервиса. Если журнал существует только в личном кабинете, после смены оператора организация может потерять важные доказательства.
Журнал дополняет, но не заменяет подпись. История действий подтверждает контекст: кто получил приглашение, когда открыл файл и какой этап прошел. Но запись «подписано» не равна электронной подписи и не доказывает неизменность документа без соответствующих файлов.
Надежная система связывает четыре элемента:
1. Конкретную версию документа.
2. Электронную подпись.
3. Проверенные полномочия подписанта.
4. Неизменяемую историю событий.
Если хотя бы один элемент потерян, разбирать спор становится сложнее. Например, подпись без журнала подтверждает файл, но не объясняет маршрут, а журнал без подписи показывает действие в интерфейсе, но не обеспечивает криптографическую проверку.
Полный журнал электронного подписания должен помогать ответить на вопросы без догадок: кто действовал, с какой версией, на каком основании, в какой момент и с каким результатом. Именно такая детализация превращает технический лог в полезный инструмент аудита, безопасности и разрешения споров.
