Возможности ролевой модели контроля доступа


 Permissions MessВ последнее время всё чаще можно услышать мнение, что внедрение ролевой модели контроля доступа позволит решить все проблемы 🙂 Так ли это на самом деле, что такое RBAC в теории и с помощью каких инструментов её можно реализовать на практике - вот вопросы, на которые мы попробуем ответить. В первой статье мы рассмотрим определяющие свойства ролевой модели контроля доступа и основные стандарты в этой области.Reference Monitor

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

На данный момент, наиболее известными и распространёнными политиками доступа являются дискреционные и мандатные. В случае дискреционного управления доступом (Discretionary Access Control, DAC) у каждого ресурса есть владелец, который определяет, кто еще может получить доступ к данному ресурсу. Наличие владельца соответствует повседневному опыту, но при этом нет формального контроля над потоками информации, так как владелец может не только предоставить доступ кому угодно, но и назначить нового владельца, который сможет выполнять аналогичные действия. Мандатный контроль доступа (Mandatory Access Control, MAC), традиционно используемый в государственных и военных структурах, не предполагает наличие владельца. Возможность доступа определяется на основании назначаемого доверенным лицом (администратором информационных потоков) уровня конфиденциальности ресурса и имеющегося у субъекта уровня допуска. Т.е. в данной модели пользователь не имеет полного контроля над ресурсами, которые он создает.

Несколько позже, чем DAC и MAC, появилась ролевая модель контроля доступа (Role Based Access Control, RBAC). Роль это должность (позиция) сотрудника в организации, связанная с его полномочиями и ответственностью. За счёт того, что привилегии не предоставляются пользователю напрямую, и нет заранее предопределенных ограничений в потоках информации, появляется возможность определять права доступа к ресурсам как с помощью дискреционных, так и мандатных политик доступа [1].

Роли на уровне организации меняются значительно реже, чем происходят переводы сотрудников или смена их обязанностей. Благодаря этому, а также снижению сложности управления и количества ошибок за счет меньшего количества назначений, чем при назначении индивидуальных привилегий отдельным пользователям, можно существенно сократить затраты на контроль доступа в крупных компаниях. Также можно сократить количество ресурсов, необходимое для аудита, используя иерархии и возможности разделения обязанностей. Впечатляющие данные представлены в исследовании, спонсированном NIST, о сохранении 6 миллиардов долларов для американской экономики за 16 лет использования RBAC и о достижении возврата инвестиций с показателем 249 к 1.

Многие продукты, например, Exchange, Lync, Hyper-V, большинство IdM-систем и баз данных реализуют RBAC. Но реализация самой ролевой модели контроля доступа, ролей и их свойств может значительно отличаться. Какие же свойства объединяют различные реализации RBAC и отличают ее от других моделей контроля доступа?

В модели, разработанной в NIST, которая легла в основу стандарта ANSI/INCITS 359-2004, определены четыре уровня RBAC:

1. Flat RBAC,

2. Hierarchical RBAC,

3. Constrained RBAC,

4. Symmetric RBAC.

Для первого уровня (Flat RBAC) требуется реализация базового принципа – роли назначаются пользователям, а разрешения назначаются ролям, при этом все связи могут быть многие-ко-многим. Кроме того требуется, чтобы можно было просмотреть какие роли назначены конкретному пользователю и кому назначена конкретная роль. Модель NIST не ограничивает возможность назначения разрешений напрямую пользователям, и не выдвигает явных требований к поддержке сессий, кроме наличия возможности активировать несколько ролей одновременно. Под сессией подразумевается конкретный вход в систему для выполнения операций. В ролевой модели в рамках разных сессий пользователь может активировать все или только необходимые роли. Традиционный подход к контролю доступа на основании групп, который используется практически повсеместно, по сути, является реализацией Flat RBAC.

Roles HierarchyКаждый последующий уровень добавляет одно дополнительное свойство. На втором уровне (Hierarchical RBAC) появляется требование к поддержке иерархий, что позволяет структурировать роли. Системы, реализующие данную модель, могут поддерживать, как иерархии в виде простых деревьев, так и произвольные отношения частичного порядка.

На следующем уровне (Constrained RBAC) добавляется требование к обеспечению разделения обязанностей (Separation of duties или Segregation of duties (SoD)). Ограничение списка ролей, которые могут быть назначены пользователю одновременно с другими ролями, позволяет снизить риск ошибок и злонамеренных действий. Простейший пример реализации требований SoD - подача и одобрение заявки или авансового отчета не должны выполняться одним и тем же лицом. Невозможность назначить пользователю две конфликтующие роли называют статическим разделением обязанностей (static SoD), а невозможность одновременной активации уже назначенных конфликтующих ролей называют динамическим разделением обязанностей (dynamic SoD).

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

В стандарте ANSI/INCITS 359-2012 в дополнение к 4 уровням, вводятся дополнительные свойства, такие как авторизация на основании атрибутов [2]; политики, применяемые в реальном времени, и определение механизмов взаимодействия между ролевыми моделями в различных системах (RBAC Implementation and Interoperability (RIIS/ANSI INCITS-459)). Добавление в ролевую модель динамических ограничений, которые вступают в силу во время выполнения, позволяет реализовывать дополнительные проверки перед предоставлением доступа на основании атрибутов пользователя, времени суток или места доступа. Что из этих возможностей и дополнительных функций реализовано в BHOLD, решении добавляющем возможность ролевого контроля доступа к Microsoft Forefront Identity Manager 2010 R2, мы рассмотрим в следующих статьях.

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


[1] В статье «Configuring role-based access control to enforce mandatory and discretionary access control policies» (Sylvia L. Osborn, Ravi S. Sandhu, Qamar Munawer (2000)) рассматривается с помощью какого набора ролей и свойств ролевой модели можно реализовать другие модели контроля доступа. Во введении к упомянутой статье приведен список предшествующих работ с кратким описанием, позволяющий проследить историю развития ролевой модели и способы воспроизведения других моделей с ее помощью.

[2] Подробнее о добавлении в RBAC свойств от модели контроля доступа на основании атрибутов (Attribute-Based Access Control (ABAC)) можно прочитать в «Adding Attributes to Role Based Access Control» (D.R. Kuhn, E.J. Coyne, T.R. Weil (2011)).

Comments (0)

Skip to main content