ЧАСТНОЕ ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Реквизит

Значение

Предмет работ

Функции распределённых реестров аккредитации удостоверяющих центров

Направление работ

___

Шифр темы

ИЭП-2025-5

Обозначение документа

ПроКСи_ИЭП-2025-5_РРОИОК_АКК_ЧТЗ (версия 02)

Отчётный период

___

Листов

___

Аннотация

Настоящий документ представляет собой частное техническое задание (далее — ЧТЗ) на выполнение работ по созданию функций распределённых реестров объектов инфраструктуры открытых ключей. Работы выполняются по заявкам Заказчика.

Содержание

Термины и сокращения

(Заготовка: состав терминов — из Заявки и ТЗ; определения подлежат согласованию с Заказчиком.)

Термин / Сокращение

Определение

ГУЦ

Головной удостоверяющий центр

УЦ

Удостоверяющий центр

ТЗ

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

Ведение данных (сопровождение данных)

Деятельность по обеспечению соответствия данных источнику (создать-обновить-прочесть)

СКПЭП

Сертификат ключа проверки электронной подписи

УКЭП

Усиленная квалифицированная ЭП

ЭП

Электронная подпись

чейнкод

Программа, исполняющая бизнес-логику в канале распределённого реестра

канал

Логическая подсеть распределённого реестра; активы реестра размещаются в каналах

REST API

Программный интерфейс доступа к функции регистрации

MSPID

Идентификатор участника сети

глобальное состояние

(world state) Специализированная БД, глобальное состояние распределённого реестра

журнал транзакций

Журнал транзакций распределённого реестра

RFC 3339

Стандарт представления даты и времени; по требованию ЧТЗ, значения указываются в формате RFC 3339, время — UTC, без долей секунды

1 Общие сведения

Приведены в разделе 1 ТЗ.

Соответствие видов работ: выполняемые работы соответствуют ОКПД 2: 62.01.11.000 и п. ТЗ 1.7.

2 Назначение и цели выполнения работ

Приведены в разделе 2 ТЗ.

3 Характеристики объекта автоматизации

Приведены в разделе 3 ТЗ.

4 Требования к Системам

4.1 Общие требования

Приведены в пп. 4.1.1–4.1.4 ТЗ.

4.2 Требования к проводимым работам

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

4.2.1 Создание распределённых реестров данных об аккредитации удостоверяющих центров

4.2.1.1 Ведение сведений об УЦ и их аккредитации

Работы выполняются в соответствии с пунктом ИЭП-1/4.2.1.1/АКК Заявки № ИЭП-1 «Функция регистрации в распределённых реестрах данных об аккредитации удостоверяющих центров».

Назначение работ. В соответствии с Техническим заданием на выполнение работ по развитию инфраструктуры, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме (далее — ТЗ), обеспечивается развитие инфраструктуры на базе технологии распределённых реестров на платформе ИС ГУЦ. Назначение и цели выполнения работ приведены в разделе 2 ТЗ. Сведения об аккредитации удостоверяющих центров и сведения о средствах электронной подписи и удостоверяющих центрах относятся к активам инфраструктуры открытых ключей. Ведение сведений об аккредитации удостоверяющих центров в распределённом реестре обеспечивает достоверную фиксацию статуса аккредитации каждого удостоверяющего центра и возможность проверки этого статуса на любой момент времени в прошлом, в том числе для признания действительности квалифицированных сертификатов, выданных аккредитованными удостоверяющими центрами, а также связанных усиленных электронных подписей.

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

Границы требования. В рамках реализации требования не предусмотрено:

  • ведение сведений о сертификатах ключей проверки электронных подписей, выдаваемых удостоверяющими центрами;

  • ведение сведений, не относящихся к удостоверяющим центрам и их аккредитации.

Требования к функциям. В рамках данного требования необходимо:

  1. Реализовать ведение записи удостоверяющего центра, содержащей сведения: ОГРН и ИНН удостоверяющего центра, полное наименование, адрес расположения, сайт, адрес электронной почты, контактный телефон, сведения о применяемых программно-аппаратных комплексах (псевдоним ПАК, средство УЦ, класс средств электронной подписи, срок действия закрытого ключа).

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

  3. Реализовать ведение записи об аккредитации удостоверяющего центра, содержащей сведения: дату начала аккредитации, дату окончания действия аккредитации, статус (предоставлена, прекращена, приостановлена, возобновлена, аннулирована), причину изменения статуса и ссылку на решение об изменении статуса.

  4. Обеспечить хранение истории аккредитации, включая сведения об отменённых событиях (признак отмены, время отмены, хэш запроса на отмену события).

  5. Обеспечить форматно-логический контроль поступающих данных: проверку корректности ОГРН и ИНН по установленным алгоритмам, представление даты и времени в формате RFC 3339, время — UTC, без долей секунды, ограничение длин значений полей.

  6. Обеспечить формирование идентификаторов записей единым механизмом и автоматическое ведение служебных сведений (версия записи, время внесения сведений в реестр, время обновления записи в реестре).

Требования к реализации функции ведения записей в базе глобального состояния.

Для обеспечения хранения сведений об удостоверяющих центрах и их аккредитации необходимо реализовать ведение в базе глобального состояния записей следующих видов:

  • запись «Удостоверяющий центр» — актуальные сведения об удостоверяющем центре;

  • запись «История изменения данных удостоверяющего центра» — версии сведений об удостоверяющем центре после их изменения и дополнения;

  • запись «Аккредитация удостоверяющего центра» — актуальные сведения об аккредитации удостоверяющего центра;

  • запись «История аккредитации удостоверяющего центра» — события жизненного цикла аккредитации.

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

4.2.1.2 Взаимодействие с внешними информационными системами

Работы выполняются в соответствии с пунктом ИЭП-1/4.2.1.11/АКК Заявки № ИЭП-1 «Функция взаимодействия с внешними информационными системами в части получения и передачи данных об аккредитации удостоверяющих центров».

Назначение работ. Аккредитация удостоверяющих центров и изменение её статуса осуществляются оператором ИС ГУЦ — федеральным органом исполнительной власти, уполномоченным в сфере использования электронной подписи; статусы аккредитации удостоверяющих центров относятся к активам инфраструктуры открытых ключей, регистрируемым в распределённых реестрах. Достоверная фиксация событий жизненного цикла аккредитации (предоставление, приостановление, возобновление, прекращение, аннулирование) обеспечивает возможность предоставления сведений о статусе аккредитации на любой момент времени в прошлом — условие признания действительности квалифицированной электронной подписи (статья 11 Закона № 63-ФЗ) и основу автоматизированного контроля (надзора) в сфере электронной подписи. Выполнение работ предусмотрено п. 4.2.1.11 ТЗ (создание функции взаимодействия с внешними информационными системами).

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

Границы требования. В рамках реализации требований не предусмотрено:

  • предоставление сведений об аккредитации удостоверяющих центров внешним потребителям (выполняется в рамках отдельной заявки);

  • ведение сведений о сертификатах ключей проверки электронных подписей, выдаваемых удостоверяющими центрами.

Требования к функциям. В рамках данного требования необходимо:

  1. Реализовать функцию регистрации нового удостоверяющего центра, обеспечивающую:

    • приём сведений об удостоверяющем центре: ОГРН, ИНН, полное наименование, адрес расположения;

    • форматно-логический контроль поступающих данных, в том числе проверку корректности ОГРН и ИНН по установленным алгоритмам, с отказом в регистрации и возвратом кода ошибки при несоответствии;

    • отказ в регистрации с возвратом кода ошибки, если сведения об удостоверяющем центре уже находятся в реестре.

Обоснование: постановка удостоверяющего центра на учёт в реестре — отправная точка жизненного цикла его аккредитации; внесение сведений с некорректными ОГРН и ИНН либо повторная регистрация не допускаются. Допускается первичная постановка УЦ на учёт в реестре, с неполными данными и их последующим обогащением.

  1. Реализовать функцию изменения сведений об удостоверяющем центре, обеспечивающую:

    • приём изменённых сведений (не менее одного из: полное наименование, адрес расположения) с указанием даты и времени начала действия изменения, причины изменения и ссылки на решение об изменении сведений;

    • контроль целостности запроса, обеспечивающий отказ от повторной обработки одного и того же изменения.

Обоснование: сведения об удостоверяющем центре изменяются при изменении его реквизитов; каждое изменение фиксируется с датой и временем начала действия, повторная обработка одного и того же изменения не допускается.

  1. Реализовать функцию дополнения сведений об удостоверяющем центре, обеспечивающую:

    • приём дополнительных сведений (не менее одного из: сайт, адрес электронной почты, контактный телефон, сведения о программно-аппаратных комплексах);

    • контроль полноты сведений о программно-аппаратном комплексе: в случае заполнения хотя бы одного из полей (псевдоним ПАК, средство УЦ, класс средств электронной подписи) остальные поля также должны быть заполнены;

    • контроль целостности запроса, обеспечивающий отказ от повторной обработки одного и того же дополнения.

Обоснование: сведения дополняются по мере появления информации о средствах электронной подписи и контактных данных; сведения о программно-аппаратных комплексах должны быть полными, повторная обработка одного и того же дополнения не допускается.

  1. Реализовать функцию создания аккредитации удостоверяющего центра, обеспечивающую:

    • приём сведений: дата и время начала аккредитации, дата и время окончания действия аккредитации, причина, ссылка на решение;

    • установление аккредитации статуса «предоставлена»;

    • отказ с возвратом кода ошибки, если период аккредитации совпадает с периодом действующей аккредитации удостоверяющего центра.

Обоснование: предоставление аккредитации — основание для выдачи удостоверяющим центром квалифицированных сертификатов ключей проверки электронных подписей; период предоставляемой аккредитации не должен совпадать с действующим.

  1. Реализовать функцию изменения статуса аккредитации удостоверяющего центра, обеспечивающую:

    • приём нового статуса с указанием даты и времени начала действия изменения, причины и ссылки на решение;

    • проверку допустимости изменения статуса по статусной модели с отказом и возвратом кода ошибки при недопустимом изменении;

    • при аннулировании аккредитации — установление даты и времени начала действия изменения равными дате начала аккредитации.

Обоснование: приостановление, возобновление, прекращение и аннулирование аккредитации — действующие сценарии управления аккредитацией со стороны оператора ИС ГУЦ; недопустимые изменения статуса должны отклоняться, нарушения процессов изменения статуса выявляются автоматическим контролем (надзором) в сфере электронной подписи.

  1. Реализовать функцию отмены события, обеспечивающую:

    • отмену последнего неотменённого события аккредитации удостоверяющего центра;

    • запрет отмены события предоставления аккредитации;

    • возврат к предыдущему состоянию аккредитации при отмене;

    • фиксацию признака отмены, времени отмены и хэша запроса на отмену;

    • контроль уникальности запроса на отмену, обеспечивающий отказ от повторной обработки одного и того же запроса.

Обоснование: ошибочно внесённое событие аккредитации должно быть отменено с возвратом к предыдущему состоянию; событие предоставления аккредитации отмене не подлежит, повторная обработка одного и того же запроса на отмену не допускается.

Требования к реализации статусной модели изменения состояния аккредитации.

  1. Аккредитация удостоверяющего центра может находиться в одном из следующих состояний: «предоставлена», «прекращена», «приостановлена», «возобновлена», «аннулирована».

  2. Допустимы следующие изменения состояния аккредитации:

    • «предоставлена» → «приостановлена», «прекращена», «аннулирована»;

    • «приостановлена» → «возобновлена», «прекращена», «аннулирована»;

    • «возобновлена» → «приостановлена», «прекращена», «аннулирована»;

    • «прекращена» → «аннулирована».

  3. Изменения состояния, не указанные в пункте 2, должны отклоняться с возвратом кода ошибки.

4.2.1.3 Представления данных об аккредитации УЦ

Работы выполняются в соответствии с пунктом ИЭП-1/4.2.1.5/АКК Заявки № ИЭП-1 «Функция формирования представления данных об аккредитации удостоверяющих центров».

Назначение работ. Сведения об аккредитации удостоверяющих центров должны предоставляться внешним потребителям по запросу, в том числе о статусе аккредитации на любой момент времени в прошлом. Возможность получить историю аккредитации, периоды её действия и статус на заданную дату необходима для признания действительности квалифицированной электронной подписи (статья 11 Закона № 63-ФЗ), а массовая выборка сведений по заданным фильтрам — для внешних информационных систем и автоматизированного контроля (надзора) в сфере электронной подписи. Выполнение работ предусмотрено п. 4.2.1.5 ТЗ (создание новой функции обработки данных).

Целевая модель. В рамках данной заявки необходимо обеспечить формирование и предоставление через программный интерфейс (REST API) представлений данных об аккредитации удостоверяющих центров: истории аккредитации, периодов действия аккредитации, статуса аккредитации на заданную дату и выборок по заданным фильтрам.

Границы требования. В рамках реализации требований не предусмотрено:

  • изменение сведений реестра по результатам запросов — функции только чтения (внесение сведений выполняется в рамках отдельной заявки);

  • предоставление сведений о сертификатах ключей проверки электронных подписей, выдаваемых удостоверяющими центрами.

Требования к функциям. В рамках данного требования необходимо:

  1. Реализовать функцию получения истории аккредитации удостоверяющего центра, обеспечивающую:

    • приём запроса с идентификатором удостоверяющего центра (ОГРН);

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

    • отказ с возвратом кода ошибки при отсутствии удостоверяющего центра в реестре либо записей об аккредитации.

Обоснование: полная история событий аккредитации — требуется для подробного анализа и проверки всех событий статуса аккредитации УЦ в прошлом.

  1. Реализовать функцию получения периодов действия аккредитации удостоверяющего центра, обеспечивающую:

    • приём запроса с идентификатором удостоверяющего центра (ОГРН);

    • вычисление периодов, в течение которых аккредитация действовала, с учётом отменённых событий;

    • возврат перечня периодов с указанием даты и времени начала и окончания каждого периода.

Обоснование: периоды действия аккредитации позволяют потребителям установить, действовала ли аккредитация на интересующий момент, без обработки полной истории событий.

  1. Реализовать функцию получения статуса аккредитации на заданную дату, обеспечивающую:

    • приём запроса с идентификатором удостоверяющего центра (ОГРН) и моментом проверки;

    • определение статуса аккредитации на указанный момент с учётом отменённых событий;

    • возврат признака действия аккредитации на указанный момент (действует / не действует);

    • отказ с возвратом кода ошибки, если момент проверки раньше даты начала аккредитации.

Обоснование: проверка статуса аккредитации на момент подписания — условие признания действительности квалифицированной электронной подписи (статья 11 Закона № 63-ФЗ).

  1. Реализовать функцию получения сведений по фильтру, обеспечивающую:

    • приём параметров фильтрации: статус аккредитации; период по дате и времени окончания действия аккредитации; период по дате и времени начала аккредитации; период по дате и времени обновления сведений об аккредитации; период по дате и времени обновления сведений об удостоверяющем центре; комбинации статуса аккредитации с каждым из указанных периодов;

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

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

Обоснование: массовая выборка сведений по фильтрам обеспечивает использование данных реестра внешними информационными системами и автоматизированным контролем (надзором) без обработки полной истории.

4.2.2 Создание распределённых реестров данных о сертификатах УКЭП и событиях жизненного цикла сертификатов УКЭП

4.2.3 Создание распределённых реестров данных о сертификатах УНЭП и событиях жизненного цикла сертификатов УНЭП

4.2.4 Создание функций маршрутизации запросов в распределённых реестрах

4.3 Требования к видам обеспечения

Приведены в разделе 4.3 ТЗ.

5 Порядок контроля и приемки работ

Приведены в разделе 5 ТЗ.

6 Требования к документированию

Приведены в разделе 6 ТЗ.

7 Требования к подготовке разработанной функциональности к вводу в действие

Приведены в разделе 7 ТЗ.

8 Требования к предоставлению гарантии качества работ

Приведены в разделе 8 ТЗ.