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

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

Станислав задаёт вопрос по реализации стандарта управления доступом 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT