Разработка ролевой модели прав доступа

Очень популярны заявки «Мне как у соседа», где вместо соседа вписывается ФИО коллеги, который, как кажется, исполняет схожие должностные обязанности. При этом никто не даст гарантии, что у этого коллеги права не избыточны. Этот ком продолжает расти, и в итоге у сотрудников накапливается огромное количество ненужных полномочий, которые сложно контролируются и могут давать доступ к конфиденциальной информации.

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

Оптимальным решением является предварительный проект по оптимизации ролевой модели прав доступа. Самое главное здесь – не увлекаться: часто ответственные за проект стараются «распихать» 100% всех прав доступа по бизнес-ролям, чтобы при перемещении по должности все роли в ИТ-системах выдавались строго в соответствии с должностью сотрудника и его позицией в оргштатной структуре компании. Этот подход не рационален. Наша практика показывает, что после включения в бизнес-роли ?80% ИТ-ролей затрачиваемые временные и финансовые ресурсы резко возрастают, и если вовремя не остановиться, на проект можно потратить большое количество ресурсов и так его и не завершить.

Рис. 1. Зависимость ресурсных затрат от полноты ролевой модели

Ролевые модели чаще всего разрабатываются в соответствии со следующими методологиями:

1. Должностная ролевая модель – выделение ролей на базе должностных обязанностей сотрудников.
2. Функциональная ролевая модель – выделение ролей на базе функциональных задач.
3. Гибридная модель – совмещаются подходы должностной и функциональной ролевой модели.

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

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

Роли на базе функциональных задач. Метод наиболее оптимален с точки зрения соотношения результатов и затраченных усилий. Для построения этого типа ролевой модели в компании выделяют основные и наиболее часто встречающиеся группы ИТ-ролей для запроса, далее они выделяются в отдельные бизнес-роли (например, «доступ в интернет», «годовая отчетность 2016»), которые сотрудник может запрашивать самостоятельно по мере необходимости. Подход в лучшем случае покрывает 70–80% необходимого доступа, оставшиеся роли сотруднику придется набирать из ИТ-ролей.

Гибридная модель. Гибридный подход совмещает 2 предыдущих принципа. Разработка модели для базовых должностей, например, «Кассир», «Бухгалтер», «Инженер», идет следующим образом: выбираются минимальные наборы прав доступа, которые обычно содержат базовые полномочия для этих должностей и назначаются при приеме на работу, а все необходимые сверх этого доступы запрашиваются из функциональной модели или ИТ-ролей. Гибридная модель наиболее востребована на российском рынке, т.к. она гибка в построении и поддержке, умеренна по ресурсным затратам, удобно автоматизируется системами контроля доступа.

Для выделения первоначальной ролевой модели можно использовать специализированное ПО, но, к сожалению, такие решения довольно сложны в установке и настройке. Кроме того, как правило, они очень дороги и не всегда дают нужный результат, т.к. их алгоритмы являются черным ящиком и не могут быть оптимизированы под конкретные форматы, использующиеся на российском рынке. Для решения этой проблемы мы реализовали собственный инструмент. В него на вход загружаются данные оргштатной структуры и полномочия сотрудников, а на выходе выдаются 2 вида отчетности: перечень набора ролей для каждой должности из оргструктуры и перечень типовых ролей, которые востребованы у большинства сотрудников компании. На эти отчеты уже намного удобнее накладывать правила разделения полномочий (SoD) и дорабатывать их под требования и регламенты компании.

Еще раз отметим, что построение ролевой модели и дальнейшие регламенты по ее поддержанию позволяют не только снизить риски внутреннего мошенничества, упростить процессы управления и контроля назначения прав доступа, но и получить максимальный эффект от внедрения IdM-системы и упростить дальнейшее сопровождение всех ИС компании в части управления доступом.