Разграничение доступа к системе мониторинга: роли и права

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

     С ростом инфраструктуры ситуация меняется. В единой системе могут контролироваться несколько серверных, распределённые объекты, системы электропитания и кондиционирования, телекоммуникационное оборудование и другие компоненты. Одновременно с системой начинают работать дежурные операторы, инженеры эксплуатации, администраторы, специалисты информационной безопасности и подрядчики.

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

     Оператору может требоваться только видеть состояние оборудования и реагировать на тревоги. Инженеру — изменять параметры мониторинга и обслуживать оборудование. Администратору — добавлять пользователей и изменять конфигурацию всей системы. Подрядчику может быть достаточно доступа к отдельной площадке на время проведения работ.

     Если каждому предоставить полный административный доступ, любая из этих задач будет выполнима. Одновременно каждый пользователь получит возможность изменять настройки, которые к его работе отношения не имеют.

     Поэтому при проектировании системы мониторинга важно определить не только, какие параметры она контролирует, но и кто сможет видеть эти данные и какие действия выполнять.

Что именно нужно разграничивать

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

     Права могут определять возможность:

• просматривать состояние объектов и оборудования;

• видеть текущие тревоги и историю событий;

• подтверждать или закрывать события;

• выполнять управляющие действия;

• изменять пороги срабатывания;

• настраивать уведомления;

• добавлять и удалять контролируемые устройства;

• изменять параметры опроса;

• редактировать структуру объектов;

• изменять системные и сетевые параметры;

• создавать пользователей и назначать им права;

• просматривать журнал действий пользователей.

     Кроме того, доступ может ограничиваться не только по функциям, но и по объектам.

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

Типовые роли пользователей

Конкретный состав ролей зависит от системы мониторинга и организации эксплуатации. Тем не менее можно выделить несколько типовых вариантов.

     Это не обязательный набор. В небольшой инфраструктуре достаточно двух-трёх ролей, а в крупной их может быть значительно больше.

Рис. 1. Пример ролевого разграничения доступа

Матрица прав

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

Эта таблица не является универсальной моделью. В реальной системе права определяются возможностями программного обеспечения и принятым процессом эксплуатации.

     Её задача — определить необходимость каждого разрешения до его выдачи.

Принцип минимальных привилегий

     Такой подход применяется при организации управления учётными записями и правами доступа в информационных системах. Требования к управлению правами пользователей, контролю учётных записей и разграничению доступа рассматриваются, в частности, в ГОСТ Р 71753-2024 «Защита информации. Системы автоматизированного управления учетными записями и правами доступа. Общие требования».
Подробнее:
https://docs.cntd.ru/document/1310068328

Для системы мониторинга этот принцип можно свести к простому вопросу: если сотруднику нужно видеть температуру в серверной, должен ли он одновременно иметь возможность изменить сетевые параметры контроллера или удалить устройство из системы?

     Если нет, эти права ему не нужны.

     Особенно важно отделять просмотр информации от действий, способных повлиять на работу инфраструктуры.

Просмотр и управление — разные задачи

Система мониторинга может не только собирать данные, но и выполнять управляющие действия.

     Например, в ней могут отображаться:

• температура и влажность;

• состояние дверей;

• наличие электропитания;

• состояние ИБП;

• аварии климатического оборудования;

• доступность сетевых устройств.

     Для повседневной работы дежурному оператору может быть достаточно видеть эти данные и получать тревоги.

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

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

Право видеть состояние и право изменять состояние — разные разрешения.

     Именно поэтому функции просмотра и управления целесообразно разграничивать отдельно.

Разграничение по объектам

В распределённой инфраструктуре одной функциональной роли может быть недостаточно.

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

     Локальному инженеру могут быть нужны широкие права, но только в пределах своей площадки. Центральному оператору — просмотр всех объектов без возможности изменять их конфигурацию. Администратору центральной системы — полный доступ ко всей инфраструктуре.

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

Zabbix

В Zabbix права пользователя определяются его ролью и правами группы пользователей на группы узлов сети. Роль позволяет дополнительно ограничивать доступ к разделам интерфейса, сервисам, модулям, API и отдельным действиям.

Документация:
https://www.zabbix.com/documentation/current/ru/manual/config/users_and_usergroups/permissions

Checkmk

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

Документация:
https://docs.checkmk.com/latest/en/wato_user.html

PRTG

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

Документация:
https://www.paessler.com/manuals/prtg/access_rights_management

     Эти примеры показывают, что одинаковую задачу разные системы решают по-разному. Поэтому при выборе платформы важно проверять не просто наличие ролей, а то, насколько модель доступа соответствует структуре конкретной инфраструктуры.

Зачем нужны индивидуальные учётные записи

Даже если несколько сотрудников выполняют одинаковые обязанности, предпочтительнее использовать отдельные учётные записи.

     Общая учётная запись администратора, пароль от которой известен всей смене, создаёт несколько проблем:

1. сложнее определить, кто выполнил конкретное изменение;

2. невозможно отозвать доступ только одного сотрудника: при увольнении или переводе приходится менять общий пароль и передавать новый остальным пользователям;

3. невозможно назначить разным сотрудникам разные права: все они работают с полномочиями общей учётной записи.

     Индивидуальные учётные записи позволяют управлять доступом каждого сотрудника отдельно, а при поддержке журналирования — связывать действия с конкретным пользователем.

Журналирование действий

Разграничение прав отвечает на вопрос, что пользователь может сделать. Журналирование позволяет определить, какие действия фактически выполнялись.

     Для эксплуатации могут быть важны сведения о:

• входе пользователя в систему;

• изменении конфигурации;

• изменении порогов;

• добавлении или удалении оборудования;

• изменении схем уведомлений;

• выполнении управляющих команд;

• создании пользователей;

• изменении ролей и разрешений.

     Особенно полезен журнал при разборе ситуации, когда после изменения конфигурации перестало приходить уведомление или изменилось поведение контролируемого объекта.

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

Доступ для подрядчиков

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

     Выдавать подрядчику постоянную административную учётную запись только потому, что это проще, нецелесообразно.

     Если система позволяет, для таких пользователей лучше создавать отдельные учётные записи с ограничением доступа по объектам, действиям и времени:

• доступом только к обслуживаемому объекту;

• минимально необходимым набором действий;

• отсутствием прав на управление другими пользователями;

• ограниченным сроком действия.

     После окончания работ доступ должен быть отозван.

     Такой подход полезен не только с точки зрения информационной безопасности. Он снижает вероятность того, что специалист случайно изменит параметры соседнего объекта, к которому его работы отношения не имеют.

Типовые ошибки при организации доступа

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

2. Максимальные права для всех. Формально учётные записи разделены, но фактического разграничения нет.

3. Чрезмерно сложная ролевая модель. Большое количество ролей и исключений усложняет сопровождение. Роли должны соответствовать реальным обязанностям.

4. Отсутствие пересмотра прав. Сотрудник может сменить должность или перестать обслуживать объект, сохранив прежний доступ.

5. Смешивание наблюдения и управления. Пользователь получает возможность воздействовать на оборудование только потому, что ему необходимо видеть его состояние.

Что проверять при выборе системы мониторинга

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

     Следует проверить:

1. Можно ли создавать отдельные учётные записи.

2. Поддерживаются ли роли или группы пользователей.

3. Какие именно действия можно разрешать и запрещать.

4. Можно ли отделить просмотр от изменения конфигурации.

5. Можно ли отдельно ограничить управляющие команды.

6. Можно ли предоставлять доступ только к определённым объектам или группам оборудования.

7. Как наследуются права внутри структуры объектов.

8. Ведётся ли журнал действий пользователей.

9. Поддерживается ли интеграция с корпоративной системой аутентификации.

10. Можно ли быстро отозвать доступ одного пользователя, не затрагивая остальных.

     При этом большее количество настроек не всегда означает лучшую систему. Для небольшого объекта сложная ролевая модель может вообще не потребоваться. Требования к управлению доступом должны соответствовать масштабу и архитектуре мониторинга.

Если система не поддерживает разграничение прав

Не каждая система мониторинга имеет встроенную ролевую модель. Особенно это характерно для отдельных контроллеров и других устройств, рассчитанных прежде всего на настройку и эксплуатацию администратором.

     В этом случае разграничение можно организовать на другом уровне архитектуры.

     Например, контроллеры используются как источники данных: получают информацию от датчиков, контролируют состояние подключённого оборудования и передают необходимые параметры во внешнюю систему мониторинга.

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

     Такой подход может применяться и с устройствами NetPing. В самих устройствах NetPing нет ролевого разграничения прав пользователей: для работы с веб-интерфейсом используется административный доступ.

     Если требуется разграничение доступа между операторами, его можно реализовать на уровне внешней системы мониторинга, которая получает данные от устройств NetPing.

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

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

Пример: мониторинг нескольких серверных

Рассмотрим организацию с центральным офисом и несколькими удалёнными серверными.

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

     С системой работают четыре категории пользователей.

При такой архитектуре каждому специалисту доступна информация, необходимая для его задачи, но полномочия одного пользователя не распространяются автоматически на всю систему.

Разграничение доступа нужно проектировать вместе с мониторингом

Когда система состоит из одного устройства и обслуживается одним специалистом, отдельные роли могут быть избыточны.

     Но по мере роста инфраструктуры административный доступ для всех становится всё менее удобным и повышает риски ошибочных или нежелательных изменений.

     Поэтому при проектировании мониторинга стоит заранее определить:

• кто будет работать с системой;

• какие объекты нужны каждому пользователю;

• какие действия ему необходимо выполнять;

• какие операции способны повлиять на работу оборудования;

• кому действительно требуются административные права.

     После этого можно оценивать, достаточно ли возможностей конечных устройств или необходима централизованная система с более развитым управлением пользователями.

---

Для подбора оборудования для системы мониторинга и консультации по его применению можно обратиться к специалистам «Алентис Электроникс».

Отдел продаж: sales@alentis.ru
Pre-sale-консультации: pre-sales@alentis.ru
Техническая поддержка: support@netping.ru