Кратко

  • В RFC 1447 строка доступа индексировалась целевой стороной, стороной-субъектом и контекстом ресурсов; разрешённые классы PDU хранились отдельно.
  • Известный источник и успешная аутентификация оставались входами локального решения при приёме, а не переносимым правом на любую операцию.
  • Позднейший VACM сменил архитектуру, но сохранил связь principal, контекста, условий безопасности, типа представления и отдельного объекта.

Имя открывало запись, а не все двери

Party MIB вошла в исходный комплект SNMPv2, опубликованный в апреле 1993 года. Party означала концептуальную среду исполнения, чьи возможности администрация ограничила частью операций SNMPv2-сущности. Это не было простым синонимом человека или организации.

Одна сущность могла реализовывать несколько сторон с пересекающимися или раздельными полномочиями. Она могла знать удалённую сторону, не исполняя её локально. Идентификатор выбирал административную запись, но не нёс универсальную роль администратора.

RFC 1447 представил это ограничение таблицей aclTable. Индекс строки включал aclTarget, aclSubject и aclResources. Target называл сторону, у которой просили выполнение; subject — сторону, которая просила; resources — контекст SNMPv2 с управляемыми ресурсами.

Лишь затем aclPrivileges определял разрешённые классы сообщений. Полномочие принадлежало направленному отношению, а не субъекту отдельно.

Число кодировало глаголы, а не статус

Классы PDU складывались: Get 1, GetNext 2, Response 4, Set 8, GetBulk 32, Inform 64 и SNMPv2-Trap 128. Ноль означал пустое множество. Значение по умолчанию 35 объединяло Get, GetNext и GetBulk.

Это не шкала доверия. 43 добавляло Set к набору чтения, а 4 разрешало только Response. Политика становилась понятной после разложения числа и восстановления тройки, к которой оно относилось.

Начальные примеры задавали разные строки для направлений. Управляющий субъект мог посылать агенту запросы чтения, а обратная строка разрешала Response и Trap. Право спрашивать не создавало право отвечать; Set требовал отдельного разрешения.

Экран может для краткости назвать 35 «чтением». Назвав его «доверенным», он уничтожит сведения о цели, контексте, направлении и операции.

Отправка не принимала решение за получателя

RFC 1445 применял контроль доступа при получении, а не при отправке. Отправитель собирал источник, назначение, контекст и PDU и мог передать корректное сообщение, не запустив локальную политику удалённой сущности.

Получатель последовательно проверял: известно ли назначение и реализовано ли оно здесь; известен ли источник; прошла ли аутентификация; существует ли контекст; есть ли строка для источника, назначения и контекста; включает ли она текущий класс PDU.

Правильно закодированное сообщение могло назвать неизвестную цель. Известная цель могла встретить неизвестный источник. Аутентичный источник мог запросить отсутствующий контекст. Контекст мог существовать без ACL, а ACL — разрешать Get и запрещать Set.

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

Контекст удерживал область ресурсов

Контекст SNMPv2 обозначал набор управляемых объектов. Для локальных ресурсов он ссылался на MIB view, для удалённых мог описывать proxy-отношение. Одна пара subject–target могла иметь разные права в разных контекстах.

Фраза «может читать» оставалась незаконченной без цели, контекста и представления. Допуск PDU не отменял проверки фактического пространства объектов.

Невидимость объекта в одном контексте не доказывала его физическое отсутствие, закрытость во всех других контекстах или отсутствие прав у другого субъекта. Это был результат одной локальной связи в одном административном состоянии.

Строка полномочия сама была состоянием

ACL содержала aclStorageType и aclStatus. Строка могла храниться volatile, nonVolatile или permanent, а жизненный цикл выражался через RowStatus. Видимая запись не доказывала активность, сохранность после перезагрузки или изменяемость.

Общая история RowStatus рассказана отдельно. Здесь важнее рекурсия: административные объекты, решавшие судьбу будущих сообщений, сами могли меняться через управление SNMP.

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

VACM сменил таблицы, но не отменил координаты

Исходная party-архитектура стала Historic. RFC 2575, затем RFC 3415 определили VACM для модульного SNMP. Модель безопасности и securityName отображались в group; group, contextName, модель и уровень безопасности выбирали строку; read, write или notify выбирали view; отдельный variableName проверялся внутри него.

VACM различал отсутствие контекста, группы, строки доступа, представления и нахождение объекта вне представления. Все исходы могли выглядеть отказом, но указывали на разные разрывы связи.

Party MIB и VACM — не одна система. Сохранился принцип: ответ «кто?» не отвечает на «где?», «при какой защите?», «каким действием?» и «над каким объектом?».

Записанная политика не была исполненным эффектом

Принцип Lu Heng о первичности работающего кода отделяет спецификацию, реализацию, проверку, развёртывание и использование. Его слои реальности отделяют символическую власть от исполнимого результата. RFC 1447 даёт ограниченный исторический пример.

Party ID называл. ACL выражала локальную политику. Приёмный путь исполнял её. Ответ фиксировал протокольный исход. Реальное изменение интерфейса, счётчика или маршрута требовало другого наблюдения.

Известная сторона не доказывала авторизацию. Существующая строка не доказывала активность. Принятый Set не доказывал правильный или устойчивый эффект. Возвращённое значение не доказывало смысловую точность.

Party MIB стала историей. Её дисциплина остаётся практичной: аудируемое полномочие живёт в восстанавливаемом отношении, а не в лестном свойстве имени.

Источники