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