Пункт 5.7 приложения 3 к ПТКЗИ: издание сертификатов открытых ключей ЭЦП

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

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

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

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

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

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

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

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

Практическая трактовка требования

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

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

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

Удостоверяющий центр и регистрационный центр: что важно не перепутать

В скобках к пункту 5.7 перечислены удостоверяющий центр, регистрационный центр при его наличии и средства электронной цифровой подписи. Этот перечень нельзя читать как утверждение, что удостоверяющий и регистрационный центры сами по себе являются средствами защиты информации. УЦ и РЦ – организационные и инфраструктурные участники процесса издания сертификатов; средства ЭЦП – технические средства, используемые в соответствующих операциях.

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

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

Что именно должно быть организовано

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Файл сертификата, размещённый на рабочем месте, не закрывает требование, если ИС не проверяет его действительность, не учитывает отзыв и не связывает сертификат с полномочиями владельца.

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

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

Вывод

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

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

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

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

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

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