Подписаться
Читать в телеграм
Как правильно построить ролевую модель управления доступом?
Если компания активно использует информационные системы и у нее большой штат сотрудников, она неизбежно сталкивается с проблемой роста полномочий, которые доступы для запроса пользователям. В некоторых системах количество таких полномочий (ИТ-ролей) исчисляется десятками тысяч, например, в SAP ERP или Oracle ERP количество ИТ-ролей может достигать 250 тысяч. Разобраться в этом списке обычному пользователю очень трудно.
В некоторых компаниях есть специальные отделы аналитиков и методологов, единственная задача которых – принимать заявки на доступ от сотрудников в свободной форме. Затем в информационных системах отбираются необходимые полномочия и их перечень отправляется на согласование пользователю, который формирует итоговую заявку и повторно отправляет ее на согласование в контролирующие инстанции и на исполнение. Если же такого отдела нет, составление заявки на доступ превращается в длительный и запутанный квест, пользователи начинают самостоятельно искать среди тысяч полномочий необходимые, запрашивать их. После того как заявка согласована и выполнена, выясняется, что часть полномочий не подходит для этого филиала, часть уже не используется, а то, что предоставляется, недостаточно для работы. Кроме того, что на составление заявок уходит время сотрудников компании, на эту же задачу тратит свое время системный администратор, который, вместо того чтобы заниматься администрированием ИС, разбирает поток заявок и назначает десятки полномочий в день. При обследовании в одной из компаний с общим штатом сотрудников в 6000 человек мы выяснили, что администраторы тратили 134 человеко-дня в месяц на разбор и обработку заявок на доступ.
Очень популярны заявки «Мне как у соседа», где вместо соседа вписывается ФИО коллеги, который, как кажется, исполняет схожие должностные обязанности. При этом никто не даст гарантии, что у этого коллеги права не избыточны. Этот ком продолжает расти, и в итоге у сотрудников накапливается огромное количество ненужных полномочий, которые сложно контролируются и могут давать доступ к конфиденциальной информации.
Для решения этих проблем компании часто инициируют проекты внедрения IdM-системы, но без предварительной систематизации доступа. Если она не проводилась в процессе внедрения, результатом становится автоматизированный хаос. Полномочия раздаются и отзываются автоматически, но неразбериха с правами остается.
Оптимальным решением является предварительный проект по оптимизации ролевой модели прав доступа. Самое главное здесь – не увлекаться: часто ответственные за проект стараются «распихать» 100% всех прав доступа по бизнес-ролям, чтобы при перемещении по должности все роли в ИТ-системах выдавались строго в соответствии с должностью сотрудника и его позицией в оргштатной структуре компании. Этот подход не рационален. Наша практика показывает, что после включения в бизнес-роли ?80% ИТ-ролей затрачиваемые временные и финансовые ресурсы резко возрастают, и если вовремя не остановиться, на проект можно потратить большое количество ресурсов и так его и не завершить.
Рис. 1. Зависимость ресурсных затрат от полноты ролевой модели
Ролевые модели чаще всего разрабатываются в соответствии со следующими методологиями:
- Должностная ролевая модель – выделение ролей на базе должностных обязанностей сотрудников.
- Функциональная ролевая модель – выделение ролей на базе функциональных задач.
- Гибридная модель – совмещаются подходы должностной и функциональной ролевой модели.
Роли на базе должностей. Разработка ролей отталкивается от должностных инструкций сотрудников компании. Для каждой должности ответственные за ролевую модель собирают перечень функциональных обязанностей и необходимых полномочий в информационных системах. Этот принцип построения ролевой модели самый очевидный и при этом наиболее сложный как в разработке, так и в дальнейшей поддержке. При этом он наиболее полон в части покрытия ролями потребностей сотрудников.
Основную сложность разработки модели проще пояснить на конкретном примере: если компания большая, в ней может насчитываться около 15 типов бухгалтеров, из них 5 – в одном подразделении. При этом отличия будут только в коде должности. Еще одной сложностью является высокая подвижность оргштатной структуры: в связи с различными бизнес-задачами в течение года она может полностью поменяться, и ролевую модель придется значительно дорабатывать. Несмотря на эти недостатки, подход хорошо подходит компаниям, где жестко соблюдаются регламенты и правила и ведется строгий контроль предоставленного доступа.
Роли на базе функциональных задач. Метод наиболее оптимален с точки зрения соотношения результатов и затраченных усилий. Для построения этого типа ролевой модели в компании выделяют основные и наиболее часто встречающиеся группы ИТ-ролей для запроса, далее они выделяются в отдельные бизнес-роли (например, «доступ в интернет», «годовая отчетность 2016»), которые сотрудник может запрашивать самостоятельно по мере необходимости. Подход в лучшем случае покрывает 70–80% необходимого доступа, оставшиеся роли сотруднику придется набирать из ИТ-ролей.
Гибридная модель. Гибридный подход совмещает 2 предыдущих принципа. Разработка модели для базовых должностей, например, «Кассир», «Бухгалтер», «Инженер», идет следующим образом: выбираются минимальные наборы прав доступа, которые обычно содержат базовые полномочия для этих должностей и назначаются при приеме на работу, а все необходимые сверх этого доступы запрашиваются из функциональной модели или ИТ-ролей. Гибридная модель наиболее востребована на российском рынке, т.к. она гибка в построении и поддержке, умеренна по ресурсным затратам, удобно автоматизируется системами контроля доступа.
Для выделения первоначальной ролевой модели можно использовать специализированное ПО, но, к сожалению, такие решения довольно сложны в установке и настройке. Кроме того, как правило, они очень дороги и не всегда дают нужный результат, т.к. их алгоритмы являются черным ящиком и не могут быть оптимизированы под конкретные форматы, использующиеся на российском рынке. Для решения этой проблемы мы реализовали собственный инструмент. В него на вход загружаются данные оргштатной структуры и полномочия сотрудников, а на выходе выдаются 2 вида отчетности: перечень набора ролей для каждой должности из оргструктуры и перечень типовых ролей, которые востребованы у большинства сотрудников компании. На эти отчеты уже намного удобнее накладывать правила разделения полномочий (SoD) и дорабатывать их под требования и регламенты компании.
Еще раз отметим, что построение ролевой модели и дальнейшие регламенты по ее поддержанию позволяют не только снизить риски внутреннего мошенничества, упростить процессы управления и контроля назначения прав доступа, но и получить максимальный эффект от внедрения IdM-системы и упростить дальнейшее сопровождение всех ИС компании в части управления доступом.
