8.3.1. Ядро rbac

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

Пользователи, роли, разрешения, операции и сессии определяются на основании политики безопасности.

• Имеются отношения «многие-ко-многим» между отдельными пользователями и привилегиями.

• Сессия является соответствием между пользователем и подмножеством назначенных ему ролей.

• Применяется традиционное, но более надежное управление доступом на основе групп.

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

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

8.3.2. Иерархический rbac

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

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

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

1. Ограниченные иерархии. Доступен только один уровень иерархии (например, Роль 1 наследует права Роли 2, но не других ролей).

2. Обычные иерархии. Доступно много уровней иерархии (например, Роль 1 наследует права Роли 2 и Роли 3).

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

Иерархии ролей определяют порядок наследования между ролями.

Управление доступом в модели RBAC может происходить следующими способами:

• Не-RBAC. Назначение прав пользователям производится напрямую в приложениях, роли не используются.

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

• Гибридное RBAC. Пользователям назначены роли, связанные с различными приложениями. Этим ролям назначены только выбранные права.

• Полное RBAC. Пользователям назначены корпоративные роли.

RBAC, MAC, DAC. Много путаницы возникает в отношении того, является ли RBAC разновидностью модели DAC или MAC. Различные источники содержат разную информацию на этот счет, но фактически RBAC является самостоятельной моделью.

В 1960-х – 1970-х годах американские военные и NSA проводили много исследований модели MAC. Появившаяся в то же время модель DAC имеет свои корни в академических и коммерческих лабораториях. Модель RBAC, которая начала набирать популярность в 1990-е годы, может использоваться в комбинации с системами MAC и DAC. Получить наиболее актуальную информацию о модели RBAC можно по адресу: http://csrc.nist.gov/rbac, где размещены документы с описанием стандарта RBAC и независимой модели, с целью прояснить прояснения этой постоянной путаницы.