Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: реализация стандарта управления доступом RBAC Policy Enhanced

Опубликовано 30 мая 2016
Рубрики: Вопрос из зала, Управление доступом и IDM
Комментарии

Станислав задаёт вопрос по реализации стандарта управления доступом INCITS 494-2012:

Добрый день!

Не подскажете, на текущий момент известны какие-нибудь реализации стандарта INCITS 494-2012 (Role Based Access Control Policy Enhanced), или подходы к реализации, поддержка в фреймворках? Интересует именно реализация динамических ограничений (в частности, на основе атрибутов).

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

У нас в проекте используется классический RBAC (без расширений). Небольшой пример ролей и привилегий из нашего проекта "Роль{permission1, …}":
* Врач{чтение_своих_пациентов}
* Гл.Врач{чтение_своих_пациентов, чтение_пациентов_в_своей_организации}
* Статистик{чтение_отчет_#1_по_своим_пациентам}
* Гл. статистик{чтение_отчет_#1_по_пациентам_в_своей_организации}

Динамически добавляемые привилегии (в зависимости от типа организации):
* чтение_пациентов_в_подчиненных_организациях
* чтение_отчет_#1_по_пациентам_в_подчиненных_организациях

Динамические ограничения:
* Федеральный округ — чтение пациентов/формирование отчета_#1 ограничено конкретным федеральным округом
* Федеральный субъект – чтение пациентов/формирование отчета_#1 ограничено конкретным федеральным субъектом

Понятно, что эти ограничения можно представить в виде привилегий:
* чтение_пациентов_региональный уровень
* чтение_пациентов_федеральный уровень

Однако, по мере усложнения требований к доступу, становится труднее поддерживать решение, основанное на таком подходе.
К примеру, если добавиться временное ограничение: "Роль может выполнять операцию над объектом только по прошествии определенного времени после события". Очевидно, такое ограничение будет сложно реализовать через привилегии. А раз так, то почему бы ограничения: "мои_пациенты", "моя_организация", "подчиненные_организации", "региональный_уровень", "федеральный_уровень", "привязка ко времени" не вынести в отдельный механизм?

Я так понял, стандарт INCITS 494-2012, а точнее его раздел, посвященный динамическим и статическим ограничениям, должен как раз решать данную задачу?

ОБУЧЕНИЕ
Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Также по теме:

Комментариев: 9

  • Денис Денисов

    Очевидно, такое ограничение будет сложно реализовать через привилегии. А раз так, то почему бы ограничения <…> не вынести в отдельный механизм?

    Станислав, думаю, что Вы рассуждаете в точности, как создатели стандарта RBAC PE (INCITS 494-2012), расширившие его относительно базового стандарта (INCITS 359-2012) возможностями использования внешних политик. Используя этот механизм, бизнес-правила, текущие значения определённых атрибутов можно передавать в RBAC. В зависимости от значения атрибута можно настроить запрет на использование роли или конкретных прав доступа. Как мне известно, в IDM-продуктах крупных вендоров это реализовано.

    • Станислав

      Денис, спасибо за ответ!

      Похоже простого решения в реализации данного механизма нет, т.е. вопрос уже переходит на уровень выбора между использованием IDM системы и собственной реализацией данного механизма.

  • Андрей

    Тут, мне каежтся, проблема глубже.

    Ролевой принцип должен идти ПОСЛЕ перехода на ПРОЦЕССНУЮ модель управления. И роли должны формализовываться из модели процессов. Я не могу утверждать точно, но есть большое подозрение, что роли у вас взяты из штатного расписания, а это принципиальная ошибка и все проблеммы вытекают именно из этого. Хотя, так происходило на ВСЕХ проектах по IDM, что я видел. Что касаемо самого вопроса, то тут, опять таки, могут помочь инструменты, используемые при автоматизации процессов, так называемые Business Rules Management, системы принятия решения. На сегодня используется две модели – матрица принятия решений и/или последовательность IF-THEN. Их вполне можно использовать для динамического присвоения ролей. Но я все равно бы начал с посторения и анализа моделей бизнес процессов:)))

    • Станислав

      Андрей, добрый вечер!

      Спасибо за ответ!

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

      Я так понял, Вы имеете ввиду еще и матрицу доступа (привилегия x фио) и ее анализ на основе которых могут быть выделены роли?

      • Андрей

        Станислав,

        Нет, я имел ввиду один из методов, реализуемых в системах Business Rules Management. Т.е. это более общий случай. И там матрица используется не только как матрица принятия решения о доступе, а для принятия любого бизнес решения. Я думаю такой инструмент мог бы вполне вам подойти для динамического назначения ролей. Инструмет как правило позволяет использовать для оценки любое количество параметров – ФИО, время суток, местоположение,  и т.д. 

        • Станислав

          Да, Андрей, теперь понял.

          Посмотрел open source решения, оказывается и такие есть – JBoss Drools

          Еще раз спасибо за подсказку!

    • Станислав

      <<<<<<<<<<<<<<<<<<

      Ролевой принцип должен идти ПОСЛЕ перехода на ПРОЦЕССНУЮ модель управления. И роли должны формализовываться из модели процессов

      <<<<<<<

      Андрей,

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

      Например, если через Модель Предметной Области можно управлять изменениями предметной области, которые должны быть учтены в системе, то в области упраления доступом существуют модели (диаграммы, отчеты, схемы) через которые разработчик может управлять изменениями в правилах доступа?

  • Станислав

    Кстати, еще пара вопросов из области: графический интерфейс, фильтрация списка объектов, доступ к фильтру

    На допустимый набор фильтров могут влиять следующие факторы:
    1. Требование заказчика: нужен такой-то набор фильтров
    2. Доступ пользователя на чтение данных объектов: "мои_пациенты", "моя_организация", "подчиненные_организации", "региональный_уровень", "федеральный_уровень", "привязка ко времени"

    Вопросы:
    1. Фильтр, как объект доступа.
       Когда происходит чтение списка объектов, фильтр является одним из критериев ограничения зоны поиска объектов.
       А когда формируется набор фильтров на странице правильно ли рассматривать отдельный фильтр, как объект доступа по модели RBAC Policy Enhanced?

    По сути, фильтр – это измерение, а выбранное значение фильтра – это срез измерения (если говорить в терминологии многомерных данных).
    Тогда можно предположить, что правила RBAC Policy Enhanced должны ограничивать как сам допустимый набор измерений для фильтрации, так и диапазон срезов в контексте одного измерения.
    Т.е. если в политиках иное не определено, то по умолчанию доступны все измерения для фильтрации списка объектов

    2. Зависимости при вычислении доступа
    Если представить описание доступа к фильтру через функцию, верны ли будут следующие записи?
    доступ к фильтру F = доступ_функция_от(привилегия на чтение объекта, ограничения RBAC Policy Enhanced на привилегию)
    диапазон срезов фильтра F = срезы_функция_от(привилегия на чтение объекта, ограничения RBAC Policy Enhanced на привилегию)

     Если представить реализацию RBAC Policy Enhanced (к примеру, внешнюю IDM) в виде сервиса, то ее можно будет использовать не только на операционном уровне (по 3х уровневой архитектуре приложения DDD), но и на интерфейсном уровне, для вычисления доступных элементов графического интерфейса.

    3. Можете посоветовать какие-нибудь шаблоны проектирования, best practics, книжки по организации доступа на уровне графического интерфейса?

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.