Правильная разработка и настройка ролевой модели прав доступа
Информационная безопасность Информационная безопасность

Как правильно построить ролевую модель управления доступом

Главная>Информационная безопасность>Разработка ролевой модели прав доступа
Информационная безопасность Тема номера

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

Дата публикации:
12.02.2016
Посетителей:
3236
Просмотров:
2880
Время просмотра:
2.3

Авторы

Автор
Павел Кудрин В прошлом - руководитель группы внедрения IdM-решений компании «Инфосистемы Джет»

Как правильно построить ролевую модель управления доступом?

Если компания активно использует информационные системы и у нее большой штат сотрудников, она неизбежно сталкивается с проблемой роста полномочий, которые доступы для запроса пользователям. В некоторых системах количество таких полномочий (ИТ-ролей) исчисляется десятками тысяч, например, в SAP ERP или Oracle ERP количество ИТ-ролей может достигать 250 тысяч. Разобраться в этом списке обычному пользователю очень трудно.

 

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Уведомления об обновлении тем – в вашей почте

Так сложилось, что не получилось! Правильный подход к внедрению IdM

Как осуществляется подготовка к IdM-проектам и почему стандартный подход не всегда работает? Какие этапы должна включать подготовка? Что дает аудит перед стартом IdM-проекта?

"Разрешите представиться"

За старомодными оборотами «разрешите представиться» и «разрешите вам представить» обнаруживаются технологические приемы идентификации личности

Новые возможности Forefront Identity Manager 2010

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

Oracle Identity Managemeht – комплексные решения

Существенную роль в обеспечении успеха проекта играет правильный выбор технологической платформы

Первое российское исследование рынка систем управления доступом (IdM)

Настоящее исследование посвящено рынку систем управления доступом – Identity Management (IdM) или, как их часто называют в последнее время, Identity Governance & Administration (IGA)

Система IdM: опыт эксплуатации

Система управления правами доступа эксплуатируется в Банке Москвы уже больше двух лет. Об опыте ее использования рассказывают Евгений Горбачев, начальник Управления информационной безопасности и Андрей Петрусевич, эксперт Управления информационной безопасности Банка Москвы.

Внедрение системы IdM за 10 шагов

Проекты по внедрению IdM-систем иногда сопровождаются большими усилиями, срывами запланированных сроков и бюджетами, превышающими сумму, которая планировалась вначале

Вопрос полномочий: как выстроить процесс управления доступом в компании

Любая современная информационная система (ИС) имеет встроенные средства контроля доступа

Экономическая эффективность IdM

Проекты внедрения IdM зачастую требуют больших вложений, и часто у заказчиков возникают вопросы

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня