#20. ПО Access Control для разграничения прав доступа
В предыдущих видео мы уже упоминали специализированное ПО Access Control, с помощью которого (и только с помощью него) мы настраиваем права доступа для пользователей. Важно отметить, что это ПО нужно только в момент настройки, когда мы только настраиваем систему, или делаем корректировки в процессе работы. Не требуется, чтобы оно было открыто в течение всего времени эксплуатации системы. Посмотрим, как оно устроено, как им можно пользоваться и разберем специфические особенности данной конкретной системы.

Открываем окно и видим в левой части все доступные источники. Фактически это все сервера, которые в данный момент доступны в системе, с которыми я могу настраивать права доступа. В основном окне есть три вкладки:

I. Список пользователей
Смотреть эпизод
Для каждого пользователя можно настраивать:
  • Логин/пароль;
Помните о том, что логин и пароль чувствительны к маленьким/ большим, строчным/прописным буквам, это нормальная практика.

  • Уровень привилегий — уровень доступа, про который мы говорили;
  • Галочка администратора;
  • Галочка эксклюзивного доступа.

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

Уровни доступа мы уже описывали:
  1. Обычный пользователь;
  2. Привилегированный пользователь;
  3. Начальник.
Административный уровень вынесен отдельно как галка. Администратор в системе может быть только один. Только одному из пользователей можно поставить права доступа администратора.

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

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

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

II. TX Access Table
Смотреть эпизод
В этой вкладке для ресурсов появляются отдельные логические группы. Они могут быть реализованы в виде перечня ресурсов, доступных определенному пользователю для выполнения определенных задач.

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

III. User Access
Смотреть эпизод
Здесь происходит связка между первой и второй вкладками. Для пользователя мы назначаем логическую группу или несколько логических групп. Ее можно открыть для просмотра (View), для управления (Control) и закрыть.

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

Таким образом получается общая матрица доступа к логическим группам и пользователям.

Когда мы настроили матрицу доступа, ее нужно загрузить на контроллер управления, который называется Access server. В перечне источников есть основной сервер (помечен буквой M (Master)) и дополнительный сервер (Slave). Важно понимать, что контроллер управления — это не отдельно стоящий выделенный сервер со своей ОС и аппаратным обеспечением. В данном случае это любой из передатчиков, который установлен и работает внутри KVM-сети.

Почему это важно? Дело в том, что когда есть централизованная система с выделенным сервером, то выход из строя этого сервера фактически означает выход из строя всей системы. Это очень отказонеустойчиво и небезопасно, особенно в критически важных объектах. Здесь же другая история — есть Master, есть Slave, и это один из передатчиков системы (дополнительный или один из рабочих). Но самое главное, что даже если что-то с ним случается, то ничего не стоит зайти в ПО, выделить другой передатчик, назначить его основным или дополнительным, и буквально через минуту вся система будет абсолютно работоспособна. Именно это позволяет организовать фактически децентрализованную систему работы и, самое главное, с очень высоким запасом отказоустойчивости. Это важно для объектов с особыми требованиями по надежности.

Когда мы настроили матрицу, нажимаем «Записать настройки», и появляется сообщение, что настройки записаны (здесь сразу на 2 контроллера с IP-адресами 33 и 91).

Следует отметить, что есть возможность экспортировать и импортировать конфигурацию. Мы можем текущую конфигурацию экспортировать. Она сохранится в файл с расширением acg. Но нужно понимать, что это xml разметка, которую можно сохранить в виде обычного текстового файла и импортировать при необходимости. Это нужно для того, чтобы иметь возможность быстро выгружать и подгружать готовую, полностью запрограммированную ранее конфигурацию, или возвращаться, делать бэкап конфигурации на определенную точку восстановления.

Мы рассмотрели основной функционал. Теперь вы знаете, как заводить пользователей в системе KVM, создавать логические группы для доступа к определенным ресурсам, и сопоставлять пользователей и эти логические группы.