ПМИ_ротация_каналов_А.4_v01_draft
А.4 Проверка создания функций маршрутизации запросов в распределённых реестрах
Настоящая методика обеспечивает проверку реализации требований, изложенных в ЧТЗ п. 4.2.4, в соответствии с заявкой Заказчика № ___ (пункт ___/4.2.4/АКК).
Проверки выполняются вызовами методов сервисного чейнкода и наблюдением сервисной базы данных сервисного чейнкода. Во всех шагах проверок действует единственная роль — демонстрирующий; иные роли не предусмотрены. Порядок вызова методов сервисного чейнкода определяется средствами, предоставленными демонстрирующим. Функции доступны в среде развёртывания; IP-адрес среды указывается при подготовке испытаний и приводится в протоколе испытаний (Приложение В).
Предварительные условия: развёрнут тестовый стенд; сервисный чейнкод развёрнут в канале ГУЦ; в сервисной базе данных присутствует запись о реестре; демонстрирующему предоставлены учётные данные для подключения к сервисной базе данных и средства вызова методов сервисного чейнкода; подключение DBeaver выполнено.
А.4.1 Проверка ведения сервисной базы данных сервисного чейнкода
Способ проверки: наблюдение сервисной базы данных.
Проверка подтверждает, что данные о действующих и ротированных каналах доведены до сервисной базы данных. Наблюдением записи о реестре подтверждается её состав: версия сервисного чейнкода, идентификатор участника сети, идентификатор издателя актива, тип актива, системные имена канала и чейнкода, идентификатор реестра и служебные поля времени. Записи о реестрах, полученные при выполнении проверок А.4.2 и А.4.3, служат предметом настоящей проверки.
№ | Шаг | Ожидаемый результат |
1 | Действие: Подключиться к сервисной базе данных сервисного чейнкода (DBeaver) | Подключение установлено; сервисная база данных доступна. |
2 | Действие: Выполнить выборку записи о реестре и проверить её структуру | Запись содержит поля: |
3 | Действие: Проверить значения |
|
[Место для уточнений — согласуется с А.М.: полнота выборки записи (обязательность полей, значения NULL для полей разрешения коллизий); формат даты и времени в полях dateTimeOpened/dateTimeClosed (требование к формату не установлено).]
А.4.2 Проверка регистрации реестра в сервисном чейнкоде
Проверка подтверждает регистрацию нового издателя актива в служебной базе данных: метод регистрации реестра принимает все поля сервисной базы данных, кроме идентификатора реестра, и возвращает идентификатор реестра со значением 0. Зарегистрированный реестр используется далее при ротации канала (проверка А.4.3) и при маршрутизации запросов (проверки А.4.7, А.4.8).
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Метод возвращает идентификатор реестра со значением 0 — зарегистрирован новый издатель актива. |
2 | Действие: Выполнить выборку записи о зарегистрированном реестре | Создана запись, содержащая: |
3 | (альтернативный к шагу 1) Действие: Повторно вызвать метод | Запрос отклонён; повторная запись о реестре не создана. |
[Место для уточнений — согласуется с А.М.: поведение при повторной регистрации того же издателя и код ошибки не определены.]
А.4.3 Проверка ротации канала и доступа к данным ранее созданных каналов
Предварительные условия: реестр зарегистрирован (результат проверки А.4.2); создан новый канал того же назначения, участники присоединены к каналу.
Проверка подтверждает ротацию канала: для нового создаваемого канала идентификатор реестра увеличивается на 1, в сервисной базе данных создаётся отдельная запись о новом реестре, при этом возможность доступа к данным ранее созданных каналов сохраняется. Созданные записи о реестрах используются при проверках А.4.4, А.4.7 и А.4.8.
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Метод возвращает идентификатор реестра, увеличенный на 1 относительно предыдущего значения (не более 31). |
2 | Действие: Выполнить выборку записей сервисной базы данных по идентификатору издателя актива и типу актива | Создана отдельная запись о новом реестре с новым значением |
3 | Действие: Выполнить запрос к активу, размещённому в ранее созданном канале | Запрос выполнен; сведения об активе возвращены (доступ к данным ранее созданных каналов сохранён). |
А.4.4 Проверка вывода канала из эксплуатации и работы канала в «холодном» режиме
Предварительные условия: канал выведен из эксплуатации (заполнен dateTimeClosed); в канале размещён актив, время действия которого не истекло.
Проверка подтверждает работу канала, выведенного из эксплуатации, в «холодном» режиме: в канале возможно чтение информации об активах и запись информации об изменении жизненного цикла активов, в том числе аннулирования сертификата.
№ | Шаг | Ожидаемый результат |
1 | Действие: Выполнить запрос чтения сведений об активе, размещённом в канале с заполненным | Сведения об активе возвращены (чтение информации об активах доступно). |
2 | Действие: Выполнить запись сведений об изменении жизненного цикла актива (например, аннулирование сертификата), размещённого в канале, выведенном из эксплуатации | Запись выполнена; сведения об изменении жизненного цикла актива зафиксированы. |
[Место для уточнений — согласуется с А.М.: перечень исключительных случаев записи в «холодный» канал и негативная ветка (запись нового актива) не определены.]
А.4.5 Проверка формирования идентификатора объекта по данным удостоверяющего центра
Проверка подтверждает формирование идентификатора объекта по значению ОГРН УЦ и его соответствие структуре идентификатора: версия чейнкода, контрольная сумма, глобальность адреса и область действия, тип актива, идентификатор реестра, идентификатор владельца реестра, идентификатор актива. Сформированный идентификатор используется при маршрутизации запросов (проверка А.4.7).
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращён идентификатор объекта (UUID) — 128-битовое значение. |
2 | Действие: Проверить состав идентификатора | Идентификатор содержит: версию чейнкода (для действующей версии — 1 в битовом виде 001); тип актива УЦ (значение 1); идентификатор реестра; идентификатор владельца реестра; идентификатор актива. |
3 | Действие: Повторно вызвать метод с теми же сведениями об УЦ | Возвращён идентификатор, совпадающий с полученным на шаге 1 (формирование идентификатора детерминировано). |
4 | (альтернативный к шагу 3) Действие: Вызвать метод со сведениями об УЦ, ОГРН которого отличается | Возвращён идентификатор, отличный от полученного на шаге 1. |
А.4.6 Проверка формирования идентификатора объекта по данным сертификата и электронной подписи
Проверка подтверждает формирование идентификаторов объектов по данным сертификата и по данным электронной подписи: в первом случае используются хэш серийного номера и Issuer.OGRN (или хэш от поля Issuer), во втором — значение электронной подписи и ОГРН издателя сертификата подписи. Сформированные идентификаторы используются при маршрутизации запросов к соответствующим активам.
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращён идентификатор объекта (UUID); тип актива в идентификаторе соответствует типу актива реестра (КСКПЭП либо НСКПЭП). |
2 | Действие: Вызвать метод | Возвращён идентификатор объекта (UUID); тип актива в идентификаторе — ЭП (значение 4). |
3 | Действие: Проверить, что идентификатор владельца реестра в полученных идентификаторах соответствует издателю актива | Идентификаторы объектов разных издателей различаются значением идентификатора владельца реестра. |
[Место для уточнений — согласуется с А.М.: состав структуры сведений о сертификате и об электронной подписи приведён обобщённо; состав тестовых данных подлежит уточнению.]
А.4.7 Проверка маршрутизации запроса к объекту канала по идентификатору объекта
Предварительные условия: имеются активы, размещённые в действующем и в ранее созданном (ротированном) реестрах (результат проверки А.4.3); идентификаторы объектов сформированы (проверки А.4.5, А.4.6).
Проверка подтверждает маршрутизацию запроса: по идентификатору объекта определяются тип и ключевая дата актива, версия сервисного чейнкода, вычисляется издатель, находится реестр актива для данного издателя и возвращается пара значений «наименование канала + наименование чейнкода».
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращена пара значений: |
2 | Действие: Выполнить запрос к активу, размещённому в действующем реестре | Запрос выполнен в канале, соответствующем действующему реестру актива. |
3 | Действие: Выполнить запрос к активу, размещённому в ранее созданном реестре | Запрос выполнен в канале, соответствующем реестру, в котором размещён актив. |
4 | (альтернативный к шагу 1) Действие: Вызвать метод | Запрос отклонён; реестр для актива не определён. |
[Место для уточнений — согласуется с А.М.: поведение при отсутствии реестра для актива и код ошибки не определены.]
А.4.8 Проверка определения реестра по данным актива
Проверка подтверждает определение реестра по данным актива (формирование идентификатора объекта и его маршрутизация) и подбор всех возможных (по версиям сервисного чейнкода) реестров для данного актива и его издателя. Проверка дополняет проверку А.4.7: в первом случае на вход подаётся идентификатор объекта, во втором — данные актива.
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращена пара значений: |
2 | Действие: Вызвать метод | Возвращён перечень всех возможных (по версиям сервисного чейнкода) реестров для данного актива и его издателя — записи вида |
3 | Действие: Проверить состав перечня, полученного на шаге 2, при наличии нескольких поколений реестров у издателя | Перечень содержит реестры издателя для данного актива по всем версиям сервисного чейнкода; действующий реестр присутствует в перечне. |
А.4.9 Проверка определения типа актива и ключевой даты актива
Проверка подтверждает определение типа актива по данным актива и определение ключевой даты для актива. Полученные значения используются при маршрутизации запроса (проверка А.4.7).
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращено числовое значение типа актива; возвращаемое значение входит в диапазон 0..7 и соответствует типу актива и версии сервисного чейнкода. |
2 | Действие: Вызвать метод | Возвращена ключевая дата актива. |
[Место для уточнений — согласуется с А.М.: расхождение источника (метод GetAssetType: «УЦ, СКПЭП, ЭП», диапазон 0..7) с таблицей типов (1–4); определение ключевой даты по типам активов не задано.]
А.4.10 Проверка определения версии сервисного чейнкода
Проверка подтверждает определение версии сервисного чейнкода — текущей либо актуальной на заданный момент времени. Версия сервисного чейнкода определяет состав признаков типа актива и правила формирования идентификатора объекта.
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращена текущая версия сервисного чейнкода (для действующей версии — 1). |
2 | Действие: Вызвать метод | Возвращена версия сервисного чейнкода, актуальная на заданный момент времени. |
3 | Действие: Сопоставить версию, полученную на шаге 1, со значением поля | Значения совпадают. |
А.4.11 Проверка разрешения коллизий между владельцами реестров
Предварительные условия: подготовлены данные двух издателей актива, идентификаторы владельцев реестров которых совпадают (коллизия).
Проверка подтверждает разрешение коллизий между владельцами реестров: при обнаружении коллизии создаётся дополнительная запись в сервисной базе данных, при маршрутизации выполняется проверка наличия записи о коллизии с последующим уточнением данных по точному значению идентификатора.
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод | Возвращена требуемая добавка к идентификатору издателя актива ( |
2 | Действие: Выполнить выборку сервисной базы данных по идентификатору издателя актива | Создана дополнительная запись, содержащая |
3 | Действие: Вызвать метод маршрутизации для актива владельца, для которого зафиксирована коллизия | Наличие записи о коллизии проверено; данные о записи уточнены по точному значению идентификатора; возвращена пара значений, соответствующая реестру данного владельца. |
А.4.12 Проверка разрешения коллизий между объектами реестра
Предварительные условия: подготовлены данные двух объектов реестра, идентификаторы которых совпадают (коллизия).
Проверка подтверждает разрешение коллизий между объектами реестра: при обнаружении коллизии создаётся дополнительная запись в сервисной базе данных, при маршрутизации выполняется проверка наличия записи о коллизии с последующим уточнением данных по точному значению идентификатора.
№ | Шаг | Ожидаемый результат |
1 | Действие: Вызвать метод маршрутизации для объекта, для которого обнаружена коллизия | Возвращена пара значений, соответствующая реестру объекта; уточнение данных выполнено по уникальному значению, разрешающему коллизию. |
2 | Действие: Выполнить выборку сервисной базы данных по идентификатору объекта, имеющего коллизию | Создана дополнительная запись, содержащая |
3 | Действие: Вызвать метод маршрутизации для второго объекта, идентификатор которого совпал с первым | Возвращена пара значений, соответствующая реестру второго объекта; объекты не смешиваются. |
[Место для уточнений — согласуется с А.М.: способ создания коллизии (тестовые данные) и поведение при неразрешимой коллизии не определены.]
А.4.13 Проверка ограничения количества ротаций канала
Проверка подтверждает ограничение количества ротаций канала, установленное структурой идентификатора объекта: идентификатор реестра занимает 5 бит, значения последовательно увеличиваются на 1 при ротации канала и не превышают 31.
№ | Шаг | Ожидаемый результат |
1 | Действие: Выполнить последовательные ротации канала, фиксируя значения идентификатора реестра | Значения идентификатора реестра последовательно увеличиваются на 1 (от 0 до 31); количество ротаций канала — 32. |
2 | (альтернативный к шагу 1) Действие: Выполнить ротацию канала при достижении максимального значения идентификатора реестра | Запрос отклонён; новое значение идентификатора реестра не присвоено. |
[Место для уточнений — согласуется с А.М.: поведение при исчерпании значений идентификатора реестра не определено; варианты увеличения количества ротаций настоящей проверкой не охватываются.]
А.4.14 Проверка процесса ротации канала
Проверка подтверждает выполнение процесса ротации канала и перевода ранее созданного канала в «холодный» режим в последовательности, предусмотренной ЧТЗ п. 4.2.4.1. Ротация выполняется вручную.
№ | Шаг | Ожидаемый результат |
1 | Действие: Выполнить шаги 1–7 процесса ротации канала (создание канала, присоединение пиров) | Канал создан; пиры участников присоединены к каналу и видимы в канале. |
2 | Действие: Выполнить регистрацию канала в сервисном чейнкоде (шаг 8 процесса) | Канал зарегистрирован; результат соответствует проверке А.4.2. |
3 | Действие: По наступлении времени вывода канала из эксплуатации создать новый канал и обеспечить поддержку старого канала для внесения информации о жизненном цикле действующих активов (шаг 9 процесса) | Новый канал создан; ранее созданный канал принимает информацию о жизненном цикле действующих активов. |
4 | Действие: Перевести старый канал в «холодный» режим по истечении времени жизни всех активов (шаг 10 процесса) | Канал переведён в «холодный» режим; результат соответствует проверке А.4.4. |
[Место для уточнений — согласуется с А.М.: выполняются ли шаги 1–7 в рамках приёмочных испытаний; роли оператора сети и администратора узла в сценарии испытаний; дополнительные идеи проверок — соответствие типов актива при смене версии сервисного чейнкода; контрольная сумма идентификатора объекта при искажении данных актива; периодическая ротация по истечении расчётного времени эксплуатации канала; поведение при недоступности канала, в который маршрутизируется запрос.]