Подготовка к построению ролевой модели

Сначала на простом примере разберемся, что такое управление доступом на базе ролей. Допустим, в крупном банке более ста тысяч сотрудников и каждый из них – субъект внутренних информационных ресурсов (объектов). Ресурсами могут быть информационные системы, приложения, базы данных, и их тоже может быть несколько десятков и даже сотен. Если умножить количество объектов на количество субъектов, получится число связей, которые необходимо построить, затем усердно контролировать. Вручную справиться с этими задачами нереально, поэтому на помощь придут роли – наборы определенных полномочий, которые нужны сотрудникам или группам работников для реализации бизнес-процессов. Причем одному пользователю может назначаться несколько ролей. В свою очередь, роли могут содержать как одно полномочие, так и очень много. Главное условие – роли должны иметь привязку к должностям, рабочим подразделениям или конкретным текущим задачам. 

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

Можно ли выстроить 100-процентную ролевую модель и обеспечить полным набором необходимых полномочий всех сотрудников на каждой должности? Это практически нереализуемо, но и не нужно. Ролевая схема динамична – она зависит от перемен в бизнес-деятельности, информационном окружении, организационной структуре. Также на изменения в полномочиях влияют негативные факторы: желание получать прибыль, невзирая на безопасность компании, нарушение должностных инструкций, отсутствие надлежащих ресурсов. С учетом всего этого, достаточно стремиться к ролевой модели, закрывающей около 80% потребностей сотрудников в базовых полномочиях в рамках назначенной должности. Недостающие 20% пользователи смогут запрашивать по факту необходимости с помощью заявок. 

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

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

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

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

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

Шаг 1. Формирование функциональной модели

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

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

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

Шаг 2. Аудит информационных ресурсов и подготовка плана приоритизации

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

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

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

Чтобы определить критичность ИС, необходимо проработать многочисленные вопросы:

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

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

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

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

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

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

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

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

Шаг 4. Фиксация характеристик текущего формата управления доступом

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

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

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

Шаг 5. Создание описания полномочий 

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

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

Какие сведения фигурируют в справочнике?

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

Шаг 6. Выгрузка сведений о работниках и их правах. Сопоставление информации с кадровыми источниками

Это итоговый этап перед внедрением новой схемы управления. В его рамках необходимо получить из ИС все сведения о работниках компании и их текущих правах. Задача решается в рамках одного из двух сценариев:

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

Обязательно выгрузить наименования «учеток» и ФИО сотрудников-владельцев, даты создания и последнего использования, статусы (активны/неактивны), список прав и ролей. После того как отчеты будут готовы, необходимо почистить перечень от старых заблокированных учетных записей, поскольку ролевое управление применяется исключительно в отношении активных клиентов сети (сотрудников).

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

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

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