Общий пароль от сетевого оборудования может казаться удобным техническим решением: его легко передать коллеге, не нужно создавать отдельные учётные записи, а доступ к устройству получают все, кому он необходим. Но такая простота исчезает, как только сотрудник меняет роль, увольняется или в конфигурации возникает неожиданное изменение.
Посмотреть, как заменить общий секрет персональными учётными записями, ролями и журналом входов, можно на открытом практикуме по защите доступа к сетевой инфраструктуре.
Устройство узнаёт пароль, но не человека
При использовании общей учётной записи маршрутизатор может проверить введённый пароль и разрешить вход. Однако с точки зрения управления доступом остаётся принципиальный пробел: система не различает людей, которые воспользовались этим секретом.
В нормальной схеме сначала происходит идентификация — пользователь сообщает, кто он. Затем аутентификация подтверждает заявленную личность. Если все входят под одним логином, персональная идентификация исчезает. Для устройства разные сотрудники превращаются в одного условного администратора.
Это особенно заметно при разборе журналов. Даже если устройство фиксирует административные команды, записи создаются от имени общей учётной записи и их нельзя надёжно связать с конкретным специалистом. Формально событие зафиксировано, а персональной подотчётности нет.
У всех одинаковые права — даже если задачи разные
Все сотрудники, использующие одну учётную запись, получают назначенный ей одинаковый уровень привилегий. Специалисту, которому достаточно посмотреть состояние интерфейсов, становятся доступны те же действия, что и другим пользователям этого аккаунта.
Такой подход противоречит принципу наименьших привилегий. Пользователь должен получать минимальный набор прав, необходимый для его текущей задачи. В сетевом оборудовании это можно реализовать через уровни привилегий: одному пользователю разрешить ограниченный набор команд, другому — расширенные операции, а полный административный доступ оставить отдельной роли.
Ролевой подход полезен ещё и тем, что права назначаются не каждому человеку вручную, а через заранее определённую функцию. Сотрудник меняет обязанности — меняется его роль и связанный с ней набор разрешений. При использовании одной общей учётной записи точечно изменить полномочия отдельного сотрудника невозможно: назначенный аккаунту набор прав получают все, кто знает его пароль.
Увольнение одного сотрудника превращается в смену секрета для всех
У учётной записи есть жизненный цикл: её создают, пересматривают, блокируют или отзывают. При персональном доступе можно отключить одного пользователя, не затрагивая остальных. С общим паролем точечный отзыв невозможен.
Чтобы гарантированно закрыть доступ одному человеку, приходится менять общий секрет и распространять новый среди всех действующих администраторов. Если устройств несколько и пароль хранится локально на каждом из них, операцию нужно повторить по всей инфраструктуре. Чем больше узлов, тем выше объём ручной работы и риск, что на каком-то устройстве останется прежняя комбинация.
Централизованная AAA решает эту задачу иначе: учётные записи и права хранятся на выделенном сервере, а сетевые устройства обращаются к нему при входе. Блокировка пользователя выполняется централизованно и не требует менять данные остальных сотрудников.
На практикуме 1 октября такая схема будет собрана на FreeRADIUS и виртуальном маршрутизаторе Eltex vESR: с отдельными пользователями, разными уровнями привилегий и проверкой успешных и неуспешных входов по журналам.
Локальные учётные записи плохо масштабируются
Общая учётная запись — лишь крайний случай более широкой проблемы: локального управления доступом. Пока устройств мало, пользователей можно создавать непосредственно на них и управлять записями вручную. Но при росте сети одни и те же данные приходится дублировать.
Каждое изменение превращается в серию ручных операций:
- создать нового администратора на всех нужных устройствах;
- одинаково назначить ему права;
- изменить уровень доступа при смене обязанностей;
- заблокировать учётную запись на каждом узле;
- проверить, что нигде не осталось старых данных.
Политики постепенно расходятся. На одном маршрутизаторе пароль уже изменён, на другом — ещё нет; где-то пользователь заблокирован, а где-то его локальная запись продолжает действовать. Централизованный сервер устраняет необходимость поддерживать одинаковые базы вручную на каждом устройстве.
Что должно быть вместо общего пароля
Рабочая схема управления административным доступом строится не вокруг одного очень сложного секрета, а вокруг нескольких взаимосвязанных механизмов.
Персональные учётные записи. Каждый специалист входит под собственным идентификатором. Это создаёт основу для точечного управления и аудита.
Централизованная аутентификация. Для штатного входа устройство передаёт проверку серверу AAA, поэтому одинаковые записи не приходится вручную поддерживать на каждом узле. При этом локальный способ входа может сохраняться как предусмотренный проектом резервный вариант.
Разные уровни привилегий. После входа пользователь получает только те команды и операции, которые соответствуют его роли.
Учёт событий. Система может фиксировать успешные и неуспешные попытки входа, а также данные о сессиях. Запись отдельных административных команд зависит от используемого протокола, возможностей оборудования и настройки командного учёта.
Управление жизненным циклом. Учётную запись можно создать, пересмотреть или отозвать без изменения доступа всей команды.
Резервирование. Централизованный сервер становится критичным для инфраструктуры, поэтому необходимо заранее продумать резервный узел и поведение устройств при недоступности основной системы.
Как проверить, что схема действительно работает
Настроить сервер и увидеть успешный вход недостаточно. Систему следует проверить в нескольких состояниях:
- пользователь с минимальными правами выполняет разрешённую команду;
- тот же пользователь пытается выполнить запрещённое действие;
- администратор с более высоким уровнем получает дополнительный набор возможностей;
- неверные данные приводят к отказу;
- успешные и неуспешные попытки появляются в журнале;
- отключённая учётная запись больше не позволяет войти;
- ошибка связи с сервером обрабатывается так, как предусмотрено проектом.
Такой тест показывает всю цепочку: от идентификации пользователя до записи результата. Только после этого можно говорить, что организация управляет административным доступом, а не просто хранит пароль.
Общий секрет кажется простым, потому что переносит сложность из момента настройки в будущее. Позднее она возвращается в виде обезличенных записей, одинаковых прав и трудного отзыва доступа. Персональные учётные записи и централизованная AAA требуют продуманной архитектуры, зато позволяют установить, кто вошёл, какие права получил и какие события были зафиксированы системой.
Повторить эту схему на виртуальном стенде можно после эфира 1 октября в 19:00 МСК. Все участники получат доступ к нему и дистрибутивы. На выходе — понимание процесса и готовый кейс для портфолио.
