Портал №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 не будет опубликован.

  • Рубрики

  •  
  • Авторы

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

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT