Дина Погонышева - Безопасность информационных систем. Учебное пособие

Ролевая модель контроля доступа (RBAC)

Ролевой метод управления доступом контролирует доступ пользователей к информации на основе типов их активностей в системе

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

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

Для формального определения модели RBAC используются следующие соглашения:

S = субъект – человек или автоматизированный агент.

R = роль – рабочая функция или название, определяется на уровне авторизации.

P = разрешения – утверждения режима доступа к ресурсу.

SE = сессия – Соответствие между S, R и/или P .

SA = назначение субъекта (Subject Assignment). SA ⊆ S × R . При этом субъекты назначаются связям ролей и субъектов в отношении «многие ко многим» (один субъект может иметь несколько ролей, а одну роль могут иметь несколько субъектов).

PA = назначение разрешения (Permission Assignment). PA ⊆ P × R . При этом разрешения назначаются связям ролей в отношении «многие ко многим».

RH = частично упорядоченная иерархия ролей (Role Hierarchy). PH ⊆ R × R .

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

Основные достоинства ролевой модели:

1. Простота администрирования. В отличие от модели DAC нет необходимости прописывать разрешения для каждой пары «объект-пользователь». Вместо этого прописываются разрешения для пар «объект-роль» и определяются роли каждого пользователя. При изменении области ответственности пользователя, у него просто изменяются роли. Иерархия ролей также упрощает процесс администрирования. Иерархия ролей – это когда роль наряду со своими собственными привилегиями может наследовать привилегии других ролей.

2. Принцип наименьшей привилегии. Ролевая модель позволяет пользователю регистрироваться в системе ролью, минимально необходимой для выполнения требуемых задач. Запрещение полномочий, не требуемых для выполнения текущей задачи, не позволяет обойти политику безопасности системы.

3. Разделение обязанностей.

RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R/3 и множество других, эффективно применяющих RBAC.

С помощью RBAC могут быть смоделированы дискреционные и мандатные системы управления доступом.

Системы разграничения доступа

Конкретное воплощение модели разграничения доступа находят в системе разграничения доступа (СРД). СРД – это совокупность реализуемых правил разграничения доступа в средствах вычислительной техники или автоматизированных системах.

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

Основными требованиями к реализации диспетчера доступа являются:

1. Требование полноты контролируемых операций. Проверке должны подвергаться все операции всех субъектов над всеми объектами системы. Обход диспетчера предполагается невозможным.

2. Требование изолированности. Защищенность диспетчера от возможных изменений субъектами доступа с целью влияния на процесс его функционирования.

3. Требование формальной проверки правильности функционирования.

4. Минимизация используемых диспетчером ресурсов.