Пункт 5.3 приложения 3 к ПТКЗИ: подлинность и целостность электронных документов

Смысл требования

Пункт 5.3 приложения 3 к ПТКЗИ – практический разбор требования «ЭЦП документов». Пункт 5.3 относится к защите электронных документов, создаваемых, обрабатываемых, передаваемых или хранимых в информационной системе. Его смысл состоит в том, что владелец ИС должен обеспечить возможность подтвердить, кем сформирован или подписан электронный документ, а также убедиться, что после подписания его содержание не было изменено без обнаружения такого изменения.

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

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Обеспечение криптографической защиты информации», пункт 5.3: «обеспечение подлинности и контроля целостности электронных документов в информационной системе (средства электронной цифровой подписи)».

Обязательность применения

По таблице приложения 3 требование пункта 5.3 является обязательным для всех классов типовых ИС. При этом пункт 12 Положения требует формировать ТЗ с учётом используемых технологий и допускает не включать отдельное обязательное требование при отсутствии соответствующего актива или технологии либо при согласовании с ОАЦ обоснованных компенсирующих мер.

Следовательно, наличие в ИС обычных файлов или записей само по себе ещё не доказывает применимость пункта 5.3. Сначала необходимо установить, создаются, принимаются, обрабатываются или хранятся ли в системе электронные документы и используется ли технология ЭЦП. Вывод должен быть зафиксирован в ТЗ, а не сделан устно во время проверки.

Что считать электронным документом в контексте требования

Термин «электронный документ» следует использовать в значении Закона Республики Беларусь № 113-З, а не как синоним любого файла. Электронный документ имеет установленную структуру, реквизиты и форму, позволяющую его восприятие, и связан с применением электронной цифровой подписи в предусмотренных законом случаях.

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

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

База данных, журнал событий, произвольный PDF или кнопка «согласовать» не становятся электронным документом и ЭЦП автоматически. Это определяется законодательной и документированной моделью конкретной ИС.

Подлинность и контроль целостности: практическое различие

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

Если в ИС есть только контрольная сумма файла без связи с подписантом, это может помогать контролю целостности, но не подтверждает подлинность электронного документа. Если есть только учётная запись пользователя и журнал действия “нажал кнопку”, это может подтверждать факт операции в системе, но не всегда заменяет ЭЦП электронного документа. Если есть скан бумажного документа с изображением подписи, это также не равно полноценной электронной цифровой подписи.

Поэтому при проектировании нужно чётко определить, какие документы требуют именно ЭЦП, а какие записи достаточно защищать иными механизмами: журналированием, разграничением доступа, контролем целостности, версионированием или утверждением внутри прикладной системы. Это решение должно быть не устным, а отражённым в ТЗ, ЛПА и описании бизнес-процессов ИС.

Что следует подтвердить при проверке

При проверке пункта 5.3 оценивается не просто наличие кнопки “подписать” в интерфейсе. Проверяющий смотрит, какие электронные документы существуют в ИС, какие из них подлежат подписанию, какие средства ЭЦП применяются, как проверяется подпись, как хранится подписанный документ и что происходит при изменении документа после подписания.

• определён ли перечень электронных документов, создаваемых, принимаемых, обрабатываемых или хранимых в ИС;
• установлено ли, какие документы подлежат подписанию ЭЦП и на каком этапе жизненного цикла;
• закреплены ли правила применения ЭЦП в ТЗ, ЛПА, регламенте электронного документооборота, инструкции пользователя или инструкции администратора;
• используются ли средства электронной цифровой подписи, допустимые для соответствующего сценария применения;
• реализована ли проверка подписи при получении, открытии, обработке, хранении или архивировании документа;
• обнаруживается ли изменение подписанного документа после наложения ЭЦП;
• определён ли порядок действий при недействительной подписи, истёкшем или отозванном сертификате, ошибке проверки, компрометации ключа или споре о подлинности;
• обеспечено ли хранение подписанного документа вместе с необходимыми данными для последующей проверки подписи;
• понятно ли, кто имеет право подписывать документы и каким образом это связано с полномочиями пользователя в ИС;
• ведутся ли журналы операций подписания, проверки подписи, отказов проверки и административных действий со средствами ЭЦП.

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

Варианты реализации

Организационный вариант.

Владелец ИС определяет перечень электронных документов, роли подписантов, основания подписания, порядок проверки подписи и действия при ошибках. Такой вариант необходим как правовая и процессная основа, но сам по себе не закрывает требование, поскольку пункт 5.3 прямо указывает на средства электронной цифровой подписи. Документы должны задавать порядок, а техническая реализация должна обеспечивать фактическое подписание и проверку.

Подписание документов в прикладной системе.

В этом варианте функция ЭЦП встроена в прикладное ПО. Пользователь подписывает документ непосредственно в бизнес-процессе, а система сохраняет подписанный объект, сведения о сертификате, статус проверки и результат контроля целостности. Такой подход удобен для медицинских, финансовых, государственных, кадровых, договорных и иных систем, где электронные документы создаются внутри ИС.

Подписание файлов и контейнеров вне прикладной системы.

Такой вариант подходит, если ИС хранит или передаёт документы как файлы: PDF, XML, архивы, отчёты, выгрузки, пакеты обмена. Подписание выполняется внешним средством ЭЦП, после чего в ИС помещается подписанный файл или файл вместе с отделённой подписью. Важно, чтобы ИС сохраняла связь между документом и подписью и позволяла проверить её в дальнейшем.

Интеграция с удостоверяющей инфраструктурой.

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

Комбинированный вариант.

Наиболее устойчивый вариант для сложных ИС. Внутренние документы определяют, какие документы подписываются и кем; прикладная система обеспечивает подписание и проверку; средства ЭЦП обеспечивают криптографическую часть; журналы фиксируют операции; архив хранит документы в форме, пригодной для последующей проверки. Такой подход лучше всего выдерживает проверку, потому что связывает бизнес-процесс, юридическую значимость и технический механизм защиты.

Что целесообразно закрепить в ТЗ, ЛПА и ОРД

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

Для пункта 5.3 документы должны описывать не общую фразу “используется ЭЦП”, а конкретный порядок обращения с электронными документами. Проверяющему должно быть понятно, какие документы подписываются, кто их подписывает, каким средством, как проверяется подпись и как сохраняется возможность доказать подлинность и целостность спустя время.

• перечень электронных документов, создаваемых, принимаемых, обрабатываемых и хранимых в ИС;
• перечень документов, для которых требуется ЭЦП;
• роли и должностные лица, имеющие право подписывать конкретные виды документов;
• порядок наложения ЭЦП и этап бизнес-процесса, на котором документ подписывается;
• порядок проверки ЭЦП при получении, открытии, обработке, передаче и архивировании документа;
• порядок хранения подписанных документов, подписей, сертификатов и сведений, необходимых для проверки;
• порядок действий при недействительной подписи, ошибке проверки, отзыве сертификата, истечении срока действия сертификата или компрометации ключа;
• порядок разграничения доступа к операциям подписания и проверки;
• порядок журналирования операций с ЭЦП;
• ответственных лиц за сопровождение средств ЭЦП и контроль корректности их применения.

Если ИС создаётся или дорабатывается, требования к ЭЦП следует включать уже в техническое задание. Позднее добавление подписи в готовый процесс часто приводит к техническим компромиссам: подпись применяется не к тому объекту, не на том этапе, не сохраняет доказательную силу или не проверяется при последующем использовании документа.

Возможность технической реализации и инструменты

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

• Средства выработки и проверки ЭЦП. Применяются с учётом требований законодательства, ТЗ и допустимости использования в конкретной ИС.
• Криптографические носители и средства защиты личных ключей. Поддерживают выполнение пункта 5.5 и предотвращают использование ключа посторонним лицом.
• Сертификаты открытых ключей. Используются для связи открытого ключа с владельцем и проверки действительности подписи.
• Прикладная интеграция. Система должна подписывать именно окончательный документ или однозначно определённый набор данных и не позволять изменять их без нарушения подписи.
• Долговременное хранение. Подписанный документ, подпись, сертификат и сведения о проверке должны сохраняться связанно в течение установленного срока.

Скан подписи, пароль пользователя, запись в журнале или обычная контрольная сумма не являются заменой ЭЦП по пункту 5.3.

Типичные ошибки при реализации

• изображение рукописной подписи ошибочно считается электронной цифровой подписью;
• система фиксирует только факт нажатия кнопки “согласовать”, но не формирует ЭЦП электронного документа;
• не определён перечень документов, подлежащих подписанию;
• подписывается не итоговая версия документа, а промежуточный файл или часть данных;
• после подписания документ можно изменить без нарушения статуса подписи;
• при загрузке подписанного документа ИС не проверяет ЭЦП и статус сертификата;
• подписанный документ хранится отдельно от подписи, и связь между ними теряется;
• не определён порядок действий при отзыве сертификата, истечении срока его действия или компрометации ключа;
• личные ключи подписантов хранятся в небезопасном виде или используются несколькими лицами;
• операции подписания и проверки ЭЦП не журналируются;
• ЭЦП внедрена технически, но не отражена в ТЗ, ЛПА, регламенте электронного документооборота и инструкциях пользователей.

Вывод

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

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

Связанные материалы

• Защита личных ключей ЭЦП
• Издание сертификатов открытых ключей проверки ЭЦП
• Полномочное управление учётными записями

Нормативная основа

• Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 – приложение 3, пункт 5.3; пункт 12 о зависимости требований от используемых технологий; пункт 13 о регламентации применения технологии ЭЦП. Официальный текст
• Закон Республики Беларусь от 28.12.2009 № 113-З «Об электронном документе и электронной цифровой подписи» – определения электронного документа, ЭЦП, подлинности и целостности электронного документа. Официальный текст