Построение ролевой модели управления доступом

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

Первый сценарий 

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

Также этот сценарий оптимален, если ролевой подход формируется в только что внедренной системе с нуля.

Вот как строится работа в этом случае:

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

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

Второй сценарий 

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

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

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

Выстраивание ролевого управления по второму сценарию

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

Готовые ролевые матрицы должны быть утверждены представителями службы безопасности и руководителями. После согласования они будут служить базой для назначения доступа в рамках сформированных ролей и фигурировать в плане автоматизации процессов доступа к ИС.

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

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

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

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

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

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

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

Какие функции могут выполнять IdM/IGA-системы:

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

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

• с помощью различных методик сравнивать полномочия разных пользователей;
• выявлять совпадающие полномочия для конкретных категорий сотрудников;
• анализировать и согласовывать совпадающие полномочия.

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

Реализация регламента в отношении прав доступа

Это как раз тот момент, когда в организации стартует «свежевнедренная» структура, с учетом которой будут раздаваться, редактироваться и блокироваться пользовательские права.

Несколько положений из регламента:

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

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

Также в регламенте обязаны присутствовать положения, касающиеся предоставления и отзыва прав доступа к ИС для внешних сотрудников. Очень часто данные о них не фиксируются в кадровых источниках, поэтому не обеспечиваются должные меры контроля. И тут снова на помощь придут IdM/IGA-решения. У внешних работников не получится завладеть доступом к ИС обходными путями, а по истечении договора с подрядчиками права будут немедленно отозваны. 

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

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

В каких случаях потребуются корректировки:

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

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

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

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

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

Заключение

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

Чем еще будет полезен ролевой принцип:

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

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

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

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