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

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

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

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

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

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

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

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

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

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

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

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

Все, кому интересно, как вообще появилось ролевое управление доступом, могут
нырнуть за экскурсом в историю
Если обратиться к истории, то впервые ИТ-сообщество задумалось о методах управления доступом ещё в 70-х годах XX века. Хотя приложения были тогда достаточно простыми, но, как и сейчас, всем очень хотелось удобно управлять доступом к ним. Предоставлять, менять и контролировать права пользователей – просто чтобы легче было понимать, какой доступ есть у каждого из них. Но в то время не существовало никаких общих стандартов, разрабатывались первые системы по управлению доступом, и каждая компания основывалась на свих собственных представлениях и правилах.

Сейчас уже известно много разных моделей управления доступом, но появились они не сразу. Остановимся на тех, которые внесли ощутимый вклад в развитие этого направления.

Первая и, наверное, самая простая модель – Дискреционное (избирательное) управление доступом (DAC – Discretionary access control). Эта модель подразумевает совместное использование прав всеми участниками процесса доступа. Каждый пользователь получает доступ к конкретным объектам или операциям. По сути здесь множество субъектов прав соответствует множеству объектов. Такая модель была признана слишком гибкой и слишком сложной для сопровождения: списки доступа со временем становятся огромными и трудно контролируемыми.

Вторая модель – это Мандатное управление доступом (MAC — Mandatory access control). По этой модели каждый пользователь получает доступ к объекту в соответствии с оформленным допуском к тому или иному уровню конфиденциальности данных. Соответственно объекты должны быть категорированы по уровню конфиденциальности. В отличие от первой гибкой модели, эта, наоборот, оказалась слишком строгой и ограничительной. Её применение не оправдывает себя, когда в компании множество разнообразных информационных ресурсов: чтобы разграничить доступ к разным ресурсам, придётся вводить множество категорий, которые не будут пересекаться.

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

Первую чётко описанную структуру ролевой модели предложили американские учёные Девид Феррайло и Ричард Кун из Национального института стандартов и технологий США в 1992 году. Тогда впервые появился термин RBAC (Role-based access control). Эти исследования и описания основных компонентов, а также их взаимосвязи легли в основу действующего по сей день стандарта INCITS 359-2012, утвержденного Международным комитетом по стандартам информационных технологий (INCITS).

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

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

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

Отдельно стоит сказать про управление доступом на основе атрибутов (ABAC — Attribute-based access control). Подход строится на предоставлении доступа с помощью правил совместного использования атрибутов. Эта модель может использоваться отдельно, но довольно часто она активно дополняет классическую ролевую: к определённой роли можно добавлять атрибуты пользователей, ресурсов и устройств, а также времени или местоположения. Это позволяет использовать меньше ролей, вводить дополнительные ограничения и сделать доступ минимально достаточным, а, следовательно, повысить безопасность.

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

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

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

Шаг 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

Источник: habr.com