Существует два уровня доступа операторов к IP KVM системам:
Свободный, когда оператор просто приходит и работает;
На самом деле даже в больших компаниях не всегда есть необходимость в дополнительной авторизации. Там безопасность обеспечивается другими административными ресурсами. Также в огромном количестве маленьких ситуационных центров, где работает 3-4 человека, физически не нужно городить огород из авторизации и еще чего-то. Особенно это касается ситуационных и диспетчерских центров, связанных с видеонаблюдением, где 3-4 оператора наблюдают на экранах за происходящим. Это достаточно большой пласт задач.
С авторизацией.
Посмотрим, как это работает, на демо.
Происходит процесс перезагрузки приемника. Сначала видим процесс без авторизации. Система автоматически подключается без авторизации и на экране появляется набор доступных источников. Оператор может выбирать и работать.
Система с авторизацией потребует ввода логина/пароля.
У вендоров есть версии с авторизацией, без авторизации, либо и такая, и такая. Например, в TnTv есть две версии:
· Базовая версия без авторизации (дешевле)
· Версия с авторизацией. У нее больше функциональных возможностей, она дороже.
Это одно и то же устройство, просто софт разный. Интегратор подбирает заказчику систему, ориентируясь на его требования.
Напоминаем, что в целом IP KVM система — это надстройка над текущей информационной системой, не надо их путать. Процесс авторизации в IP KVM системе ни в коем случае не заменяет авторизацию в информационной системе предприятия. Это дополнительный уровень безопасности.
Если есть несколько источников, как разграничить к ним доступ? Существуют разные типы прав пользователей на источники:
· Нет доступа;
· Только просмотр, то есть пользователь может смотреть картинку, но управлять не может;
· Полный доступ, то есть пользователь может и смотреть, и управлять.
В достаточно сложных IP KVM системах есть не только права пользователей, но и права устройств отображения и рабочих мест. Например, можно дать право видеостене, и тогда она имеет право показать на себе что-то. Понятно, что видеостена обезличена, но поскольку она входит в нашу IP KVM систему, она тоже имеет права, как ни странно. Другими словами, на любую сущность внутри IP KVM системы можно назначить некие права. У каждого вендора это реализовано по-своему, есть большое количество нюансов, у кого-то это проще сделано, у кого-то сложнее и гибче.
Посмотрим, как происходит процесс заведения прав пользователей, чтобы в целом было понятней, как с устройствами работать.
В ПО AccessControl (система TnTv) заведем 3 пользователей и пароли для них:
Процесс заведения пользователей и паролей у каждого вендора свой.
Пока у нас все пользователи имеют одинаковые права.
Теперь переходим в таблицу с назначением источников, которым будут даваться права.
Слева список источников, их 3 штуки, но это не значит, что все эти источники могут использоваться в IP KVM системе. Мы даем права только на те, которые нужны. В данном случае мы выбрали один источник, говорим, что он будет доступен в нашей системе.
Переходим в следующую закладку, где 3 пользователям даем разные уровни прав:
У первого пользователя доступ закрыт, у второго доступен только просмотр, а у третьего полный доступ.
Теперь посмотрим, как это работает вживую.
Сначала на рабочем месте авторизируемся под первым пользователем. Напоминаем, что первый пользователь не имеет никаких прав.
После авторизации у первого пользователя список доступных источников пуст.
У второго пользователя после авторизации в меню появляется источник с пометкой view only (только просмотр). После авторизации третьего пользователя в меню появляется источник с полным доступом.
Если пользователь работает с большим количеством источников, например, 20-30 штук, неудобно ему назначать права доступа на каждый по отдельности. Обычно во всех системах есть понятие группы прав. Обычно делается логическое деление на группы, например, по типам выполняемых функций, административное деление (начальник, рядовой пользователь, дежурный администратор), и им назначаются соответствующие права.
Пример:
Здесь есть источник 1 и источник 2 — это два конкретных компьютера. Группе пользователей (3 столбец) доступны 4, 5, 6 источник. Группе начальников (столбец 4) доступны все источники, группе аналитиков (столбец 5) доступны последние 3 источника.
Можно просто выбирать пользователя и назначать ему группу, и у него будут объединяться доступные ему источники.
Точно также складываются права доступа, а не только источники. Если у оператора права доступа не было, а на сервере только просмотр, итоговое право — только просмотр. Если бы был только просмотр, а в другой группе этот же источник имел полный доступ, то в итоге будет полный доступ.
Следующий важный вопрос — это иерархия пользователей в системе, так называемые роли.
IP-KVM системы выделяют три основных типа в части иерархии пользователей:
1. По доступным функциям;
Модель построена на ограничении прав. Грубо говоря, начальник может все, а рядовой пользователь может минимально. Например, в компании Aten в IP KVM системе реализована модель именно на уровне ограничения прав. Рядовой пользователь может только выбирать источники, и больше ничего, а продвинутому пользователю доступны все действия в IP KVM системе.
2. По приоритетам пользователей;
Модель основана на базе уровней приоритетов пользователей по иерархии доступа (начальник СЦ, его зам, группа администраторов, группа рядовых пользователей).
3. По функциям и по приоритетам пользователей
В IP KVM системе TnTv используется как раз гибридный вариант — можно делать и так, и так.
На самом деле это очень важная тема, поскольку чем ближе находится иерархия пользователей к текущей структуре предприятия заказчика, тем легче заказчику интегрироваться в работу с IP KVM системой. Грубо говоря, никто не будет менять свои регламенты, которые приняты в организации, только из-за того, что ему поставили то или иное оборудование.
Естественно, в каждой организации свои принципы и логика построения бизнес-процессов. Здесь важно не натягивать бизнес-модель заказчика под IP KVM систему. Наоборот, нужно выбирать IP KVM систему под бизнес-модель заказчика, делать ее максимально близкой, иначе это вызывает отторжение. Если заказчику это неудобно, он откажется от такой модели.
Посмотрим, как это выглядит в TnTv.
Здесь первый пользователь обычный, второй привилегированный, третий — начальник. Еще в структуре есть админ, но о нем поговорим позже.
Даем всем пользователям одинаковые права — полное право на управление.
Посмотрим, как эта ролевая модель построена на иерархии уровней доступа: начальник, привилегированный пользователь, обычный пользователь. В нашей модели в данном случае остается иерархия пользователей на уровне приоритета управления.
Подключаемся к рабочему месту обычного пользователя с минимальным уровнем доступа.
У него есть доступ к компьютеру, он может работать.
Подключаемся к рабочему месту привилегированного пользователя, у которого приоритет выше.
На левом мониторе появилась надпись, что в данный момент времени управление отключено оператором с соседнего рабочего стола. То есть после подключения более привилегированного пользователя у обычного пользователя отобрали управление.
Теперь на третьем рабочем месте авторизуемся от имени начальника.
На первом компьютере появляется та же самая надпись о том, что занято тем-то столом.
Теперь начальник работает, а привилегированный пользователь отключен.
После того, как начальник поработал, он отключает К/М канал.
Мы сейчас показываем, как пользователь использует ручное управление. Он поработал и освобождает К/М канал.
У первого пользователя в данный момент на экране появляется сообщение, что К/М освободился.
Можно подключиться, канал запускается и можно управлять.
Аналогичным образом, как только привилегированный пользователь отключится от этого источника либо отключит канал, источник становится доступным для рядового пользователя. Таким образом, чем выше иерархия, тем больше приоритет.
Мы посмотрели пример иерархии по приоритету. Дальше посмотрим, как сделать настройку уровней доступа по функционалу, когда кому-то что-то доступно, кому-то не доступно с точки зрения возможностей системы.
Мы уже говорили, что в компании Aten модель построена на том, что кому доступно. У них есть два уровня пользователей: первый может только выбирать источники, никаких других функций нет. Второй — это продвинутый пользователь более высокого ранга, которому доступно все. На самом деле есть третий уровень — админ, но это отдельная тема, мы про него дальше тоже поговорим.
В TnTv система более гибкая. Мы можем из функционала ограничивать, фильтровать функции взаимодействия операторов с объектами IP KVM системы. Классический вариант — это выбор источника IP KVM системы, с которым ты работаешь. Второй частый вариант — функции push (выпихнуть источник куда-то) и pull (взять источник откуда-то себе). Есть функции управления источниками на других рабочих местах, видеостенах, группами и т.д.
Посмотрим, как это работает.
Например, у оператора на рабочем месте нет прав (в меню нет main zone), и он ничего не может. А на соседнем рабочем месте сидит начальник, у него в меню напротив видеостены указано main zone, и он может запихнуть любое изображение на видеостену.
Мы пока не говорили про администратора. На самом деле это очень интересная роль в IP KVM системе. Интересно, что он у всех вендоров имеет разные функции. Иногда это просто пользователь, который может только заводить других пользователей, и все. У других он вдобавок имеет минимальные возможности управления. У третьих он, что называется, царь и бог. Выбирая IP KVM систему, надо понимать, какие функции нужны администратору.
В TnTv системе администратор — это царь и бог, имеющий максимально высокий уровень приоритета. Ему по умолчанию доступны вообще все источники, даже те, на которые нет прав у других пользователей, которые не занесены в систему. Самое главное, у него есть функция делегирования прав. Мы уже упоминали, что иногда в случае форс-мажора бывает необходимо дать доступ какому-то пользователю к источнику, на который у него прав нет. Администратор может временно делегировать это право управления.
Посмотрим, как это работает. Сначала заведем админа. Им может быть только начальник, и админ в системе только один.
У админа автоматически сразу появляются все права, даже на группы, которые не существуют — ведь он царь и бог.
До этого мы работали без админа. У некоторых вендоров система без админа не существует, он есть по умолчанию. В TnTv админ — это сущность, которая заводится, если она нужна. Ведь админ — это повышенная уязвимость системы, потому что ему доступно всё. Если этот функционал с делегированием прав, с доступностью всех и вся не нужен, его можно не заводить.
Слева рабочее место пользователя, который работает с одним источником. Справа — рабочее место администратора, у которого 3 источника. Напоминаем, что в данном случае в системе зарегистрирован только 1 источник.
Пользователь с левого рабочего места просит администратора какой-то другой источник, чтобы срочно решить какую-то проблему. Администратор заходит в административную функцию управления, выбирает нужный рабочий стол и делает функцию push.
Источник появляется на рабочем месте оператора. Но если посмотреть меню на рабочем столе оператора, там этот источник не появился.
Оператору просто дали временно доступ к источнику, на который у него доступа нет. Как только он отключится от этого источника, он исчезнет — это мираж.