Безопасность и стабильность работы любой многопользовательской информационной системы зависит от корректности настройки ролей пользователей и прав доступа. Каждый участник рабочего процесса должен иметь доступ только к тем функциям, которые определены его должностными обязанностями. Настройка ролей и прав доступа в SimpleOne устроена по традиционной схеме наследования, но имеет некоторые особенности и уникальные возможности.
Ролевая структура
Структура ролей SimpleOne состоит из трёх уровней, каждый из которых даёт определённые полномочия своим владельцам.
Конечные пользователи — базовый уровень, члены которого лишены каких-либо возможностей в системе и могут только использовать портал самообслуживания, регистрировать обращения и отслеживать их статус.
Специалисты (пользователи, работающие в ITSM-системе) — примером могут выступать ITSM-агенты, пользователи решения ITSM, которые имеют определённую функциональную роль. Сотрудники с ролью ITSM-агента выполняют в системе определённую задачу, например обрабатывают инциденты или работают с CMDB. Некоторые задачи требуют более широких полномочий, тогда пользователю назначается несколько ролей ITSM-агента. Для удобства работы SimpleOne «из коробки» содержит базовые преднастроенные роли: ITSM_agent, change_manager, CMDB_manager, incident_manager, service_catalogue_manager и другие. Из названия каждой роли уже понятно, какие полномочия она даёт своему владельцу.
Более подробно ознакомиться с базовыми ролями можно в технической документации к ITSM-решению SimpleOne.
Администраторы — это высший уровень ролей в иерархии SimpleOne, которые дают своему владельцу доступ ко всем возможностям платформы, в том числе её администрированию. Административная роль бывает двух типов — стандартная и специальная. К стандартной относятся под-роли admin и security_admin: первая даёт все возможности управления платформой, кроме назначения прав, вторая позволяет управлять правами доступа, но не разрешает менять конфигурацию. Специальные административные роли предоставляют ограниченные привилегии: import_admin — управление импортом, notification_admin — управление уведомлениями, impersonator — возможность «посмотреть на систему глазами другого пользователя» (подробнее об этом расскажем ниже).
Администраторы SimpleOne не ограничены только приведёнными выше ролями, они могут создавать собственные под потребности бизнеса и прописывать необходимые полномочия. Для этого требуется создать собственные правила ACL (Access Control List, или список управления доступом).
Наследование
Для того чтобы не назначать роли каждому пользователю персонально, создаются группы и уже на группу назначаются определённые роли. Так все пользователи, которые входят в группу, наследуют её права и возможности. Механизм наследования нагляднее всего изобразить схемой.
Андрей является специалистом технической поддержки, работает с изменениями и инцидентами. Для того чтобы выполнять свои обязанности, его руководитель вручную присвоил ему роль incident_manager. Дальше процесс развивается по принципу матрёшки: Андрей унаследовал роль ITSM_admin, так как входит в группу ITSM_admins, роли problem_manager и change_manager унаследовал от группы ITSM_managers, роль ITSM_agent — от группы ITSM. А роль impersonator он получил от группы Impersonators, которая входит в группу security_admin.
Защита «от дурака»
Расширенные права — это не только возможности, но ещё и дополнительная ответственность. Пользователь, обладающий ролью внесения изменений в платформу, может случайно по неосторожности навредить и дестабилизировать работу всей системы. Поэтому в SimpleOne добавлен дополнительный инструмент защиты от случайных изменений — повышение привилегий.
Включение данной опции для роли пользователя отключает её по умолчанию и активизирует только по запросу. Например, на рисунке выше показано, что пользователю Admin назначена роль security_admin, но для того, чтобы воспользоваться её преимуществами, требуется дополнительная активация через меню пользователя. Таким образом, дополнительная роль включается только в тот момент, когда она нужна. Повышение привилегий возможно только между основными уровнями ролей, то есть невозможно пользователю с ролью incident_manager добавить повышающую роль problem_manager, так как они обе из одного уровня ITSM-агенты, однако можно повысить до admin, тем самым наделить пользователя полными правами после активации опции.
Режим «аватара» (имперсонирование)
Вторая нестандартная возможность платформы SimpleOne — имперсонирование. Для того чтобы иметь возможность имперсонизации, пользователь должен обладать ролью impersonator. Она позволяет выполнить временный вход в систему под другим пользователем.
Например, пользователь Admin, обладающий ролью impersonator, может в любой момент переключиться на пользователя Владимира и посмотреть, как система выглядит и работает с точки зрения конечного пользователя. Эта функция находит широкое применение во время разработки и доработки платформы, когда архитекторы и администраторы должны проверить работу системы от лица обычных пользователей. Одно из ограничений имперсонирования — это запрет на переключение на пользователя, который обладает набором старших ролей, отличным от текущего. Если пользователь не обладает ролью admin, то не сможет имперсонироваться в пользователя, который ей обладает. То же относится и к роли security_admin.
Делегирование
И третья важная возможность платформы SimpleOne, связанная с правами и ролями, — это делегирование. Пользователь делегирует свои права и возможности внутри платформы своему коллеге, например, на время отпуска. Так, пользователь Владимир, являясь руководителем отдела, может согласовывать заявления своих подчинённых. На время своего отпуска он делегирует свои полномочия заместителю Сергею, который получает в системе возможность согласования заявлений от своего имени. На время делегирования платформа даст возможность Сергею совершать от своего имени все действия, которые выполнял Владимир.
Функциональность пользовательских критериев
Создание произвольных ролей и назначение им определённых разрешений — удобный способ настройки безопасности, но недостаточно гибкий. Мы его называем системным, так как он оперирует только системными параметрами пользователей — их принадлежностью к какой-либо группе.
У пользователей значительно больше косвенных признаков, по которым их можно идентифицировать, например должность, подразделение, участник проекта, географическое расположение и другие. Для расширения возможностей стандартных ACL в SimpleOne реализован механизм проверки на соответствие пользовательским критериям. Администратор может создать пользовательский критерий, включив в него признаки пользователя, необходимые для определения его прав доступа. Это могут быть как разрешения доступа в определённые разделы платформы, так и настройка отображения элементов портала.
Например, необходимо дать доступ к закрытому разделу базы знаний сотрудникам, которые занимаются контентом и работают в московском офисе. Администратор создаёт пользовательский критерий с названием «Контент Москва», в нём задает условия соответствия пользователей — роль content_manager, а расположение — «Москва». После этого он применяет критерий к базе знаний так, чтобы только пользователи, которые ему соответствуют, могли получить доступ к закрытому разделу.
Используя пользовательские критерии, администратор может настраивать сложные права и правила.
Например, компания использует ITSM-систему SimpleOne вместе с модулем CRM. В базу данных заносятся все сделки — закрытые, текущие и возможные. Список сделок и их карточки может увидеть любой пользователь, входящий в группу отдела продаж, а также руководство компании — это настроено с помощью политик прав пользователей. Однако менеджмент компании считает, что сделки с суммой контракта выше 100 тысяч рублей должны видеть только владельцы карточек и их руководители.
Администратор создаёт пользовательский критерий, который определяет группы пользователей, имеющих доступ к таблице контрактов.
С помощью настроек прав доступа ACL администратор задаёт разрешения на чтение контрактов менеджерам по продажам и их руководителю, а также вводит ограничение на просмотр чужих контрактов дороже 100 тысяч рублей всем, кроме руководителя.
В результате применения пользовательского критерия и ACL каждый менеджер по продажам видит все свои контракты, а также чужие контракты с бюджетом меньше 100 тысяч рублей, а руководитель отдела продаж видит контракты всех менеджеров вне зависимости от значения поля Total Cost.
Пользовательские критерии — это новый подход к созданию политик доступа. Администратор создаёт абстрактные сущности исходя из логических параметров, а не системных определений. И применяет их для решения любых задач организации доступа или тонкой настройки платформы. Это обеспечивает системе настройки прав доступа непревзойдённую гибкость, ограниченную только фантазией администратора системы.
Заключение
Настройка ролей и политик доступа — это важное мероприятие при внедрении любой информационной системы, так как от её грамотной настройки зависит безопасность и стабильность работы корпоративных бизнес-процессов.
ITSM-система SimpleOne позволяет применять политики доступа с помощью распределения ролей как на отдельных пользователей, так и на целую группу, а также обеспечивает высокую гибкость настроек, защиту «от дурака» и удобный инструмент для отладки и тестирования с помощью имперсонирования.
При этом ESM-платформа (на основе которой автоматизируются сервисные процессы) позволяет настраивать контекстную выдачу прав вплоть до отдельных полей или карточек записей с использованием логики произвольного уровня сложности. Для этого используется функциональность ACL, которая позволяет задействовать для проверки прав доступа любую информацию, содержащуюся в системе.
