[Информационная безопасность, IT-инфраструктура, Управление проектами] Строим ролевую модель управления доступом. Часть вторая, «строительная»

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
20-Авг-2020 11:31

Цитировать

Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству». В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.

Для построения ролевой модели в информационной системе есть два способа.
Первый подход
Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.
Также этот подход хорош, когда вводится в эксплуатацию новая система и ролевые модели формируются с нуля. Для начала нужно разобраться вместе с ИТ–менеджером системы, каким образом предоставляются права, есть ли какие-то внутренние роли или группы в системе. Затем совместно с руководителями бизнес-подразделений и технологами ОТО нужно разработать роли, включив в них необходимые права. Затем созданные роли необходимо согласовать с владельцем системы от бизнеса, т.к. он отвечает за выполнение бизнес-процессов, с подразделением внутреннего контроля для исключения кросс-системных конфликтов и с подразделением безопасности, чтобы не нарушалась утверждённая политика безопасности компании. После этого систему можно вводить в эксплуатацию и назначать права в соответствии с утверждённой ролевой моделью.
Второй подход
Роли формируются из действующих прав, уже предоставленных сотрудникам. В большинстве случаев требуется сделать именно это, т.к. системы эксплуатируются достаточно давно и нужно разобраться с тем бардаком в правах пользователей, который накопился за много лет эксплуатации. Здесь есть свои особенности.
Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.
Строим ролевую модель по второму подходу
В нашей крупной финансовой компании мы строили ролевую модель по второму подходу, чтобы навести порядок в уже работающих системах. По тем из них, в которых пользователи имели немного прав, мы взяли очищенную выборку (только активных пользователей). Разработали шаблон заполнения ролевой матрицы для каждой системы: напомним, ролевая матрица – это роли (набор прав) в привязке к подразделениям компании и должностям в них. Шаблон направили владельцам этих систем для заполнения. Те в свою очередь собрали информацию с подразделений, в которых использовалась система, и вернули уже заполненный шаблон для дальнейшего согласования со службами ИБ и внутреннего контроля. Заполненный шаблон, а именно ролевая матрица затем используется в предоставлении доступа на основе ролей, а также включения в будущий проект автоматизации.
К сожалению, не бывает таких матриц и таких систем, где все права могут быть однозначно разбиты по ролям и роли привязаны к должностям. Поскольку в этом случае вы либо получите немного довольно универсальных ролей, где часть прав будет избыточна. Либо, наоборот, слишком много ролей, и это будет уже не ролевой, а персональный доступ на основе дискреционного метода, о котором мы писали в первой части. Часто в крупных организациях роли могут быть необходимы не для должности, а для конкретного функционала. Например, несколько сотрудников могут занимать одну и ту же должность, но выполнять разные функции. Поэтому имеет смысл часть одинакового функционала вносить в базовые роли, которые будут присваиваться по умолчанию. А часть уникальных функций сотрудника оставлять для оформления прав по отдельным запросам, которые направляются на согласование в установленном в компании порядке.
Пример шаблона для заполнения ролевых матриц
Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке.

На втором листе мы разместили справочник, который показывал наполнение ролей отдельными правами (полномочиями).

На третьем листе – матрицу SOD-конфликтов (запрета на возможное сочетание ролей).

Сразу скажу, что к теме SOD-конфликтов мы подошли в первом приближении, т.к. это отдельная большая активность со своим собственным процессом. Запрет на сочетание определенных полномочий может устанавливаться как в рамках отдельной роли, так и между ролями, и в кроссистемных взаимодействиях. Кроме того, важна настройка процесса работы с SOD- конфликтами и разработка сценариев реагирования на них. Это тема для отдельного рассмотрения.
Для тех систем, в которых много пользователей и структура прав довольно разнообразная, составить матрицу в ручном режиме очень непросто. Мы использовали для этих целей специализированные инструменты построения ролевой модели Role mining. Инструменты эти могут сильно отличаться логикой работы, стоимостью, удобством использования и другими характеристиками. Но принцип работы и цели у них общие — это сбор информации о текущих правах сотрудника в информационных системах, анализ повторяемости этих прав для сотрудников с одинаковыми атрибутами, объединение этих прав в роли и, в конечном итоге, построение некой базовой ролевой модели, которая отражает текущее положение дел.
Сейчас, по прошествии времени и работая в компании, которая разрабатывает ПО для управления доступом, я понимаю, что есть и более эффективные методы построения ролевых моделей в крупных системах. Чем раньше организация придет к использованию автоматизированных средств для наведения порядка, тем более гладко и безболезненно пройдёт процесс построения ролевых моделей. В этом случае автоматизированная система будет помощником или подспорьем в построении ролей. Внедрение автоматизированных систем управления доступом (IdM/IGA) нужно начинать с подключения кадровых источников и целевых систем для выгрузки данных и их мапинга и анализа. Используя специализированные инструменты, встроенные в решения по управлению доступом, можно с самого начала достаточно эффективно выстроить нужные процессы на основе автоматизации. Это значительно сократит трудозатраты и исключит шоковую терапию в будущем. Например, гораздо быстрее и эффективнее пройдёт процесс работы с учётными записями, а именно на первом этапе:

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

А уже на втором этапе использование автоматизированных систем управления доступом позволяет повысить эффективность работы с правами пользователей и построить ролевую модель, в частности:

применить различные методики сравнения прав у разных пользователей,
осуществлять автоматизированный Role mining и выявление совпадающих прав для отдельных категорий пользователей с последующим анализом и согласованием. Так гораздо быстрее и проще создаются необходимые матрицы прав доступа.

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

Права доступа определяются наличием / отсутствием ролевой модели по конкретной информационной системе. Как говорилось выше, выстроить ролевые матрицы сразу по всем ИС просто невозможно, нужно действовать постепенно, в соответствии с утверждённым планом.
Если утверждённой ролевой модели пока в системе нет, то права, как минимум, должны быть согласованы с руководителем подразделения и владельцем ресурса.
Если ролевая модель разработана и утверждена, то права назначаются/изменяются на её основе.
Должен быть определён порядок согласования, предоставления и аннулирования нестандартных прав.
В любом процессе есть исключения и ограничения. Поэтому необходимо учесть взаимозаменяемость сотрудников в период отсутствия, незаполненные вакансии, а также отдельные функциональные роли, которые предоставляются по запросам.
Однако и в случае с исключениями необходим строгий порядок и контроль персональной авторизации. Во-первых, она должна быть обоснована и согласована в соответствии с утверждённым регламентом.
Во-вторых, по тем правам, которые предоставляются на время, должна быть разработана процедура их своевременного отзыва. Здесь также очень помогут IdM/IGA-системы, которые позволяют заложить и автоматизировать маршруты согласования нестандартных прав, реализовать процедуру автоматического прекращения доступа по истечение заданного срока. А отчётность, которую можно настроить в системе, позволит регулярно анализировать и оценивать ситуацию с персональными правами. Если таких прав становится слишком много, то есть повод пересмотреть подход совместно с владельцем ресурса и доработать стандартные роли. Ведь судя по всему, они перестали обеспечивать потребности сотрудников, и их необходимо дополнить нужными правами для выполнения функционала в полном объеме.
В регламенте нужно закрепить порядок предоставления и аннулирования доступа к информационным системам внешним сотрудникам. По таким категориям сотрудников надо вести отдельный контроль, т.к. они отсутствуют в кадровом источнике и информация о них, как правило, фиксируется в отдельных списках чуть ли не вручную или не фиксируется вообще. Если же в компании уже применяется автоматизированная система управления доступом, то она является общим справочником по всем работникам, использующим ресурсы компании. В этом случае внешние сотрудники просто не смогут получить доступ к ресурсам компании в обход нее. Кроме того, по истечении договора подряда доступ будет своевременно заблокирован в автоматическом режиме.

Актуализация ролевой модели
Ролевая модель не может быть статичной. Она, как живой организм, должна адаптироваться под происходящие в организации изменения. Что служит поводом для её корректировки?
Первое – это изменение организационно-штатной структуры. В крупных организациях, в этом я убедилась на собственном опыте, такие изменения могут происходить практически ежедневно. Часто изменения связаны с переименованием подразделений и должностей. При этом функционал остаётся прежним, но, тем не менее, эти изменения должны отражаться в ролевой модели и все корректировки должны вноситься своевременно. Когда же происходит слияние подразделений или, наоборот, деление на отдельные группы/отделы, то изменения более глобальны. Они затрагивают функционал работников, который нужно пересмотреть, актуализировать функциональную модель и на её основе внести изменения в существующие роли. Или же разработать и внедрить новые роли в ролевую модель.
Второе – это изменение бизнес-процессов компании. Бизнес не может быть статичным: внедряются новые процессы и механизмы, которые позволяют совершенствовать работу каждого подразделения. Это улучшает обслуживание клиентов, повышает продажи, помогает достичь стратегических целей. Внедрение каждого нового бизнес-процесса должно учитываться в ролевой модели. Появятся новые роли, или же придется доработать имеющиеся, – и в них нужно будет включить новые опции и права.
Третье – это изменение системной архитектуры. На предприятиях периодически происходит вывод из эксплуатации старых систем и ввод в эксплуатацию новых. Допустим, старая система выводится из эксплуатации и функционал, который в ней выполняли сотрудники, должен быть переведён в новую систему. Для этого придётся провести ревизию всех ролей старой системы и их актуальности, проанализировать созданные роли новой системы и сделать матрицу сопоставления старых и новых ролей. Вполне возможно, что на какой-то переходный период эти роли будут существовать параллельно, пока весь нужный функционал не перенесут в новую систему и ролевая модель не будет доработана. Затем использование ролей старой системы можно будет прекратить, доступ пользователей аннулировать, а данные старой системы отправить в архив.
Все рассмотренные изменения говорят о том, что для поддержания актуальности ролевой модели нужен отдельный процесс. В нем следует учесть все активности организации, связанные с доступом к информационным ресурсам. Он должен включать процедуру обновления ролевой модели, которая планируется заранее, чтобы все необходимые изменения были сделаны вовремя. Это и инициирование заявки на изменение роли/ролей в автоматическом или ручном режиме, и согласование, и утверждение изменений и их ввод в эксплуатацию с актуализацией смежных процессов. Всё это должно быть зафиксировано в регламенте по ведению и обновлению ролевой модели, где также необходимо указать ответственных за каждый шаг процесса.
Помимо изменений в ролевой модели на основании вышеописанных причин нужен систематический плановый пересмотр прав. В частности, для финансовых компаний таких регулярных пересмотров требуют надзорные органы. Пересмотры позволяют выявлять недочёты в существующей модели прав и повышать контроль за полномочиями пользователей. Решение этой задачи значительно упрощают IGA/IdM-системы, которые позволяют автоматизировать процесс пересмотра (ресертификации) с заданной периодичностью.
Подведём итоги
Управление доступом с использованием ролевой модели повышает уровень информационной безопасности компании, т.к. доступ становится более прозрачным, управляемым и контролируемым. А также снижает нагрузку на подразделение ИТ в части его администрирования. Что станет делать проще с помощью ролевого управления доступом?

Вы сможете предоставлять одинаковые права многим сотрудникам, занимающим одинаковую должность или работающим в одном подразделении. Достаточно предоставить им одну и туже роль.
Вы сможете менять права для сотрудников одной должности быстро, в несколько кликов. Достаточно добавить или удалить права в составе общей роли.
Вы сможете строить иерархию ролей и устанавливать правила наследования полномочий, что упрощает структуру доступа.
Вы сможете вводить разграничения полномочий (SOD) – запрет на сочетание одной роли с другой.

Однако одним лишь построением ролевой модели не решить вопрос качественного и эффективного управления доступом в большой компании – это только один из шагов. Если построить ролевую модель и на этом успокоиться, через какое-то время она устареет, и грандиозная проделанная работа окажется абсолютно бесполезной. Почему?

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

Все перечисленные причины говорят о том, что важен именно комплекс мероприятий по управлению доступом. Нужны средства автоматизации, работающие процессы и механизмы, их поддержка, развитие, обновление и масштабирование в соответствии с жизненным циклом компании.
Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_itinfrastruktura (IT-инфраструктура), #_upravlenie_proektami (Управление проектами), #_rolevaja_model (ролевая модель), #_upravlenie_dostupom (управление доступом), #_idm, #_iga, #_roli (роли), #_kontrol_dostupa (контроль доступа), #_role_based_access_control, #_role_mining, #_blog_kompanii_rostelekomsolar (
Блог компании Ростелеком-Солар
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_itinfrastruktura (
IT-инфраструктура
), #_upravlenie_proektami (
Управление проектами
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 10:32
Часовой пояс: UTC + 5