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

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

Сейчас я работаю в компании-вендоре программного обеспечения, в частности решений по управлению доступом. А мой опыт «из прошлой жизни» связан со стороной заказчика – крупной финансовой организацией. Тогда наша группа по контролю доступа в ИБ-департаменте не могла похвастаться большими компетенциями в IdM. Мы многому обучались в процессе, пришлось набить кучу шишек, чтобы выстроить в компании работающий механизм управления правами пользователей в информационных системах.

Объединив свой выстраданный в заказчике опыт с вендорскими знаниями и компетенциями, я хочу поделиться с вами по сути пошаговой инструкцией: как создать в крупной компании ролевую модель управления доступом, и что это даст на выходе. Моя инструкция состоит из двух частей: первая – готовимся строить модель, вторая – собственно строим. Перед вами часть первая, подготовительная.

N.B. Построение ролевой модели – это, к сожалению, не результат, а процесс. А точнее даже часть процесса созидания в компании экосистемы управления доступом. Так что настройтесь на игру вдолгую.

Сначала определимся – а что же такое управление доступом на основе ролей? Предположим, есть у вас крупный банк с десятками, а то и сотнями тысяч сотрудников (субъектов), у каждого из которых есть десятки прав доступа в сотни внутрибанковских информационных систем (объектов). А теперь умножьте число объектов на число субъектов – именно столько связей минимум вам нужно сначала выстроить, а потом контролировать. Реально это сделать вручную? Конечно нет – для решения этой задачи и появились роли.

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

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

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

Конечно, вы можете спросить: «А что, вообще не бывает 100% ролевых моделей?» Ну почему же, такое встречается, например, в некоммерческих структурах, которые не подвержены частым изменениям, – в каком-нибудь НИИ. Или в организациях ВПК с высоким уровнем защищённости, где безопасность стоит на первом месте. Бывает, и в коммерческой структуре, но в рамках отдельно-взятого подразделения, работа которого является достаточно статичным и предсказуемым процессом.

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

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

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

Все, кому интересно, как вообще появилось ролевое управление доступом, могут

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

Шаг 1. Создаем функциональную модель

Начать стоит с создания функциональной модели – верхнеуровневого документа, в котором подробно описан функционал каждого подразделения и каждой должности. Как правило, информация в него попадает из различных документов: должностных инструкций и положений по отдельным подразделениям – отделам, управлениям, департаментам. Функциональная модель должна быть согласована со всеми заинтересованными подразделениями (бизнес, внутренний контроль, безопасность) и утверждена руководством компании. Для чего нужен этот документ? Для того, чтобы ролевая модель могла на него ссылаться. Например, вы собираетесь строить ролевую модель на основе уже имеющихся прав сотрудников – выгруженных из системы и «приведённых к единому знаменателю». Тогда при согласовании полученных ролей с бизнес-владельцем системы можно сослаться на конкретный пункт функциональной модели, на основании которого в роль включается то или иное право.

Шаг 2. Аудируем ИТ-системы и составляем план приоритизации

На втором этапе следует провести аудит ИТ-систем, чтобы разобраться, как организован доступ в них. Например, в моей финансовой компании эксплуатировалось несколько сотен информационных систем. Во всех системах были некоторые зачатки ролевого управления, в большинстве – какие-то роли, но в основном на бумаге или в справочнике системы – они давно устарели, и доступ в них раздавался по фактическим запросам пользователей. Естественно, построить ролевую модель сразу в нескольких сотнях систем просто невозможно, надо с чего-то начинать. Мы провели углубленный анализ процесса управления доступом, чтобы определить уровень его зрелости. В процессе анализа выработали критерии приоритизации информационных систем – критичность, готовность, планы по выводу из эксплуатации и т.п. С их помощью выстроили очерёдность по разработке/актуализации ролевых моделей для этих систем. А затем – включили ролевые модели в план по интеграции с решением Identity Management, чтобы автоматизировать управление доступом.

Итак, как же определить критичность системы? Ответьте себе на следующие вопросы:

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

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

N.B. Крупные компании с развитыми ИТ-процессами наверняка знакомы с процедурой ИТ-аудита – IT general controls (ITGС), который позволяет выявить недостатки в ИТ-процессах и наладить контроль так, чтобы улучшить процессы в соответствии с best practice (ITIL, COBIT, IT Governance и др.) Такой аудит позволяет ИТ и бизнесу лучше понять друг друга и выработать совместную стратегию развития, проанализировать риски, оптимизировать затраты, выработать более эффективные подходы в работе.

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

Шаг 3 Создаем методологию

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

• общие корпоративные требования;
• требования к областям ИБ (зависят от направлений деятельности организации);
• требования к технологическим процессам (инструкции, матрицы доступа, методические указания, требования к конфигурациям).

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

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

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

Шаг 4. Фиксируем параметры существующей модели управления доступом

Составляем так называемый «паспорт системы» в части управления доступом. По сути, это опросник по конкретной информационной системе, в котором зафиксированы все алгоритмы управления доступом к ней. Компании, которые уже внедряли у себя решения класса IdM, наверняка знакомы с подобным опросником, так как именно с него начинается исследование систем.

Часть параметров о системе и владельцах перетекла в опросник из реестра ИТ (см. шаг 2, аудит), но добавились и новые:

• как осуществляется управление учётными записями (напрямую в БД или через программные интерфейсы);
• как пользователи выполняют вход в систему (с помощью отдельной учётной записи или с использованием учётки AD, LDAP или др.);
• какие уровни доступа к системе используются (уровень приложения, системный уровень, использование системой сетевых файловых ресурсов);
• описание и параметры серверов, на которых работает система;
• какие операции по управлению учётными записями поддерживаются (блокировка, переименование и т.п.);
• по каким алгоритмам или правилам формируется идентификатор пользователя системы;
• по какому атрибуту можно установить связь с записью о сотруднике в кадровой системе (ФИО, табельный номер или др.);
• все возможные атрибуты учётной записи и правила их заполнения;
• какие права доступа существуют в системе (роли, группы, атомарные права и др., есть ли вложенные или иерархические права);
• механизмы разделения прав доступа (по должностям, подразделениям, функционалу и др.);
• есть ли в системе правила разграничения прав (SOD – Segregation of Duties), и как они работают;
• как обрабатываются в системе события отсутствия, перевода, увольнения, обновления данных о сотрудниках и т.п.

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

Шаг 5. Создаем бизнес-ориентированное описание полномочий

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

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

• наименование полномочия, включая объект, к которому применяется право доступа;
• действие, которое разрешается делать с объектом (просмотр, изменение и т.п., возможность ограничения, например, по территориальному признаку или по группе клиентов);
• код полномочия (код и имя функции/запроса системы, которые можно выполнить с использованием полномочия);
• описание полномочия (подробное описание действий в ИС при применении полномочия и их последствий для процесса;
• статус полномочия: «Активно» (если полномочие назначено хотя бы одному пользователю) или «Не активно» (если полномочие не используется).

Шаг 6 Выгружаем из систем данные о пользователях и правах и сопоставляем с кадровым источником

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

Какие данные необходимо выгрузить:

• Наименование учётной записи
• ФИО работника, за которым она закреплена
• Статус (активна или заблокирована)
• Дата создания учётной записи
• Дата последнего использования
• Список доступных прав/групп/ролей

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

Затем, если у вас в компании нет автоматизированных средств закрытия доступа уволенным сотрудникам (такое нередко встречается) или есть лоскутная автоматизация, которая не всегда корректно срабатывает, нужно выявить все «мёртвые души». Речь об учётных записях уже уволенных сотрудников, права которых по какой-то причине не заблокированы, – их нужно заблокировать. Для этого сопоставляем выгруженные данные с кадровым источником. Кадровую выгрузку тоже нужно предварительно получить у подразделения, ведущего кадровую базу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор:

Людмила Севастьянова, эксперт центра продуктов Solar inRights компании «Ростелеком-Солар»

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

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

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

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

Как распределить роли?

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

Казалось бы, как вообще распределять права без ролевой модели? Однако даже сегодня в подавляющем большинстве российских организаций до начала внедрения систем IDM такие документы, как ролевая модель или матрица доступа, просто отсутствуют. А права доступа назначаются «по ситуации» – на основании запросов непосредственного руководителя или по аналогии с набором прав сотрудника, уже работающего на такой же должности. Естественно, это быстро выводит ситуацию из под контроля: сотрудники постепенно обрастают всевозможными правами, многие из которых им давно не нужны, так как соответствуют ранее занимаемым должностям, а то и вовсе никогда не требовались, но почему-то были назначены. Даже учетные записи уволенных сотрудников зачастую остаются активными. Трудно представить ситуацию более благоприятную для злоумышленника.

Именно поэтому создание ролевой модели – это первый этап любого IDM-проекта. Долгое время такие модели создавали вручную, интервьюируя руководителей и ключевых сотрудников и объединяя полученные результаты. Ясно, что этот подход крайне неэффективен. На сбор и систематизацию исходной информации в крупной организации с тысячами сотрудников и сотнями должностей могли уйти многие месяцы, а иногда и годы, не говоря уже о стоимости человеческих ресурсов, которые необходимо задействовать для выполнения этой задачи.

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

Но вот светлый день настал: последняя подпись на документе поставлена, и в организации есть, наконец, утвержденная ролевая модель. Но тут выясняется, что пока над ней работали, права доступа для большинства сотрудников изменились, процессы поменялись, информационная система изменилась. И утвержденный документ, созданный с таким трудом, можно смело отправлять в мусорное ведро. Очень неприятная ситуация, но, увы, распространенная. Поэтому именно опасения «провалить» создание корректной ролевой модели стали причиной отказа многих и многих организаций от запуска IDM-проектов.

К счастью, в последние годы ведущие IDM-вендоры реализовали и предложили заказчикам промышленное решение этой серьезной задачи. Таким решением стал специальный модуль (IDM Role Manager), позволяющий автоматизировать весь процесс создания ролевой модели. Не уходя глубоко в технические детали, суть работы этого модуля можно описать так: сначала автоматическое извлечение информации из конечных систем обо всех имеющихся в организации учетных записях и закрепленных за ними правах доступа, затем выгрузка из кадровой системы информации обо всех сотрудниках и их должностях. Затем выявление взаимосвязи собранных учетных записей с конкретными сотрудниками и их должностями и математический анализ реальных наборов прав доступа сотрудников, занимающих одинаковые должности. Цель – выявить наиболее часто встречающиеся у них прав, которые войдут в так называемую базовую роль для данной должности. Все не вошедшие в нее права каждого сотрудника оформляются в виде исключений. И, наконец, сравнение полученных базовых ролей между собой, позволяющее выявить полные совпадения и объединить такие роли в одну, назначаемую сразу нескольким категориям сотрудников.

Результат поразительный: с помощью модуля IDM Role Manager организация за считанные часы получает готовую для утверждения ролевую модель, основанную на реальных правах доступа, и абсолютно актуальную, так как временной разрыв между моментом сбора информации и готовностью документа практически отсутствует. Да и процесс согласования такой модели не занимает много времени, так как при ее создании отсутствовал какой-либо субъективизм исполнителя, система автоматически обобщила те права, которые уже были у сотрудников к настоящему моменту, и не имеет смысла их оспаривать.

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

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

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

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

Надежная и удобная реализация Workflow – это штатный функционал качественных IDM-систем. Но если на момент внедрения IDM в организации уже функционирует система электронного документооборота (СЭД), и сотрудники уже привыкли к ней, то технически возможно интегрировать IDM c СЭД в части согласования заявок, чтобы процесс утверждения проходил в привычной для пользователей системе, а его результаты автоматически обрабатывались IDM.

Все бы хорошо, но вышеописанный цикл согласований позволяет добавлять новые права в качестве исключений. Однако для качественного функционирования IDM и предотвращения «расползания» ролевой модели необходимо с определенной периодичностью (обычно 1–2 раза в год) проводить ресертификацию ролей, т.е. процесс актуализации ролевой модели.

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

Современные IDM-системы предлагают следующий функционал для организации процесса ресертификации. Во-первых, заявки на создание, изменение или удаление роли в рамках Workflow.

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

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

Во-вторых, матрица конфликтных прав / ролей. При проведении ресертификации очень важно проводить с ней сверку изменений.

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

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

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

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

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

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

Андрей Конусов, генеральный директор компании Аванпост
CNews|Аналитика