Не так давно мы с моим коллегой, Александром Омельченко, провели вебинар, посвящённый современным подходам к управлению учётными записями и доступом. На нём в числе прочего мы рассказывали и о ролевой модели, как об одной из составляющих эффективного решения задачи управления доступом в компаниях и её преимуществах. Хочу продолжить начатое, немного детальнее рассказав о ролевом подходе, основываясь на существующих международных стандартах, которые посвящены ролевому управлению доступом (Role-Based Access Control, RBAC).
Хотел бы выделить три стандарта по теме, которые взаимоувязаны друг с другом:
- INCITS 359-2012 «Information Technology – Role Based Access Control»
- INCITS 494-2012 «Information technology – Role Based Access Control – Policy Enhanced»
- INCITS 459-2011 «Information Technology – Requirements for the Implementation and Interoperability of Role Based Access Control»
Первый стандарт содержит референтную модель ролевого управления доступом. Второй является, фактически, дополнением к первому в части обработки динамических ограничений. Третий описывает допустимые сочетания компонентов (функциональных наборов) и интерфейсы. О первых двух и пойдёт речь чуть подробнее.
INCITS 359-2012. Стандарт состоит из двух частей: а) референтная модель и б) административная функциональная спецификация.
Референтная модель определяет множества элементов, которыми оперирует стандарт: пользователи, роли, права доступа, операции и объекты (доступа). В её состав входят четыре компонента:
- ядро (Core RBAC)
- иерархичность (Hierarchical RBAC)
- статическое разделение обязанностей (Static Separation of Duty)
- динамическое разделение обязанностей (Dynamiс Separation of Duty)
Ядро – обязательный компонент при использовании подхода RBAC. Определяет минимально необходимый набор элементов, множеств элементов и связей для построения целостной системы. Реализует фундаментальное свойство подхода – объединение прав доступа в роли и затем назначение ролей пользователям (вместо прямой выдачи определённых прав доступа конкретному пользователю). Остальные компоненты RBAC независимы друг от друга и могут быть реализованы отдельно, за правильную компоновку их друг с другом отвечает третий стандарт в верхнем списке.
Иерархичность добавляет связи для обеспечения иерархии ролей. Роли располагаются по старшинству, нижестоящие наследуют от вышестоящих права доступа. Это удобно и упрощает администрирование – общие базовые права доступа в каких-либо ролях целесообразно вынести в одно множество, выделив в отдельную роль. Например, роль "Сотрудник" и "Главный инженер". В этом случае не нужно будет при описании каждой роли перечислять и в той, и в другой роли одинаковые права доступа. Достаточно будет указать, что роль "Главный инженер" наследует права доступа от роли "Сотрудник".
Статическое и динамическое разделение обязанностей добавляют ограничения в RBAC, что выражается в правилах назначения и сочетания ролей. Например, роль, в которой сотрудник осуществляет формирование заявок на проведение платежей, не совместима с ролью, в которой производится заверение проведения платежей.
Функциональная спецификация определяет наборы трёх типов команд (функций) для работы с элементами и конструкциями модели RBAC для каждого компонента и подробно описывает каждую команду:
- административные – для создания и работы с элементами множеств и связями при построении различных компонентов модели RBAC. Примеры: "AddUser", "DeleteUser", "AddRole", "GrantPermission" и т.д. За каждым названием скрывается свой алгоритм работы команды
- системные – для обеспечения работы конструкций в течение пользовательских сессий. Примеры: "CreateSession", "AddActiveRole", "CheckAccess" и пр.
- контрольные – проверка результатов выполнения административных команд. Примеры: "AssignedUsers", "RolePermissions", "UserPermissions", "UserOperationsOnObject" и пр.
INCITS 494-2012. Стандарт появился в ответ на критику "чистого" RBAC за его негибкость в условиях изменчивого окружения, отсутствие возможности работы с динамическими ограничениями, например, таких как: "день недели", "определённый период времени в сутках", "местоположение" и пр. Он является продолжением основного стандарта INCITS 359-2012, расширяя его возможности в части ограничений: не только разделение обязанностей (статическое и динамическое), но и обработка других типов ограничений. Стандарт позволяет внешним политикам (правилам и данным) создавать ограничения на уровне ядра RBAC, которые могут применяться к базовым множествам: пользователям, ролям, операциям, объектам и правам доступа. Стандарт также содержит референтную модель и функциональную спецификацию, во многом пересекающиеся с базовым стандартом.
Референтная модель состоит из "движка" RBAC (ядро RBAC) как основы и трёх дополнительных компонентов – интерфейсов: правила внешней политики, унифицированные функции стандарта INCITS 459-2011 и аудит.
Через интерфейс правил внешней политики ограничения из внешней среды поступают в движок RBAC. Это могут быть бизнес-правила, текущие значения определённых параметров и т.д. Движок RBAC может сам служить точкой принятия решения (policy decision point, PDP) либо использовать уже обработанные результаты других PDP.
Интерфейс аудита позволяет получать на выходе записи в результате работы движка RBAC. Примеры: использование прав доступа, отказ в исполнении запроса на доступ, применение ограничения.
Интерфейс унифицированных функций стандарта INCITS 459-2011 позволяет движку RBAC и внешней системе синхронизироваться в части используемых определений элементов и множеств.
Стандарт делит возможные ограничения на статические и динамические, и определяет следующие их типы:
| Тип ограничения | Описание |
|---|---|
| Роль-роль | Запрет на одновременное использование ролей |
| Пользователь-роль | Запрет пользователям исполнять данную пару ролей в одно и то же время |
| Атрибут | Запрет на использование роли или конкретных прав доступа в зависимости от значения атрибута |
Атрибутами могут быть: определённый период времени в сутках, местоположение, цель использования, класс пользователя, значение определённого типа данных, тип учётной записи.
| Тип ограничения | Описание |
|---|---|
| Роль-роль | Запрет на назначение роли конкретному пользователю |
| Пользователь-роль | Запрет определённым пользователям быть назначенными на данную пару ролей |
| Права доступа-права доступа | Запрет на использование комбинаций определённых прав доступа в конкретной роли |
| Права доступа-роль | Запрет на использование конкретных прав доступа в конкретной роли |
Функциональная спецификация стандарта содержит команды, которые дополняют базовый стандарт. Например, "GetRule", "ParseRule", "GetValue" и пр.
Таким образом, связка стандартов INCITS RBAC устанавливает общую терминологию в части ролевого метода управления доступом. Определяет элементы, множества, интерфейсы, команды, модели, которые затем можно использовать как при проектировании систем управления доступом на базе ролевого подхода, так и при анализе их функциональных особенностей.
ну очень хочется увидеть не теорию, а пример реализации ролевой модели в Shared Folder Windows ну хотя бы на 5 отделов с общим местом для всех (general public) и общими местами для кортежей из нескольких отделов (скажем 5-6 локальных public) + начальниками всех отделов со своими отдельными от подчиненными publiс'ами. В общем стандартаня задача для небольшой конторки…. Мда… а генеральный должен иметь доступ всюду….