Кратко

  • RFC 9642 стандартизует YANG-keystore для симметричных и асимметричных ключей, сертификатов, центральных ссылок и inline-определений, но не выдаёт заключение о восстановлении.
  • Перенос шифрованной конфигурации требует замкнуть граф от ciphertext к общему KEK, исходному и целевому первичным ключам, операции перепаковки и её полномочиям.
  • Доказательство завершается у потребителя: выбран правильный объект и сертификат, разрешённая операция выполнена, запрещённая отклонена, результат сервиса наблюдаем.

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

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

RFC 9642 создаёт ietf-keystore, чтобы разные системы одинаково представляли ключи, сертификаты и ссылки. Это минимальная координационная спецификация. Она не может сама подтвердить, что сохранённые отношения действуют в работающем коде.

Совместимый модуль не означает одинаковую поверхность

RFC 9642 опубликован в октябре 2024 года как документ Standards Track. Центральный keystore, inline-определения, асимметричные и симметричные ключи включаются отдельными features. Потребляющий модуль может выбирать между центральной ссылкой и локальным материалом и добавлять иные расположения.

Поэтому квитанция фиксирует revision, feature set, YANG Library, datastore, полный путь, hash и потребителя. Имя элемента уникально только в своём списке; оно не является глобальным идентификатором, доказательством владельца или назначения.

Разрешившаяся leafref подтверждает связь конфигурации. Она не подтверждает, что процесс загрузил ту же версию, не предпочёл inline-вариант и действительно выполнил операцию этим ключом.

System origin — не история происхождения

В архитектуре RFC 8342 встроенные ключи могут появляться в <operational> и <system> с системным происхождением. Ключ мог быть установлен при производстве, создан при первом запуске или при включении службы.

Аннотация отличает значение сервера от обычной записи оператора. Она не доказывает производителя, источник случайности, аппаратную границу, неэкспортируемость, версию firmware или действительность сертификата. Процесс установки и изменения встроенных ключей RFC оставляет реализации.

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

encrypted-by — исполняемая зависимость

Шифрованный объект содержит формат, ciphertext и ссылку на защищающий ключ. Сервер должен иметь KEK или API, использующий его. Иначе байты сохранены, а полномочие недоступно.

Ненормативная схема миграции RFC 9642 шифрует множество ключей общим KEK, который защищён уникальным встроенным первичным ключом сервера. Для новой машины общий KEK перепаковывается под её первичный ключ; остальные ciphertext могут остаться прежними.

Экономия создаёт общий радиус. Потеря KEK блокирует много потребителей, замена меняет их основу, широкое API расширяет власть. Целостность backup не равна замкнутости графа. Нужны все ciphertext, ссылки, первичные ключи, KEK, форматы, алгоритмы, уполномоченный актор, результат перепаковки и rollback.

Диаграмма стандарта не доказывает работу конкретного продукта. Отчёт называет hash backup, исходную и целевую системы, идентичности ключей, согласования и тесты.

Hidden и encrypted имеют узкий смысл

RFC 9640 задаёт используемые формы. Hidden означает, что моделируемая management-поверхность не возвращает секрет; это не универсальная неэкспортируемость через память, консоль, backup или hardware. Encrypted не доказывает защиту и доступность KEK.

RFC 9642 рекомендует шифровать постоянное хранение и обнулять расшифрованные копии в volatile memory после использования. Незашифрованное хранилище должно быть недоступно. YANG-дерево не видит реплики, swap, crash dump, logs и локальные привилегии.

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

NACM — решение на одной границе

Все writable nodes имеют nacm:default-deny-write, а читаемые секреты — более строгий запрет. RFC 8341 даёт механизм, но сама аннотация не хранит сессию, правило и исключение события.

След соединяет NETCONF/RESTCONF identity, channel, версию NACM, matched rule, path, before/after, commit, approval и operational projection. В нём также перечислены local, vendor и hardware пути вне YANG. RFC 6241 и RFC 8040 дают контекст управления, но не полную биографию ключа.

RFC 9642 не определяет RPC/action. Генерация возможна в потребляющих SSH/TLS-моделях или вне сервера. Наличие узла не восстанавливает церемонию и полномочия.

Сертификат и ключ ещё должен выбрать сервис

Асимметричный ключ может иметь несколько сертификатов. Ссылка end-entity выбирает ключ и сертификат. Verified Errata 8441 исправляет скопированный комментарий, ошибочно называвший выбор симметричным; структура всегда была асимметричной парой.

RFC 9644 и RFC 9645 показывают SSH/TLS-потребителей. Квитанция разрешает их ссылку, фиксирует revision, наблюдает подпись, расшифрование или session и связывает результат с объектом.

Модуль не ограничивает private key только подписью или расшифрованием. Сертификат может ограничить публичный ключ; организационное полномочие и фактическая операция остаются отдельными. Тест проверяет успех разрешённого и отказ запрещённого.

Уведомление об истечении не завершает ротацию

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

Цепочка идёт от события к получателю, подтверждению, новому сертификату, соответствию ключа, потребителю, развёртыванию и операции. Расхождения между central и inline сохраняются.

Закрытие квитанции восстановления

Сначала фиксируются backup, источник, modules, features, datastores, origins, fingerprints, formats и все encryption edges. Затем — оба первичных ключа, общий KEK, уполномоченная перепаковка и результат.

На цели проверяется раскрытие необходимых объектов, правильная версия ссылок, сертификат, выбор потребителя, разрешённая операция и отказ запрещённой. Конец — ограниченный service outcome и независимый rollback.

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

Источники