Модели защиты информационных активов

Модель ролевого управления доступом (RBAC - Role-based Access Control), также называемая недискреционным управлением доступом (Nondiscretionary Access Control), использует централизованно администрируемый набор контролей, предназначенных для определения порядка взаимодействия субъекта с объектом. Этот тип модели разрешает доступ к ресурсам, основываясь на роли пользователя в компании. Это называют недискреционным подходом, поскольку назначение пользователю роли является неизбежным. Это означает, что если вам в компании назначена роль «Подрядчик», вы ничего с этим сделать не можете. Вы не определяете самостоятельно, какая роль вам будет назначена.

Более традиционное администрирование прав доступа основано на модели DAC, в которой управление доступом происходит на уровне объекта с использованием ACL. Этот подход более сложен, т.к. администратор должен перевести организационную политику компании в разрешения при настройке ACL. С ростом количества объектов и пользователей в компании у многих пользователей появляются (или остаются после изменения обязанностей) права доступа к некоторым ресурсам, которые им не требуются для работы. Это нарушает принцип минимальных привилегий и увеличивает риски компании. Подход RBAC позволяет избежать этого, так как разрешения управляются на уровне должностных ролей. В модели RBAC роль определяется в терминах операций и задач, которые она выполняет, тогда как в модели DAC описывается, какие субъекты могут иметь доступ к каким объектам.

Например, нам нужна роль аналитика. Мы разрабатываем эту роль, позволяя ей иметь доступ ко всем видам продукции и данным тестирования, а также, что более важно, определяем задачи и операции, которые эта роль может выполнять с этими данными. Когда пользователь, которому присвоена эта роль «Аналитик», делает запрос на доступ к новым результатам тестирования на файловом сервере, операционная система в фоновом режиме просматривает уровень доступа роли, прежде чем эта операция будет разрешена.

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

Модель RBAC лучше всего подходит для компаний с большой «текучестью» кадров. Если увольняется сотрудник, которому была назначена определенная роль, то новому сотруднику, который займет его место, просто назначается та же роль. Таким образом, администратору не нужно постоянно вносить изменения в ACL отдельных объектов. Ему достаточно создать определенные роли, настроить необходимые этим ролям права и разрешения, а затем назначить пользователям эти роли.[2]

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

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

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

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

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

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

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

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

Отражает организационную структуру и функциональные разграничения.

Существует два типа иерархий:

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

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

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

- Статическое разделение обязанностей (SSD - Static Separation of Duty) посредством RBAC. Это может использоваться для предотвращения мошенничества, предоставляя постоянный ограниченный набор привилегий (например, пользователь не может быть одновременно членом групп «Кассир» и «Контролер»).

- Динамическое разделение обязанностей (DSD - Dynamic Separation of Duties) посредством RBAC. Это может использоваться для предотвращения мошенничества, предоставляя ограничение набора возможных привилегий в рамках одной сессии (например, пользователь не может в рамках одной сессии использовать права «Кассира» и «Контролера», хотя он может быть одновременно членом обеих этих групп). Это немного сложнее. Рассмотрим пример: пользователь является одновременно членом групп «Кассир» и «Контролер», однако, если он входит в систему в качестве кассира, ему недоступны права контролера и наоборот. [6]

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

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

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

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

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

RBAC, MAC, DAC. Много путаницы возникает в отношении того, является ли RBAC разновидностью модели DAC или MAC. Различные источники содержат разную информацию на этот счет, но фактически RBAC является самостоятельной моделью. В 1960-х - 1970-х годах американские военные и NSA проводили много исследований модели MAC. Появившаяся в то же время модель DAC имеет свои корни в академических и коммерческих лабораториях. Модель RBAC, которая начала набирать популярность в 1990-е годы, может использоваться в комбинации с системами MAC и DAC. [2]

Заключение