Кратко

  • В редакции 15 проекта UCL допускается несколько экземпляров User-Access-Group-ID в Access-Accept; это означает принадлежность пользователя к нескольким группам.
  • Сам список групп не определяет универсальный порядок разрешений и запретов. Чтобы объяснить итог, система должна сохранить все группы, версию ACL, приоритет и расписание правил, состояние каждого PEP и наблюдение пакета.

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

Система событий была рассчитана на один столбец. Она выбрала первое непустое значение и записала engineer. Через неделю аудит увидел разрешённое соединение и решил, что сработала обычная инженерная политика. На самом деле PEP применил временную роль, а запрет устройства не сработал из-за старой версии ACL.

Удалённые значения не были дубликатами. Они описывали независимые основания политики. Превратив множество в одну строку, платформа потеряла не только детали членства, но и возможность восстановить конфликт, порядок и причину результата.

Редакция 15 документа A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control создаёт модель для таких сценариев. Она расширяет ACL-модель RFC 8519 группами конечных точек, сопоставлением исходной и целевой Group ID и эффективным расписанием ACE. Для доступа, запускаемого аутентификацией, определяется RADIUS-атрибут User-Access-Group-ID.

Документ близок к завершению процесса, но не завершил его. Datatracker показывает рабочую группу OPSAWG, предполагаемый статус Proposed Standard, передачу в IESG и очередь RFC Editor с состоянием финального рассмотрения. Проверка IANA завершена с необходимыми действиями. Редакция 15 датирована 2 апреля 2026 года и истекает 4 октября. Номера RFC пока нет. Этот статус не подтверждает поведение конкретной реализации.

Множество членств — вход, а не итог

В Access-Accept может находиться ноль или больше экземпляров атрибута. Несколько экземпляров означают, что пользователь состоит во многих группах. Это полезно: организационные роли редко образуют идеальную иерархию. Человек может одновременно быть сотрудником, участником проекта, дежурным и пользователем управляемого устройства.

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

Результат зависит от полной ACL, порядка ACE, семантики действий, конкретной реализации и активного расписания. Список групп не является формулой конфликта. Проект не превращает сам факт множественного членства в универсальный allow или deny.

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

Даже политика «запрет сильнее разрешения» требует области. Запрет по устройству может относиться лишь к одному сервису или времени. Глобальное повышение такого правила способно вызвать отказ. Локальная политика допустима; скрытая политика в коде агрегации — нет.

В запросе тот же атрибут имеет другую власть

User-Access-Group-ID может появляться и в Access-Request, но там служит подсказкой или предпочтением. Сервер не обязан её учитывать. Если конвейер объединяет запрос и ответ в одно поле, клиентское пожелание становится похожим на серверную авторизацию.

Минимальная запись сохраняет тип пакета, направление, идентичности RADIUS-клиента и сервера, связь запроса с ответом, все экземпляры атрибута и статус решения. Отсутствие группы в ответе нельзя заполнять значением из запроса ради удобства аналитики.

В Access-Reject и Access-Challenge атрибут не допускается. Он также не допускается в CoA-ACK и CoA-NACK. Отсутствие в этих сообщениях следует правилам размещения и не должно превращаться в новое утверждение о членстве.

Защищённый транспорт важен, но не исправляет ошибку модели данных. Даже аутентифицированный и целостный запрос остаётся запросом, а не решением.

CoA меняет множество во время сессии

Атрибут разрешён в CoA-Request. Сервер может добавить или убрать группы без новой начальной аутентификации. Это создаёт переход, где старое и новое множество какое-то время сосуществуют на разных уровнях.

NAS может уже принять CoA. Контроллер может пересчитать ACL. Один PEP устанавливает новую ревизию, другой ждёт транзакцию, третий недоступен. Пакеты по разным путям получают разные решения.

Состояние нельзя описать одной заменой массива. Нужно сохранить старую и новую авторитетные версии, время решения, ожидаемый набор PEP и состояние каждой доставки. Только после заданного критерия завершения новая версия может считаться полностью действующей.

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

CoA-ответ на уровне протокола не является квитанцией всех внешних точек применения. Он доказывает более узкий шаг. Система не должна расширять его смысл.

Группа должна стать пакетным предикатом

Проект описывает два способа применения. Контроллер может динамически сопоставлять Group ID с IP- и транспортными полями, например пятёркой параметров, и программировать обычные ACL. Либо PEP может понимать группы и самостоятельно связывать входящие пакеты с исходной или целевой группой.

В первом случае членство и правило могут быть правильными, а адресная проекция — устаревшей. Пользователь переподключается, временный IPv6-адрес меняется, NAPT создаёт новые координаты, приложение переезжает. Пока обновление не дошло до всех PEP, старые ACL остаются синтаксически корректными.

Во втором случае нужны аппаратные или программные возможности, а классификация может влиять на производительность. Кроме того, строка Group ID не обязана совпадать с тегом в пакете. Способ её преобразования в поле заголовка или инкапсуляции находится вне рамок проекта.

Следовательно, пакетный тег требует версии таблицы соответствия. Захваченный номер не доказывает группу сам по себе. И наоборот, название группы в конфигурации не доказывает, что dataplane прочитал наблюдаемый тег так же.

Раздел Mapping Consistency требует достаточной настройки и особой осторожности при совместном использовании разных механизмов, включая RADIUS. Это не автоматическая гарантия, а эксплуатационное обязательство.

Расписание меняет конфликт во времени

ACE может иметь effective-schedule: период или повторение по RFC 9922. Без расписания ACE применяется сразу и всегда.

Для нескольких групп это особенно важно. Утром разрешение дежурного может быть активно, а вечером останется лишь базовый запрет. В день исключения временное правило может не включиться. Один и тот же набор членств создаёт разный итог в зависимости от времени.

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

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

Если конфликт групп разрешается по активным ACE, потеря истории расписания разрушает объяснение даже при сохранённых членствах. Через месяц будет видно, какие группы были у пользователя, но не какие правила реально участвовали в 18:01.

Accounting — свидетель со своей точкой наблюдения

В Accounting-Request NAS может передать User-Access-Group-ID, подтверждая получение атрибута и применение политики. Такая запись полезна: она связывает сессию, множество групп и утверждение NAS.

Но NAS не обязательно наблюдает внешний межсетевой экран, фабрику или сервисный шлюз. Он не доказывает версию их mapping, расписания и ACL. Он также не показывает, ответило ли приложение после разрешения пакета.

Правильный аудит сопоставляет источники, не назначая одному универсальный приоритет. AAA говорит, что авторизовал группы A, B, C. NAS говорит, что получил и применяет. Контроллер говорит, какую политику и карту распределил. Каждый PEP сообщает установку и readback. Счётчики и пробы показывают поведение.

Если сведения расходятся, расхождение само является результатом. Нельзя «исправлять» его выбором самого позднего сообщения, потому что сообщения отвечают на разные вопросы.

Счётчик совпадений тоже ограничен. Он может доказать, что часть пакетов попала в ACE, но не что все разрешённые потоки работают или что обходного пути нет. Нужны положительные и отрицательные canary с указанным маршрутом и временем.

Нулевая ошибка схемы не разрешает политику

Datatracker сообщает ноль ошибок и ноль предупреждений YANG Validation для редакции 15. Это доказательство формальной проверки опубликованной модели. Оно не определяет порядок конфликтующих правил у каждого производителя и не подтверждает распределённую активацию.

Изменения между редакциями 14 и 15 преимущественно редакционные: даты, формулировки, раскрытие NVO3, ссылка на опубликованный RFC 9907. Новых результатов внедрения, тестов совместимости или измерений нет.

NETCONF и RESTCONF должны использовать безопасный транспорт и взаимную аутентификацию; NACM ограничивает доступ. Несанкционированная запись списка групп может создать ложную группу или удалить настоящую. Изменение Group-ID match может разрешить запрещённое или запретить разрешённое.

Но авторизованная запись тоже может нести старую политику или неполное множество. Контроль доступа к управлению доказывает, кто мог изменить объект. Он не доказывает правильность решения и результат пакета.

Минимальная квитанция многогруппового решения

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

Второй слой — mapping. Для обычной ACL это поля, источник, версия и срок действия. Для тега — пространство имён, значение и версия соответствия. Для локального классификатора — версия логики и входы.

Третий слой — ACL: ревизия, ACE, порядок, действие, правило конфликта и расписание. Четвёртый — версия целевого набора PEP и возможности каждого устройства. Пятый — отправка, валидация, установка, активация и readback по каждому PEP.

Шестой слой — наблюдение: совпавшая ACE, пакетный счётчик, путь, положительная или отрицательная проба и результат сервиса. Неизвестное сохраняется неизвестным.

Принцип Minimum Initial Specification Хэна Лу здесь означает небольшой общий контракт, а не единую глобальную политику. Сети могут выбирать разные способы разрешения конфликтов, если выбор назван, версионирован и связан с результатом.

Разделение слоёв реальности не позволяет строке заменить действие. Group ID — символ. Авторизация и ACL — решения управления. Активное правило — исполняемое состояние. Пакет и сервис — наблюдаемая реальность. Совпадение имён между слоями не является доказательством перехода.

Running-Code Primacy требует тестировать несколько групп с конфликтом, CoA при недоступном PEP, миграцию приложения, смену адреса и границу расписания. Безопасная система не обязана всегда разрешать доступ; она обязана показать, какой набор правил и какая версия его решила.

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

Sources