Стандарты ролевого подхода к управлению доступом

Не так давно мы с моим коллегой, Александром Омельченко, провели вебинар, посвящённый современным подходам к управлению учётными записями и доступом. На нём в числе прочего мы рассказывали и о ролевой модели, как об одной из составляющих эффективного решения задачи управления доступом в компаниях и её преимуществах. Хочу продолжить начатое, немного детальнее рассказав о ролевом подходе, основываясь на существующих международных стандартах, которые посвящены ролевому управлению доступом (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-1

Иерархичность добавляет связи для обеспечения иерархии ролей. Роли располагаются по старшинству, нижестоящие наследуют от вышестоящих права доступа. Это удобно и упрощает администрирование — общие базовые права доступа в каких-либо ролях целесообразно вынести в одно множество, выделив в отдельную роль. Например, роль "Сотрудник" и "Главный инженер". В этом случае не нужно будет при описании каждой роли перечислять и в той, и в другой роли одинаковые права доступа. Достаточно будет указать, что роль "Главный инженер" наследует права доступа от роли "Сотрудник".

Статическое и динамическое разделение обязанностей добавляют ограничения в 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-2

 

 

 

 

 

 

 

 

 

 

Через интерфейс правил внешней политики ограничения из внешней среды поступают в движок RBAC. Это могут быть бизнес-правила, текущие значения определённых параметров и т.д. Движок RBAC может сам служить точкой принятия решения (policy decision point, PDP) либо использовать уже обработанные результаты других PDP.

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

Интерфейс унифицированных функций стандарта INCITS 459-2011 позволяет движку RBAC и внешней системе синхронизироваться в части используемых определений элементов и множеств.

Стандарт делит возможные ограничения на статические и динамические, и определяет следующие их типы:

Тип ограничения Описание
Динамические ограничения
Роль-роль Запрет на одновременное использование ролей
Пользователь-роль Запрет пользователям исполнять данную пару ролей в одно и то же время
Атрибут Запрет на использование роли или конкретных прав доступа в зависимости от значения атрибута

Атрибутами могут быть: определённый период времени в сутках, местоположение, цель использования, класс пользователя, значение определённого типа данных, тип учётной записи.

Тип ограничения Описание
Статические ограничения
Роль-роль Запрет на назначение роли конкретному пользователю
Пользователь-роль Запрет определённым пользователям быть назначенными на данную пару ролей
Права доступа-права доступа Запрет на использование комбинаций определённых прав доступа в конкретной роли
Права доступа-роль Запрет на использование конкретных прав доступа в конкретной роли

Функциональная спецификация стандарта содержит команды, которые дополняют базовый стандарт. Например, "GetRule", "ParseRule", "GetValue" и пр.

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

CleverIDM CleverIDM: Управление учётными записями и доступом

Новая услуга в партнёрстве с Аванпост.
 

Узнайте больше!

Комментарии и мнения

  1. Вячеслав Алпатов

    ну очень хочется увидеть не теорию, а пример реализации ролевой модели в Shared Folder Windows ну хотя бы на 5 отделов с общим местом для всех (general public) и общими местами для кортежей из нескольких отделов (скажем 5-6 локальных public)  + начальниками всех отделов со своими отдельными от подчиненными publiс'ами. В общем стандартаня задача для небольшой конторки... Мда... а генеральный должен иметь доступ всюду...

    1. Денис Денисов Автор

      Какие роли я вижу:

      1) "сотрудник" — права доступа только к general public, базовая роль;

      2) "сотрудник отдела №..." (по числу отделов) — наследует права доступа роли "сотрудник" и имеет доступ к локальному public своего отдела;

      3) "начальник отдела №..." (тоже по числу отделов) — наследует права доступа роли своих подчинённых к local public отдела и меет доступ к manager's public своего отдела;

      4) "генеральный директор".

      Это первое приближение, задачу можно уточнять.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26