Как сохранить версию и журнал операций при ревизии отчёта с электронной подписью?

Что делать при ревизии отчёта с электронной подписью?

Не изменяйте подписанный файл. Откройте новую ревизию с обоснованием изменения; сохраните предыдущую подписанную версию, её хеш-значение и подтверждения проверки. Проведите новую версию через повторное техническое утверждение и подпишите её, а связь между двумя версиями зафиксируйте в следе операций.

Так актуальный отчёт легко находится, а старая копия не исчезает незаметно и не выглядит как новая версия. Электронная подпись подтверждает целостность подписанной версии. При изменении содержимого вместо переноса старой подписи на новый файл требуется новый цикл подписания.

В какой структуре сохраняется запись о ревизии?

Краткий ответ: под неизменным идентификатором отчёта каждая опубликованная версия должна быть отдельным неизменяемым объектом; версии должны связываться между собой связями «предыдущая» и «заменяющая».

ISO/IEC 17020:2026 — актуальное издание, вводящее для инспекционных организаций новые положения о контроле данных и информации. Его программный эквивалент — не хранение одного лишь файла отчёта, а контролируемое сопровождение порождающих его связей записей, решений, доступа и версий. Применимые организацией требования следует дополнительно оценивать с учётом её охвата и плана перехода.

Какие события должен фиксировать след операций?

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

• Открытие запроса на ревизию, его обоснование и исходная запись
• Создание черновика и поля, перенесённые из предыдущей версии
• Изменения полей и вложений; безопасные ссылки на прежнее и новое значения
• Техническая проверка, возврат, утверждение и контроль разделения обязанностей
• Хеш-значение файла, представленного на подписание, и результат операции подписи
• Сертификат, статус отзыва, метка времени и результат применённой политики проверки
• Публикация, видимость на портале, загрузка и события внешней рассылки
• Переход старой версии в статус «опубликована новая замещающая ревизия»

След операций должен содержать поля пользователя приложения, достоверного времени, типа события, идентификатора объекта, результата и обоснования. Права администратора не должны давать возможность молча переписывать историю; запись журнала, требующая корректировки, должна объясняться новой встречной записью. Для событий с персональными данными доступ ограничивается ролью и необходимостью.

Как проверяются старая и новая подписи?

Каждая версия должна проверяться независимо. Даже если подпись старой версии действительна, это не означает, что версия всё ещё актуальна; актуальность новой версии также не отменяет подтверждение старой подписи.

BTK разъясняет, что безопасная электронная подпись позволяет определить, вносились ли изменения в подписанные данные после подписания; проверяющая сторона должна проверить квалифицированный сертификат, срок действия или статус отзыва и ограничения использования. ETSI EN 319 102-1 V1.4.1 описывает процесс проверки, а ETSI TS 119 102-2 V1.4.1 — структурированное отчётирование результата проверки. Результат внедрения должен как минимум разделяться на действительна, недействительна и неопределённо/отсутствует подтверждение ; сбой службы не должен считаться успехом.

1. Сопоставляются хеш-значение запрошенной версии и контейнер подписи.
2. Оцениваются целостность подписи, цепочка сертификатов, статус на момент подписания и ограничения использования.
3. При наличии проверяются метка времени и подтверждения долгосрочной проверки.
4. Результат связывается с записью версии вместе со временем проверки, политикой/версией и описанием ошибки.
5. Отдельное бизнес-правило определяет статус: актуальна, замещена, отозвана или черновик.

Что защищают метка времени и архивный пакет?

Метка времени помогает доказать существование электронных данных до определённого момента; сама по себе она не является управлением версиями или архивом. Для проверки в будущем должны совместно сохраняться подписанный файл, цепочка сертификатов, подтверждение статуса отзыва, метка времени, отчёт о проверке и применённая политика.

Руководство BTK по профилям использования электронной подписи разграничивает формы электронной подписи с данными проверки, долгосрочной и архивной. Архивная стратегия должна рассматривать и продление подтверждений при устаревании криптографических методов или политики как документируемую операцию. Продление не изменяет содержимое старого отчёта; оно добавляет к существующему пакету подтверждений новое, датированное подтверждение защиты.

Как показывать старую версию на портале и в рассылке?

Актуальная ревизия должна выдвигаться на первый план; старая версия должна оставаться доступной для уполномоченного пользователя и явно показывать статус «опубликована новая замещающая ревизия».

• Старый URL или запись проверки не должны молча отдавать новый файл для загрузки.
• Пользователю должны показываться идентификатор отчёта, ревизия, дата публикации и статус актуальности.
• Следует давать безопасную ссылку на актуальную версию; конфиденциальное обоснование изменения не должно раскрываться всем.
• Если для получателей старой копии требуется информирование или отзыв, создаётся задача по каждому получателю.
• Сбой рассылки не должен закрываться как выполненная отправка.

Для полей общедоступного вида проверки обратитесь к руководству по странице QR-проверки отчёта можете изучить.

Как выстроить полномочия и безопасность персональных данных?

Полномочия на открытие ревизии, изменение содержимого, техническое утверждение, подписание, публикацию и доступ к истории должны связываться с отдельными ролями. KVKK требует предотвращать неправомерный доступ к персональным данным и предусматривать технические и административные меры для их защиты; вместо единой модели безопасности требуются меры, соответствующие рискам работы и данных.

Поэтому след операций не должен быть файлом, доступным каждому для чтения. Матрица полномочий, строгая аутентификация, журнал доступа, неизменяемые резервные копии, тест восстановления и процедура расследования инцидентов должны работать вместе. Срок хранения должен определяться типом отчёта, договором, применимым законодательством и целью обработки данных и не должен считаться универсальным и бессрочным.

Какие сценарии стоит испытать в пилоте VizyonTech?

Решение Vizyon Periyodik при оценке испытайте в одной группе отчётов наряду с обычной ревизией и негативные сценарии. Критерий успеха — не просто создание нового PDF, а способность системы предотвратить публикацию неверной версии и закрытие без полного набора подтверждений.

1. Попробуйте изменить подписанный файл на месте; система должна требовать открытия новой ревизии.
2. Отправьте на утверждение без обоснования изменения; поток должен закрыться.
3. Измените хеш файла перед подписанием; операция подписи должна быть отменена.
4. Проверьте результат проверки при недоступном статусе сертификата; результат должен оставаться неопределённым.
5. Откройте страницу проверки старой ревизии; должно быть видно, что она неактуальна, и связь с новой версией.
6. Отслеживайте задачу уведомления по разосланной старой копии и подтверждение доставки.

Более широкий взгляд на согласование и электронную подпись даёт руководство по цифровизации процесса периодического контроля , с которым также можно ознакомиться.