Строим ролевую модель управления доступом. Часть вторая, «строительная»

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



    Для построения ролевой модели в информационной системе есть два способа.

    Первый подход


    Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.

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

    Второй подход


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

    Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.

    Строим ролевую модель по второму подходу


    В нашей крупной финансовой компании мы строили ролевую модель по второму подходу, чтобы навести порядок в уже работающих системах. По тем из них, в которых пользователи имели немного прав, мы взяли очищенную выборку (только активных пользователей). Разработали шаблон заполнения ролевой матрицы для каждой системы: напомним, ролевая матрица – это роли (набор прав) в привязке к подразделениям компании и должностям в них. Шаблон направили владельцам этих систем для заполнения. Те в свою очередь собрали информацию с подразделений, в которых использовалась система, и вернули уже заполненный шаблон для дальнейшего согласования со службами ИБ и внутреннего контроля. Заполненный шаблон, а именно ролевая матрица затем используется в предоставлении доступа на основе ролей, а также включения в будущий проект автоматизации.

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

    Пример шаблона для заполнения ролевых матриц


    Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке.

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

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

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

    Для тех систем, в которых много пользователей и структура прав довольно разнообразная, составить матрицу в ручном режиме очень непросто. Мы использовали для этих целей специализированные инструменты построения ролевой модели Role mining. Инструменты эти могут сильно отличаться логикой работы, стоимостью, удобством использования и другими характеристиками. Но принцип работы и цели у них общие — это сбор информации о текущих правах сотрудника в информационных системах, анализ повторяемости этих прав для сотрудников с одинаковыми атрибутами, объединение этих прав в роли и, в конечном итоге, построение некой базовой ролевой модели, которая отражает текущее положение дел.

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

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



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

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



    Претворяем в жизнь новый регламент прав доступа


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

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

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


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

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

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

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

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

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

    Подведём итоги


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

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

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

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

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

    Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights
    Ростелеком-Солар
    Безопасность по имени Солнце

    Комментарии 6

      0
      Отличная статья, спасибо.
      Разве что осталось неудовлетворенным любопытство:
      Чем проводите автоматизированный Role mining?
      О каких именно IdM/IGA системах речь?
        0
        Ранее, в финансовой компании, мы привлекали сторонних специалистов по договору на эти работы, и это были не специализированные решения IdM/IGA, а только часть автоматизации. Но теперь, по опыту в компании-вендоре, которая разрабатывает собственное решение IGA, есть понимание, что специализированный инструмент гораздо удобнее, т.к. решает задачу комплексно, встраивается в процессы по управлению доступом и приносит результат гораздо быстрее и качественнее.
        0

        Литературное творчество автора подкреплено практическими знаниями и умениями, что вызывает чувство глубокого уважения, но возникает ряд вопросов (мыслей) по реализации: 1) SOD определение запретов по пересечению ролей, как это сделать в крупной КО непонятно, аналитики и компетенций просто не у подразделений: СВА, УИБ, СВК и прочиХ, особенно это касается конфликта интересов, если с базовыми запретами на пересечения в части ИБ, например оператор/контролер -понятно, в остальном нет. 2) тему с role mining также хотелось бы попросить осветить более наглядно для народных масс, это полезно. 3) перевод функциональных обязанностей на язык прав и полномочий доступа опять же для мелких банков видится нереализуемым, ввиду отсутствия аналитиков в части АБС и мастер систем. С уважением, эксперт по ИБ при работе в условиях полной неопределенности.

          0
          1) Как было указано выше, тема SOD-конфликтов достаточно весомая и многогранная. Как говорит один наш коллега, потянет на диссертацию :) Она включает множество отдельных процессов: и анализ прав доступа на наличие конфликтов между ними и определение уровня риска, который может реализоваться в случае совмещения данных прав доступа. И принципы разграничения полномочий, включая не только конфликты в рамках одного процесса, но и кросс-функциональные конфликты. И назначение компенсационных процедур, т.е. действий, направленных на минимизацию рисков, возникающих в результате наличия конфликтующих полномочий, и т.п. Но необходимо понимать, что никакая автоматизация не будет эффективной, если в компании не выстроены эти процессы и не определены политики. Чтобы их правильно выстроить, конечно, нужны соответствующие компетенции, и здесь два варианта: либо выращивать свои, что может быть долго и дорого, либо воспользоваться помощью внешних профессиональных консультантов.

          2) Принцип работы инструментов «role mining» состоит в том, чтобы проанализировать имеющиеся у сотрудников текущие права доступа и выявить совпадающие права для сотрудников одной должности или одного подразделения для дальнейшего объединения этих прав в роли. Чтобы поближе познакомиться с этой темой и посмотреть, как это работает на практике, нужно обратиться к компании-производителю решения по управлению доступом и запросить демонстрацию. Практически все существующие на рынке решения имеют в своём арсенале такой функционал. Посмотрев несколько решений, вы сможете их сравнить.

          3) Да, действительно, иметь в своём штате аналитиков или технологов, занимающихся непосредственно разработкой ролевых моделей, может себе позволить достаточно крупная компания. Но на начальном этапе компании среднего размера могут запустить внутренний проект по наведению порядка в процессах управления доступом, со своим уставом/регламентом и рабочей группой, в которую войдут представители бизнеса, ИТ, безопасности и СВК. Или же можно воспользоваться услугами внешних компаний, предлагающих соответствующие сервисы.
          В любом случае, чем раньше начинать эти процессы, тем лучше, пока состояние «полной неопределённости» не увеличилось в масштабах и не привело к негативным последствиям.
            +1
            Раз уж про SOD, то давайте уточним. В вашем примере Роль_25 и Роль_3 в верхней и нижней части матрицы пересекаются по разному (2 и 26 тоже). Это опечатка или допустимый случай? Если так бывает, то можете привести пример?
              0
              Здравствуйте. Это ошибка, допущенная при верстке таблиц. Благодарим, что заметили, — уже исправили в статье.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое