Ролевая модель – актуальность, безопасность и эффективность!

Ролевая модель – актуальность, безопасность и эффективность сопровождения доступа

В крупной компании, где сотни информационных систем и тысячи пользователей управление доступом будет эффективно и безопасно только если оно основано на использовании ролевой модели.

Роли помогают оптимизировать процесс. Например, специалисту отдела оплаты труда на ежедневной основе требуются одни и те же права в бухгалтерской системе: открыть и закрыть счет, провести начисления или списания, просмотреть или скорректировать данные по сотруднику и т.п. В системе документооборота тому же бухгалтеру требуются права по созданию различных отчетов и отправки их в головную организацию. Если в компании много бухгалтеров и много систем в которых они постоянно работают, то все эти права можно объединить в одну роль и тогда, когда придет новый сотрудник на должность бухгалтера, можно будет в один клик назначить ему эту роль со всеми необходимыми полномочиями. Еще лучше если этот процесс будет автоматизирован и роль назначится автоматически, как только вышел приказ о принятии сотрудника на работу.

Через роли удобно менять доступ для сотрудников одной должности. Если поменялся функционал у бухгалтеров и нужно добавить новый отчет в финансовой системе, то достаточно будет за пару минут внести изменения в одну роль, а не менять доступ каждому сотруднику бухгалтерии в отдельности и тратить на это несколько часов или даже дней.

Роли, как правило, создают для определенных должностей или подразделений, включают в них все необходимые полномочия для выполнения сотрудниками должностных или функциональных обязанностей. Матрица, где хранится вся информация по созданным ролям и отношение их к различным должностям и подразделениям называется ролевой моделью (англ. RBAC – role Based Access Control).

Управление доступом на основе ролевой модели серьезно упрощает процесс выдачи прав. Количество ролей существенно меньше, чем количество пользователей. Например, в ритейловой компании, которая занимается продажей бытового оборудования и имеет множество филиалов по всей стране числятся тысячи продавцов. Набор прав у них у всех должен быть одинаковый. Для них будет создана одна роль, которая включает все их потребности.

Важным преимуществом ролевого управления доступом является разделение несовместимых полномочий (англ. SoD – Segregation of Duties). Сотрудник, имеющий определенную роль в системе, не может иметь одновременно другую роль, права которой не должны сочетаться с правами в первой. Например, кассир, который вводит финансовый платеж не должен иметь возможности подтвердить (проконтролировать) этот платеж. Функция контроля должна быть в руках другого сотрудника: менеджера или руководителя. Создание, внедрение и поддержание ролей в актуальном состоянии может быть сложным.

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

Основные шаги по созданию ролевой модели

Рассмотрим, как выглядит процесс по созданию ролевой модели в организации, где ранее права выдавались по требованию, т.е. по отдельным оформленным заявкам и практически не менялись с течением времени:

• Начать нужно с разработки концепции RBAC. На этом этапе нужно определить и донести до всех подразделений почему нужно внедрить ролевую модель, каковы долгосрочные планы по её использованию, какую пользу это принесёт компании, подразделениям и сотрудникам.

• Затем нужно собрать требования всех заинтересованных сторон. Опросить руководителей и бизнес-лидеров, чтобы понять их ожидания от процесса использования ролевой модели.

• Также нужно обратиться к владельцам ИТ-систем, чтобы зафиксировать как на данный момент хранится, предоставляется и аннулируется доступ в конкретное приложение. Зафиксировать какие роли существуют в самом приложении. Составить бизнес-ориентированное описание всех возможных прав доступа в конкретной системе, чтобы любому руководителю было понятно какие возможности предоставляет каждое полномочие и в каком режиме работает: просмотр или проведение активных операций (ввод, изменение, удаление).

• Применить процедуру Role-Mining – автоматическое объединение полномочий в роли, на основании обнаружения повторяющихся прав у сотрудников одной должности или подразделения. Полученные результаты могут быть использованы для выработки рекомендаций по созданию ролей.

• Затем проводится интеллектуальный анализ ролей. Автоматически созданные роли должны будут пройти процедуру согласования у руководителей, сотрудников информационной безопасности, внутреннего контроля или других регулирующих подразделений. На этом этапе роли могут быть скорректированы: дополнены необходимыми правами или будут исключены лишние полномочия.

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

• В завершение утвержденные роли вносятся в общую матрицу – ролевую модель и далее будут назначаться сотрудникам подразделений компании на основании кадровых назначений.

Лучше, если это будет выполняться в автоматическом режиме, через централизованную систему управления доступом. Либо в ручном режиме через управление доступом администратором.

На что обратить особое внимание

«Подводные камни», которые следует учитывать при разработке ролей. Создание ролевой модели – это не только Role-Mining и интеллектуальный анализ ролей. Очень многое зависит от состояния данных, на которых выстраивается система:

• Например, данные, поступающие из HR-системы. Роли мы создаем для конкретных должностей и подразделений, назначаем их работникам, приятым на эти позиции. Во многих организациях качество и количество кадровых данных оставляет желать лучшего. Например, могут отсутствовать или быть не полными такие данные, как атрибуты пользователя: географическое положение, код должности, код отдела. Иногда нет единой кадровой базы данных. Или данные в кадровой базе обновляются с большой задержкой: сутки и более. Эти моменты нужно заранее проработать, а данные привести к консистентному виду.

• В некоторых системах может быть многоуровневая структура доступа, права могут быть слишком детализированы или связаны в определенные структуры. Например, сложная структура каталогов Active Directory или слишком детализированные полномочия системы SAP. Исходя из этого нужно определить на каком уровне погружения осуществляется управление ролевой моделью. На уровне атомарных (детально гранулированных) прав или же на основании групповых объединений. Кроме того, для корректной работы иногда предоставление одного полномочия требует обязательного предоставления дополнительного второго полномочия. Например, чтобы предоставить доступ к определенной группе закрытых счетов, учетная запись сотрудника должна быть внесена в определенную таблицу разрешений, которая хранится в отдельном файле, отдельной библиотеке. Здесь будет полезно дополнительное участие в разработке ролевой модели сотрудников, которые непосредственно занимаются выдачей прав вновь принятым работникам и удалением прав уволенных сотрудников. Только они обладают полной информацией о том, как предоставляется доступ, чтобы он был корректным и работоспособным.

Не нужно стремиться построить 100% ролевую модель

Надо понимать, что построить 100% ролевую модель, обеспечив всеми необходимыми правами сотрудников каждой должности в крупной компании просто невозможно. Да это и не нужно. Ведь ролевая модель не может быть статичной потому, что она зависит от:

• Постоянно меняющегося окружения.

• Изменения бизнес-деятельности компании, которое влияет на изменение организационной структуры и функционала.

• Отсутствия полного обеспечения ресурсами.

• Несоблюдения должностных инструкций.

• Стремления к прибыли в ущерб безопасности.

Нужно строить ролевую модель, которая сможет закрыть до 80% потребностей пользователей в необходимых базовых правах при назначении на должность. Остальные 20% они смогут, если нужно, получить как дополнительные привилегии позже по отдельным заявкам.

Конечно, может быть выстроена ролевая модель приближенная к 100% покрытию всех потребностей. Это может быть в организациях, которые не подвержены частым изменениям, например, научно-исследовательский институт или военная структура, где все подчиняется четким правилам и безопасность стоит на первом месте. Бывает, что роли можно разработать так, чтобы они полностью закрывали весь функционал как в крупной коммерческой структуре, так и в рамках отдельно-взятого подразделения, работа которого является достаточно статичным и предсказуемым процессом, где очень мало различий в доступе среди сотрудников.

Актуализация ролевой модели

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

• Изменение организационно-штатной структуры. Например, было два отдела и их объединили в один. Естественно, что полномочия у сотрудников должны поменяться и соответственно роли должны обновиться.

• Изменение бизнес-процессов компании. В организацию внедряются новые процессы, которые совершенствуют работу персонала и помогают достижению стратегических целей. Например, появилась новая должность в подразделении с новым функциями – администратор по улучшению хозяйственной деятельности в отделе АХО. Для новой должности должна быть создана новая роль с необходимым набором полномочий в системах компании. Или же разработали новый перспективный отчет для руководителей операционных офисов банков и менеджеров. Отчет нужно включить в соответствующие существующие роли, созданные для этих должностей.

• Изменение ИТ-архитектуры. На предприятиях периодически происходит вывод из эксплуатации старых систем и ввод в эксплуатацию новых. Допустим, старая система выводится из эксплуатации. Соответственно функционал, который в ней выполняли сотрудники должен быть переведен в новую систему. Для этого придется провести ревизию всех ролей старой системы и их актуальности, проанализировать созданные роли новой системы, сделать матрицу сопоставления старых и новых ролей. Вполне возможно, что на какой-то переходный период эти роли будут существовать параллельно, пока весь нужный функционал не перенесут в новую систему и ролевая модель не будет доработана. Затем использование ролей старой системы можно будет прекратить, доступ пользователей аннулировать, а данные старой системы отправить в архив.

Для поддержки жизненного цикла ролевой модели и её актуализации необходим регламент, который будет учитывать описанные процессы и определять порядок действий по внесению изменений. Он закрепит ответственных лиц за каждый шаг процесса и сроки исполнения по реализации актуальных изменений.

Управление доступом с использованием ролевой модели повышает уровень информационной безопасности компании, т.к. доступ становится более прозрачным, управляемым и контролируемым. Также снижает нагрузку на подразделение ИТ в части его администрирования.