Долгое время квалифицированные интеграторы и пользователи с опытом применения решений западных вендоров считали, что одним из основных недостатков Avanpost IDM была модель управления доступом, не соответствовавшая в полной мере стандарту NIST RBAC model (INCITS 359−2012). Завершив наиболее приоритетные с точки зрения бизнеса задачи (например, миграцию продукта на Linux), департамент разработки Avanpost принялся за изменение подхода к управлению правами. Анализ имеющихся вариантов, поиск компромиссов и собственно разработка заняли весьма продолжительный период, но теперь, с выходом версии 6.5, он завершен, и компания готова предложить новую модель.

Введение
Основу управления доступом во всех IdM- (IAM-, IGA-) решениях составляет ролевая модель, описанная стандартом NIST RBAC model (INCITS 359−2012). Стандарт сам по себе является высокоуровневым и дает значительную свободу реализации, задавая лишь основные понятия, отношения между сущностями и механизмы.

Основу модели составляют пользователи, роли, разрешения и сессии. Роль является агрегатом разрешений, назначение ролей пользователю определяет список его эффективных полномочий. Разрешения, в свою очередь, относятся к операциям и к объектам, над которыми те совершаются. Когда в каком-либо приложении открывается пользовательская сессия, применяются одна или несколько ролей, определяющих динамический набор разрешений для нее. Расширения стандарта предполагают иерархию ролей (включая наследование разрешений), а также наличие статического и динамического разделения обязанностей (Separation of Duties, SoD).

Модель NIST ориентирована на реализацию в прикладных информационных системах, поэтому во внешней системе управления доступом она имеет естественные ограничения: например, сессии и динамические правила разделения ответственности остаются на уровне прикладных (управляемых с точки зрения IdM) систем.
Прежде основным инструментом управления доступом в решении Avanpost IDM была «Роль», а набор ролей составлял ролевую модель. Роль любого уровня (бизнес-, организационная, функциональная) конструировалась из набора полномочий управляемой информационной системы, например групп Active Directory или ролей SAP. Подобная организация ролевой модели приводила к дублированию полномочий в нескольких ролях и, соответственно, к дублированию правил, относящихся к ним — например, настроек совместимости (SoD-конфликты). Это было не единственным недостатком данного подхода; в числе прочих можно перечислить трудоемкость поддержки ролевой модели, сложности при делегировании управления ею на уровне бизнеса, построении процессов сертификации доступа, первичном устранении расхождений (реконсиляции) и т. д.

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

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

• Мандатная (MAC, mandatory access control) — разграничение доступа субъектов к объектам на основе метки конфиденциальности объекта и уровня допуска пользователя. Чаще всего встречается в государственных информационных системах.
• Дискретная (DAC, discretionary access control) — прямое разграничение доступа субъектов к объектам на основе списка управления доступом (ACL, Access Control List). Встречается в большинстве операционных систем и файловых хранилищ, системах документооборота, аналитических системах и т. д.
• Ролевая (RBAC, role-based access control) — описана выше, встречается в большинстве прикладных решений. Часто ролевая модель реализуется не в соответствии со стандартом; наиболее популярная модификация — это роли, предоставляемые в контексте какой-либо области (например, проекта в системе управления проектами или организационной единицы в ERP).
• Атрибутивная (ABAC, attribute-based access control) — разграничение доступа на основе анализа правил, оперирующих атрибутами субъекта и объекта доступа. Наиболее гибкая и в то же время сложно сопровождаемая модель из описанных. Любую другую модель можно выразить через ABAC. За счет сложности реализации и сопровождения в прикладных решениях встречается крайне редко, чаще всего — в обрезанном и сильно упрощенном варианте.

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

Глобальные права

Глобальное право представляет собой разрешение в терминах RBAC (permission), применяемое в контексте всей системы в целом. Например, это может быть «право входа в систему» или «право создания документа». Через глобальные права, помимо прямого соотнесения (маппинга) привилегий системы, эффективно выражаются ролевая и мандатная модели управления доступом на уровне информационной системы.

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

Права доступа к объектам

Право доступа к объекту — разрешение на операцию в контексте конкретного объекта или группы (класса) таковых, выполнение действий над ними в терминах RBAC (Ops ↔ Objs). Примером может служить ACL файлообменной папки, проектная роль в системе управления проектами и т. д. Механизм позволяет эффективно выразить дискретную модель управления доступом, а также различные многоуровневые модели и их комбинации.

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

• file:///C:/Temp — локальная папка или файл;
• https://www.avanpost.ru/products/avanpost-idm/ - веб-ресурс;
• //fileserver/documents — общая папка на сервере.

Роль в Avanpost IDM

Роль, как того и требует стандарт, является набором разрешений (в терминах Avanpost IDM — прав), но при этом позволяет агрегировать их из множества систем, отличаясь тем самым от положений документа NIST, который ориентирован на применение в прикладных решениях. В дополнение к прямой агрегации полномочий роль в Avanpost IDM позволяет определять их динамически, вычисляя выражения в контексте пользователя. Это дает возможность оптимизировать ролевую модель при наличии большого множества одинаковых с точки зрения информационной безопасности полномочий, существующих, например, по причине географической распределенности управляемой информационной системы. Помимо набора прав доступа роль в Avanpost IDM обладает и дополнительными настройками.

Привязка роли к организационной структуре

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

Область применения роли

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

Совместимость ролей

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

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

Организация иерархической ролевой модели

Главное изменение на уровне ролевой модели в версии 6.5 — возможность наследования ролей. Если ранее роль включала наборы прав из информационных систем, то теперь появилась возможность построить иерархическую ролевую модель любой глубины вложенности, где права и правила совместимости определяются вышестоящим (родительским) набором привилегий. Роли в Avanpost IDM не делятся явно на типы, как в некоторых других продуктах. Каждое множество разрешений может включать в себя полномочия информационной системы напрямую и при этом наследовать в дополнение к ним набор из другой роли; также роль, ссылающаяся на прямые полномочия информационной системы, может иметь организационные привязки и назначаться автоматически по кадровым событиям. Такое решение мы выбрали осознанно, чтобы поддержать совместимость с ролевой моделью пятой версии и не навязывать конкретную иерархию и определенный подход клиентам и интеграторам. Тем не менее, для эффективной организации ролевой модели, облегчения ее сопровождения и для возможности делегировать управление отдельными ее частями мы рекомендуем использовать возможности наследования.

ИТ-роль

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

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

Функциональная роль

Функциональная роль определяет набор разрешений, необходимых для выполнения отдельной атомарной бизнес-функции. На этом уровне и выше настоятельно не рекомендуется включать в роль права доступа напрямую: взамен стоит пользоваться наследованием. Например, функциональная роль «Коммуникация с B2B-клиентами» может быть сконструирована путем наследования ИТ-ролей «CRM\Доступ на чтение», «CRM\Создание клиента», «CRM\Изменение статуса клиента» и «Отправка внешней почты». Уровень функциональных ролей призван представлять организационную модель управления доступом, основанную на точке зрения бизнеса, и должен поэтому строиться в тесном сотрудничестве с соответствующими подразделениями или бизнес-аналитиками в крупных компаниях.

Организационная роль

Этот уровень определяет варианты доступа по умолчанию для групп пользователей — в первую очередь в соответствии с их положением в структуре компании, а также с учетом функциональных и ИТ-ролей. Например, организационная роль «Корпоративный бизнес\Отдел продаж продуктов\Специалист» может наследовать функциональную роль «Коммуникация с B2B-клиентами» и — в дополнение к ней — соответствующий набор ИТ-ролей (например, «Доступ к папке отдела»), а также иметь правила автоматического ее назначения на подразделение «Корпоративный бизнес\Отдел продаж продуктов» и на должность «Специалист». Уровень организационных ролей предназначен для автоматизации управления доступом по кадровым событиям (прием, перевод) и должен формироваться в сотрудничестве с подразделениями, для которых создается ролевая модель.

Бизнес-роль

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

Выводы

В версии Avanpost IDM 6.5 мы реализовали модель управления доступом, полностью соответствующую стандарту NIST RBAC model (INCITS 359−2012), устранив таким образом основные принципиальные недостатки продукта, а также реализовали ряд дополнительных процессов и сценариев, базирующихся на обновленном подходе к управлению доступом.

Александр Махновский, руководитель Департамента разработки Аванпост