ЧТЗ_ротация_каналов_4.2.4_v01_draft

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

Работы выполняются в соответствии с пунктом ___/4.2.4/АКК Заявки № ___ «Создание функций маршрутизации запросов в распределённых реестрах».

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

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

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

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

• переход на 256-битовую структуру идентификатора объекта (увеличение количества ротаций канала до 228) — подход не является стандартизированным и требует более глубокой проработки;

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

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

• определение фактического времени эксплуатации канала до ротации — устанавливается в рамках нагрузочного тестирования.

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

1. Реализовать функцию регистрации реестра в сервисном чейнкоде, обеспечивающую: приём всех полей сервисной базы данных, кроме идентификатора реестра; присвоение идентификатора реестра (0 — при регистрации нового издателя актива; значение, увеличенное на 1, — при ротации канала, но не более 31); фиксацию момента ввода канала в эксплуатацию.

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

3. Обеспечить расчётные сроки эксплуатации каналов до ротации (таблица 1).

Таблица 1. Расчётное время эксплуатации каналов до ротации

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

2. Обеспечить формирование идентификатора объекта по данным актива: по значению ОГРН УЦ — для сведений об аккредитации удостоверяющего центра; по значению хэша серийного номера и Issuer.OGRN (или хэша от поля Issuer) — для сведений о сертификате; по значению электронной подписи и ОГРН издателя сертификата подписи (или хэша от поля Issuer издателя) — для сведений об электронной подписи.

3. Обеспечить структуру идентификатора объекта — 128-битовый вектор (RFC 9562) с составом полей согласно таблице 3 и соответствием типов актива согласно таблице 4.

4. Реализовать функцию маршрутизации запроса к объекту канала по идентификатору объекта: определение типа и ключевой даты искомого актива, версии сервисного чейнкода; вычисление издателя актива; поиск реестра актива для данного издателя; возврат пары значений «наименование канала + наименование чейнкода».

5. Реализовать функцию определения реестра по данным актива (формирование идентификатора объекта и его маршрутизация) и функцию подбора всех возможных (по версиям сервисного чейнкода) реестров для данного актива и его издателя.

6. Реализовать функцию определения типа актива по данным актива — возврат числового значения в соответствии с версией сервисного чейнкода.

7. Реализовать функцию определения ключевой даты актива по данным актива.

8. Реализовать функцию определения версии сервисного чейнкода — текущей либо актуальной на заданный момент времени.

9. Обеспечить разрешение коллизий между владельцами реестров (issuerID, issuerIDAddon, roundsNum): при обнаружении коллизии создаётся дополнительная запись в сервисной базе данных; при маршрутизации проверяется наличие записи о коллизии, данные о записи уточняются по точному значению идентификатора.

10. Обеспечить разрешение коллизий между объектами реестра (collisionID, uniqueIDForCollision): при обнаружении коллизии создаётся дополнительная запись в сервисной базе данных; при маршрутизации проверяется наличие записи о коллизии, данные о записи уточняются по точному значению идентификатора.

4.2.4.1 Требования к функции ротации каналов

Ротация канала выполняется вручную следующей последовательностью действий (таблица 6).

Таблица 6. Последовательность действий при ротации канала

Ротация канала для активов отражается изменением значения идентификатора реестра: для нового создаваемого канала идентификатор увеличивается на 1. Момент ввода канала в эксплуатацию фиксируется в сервисной базе данных и выступает временем начала периода вносимых в канал активов; момент вывода канала из эксплуатации фиксирует начало работы канала в «холодном» режиме.

Каждому поколению каналов соответствует индекс ротации (0 … N+1): канал ГУЦ (mcc), приватные каналы сертификатов ГУЦ, публичные и приватные каналы квалифицированных и неквалифицированных сертификатов УЦ, канал электронных подписей; системные имена каналов и чейнкодов включают индекс поколения. Сервисный чейнкод (service_cc) развёрнут у каждого участника (ГУЦ, УЦ) и при переходе к очередному поколению каналов переводится на новое поколение.

4.2.4.2 Требования к ведению сервисной базы данных сервисного чейнкода

Таблица 2. Состав сервисной базы данных сервисного чейнкода

Информация о созданном (затем ротируемом) канале указывается в поле registryID с указанием даты dateTimeOpened, выступающей в качестве времени начала периода вносимых активов в канал. Поле dateTimeClosed указывает на время вывода канала из эксплуатации: с этого времени канал принимает только информацию об изменении жизненного цикла активов (до истечения времени их действия), а также работает в «холодном» режиме.

4.2.4.3 Требования к структуре идентификатора объекта и типам актива

Таблица 3. Структура идентификатора объекта

Таблица 4. Соответствие типов актива

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

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

Таблица 5. Количество ротаций канала в случае перераспределения битов

* вероятность отсутствия коллизии определяется согласно схеме «парадокса дней рождений».

Настоящим требованием переход на 256-битовый идентификатор объекта не предусматривается; примерный состав идентификатора объекта увеличенной разрядности приведён в таблице 6 (справочно, вне объёма работ).

Таблица 6. Примерный формат идентификатора объекта увеличенной разрядности (справочно)

4.2.4.4 Требования к методам сервисного чейнкода

Для обеспечения работы с активами в каналах реализуются методы сервисного чейнкода согласно таблице 7 (входные данные — аргументы методов, выходные данные — результаты методов).

Таблица 7. Методы сервисного чейнкода

Разрешение возможных коллизий между владельцами реестров обеспечивается полями issuerID, issuerIDAddon, roundsNum: при обнаружении коллизии создаётся дополнительная запись в сервисную базу данных; при обеспечении маршрутизации производится проверка наличия записи о коллизии в сервисном чейнкоде, после чего данные о записи уточняются по точному значению идентификатора.

Разрешение возможных коллизий между объектами реестра обеспечивается полями collisionID, uniqueIDForCollision: при обнаружении коллизии создаётся дополнительная запись в сервисную базу данных; при обеспечении маршрутизации производится проверка наличия записи о коллизии в сервисном чейнкоде, после чего данные о записи уточняются по точному значению идентификатора.

Сервисный чейнкод содержится в канале ГУЦ.

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

Для работы с активами реализуются методы получения идентификатора объекта по данным актива согласно таблице 8.

Таблица 8. Методы формирования идентификатора объекта по данным актива