Comments 47
Очень наглядный конспект-лекция, причём понятный даже для непрофильных специалистов.
А инфраструктурные решения есть для ABAC? Чтобы интегрировать и пользоваться?
Есть некоторые реализации стандарта XACML, например решение от axiomatics.
Я так понимаю, что единственная проблема ABAC в том, что приходится поддерживать EAV модели для всех сущностей в системе, чтобы иметь возможность добавлять им новые свойства, влияющие на уровень доступа. Или есть еще какие-то?
А бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели.
Ага, а теперь попробуйте в ABAC применить правило «Менеджер при отсутствии в штатке начальника может смотреть заказы».
С помощью ролевой модели этого менеджера можно добавить в роль, а в ABAC?
А разве ролевая модель не полностью может быть выполнена на ABAC?
Ну и как такая попытка?
Ну и как такая попытка?
Субъект.Должность ="Менеджер"
Субъект.Начальник ="НУЛЛ"
Действие.Название= "Просмотр"
Объект.Тип = "Заказы"
Ролевая модель (одномерная) это частный случай атрибутной модели (многомерной).
Субъект.Начальник это уже еще один субъект, вычисление этого свойства во время работы требует программирования, что не относится к функциям администрирования. Либо, как выше в комментариях сказано, надо держать EAV на все случаи жизни, вплоть до перечисления суббот шаббата.
Программирование для этого не нужно. В бизнес-правилах вы оперируете теми атрибутами, которые и так уже должны быть в бизнес-модели. Все что вам требуется для проверки прав доступа, это найти значения перечисленных в правилах безопасности атрибутов и проверить их. Этим поиском и проверкой должна заниматься инфраструктура системы контроля доступа. Грубо говоря, в момент проверки прав вы отдаете все учавствующие в действии объекты и правила безопасности в систему контроля доступа. Она, в свою очередь, находит в объектах указанные в правилах атрибуты, получает их значения и проводит необходимые вычисления.
Если есть такой бизнес смысл, то где-то в системе должен быть признак присутствия или отсутствия начальника. Он и будет являться атрибутом используемым в правилах доступа.
К ссылкам в конце статьи хотел бы еще добавить «пять копеек» для сторонников JSON'а: JОSON Profile of XACML 3.0
Вообще говоря, еще до появления очередной пачки модных маркетинговых акронимов этот вопрос решался (и решается) следующим образом.
Доступ пользователя в системе разделяется на 2 независимых «измерения»:
1. Деятельность: какие действия ему разрешены. Для этого вводятся хорошо нам знакомые роли. Обычный и привычный инструмент управления ролями — матрица, где строки соответствуют пользователям, столбцы — ролям, а ячейки — чекбоксы. Роли в нулевом приближении можно рассматривать как типовой набор SCRUD (aka BREAD) actions.
2. Доступность: какие данные в системе ему доступны. Для этого дополнительно вводятся — как это сделано, например, в платных версиях SugarCRM — teams (или нечто аналогичное по сути). Заметим, что роли в SugarCRM тоже есть.
teams обычно это дерево, в котором каждый узел «видит» только данные, видимые ему непосредственно плюс видимые всем его поддеревьям до листьев включительно.
Таким образом, мы получаем для каждого отдельного пользователя отдельную матрицу (обычно подразумеваемую, так как роли управляются в одном месте, а teams в другом) где в воображаемых строках — teams, в которые может быть включен пользователь, в столбцах — разрешенные действия. Таким образом можно включить пользователя одновременно в team «склад» и «продажи», но в рамках team склада разрешить только R (смотреть остатки) а в рамках team продаж — открывать сделки и выписывать счета, но не видеть при этом счета, выписанные коллегами.
Сами данные, несомненно, конфигурируются так, что система знает, какие записи какой таблицы каким teams видимы.
Эта модель давно не нова и вполне достаточна для реальных применений (с учетом того, что пользователь может быть и включен в несколько teams и иметь несколько ролей), главное — вот та самая «вторая матрица», которая определяет действительность каждой выданной ему роли только в контексте четко ограниченного подмножества данных.
Так что новизны в описанном я лично не усматриваю, дело пахнет скорее очередной порцией криптических акронимов для заморачивания покупателю мозгов маркетинговыми квази-фичами. (На покупателей, поведенных на ИБ, особенно действует, это факт).
Отдельно замечу, что дерево связей подчиненности «у много сотрудников есть один общий непосредственный начальник» это не team, это еще одна совершенно отдельная структура. teams это кроссфункциональные «горизонтальные» команды, связи подчиненности — это вертикали функциональной оргструктуры, и просьба не путать.
Доступ пользователя в системе разделяется на 2 независимых «измерения»:
1. Деятельность: какие действия ему разрешены. Для этого вводятся хорошо нам знакомые роли. Обычный и привычный инструмент управления ролями — матрица, где строки соответствуют пользователям, столбцы — ролям, а ячейки — чекбоксы. Роли в нулевом приближении можно рассматривать как типовой набор SCRUD (aka BREAD) actions.
2. Доступность: какие данные в системе ему доступны. Для этого дополнительно вводятся — как это сделано, например, в платных версиях SugarCRM — teams (или нечто аналогичное по сути). Заметим, что роли в SugarCRM тоже есть.
teams обычно это дерево, в котором каждый узел «видит» только данные, видимые ему непосредственно плюс видимые всем его поддеревьям до листьев включительно.
Таким образом, мы получаем для каждого отдельного пользователя отдельную матрицу (обычно подразумеваемую, так как роли управляются в одном месте, а teams в другом) где в воображаемых строках — teams, в которые может быть включен пользователь, в столбцах — разрешенные действия. Таким образом можно включить пользователя одновременно в team «склад» и «продажи», но в рамках team склада разрешить только R (смотреть остатки) а в рамках team продаж — открывать сделки и выписывать счета, но не видеть при этом счета, выписанные коллегами.
Сами данные, несомненно, конфигурируются так, что система знает, какие записи какой таблицы каким teams видимы.
Эта модель давно не нова и вполне достаточна для реальных применений (с учетом того, что пользователь может быть и включен в несколько teams и иметь несколько ролей), главное — вот та самая «вторая матрица», которая определяет действительность каждой выданной ему роли только в контексте четко ограниченного подмножества данных.
Так что новизны в описанном я лично не усматриваю, дело пахнет скорее очередной порцией криптических акронимов для заморачивания покупателю мозгов маркетинговыми квази-фичами. (На покупателей, поведенных на ИБ, особенно действует, это факт).
Отдельно замечу, что дерево связей подчиненности «у много сотрудников есть один общий непосредственный начальник» это не team, это еще одна совершенно отдельная структура. teams это кроссфункциональные «горизонтальные» команды, связи подчиненности — это вертикали функциональной оргструктуры, и просьба не путать.
Ваш комментарий еще раз подтверждает то, что написано выше: средствами одной ролевой модели решить все проблемы доступа невозможно, для чего вводятся дополнительные инструменты. Из-за этого бизнес-правило «размазывается» по этими инструментам. Не имея жесткой связи между своими частями, это бизнес-правило легко может быть нарушено, если изменить одну его часть и забыть поменять другую.
Особенно, учитывая, что матрица для компании в несколько тысяч человек или десятков тысяч человек будет огромная.
Доступ к данным, конечно, можно разграничить заранее, если известно по какому принципу, но что делать, если это заранее неизвестно? Пример навскидку: «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик».
Не говоря уже о проверке атрибутов среды, таких как время или местоположение. Они дают возможность запрещать выполнения некоторых действий в нерабочее время, или при нахождении за пределами компании.
Подход с атрибутами позволяет задавать правила любой сложности и делать их компактными и наглядными. Глядя на них, даже обычный бизнес-пользователь поймет, что они означают. Их легко будет поддерживать, не обладая специфическими знаниями различных инструментариев. И уж тем более не придется вникать во всю матрицу, чтобы правильно расставить чекбоксы.
Особенно, учитывая, что матрица для компании в несколько тысяч человек или десятков тысяч человек будет огромная.
Доступ к данным, конечно, можно разграничить заранее, если известно по какому принципу, но что делать, если это заранее неизвестно? Пример навскидку: «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик».
Не говоря уже о проверке атрибутов среды, таких как время или местоположение. Они дают возможность запрещать выполнения некоторых действий в нерабочее время, или при нахождении за пределами компании.
Подход с атрибутами позволяет задавать правила любой сложности и делать их компактными и наглядными. Глядя на них, даже обычный бизнес-пользователь поймет, что они означают. Их легко будет поддерживать, не обладая специфическими знаниями различных инструментариев. И уж тем более не придется вникать во всю матрицу, чтобы правильно расставить чекбоксы.
средствами одной ролевой модели решить все проблемы доступа невозможно
кто бы спорил, лично я даже не попробую пытаться
мне вот интересно другое, «все проблемы доступа» лично вы сформулируете? (подсказка: слово «доступ» вы употребили несколько поспешно)
ну и продолжая разбор вопроса; наука о моделировании бизнеса четко структурирует: есть субъект, и есть контексты
* места (гео)
* времени
* объектов (данных)
* мотиваций (правил)
лучше всего об этом писали Zachmann & Sowa в 1992 а еще лучше — David C. Hay в 2006-2009 (книга издана).
Я к тому, что опыт измыслов сложной хрени, он в истории есть многократно. Сравним простую и легкую логику UNIX-систем с монстроидальной пирамидой Хеопса имени VAX VMS, которую команда Каттлера потом перенесла в Windows NT в виде системы ACL.
И кто из администраторов реальных Windows Server систем в течении следующих 20 лет хотя бы ПОНЯЛ, как работают эти ACL и зачем они нужны? Человек 20 на всю планету?
Давайте, если уж мы ведем беседу — вести ее по существу.
Отвечая на ваш вопрос, могу сказать, что ACL есть даже во многих популярных дистрибутивах линукса. Очевидно, что его понимает несколько больший круг людей, чем вы предполагаете.
Еще раз хочу заметить, что RBAC имеет ряд существенных проблем, в том числе и так называемая «role explosion». На примере исследования видно, что количество ролей обычно превышает количество пользователей в 1.5 раза. Представьте, насколько сложным становится администрирование такой огромной матрицы, если в компании несколько сотен или тысяч человек. Все эти проблемы призван решать ABAC.
Отвечая на ваш вопрос, могу сказать, что ACL есть даже во многих популярных дистрибутивах линукса. Очевидно, что его понимает несколько больший круг людей, чем вы предполагаете.
Еще раз хочу заметить, что RBAC имеет ряд существенных проблем, в том числе и так называемая «role explosion». На примере исследования видно, что количество ролей обычно превышает количество пользователей в 1.5 раза. Представьте, насколько сложным становится администрирование такой огромной матрицы, если в компании несколько сотен или тысяч человек. Все эти проблемы призван решать ABAC.
ABAC тоже решает многие проблемы только на бумаге. Предполагаю, вы используете XACML, насколько сложны ваши полиси? Все легко и удобно? Только не говорите про ALFA :)
Да, используем XACML, так как это единственный стандарт на сегодняшний день. Большие правила безопасности, написанные на XACML, действительно могут выглядеть очень монструозно, но с этим можно справиться. Тут весь вопрос заключается в инструменте администрирования этих политик безопасности. Я постараюсь осветить этот момент максимально подробно, показав в следующей статье как можно с этим справиться.
Мы с вами ведем беседу совершенно по существу, просто несколько разными семантиками.
Я утверждаю, что вся задача ИБ и управления access and authorization в любой системе (даже если в ней нет ни одного компьютера в принципе) состоит в
1) определении субъекта (как минимум это идентификация, но обычно аутентификация)
2) определения объекта — (под)множества данных или tangibles в отношении которых субъекту что-то «можно»
3) определения времени (момента)
4) определения места (тут есть интересно, но об этом далее)
5) определения действий, допустимых в контексте ранее определенных субъекта, объекта, времени и места
RBAC это просто акроним и маркетинговая трескотня, одна из упрощенных интертрепаций вышесказанного для неподготовленного слушателя. На самом деле, это просто п.5 но «сферический в вакууме» в отвязке от пп.2, 4 и особенно 3.
ABAC это тоже акроним и маркетинговая трескотня, но по сравнению с RBAC в ней хотя бы появляется упоминание места и времени, уже достижение, несомненно.
Но интересен другой вопрос, которого избегают продавцы snake oil и прочих «решений» — А НА… ЗАЧЕМ?
Приходит ко мне вот такой шаман из высших нематериальных ИБ-небесных-сфер и говорит — «дай мне денег, а я тебе за них сделаю ABAC и будет тебе щаззтье». Как нормальный рациональный человек, который считает СВОИ деньги, я начинаю прикидывать: а шо за «щаззтье» он мне предлагает?
Мне нахрен не нужно контролировать действия сотрудника в сложном контексте одновременно места и времени. Если он находится на рабочем месте, в рабочее время, ему разрешено работать в системе. Если место «не то» или время «не то» — то не разрешено. Всё.
Вариант «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик» занятен, но это отдает такими казенно-чиновными представлениями о человеческой и предпринимательской деятельности, что лично я за такое и копейки не заплачу.
Потому что все такого рода правила востребованы исключительно в контексте определенных деловых процессов (business process). В рамках одного процесса у меня одни правила (business rules) в рамках другого — другие. Для этого используется инструментарий Business Rules Engine который кроме желтых штанов «атрибутов» учитывает еще и время, и место (причем с учетом того, что в современном мире субъект и объект деятельности могут находиться каждый в совершенно своем географическом месте), и массу прочих привходящих факторов вроде «политики продаж» итд.
Ваш ABAC купят ФСБ РФ и прочие такого рода структуры. Там и бабла навалом, и делать нечего, а чем занимается сторожевая собака на цепи в свободное от несения вахты время, известно из народного фольклора.
Бизнес этого не купит.
Я утверждаю, что вся задача ИБ и управления access and authorization в любой системе (даже если в ней нет ни одного компьютера в принципе) состоит в
1) определении субъекта (как минимум это идентификация, но обычно аутентификация)
2) определения объекта — (под)множества данных или tangibles в отношении которых субъекту что-то «можно»
3) определения времени (момента)
4) определения места (тут есть интересно, но об этом далее)
5) определения действий, допустимых в контексте ранее определенных субъекта, объекта, времени и места
RBAC это просто акроним и маркетинговая трескотня, одна из упрощенных интертрепаций вышесказанного для неподготовленного слушателя. На самом деле, это просто п.5 но «сферический в вакууме» в отвязке от пп.2, 4 и особенно 3.
ABAC это тоже акроним и маркетинговая трескотня, но по сравнению с RBAC в ней хотя бы появляется упоминание места и времени, уже достижение, несомненно.
Но интересен другой вопрос, которого избегают продавцы snake oil и прочих «решений» — А НА… ЗАЧЕМ?
Приходит ко мне вот такой шаман из высших нематериальных ИБ-небесных-сфер и говорит — «дай мне денег, а я тебе за них сделаю ABAC и будет тебе щаззтье». Как нормальный рациональный человек, который считает СВОИ деньги, я начинаю прикидывать: а шо за «щаззтье» он мне предлагает?
Мне нахрен не нужно контролировать действия сотрудника в сложном контексте одновременно места и времени. Если он находится на рабочем месте, в рабочее время, ему разрешено работать в системе. Если место «не то» или время «не то» — то не разрешено. Всё.
Вариант «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик» занятен, но это отдает такими казенно-чиновными представлениями о человеческой и предпринимательской деятельности, что лично я за такое и копейки не заплачу.
Потому что все такого рода правила востребованы исключительно в контексте определенных деловых процессов (business process). В рамках одного процесса у меня одни правила (business rules) в рамках другого — другие. Для этого используется инструментарий Business Rules Engine который кроме желтых штанов «атрибутов» учитывает еще и время, и место (причем с учетом того, что в современном мире субъект и объект деятельности могут находиться каждый в совершенно своем географическом месте), и массу прочих привходящих факторов вроде «политики продаж» итд.
Ваш ABAC купят ФСБ РФ и прочие такого рода структуры. Там и бабла навалом, и делать нечего, а чем занимается сторожевая собака на цепи в свободное от несения вахты время, известно из народного фольклора.
Бизнес этого не купит.
На вопрос «зачем» — я как раз и пытался дать ответ в этой обзорной статье, и, как мне кажется, это не плохо получилось.
Если вы считаете, что у вас все проще и вам это не нужно, то ABAC для вас будет действительно избыточен. Я не собираюсь вам ничего продавать, это делают другие, если вы изучите ссылки, приведенные в конце статьи, вы увидите интересные, востребованные на рынке примеры.
Я лишь хочу познакомить вас и других читателей с тем, что еще существует, чтобы у вас был выбор при принятии решения.
Если вы считаете, что у вас все проще и вам это не нужно, то ABAC для вас будет действительно избыточен. Я не собираюсь вам ничего продавать, это делают другие, если вы изучите ссылки, приведенные в конце статьи, вы увидите интересные, востребованные на рынке примеры.
Я лишь хочу познакомить вас и других читателей с тем, что еще существует, чтобы у вас был выбор при принятии решения.
Хочу опровергнуть ваше финальное утверждение. Бизнес как раз и покупает ABAC, причем очень активно. Покупают и средние и большие компании. Я, признаться, не сторонник XACML, хотя и работаю в компании, которая решения исключительно на его базе и продает.
Основная проблема на мой взляд — стандарт явно «не удался»: местами перегружен ерундой, местами откровенно сложен, ну и просто достаточно высокий порог вхождения. Но, как уже было отмечено, это стандарт.
Проблема еще и в том, что XACML не очень легко спрятать за красивой «ширмой», как это делает, например, С с ассемблером. Но решение можно найти всегда. А компании, которые купят или разработают XACML решения, образуют новый рынок, на котором появятся новые инструменты, облегачающие работу и оптимизирующие все и вся.
Основная проблема на мой взляд — стандарт явно «не удался»: местами перегружен ерундой, местами откровенно сложен, ну и просто достаточно высокий порог вхождения. Но, как уже было отмечено, это стандарт.
Проблема еще и в том, что XACML не очень легко спрятать за красивой «ширмой», как это делает, например, С с ассемблером. Но решение можно найти всегда. А компании, которые купят или разработают XACML решения, образуют новый рынок, на котором появятся новые инструменты, облегачающие работу и оптимизирующие все и вся.
«Покупает» говорит о том, что это удается продать, однако как это связано с последующим применением и каков, условно говоря, ROI от такой покупки? Кто может привести примеры? TCO-то посчитать можно, а вот ROI?
Условный ROI вполне поддается оценке и подсчету, это ведь development tool впервую очередь. Из реальных примеров: один известный банк решает как-то более цивилизованно управлять доступом к своим документам, сервисам и т.д. Внутренний отдел, который занимается разработкой и интеграцией оценивает задачу и предлагает варианты. Все варианты оцениваются с точки зрения затрат на разработку, разветывание, интеграцию и т.д.
Один из вариантов предполагает «завязку» на стандарте и приоретение готового решения/инфраструктуры. Стоимость других вариантов также известна. Сравнивают, видят приятную экономию и времени и денег, принимают решение о покупке.
Один из вариантов предполагает «завязку» на стандарте и приоретение готового решения/инфраструктуры. Стоимость других вариантов также известна. Сравнивают, видят приятную экономию и времени и денег, принимают решение о покупке.
ACL есть даже во многих популярных дистрибутивах линукса. Очевидно, что его понимает несколько больший круг людей, чем вы предполагаетеСовершенно бездоказательное утверждение ;) интересно было бы увидеть ссылки например на опросы ИТ-спецов и сисадминов, из которых можно было бы составить хотя бы приблизительное мнение — какой % компаний реально использует ACL (в Linux, в Windows Server — неважно) и самое главное — как это либо помогло компании больше заработать, либо помогло меньше потратить, либо доказуемо снизило вероятность наступления каких-либо рисков.
А так, извините, все эти сложные навороченные нагромождения концепций, непонятных реальным пользователям — это сродни метровому фаллосу. Штука, несомненно, визуально и тактильно впечатляющая, но какого-либо реального применения в быту не имеет. Зато частенько мешает ходить и вынуждает заказывать одежду специального индивидуального покроя (что удорожает). :)
Интересная модель, но я не согласен про RBAC. Существуют роли, у ролей есть правила, правила можно реализовать в виде отдельной сущности (класса). В классе можно описать те же условия с атрибутами и вложить правила друг в друга, так что по проверке роли, вызвался ряд правил зависящих друг от друга.
Например: роль менеджер зависит от правила стоимости заказа < 100 000 руб. Компания разрослась на филиалы и появляется правило о филиале и городе. Связываем все три правила в одно «может принять доступный заказ», которое является дочерним для для «может принять заказ» через установку зависимостей и все. В итоге роль одна, правил 5 (принять заказ, принять доступный заказ, цена, город, филиал.) которые можно использовать в дальнейшем, например администратор может принять любой заказ, значит дадим ему правило «может принять заказ». Теперь проверив одно и тоже правило на разных ролях, получим разные заказы в зависимости от роли.
Например: роль менеджер зависит от правила стоимости заказа < 100 000 руб. Компания разрослась на филиалы и появляется правило о филиале и городе. Связываем все три правила в одно «может принять доступный заказ», которое является дочерним для для «может принять заказ» через установку зависимостей и все. В итоге роль одна, правил 5 (принять заказ, принять доступный заказ, цена, город, филиал.) которые можно использовать в дальнейшем, например администратор может принять любой заказ, значит дадим ему правило «может принять заказ». Теперь проверив одно и тоже правило на разных ролях, получим разные заказы в зависимости от роли.
Вы еще раз подтвердитили то, что написано в статье. Одних ролей вам не достаточно и вы добавляете новый инструмент — «правила» для того, чтобы оперировать аттрибутами. А это как раз и есть ABAC.
правила всегда были частью RBAC. из них собственно и состоят роли. Правила либо описываются как бизнес-правила (может создать пост на хабра), либо как уточняющие от дочерних (может создать пост только в песочнице дочка от может создать пост). Аналогично работает «может редактировать пост» -> «может редактировать свой пост». Первое правило — просто бизнес правило, второе дочка с уточнением авторства.
То что вы описываете — уже не классический RBAC. В RBAC разрешения вешаются только на роли, субъект в определении разрешений не участвует. Тем более, вы предлагаете «хардкодить» роли в виде классов. В ABAC мы просто описываем какими значениями должны обладать те или иные атрибуты для выполнения действия. А их значения вычисляются в момент проверки прав доступа инфраструктурой. Никакого «хардкода».
«Роль» по определению это описание (и ограничение) деятельностей. SCRUD или BREAD это именно вектор ролей.
«Субъекта» дело аутентифицироваться и авторизоваться для исполнения некого множества «ролей» в контексте некоторых ортогональных множеств интервалов времени, локаций мест, контекстов данных.
«Субъекта» дело аутентифицироваться и авторизоваться для исполнения некого множества «ролей» в контексте некоторых ортогональных множеств интервалов времени, локаций мест, контекстов данных.
Вы не правы. Я не предлагаю хардкодить классы, я лишь говорю что у общих правил могут быть дочерние правила в виде классов с минимальной бизнес логикой типа
post.createdBy == user.id
и дальнейшей проверкой общего бизнес правила, типа:
user.can('updatePost')
которое и вызовет дочку для уточнения, так как у обычного пользователя не может быть прав редактировать любой пост.
То что Вы называете действиями в ABAC, является правилами в RBAC. И, на мой взгляд, описание множества действий абсолютно аналогично описанию множества ролей, только вместо атрибутов в RBAC используются дочерние правила, которые приписываются не бездушным действиям, а ролями, определяющим должность или статус.
Извиняюсь заранее за ошибки и оформление комментария. Пишу с телефона.
post.createdBy == user.id
и дальнейшей проверкой общего бизнес правила, типа:
user.can('updatePost')
которое и вызовет дочку для уточнения, так как у обычного пользователя не может быть прав редактировать любой пост.
То что Вы называете действиями в ABAC, является правилами в RBAC. И, на мой взгляд, описание множества действий абсолютно аналогично описанию множества ролей, только вместо атрибутов в RBAC используются дочерние правила, которые приписываются не бездушным действиям, а ролями, определяющим должность или статус.
Извиняюсь заранее за ошибки и оформление комментария. Пишу с телефона.
Добавлю: из статьи на вики.
Роль является совокупностью прав(!)(примечание: право = правило из моего контекста) доступа на объекты компьютерной системы…
… его правила определяют порядок предоставления доступа субъектам компьютерной системы в зависимости от имеющихся (или отсутствующих) у него ролей в каждый (!) момент времени
Роль является совокупностью прав(!)(примечание: право = правило из моего контекста) доступа на объекты компьютерной системы…
… его правила определяют порядок предоставления доступа субъектам компьютерной системы в зависимости от имеющихся (или отсутствующих) у него ролей в каждый (!) момент времени
Можно и так трактовать, но обычно понимание роли постулируется как роли функциональной, то есть регламентирущей доступные деятельности в системе. Можно, конечно, попытаться толковать «роль» и расширенно-многомерно, как права на деятельность(и) в контекстах
— подмножества объектов деятельности,
— временнЫх ограничений на деятельности,
— ограничений местоположений, отдельно по субъекту и отдельно по объекту деятельности.
Но тут мы приходим снова-таки к тому, что при таком подходе деятельность является таким же контекстом (я кстати не понимаю, почему ABAC называет контексты атрибутами), как и остальные прочие — посему наборы бизнес-правил, в моем понимании, конструктивнее строить отдельно для каждого делового процесса с учетом как описанных выше контекстов, так и не описанных (как то «политики продаж» итд).
— подмножества объектов деятельности,
— временнЫх ограничений на деятельности,
— ограничений местоположений, отдельно по субъекту и отдельно по объекту деятельности.
Но тут мы приходим снова-таки к тому, что при таком подходе деятельность является таким же контекстом (я кстати не понимаю, почему ABAC называет контексты атрибутами), как и остальные прочие — посему наборы бизнес-правил, в моем понимании, конструктивнее строить отдельно для каждого делового процесса с учетом как описанных выше контекстов, так и не описанных (как то «политики продаж» итд).
Еще раз хочу подчеркнуть, что одних ролей вам оказалось недостаточно и вам пришлось «зашивать» в код те проверки, которые нельзя сделать в RBAC. Если во всей системе у вас будет всего лишь несколько таких проверок и они никогда не будут меняться, то тогда вам действительно будет дешевле использовать RBAC.
Но, если бизнес-требования будут более сложными и будут требовать проверки других атрибутов, такие проверки вам тоже придется «зашивать» в код. Что если вам нужно дать разрешение менять сущность, но некоторым пользователям должны быть доступны для изменения не все атрибуты, а лишь некоторая их часть? И что если вам нужно учитывать не только пользователя, но и время, ip-адрес, или еще какие-либо атрибуты субъекта и объекта, сравнивать их между собой или с динамически вычисляемым значением? Все это тоже придется «зашивать» в код, и у вас появятся все те проблемы, что я пытался показать в статье. А если эти правила еще и постоянно меняются то для их изменения потребуется привлечь программиста, протестировать изменения, выпустить новую версию приложения, обновить ее у заказчика — все это будет долго и дорого.
В случае ABAC инфраструктура просто получает все текущие атрибуты и проверяет их, используя заданные администратором в «текстовом» виде правила, менять которые дешево.
Грубо говоря, где-то на инфраструктурном уровне это может выглядеть, как: accessEngine.Check(action, subject, object, environment).
Об этом более углубленно я постараюсь рассказать в следующей статье, в которой буду разбирать существующий стандарт — XACML.
Но, если бизнес-требования будут более сложными и будут требовать проверки других атрибутов, такие проверки вам тоже придется «зашивать» в код. Что если вам нужно дать разрешение менять сущность, но некоторым пользователям должны быть доступны для изменения не все атрибуты, а лишь некоторая их часть? И что если вам нужно учитывать не только пользователя, но и время, ip-адрес, или еще какие-либо атрибуты субъекта и объекта, сравнивать их между собой или с динамически вычисляемым значением? Все это тоже придется «зашивать» в код, и у вас появятся все те проблемы, что я пытался показать в статье. А если эти правила еще и постоянно меняются то для их изменения потребуется привлечь программиста, протестировать изменения, выпустить новую версию приложения, обновить ее у заказчика — все это будет долго и дорого.
В случае ABAC инфраструктура просто получает все текущие атрибуты и проверяет их, используя заданные администратором в «текстовом» виде правила, менять которые дешево.
Грубо говоря, где-то на инфраструктурном уровне это может выглядеть, как: accessEngine.Check(action, subject, object, environment).
Об этом более углубленно я постараюсь рассказать в следующей статье, в которой буду разбирать существующий стандарт — XACML.
Думаю, мы ни к чему не придем в этом споре. Я объясняю что правила (business rules / access rules) это часть ролей. То есть роль это совокупность правил (прав), как право редактирования собственного поста. И их накопление и интеграция просты.
С другой стороны Вы повторяете что я «зашиваю» в код какие то проверки, которые не являются на самом деле частью Access Controll системы приложения. Интересно, как же тогда через RBAC производится проверка авторства или принадлежности к региону?
Опять же, я понял плюсы атрибутов, но я не вижу никакой разницы между действиями в ABAC и правилами (правами) в RBAC. Вопрос только в том что в ABAC можно динамически изменять количество проверяемых атрибутов, но для этого нужно иметь достаточно развитый UI, который можно сделать и для RBAC(генерация классов правил опять же вариант, или некое динамическое правило, которое обращается к БД или файлу за конфигурацией).
Если говорить о финансовой стороне, лично я считаю, что добавление нового атрибута ABAC, в реальном мире, так же отдается программисту, как и написание класса нового правила (права). Мне, как программисту, сложно представить сколько будет стоить система динамически программируемая с неизвестным количеством атрибутов и связей, а так же возможностью добавления новых, непредсказуемых связей, калькулируемых атрибутов и действий, а ведь именно такая система и должна быть, чтобы ее смогли обслуживать администраторы без привлечения программистов. Если же количество действий является константой, то количество проверок и атрибутов можно через те же правила в RBAC запрограммировать на уровне конфига и предоставить к нему UI, на мой взгляд это дешевле и легче в понимании.
За сим откланяюсь и буду следить за концепцией ABAC, вдруг я изменю свое мнение.
С другой стороны Вы повторяете что я «зашиваю» в код какие то проверки, которые не являются на самом деле частью Access Controll системы приложения. Интересно, как же тогда через RBAC производится проверка авторства или принадлежности к региону?
Опять же, я понял плюсы атрибутов, но я не вижу никакой разницы между действиями в ABAC и правилами (правами) в RBAC. Вопрос только в том что в ABAC можно динамически изменять количество проверяемых атрибутов, но для этого нужно иметь достаточно развитый UI, который можно сделать и для RBAC(генерация классов правил опять же вариант, или некое динамическое правило, которое обращается к БД или файлу за конфигурацией).
Если говорить о финансовой стороне, лично я считаю, что добавление нового атрибута ABAC, в реальном мире, так же отдается программисту, как и написание класса нового правила (права). Мне, как программисту, сложно представить сколько будет стоить система динамически программируемая с неизвестным количеством атрибутов и связей, а так же возможностью добавления новых, непредсказуемых связей, калькулируемых атрибутов и действий, а ведь именно такая система и должна быть, чтобы ее смогли обслуживать администраторы без привлечения программистов. Если же количество действий является константой, то количество проверок и атрибутов можно через те же правила в RBAC запрограммировать на уровне конфига и предоставить к нему UI, на мой взгляд это дешевле и легче в понимании.
За сим откланяюсь и буду следить за концепцией ABAC, вдруг я изменю свое мнение.
сложно представить сколько будет стоить система динамически программируемая с неизвестным количеством атрибутов и связей, а так же возможностью добавления новых, непредсказуемых связей, калькулируемых атрибутов и действий, а ведь именно такая система и должна быть, чтобы ее смогли обслуживать администраторы без привлечения программистов
вот-вот
О месте business rules в архитектуре предприНятия (англ. business) лучше всего сказали Zahmann, Sowa в 1988-1992 и как развитие их идей — David C. Hay в работах 2006-2013 годов.
А подскажите данную реализацию для Ruby (on Rails)?
Подход ABAC реализован в https://github.com/CanCanCommunity/cancancan .
Про реализацию стандарта XACML не подскажу.
Отличная статья, мы реализовали у себя в плагине Luxury buttons для Redmine нечто подобное. Правда не знал, что есть такая глубокая теория о правах доступа. Вроде как логически приходишь к ABAC.
Не совсем согласен с табличкой «Сравнение ABAC и RBAC»
У RBAC есть преимущества над ABAC: более простая реализация, менее сложный код приложения и более дешевая поддержка кода и т.д.
Не совсем согласен с табличкой «Сравнение ABAC и RBAC»
У RBAC есть преимущества над ABAC: более простая реализация, менее сложный код приложения и более дешевая поддержка кода и т.д.
Я бы сделал отсылку к одному из основателей и/или популяризаторов ABAC - Ruby-on-Rails библиотеке CanCan (ныне CanCanCan) . Имеет весьма приятный DSL для описания доступов и интеграцию и с контроллером, и с построителем запросов ActiveRecord.
Sign up to leave a comment.
Подходы к контролю доступа: RBAC vs. ABAC