Кратко

  • Индивидуальный проект IETF от 27 октября требует указать в передаваемом объекте политики область действия, владельца, автора, язык и текст правила. Проверку права заявленного владельца менять правила в принимающей области документ описывает словом MAY.
  • Подлинная подпись удостоверяет происхождение пакета. Разрешение установить правило в чужой сети должно исходить от принимающей стороны и оставаться привязанным к конкретной редакции, её установке и отзыву.

Откат как способ вернуть чужую власть

Представим, что организация отозвала у поставщика право менять правила своей сети. Новый пакет от поставщика можно отклонить. Но в системе ещё живёт старая редакция, а кнопка «откатить» возвращает её без повторной проверки полномочий. Так право, которое истекло сегодня, тихо возвращается вместе со вчерашним файлом. Вопрос о полномочиях нужно задавать не только при первой доставке политики, но и на каждом переходе её жизненного цикла.

Проект Model for distributed policy sharing предлагает общий YANG-контейнер для отдельного объекта политики. Поля area, language, policy-content, owner и author обязательны; origin и подпись происхождения в примере необязательны. Само правило находится внутри как непрозрачное содержимое. Контейнер помогает перенести метаданные и версию между системами, но не определяет, как целевая машина исполнит Rego или иную политику.

Для сетевого администратора это удобное разделение. Для администрации территории действия оно оставляет главный вопрос открытым. owner указывает того, кого пакет называет ответственным. author называет создателя. Оба значения пришли вместе с самим пакетом. Ни одно не является документом о том, что получатель делегировал этому лицу власть над area. Подпись, описанная в связанном проекте о происхождении данных YANG, подтверждает источник и целостность подписанных данных при корректной проверке. Доверенность на изменение чужой сети выдается отдельно.

У обязательных полей необязательный пограничный контроль

Раздел 6.1 поручает Policy Administration Point, PAP, проверку схемы и управление жизненным циклом. До приема или распространения объекта PAP MAY обратиться к Policy Decision Point и выяснить, вправе ли заявленный владелец или отправитель создавать либо менять политику в указанной области. На схеме следующего раздела «Governance Authorization Check» занимает заметное место внутри PAP. Схема производит впечатление обязательного турникета. Текст оставляет решение об установке турникета местной системе.

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

Одна из авторов в письме рабочему списку NMOP описала будущую демонстрацию между двумя доменами. Один будет получать Rego для принятия решений через OPA, другой — политику на основе RFC 9061, требующую IPsec-туннель между определенными узлами. Так можно показать доставку правил разных языков. Но для оценки власти нужны отдельные результаты: кто разрешил установку в каждом домене, что случилось после отмены разрешения, как отозвали уже действующую редакцию. Письмо объявляет демонстрацию; отчета о ее завершении в нем нет.

IETF Datatracker относит документ к активным индивидуальным Internet-Draft со статусом I-D Exists. Проект прямо называет неопределенность доверия между административными областями: известный источник может не иметь права задавать правила для принимающей стороны. Это утверждение о проектируемом механизме, а не сообщение о конкретном инциденте.

Связать журнал с решением, а не с красивой подписью

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

RFC 2904 дает основу для разделения функций авторизации. Новый проект не задает транспортный протокол. Значит, принимающая сторона должна сама соединить доставку с действующей картой полномочий, прежде чем незнакомый объект станет ее рабочим правилом.

Источники