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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT