Net-SNMP FAQ (Перевод)   |   Net-SNMP README (Перевод)

Перевод документации на Net-SNMP :: Net-SNMP FAQ




www.net-snmp.ru /  Net-SNMP FAQ / AGENT. Я не могу понять смысла нового контроля доступа - что это значит?



AGENT. Я не могу понять смысла нового контроля доступа - что это значит?

Идея, лежащая в основе новой модели контроля доступа - предоставить более гибкий способ для указания того, кто что может видеть и кто что может сделать в MIB дереве. Это гораздо сложнее объяснить, чем пример в вопросе выше, но это именно потому, что эта модель позволяет делать намного больше.

Есть 4 ключевых конфигурационных слова в новой схеме: 'com2sec', 'group', 'view' и 'access'.

По очереди разъясним каждую из них, начав с 'access'. (Просто потому что мне больше нравится начинать с конца - Хорошо?).

Слово "access" выполняет работу по указанию того, что имеет доступ и к каким частям MIB дерева. Команда имеет 8 параметро, поэтому выглядит достаточно запутанно. Большинство из них могут быть совершенно спокойно опущены и заменены значениями по умолчанию в большинстве случаев (так что вам не нужно пережаивать по поводу недостатка знаний об этой команде). Синтаксис следующий:

access {group} "" any noauth exact {read-tree} {write-tree} {notify-tree}
где значения в фигурных скобках указываются всегда, а остальные могут быть опущены как показано здесь.
[Если вы действительно хотите знать, поле 'sec.model' лучше использовать для указания доступа, который связан только с какой-то отдельной версией SNMP (v1 или v2c) чем указывать версию "any", а поле 'sec.level' служит для указания того, что использовать для работы с запросом - аутентицикаию или криптование.
Поля context и prefix могут быть использованы для внесения различий между параллельными версиями одного и того же MIB дерева.]

Слово "view" испольуется для настройки конкретных кусков MIB дерева, для использования в последних трех полях записи access. Синтаксис следующий:

view {name} included/excluded {subtree} {mask}
где {name} - идентификатор, который будет использоваться для указания на данное представление (т.е. что должно появиться в записи access), а and {subtree} - часть MIB дерева, которую вызывает данное имя (в числовом или именованном формате).
Обратите внимание, что имя представления не имеет ничего общего с тем, что нужно сделать с именами MIB идентификаторов - это всего лишь идентификационная строка для использования внутри config файла (хотя указания многозначительного имени конечно же хорошая идея).
Поле {mask} может быть использовано для контроля, какие элементы OID поддерева могут быть опеределны как важные при определении, в каком представлении находится OID. Наиболее подходит это при задании "unusual" представлений, таких как одиночная строка в таблице. В большинстве случаев поле можно пропустить.

Третье поле может быть использовано для подключения или отключения какой-то части MIB из именованного представления. Одиночное представление может быть построено с использованием нескольких линий 'view' (с одним и тем же именем представления), включая или исключая поддеревья OID, когда это нужно.

Три поля просмотра в линии доступа (access line) используются для контроля того, какую часть MIB дерева кто-то {группа} может видеть (GET и другие), изменять (SET), или запрашивать (NOTIFY).

Это что касается вопроса с "что" - теперь "кто". Эта роль отведена для записей "group" и "com2sec".

Слово "group" дает основной контроль, являясь связующим звеном между "security name" (для некоторых версий протокола) и внешним именем, используемым в линии доступа. Обратите внимание, что вариант "any" более не доступен для модели безопасности - его поддержка была завершена вследствие разночтений в RFC. Вам следует заменить все подобные линии различными версиями для каждой из желаемых моделей безопасности ('v1', 'v2c' & 'usm').

Для SNMPv1 и SNMPv2c линия group всего лишь промежуточный шаг между линиями "access" и "com2sec", который является последним битом в jigsaw. Переменная "com2sec" используется для определения "security name" из обычной строки community, находящейся в аккаунте, откуда пришел запрос. Таким образом, та же строка community может дать доступ к различным частям дерева в зависимости от того, откуда пришел запрос.

К примеру, в ранних версиях примера config файла было 2 com2sec линии с одной и той же строкой community "public" - один корректен для запросов отовсюду (с security name "public") и один корректен только для локальной сети (security name "mynet").
Линии групп (group lines) конвертируют эти имена (security names) в группы "public" и "mygroup" соответственно, а линии доступа (access lines) дают этим двум группам возможность получать (GET) значения в поддереве 'system' (отовсюду) или поддереве 'mib-2' (из локальной сети). Ни одна из строк не дает права записи (SET) любых значений (поскольку write-tree указано в обоих случаях как "none").

Кто-то с локальной машины, испольуя строку community "private", имеющий security name "local" и имя группы "local", и поэтому имеющий полный доступ (и GET и SET, а также и NOTIFY) к полному MIB дереву (ну или по крайней мере ко всему под .1, где содержится много полезного!).

Обратите внимание, что три появления слова "public" в качестве строки community, имен security и группы были тремя полностью раздельными вещами. Вы не можете использовать строку community в поле security name, или любую из этих строк как имя группы (и наоборот), если вы не указали необходимые записи для связки одного имени с другими.

На SNMPv3 security name является частью бзаового протокола и может быть использовано напрямую из настройки группы.

И этим ограничим наш тур по механизму контроля доступа, построенному на базе представлений (view-based access control mechanism). УФФФФФФ!



<<<  AGENT. Как мне настроить контроль доступа? 
AGENT. Как мне настроить пользователей SNMPv3?  >>>
При копировании размещение гиперссылки на оригинал обязательно!
© MIB Search 2006-2009