Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Как сделать ограничение администраторского доступа с нескольких хостов? | about NetApp

Администраторский доступ с нескольких хостов

Системы хранения NetApp позволяют ограничить доступ к админской консоли, задав IP-адрес админского хоста либо при установке, либо в параметре admin.hosts

Однако, иногда хотелось бы задать не один конкретный адрес, а подсеть, или несколько адресов.

В этом случае возможен следующий простой трюк. Можно указать в качестве админхоста gateway соответствующей подсети, например в которой находятся рабочие места админов. В этом случае доступ будет ограничен только хостами указанной подсети:

fas1> options admin.hosts 192.168.1.254

Другой вариант – указать их в таком виде:

fas1> options admin.hosts host1.domain.com:host2.domain.com:host3.domain.com

Не забывайте, что это ограничение предельно примитивное, и строить защиту админского доступа только на нем не стоит, так как определяет возможность доступа к логину консоли исключительно по легко изменяемому IP источника. Если стоит задача серьезного разграничения доступа, то стоит использовать как “секурный” доступ по SSH и HTTPS (команда secureadmin), pre-shared key, и средства RBAC (Role-based Access Control), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.

3 комментария

  1. Korj:

    А в чём разница с документированной опцией trusted.hosts?

  2. trusted.hosts
    Specifies up to 5 clients that will be allowed telnet, rsh, and administrative HTTP (i.e. FilerView)access to the server.

  3. Korj:

    Я имел в виду принципиальную разницу - есть документированная опция trusted.hosts, поддерживается в том числе System Manager-ом. ? есть недокументированная “deleted” опция вроде бы с тем же функционалом. Зачем её использовать?

    Вообще как эта опция работать-то должна? Как вообще получается, что она шлюз воспринимает в качестве адреса? Адреса не из её подсети работать не будут, потому что она видит шлюз? Вообще как это согласуется с tcp/ip - какое отношение имеет шлюз к пакету? он с точки зрения tcp/ip вообще прозрачен - пакет приходит от исходного адреса - никаких шлюзов в пакете не отмечается. Как система узнаёт, из какого шлюза пришёл пакет? reverse arp? из своей таблицы _исходящего_ роутинга?
    Вы уверены, что вы (или Mohit Garg? ;) не перепутали gateway и proxy server? Трюк с proxy будет работать и с trusted.hosts, более того, из-за настройки прокси-сервера казалось бы допустимый хост может не пускать в админку, потому что он через прокси лезет (особенный казус с System Manager-ом, которому пишут имя хоста, а он его резолвит и лезет по ip).

    Что касается trusted.hosts, то практика показывает, что как минимум список из 6 хостов вполне работает, а если уж нужен более гибкий инструмент - то “option *.access” (na_protocolaccess) позволяет гибче некуда конфигурировать доступ вполне документированным и современным способом.

Оставить комментарий

20/0.078

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.